1536 color test

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

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
dr. apocalipsis
Interested
Posts: 17
Joined: Fri Oct 19, 2007 10:56 pm

1536 color test

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
Very interested
Posts: 856
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

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 :wink:

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_
Very interested
Posts: 265
Joined: Tue Aug 12, 2008 12:26 pm
Location: Sweden
Contact:

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

It works on my PAL Megadrive 2.

screenshot taken with mobile cam.

Fonzie
Genny lover
Posts: 323
Joined: Tue Aug 29, 2006 11:17 am
Contact:

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
Interested
Posts: 17
Joined: Fri Oct 19, 2007 10:56 pm

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
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

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)
Very interested
Posts: 2370
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

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.
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

dr. apocalipsis
Interested
Posts: 17
Joined: Fri Oct 19, 2007 10:56 pm

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

Gens display 1471 colors, in fact :P

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

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)
Very interested
Posts: 2370
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

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...
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

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

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
Very interested
Posts: 591
Joined: Thu Nov 30, 2006 6:30 am

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).

Post Reply