Is the raster effect (quick palette switch) useless?

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Chilly Willy
Very interested
Posts: 2603
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Aug 05, 2012 12:02 am

Oerg866 wrote:
Chilly Willy wrote:What would suffer the most with DMA direct color is PCM via the YM2612 - unless you only did a line or two, you'd have a BIG click everyframe. Even a low sample rate wouldn't help. But just using FM updated in the vblank wouldn't have a problem.
Actually no, it's not that big of a deal. We once did DMA stuff with music, the engine survives with minimal cpu time. You'll notice a little flakyness. But in honesty, you either skillfully use the YM and PSG to their fullest without relying on PCM too much or you just don't belong in that field, end of story. PCM-Only stuff on Mega Drive is LAME.
Actually, yes. If you play a PCM clip, be it sound effect or whatever, you're going to hear a honking big glitch in the PCM with dma that lasts more than a few scanlines.

Let's do some math... 1 scanline is about 63.5 microseconds. Let's take an extremely crappy PCM clip you'd be embarrassed to play on an 8-bit system... say 4kHz. That's 250 microseconds per sample - which is 3.93 scanlines per sample. So even a ridiculously tiny one cell tall DMA (8 scanlines) will hold off the PCM for two sample periods... well within the hearing of even an average gamer. Using 100 lines will hold off the PCM for 25 samples, and if you can't hear that, you're deaf! :lol:

The problem gets worse the higher the PCM sample rate. At 12kHz, a 200 line DMA will hold off the PCM for 150 samples. :shock:

Remember that this delay is for EVERY SINGLE FRAME of the display, and periodic noise is FAR more easily heard than random noise... which is just noise. You have the equivalent of a 60 Hz square wave added to your PCM.

Now if you're playing a 1kHz sample, MAYBE the sample is sooooooo crappy you won't notice the pop from the DMA, but who's going to use PCM that bad? :wink:

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Wed Oct 03, 2012 10:37 pm

greatkreator wrote:Do you know a way to overcome those CRAM artifacts?
I seem to remember that one of Charles MacDonald's Genesis docs or demos mentioned that you needed to turn off the display while copying colors to avoid the CRAM dot artifacts. I seem to remember that I was able to confirm this with my own hardware back when I was playing with color cycling.

This obviously only works if you do all of your color copying during HBLANK. HBLANK is very short. Polling on VDP flags will save you some cycles over using the HBLANK interrupt (at the cost of making it rather difficult to do anything useful with the CPU during the active display period), but even then you won't manage more than 8 colors changed per line.

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Thu Oct 04, 2012 12:48 am

Mask of Destiny wrote:
greatkreator wrote:Do you know a way to overcome those CRAM artifacts?
you needed to turn off the display while copying colors to avoid the CRAM dot artifacts.
I think I was wrong about this. When the screen is turned off the VDP reads CRAM to get the backdrop/overscan color, and when games DMA their palette during V-Blank you see the dots jumping around in the border area as the writes to CRAM are made. This would indicate the flicker is present even with the screen off.

Now I would imagine the same would hold true for CRAM access during the active display area with the screen turned off but I haven't messed with that in ages. I'll try to test this soon.

Speaking of edge cases, I wonder if you can change CRAM without flicker in mode 4 by enabling the TMS9918 mode (which isn't supported) which blanks the screen but IIRC always uses black regardless of CRAM contents. Not that there's a big need for such a technique... :D

Mask of Destiny
Very interested
Posts: 572
Joined: Thu Nov 30, 2006 6:30 am

Post by Mask of Destiny » Thu Oct 04, 2012 11:21 pm

Charles MacDonald wrote:I think I was wrong about this. When the screen is turned off the VDP reads CRAM to get the backdrop/overscan color, and when games DMA their palette during V-Blank you see the dots jumping around in the border area as the writes to CRAM are made. This would indicate the flicker is present even with the screen off.
I could have sworn that I had tested two versions (one with screen turned off during DMA in HBLANK and one with it on) and getting observations that matched what your notes said, but I suppose my memory could be faulty. I'll have to see if I can get my old code working again and give it another test.

I'll be honest, the explanation of the artifact never made a lot of sense to me. I would guess that the format of the line buffer is something like 7-bits (1-bit for priority and 6 for palette entry) per pixel. This would require less CRAM bandwidth and less storage than storing RGB values. Assuming this is correct, the only time the VDP would read from CRAM is when it's displaying the background color or part of the active display area. It shouldn't be doing either during HBLANK. Even if you ran a little long, you would expect the artifact to be there in the border, not in the active display area.

User avatar
TmEE co.(TM)
Very interested
Posts: 2319
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Fri Oct 05, 2012 11:23 am

CRAM is single port and read every pixel, when you do a write the display ciruit will either not read (show a fixed value) or rad the value being written. CRAM dots have the color of the palette entry that you are writing. Writes to any memory happen every second pixel (unless you hit a refresh cycle, then you get 2 pixel delay).
Border color is still being read out of CRAM so you get artifact everywhere.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Sun Oct 07, 2012 3:35 am

TmEE co.(TM) wrote:CRAM is single port and read every pixel, when you do a write the display ciruit will either not read (show a fixed value) or rad the value being written.
Thanks TmEE!

I did some tests and can confirm what you said. When accessing CRAM you get flicker all over, in the active display, outside of it, with the screen on or off, etc. Oh well. :)

Now for something new:

I was reading about how Atari ST coders sync the 68K to the video hardware by reading the current bitmap address being scanned out to the display, and using that to execute a variable number of shifts with LSR Dn,Dn. This has the effect of making the 68K run long enough (or short enough) to become synchronized to the display. Well as you can guess, it works to some extent on the Genesis too:
move.b $C00009, d0
not.b d0
lsl.b d0, d0
After this point the 68K is roughly synchronized with the raster beam, but because it doesn't run at the same speed, the synchronization changes a bit as the scanline is rendered from left to right. However it's much better than nothing. What's cool is that now you can write to CRAM rapidly and get a much more stable display.

To improve things, I found if you set the control register to $01 for 320-pixel mode (not $81) then the 68K <> VDP synchronization is extremely consistent on every scanline; in fact there seems to be only minor jitter every other scanline. This changes per frame and visually cancels out at 60 Hz.

If you use these two techniques you can display a 32x224 9-bit bitmap that looks quite good. The column widths are more uniform and vary around 8 to 10 pixels. At least with the composite video output, using mode 0x01 does cause more color fringing but I guess you have to have trade-offs.

Here are some pics:

Image

In this one I poll the H-Blank flag in the control port and then write out 32 values to CRAM, using mode 0x81. It's pretty bad.

Image

In this one I do the beam synchronization thing, using mode 0x81. There is some horizontal jitter that creeps up the screen repeatedly, and the motion is very noticeable which a single frame doesn't capture.

Image

Finally, I do synchronization and use mode 0x01. There's jitter, but it's consistently positioned on every frame.

You can get much more narrow columns by using move.l, but back to back move.l instructions lead to columns of quite different widths. For this example I had a block of 32 move.w instructions.

There are probably other applications for the synchronization technique like getting "cleaner" splits when writing to registers mid-frame instead of having garbage coming out into the screen. Anyway, something different and kinda fun. :D

User avatar
TmEE co.(TM)
Very interested
Posts: 2319
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Sun Oct 07, 2012 3:42 am

overflow the FIFO to get sync to VDP :P
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Sun Oct 07, 2012 4:05 am

TmEE co.(TM) wrote:overflow the FIFO to get sync to VDP :P
I've never been able to fill the FIFO, what's the trick for doing it?

EDIT:

OK I get it now. Well at least we have a few approaches at our disposal now. :P

LocalH
Very interested
Posts: 152
Joined: Tue Dec 19, 2006 5:04 pm

Post by LocalH » Mon Oct 08, 2012 10:35 pm

Nice technique, Charles. I wonder how it would work if, instead of stuffing CRAM, one pre-loaded 64 colors into CRAM and modified VDP$07 to point to the desired colors. Less colorful, but possibly better for synchronization and/or resolution? I'm pretty sure that modifying the backdrop register bypasses the issues with the "slots" that restrict the width of the color changes.

User avatar
greatkreator
Very interested
Posts: 153
Joined: Sat May 12, 2012 7:37 pm
Location: Ukraine

Re: Is the raster effect (quick palette switch) useless?

Post by greatkreator » Sat Nov 28, 2015 4:43 pm

Hi greatkreator from 2012!

You were wrong. It is a very cool effect and very useful!
You just needed to turn the screen and do DMA. Also you should add some sync and not to try to transfer 64 colors per line without artifacts.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests