I implemented MBC5 emulation and optimised the code enough to load Pokemon Blue in ~20s instead of >5 minutes. It plays the intro and then (of course, why would I have expected something else) crashes.
Whelp, I probably messed up the bank switching somewhere. I should check what the game does in the emulator...
I'm a bit jealous of the MachXO2 because my experiments are still using ispMACH 4000 and the crappy ispLEVER software :/
Hehe, I probably checked every FPGA family I could find and the MachXO2 was the only one that really fits the bill (small package with enough I/O-pins, enough logic, single supply, embedded config memory and enough embedded memory to boot from, PLL... you get the idea). Of course not everything on that list is really mandatory, but the smaller (feature-wise) chips I found did not really seem to be worth the trouble.
My design currently uses about 25% of the FPGA and the MACH 4000 looks relly tiny in comparison. How much did you manage to fit in the CPLD?
It's difficult to see from the pictures, but do you have unused inputs on your level shifters? You probably know this, but CMOS inputs should in general not be left floating.
That is true. I do have 4 unused and unconnected inputs on one level shifter (74LVT16245B) which is fine according to the datasheet because "Bus hold data inputs eliminate need for external pull-up resistors to hold unused inputs", but they are directly adjacent to a GND trace so connecting them would be trivial.
On pre-CGB devices the only DMA available is OAM DMA which will not help you. Can't you move bytes around with the FPGA faster than the GB CPU? If your level shifters are 3-state, you can isolate the GB from the FPGA/SDRAM and just move things around as fast as possible.
That was probably a bit unclear. By DMA I mean moving around the data without involving the GB CPU. The SDRAM is sitting on its own isolated bus anyway and is idle most of the time, so I just wanted to squeeze some cycles in there. The GB should have absolute priority, but the CLK pin makes it easy to anticipate the next access.
I will need something like this anyway to move savegames to permanent storage, as ROM + Save RAM are stored in the SDRAM and battery backing that is not feasible. I'm not too sure how reliable this is if the GB can be turned off at any moment, but I'm not there yet anyway.
Speaking of 3-stating the level shifters, you can also reset the GB by pulling RST low.
There is an open-collector (or rather open-drain) transistor on the bottom right connected to RST. Resetting the GB works well, but I don't really need it at the moment.
Are your level shifters dual supply or just 5V-tolerant? I'm pretty sure a 5V-tolerant buffer in the data bus wouldn't be 100% reliable because it can't reliably drive highs in the full 5V CMOS range used by the Game Boy. In practice this might not be a problem, but random issues are very annoying and hard to debug.
The shifters are single supply 74LVT16245B. The 3.3V are indeed slightly too low for proper CMOS high levels, but I haven't encountered any issues so far. At a glance, the 74ALVC164245 could be an option. Do you have suggestions?
I see that CLK/PHI pin from the Game Boy is connected. Are you aware that it is stopped sometimes (e.g. HALT mode, STOP mode)?
Yes. Everything runs off the 40MHz oscillator next to the MicroSD socket. Some signals are unused but connected in case I need them later and because there were still unused FPGA pins. Now I kind of wished I had added more than one LED instead of connecting all 4 SDIO data pins