Recent Posts

The shell was only a test with a leftover cutdown aftermarket front shell to make sure the PCB fit inside and cleared the internal standoff. I'll have to find a donor SNES shell and cut a proper shell for the plugin.

Update: The SMS/GG firmware is still in BETA while I finalize the GG EEPROM support.

I've got the GG EEPROM read code working and the write code partially works. The write code only works when the cart is connected through my logic analyzer adapter board. The long traces on the logic analyzer adapter must be affecting the timing of the signals to the EEPROM. At least I know that the structure of my code is correct.

I'll continue to run tests in search of the proper timing needed for the write code. Once the EEPROM code is fully working then I'll release the firmware for BETA testing followed by public release.

Yes, Gameboy Camera was tricky and handled different from normal carts.

From my notes on my Arduino GB reader:WR, RD, CS must be low to get valid headerHold CS low for read/write operations

That's a strange combination, pulling WR and RD both low. Do you know if (and why) a real GB would do that? Before v0.19 beta, the Retrode actually did it, but I'm sure that was unintentional.Anyway, this interesting feature would explain why v0.19 beta and later cannot read the GB Camera. Quoting myself from the commit log:

Quote

Fixed issues with GB SRAM access: (...)- Pulling /CS low when writing to mapper register address 0x1EFF caused SRAM to be corrupted. I read on the internet that /CS is required for SRAM access, but optional for ROM access. It seems that some MBCs take /CS to select SRAM even if the address is outside the SRAM range. I therefore guess that the real GB pulls /CS low only when accessing SRAM, not when reading ROM or writing mapper registers. And so does the Retrode now.- Due to confusion about the port bits assigned to /CS and /RD, gbWriteByte allowed /RD to stay low while pulling /WR low as well. This caused SRAM writing to fail on MBC2.

Note that the SRAM corruption was hard to spot (only one byte changed, often an unused one). But my Kid Icarus savegame was affected noticeably.

Since reading the header neither requires writing to 0x1EFF nor to SRAM: Could the solution be to let auto-detection read the header as if it were a GB Camera, then chose the appropriate r/w methods based on the detected cartridge type (from the header)?

I'll give the Retrode and the adapter a good clean, and check if I can see any physical problems.

I retinned 2 connectors in the Game Boy adapter, and checked the solder points on the Retrode's Megadrive connector, but no difference I'm afraid.

At this point, it would be helpful to know if somebody else sees the same problem, with the same ROM name, on this cart, so that we know for sure that the problem is the Retrode's firmware, rather than going on a wild goose chase.

Hi...as per my knowledge you should be able to find hundreds of thousands of different types on Digi-Key. It appears the system is quite tolerant with respect to these clocks, so if there is no need for precise tuning you might as well grab anything within 1-5 of the target frequency.