1536 color test

dr. apocalipsis · Post by **dr. apocalipsis** » Wed Sep 10, 2008 10:51 pm

Hi.

I thought maybe it could be interesting to try this demo on real hardware.

Only works something close to fine on Gens. Even Fusion fails to draw what expected.

Someone?

http://rapidshare.com/files/144238750/TEST1536.BIN.html

Eke · Post by **Eke** » Thu Sep 11, 2008 7:46 am

this is a color demo from Charles MacDonald, using Shadow/Highlight effect to output a larger amount of colors (3 x 512) and I'm sure this work on real hardware since he made all his tests on real hardware

on an emulator, this will fail if you implement cycle-accurate VDP timings (HINT/HBLANK & FIFO latency) in an unaccurate way. Gens does not implement completely so it has no problem with the program, Kega implements VDP latency and cycle-accurate INT but is not as accurate as you would initially thought.

mic_ · Post by **mic_** » Thu Sep 11, 2008 10:01 am

It works on my PAL Megadrive 2.

screenshot taken with mobile cam.

Fonzie · Post by **Fonzie** » Thu Sep 11, 2008 10:28 am

If i remember, Charles used some kind of DMA trick to refresh colors.
Mic : Did you see a bunch of white/black corruption dots blinking all around the screen?

dr. apocalipsis · Post by **dr. apocalipsis** » Thu Sep 11, 2008 10:36 am

Many thanks for the shot ^.^

Anyway, could this way represent statics pictures with such high number of onscreen colors?

Or only this secuential way with some sort of DMA trick?

Many games have more than 100 colors using Sh/Hi modes. But are limited to 4x15 (+0 transparent) palettes due to CRAM, true?

There is any way of avoid that CRAM limit?

Thanks

Jorge Nuno · Post by **Jorge Nuno** » Thu Sep 11, 2008 10:40 am

Use the horizontal interrupt or the HV counter to decide when to change colors mid-screen.

Make sure the colors you are replacing aren't needed anymore in the bottom part...

Just update them when the video is inactive (in the TV left/right border) or else the colors you are trying to write become visible as pixel glitches on the screen (like Sonic1/2 in the water levels, among others)

Also I believe that the maximum # of colors isn't 3*512.
Example: the color 0x0222 (grey) I think it's equal to the color 0x0444 shadowed.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Thu Sep 11, 2008 11:52 am

Colors will overlap, my 1024 color test is actually 960 colors... so 1536 is most likely 1408 colors... you will get pixel carbage none the less, with DMA, they're just more closer together.

dr. apocalipsis · Post by **dr. apocalipsis** » Thu Sep 11, 2008 2:21 pm

Gens display 1471 colors, in fact

Jorge Nuno · Post by **Jorge Nuno** » Thu Sep 11, 2008 2:46 pm

TmEE co.(TM) wrote:Colors will overlap, my 1024 color test is actually 960 colors... so 1536 is most likely 1408 colors... you will get pixel carbage none the less, with DMA, they're just more closer together.

If you do DMA in the left/rigth black border (Hsync Low) they aren't visible at all... Or in PAL starting in line 577+ or in NTSC in line 481+, anytime.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Thu Sep 11, 2008 3:35 pm

DMA will not finish in the HBL period I think, or does it ? I've not tested it actually... but seeing how long it takes to write 16 colors into CRAM on overscan area, I can't imagine all data being written within the HBL period...

Jorge Nuno · Post by **Jorge Nuno** » Thu Sep 11, 2008 3:56 pm

I think you can DMA something like 8 colors, in the invisible region, if you prepare the DMA before H-int, though I'm just speculating.

Mask of Destiny · Post by **Mask of Destiny** » Mon Sep 22, 2008 3:36 am

In my tests, you could turn the display off, DMA 8-colors, and turn it back on all within H-Blank if you polled for H-Blank rather than using H-Interrupts. Using H-Interrupts I think I was able to do 8-colors if I didn't turn the display on and off, but not reliably. Also doing DMA to CRAM during H-Blank causes a little bit of junk to be displayed at a certain point in the display if you don't turn the display off before doing the DMA (I did not discover this phenomenon, but I have observed it). It's been a while though. All of these tests used the same DMA pre-load optimization that Charles MacDonald's demo uses.

Note that these tests were done in "Sega Cd" mode, but running from Genesis work RAM (IIRC).