Jump to content
IGNORED

Bank switching with a CPLD


jwiggams

Recommended Posts

Hey all,

 

I am working on a custom 8K bank switch (F8) cart, but am having issues getting games to boot. I have a heavy sixer and a junior, and while the game boots (but eventually crashes) on the sixer, it never boots or immediately crashes on the junior. I've been using Centipede for my tests, because the dancing Centipede is awesome.

 

Do these address lines require debouncing for me to properly check when the bank switch addresses are accessed? I figured I could do it without an external clock signal, as the CPLD has less than 10ns delay pin to pin, but even with buffering each pin internally in the CPLD (using an external clock to catch and buffer the data fast enough), I still can only get things kind-of working on the sixer...and not at all on the junior.

 

Does anyone have any experience in this area that might be able to shed some light on the issue?

 

Thanks!

  • Like 1
Link to comment
Share on other sites

You do need to debounce the address lines in the sense that you only react on an address, in case it is seen by the CPLD long enough. Since not all address bits are set synchronously, a single read from the CPLD can result in a more or less random address. It might already be different a few nanoseconds later. If you trigger a bankswitch on an address that has not yet stabilized, most definitely the cartridge will crash sooner or later. In general, everything on the bus (data or address) that you are going to use for bankswitching needs to stabilize before usage.

So you need to find a way in VHDL or Verilog (or however you program your CPLD) to realize some reliable timing. I tried a lot of things, but the only way that really worked for me was to connect an external oscillator to the CPLD. In case you ever want to support extra RAM, you will need an accurate timing anyway. All timing and delay mechanisms I tried failed, so I went with an external oscillator.

BTW: Don't waste your time with CPLD. You can better to this with a small microcontroller ... everybody is using microcontrollers now. Even Raspberry Pi is fast enough. CPLD are no longer needed if you ask me.

  • Like 2
Link to comment
Share on other sites

52 minutes ago, CPUWIZ said:

 

That would look weird, sticking out of a cartridge slot and isn't exactly a cheap solution, plus it is 3.3V level GPIO AFAIK. :P

Yes, true ... not looking good :)
But there are so many cheap little controllers now ...like Rasperry Pi Pico. 5$ and easy to interface ... levelshifters for the 3.3V are not a real problem, since you would need some interface PCB anyway.

Link to comment
Share on other sites

3 hours ago, Kroko said:

You do need to debounce the address lines in the sense that you only react on an address, in case it is seen by the CPLD long enough. Since not all address bits are set synchronously, a single read from the CPLD can result in a more or less random address. It might already be different a few nanoseconds later. If you trigger a bankswitch on an address that has not yet stabilized, most definitely the cartridge will crash sooner or later. In general, everything on the bus (data or address) that you are going to use for bankswitching needs to stabilize before usage.

So you need to find a way in VHDL or Verilog (or however you program your CPLD) to realize some reliable timing. I tried a lot of things, but the only way that really worked for me was to connect an external oscillator to the CPLD. In case you ever want to support extra RAM, you will need an accurate timing anyway. All timing and delay mechanisms I tried failed, so I went with an external oscillator.

BTW: Don't waste your time with CPLD. You can better to this with a small microcontroller ... everybody is using microcontrollers now. Even Raspberry Pi is fast enough. CPLD are no longer needed if you ask me.

Great info, thank you!

 

Did you have a recommendation on a good micro (not a Pi) that's fast enough for this? I figure a STM32 would probably work for the 72MHz or faster versions, but they're impossible to find right now due to parts shortages. I am pretty used to HDL, so FPGA/CPLD is usually my go-to hardware, but if a micro would work better I will at least check into it.

  • Like 1
Link to comment
Share on other sites

Micro seems like overkill, considering that bank-switching has been done for years with commodity, non-CPLD hardware.  Plus, the micro itself could emulate the entire machine and it just seems silly to relegate it to watching a few address lines.

 

The external clock and some shift registers which reset when they receive the "wrong" signal on a particular clock are probably the best you can manage.

  • Like 1
Link to comment
Share on other sites

7 hours ago, jwiggams said:

I am pretty used to HDL, so FPGA/CPLD is usually my go-to hardware, but if a micro would work better I will at least check into it.


It really depends on what you want to do in the end. Are you really only interested to have the 8K switching logic on a CPLD and nothing else ?

 

Link to comment
Share on other sites

8 hours ago, Kirmok said:

Why not use a simpler one SPLD like the PAL family ICs ?

I don't have a chip programmer that can program PALs, and I've never used them before. Doesn't make sense to dive into that when I've got more experience with CPLD or micro stuff, and when there are STM32 or STM8 micros that are more capable for similar pricing it doesn't make sense to me.

 

12 hours ago, ChildOfCv said:

Micro seems like overkill, considering that bank-switching has been done for years with commodity, non-CPLD hardware.

I had tried making a design I came across that used standard off-the-shelf ICs. Didn't work, though that may have just been not finding the right capacitor for cleaning the clock signal. It used a comparator, a flip flop and a couple of inverters. Or maybe 74HC series isn't what I should have tried, maybe should have tried to find the LS equivalent...or HCT maybe?

 

8 hours ago, Kroko said:


It really depends on what you want to do in the end. Are you really only interested to have the 8K switching logic on a CPLD and nothing else ?

 

It's just a hobby project, but I'd like to support RAM and larger games eventually. I don't need DPC or anything fancy, my CPLD doesn't have enough logic to handle all the fancy extras anyhow. This is my first look into Atari hardware so I figured the cartridge was a good place to start.

  • Like 1
Link to comment
Share on other sites

14 hours ago, jwiggams said:

I had tried making a design I came across that used standard off-the-shelf ICs. Didn't work, though that may have just been not finding the right capacitor for cleaning the clock signal. It used a comparator, a flip flop and a couple of inverters. Or maybe 74HC series isn't what I should have tried, maybe should have tried to find the LS equivalent...or HCT maybe?

HCT stands for "High Speed CMOS, TTL compatible" so yeah LS is the technology of the day for looking at asynchronous signals such as the cartridge addresses when you want to avoid false positives.  You may be able to make use of HC or HCT anyway by adding a resistor/capacitor network to the trigger output so that it requires at least *300ns of trigger output before you act on it.  If it's negative trigger, also put a forward biased diode across the resistor so that it can instantly recharge the capacitor.  So, maybe a 300 ohm resistor in series with the trigger output, 1nF cap to ground after the resistor, and a diode parallel with the resistor.

 

*I just chose 300ns because that's the minimum time between address valid and output data valid.  So it lets you bide your time to make sure it is REALLY addressing your chip.  But because there's 200ns of slack, it may also be a good idea to let your bank switcher use a level trigger to collect the data.

Link to comment
Share on other sites

22 hours ago, jwiggams said:

but I'd like to support RAM and larger games eventually

In that case do yourself a favor, spend an external quarz-oscillator and connect it to one of you CPLD inputs. I was using 10 MHz in the past. 10 Mhz is good enough for the kind of timing you need for external RAM.
This input can be used as input to some counter on the CPLD to get all kinds of differnt time delays between things that you want to detect on address or databus.
 

Link to comment
Share on other sites

  • 8 months later...

Regarding the delay, the Joe Grand - Pixels Past bankswitch cart uses a 100pF cap and a 2.2K resistor for approx. 220ns delay.  

 

It is a GAL based board.

 

The assembly instructions for that board call for a ATF20V8B-10PC-ND but Lattice GAL20V8B-10LP seem to work well.

 

In Joe's source for the equations, Joe also lists the Cypress PLDC20G10-25PC as a target device.  However, when I attempted to use instead a National GAL20V8-25LNC it did not work reliably.
 
Should it be possible to adjust the RC delay to accommodate the slower GAL or is that not an issue?  If so, is there a max for the delay beyond which it would be unreasonable to try?

 

 

Edited by SIO2
Wrong part name
Link to comment
Share on other sites

On 2/7/2022 at 9:33 AM, SIO2 said:

Regarding the delay, the Joe Grand - Pixels Past bankswitch cart uses a 100pF cap and a 2.2K resistor for approx. 220ns delay.  

 

It is a GAL based board.

 

The assembly instructions for that board call for a ATF20V8B-10PC-ND but Lattice GAL20V8B-10LP seem to work well.

 

In Joe's source for the equations, Joe also lists the Cypress PLDC20G10-25PC as a target device.  However, when I attempted to use instead a National GAL20V8-25LNC it did not work reliably.
 
Should it be possible to adjust the RC delay to accommodate the slower GAL or is that not an issue?  If so, is there a max for the delay beyond which it would be unreasonable to try?

Some devices just don't like the RC circuit and changing the values doesn't do much. I am not sure how the delay time was calculated but in practice it isn't always reliable from device to device, or even among devices with the same part number.

 

The reason is that the RC signal is not technically a "delay." The RC is fed into a clock which is triggered on a rising edge, not a logic level. The RC does not delay the start of the rise. It only changes the slope of the incoming clock.

 

I suspect that the behavior we see (a delay caused by changing the slope of the clock) is not actually defined on any specification of any device. In practice, on many devices, it does seem to translate into a delay, but clearly this does not work in all cases.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...