So, based on a recent post and finding some odd issues with certain CF Cards, I decided to start a new thread on this topic.

Background: My C02 Pocket SBC is a 6 MHz W65C02 with 32KB RAM/ROM and a NXP SCC2691 UART. It uses an Atmel AT22V10CQZ single glue chip for address decoding for RAM/RAM, I/O and qualified read and write signals. The PLD is rated at 20ns, which should be fine for a 6 MHz clock rate.

Add in my later designed adapter which adds a Maxim DS1511 RTC and an IDE interface with a 16-bit data port based on a pair of 74AC573 latches. It works fine... and I've managed a custom build of Richard Leary's DOS/65 running on it. However, I found certain CF Cards either wouldn't work at all or wouldn't work properly, but could never quite figure out the issue.... but never really dug deep into the issue either.

Next... moving to 3.3V, which is where this thread gets it's start from (viewtopic.php?f=4&t=6722#p86843)

Alliance discontinued the 70ns SRAM I used in the C02 Pocket, but they have a 55ns version, so picked up a few. Oddly, this RAM chip would not work in the C02 Pocket, simply dead on power up. While I was doing some initial testing to get a SC28L92 DUART in place of the SCC2691, I decided to swap out the PLD with an Atmel AT22V10C, which is rated at 15ns. I also have the 55ns SRAM in and connected the RTC/CF Card adapter and made a few minor changes to get DOS/65 running. I was also to kick the CPU clock up to 10 MHz without issue. Just for giggles, I decided to pop in the other CF Cards that never worked before and found that they worked perfectly fine... hence the decision to investigate more and create this thread.

In short, just swapping out the ATF22V10CQZ (which is rated at 20ns) to the ATF22V10C (rated at 15ns) allowed both the 55ns Alliance SRAM to function "and" the other Compact Flash cards which didn't before... hence the topic for this post. I've done some additional testing and it's consistent... the faster PLD timing resolves the issues for the non-working CF Cards found earlier and the recent perplexing find that the same SRAM part number with a 55ns (vs the older 70ns part) now working... who knew!

So, turns out that 5ns really can be a make or break in a 6 MHz system. I also dropped the clock rate to 4 MHz and it still didn't work with the 55ns SRAM part. So I have to believe that it's more than the 5ns timing spec difference. In any case, I'll be swapping out all of ATF-xxxxx-CQZ parts for standard ones.

Not sure if anyone else has fallen into some odd hardware issues using PLDs, but figured this was worth posting, mostly as an FYI, hope it helps someone.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Is there a possibility that your glue logic can cause a glitch on some output, and a slightly faster part produces no glitch, or possibly a glitch too short to cause a malfunction?

The two problem areas I've observed regarding compact flash implementation in retrocomputing are:
1. Insufficient setup time from Address-and-chip-select valid to read or write strobe asserted. The spec calls for 25nS setup, but some CF disks can tolerate 0nS; few can even tolerate negative setup time. Smaller the setup time, fewer brands of CF will work.
2. Data-dependent noise that affects the CF read strobe and causes spurious read of CF data FIFO resulting in data loss.

Issue 1 can be determined by looking at the decoding logic of CF interface. Issue 2 is PC board layout dependent, but source terminating resistors for data lines and noise filter for CF read strobe are helpful.
Bill

The "zero power" features of the CQZ version might also be worth investigating. Could possibly be those, rather than the difference in speed rating?

First, thanks for all of the replies.... it is an interesting problem.

It's seems more basic related to the CQZ version of the PLD... if I only have the base Pocket SBC (no RTC/CF-Card adapter attached), there's still a problem. Swapping from the 70ns to 50ns Alliance memory fails, the SBC is dead. I've even tried several different Pocket SBC boards and several different 55ns SRAM chips... it's consistent, it always fails. Replace the CQZ version with the standard C version of the PLD and the problem goes away.

Here's the source for the PLD code. I've used this same source for the ATF750CL, the ATF22V10C and the ATF22V10CQZ. Only the CQZ chip has the issue, so I'm also thinking it likely is related to the "zero power" feature of that version.



Perhaps there is some code option in WinCUPL to compensate for the CQZ version, or the simple fact is, it shouldn't be used in this particular application for some odd reason.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I found some other Atmel documentation regarding their PLDs... some interesting content regarding their "Z" (zero power) devices and selection of decoupling capacitors.




Page 8 in the first doc talks to the "Z" devices and decoupling... and references the second doc for selecting caps. In short, they recommend a 0.22uF decoupling cap.

I'll try adding an additional cap on the PLD and see if it makes any difference. I've got over a dozen decoupling caps on the small PCB now, but only a single 0.1uF directly on every chip.

_________________
Regards, KM
https://github.com/floobydust