It is currently Thu Aug 17, 2017 1:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Thu Apr 27, 2017 7:27 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 173
Location: Poland
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?


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 8:09 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6027
Location: Seattle
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?


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 9:54 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1859
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 11:37 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7144
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Thu Apr 27, 2017 11:49 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6027
Location: Seattle
... 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.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 1:05 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7144
Location: Chexbres, VD, Switzerland
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 :(


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 2:52 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 173
Location: Poland
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.


Top
 Profile  
 
PostPosted: Fri Apr 28, 2017 3:15 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 173
Location: Poland
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group