Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
WPCEdit 2.0
03-24-2011, 11:08 PM
Post: #1
WPCEdit 2.0
Attached is WPCEdit2.0 exe.

- Displays the font table images from WPC ROMs.
- Displays images found from Animation table in WPC ROMs.

Font data appears to be viewable from all WPC ROMs.
Animation table is sketchy. Depends on how organized the ROM s/w was put together. In IJ_L7, for example, a list of all animations are neatly stored in one place (the "Animation Table" which is right after the full-frame graphics table which WPC Edit has always shown). In other ROMs, the normal "animation table" simply points back to the font table so you'll see same images in font an animation windows. In other ROMs, they may store a few valid animations in the normal "animation table" but there's no reason the ROM couldn't store other animations, elsewhere in the ROM, and not have it listed in the animation table.

I hope you have as much fun using WPCEdit as I have had creating it!


Attached File(s)
.zip  WPCEdit20.zip (Size: 49.77 KB / Downloads: 647)
Find all posts by this user
Quote this message in a reply
03-25-2011, 08:58 AM
Post: #2
RE: WPCEdit 2.0
Very cool, man! Thanks for taking the time to do this.
Find all posts by this user
Quote this message in a reply
06-06-2011, 04:31 PM
Post: #3
RE: WPCEdit 2.0
Attached is source code for WPCEdit 2.0.
I use and old compiler, Microsoft Visual C++ 5.0 (Visual Studio 97) to make the exe on a Windows XP Professional workstation.

You may notice significant differences from the previous source code. I tried to remove tabs and make it spaces for easier readability. The graphicic table is now found using different method (it looks for the font table and then assumes the graphic table is immediately prior to the font table (which I found is always true).

Let me know if you have any questions. I'm happy to help.


Attached File(s)
.zip  WPCEdit20Source.zip (Size: 160.88 KB / Downloads: 529)
Find all posts by this user
Quote this message in a reply
06-28-2011, 09:24 AM
Post: #4
RE: WPCEdit 2.0
(06-06-2011 04:31 PM)mrglee Wrote:  Attached is source code for WPCEdit 2.0.
I use and old compiler, Microsoft Visual C++ 5.0 (Visual Studio 97) to make the exe on a Windows XP Professional workstation.

You may notice significant differences from the previous source code. I tried to remove tabs and make it spaces for easier readability. The graphicic table is now found using different method (it looks for the font table and then assumes the graphic table is immediately prior to the font table (which I found is always true).

Let me know if you have any questions. I'm happy to help.

Hello:


Very cool your tool, thanks for share it.

One suggestion:
Its possible, add some option to save all frames in external file ???

I have try to read your source code, to locate WHERE are stored frames, but do not locate it. Also try to understand how know where start index in each pinball file, because of seem its different in each file. May you help about it ???

I tried to do it, to see if I may modify source, to add option to save frames in external files. Seem that each frame index is 3 bytes, that suppose point to some site in file where is store the frame.



Kind Regards
Find all posts by this user
Quote this message in a reply
06-29-2011, 06:47 PM
Post: #5
RE: WPCEdit 2.0
Thanks for the suggestion about saving frames to a file. You can use Alt+print-screen key on your keyboard and paste into graphics editor if you want. What format would you expect the data to be exported? Just to name a few, there's a jpeg showing same thing you get in wpcEdit, ascii art, HEX dump of each image compressed, hex dump of an uncompressed version of the image.

WPC ROMs have lots of data tables. Tables are usually in 3-byte paged address format or in some roms you might find 2-byte addressing implying the current bank or the non-banked region.

WPCEdit is coded knowing that the animation table, graphics table and font table pointers are always next to each other, so first WPCEdit finds the font table pointer and then it immediately knows the animation and graphics table pointers.

After the data table pointer is known, it is used to read the particular table. Or in some cases it points to another table of pointers (for example the font table pointer points to a list of other pointers, each one representing a particular font table). So when WPCEdit lists the full-frame graphics, it just uses the graphics table pointer and walks the list of pointers that are in the table. Each pointer points to the compressed graphic in the ROM.

If the above statements don't make a lot of sense I think it's a good idea to read my post titled "WPC Banked Rom Addresses".

Also I have a debug mode in WPCEdit 2.0, if you hold the shift-key down while opening the graphics-viewer window (select the ROM file to use, then hold shift, then click on the button that opens the DMD viewer). Debug mode will show some addresses found in the ROM and used by wpc edit. You can see in dmd.cpp source code file exactly where the debug messages are generated with call to function "DebugShiftKeyMsgStrPrint()".

Also I noticed I did NOT remove <tab> characters from the source code, sorry about that. I guess tabs yield a smaller file size so maybe that's why I left them in.
Find all posts by this user
Quote this message in a reply
06-30-2011, 02:14 PM
Post: #6
RE: WPCEdit 2.0
(06-29-2011 06:47 PM)mrglee Wrote:  Thanks for the suggestion about saving frames to a file. You can use Alt+print-screen key on your keyboard and paste into graphics editor if you want. What format would you expect the data to be exported? Just to name a few, there's a jpeg showing same thing you get in wpcEdit, ascii art, HEX dump of each image compressed, hex dump of an uncompressed version of the image.

Thanks your your help.
About format to save do not know exactly, I want may extract full frames where define status of each 4096 pixel of a full picture.

And about it, there is something that do not understand. Your software read TWO frames do to ONE image, so this mean 3 grey levels (black, white and grey), but I have read in several forums, and also in Pinmame source code that WPC have 4 grey levels, so really need THREE frames to do one full picture.

May clarify about it ???


Quote:WPC ROMs have lots of data tables. Tables are usually in 3-byte paged address format or in some roms you might find 2-byte addressing implying the current bank or the non-banked region.

WPCEdit is coded knowing that the animation table, graphics table and font table pointers are always next to each other, so first WPCEdit finds the font table pointer and then it immediately knows the animation and graphics table pointers.

Ok, understand.
But how locate the font table ???

Quote:After the data table pointer is known, it is used to read the particular table. Or in some cases it points to another table of pointers (for example the font table pointer points to a list of other pointers, each one representing a particular font table). So when WPCEdit lists the full-frame graphics, it just uses the graphics table pointer and walks the list of pointers that are in the table. Each pointer points to the compressed graphic in the ROM.

For example in Theatre of Magic ROM, first frame index is in 0x26487. I open ROM file with WINHEX, go to that address, and there see 41 14 20, I understand that those 3 bytes point to some site in ROM where is this frame compressed.

But which address in ROM is 41 14 20 ???
Its 0x411420 ???, understand that not because of last address in rom file is 7FFFF.


Quote:If the above statements don't make a lot of sense I think it's a good idea to read my post titled "WPC Banked Rom Addresses".

I will read, thanks, to see if I may understand where are locate each bank.


Quote:Also I have a debug mode in WPCEdit 2.0, if you hold the shift-key down while opening the graphics-viewer window (select the ROM file to use, then hold shift, then click on the button that opens the DMD viewer). Debug mode will show some addresses found in the ROM and used by wpc edit. You can see in dmd.cpp source code file exactly where the debug messages are generated with call to function "DebugShiftKeyMsgStrPrint()".

Good, debug is always very useful.
Find all posts by this user
Quote this message in a reply
06-30-2011, 06:51 PM
Post: #7
RE: WPCEdit 2.0
(06-30-2011 02:14 PM)planeta9999 Wrote:  
(06-29-2011 06:47 PM)mrglee Wrote:  Thanks for the suggestion about saving frames to a file. You can use Alt+print-screen key on your keyboard and paste into graphics editor if you want. What format would you expect the data to be exported? Just to name a few, there's a jpeg showing same thing you get in wpcEdit, ascii art, HEX dump of each image compressed, hex dump of an uncompressed version of the image.

Thanks your your help.
About format to save do not know exactly, I want may extract full frames where define status of each 4096 pixel of a full picture.

And about it, there is something that do not understand. Your software read TWO frames do to ONE image, so this mean 3 grey levels (black, white and grey), but I have read in several forums, and also in Pinmame source code that WPC have 4 grey levels, so really need THREE frames to do one full picture.

May clarify about it ???

There's 4 colors if you include black or off pixel. One bitmap represents medium pixels and one represents dim pixels. As a convience, WPCEdit then overlays them on top of each other in the 3rd pane where it shows bright pixels whereever there's a pixel set in both medium and dim panes. This is pretty much the same thing that the WPC game s/w does while it's running.

(06-30-2011 02:14 PM)planeta9999 Wrote:  
Quote:WPC ROMs have lots of data tables. Tables are usually in 3-byte paged address format or in some roms you might find 2-byte addressing implying the current bank or the non-banked region.

WPCEdit is coded knowing that the animation table, graphics table and font table pointers are always next to each other, so first WPCEdit finds the font table pointer and then it immediately knows the animation and graphics table pointers.

Ok, understand.
But how locate the font table ???

See function DMD::InitTableAddrs(), it just looks for signaure of the opcodes amongst all of the WPC roms where their code reads the font table. If this is hard to follow, you may want to study up on Motorola 6809 assembly language.

(06-30-2011 02:14 PM)planeta9999 Wrote:  
Quote:After the data table pointer is known, it is used to read the particular table. Or in some cases it points to another table of pointers (for example the font table pointer points to a list of other pointers, each one representing a particular font table). So when WPCEdit lists the full-frame graphics, it just uses the graphics table pointer and walks the list of pointers that are in the table. Each pointer points to the compressed graphic in the ROM.

For example in Theatre of Magic ROM, first frame index is in 0x26487. I open ROM file with WINHEX, go to that address, and there see 41 14 20, I understand that those 3 bytes point to some site in ROM where is this frame compressed.

But which address in ROM is 41 14 20 ???
Its 0x411420 ???, understand that not because of last address in rom file is 7FFFF.

There are two types of addresses. ROM address and WPC Address. You're confusing the two. A ROM Address is 0 to 0x7FFFF. A WPC Address is 0x4000-0x7FFF for paged address, or 0x8000 - 0x7FFF for non-paged address. You are looking at 0x4114 which is a paged address. The third byte 0x20 is the page (or bank, I use "page" and "bank" interchangebly).

(06-30-2011 02:14 PM)planeta9999 Wrote:  
Quote:If the above statements don't make a lot of sense I think it's a good idea to read my post titled "WPC Banked Rom Addresses".

I will read, thanks, to see if I may understand where are locate each bank.


Quote:Also I have a debug mode in WPCEdit 2.0, if you hold the shift-key down while opening the graphics-viewer window (select the ROM file to use, then hold shift, then click on the button that opens the DMD viewer). Debug mode will show some addresses found in the ROM and used by wpc edit. You can see in dmd.cpp source code file exactly where the debug messages are generated with call to function "DebugShiftKeyMsgStrPrint()".

Good, debug is always very useful.
Find all posts by this user
Quote this message in a reply
07-02-2011, 06:41 AM (This post was last modified: 07-02-2011 08:40 AM by planeta9999.)
Post: #8
RE: WPCEdit 2.0
Quote:There's 4 colors if you include black or off pixel. One bitmap represents medium pixels and one represents dim pixels. As a convience, WPCEdit then overlays them on top of each other in the 3rd pane where it shows bright pixels whereever there's a pixel set in both medium and dim panes. This is pretty much the same thing that the WPC game s/w does while it's running.

What is exactly a dim pixel ???

I thought that a pixel had only two status, ON or OFF, in every frame.
So according with it, with two frames, there are only 3 grey levels, because of a pixel may be OFF in both frames (black), ON in both frames (white), ON in one frame OFF in next frame (grey level, or 50% white).

Do not understand what do you mean about Dim pixels, and how get the 4th grey level with two frames.

Quote:After the data table pointer is known, it is used to read the particular table. Or in some cases it points to another table of pointers (for example the font table pointer points to a list of other pointers, each one representing a particular font table). So when WPCEdit lists the full-frame graphics, it just uses the graphics table pointer and walks the list of pointers that are in the table. Each pointer points to the compressed graphic in the ROM.

What is for the font table ???
Its to show variable texts in screen, like the Scores, ball in game, etc... ??

I have think about it, too.
I understand that in frames of videoanimations, are not the variable data like scores that show in some animations, so understand that must mix frames of videoanimations with scores when need.

Quote:There are two types of addresses. ROM address and WPC Address. You're confusing the two. A ROM Address is 0 to 0x7FFFF. A WPC Address is 0x4000-0x7FFF for paged address, or 0x8000 - 0x7FFF for non-paged address. You are looking at 0x4114 which is a paged address. The third byte 0x20 is the page (or bank, I use "page" and "bank" interchangebly).

OK, fine, I understand now.
I have read a little about 6809 processor, and seem that can not manage all ROM addresses directly, but in banks, so really those 3 bytes are address + bank.

At any rate, do you have think about add some option to your software, to dump frames to external files ???
Even may be very interesting, some option to modify directly in graphical mode, each frame, though I think this may be really hard because of frames are then stored compressed and with different compress modes.


Regards
Find all posts by this user
Quote this message in a reply
07-02-2011, 07:13 PM
Post: #9
RE: WPCEdit 2.0
(07-02-2011 06:41 AM)planeta9999 Wrote:  
Quote:There's 4 colors if you include black or off pixel. One bitmap represents medium pixels and one represents dim pixels. As a convience, WPCEdit then overlays them on top of each other in the 3rd pane where it shows bright pixels whereever there's a pixel set in both medium and dim panes. This is pretty much the same thing that the WPC game s/w does while it's running.

What is exactly a dim pixel ???

I thought that a pixel had only two status, ON or OFF, in every frame.
So according with it, with two frames, there are only 3 grey levels, because of a pixel may be OFF in both frames (black), ON in both frames (white), ON in one frame OFF in next frame (grey level, or 50% white).

Do not understand what do you mean about Dim pixels, and how get the 4th grey level with two frames.

Different people use different words. Every pixel on the DMD, as the user sees it, has 4 states which I chose to name as follows:
1 - off (or black)
2 - dim, visible but not very bright.
3 - medium, more illimination than dim, but not brightest.
4 - bright, brightest.

The terminology is just what I came up with using English words. It's likely that the manufacturer of the DMD panels use different words. It's also likely that the people at Williams used different words, and also the pinMame guys use even different words. I just chose the words "dim", "medium" and "bright" because they make sense to me and I'm not trying to conform to any particular standard.

Since the DMD can display 4 colors (remember, I'm calling "off" a color here), the guys at Williams could have stored the image data in the ROM with 2 bits per pixel. You can count 0, 1, 2, 3 with 2-bit pixel encoding. They could have stored the 4-color bitmaps somewhere in the ROM and then send the 4-color image to the DMD in some part of the code. BUT this is not what they did. They stored monochrome bitmaps with the WPC code knowing that one bitmap represents "dim" pixels and another bitmap represents "medium" pixels. Then their code is smart enough to know how to read the two monochrome bitmaps into a single 4-color bitmap which the DMD can then display (again, I'm saying 4-color with the idea that off is a color, black).

(07-02-2011 06:41 AM)planeta9999 Wrote:  
Quote:After the data table pointer is known, it is used to read the particular table. Or in some cases it points to another table of pointers (for example the font table pointer points to a list of other pointers, each one representing a particular font table). So when WPCEdit lists the full-frame graphics, it just uses the graphics table pointer and walks the list of pointers that are in the table. Each pointer points to the compressed graphic in the ROM.

What is for the font table ???
Its to show variable texts in screen, like the Scores, ball in game, etc... ??

Mostly yes. The font table is a table that contains different bitmap encoding for different alphabet letters and numbers (and other characters). Most of the fonts are single color although some font characters have special encodings which tell the WPC code to display part of the font bitmap in the dim color and the other in the medium. In addition to ASCII bitmaps, they can also store graphic data in the font table. For example maybe they could put the animation of a horse. Letter 'A' could the the image of a horse. Letter 'B' could be the image of the horse with legs moved. The other letters could show more movement. Then the WPC code could use the font table to display an animation by calling a function that says "Print Letter 'A' on the DMD using horse font". Then they could "Print Letter 'B' on the DMD using horse font. And so on. That could create an animation of the horse but the WPC code thinks its just printing a font character (which it is).

(07-02-2011 06:41 AM)planeta9999 Wrote:  I have think about it, too.
I understand that in frames of videoanimations, are not the variable data like scores that show in some animations, so understand that must mix frames of videoanimations with scores when need.

Quote:There are two types of addresses. ROM address and WPC Address. You're confusing the two. A ROM Address is 0 to 0x7FFFF. A WPC Address is 0x4000-0x7FFF for paged address, or 0x8000 - 0x7FFF for non-paged address. You are looking at 0x4114 which is a paged address. The third byte 0x20 is the page (or bank, I use "page" and "bank" interchangebly).

OK, fine, I understand now.
I have read a little about 6809 processor, and seem that can not manage all ROM addresses directly, but in banks, so really those 3 bytes are address + bank.

At any rate, do you have think about add some option to your software, to dump frames to external files ???
Even may be very interesting, some option to modify directly in graphical mode, each frame, though I think this may be really hard because of frames are then stored compressed and with different compress modes.

I have no plans on putting in an export function. It's not really the direction I wanted to take WPCEdit software. There are too many formats that people would want and I could spend months working on something that nobody would necessarily use. A s/w guy might want HEX encoding of uncompressed image. A hacker type guy might want to see the HEX encoding of the compressed image. A graphic artist might want the pixel image graphic just like you see in WPCEdit exported in a jpg, or gif, or some other particular graphic format. A web developer might want to have font data exported into a standard font file for use in a word processor. I actually have all of the info in WPCEdit to satisfy those who really want to put the effort into getting what they want. You can use the print-screen feature to get the image into a JPG. You can look at the addresses shown on the WPCEdit window to see the address of the image in the ROM file.

Regards
[/quote]

No problem. You ask good questions. Happy to help.
Find all posts by this user
Quote this message in a reply
07-03-2011, 11:42 AM (This post was last modified: 07-03-2011 11:50 AM by planeta9999.)
Post: #10
RE: WPCEdit 2.0
Quote:Different people use different words. Every pixel on the DMD, as the user sees it, has 4 states which I chose to name as follows:
1 - off (or black)
2 - dim, visible but not very bright.
3 - medium, more illimination than dim, but not brightest.
4 - bright, brightest.

The terminology is just what I came up with using English words. It's likely that the manufacturer of the DMD panels use different words. It's also likely that the people at Williams used different words, and also the pinMame guys use even different words. I just chose the words "dim", "medium" and "bright" because they make sense to me and I'm not trying to conform to any particular standard.

Since the DMD can display 4 colors (remember, I'm calling "off" a color here), the guys at Williams could have stored the image data in the ROM with 2 bits per pixel. You can count 0, 1, 2, 3 with 2-bit pixel encoding. They could have stored the 4-color bitmaps somewhere in the ROM and then send the 4-color image to the DMD in some part of the code. BUT this is not what they did. They stored monochrome bitmaps with the WPC code knowing that one bitmap represents "dim" pixels and another bitmap represents "medium" pixels. Then their code is smart enough to know how to read the two monochrome bitmaps into a single 4-color bitmap which the DMD can then display (again, I'm saying 4-color with the idea that off is a color, black).


I think I understand now how CPU play grey levels. Really my confusion was because of I thought about how CPU send data to Video controller board, how this store pictures and how send it to DMD.

I have develop an electronic circuit to do some tests with DMD. I know that controller board has a 64K RAM memory to store pictures, because of each full screen is 4K, then suppose that store 16 frames.

Controller board, send very fast two frames by picture, to generate one full picture with all grey levels. But I supossed, and probably it's my mistake, that each two frames generate ONE full screen, and that EACH frame send from video controler board to DMD, ONE time, so with that idea only 3 grey levels possible.

I must check yet with my electronic circuit, exactly which information send video controller board to DMD, but I suspect that really, send first frame ONE time, and second frame TWO times, so may generate 4 grey levels, like show your software.

I will test soon, its like capture content of Video controller RAM (64K), and check what send controller board to DMD.


Thanks for your help.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)