DBGC
DBGC copied to clipboard
deltabeard
Add RP2350 support
The RP2350 has improvements to the PIO that includes:
- Improved GPIO input/output delay and skew
- Reduced DMA request (DREQ) latency by one cycle vs RP2040
- Use of PSRAM
These features may allow for improvements in DBGC, and possibly allow for support for CGB clock speed games.
No. I also don't think changes of the RP2350 are enough to support double speed. With the larger internal RAM, it may be possible to play games at double speed, but the communication with the PSRAM and NOR Flash are still limited to their maximum frequency of 133 MHz. So larger games that need to run off of external storage will be too slow for CGB double speed games.
Only other method is to use a parallel flash/RAM module and use the RP2040 or RP2530 as a MBC chip.
How feasible do you think the parallel approach would be?
I know the current metric is using an FPGA/CPLD to stand-in for the MBC, but I feel if it could be completely replicated via simple RPi chips, that would far easier to create and maintain.
The issue is the time taken to obtain the data requested on the parallel bus by the Game Boy from the SPI NOR flash by the RP2040. The NOR Flash is typically limited to 133MHz, but maybe Hyperram, or something similar, could be used instead to obtain the ROM data with sufficient speed. This is because Hyperram is 200MHz and also uses double data rate (DDR). The RP2040 or RP2350 would have to use the PIO to communicate with the Hyperram, as the RP2040 and RP2350 does not support DDR in their QSPI peripheral. It may be possible to determine how much time it would take to receive a byte of data from the Hyperram using the PIO.
My suggestion earlier was to have a parallel flash chip connected directly to the parallel bus, which would remove the delay in the RP2040 getting the data from the SPI flash. But I haven't explored how that would exactly work. The MBC would be emulated by the RP2040, as processing data on the internal SRAM is very fast.
To that end, ROMs that are small enough to be stored entirely within the RP2040 SRAM should be able to run at double speed, but CGB games are typically much larger than the size of the RP2040 SRAM. Although, some CGB games use at least 512kB flash, they only use a small number of bank in their code.
Since the DMG is ~4.2MHz, the cart has ~238nS to put the ROM data onto the bus. In double speed mode at ~8.4MHz, the cart has ~119nS to put the ROM data onto the bus.
A QSPI NOR Flash at 133MHz that can use Fast Read Quad I/O (EBh), would take 21 clock cycles to read the first byte of data from the flash given an address. This would take at least (1/133e6)*21*1e9= 158nS, which is okay for DMG but too slow for CGB double speed. This of course doesn't take into account the delay in the RP2040 reading the address from the cart bus, processing it for MBC commands, and any delays on the internal RP2040 CPU bus.
With the Hyperram, or an alternative Octa-SPI DDR chip, the time taken for the Hyperram to return the first byte of data when given a read instruction and the address is (cmd_addr_clocks+cmd_full_latency)*data_rate*1e9= 50nS, where cmd_addr_clocks is the number of clock transitions required for the command (6); cmd_full_latency is the number of clock transitions until the first data is issued by the Hyperram when the longest duration of latency is considered (14); and data_rate is half a period, since the Hyperram is DDR.
Since the Hyperram requires only at least 50nS, that leaves a good ~70nS to take into account other delays. An additional delay is the PIO peripheral.
It might be possible to support the CGB double speed mode with the RP2040 and RP2350. Although I do not think that the RP2350 introduces any much benefit over the RP2040 in this use case.
To save even more time, since the Hyperram is 8-bit bus, maybe the pins of the Hyperram could be connected to the Game Boy bus directly using a switch. So instead of the RP2040 reading this data and then putting it on the Game Boy bus, the Hyperram bus could be connected to the Game Boy bus directly, with a switch controlling when the Hyperram should be driving the bus.