Direct Color Demo using DMA

[Chilly Willy]

Okay, why the effin hell isn't this being used by SCD games?

Recently, a demo was uploaded that used DMA to the CRAM background color entry to do a direct color display (9 bit RGB). It's hard as hell to see if the mode is useful from the demo - the image used sucks donkey dongs. It's also just a small asm program.

The code was posted, so I looked it over to see how it worked... this is my demo based on it. I inserted the code into my "standard" framework and used a GOOD image, something you'll probably recognize.

http://www.mediafire.com/?gvg7m4b1rlp5w9l

The way this works is you disable ints, turn on the display and wait for the vblank. You then write some data to vram to synchronize to a specific spot on the display. Then you setup dma from memory to cram with the increment set to 0 so that it always stores to the same cram entry. You then turn off the display and start the dma. This halts the cpu until the dma is done.

We know from posted tables that there are 198 cycles for dma in horizontal line when the display is not active (in 40 cell mode). So the width of the direct color display is 198... but not all of that is visible. From my demo, you get an idea of what is visible. My image is a 320x200 image shrunk to 160x200, then centered in the 198x224 direct color display region. So you can see that the visible horizontal width in this mode is 160 (I need to move the image left a bit for proper centering - using the exact center of the 198 width is too far right).

Anywho, what use is this mode? The cpu is halted for most of the time. Well, it's AWESOMENESS PERSONIFIED for SCD games. Think about it - instead of a static display in rom, a frame buffer in word ram. The SCD game prepares the video, then swaps word ram buffers during the vblank (run in two 128KB word ram banks mode). The MD side does nothing but DMA whatever is in word ram to the screen just like in the demo. The CD side handles the word ram banks, drawing the frames and flipping them for the MD side. It also runs the game and plays the audio via the PCM chip. The only things the MD side needs to do is DMA the damn buffer and read the pads, which you would do immediately after the DMA finishes, and before you wait on the vblank.

It's stable and looks great. 160x200 is a great mode for games, especially when it means you can do 9-bit RGB. This is my mode for my MCD port of Wolf3D... I can get back on that now that I have a good video mode to use. I can actually use the original graphics instead of 16 color graphics.

You could also use this for FMV. Imagine nice direct color images instead of "cinepak" images... I'll have to make a demo for that as well. Time to get some SCD demos going.

[Oerg866]

Okay, so what I originally invisioned are static screens and parts. You can blank the display mid-screen, use the top portion of the screen for some kind of other thing like a scroller or something, then have a high color bitmap in the other.

As for the suckey image, well, we just wanted an image with lots of colors We somehow ended up with this one with a lousy conversion and no dithering, but 336 unique colors!

Best regards,
Eric

Okay, why the effin hell isn't this being used by SCD games?

Recently, a demo was uploaded that used DMA to the CRAM background color entry to do a direct color display (9 bit RGB). It's hard as hell to see if the mode is useful from the demo - the image used sucks donkey dongs. It's also just a small asm program.

The code was posted, so I looked it over to see how it worked... this is my demo based on it. I inserted the code into my "standard" framework and used a GOOD image, something you'll probably recognize.

http://www.mediafire.com/?gvg7m4b1rlp5w9l

The way this works is you disable ints, turn on the display and wait for the vblank. You then write some data to vram to synchronize to a specific spot on the display. Then you setup dma from memory to cram with the increment set to 0 so that it always stores to the same cram entry. You then turn off the display and start the dma. This halts the cpu until the dma is done.

We know from posted tables that there are 198 cycles for dma in horizontal line when the display is not active (in 40 cell mode). So the width of the direct color display is 198... but not all of that is visible. From my demo, you get an idea of what is visible. My image is a 320x200 image shrunk to 160x200, then centered in the 198x224 direct color display region. So you can see that the visible horizontal width in this mode is 160 (I need to move the image left a bit for proper centering - using the exact center of the 198 width is too far right).

Anywho, what use is this mode? The cpu is halted for most of the time. Well, it's AWESOMENESS PERSONIFIED for SCD games. Think about it - instead of a static display in rom, a frame buffer in word ram. The SCD game prepares the video, then swaps word ram buffers during the vblank (run in two 128KB word ram banks mode). The MD side does nothing but DMA whatever is in word ram to the screen just like in the demo. The CD side handles the word ram banks, drawing the frames and flipping them for the MD side. It also runs the game and plays the audio via the PCM chip. The only things the MD side needs to do is DMA the damn buffer and read the pads, which you would do immediately after the DMA finishes, and before you wait on the vblank.

It's stable and looks great. 160x200 is a great mode for games, especially when it means you can do 9-bit RGB. This is my mode for my MCD port of Wolf3D... I can get back on that now that I have a good video mode to use. I can actually use the original graphics instead of 16 color graphics.

You could also use this for FMV. Imagine nice direct color images instead of "cinepak" images... I'll have to make a demo for that as well. Time to get some SCD demos going.

[djcouchycouch]

Hi CW,

Tried out Direct-Color-DMA.bin. Here's what I see:



Is it as expected? I see the border goes off to the right side, there's a light coloured line up top and there's random data at the bottom. I'm running on a Genesis II with 32X attached.

DJCC

[Chilly Willy]

Hi CW,

Tried out Direct-Color-DMA.bin. Here's what I see:



Is it as expected? I see the border goes off to the right side, there's a light coloured line up top and there's random data at the bottom. I'm running on a Genesis II with 32X attached.

DJCC

Yes, that's correct. As I mentioned, the picture is too far to the right because it's EXACTLY centered in the 198x224 region when it needs to be a little more left of center. I could have centered it properly before releasing it, but wanted people to see what it looks like in the exact center.

Your color is also a little low on your TV compared to mine. See how the ceiling is almost black on your TV? Or is that the picture of the TV that makes the color low?

The noise at the top and bottom can be cleaned up as well. Again, I could have done that before releasing the demo, but wanted folks to see just what I saw on my first attempt. Oerg's demo doesn't have the noise at the top and bottom - it's just a lousy image for showing off this mode.

[djcouchycouch]

Your color is also a little low on your TV compared to mine. See how the ceiling is almost black on your TV? Or is that the picture of the TV that makes the color low?

It's a photo of a TV taken with a cellphone in a dark basement. Not exactly the best way to get accurate colors

[Chilly Willy]

Here's some more binaries showing more of how it looks:

http://www.mediafire.com/?rm2e09cb1pi0ctt

and a photo of my new wolf3d demo pic:



I didn't include any source this time because all I did was clear the palette and pad the image binary with a bunch of 0's trying to clear up the garbage at the bottom.

One thing I figured out - you have to use the left-most part of the display region. As the wolf picture shows, starting on the left puts you on the edge of the screen, and using 160 width barely fits on the screen. It's almost exactly edge-to-edge on my LCD monitor.

Second thing - as the -2/-3 binaries show, the 9-bit RGB does require you to be careful how you choose your colors and make your images. Wolf3D looks great because it's pretty simple with widely divergent colors; something like that will do best in this kind of display. The real-life images show you need good dithering and color choice to get a good looking picture. Remember that the images in the demo are all 15-bit RGB bmps shown in 9-bit RGB, losing 2 bits of color in each R/G/B... and the details that those bits hold in RL images.

The -3 image was converted to 256 colors with FS dithering, then back to RGB and then posterized to 9 bits. Not the best solution, but it clearly has more detail than the -2 image.

[Stef]

Neat ! As you said i really wonder why this had never been used for Sega CD FMV, maybe simply because no one though about it :p
The sub CPU could decompress and prepare the 192x224 9 bits (word) buffer then send it to main CPU in word ram at VBlank time.
Also we can use border to extends the vertical resolution, i don't remember exactly how many scanlines can be colored by background color but i think it's more than 224...

[Chilly Willy]

Neat ! As you said i really wonder why this had never been used for Sega CD FMV, maybe simply because no one though about it :p

Yeah, probably. I mean, I didn't think of it either and I've been playing around with simulating direct color displays! I was influenced by common 8-bit techniques... blending pixels or frames. This method is actually rather close to the COPPER Chunky Display for the original Amiga: they would write the bitmap as a custom COPPER list that stored the color directly to the background color register using COPPER commands. It's better, though, because the DMA means we use a plain bitmap as the source, and have a higher resolution due to the DMA bandwidth being higher.

The sub CPU could decompress and prepare the 192x224 9 bits (word) buffer then send it to main CPU in word ram at VBlank time.
Also we can use border to extends the vertical resolution, i don't remember exactly how many scanlines can be colored by background color but i think it's more than 224...

Exactly! Or... you can cut it off sooner and have more vblank time available in a game. In fact, you COULD use this for a game completely on the MD alone if you kept the DMA to only what you needed (and the game logic wasn't too complex). I tried the demo on my Nomad and it works AWESOMELY!

Currently, all the demos use $AD40 for the DMA length, which is just 198*224. That could easily be made longer or shorter.

[djcouchycouch]

Tried your new demos while the wife was looking on. Certainly didn't expect pictures of large breasted asian women to appear! Luckily she just laughed

The Wolf3d Image looked okay, but I was unsure if what was going on with the right side of the guy's head was correct. It's not super clear but you see there's a weird dark line at the right that stretches out his ear.



Could be totally expected. It just seemed odd when all the other parts of the image were reasonably sharp.

[Chilly Willy]

Tried your new demos while the wife was looking on. Certainly didn't expect pictures of large breasted asian women to appear! Luckily she just laughed

She was wearing a bathing suit. It's not like it was porn.

Hmm - how long has it been since someone did a porn pak for the MD?

The Wolf3d Image looked okay, but I was unsure if what was going on with the right side of the guy's head was correct. It's not super clear but you see there's a weird dark line at the right that stretches out his ear.

Yes, I noticed that too - it's a scaling artifact from when I shrunk the original from 320x200 to 160x200. It's nothing to do with the mode. In the original image, there's a dark outline around the head, and the hair gets darker on that side of his head near the ear. When scaled to 160, those two got combined into one fat line that looks like it comes out of the ear.

Could be totally expected. It just seemed odd when all the other parts of the image were reasonably sharp.

Remember we're dealing with scaled images at 160 width. That was a typical width for 8-bit computer games like the A8 and C64. When looking at something made for 160 instead of a 320 wide image scaled to 160, it'll look even better... or at least sharper.

[Oerg866]

Neat ! As you said i really wonder why this had never been used for Sega CD FMV, maybe simply because no one though about it :p
The sub CPU could decompress and prepare the 192x224 9 bits (word) buffer then send it to main CPU in word ram at VBlank time.
Also we can use border to extends the vertical resolution, i don't remember exactly how many scanlines can be colored by background color but i think it's more than 224...

It's *exactly* 224 on PAL IIRC


ALSO About the guy's distorted head etc., There is certain parts of every line that are twice as wide, as in double "pixels", which is small lag induced by refresh cycles. No writes occur, so the DMA doesn't advance, hence "double pixels" occuring. Hardware issue, not image issue.

And again, our image was not supposed to have a particular use, it was a proof of concept image that has as many colors as possible to show off that it's really ... "a lot" Not really possible with real world images like yours.

[Chilly Willy]

ALSO About the guy's distorted head etc., There is certain parts of every line that are twice as wide, as in double "pixels", which is small lag induced by refresh cycles. No writes occur, so the DMA doesn't advance, hence "double pixels" occuring. Hardware issue, not image issue.

Well, it doesn't appear to be much of a problem in practice. You barely notice when it affects static parts of the image, so you'd probably never notice on moving parts.

And again, our image was not supposed to have a particular use, it was a proof of concept image that has as many colors as possible to show off that it's really ... "a lot" Not really possible with real world images like yours.

Well, until someone makes something using it, we'll never know for sure... which is why I'm going to use it for a few things. I think any refresh defects are less objectionable than the artifacts you get in trying to blend pixels or frames to simulate what you get directly here.

[Oerg866]

ALSO About the guy's distorted head etc., There is certain parts of every line that are twice as wide, as in double "pixels", which is small lag induced by refresh cycles. No writes occur, so the DMA doesn't advance, hence "double pixels" occuring. Hardware issue, not image issue.

Well, it doesn't appear to be much of a problem in practice. You barely notice when it affects static parts of the image, so you'd probably never notice on moving parts.

And again, our image was not supposed to have a particular use, it was a proof of concept image that has as many colors as possible to show off that it's really ... "a lot" Not really possible with real world images like yours.

Well, until someone makes something using it, we'll never know for sure... which is why I'm going to use it for a few things. I think any refresh defects are less objectionable than the artifacts you get in trying to blend pixels or frames to simulate what you get directly here.

Heh! Well, don't get me wrong, I really love this method, which is why I implemented it in the first place, but I also have something in the works, see the first post I made in this thread =P

Best regards
Eric

[Chilly Willy]

Heh! Well, don't get me wrong, I really love this method, which is why I implemented it in the first place, but I also have something in the works, see the first post I made in this thread =P

Best regards
Eric

A scroller? Be interesting to see...

In the meantime, I did another demo. This one has seven Atari 8-bit game screens. Press A/B/C to move to the next image. This would give a better idea of how a game in 160x200 would look in this mode, just with more graphics and colors. Note that in the PacMan screen, you can see the refresh delay the easiest. Most of the rest are much harder to notice. The text at the top of PacMan looks funny, but remember the text is done in 320 mode, not 160 mode.

One thing to remember when DMAing from memory from different places - there's that pesky 128KB block issue with the DMA. That meant I had to put every image in a different 128KB block in rom to avoid problems displaying them.

I think this is the last demo of this sort I'll do unless someone has a request. I think I've shown what this mode can do over a big enough range of material to give folks an idea of the pros and cons. I feel confident this can be a useful mode to many MD programmers.

http://www.mediafire.com/?4k63ahq4l5u744p

[TmEE co.(TM)]

If you can hide sync line or push it into blanking, you can show some 240 (60Hz) or 288 (50Hz) images, in full screen, with no borders !