Post Reply 
 
Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
WPCEdit 2.0
07-03-2011, 07:12 PM
Post: #11
RE: WPCEdit 2.0
I see where the confusion came from. I was looking at it strictly from a WPC software and pinball player's point of view. It sounds like you were looking at it from a pure hardware point of view, say, from the DMD controller board's point of view, or somebody who had a DMD panel and its datasheet, but not necessarily knowledge of how it works in the WPC architecture.

Based on your comment, I suspect the DMD itself could offer infinite brightness levels, but the engineerers at Williams chose to implement 3 brightness levels (and the off pixel) when designing the WPC DMD driver board (and WPC software).
Find all posts by this user
Quote this message in a reply
07-04-2011, 05:49 AM (This post was last modified: 07-04-2011 10:08 AM by planeta9999.)
Post: #12
RE: WPCEdit 2.0
(07-03-2011 07:12 PM)mrglee Wrote:  I see where the confusion came from. I was looking at it strictly from a WPC software and pinball player's point of view. It sounds like you were looking at it from a pure hardware point of view, say, from the DMD controller board's point of view, or somebody who had a DMD panel and its datasheet, but not necessarily knowledge of how it works in the WPC architecture.

Yes, you are right.

Im engineer and I was software programmer for 18 years. Now Im developing several electronic circuits for pinball, and one of those products is a DMD with a TFT panel. I have already developed the board, only need now develop the software for the PIC32 Microcontroller that install my board.

I will try to do software in C language, and if not enough fast will try in Assembler. If even its not enought fast, then will must use an FPGA chip.


Quote:Based on your comment, I suspect the DMD itself could offer infinite brightness levels, but the engineerers at Williams chose to implement 3 brightness levels (and the off pixel) when designing the WPC DMD driver board (and WPC software).

Not exactly, really a pixel in DMD may has only two status, ON or OFF, but if you ON and OFF very fast each pixel, you may simulate brightness levels.

So, I think that video controller board simulate brightness levels in DMD, sending 3 frames very fast to the DMD for each full picture, with 3 frames are possible 4 brightness levels for each pixel:

OFF - OFF - OFF --- black
ON - OFF - OFF ---- 33%
ON - ON - OFF ---- 66%
ON - ON - ON ----- 99%

So, really though you read in ROM two frames, and one frame store the pixels with 33% and other with 66% brightness levels, the 64K RAM memory of video controller board, only may store status ON and OFF for each pixel (4096 by picture). The system to generate 4 brightness levels in DMD, must to be probably send first frame ONE time, and second frame TWO times (total 3 frames, second repeat two times), all happen very fast, so visually seem ONE full picture with 4 brightness levels.

I suppose about it, after this very interesting post, and your help, but I want test it with my electronic circuit.

Really seem that a pinball ROM, store a lot of interesting secrets, some hard to discover. I have do something in assembler for PIC16 and PIC12 microcontrollers, but a lot of time ago, and its really a very hard language, mainly for programmers that have work always with high level languages like C, Basic, Cobol, Pascal, RPG, etc...

I have read that current Stern, may play 12 brightness levels, so understand that will must store 4 frames by picture, and send it really very fast, for visual effect of 12 brightness levels. At any rate its a system very old, when there where not TFT and LCD panels, do not know why Stern keep yet the old DMD, when with a TFT may play full color and higher resolution videoanimations, without need to use that system to send several frames by picture to simulate brightness levels.



Thanks.
Find all posts by this user
Quote this message in a reply
07-05-2011, 05:32 PM
Post: #13
RE: WPCEdit 2.0
I have been looking at a disassembly the IJ ROM which serves as a basis for most of the other things I've discovered across all WPC ROMs. As far as DMD updates, I've only got to the functions that write the DMD image into memory on the main CPU board. I haven't disassembled the portion of code that clocks the image from CPU board memory to the DMD interface board, but I suspect this would be interesting for you. Of course the DMD interface board does a conversion that you're talking about which is probably even more interesting to you. I bet you can find a lot of good info in the pinmame source code.

It sounds like you're working at the same level of the color dmd that was mentioned on rec.games.pinball. If you haven't seen this, you may want to look up the post made a few weeks ago regarding color dmd.

Best of luck on your project.
Find all posts by this user
Quote this message in a reply
07-05-2011, 08:42 PM (This post was last modified: 07-05-2011 08:50 PM by planeta9999.)
Post: #14
RE: WPCEdit 2.0
(07-05-2011 05:32 PM)mrglee Wrote:  It sounds like you're working at the same level of the color dmd that was mentioned on rec.games.pinball. If you haven't seen this, you may want to look up the post made a few weeks ago regarding color dmd.

Best of luck on your project.


I saw it recently, though mine currently do not support multicolor, but will add it too, though its really hard because of need HACK ROMS (that is because of need information about how store frames in ROM, ;=) and also need extract frames to new files to colorize it, then store in my new circuit probably in a Micro SDHC card.

My current design work with TFT panel 13 inches 25:8 aspect ratio (similar to DMD) with options to select color of pixel and shape of pixel (square or round). But do not support multicolor animation, because of it need new maps of frames and colorize each one, pixel by pixel, really a VERY HARD task. If CV has close to 1800 frames, and two frames is one full picture, must colorize only for this pinball, 900 pictures all pixels, one by one. Really will need a good software to do it as fast as possible. Im good doing software, I worked for 18 years in several companies, but need to know what store the ROMS to hack it, its a big secret, now not so big secret thanks to your very good information.


My current DMD-TFT PCB board in this picture. Firmware updatable by USB:

[Image: dmdtft.jpg]
Find all posts by this user
Quote this message in a reply
07-06-2011, 05:39 PM
Post: #15
RE: WPCEdit 2.0
That's so very cool. This sounds like a fun and complicated project. Let me know if I can help any further with regard to Wpc software. I understand you would like to have export in WpcEdit but I don't think I'll get to that in the near future however if you really want to see something like a diaglog box pop up at each graphic showing the hex bytes, I could whip something like that up pretty quickly. Just let me know exactly what you want.

Looks like a microsope will also be handy. I acquired one from Ebay awhile back which makes it very helpful to solder those small pins.

I also like the idea of selecting color and pixel shape. I agree that making it full color is a lot of custom work per each individual game. I think a drop-in replacement monochrome LCD is a great idea. It would be even better if/when wpcEdit allows for modification of the images and even better if/when we can connect a dongle to the WPC CPU board to allow easy upgrades of the firmware via flash instead of EPROM. Even better is a wifi dongle to allow upgrades to the pin via wireless ethernet... lots of possibilities.
Find all posts by this user
Quote this message in a reply
07-07-2011, 09:50 AM (This post was last modified: 07-07-2011 11:02 AM by planeta9999.)
Post: #16
RE: WPCEdit 2.0
(07-06-2011 05:39 PM)mrglee Wrote:  That's so very cool. This sounds like a fun and complicated project. Let me know if I can help any further with regard to Wpc software. I understand you would like to have export in WpcEdit but I don't think I'll get to that in the near future however if you really want to see something like a diaglog box pop up at each graphic showing the hex bytes, I could whip something like that up pretty quickly. Just let me know exactly what you want.

Well, I will need export externally each full picture (mix of two frames). Probably will use some simple compress system, like store Color + number of continuous pixels. To each brightness level will apply a code, that later with colorize it, will replace by color code (256 possible colors). But only are good mix of frames 1+2, 3+4, 5+6, 7+8, etc..., those are full real pictures. Can not mix frames 2+3, 4+5, 6+7, etc... those are not good.

If you may add some option in your software that show WHERE start bytes of each frame (now only show index), and if may show those bytes will be also very useful.


Quote:Looks like a microsope will also be handy. I acquired one from Ebay awhile back which makes it very helpful to solder those small pins.

I dot not solder it by hand, may be very hard for so little pins, I have an Infrarred IC Heater.

[Image: Infrared_IC_Heater_T962_Infrared_reflow_oven_T_962.jpg]



Quote:I also like the idea of selecting color and pixel shape.

Now may select color, with 15 colors available, next update user will may enter RGB value to may select more than 260.000 colors. About shape, also some custom pixel to draw it in a 12x15 grid, with some shadow effect.

Quote: I agree that making it full color is a lot of custom work per each individual game. I think a drop-in replacement monochrome LCD is a great idea. It would be even better if/when wpcEdit allows for modification of the images and even better if/when we can connect a dongle to the WPC CPU board to allow easy upgrades of the firmware via flash instead of EPROM. Even better is a wifi dongle to allow upgrades to the pin via wireless ethernet... lots of possibilities.

Yes, many options to add, but currently hardware is not a problem, I have do it already, even version to work with multicolor, only added a slot for an SDHC card, where will store colorized maps.

The really hard task, is develop software to extract original frames to new file, option to colorize it graphically, option to hack original ROMS (each original frame must add a code to identify it when my board receive it, so will know which colorized frame must apply).... About how colorize frames, I have many ideas, the more simple is select color with mouse from a pallete of 256, then apply mouse to pixel and push left button to change color. But also may add some automatic options, where you select with mouse a rectangular area of picture, then select 3 colors and software replace automatically brightness levels by colors (only in the rectangular area), of course always will need amend pixel colors manually.

This is a picture of my new pcb design, with multicolor support, add a SD card Slot. No yet board available but CAD design, I hope receive it soon from manufacturer to start tests.

[Image: dmdtftcolor.png]
Find all posts by this user
Quote this message in a reply
07-08-2011, 08:37 PM
Post: #17
RE: WPCEdit 2.0
Looks like you have a lot of good resources and tools. Are you talking about changing how the WPC code clocks the DMD data out from the CPU board? You want it to be able to clock out color encoded data? Sounds do-able but will take a lot of time. Also in some ROMs there's hardly any unused space so might have to double the size of the ROM (ie from a 4 megabit to 8megabit) when possible which would open a lot of new room for additional image data.

The current WPC full-frame graphics have about a dozen compression algorithms. I suspect a multi-color algorithm could be designed that uses similar techniques. It would reduce the footprint in ROM if we can pick among a dozen different algorithms.

Some of the images also contain XORing of pixels which they use to quickly inverse the image. Also some images contain skip-pixels which they use to not draw any color so whatever was on display prior to the display will remain.
Find all posts by this user
Quote this message in a reply
07-09-2011, 05:14 AM (This post was last modified: 07-09-2011 05:22 AM by planeta9999.)
Post: #18
RE: WPCEdit 2.0
(07-08-2011 08:37 PM)mrglee Wrote:  Looks like you have a lot of good resources and tools. Are you talking about changing how the WPC code clocks the DMD data out from the CPU board? You want it to be able to clock out color encoded data? Sounds do-able but will take a lot of time. Also in some ROMs there's hardly any unused space so might have to double the size of the ROM (ie from a 4 megabit to 8megabit) when possible which would open a lot of new room for additional image data.

I have think a lot about it, its really the KEY of this project.

I never have think about include color data inside the ROM, because of do not know if possible, do not know if space available and even how include it in each original frame.

In the begining I thought about calculate some checksum by picture, to identify it when my board receive it from pinball, then replace original frame by my colorized frame stored in external SD memory card (this is in my board). But because of some animations show variable data (scores, pinball in game), I think that not possible calculate a Checksum by picture/frame. This Checksum option is not discarded, because of may be that variable data are not MIXED with animations in video controller board, so I want capture frames that send pinball to DMD to analize it.

Second option I thought is ADD a code to each original frame in the ROM, only modify the first 12 bits of each frame, with 12 bits may store number from 0 to 4096, enough to identify all frames. This will need modify ROM, identify where start each frame and then modify the first 12 bits to add one sequential and different code to each frame. So, when my board receive each original frame, will know that in the first 12 bits, a code identify it, then only will need read colorized frame stored in SD card, and replace original frame by new colorized frame.

Quote:The current WPC full-frame graphics have about a dozen compression algorithms. I suspect a multi-color algorithm could be designed that uses similar techniques. It would reduce the footprint in ROM if we can pick among a dozen different algorithms.

That sound good, but do not know if really will be very hard with so many compress systems. I think that option of replace only the first 12 bits to include an identification code unique by frame, may be the easy system.


Quote:Some of the images also contain XORing of pixels which they use to quickly inverse the image. Also some images contain skip-pixels which they use to not draw any color so whatever was on display prior to the display will remain.

Do you know how mix animations with variable data like scores when need show it ???

If variable data are not mixed in same frame with videoanimations, then may be possible calculate a Checksum by frame, and do not modify ROM.
Find all posts by this user
Quote this message in a reply
07-12-2011, 09:46 PM
Post: #19
RE: WPCEdit 2.0
From my understanding of looking at the WPC source code, it forms all of the graphics into an area of the CPU board RAM and then clocks it out to the DMD driver board. So the DMD driver board only cares about full frame images. It is the CPU board that handles all of the tricks of overlaying images, skipping pixels, and XORing pixel data.

I was just playing some IJ tonight and observing the DMD. If I understand what you're asking, it sounds like you'd want to be able to assign a unique number to each image on the entire DMD frame so you could display a colorized version of the image. But it appears there's just too many combinations of images to do this, especially when you consider that there's a lot of images that include the players score as well as modes with running timers showing on the display. Not to mention things like random animations that display here and there. For example, I seem to recall that Star Trek the Next Generation has a constant display of stars displaying behind the player score.

So maybe it is best to start with a monochrome display, and then thing about colorizing only the fixed full-frame images that don't include display of any variable data such as player score or countdown timers. This may not be acceptable for all pins but it would be a start. For example in IJ I noticed what seemed like quite a few combinations of variable data and animation. It might not be easy to watch a pin that switches between monochrome and color display all the time.

Another option is to make your code smart enough to identify each bitmap, whether it is a full frame image, animation cell, or a single font character, and have a colorized version for each item. This could get tricky and would need to be very fast, for example, it knows what the letter "A" looks like for a font. Your code could quickly scan the entire DMD image for anything that looks like "A" and replace it with colorized version. This would need to happen for all possible letters for all possible fonts, and aross the entire DMD image for a single frame.
Find all posts by this user
Quote this message in a reply
07-13-2011, 05:05 AM (This post was last modified: 07-13-2011 05:19 AM by planeta9999.)
Post: #20
RE: WPCEdit 2.0
Well, variable data is not a problem, I now only want identify videoanimation frames to replace it by colorized frames.

What happen when a frame in DMD mix videonimation with variable data (scores, ball in game, timers, etc... ) ???
Important is that my board identify each frame, then suppose we have modify ROM, and in the frame add a code (first 12 bits of frame), that identify that frame. Obviously, CPU has mix that frame with some variable data, and sent it to video controller board that send to DMD. No problem, really my idea is MIX original frame with my colorized frame. I mean that ONLY replace pixels colorized, but KEEP rest of pixesl of original image (scores, timers, balll in game, graphics stored like font...).

Must to do many tests, but I think its possible, but only if may modify ROM to add a unique identification code to each frame, those frames that show your current software. Obviously some graphics that are stored like fonts, will keep in black and white, but the big videoanimation will be colorized.

But even for fonts and graphics stored like fonts, may apply some simple translation in real time, brightness levels to colors. Obviouslyl that mean that fonts only will show 4 colors, but when mix all, videonimation frames and variable data, the final result may be very good. Check, for example the video about Color DMD, I think that scores always show 1 or 2 colors max, also all variable data, may be because of apply to it a simple translation brightness levels to colors (3-4 colors).

At any rate, I must to do yet some tests, capturing frames that store the videocontroller. Im not sure yet if CPU has mix all in one frame (videoanimation + variable data), or really video controller board store one full frame only with videoanimation frame, and next frame with variable data. Must think that video controller board store 16 full frames, that send very fast to DMD, to generate brightness levels, may be also that mix graphic frame (frame that show your software) with next frame that show variable data.


I have already my new board, to work with multicolor, this add one MicroSD slot to put a card that will store colorized frames.

[Image: dmdtftcolor.jpg]
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


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