PRG-RAM decoding circuitry - problems

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

PRG-RAM decoding circuitry - problems

Post by krzysiobal »

I need some kind of advice. My FPGA dev-cart needs M2 signal for clocking internal circuitries, but also for decoding accessess to $6000-$7fff (and also $4000-$5fff as some mappers, eg. mapper 90 uses this).
I know there is a delay of tens of nanoseconds between M2 changes and !ROMSEL changes
Image
so M2 transitions need to be delayed by that time.

There is lidnariq's proposition at the wiki:
Image

which in my opinion needs adding diode (the diode should be drawn backwards, sorry):
Image

because only rising edges on M2 need to be delayed. That is because all data & address latching into FPGA on CPU writes occurs at falling edge of M2, because that is the time the data is valid (at rising edge of m2 data is not valid). Anyway, never mind.

From my testing on various famiclones I figured out that 30pF is enough for most famiclones, but not for all - around 80 pF does the job. (otherwise writing to $E000-$FFFF causes data corruption in RAM mapped at $6000-$7FFFF.) Unfortunately, my FPGA has 3.3V IO pins so I had to put the `delayed` M2 thru 74LVC245 5V->3.3V converter. Unfortunately, this chip has maximum of 10ns/V rising time
Image.
What does that mean? With R*C = 1 kOhm * 28 pF the rising time at its slowest point is around 9 ns/V which is OK - and the output signal is OK.
When I increase C to 96 pF, the rising time becomes 32 ns which is too much. Too slow rising time makes various metastable states inside the 74lvc245 which makes its output behave weird - probably quick glitches are observed. Neither my analog scope nor my logic analyzer was able to see those glitches, but when I clock my FPGA with that signal, it detect those glitches. For exaample - when I clock my FPGA with that signal and I force it to change output signal on each of clock rising edge, I got something like that, instead of just M2 x 2.
Image



Here are some waveforms - all 2V/div, 0.1us/div

First - I tested with 28 pF.
Famiclone #1 (this one has longer !ROMSEL delay - about 40 ns) - 28 pF might be not enough:
Image Image Image

Famiclone #2 (this one has shorter !ROMSEL delay - about 30 ns) - 28pF should be ok:
Image Image Image

And just for curiosity - shape of M2 on RC circuit when 96 pF.
Image

First solution would be just fed to FPGA two signals - one not delayed M2 for clocking purposes, and secod glitched and delayed M2 for restoring A15 and thus decoding PRG-RAM, etc.

Second solution is to use schmitt on delayed M2 signal, before puting in on 74lvc245, but i dont want to use additional chips.

The FPGA has built-in schmitt trigger inputs, but it's useless at this purpuse because signal on 74lvc245 is not slow rising, but glitched.

Do you have any other idea how to use just one delayed M2 for all purposes in FPGA?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PRG-RAM decoding circuitry - problems

Post by lidnariq »

Couldn't you put the generation of the delayed copy of M2 after the 3V logic-level conversion?

Or use a nMOSFET clamp for just the delayed copy instead of a '245?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: PRG-RAM decoding circuitry - problems

Post by infiniteneslives »

Perhaps a little dirty, but it's worked for me. If you're only combating corrupted PRG-RAM, you can remove glitch enables by adding extra capacitive load to the sram /CE line. The cap value depends on your output driver strength. I've had success with 1nF on multiple CPLDs.

Of course that doesn't work if you have registers internal to the CPLD/FPGA that you're trying to deconflict.

I think the best solution is digital filtering/delaying of M2 internal to the FPGA itself. This of course requires that you have some logic to spare, and a decently high speed clock at your disposal however.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: PRG-RAM decoding circuitry - problems

Post by Bregalad »

krzysiobal wrote:I need some kind of advice. My FPGA dev-cart needs M2 signal for clocking internal circuitries, but also for decoding accessess to $6000-$7fff (and also $4000-$5fff as some mappers, eg. mapper 90 uses this).
I know there is a delay of tens of nanoseconds between M2 changes and !ROMSEL changes
Image
so M2 transitions need to be delayed by that time.
I do not see why it would be required to delay M2. I might be wrong, but if you're decoding circuit for SRAM at $6000-$7FFF for example, using M2 directly should work fine.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: PRG-RAM decoding circuitry - problems

Post by lidnariq »

... because M2 rises before /ROMSEL falls, any read or write from $E000-$FFFF looks like a read or write from $6000-$7FFF for the few tens of ns between the two edges.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: PRG-RAM decoding circuitry - problems

Post by Bregalad »

lidnariq wrote:... because M2 rises before /ROMSEL falls, any read or write from $E000-$FFFF looks like a read or write from $6000-$7FFF for the few tens of ns between the two edges.
Oh s***t I guess you're right. I understand now why it's so common to loose your saves :(
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: PRG-RAM decoding circuitry - problems

Post by krzysiobal »

lidnariq wrote:Couldn't you put the generation of the delayed copy of M2 after the 3V logic-level conversion?

Or use a nMOSFET clamp for just the delayed copy instead of a '245?
Thank you, I think that's the best idea. The FPGA internal Schmitt Trigger input should do the job. :)
infiniteneslives wrote:Perhaps a little dirty, but it's worked for me. If you're only combating corrupted PRG-RAM, you can remove glitch enables by adding extra capacitive load to the sram /CE line. The cap value depends on your output driver strength. I've had success with 1nF on multiple CPLDs.

Of course that doesn't work if you have registers internal to the CPLD/FPGA that you're trying to deconflict.
I have to try it because this one sounds the simpliest to apply for already etched PCB (no traces need to be cut off). I think the R+C delaying circuit is really not needed then, because:
- rising edges of M2 can be used to clock internal circuitry of FPGA
- falling edges of M2 can be used to latch data to internal FPGA registers (at this time, ROMSEL has correct & stable logic level)
All combinatorial logic involving M2 & !ROMSEL will of course be not right, but the only place it is used is really for generating !PRG_CE. Adding additional capacity as you said will delay falling (and rising edge) and thus RAM will probably behave properly.

Another way might be to instead of just capacitance, move the R+C+diode circuit to the RAM_!CS line, like the guys did to Famicom:
Image

infiniteneslives wrote: I think the best solution is digital filtering/delaying of M2 internal to the FPGA itself. This of course requires that you have some logic to spare, and a decently high speed clock at your disposal however.
I did it in my very first flash-cart, but it was clocked by external 100 MHz generator.
User avatar
krzysiobal
Posts: 1037
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: PRG-RAM decoding circuitry - problems

Post by krzysiobal »

I replaced the R+C+diode circuit with ordinary jumper and just added 1nf between WRAM-!CS and ground. No software modification was needed, everything works just fine - tested on dozen different famiclones, every single one works perfect. Removing R+C+diode made the clock circuit very stable, and now detecting A12 rises (MMC3) works just perfect and there is completely no shake at statusbar in any game. Clock circuit also is used for MMC1 to disable successive writes - it is also working without problems (thats how I found out that something is wrong - couple MMC1 games were not working right).

I can recommend good game for testing WRAM - Kid Icarus, because it writes non stop to E000-FFFF in order to switch banks and also uses SRAM at 6000-7FFF non stop. Single corruption makes this game hangs.

Also for those that don't believe that the WRAM corruption problem occurs - it does. My cartridge's menu was using 6000-7FFF as read buffer from SD card. When no 1 nf cap at SRAM !CE / no M2 delay circuitry was present, some letters in filenames read from SD card were overwritten.

Here is waveform of SRAM-!CE after adding 1nF cap - the spike is minimal and RAM does not react on it.
Image
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: PRG-RAM decoding circuitry - problems

Post by aquasnake »

For TTL output, a DRC circuit is required because TTL has strong low-level output and weak high-level output (with only one NPN transistor and pull-up resistor couples inside). To ensure a fast rising edge of SRAM_CE, a diode is needed to accelerate the jumping current.

For CMOS output, it has strong output at both high and low levels(with two internal MOSFETs), so whether it is pulled low or high, it has a strong driving strength (at least 8mA current), which can be solved with only one parallel capacitor.

For some low-power SRAMs, it is possible to simplify the circuit by only requiring decoupling capacitors. For example, the suffix is "BLL" series, but almost all FRAMs have high operating currents. Which means that their input impedance is small, and using external capacitor delay will largely fail.
Post Reply