CRAM color palette dots option

[Peredonov]

Apologies if this has been discussed and settled already, but I was wondering if devs have considered enabling to display the CRAM color dots, which usually appear on the lower overscan area during some game scenes.

An example: https://i.redd.it/ym39kqd6v8d01.jpg

This is probably the only thing the Genesis core is missing to really make you feel like you are really playing a Genesis/MD . Would really like to see it as a user selectable option. The Mega Sg for instance had it added as an option in a firmware update.

[retrorepair]

I'd like to see this too. Aren't these manipulated by certain demos for drawing to the screen without using sprites?

[retrorepair]

I'm interested actually how the core doesn't do this currently.

From my understanding they are the result of DMA access from the 68k which lots of games use. Are they masked at the moment?

[paulbnl]

The dots are caused by writing to CRAM while the VDP is reading from it. Most likely a real console uses a single data bus for reading and writing so it will read the value being written instead of the value in CRAM. The core uses dual port ram so it can read and write simultaneously.

It is a minor change to add CRAM dots: https://github.com/MiSTer-devel/Genesis ... cdba4d6379

As far as I know demos would write to the background color so it would work even if CRAM dots are not visible. CRAM dots appear only every other pixel so by writing to the background color you get CRAM dot->BG->CRAM dot->BG. This results in double sized pixels horizontally.

[Shaneus]

Very cool, to be honest I'm surprised it was so simple!

[retrorepair]

Awesome!

I think the only thing really left to add would be the debug register (really I think only for Titan 2, though I think the boarder thing sort of works anyway?) and the TMSS BIOS loading.

[retrorepair]

The dots are caused by writing to CRAM while the VDP is reading from it. Most likely a real console uses a single data bus for reading and writing so it will read the value being written instead of the value in CRAM. The core uses dual port ram so it can read and write simultaneously.

It is a minor change to add CRAM dots: https://github.com/MiSTer-devel/Genesis ... cdba4d6379

As far as I know demos would write to the background color so it would work even if CRAM dots are not visible. CRAM dots appear only every other pixel so by writing to the background color you get CRAM dot->BG->CRAM dot->BG. This results in double sized pixels horizontally.

Hmm, the dots are present but they aren't in the border/overscan area. Is the border generated differently in MiSTer?

[retrorepair]

Actually, it seems another time they are displayed (probably what I'm thinking of) is when the pallet changes in VBL:

https://segaretro.org/Sega_Mega_Drive/P ... #CRAM_dots

[paulbnl]

Did you forget to enable the border? Because here there's a disco party in the Sonic border.

[retrorepair]

Did you forget to enable the border? Because here there's a disco party in the Sonic border.

That's what I get for building a source I've been messing with, works now

I think if the TMSS BIOS was an option this would be the most accurate megadrive reproduction around!

[Peredonov]

Thank you so much paulbnl for answering my prayers!

Could you (or retrorepair) please attach a build with this option incorporated? Not sure when a public release will be updated next. Or if you can point me to instructions on compiling the .rbf myself I can try to do so.

Again, thank you!!

[paulbnl]

Howto build:

https://fpgasoftware.intel.com/17.0/?ed ... rm=windows
1. Download Quartus Prime Lite 17.0 -> Individual Files -> Quartus Prime Lite + Cyclone V device support
2. Download Gameboy Github repo zip. Code -> Download Zip
3. Quartus -> File-> Open Project-> Open Gameboy.qpf.
4. Processing -> Start compilation.
5. The rbf will appear in the output_files folder

[Peredonov]

Thank you for the instructions, although it took over 3.5 hours to compile on my old Windows laptop, it works as expected!

I also realized this should also be added to the MegaCD core, I imagine you simply would need to copy the same commit to it.

Thanks again for all you do!

[Lisko]

This is a very appreciated option. I don't have a mega drive anymore for comparison but I think that mister displays more dots than the mega drive, isn't it? For example in sonic 3 with cram dots enabled I see dots in the right area of the water in the first stage. Wasn't sonic 3 only displaying cram dots in overscan area in mid frame palette changes?

[aberu]

Did you forget to enable the border? Because here there's a disco party in the Sonic border.

That's what I get for building a source I've been messing with, works now

I think if the TMSS BIOS was an option this would be the most accurate megadrive reproduction around!

There's still quite a few things to keep people busy in the Genesis core. All roms that had eeprom-based saves listed here --> https://github.com/ekeeke/Genesis-Plus- ... prom_i2c.c - likely are not saving. That's a pretty big task. Only some of them have SRAM hacks. But most of them are mediocre games, however NBA Jam and NBA Jam TE aren't

Also there was a discovery by Artemio Urbina that the timing is off in multiple instances, so the bus arbiter is being rewritten now.

There's also little things here and there which keep coming up, edge cases, like homebrew and some prototypes not behaving the same as original hardware.

As far as to the end user though, everything is super super accurate, which I love, I use the Genesis core the most.

[paulbnl]

This is a very appreciated option. I don't have a mega drive anymore for comparison but I think that mister displays more dots than the mega drive, isn't it? For example in sonic 3 with cram dots enabled I see dots in the right area of the water in the first stage. Wasn't sonic 3 only displaying cram dots in overscan area in mid frame palette changes?

The palette writes in Sonic 3 in that water are happening at the wrong place. It indicates a timing issue with the core.

[TLPD-AVW]

Now that we have had CRAM option for the Genesis core for some time, shouldn't it be eventually ported to the MegaCD core as well? Or did the Sega Mega CD somehow alter the video generation for the entire system, eliminating CRAM dots on the combined unit?

[retrorepair]

Now that we have had CRAM option for the Genesis core for some time, shouldn't it be eventually ported to the MegaCD core as well? Or did the Sega Mega CD somehow alter the video generation for the entire system, eliminating CRAM dots on the combined unit?

The Mega CD definitely still exhibited this. It does on my MCD2 anyway.

[the_muteKi]

Cram dots are artifact of Genesis VDP (short answer: interrupts). Sega cd graphics hardware blits to Genesis VDP, not overlaid. Cram dots should be visible in same cases where they show up on Genesis.

[Zesty]

This is exciting! I was really hoping someone would implement this. I'm kind of nostalgic for the dots, even if they were usually hidden by overscan in most games.

How hard would it be to show the left and right borders too? That's the only obvious visual difference left between the core and original hardware, as far as I know: https://github.com/MiSTer-devel/Genesis ... issues/109