My first demo: a 64 color image

Mask of Destiny · Post by **Mask of Destiny** » Wed Jan 02, 2008 7:52 pm

It's an interesting idea, but you wouldn't be able to turn off the display during HBLANK that way so you'll have some artifacting. If you're not going to turn off the display you should be able to get away with just using HINT to start the DMA operation.

LocalH · Post by **LocalH** » Wed Jan 02, 2008 10:06 pm

Mask of Destiny wrote:Biggest problem is that in order to avoid artifacts you need to turn the display off during HBLANK and the only way to do that and still have enough time to DMA 8 colors is to poll the status register for HBLANK. HINTs occur too late. So you basically end up burning 100% of your CPU time on the color changes outside of HBLANK. With some clever coding I suppose you could probably break up other processing in to chunks that would fit in the active display period, but it would be somewhat awkard to do.

Said artifacts would display at the point where you actually write to CRAM, correct? Which I would think would be in the horizontal border (I wouldn't guess it'd matter one the actual blanking began since the electron beam is not drawing at that point). Every analog TV I've ever used a Genesis on showed, at most, a tiny sliver of the horizontal border on the left of the active display, so unless said artifact somehow bleed over into the active display, I wouldn't guess it would be noticeable (and since said artifacts don't even appear on emulators it wouldn't matter there either).

At least you could use some of the mid-line cycles to preload the registers with the commands and data necessary to trigger the DMA, which would save a few cycles as compared to using constants in the ROM code (since the 68k doesn't have to fetch them). As far as I know, the only data that would actually change on each line would be the DMA source and destination values (destination would alternate between two different values depending on which half you were updating, while source would more or less increment by 16 bytes each scanline). Since both of those are contained in the same set of command words, you could even go one step further and set up a table with precalculated command words that you would merely need to step through on each line.

Mask of Destiny · Post by **Mask of Destiny** » Thu Jan 03, 2008 2:14 pm

LocalH wrote:
Mask of Destiny wrote:Biggest problem is that in order to avoid artifacts you need to turn the display off during HBLANK and the only way to do that and still have enough time to DMA 8 colors is to poll the status register for HBLANK. HINTs occur too late. So you basically end up burning 100% of your CPU time on the color changes outside of HBLANK. With some clever coding I suppose you could probably break up other processing in to chunks that would fit in the active display period, but it would be somewhat awkard to do.
Said artifacts would display at the point where you actually write to CRAM, correct? Which I would think would be in the horizontal border (I wouldn't guess it'd matter one the actual blanking began since the electron beam is not drawing at that point). Every analog TV I've ever used a Genesis on showed, at most, a tiny sliver of the horizontal border on the left of the active display, so unless said artifact somehow bleed over into the active display, I wouldn't guess it would be noticeable (and since said artifacts don't even appear on emulators it wouldn't matter there either).

They actually show up about 1/4 of the way across the visible portion of the video signal. No idea what causes them, but turning off the display while you're doing the CRAM update fixes it. I didn't discover this glitch or the workaround, but I have seen it in action. The artifacting isn't severe, but it's fairly noticeable.

LocalH · Post by **LocalH** » Thu Jan 03, 2008 3:36 pm

I would assume that's the same garbage that appears when you hit VRAM period, as seen in the bottom border in the Sonic games? It's odd that it doesn't appear while you're actually hitting VRAM, since it would make sense that writing to VRAM would cause the VDP to read the values currently being written as opposed to actually reading the RAM.

Brunni · Post by **Brunni** » Sat Jan 05, 2008 2:03 am

Mask of Destiny wrote:Biggest problem is that in order to avoid artifacts you need to turn the display off during HBLANK and the only way to do that and still have enough time to DMA 8 colors is to poll the status register for HBLANK. HINTs occur too late. So you basically end up burning 100% of your CPU time on the color changes outside of HBLANK. With some clever coding I suppose you could probably break up other processing in to chunks that would fit in the active display period, but it would be somewhat awkard to do.

Too bad... I suppose that's why gradient effects like on SNES were never used on the Genesis. I had thought that it was because you don't have enough with 512 colors to create a smooth gradient.

LocalH · Post by **LocalH** » Sat Jan 05, 2008 2:37 am

Changing the backdrop over various scanlines is still doable though - the catch is, you have to have your pallet entries preloaded. Writing to VDP register $07 causes no such artifacts to appear.

Eke · Post by **Eke** » Sat Jan 05, 2008 12:09 pm

Mask of Destiny wrote:
LocalH wrote:
Mask of Destiny wrote:Biggest problem is that in order to avoid artifacts you need to turn the display off during HBLANK and the only way to do that and still have enough time to DMA 8 colors is to poll the status register for HBLANK. HINTs occur too late. So you basically end up burning 100% of your CPU time on the color changes outside of HBLANK. With some clever coding I suppose you could probably break up other processing in to chunks that would fit in the active display period, but it would be somewhat awkard to do.
Said artifacts would display at the point where you actually write to CRAM, correct? Which I would think would be in the horizontal border (I wouldn't guess it'd matter one the actual blanking began since the electron beam is not drawing at that point). Every analog TV I've ever used a Genesis on showed, at most, a tiny sliver of the horizontal border on the left of the active display, so unless said artifact somehow bleed over into the active display, I wouldn't guess it would be noticeable (and since said artifacts don't even appear on emulators it wouldn't matter there either).
They actually show up about 1/4 of the way across the visible portion of the video signal. No idea what causes them, but turning off the display while you're doing the CRAM update fixes it. I didn't discover this glitch or the workaround, but I have seen it in action. The artifacting isn't severe, but it's fairly noticeable.

I think the same thing happens in Sonic 2 split-screen mode (first zone): you can see silver artefacts at the top of the bottom screen, near the separating bar.

I once debugged the game as it relies on accurate hblank and dma timings to display the separating bar properly on emulator and here's what it is doing:

- the HINT routine execute some cycles then polls the VDP status flag until the HBLANK flag is set
- then it set the display OFF and run DMA that freeze the CPU for some lines (actually, this set the size of the separating screen bar)
- finally it polls status flag again until HBLANK is set and set DISPLAY ON

By emulating accurate hblank timings (that means,indeed, that HINT occurs too late and have to wait the next HBLANK), i was able to reproduce similar artifacts, above the 2 first visible rings