color dmd

[XNIF]

I can image that everyone that want to use the color dmd should dump the animations from the rom and edit them with the colors you prefer. There is no way that all those animations are more than one color originally. like you can do with Visual pinball with the core.c funtion:

void video_update_core_dmd(struct mame_bitmap *bitmap, const struct rectangle *cliprect, tDMDDot dotCol, const struct core_dispLayout *layout)

And then dump them to the rom again and flash em. That is my guess. I think selling custom roms could be copyright infringement...?
I do not see how else you would overrule the standard roms for your DMD.

 

[kencinder]

I can image that everyone that want to use the color dmd should dump the animations from the rom and edit them with the colors you prefer. There is no way that all those animations are more than one color originally. like you can do with Visual pinball with the core.c funtion:

void video_update_core_dmd(struct mame_bitmap *bitmap, const struct rectangle *cliprect, tDMDDot dotCol, const struct core_dispLayout *layout)

And then dump them to the rom again and flash em. That is my guess. I think selling custom roms could be copyright infringement...?
I do not see how else you would overrule the standard roms for your DMD.

Where is this color bit stored? It doesn't exist...there IS no color to the animations. Monochrome orange DMD...everything is orange. A blue DMD? Same deal...there are only intensity(brightness) levels.

Why does everyone keep assuming that this will need reprogrammed ROMs or even have any interaction with the MPU at all? Doing things that way would be needlessly difficult, overly complex to support more than one MPU design and just doesn't make any real sense.

Simply sitting on the bus where the original DMD would be, and sniffing/intercepting and displaying it's own soft version of what the DMD would is much easier than re-programming roms. Not to mention re-writing assembly? WAY faster for whoever is doing the work, to simply write things in a high level language, for the software they use.
How do you fit all that color data into the existing size memory map if you replace a ROM? You'd have to reference a color for each bit...it isn't huge data, but where do you fit it when the memory allocation on the original hardware only allows for X and it's already maxxed or near it? I've seen mention of a few games by people on here, where the game ROM(s) are absolutely crammed full...where does that extra data go? Even if say, it's only 8kb...

It just makes no sense for them to go tinkering with the existing ROMs, from either a monetary standpoint or a development time standpoint.
Hell I could be wrong...but doing things where you're replacing ROMs etc, makes no freaking sense to me, so if they went the hard road...it would be awfully strange.

 

[Lindsey]

I can image that everyone that want to use the color dmd should dump the animations from the rom and edit them with the colors you prefer. There is no way that all those animations are more than one color originally. like you can do with Visual pinball with the core.c funtion:

void video_update_core_dmd(struct mame_bitmap *bitmap, const struct rectangle *cliprect, tDMDDot dotCol, const struct core_dispLayout *layout)

I think Williams had 3 shades of orange per pixel on their DMD. I know that Stern has even more shades of orange than that (12-14 I think?). You're right about the individual frames though. It would be easy enough to write a program to grab the frame data from the ROMs, allow you to add your colors and dump a file that's compatible with the color "DMD" driver. The problem would come when the animation is not being generated by static frames being dumped to a frame buffer. There will quite likely be cases where animations are not static frames. That problem is a little tougher to solve.

I think selling custom roms could be copyright infringement...?

If there's original content then there's definitely a case. You might be right that the only way they can pull it off is to have the user create the new ROM.

I do not see how else you would overrule the standard roms for your DMD.

You could write a totally new ROM to run on the new display in an old game but that makes the programming even harder because now you have to be creative

 

[Lindsey]

No one is talking about re-programming original ROMs to run on original hardware. We're talking about using original ROMs to generate the frames for the new ROM which will be used by the driver for the new display. The new display should accept the same signals as the original display and just display different frames. Ultimately it's not that simple but that's the basic concept of how it could work.

Where is this color bit stored? It doesn't exist...there IS no color to the animations. Monochrome orange DMD...everything is orange. A blue DMD? Same deal...there are only intensity(brightness) levels.

Like I said above there are several shades of orange making for more than one color per pixel. They just all happen to be shades of orange.

Why does everyone keep assuming that this will need reprogrammed ROMs or even have any interaction with the MPU at all? Doing things that way would be needlessly difficult, overly complex to support more than one MPU design and just doesn't make any real sense.

Because you need to know what frame the MPU is trying to put on the DMD so you will know what color to swap in for the original color. You wouldn't be programming new ROMs to go in any original sockets. You would be programming the ROM to run on the color DMD driver. So basically when the original display would have displayed data from original ROM location XYZ you sub in your new modified XYZ.

Simply sitting on the bus where the original DMD would be, and sniffing/intercepting and displaying it's own soft version of what the DMD would is much easier than re-programming roms.

That's how I would build it. Basically. But you still need to create a new ROM for the new display driver based on the old one.

Not to mention re-writing assembly? WAY faster for whoever is doing the work, to simply write things in a high level language, for the software they use.

How do you fit all that color data into the existing size memory map if you replace a ROM? You'd have to reference a color for each bit...it isn't huge data, but where do you fit it when the memory allocation on the original hardware only allows for X and it's already maxxed or near it? I've seen mention of a few games by people on here, where the game ROM(s) are absolutely crammed full...where does that extra data go? Even if say, it's only 8kb...

It just makes no sense for them to go tinkering with the existing ROMs, from either a monetary standpoint or a development time standpoint.
Hell I could be wrong...but doing things where you're replacing ROMs etc, makes no freaking sense to me, so if they went the hard road...it would be awfully strange.

You're just misunderstanding. No one is suggesting re-programming and compiling a new display ROM to be compatible with the old hardware and run in the original location to drive the new display. That's not possible.

 

[Lindsey]

I'm pretty sure that the display is an LCD. Watch the video in HD on Youtube:
http://www.youtube.com/watch?v=DNFQ5waHHzQ

Especially towards the end you'll see that there aren't individual pixels, there are entire blocks of color. It is especially evident on the score numbers.

That definitely makes it more flexible. Cool project all around.

 

[kencinder]

Some on here have, and I misread XNIF's post...that's actually a copy/paste from a post elsewhere of mine, I should have stated so/used quote, and that other portion wasn't directed at XNIF at all.