SpritesMind.Net

FYI, this long standing issue was finally fixed thanks to the help of irixxxx (developer of a Picodrive fork) who successfuly debuggued the root cause and found the solution : a delay is needed when receiving a CD read command while reading is already in progress to allow at least one additional sec...

Unfortunately, Bizhawk is using a quite old version of Genesis Plus GX so it's probably missing a lot of bugfixes and added features, including automatic Mode 1 support.

That's impressive... and an unvaluable source of information. Thanks for your work

I think Genesis Plus GX also supports Mode 1 boot these days, but I've personally had trouble figuring out how to get it running. Hi, You only need to have a .cue file with same basename as the ROM file you load, in same directory, and Sega CD Mode 1 should automatically be enabled. Alternatively, ...

I think I made a typo and meant to write CXA output instead. Signal levels are near 1Vpp for full while there. It was so long ago so I am not totally sure anymore. 1Vpp for full white should be at the CXA input according to its datasheet with output being 1.4Vpp for full white still according to da...

SMS2 : mV, ratio, RGB 0, 0.000, 0 364, 0.350, 89 720, 0.684, 174 1052, 1.000, 255 I was recently trying to figure how to simulate accurate RGB levels of MD1/MD2, MS1 and MS2 RGB models (that were afaik only sold in France) and was wondering about these measured voltages (that correspond to 315-5246...

Another particularity I recently noticed is that the X'Eye (and likely Wondermega M2) was using 32KB RAM chip (LC33832) with the CDC (LC89513) instead of 16KB in all other Mega-CD models.

Fuuuuuu... the bugs in that Radical Rex code, and that just in the initial loading routine. Really surprised it runs in any emulator at all. Seems like a frickin' miracle! I know this thread is getting old (and its original author is no more among us sadly) but I recently looked again into this gam...

HV counters are not affected by display or interrupts being disabled.

VBLANK flag is forced to 1 whenever the display is disabled/blanked (through VDP register $01 bit 6).

That's only the 2nd part (ignoring invalid command values on data port writes).

Looking at Higan sourcecode, the error is here:
https://github.com/higan-emu/higan/blob ... o.cpp#L154

io.command[1:0] and io.address[13:0] should also be updated in case of register write

From memory, this game attempts to write to VRAM after setting the CTRL port for a register write, without setting the address and control registers in between. The solution is to still update the address (lower 14 bits) and code (lower 2 bits) registers when a VDP register write occurs, and ignore ...

For what it's worth, I finally got access back to my flashcart and verified the game has notable slowddown on real hardware as well.
Also confirmed that HBLANK flag is still set/cleared normally during VBLANK.

Yes, as described in linked topic, active display corresponds to the 256 or 320 active pixels wide area.

Well, i know that it does some quite risky synchronization at some points as it locks in emulators unless you carefully lockstep the two cpus but I wasn't aware of any other bugs... All I know is that, when intro is started, a dma occurs to load the sprite table from word-ram but, for some unknown r...