An interesting thing occurred to me when I looked at your 'scope traces, concerning the instruction-trace Montserrat recorded last year (when one of his consoles was crashing in a similar place, on the "SEGA!" PCM on Sonic1's intro). We saw two adjacent reads of the same PCM address
Code: Select all
167355419 C RD 071FC4 4E71 ; nop
167355444 C RD 071FC6 51C8 ; dbra d0,
167355469 C RD 071FC8 FFFC ; -4
167355514 C RD 079852 7581 ; <--- PCM read
167355583 C RD 071FC4 4E71 ; nop
167355608 C RD 071FC6 51C8 ; dbra d0, ... etc
167358463 C RD 071FC4 4E71 ; nop
167358488 C RD 071FC6 51C8 ; dbra d0,
167358514 C RD 071FC8 FFFC ; -4
167358545 C RD 079852 7581 ; <--- PCM read
167358560 C RD 079852 7581 ; <--- PCM read (same address!)
167358615 C RD 071FC6 51C8 ; pre-fetch dbra d0, ...
167358673 C WB FFFDAC 1FC4 ; save PC, low word
167358699 C WB FFFDA8 2608 ; save SR
167358724 C WB FFFDAA 0007 ; save PC, high word
167358741 C RD 000010 0000 ; illegal instruction vector, high word
167358766 C RD 000012 03E6 ; illegal instruction vector, low word
Usually the PCM reads from the 0x079688 region are far apart, but at timestamp 167358545ns, there are two
reads from the same address, adjacent to eachother. Whilst the FPGA is busy processing the latter read, it misses the expected 68000 read from 0x071FC4, so rather than reading 0x4E71 (NOP) it reads 0x7581 which throws an exception and crashes the 68000.
When we later got a logic-analyzer trace, it looked like this:
At the time I failed to put these two pieces of information together, and always assumed the region pointed to was the gap between two reads
, very close together. But in retrospect, looking at your 'scope trace, I think it might be just a bit of noise part-way through what's supposed to be a single, long read. The FPGA incorrectly interprets this noise as the beginning of another read, hence the double-adjacent-read from the same PCM address seen in the instruction trace. As for the source of the noise, I guess it could be due to slew-rate issues as Jorge pointed out (I'm not a real electronic engineer, I just make it up as I go along, so I defer to others with more experience of such things).
I can certainly reduce the slew-rate of the FPGA I/Os, and I can add some debounce logic to ensure that short, logic-high (i.e deasserted) pulses on /OE are ignored so they don't erroneously trigger a new read.