I'm doing some MMC1 stuff and found a few games corrupt their own PRG-RAM data by accidentally writing to it. So I'm trying to fix it permanently in my FPGA.
I've got the M2 rising edge signal being delayed by 40ns, it it looks accurate on my analyzer but I am seeing another section that I'm concerned about. When ROMSEL goes high, M2 is still high for 10ns before going low (see attached picture). Do I need to delay the rising edge of ROMSEL in addition to delaying the rising edge of M2? Or should I be delaying both the rising and falling edges of M2?
Any help is appreciated!
PRG-RAM delay implementation help
Moderator: Moderators
Re: PRG-RAM delay implementation help
bumping this one, hoping that someone can help me out!
If there is somewhere else I should post this that may get more attention please let me know.
If there is somewhere else I should post this that may get more attention please let me know.
Re: PRG-RAM delay implementation help
/ROMSEL is generated by the 74LS139 (usually) on the mainboard, and I've usually seen a ~30ns propagation delay through it. So the timing goes something like
A15 changes a little after M2 fall; I haven't characterized this delay specifically. (I assumed it's the same as R/W in viewtopic.php?p=244126#p244126 , where it's declared as up-to-140ns in the 2MHz binned 6502 and R/W measured at 60ns on my 2A03G)
You shouldn't need to delay /ROMSEL, only shape M2 so that you can use /ROMSEL to know when A15 would have been low.
Code: Select all
M2 ___...___¯¯¯˙˙˙¯¯¯___...___¯¯¯˙˙˙¯¯¯
A15 ¯¯_...______...____¯¯˙˙˙¯¯¯¯¯¯˙˙˙¯¯¯
/ROMSEL _¯¯˙˙˙¯¯¯¯¯¯˙˙˙¯¯¯¯¯¯˙˙˙¯¯¯¯__...___
You shouldn't need to delay /ROMSEL, only shape M2 so that you can use /ROMSEL to know when A15 would have been low.
Re: PRG-RAM delay implementation help
This problem has always been the topic of discussion in the forum. At present, there are probably several solutions
1. RC delay
2. Use an external oscillator to resample m2 and delay several clocks
3. Utilize the inherent Tpd of 74-devices
Here, the RC delay has been discussed many times, but it is not very reliable for different devices, especially cpld/fpga output pins with different driving strength and output impedance. Particular RC values are required and tuned in particular circuit.
Resampling M2 is mainly used in FPGA implementation
Here I mainly talk about the design notes of discrete 74 components:
1. I suggest using 74hc139. The decoder has a longer Tpd than other NAND gate devices
2. Use HC instead of LS, and the Tpd of HC series is also longer
3. Use cascade connection, connect M2 to the first stage instead of the second stage, which will help delay M2 by twice Tpd
4. Using the method of reducing VCC and connecting a diode in series will help to prolong Tpd
Generally, if 74hc139 is powered by 5V, the Tpd is about 15ns. When using two stage cascade, it is about 30ns. Moreover, when VCC is reduced to 4V, the Tpd can be extended to 60ns
1. RC delay
2. Use an external oscillator to resample m2 and delay several clocks
3. Utilize the inherent Tpd of 74-devices
Here, the RC delay has been discussed many times, but it is not very reliable for different devices, especially cpld/fpga output pins with different driving strength and output impedance. Particular RC values are required and tuned in particular circuit.
Resampling M2 is mainly used in FPGA implementation
Here I mainly talk about the design notes of discrete 74 components:
1. I suggest using 74hc139. The decoder has a longer Tpd than other NAND gate devices
2. Use HC instead of LS, and the Tpd of HC series is also longer
3. Use cascade connection, connect M2 to the first stage instead of the second stage, which will help delay M2 by twice Tpd
4. Using the method of reducing VCC and connecting a diode in series will help to prolong Tpd
Generally, if 74hc139 is powered by 5V, the Tpd is about 15ns. When using two stage cascade, it is about 30ns. Moreover, when VCC is reduced to 4V, the Tpd can be extended to 60ns