My mistake, I wasn't reading the timestamps properly - they actually correlate quite closely.Burbruee wrote:Oh, this is very strange that the clock speed would be different! It's not an NTSC-machine at all, it's a stock PAL MD1.
Great, thanks for confirming.Burbruee wrote:And yes I did the SDRAM test and there was no difference when comparing the two files, I just re-ran all tests and it reads back fine.
OK, here's the comparison, the same ROM running on my setup:Burbruee wrote:Here's the log.
Code: Select all
Prophet36: | Burbruee:
---------------------|---------------------
0 C RD 000000 FFFF | 0 C RD 000000 0000
38 C RD 000002 FE00 | 38 C RD 000002 FE00
64 C RD 000004 0000 | 64 C RD 000004 0000
89 C RD 000006 0206 | 89 C RD 000006 0206
114 C RD 000206 4AB9 | 114 C RD 000206 0206
152 C RD 000208 00A1 | 152 C RD 000208 4AB9
177 C RD 00020A 0008 | 177 C RD 00020A 0008
203 C RD 00020C 6606 | 202 C RD 00020C 6606
241 C RD A10008 0000 | 261 C WB 00FDFE 020A
Since this ROM was written over USB, we can eliminate the possibility that it's a flash problem. And I stand by my previous statement about it being unlikely the SDRAM isn't fast enough.
But the SDRAM controller is rather unlike the asynchronous ROMs found in MegaDrive cartridges. It needs to be triggered, on a single 48MHz cycle, with a command (read, write, refresh, etc) an address and (for writes) some data. It then goes away and does stuff for 12 (IIRC) 48MHz cycles, during which time it cannot accept more commands.
One of the biggest design challenges with UMDK was reliably detecting the assertion of /OE on the cart slot, signalling when it's safe to begin an SDRAM read, but doing it quickly enough to ensure data is ready on time during one of the fast DMA read cycles.
I suspect what's happening here is that the rising edge of the /OE signal on the cart slot is slow, and that happens to manifest itself as noise on the signal seen by the FPGA, fooling it into thinking the MegaDrive is beginning read N+1, when it's actually ending read N. The solution is to modify the VHDL to ignore the state of /OE for four or five cycles after it deasserts for the first time at the end of a read. I'll have a look into doing that, and sending you a new .xsvf file to try.