Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
WPCEdit 2.0
07-13-2011, 11:04 AM (This post was last modified: 07-13-2011 12:21 PM by ecurtz.)
Post: #21
RE: WPCEdit 2.0
Heh, didn't realize you were here - there's been various speculation about how to do this (on re-reading I guess you're separate from the "color DMD" post there, but still a clever idea) on r.g.p. and at the pinballcontrollers.com forum.

I second the recommendation of looking at the PinMAME source, particularly the file wpc.c. We had to play with this some when we were working on driving the P-ROC board from PinMAME. I am 99% sure from looking at the source that the mixing of scores and other variable data is done by the main CPU. I can't tell if the DMD board actually stores those frames for PWM display or the CPU just changes them with the correct timing. It is possible that the ROM request is visible (but ignored) on the regular data bus that goes to the sound and driver boards. If you were that lucky you could identify the animations by address.

EDIT: Just looked at the WPC-95 schematic and the Bank Select signals don't go anywhere but the ROM. You'd need to socket the ROM if you wanted to spy on the address. (I guess it might be enough to have the 16 bit address available on the bus together with some checksum info and some guesses about the previous frame, but that would be pretty tough.)
Find all posts by this user
Quote this message in a reply
07-13-2011, 02:02 PM (This post was last modified: 07-13-2011 02:05 PM by planeta9999.)
Post: #22
RE: WPCEdit 2.0
(07-13-2011 11:04 AM)ecurtz Wrote:  Heh, didn't realize you were here - there's been various speculation about how to do this (on re-reading I guess you're separate from the "color DMD" post there, but still a clever idea) on r.g.p. and at the pinballcontrollers.com forum.

Mine is not Color-DMD, but curious that somebody was working with similar idea time ago. Well, but mine DMD with TFT monocolor, is already working, 100%, and do not need any modify of pinball, replace your old DMD-GAs or DMD-LED, and work inmediately. Not multicolor yet, but you may access to config menu and select color of pixel (15 colors available, next update RGB more than 260.000 colors) and shape of pixel (round and square). Im currently working in multicolor version.

Quote:I second the recommendation of looking at the PinMAME source, particularly the file wpc.c. We had to play with this some when we were working on driving the P-ROC board from PinMAME. I am 99% sure from looking at the source that the mixing of scores and other variable data is done by the main CPU.

Yes, but in Pinmame, there is not real DMD, but simulate by software, not same. In real DMD, there is a RAM memory that store 16 frames, so may be that when there are variable data, really one frame store only graphic data and next store variable data. I must test it yet, capturing frames that send video controller board to DMD.

Quote:I can't tell if the DMD board actually stores those frames for PWM display or the CPU just changes them with the correct timing. It is possible that the ROM request is visible (but ignored) on the regular data bus that goes to the sound and driver boards. If you were that lucky you could identify the animations by address.

No, no, from video controller board to DMD, there is none data about address of frame, only send ROWs - COLS with pixel status for each full frame, and its in serial format, one line with 128 pixels, next line with 128 pixels, and so on to line 32, then start again with next frame. To simulate brightness levels, send 3 frames for one full picture.

Quote:EDIT: Just looked at the WPC-95 schematic and the Bank Select signals don't go anywhere but the ROM. You'd need to socket the ROM if you wanted to spy on the address. (I guess it might be enough to have the 16 bit address available on the bus together with some checksum info and some guesses about the previous frame, but that would be pretty tough.)

Do not need hack real ROM in pinball, with WPCEdit software may see where are stored all frames, know address index for each frame, now need locat bits for each frame and replace first 12 bits to add one unique code by frame to identify it.

I thought about calculate a checksum, but not possible, because of variable data, except if variable data are not really mixed in same frame, and that will know when capture frames that send video controller board to DMD. I may do it with my current electronic circuit, will modify firmware to capture frames and send to PC by USB.
Find all posts by this user
Quote this message in a reply
07-13-2011, 02:20 PM
Post: #23
RE: WPCEdit 2.0
PinMAME does emulate the CPU, and the DMD screens it generates are taken right out of the CPU memory - what would get sent to the DMD board on real hardware. You can look at the individual frames, and see if the text is on a separate layer, but I'm pretty sure it isn't.

I was thinking of checking the address of ROM reads as an alternative to custom ROMs, if you're going to do custom ROMs it isn't required (although things like compressed images might be a nightmare.)
Find all posts by this user
Quote this message in a reply
07-14-2011, 06:07 AM (This post was last modified: 07-14-2011 06:09 AM by planeta9999.)
Post: #24
RE: WPCEdit 2.0
(07-13-2011 02:20 PM)ecurtz Wrote:  PinMAME does emulate the CPU, and the DMD screens it generates are taken right out of the CPU memory - what would get sent to the DMD board on real hardware. You can look at the individual frames, and see if the text is on a separate layer, but I'm pretty sure it isn't.

Do you know source code file where make it Pinmame ??.
Possible debug frames in screen, or must check source code ??

Quote:I was thinking of checking the address of ROM reads as an alternative to custom ROMs, if you're going to do custom ROMs it isn't required (although things like compressed images might be a nightmare.)

But address of ROM are not available in video controller board, board only store 16 full frames, 4096 pixels by frame, total 64K memory. So, if variable data are always mixed with video animation, only possible identify each frame if include some code in the first bits of each frame, so need modify ROM, do not know another possible system if can not apply checksum.

Compressed images are not a problem, because of though include the code may modify the look of original image, finally my board replace the original frame by my colorized frame. I only need, really, a code to identify the frame, though the rest of image is lost.
Find all posts by this user
Quote this message in a reply
07-14-2011, 06:48 AM
Post: #25
RE: WPCEdit 2.0
Quote:Do you know source code file where make it Pinmame ??.
Possible debug frames in screen, or must check source code ??

The frame is copied out of CPU memory in INTERRUPT_GEN() and combined with the previous frames to simulate the DMD levels in PINMAME_VIDEO_UPDATE(). Both functions are in the file wpc.c . If you wanted to have them displayed differently you could change PINMAME_VIDEO_UPDATE(), but you'd need to recompile.

If you just want to see the individual frames that should be possible using the command line flags for adjusting the DMD:
-dmd_perc66 0-100 (Sets the Percentage to display a DMD Dot which is lit at 66%, Default = 67%)
-dmd_perc33 0-100 (Sets the Percentage to display a DMD Dot which is lit at 33%, Default = 34%)
-dmd_perc0 0-100 (Sets the Percentage to display a DMD Dot when NOT lit.

I think if you set -dmd_perc66 and -dmd_perc33 both to 0 you'll only see a single on/off frame each update.

Quote:Compressed images are not a problem, because of though include the code may modify the look of original image

I was worried a compressed image may not fit back in the same ROM space after you modified it. Maybe that isn't an issue.
Find all posts by this user
Quote this message in a reply
07-14-2011, 11:40 AM (This post was last modified: 07-14-2011 11:57 AM by planeta9999.)
Post: #26
RE: WPCEdit 2.0
Quote:The frame is copied out of CPU memory in INTERRUPT_GEN() and combined with the previous frames to simulate the DMD levels in PINMAME_VIDEO_UPDATE(). Both functions are in the file wpc.c . If you wanted to have them displayed differently you could change PINMAME_VIDEO_UPDATE(), but you'd need to recompile.

If you just want to see the individual frames that should be possible using the command line flags for adjusting the DMD:
-dmd_perc66 0-100 (Sets the Percentage to display a DMD Dot which is lit at 66%, Default = 67%)
-dmd_perc33 0-100 (Sets the Percentage to display a DMD Dot which is lit at 33%, Default = 34%)
-dmd_perc0 0-100 (Sets the Percentage to display a DMD Dot when NOT lit.

I think if you set -dmd_perc66 and -dmd_perc33 both to 0 you'll only see a single on/off frame each update.

Ok, thanks, I will check it.

Quote:I was worried a compressed image may not fit back in the same ROM space after you modified it. Maybe that isn't an issue.

No problem about it, only need replace bytes, with WINHEX, but always must keep same space, same quantity of bytes, I do not modify total bytes, do not add or remove bytes, only replace the 2 first bytes of a frame (16 bits). Its like hack a software to patch it, can not modify size of code, only replace some bytes to change how it work.

Obviously must check, which compress algorithm apply, seem may use about 12 different compress algorithms. Im checking source code of WPCEDIT to understand how ROM store frames, locate where start each one and modify with WINHEX editor.

As soon as I understand how and where store it, I will do software to include automatically a sequential code in the begining of each frame, in every ROM file. I think its possible, and not very hard. Modify some bytes may mean that some pixels of original frame will lost, but its not problem, do not need it, only frame code identification.


Basically, will need develop a software with following options:

1.- Add identification code to each frame in original ROM (really do not add, but REPLACE first 2 bytes of each frame, by sequential unique code).
2.- Extract all frames, to new file (one full picture for each two frames), with a simple compress system (color - number of pixels, color - number of pixels, etc...)
3.- Option to edit graphically the new frames (really here, one picture that mix two frames), to colorize each one. May select color from a pallete of 256, manual color of pixel with mouse (select color, put mouse on pixel and push left button to colorize), semiautomatic option (select rectangular area of picture and apply automatically conversion brigthness levels to colors, with 3 colors selected manually), show colors used in before frame to colorize new frame (because of this is like a cartoon film, several frames are one full videoanimation)...

May be more options, to help to colorize frames, because of there are many frames in each pinball, about 900 full pictures (1800 frames) in a pinball like CV.
Find all posts by this user
Quote this message in a reply
07-14-2011, 07:08 PM
Post: #27
RE: WPCEdit 2.0
I am sure the WPC s/w does all of the combining of static and variable image data into a single, mixed image in CPU board RAM. (Actually 2 layers are stored in ram, one for "medium" and one for "dim" pixels like how WPCEdit displays the two planes).

Since WPC s/w does all of the blending of image data, I'm not sure exactly what you mean by simply adding a number to each "frame". What is a "frame" really? For example on IJ there is the captive ball totem animation when you smack the captive ball. It has your score or variable data on the left of the DMD, and on the right it is animating the totem vertical movement, and also there is a smoke or dust cloud as the totem falls into the bottom of the display. So the totem graphic itself is a single oversized image which the WPC s/w knows the totem is 3x the height of the DMD display, and it knows how to scroll the single image down the DMD (WPCEdit had to be coded special to show extra large vertical images).

Or consider IJ raven bar video mode. Again, it's an oversized horizontal image which scrolls left and right. Occasionally random bad guys show up. So here are multiple images shown on the display. I don't really understand what you mean by applying a single number to represent a "frame".

Another hurdle would be to disassemble the WPC s/w enough to understand how to get the CPU board to include an index number with graphic data. This in itself would be a pretty big undertaking but not impossible. If you're lucky, all WPC pins will use the same code so it would be easy to patch ROMs.
Find all posts by this user
Quote this message in a reply
07-15-2011, 12:07 AM
Post: #28
RE: WPCEdit 2.0
(07-14-2011 07:08 PM)mrglee Wrote:  I am sure the WPC s/w does all of the combining of static and variable image data into a single, mixed image in CPU board RAM. (Actually 2 layers are stored in ram, one for "medium" and one for "dim" pixels like how WPCEdit displays the two planes).

Ok, then not possible apply checksum.

Quote:Since WPC s/w does all of the blending of image data, I'm not sure exactly what you mean by simply adding a number to each "frame". What is a "frame" really?

Well, at least the frames that show currently your software. There you show an index that point to address-bank. So, I think about modify the 2 first bytes of that address-bank, where is stored the frame.

I need that my board receive each frame with a unique code to identify it. Then replace original frame by new colorized, thought really will keep also pixels from original frame that are not in mine, so may mix drawing with variable data.

Quote: For example on IJ there is the captive ball totem animation when you smack the captive ball. It has your score or variable data on the left of the DMD, and on the right it is animating the totem vertical movement, and also there is a smoke or dust cloud as the totem falls into the bottom of the display. So the totem graphic itself is a single oversized image which the WPC s/w knows the totem is 3x the height of the DMD display, and it knows how to scroll the single image down the DMD (WPCEdit had to be coded special to show extra large vertical images).

Then understand that some pictures stored in ROM, do not show in DMD full, but may be scrolled by CPU. This complicate this matter.

Quote:Or consider IJ raven bar video mode. Again, it's an oversized horizontal image which scrolls left and right. Occasionally random bad guys show up. So here are multiple images shown on the display. I don't really understand what you mean by applying a single number to represent a "frame".

I thought only about the frames that show your software, did not know that CPU applied scroll to some original oversized images.


Quote:Another hurdle would be to disassemble the WPC s/w enough to understand how to get the CPU board to include an index number with graphic data. This in itself would be a pretty big undertaking but not impossible. If you're lucky, all WPC pins will use the same code so it would be easy to patch ROMs.

I will check it, assembler is really a very hard language, but not impossible.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


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