Direct color DMA bitmap viewer

[ComradeOj]

I put this program together because I wanted to play around with the direct color DMA trick. I'm sure a lot of you have seen the trick before. My program is a bit different, because it allows you to use unaltered .BMP files. This makes it really easy to display your own image with the color DMA trick.

I initially wanted to write the code for the direct color DMA trick completely from scratch. I actually got pretty close, but the image would jitter left and right. I ended up just basing it off of chilly willy's direct color DMA implementation.

What's kind of cool is that all of the image conversion is done by the Genesis. Regular unaltered bitmap files go in, and the Genesis converts them into a format that can be used for direct color DMA. One big drawback of this is memory limitations. The Genesis only has 64KB of memory, but the images are ~88KB. Because of this, the whole image won't fit and only 2/3rds of the image is displayed. :/ I tried to put half of the image into SRAM backup, and half into 68k RAM. It didn't work though. For some reason, I can't get SRAM writing working correctly on my everdrive. Only the oddly numbered bytes get written. I'm not sure why. I couldn't get it to DMA from SRAM anyway. I might also be able to store the image in the SEGA CD's RAM. This wouldn't be an issue if I pre-converted the images, since I could just store/DMA them from ROM space. Since the Genesis is doing the conversion, the only option is to store it in RAM.

I'll keep playing around with it and see if I can figure something out.

How to:

1. Download the program
2. Select your desired image. There are some sample images in the img folder to use.
3. Change its resolution to 198x224
4. Save it as a 16 bit .BMP file. 256 color and 24 bit won't work.
5. Save it as "img.bmp" in the program's "image" folder.
6. Run the "make.bat" file
7. If all goes well, it should make a new ROM image with your picture ready to display!

You can not run this program in most emulators. The only emulator I got it to work in is Exodus. Other than that, it runs fine on real hardware.

You can download the program here.

Here is a screenshot. It was captured from my Genesis model 2 via s-video.

[Barone]

[matteus]

Unfortunately I can't give you any more rep!

[LinkueiBR]

Unfortunately I can't give you any more rep!

[Mask of Destiny]

Nice work! It would be kind of neat to have something like this as a Sega CD release or a menu ROM for a flash cart so you could select a file from the CD/SD card to display.

Only the oddly numbered bytes get written. I'm not sure why.

On most commercial Genesis carts as well as most flash carts, save RAM is only byte-wide whereas the 68K's bus is word-wide. I think the Mega Everdrive and perhaps one or two others support word-wide save RAM, but that's about it.

You can not run this program in most emulators. The only emulator I got it to work in is Exodus. Other than that, it runs fine on real hardware.

For what it's worth, it also works in BlastEm (current repo tip has an attempt at 68K refresh delay emulation which seems to have broken this, but 0.3.1 is fine).

[ComradeOj]

Nice work! It would be kind of neat to have something like this as a Sega CD release or a menu ROM for a flash cart so you could select a file from the CD/SD card to display.

That might be cool. Make it so you can load up a whole bunch of images, and view them. I don't know a lot about accessing data from CD-ROM, but I'll keep this in mind.

On most commercial Genesis carts as well as most flash carts, save RAM is only byte-wide whereas the 68K's bus is word-wide. I think the Mega Everdrive and perhaps one or two others support word-wide save RAM, but that's about it.

Yep, I have the Everdrive MD that doesn't support word wide SRAM.
I've tried writing to it both as single words, or one byte at a time. In each case there's a loop that does something along the lines of:

write_SRAM:
     lea (sram_start),a5
     lea (somedata),a0
     move.w #$0FFF,d4
sram_loop:
     move.b (a0)+,(a5)+ 
     dbf d4, sram_loop
     rts

Yet, when I copy the file off of my everdrive, only the oddly numbered bytes are written. This is a screenshot of one of those files. I'm assuming that I'm supposed to write it with move.b and not .w. Maybe I should start the SRAM location with an oddly numbered address? There must be something I'm missing. I probably woudn't be DMA-ing anything from it anyway if the bus is only 8-bits.

For what it's worth, it also works in BlastEm (current repo tip has an attempt at 68K refresh delay emulation which seems to have broken this, but 0.3.1 is fine).

I forgot about that one! I still have an older version of it on my laptop, I'll have to try it out later.

[Mask of Destiny]

I've tried writing to it both as single words, or one byte at a time. In each case there's a loop that does something along the lines of:

write_SRAM:
     lea (sram_start),a5
     lea (somedata),a0
     move.w #$0FFF,d4
sram_loop:
     move.b (a0)+,(a5)+ 
     dbf d4, sram_loop
     rts

Yet, when I copy the file off of my everdrive, only the oddly numbered bytes are written.

The 68K doesn't have an external address line for the least significant address bit. Effectively it's always selecting a word of memory. 8-bit reads just read either the high or low byte off the bus depending on the value of the least significant bit. Similarly byte writes write to either the low or high byte of the word-wide bus. As a result byte-wide devices are available either on just odd addresses or just even addresses. So what you want instead is something like:

write_SRAM:
     lea (sram_start),a5
     lea (somedata),a0
     move.w #$0FFF,d4
sram_loop:
     move.b (a0)+,(a5)
     addq #2, a5 
     dbf d4, sram_loop
     rts

[EPSYLON EAGLE]

Nice! There is a possibility however remote of in game applications?

[Barone]

Nice! There is a possibility however remote of in game applications?

So, uh, this "new" mode means that, with a Sega CD attached, the Genesis is actually capable of 512 on screen colors (with the resolution restrictions, of course)?

You can use it with just a plain Genesis, too, it's just that the mode limits the free cpu time for the game since DMA halts the MD cpu. You also don't have much ram in the Genesis, so you'd have to keep the screen size small, like the main display area in Zero Tolerance.

As an example, the screen size in the demo is 128x128, which consumes 161*128*2 bytes of ram. That's roughly 40KB of ram for the bitmap. You only have 64KB of ram in the Genesis for everything, so the bitmap (which isn't double buffered) would take much of the ram. It would also halt the 68000 for 128 lines of the display, or over half the frame.

So using this mode with the SCD alliviates the worst problems - the word ram gives plenty of ram for the bitmap, the word ram is double buffered, and the SCD 68000 isn't halted by the mode... not the mention the SCD 68000 is almost twice as fast as the Genesis 68000. So this mode is more useful for SCD games, but COULD be used with Genesis games with the right design.

Thanks for the explanation, Chilly.
This is a good use for the Sega CD's hardware IMO.

With the Sega CD's extra RAM (I saw your lines about the Genesis side of things but I'm not sure what to conclude about the screen size using the Sega CD), how big the screen can get?

Given V28 mode as opposed to V30 (which is PAL only), you can do 160x224 in H40 mode and 128x224 in H32 mode. The width is wider in both modes, but all other pixels on the line are in the overscan region and not visible. However, by making your bitmap wider and/or taller, you can implement scrolling by changing the start address of the DMA. If you use the CD word ram in 1M mode (which gives two banks of 128KB of ram), you can go up to 198x330 in H40 mode, or 161x407 in H32 mode. Remember that only 160x224/128x224 will be visible, but you could scroll around in the larger bitmap area.

It can be full screen, for NTSC at least (not sure what the line limit is for the PAL display). You could do 160x224 or 128x224 and fill the same space as typical MD games, just with pixels being 2x as wide as normal.




Plus it's a pretty basic conversion down to 9-bit RGB vs Wolf3D's own 18-bit 256 color palette. Games specifically optimized around the advantages and limitations of 9-bit RGB's 512 colors. Actually, since it's organized with R G and B elements aligned at 4-bit boundaries, that should also make direct color alpha blending a possibility as well. (still needing bit manipulation or look-up tables, but at least a lot easier/faster to do in software than 15-bit RGB or such)
Plus, you might be able to employ the "unused" nybble for added pixel information as well.

Overall though, there's still probably many situations where the approximated 12-bit colors using dithered full-res tile graphics as a pseudo-bitmap would be more useful too, especially cases where blended paired pixels to create a pseudo 8bpp paletted pseudo 12-bit color display would be preferable. (up to 136 colors per tile by blending 16 colors -or less if using 15 colors+transparent) Using h-scroll to blur things (for effective 30/25 Hz output) would make that more solid than composite video blur and work for both PAL and NTSC equally and in RGB or S-video.
This sort of rendering would be about as fast as software rendering DMA color pixels for cases where you'd render 1 pixel at a time mostly, and potentially much faster for cases where you'd handle more than 1 pixel. (pseudo pixels being 8-bits wide, so 16-bit accesses could move things 2x as fast as dealing with 16-bit pixels)
--This sort of pseudo colorspace rendering was also underutilized, and it's a shame the Sega CD ASIC can't render 8bpp for doing dithering like that. (dithered textures artifact horrible when scaled, so that's not a good option either)

Well, I suppose there'd still be some cases where DMA color mode could actually be faster than moving 8-bit data around (pixel pairs) on actual tiles, mostly relating to max framerates (where rendering speed is not a bottleneck) and possible overhead from rendering pixels in cell order rather than linear bitmap order. (I don't think you'd want to use the ASIC's bitmap to tile conversion mode since that won't allow 1M bank word RAM and will also require rendering unpacked 16 color pixels -ASIC converts 8-bit pixels to 4-bit- rather than actually directly rendering 4-bit pixels as byte aligned pairs)

One other advantage of DMA color mode would be the potential to do that sort of flickering on a full-screen basis without the issues of VRAM size and DMA bandwidth seen with actual tiles, though you'd either have to keep flipping word RAM each frame or you'd have to settle for not quite full screen to fit 2 frames in 128k (like 160x200). In this case, you'd get pseudo 12-bit direct color instead of 9-bit and 4,096 colors on screen at 30 Hz (or 25 Hz).
However, this would take 2x the rendering bandwidth, so only really attractive in cases where that's not already a bottleneck. (or where reducing screen size or rendering speed to allow for it is preferable to using 9-bit color -or pseudo paletted 12-bit color via normal dithered/blended tiles)

[EPSYLON EAGLE]

You must spread some Reputation around before giving it to Barone again.

[ComradeOj]

The 68K doesn't have an external address line for the least significant address bit. Effectively it's always selecting a word of memory. 8-bit reads just read either the high or low byte off the bus depending on the value of the least significant bit. Similarly byte writes write to either the low or high byte of the word-wide bus. As a result byte-wide devices are available either on just odd addresses or just even addresses. So what you want instead is something like:

write_SRAM:
     lea (sram_start),a5
     lea (somedata),a0
     move.w #$0FFF,d4
sram_loop:
     move.b (a0)+,(a5)
     addq #2, a5 
     dbf d4, sram_loop
     rts

Thanks for that! I guess that means half of SRAM is effectively useless, since it can't be addressed? I'll have to finish my gravity pig level editor that I stopped working on because I couldn't figure out SRAM saving.

An update on the the DMA BMP viewer:

I've been trying to use SEGA CD's word RAM to store the images, since it's large enough. I was able to store an image and DMA from it, but for some reason the blue channel is totally missing. I'm not sure why.
I know that blue is on one byte of a word and the red/green is on the other byte. Either the byte with blue isn't being written correctly, or not being read correctly.

Maybe SEGA CD word ram has that same quirk as SRAM saves? After all, the blue channel goes on the even bytes, which are apparently unavailable with external SRAM.

I currently have nice fullscreen images, but no blue!

[Mask of Destiny]

Thanks for that! I guess that means half of SRAM is effectively useless, since it can't be addressed?

Half the address space consumed by an 8-bit SRAM will be wasted, but the full SRAM is addressable. A 32Kx8 SRAM will consume 64KB of address space.

aybe SEGA CD word ram has that same quirk as SRAM saves? After all, the blue channel goes on the even bytes, which are apparently unavailable with external SRAM.

Word RAM is definitely 16-bits wide (you wouldn't be able to run code from it otherwise). I do remember a weird issue with doing DMA from word RAM, but I don't think I've ever tried a DMA to CRAM from there. Looking at the source of Genesis Plus GX (Eke Eke leaves lots of helpful comments about how the hardware works), it seems that the first word read from the bus ends up being garbage. That shouldn't result in the symptoms you're seeing though. It should just shift the image by one pixel. Maybe the behavior is different when the target is word wide?

[Pyron]

excelent work comrade!!!!

sadly the system dont let me give you more recommends, but anyway thank you and keep going!

[Tower of Power]

This direct color DMA hack fascinates me, great work! Just imagine if someone had discovered it early on in the Genesis' lifespan!

[tryphon]

Honestly there are too much constraints for it to be really usable in games.

What saddens me more is the unused 128 Kb VRAM mode...