6502.org

I have designed my CS/A computer with a BIOS board that can contain RAM chips of various sizes. So I could either use 32k RAM, or even up to 512k RAM.

While doing some testing using this BIOS board I found that with a 32k RAM chip that system is rock stable, while with a 512k RAM chip that system has stability issues.

I did not do an elaborate memory test (need to write on before I can do that) but the issue shows that a Commodore BASIC loop (running from the ROM) breaks with strange "SYNTAX", or other errors.
Issues are the same when running with either 1MHz or 2MHz CPU / Bus clock. Also I have two of the 512k RAM chips, both show the issue, and both have been bought new (and not salvaged elsewhere)

The board is here:
http://www.6502.org/users/andre/csa/bios/index.html (board version 3.0B) and the RAM chips I am using are BS62LV4006PIP55 (512k RAM),
and GM76C256ALL-70 (32k)

The first thing I found is that the 512k RAM chips datasheet states that "Ax must be stable when /WE is low" - even when /CS is not asserted! The board does not do this, so I added PHI2 to the /WE signal, but it did not help (I could actually add the actual /CS to /WE so non-selected writes keep /WE high but I am not inclined to believe that this is an issue)

The second thing I thought was that it might be pulling too much power. I found that the RAM ICs actually driven by a 3.6V power source to keep the content during shutdown. I moved the power supply (for the 512k variant on pin 32) directly to 5V VCC. This made the system a lot more stable, but the issues are still there.

I am wondering what the differences between these two chips are that make that difference here...

Both are CMOS, but CMOS output even at 3.6V supply should easily pull up to TTL levels - see the stable 32k chip.
I'll probably add another bypass capacitor, or replace the ceramic disk one with an MLC.

The actual testing I can do with the 32k chip, but I'd still like to know what happens here or I cannot use these 512k chips in my designs.

Thanks for any help
André

Both your 32Kx8 and 512Kx8 SRAMs use industry standard PDIP pinouts. If the slower 32Kx8 works, you should be safe not having to worry about timing issues when using the faster 512Kx8, especially at 1-2MHz CPU speeds.

Your 512Kx8 does seem to take close to 6x more power comparatively. I would scope out or measure your VCC on the 512Kx8, and compare to 32Kx8.

How are you banking your A16-A18? Maybe you need to hardwire first to eliminate another variable...

Do you use power planes on your PCB's?

chip speed? I found that 150 gets flaky, -70 works fine on a 4 MHz 65C02.

By any chance, could you provide a link to the 512K SRAM's data sheet? Perhaps one of us might spot something about the SRAM's operation that could explain the apparent corruption problem.

Andre,
I looked closer at the.jpg of your board and I can clearly see through the other side, so you have no ground/power planes (which may not be a problem yet). This is also seen in your .png board layout. Those traces are very thin. I ran into a very similar (noise) problem that held me up from progressing on a project for almost a year. I was troubleshooting everything except power connections, because heck I knew power and ground were getting to each IC. But I was using 30AWG wire (very close I bet to your land width) for power and ground to ~15 IC's, mostly LSTTL.

I'll bet that if you solder thicker gauge wire for ALL your power and ground connections, your problems will end.

Good luck!

edit: clarification

Even though the current draw might not be an issue with real thin traces, reactive effects may be causing transient generation on the Vcc and ground traces. As suggested, maybe Andre might get a fix by soldering some 22AWG hook-up wire in for the Vcc and ground paths. I presume he's bypassed the heck out of everything as well. I'm using a 128k x 8 SRAM in my POC design and it works flawlessly with a 100 ns machine cycle time. My board is four-layer, so that may be a factor.

Hi André,

Have you considered replacing the 74LSxx chips with 74HCxx chips? The logic being since the CPU and memory are CMOS, its best to have the glue logic CMOS also.

Purhaps a scope could tell you if the logic high's are high enough for the CMOS memories. It might be operating right on the edge 2.1 - 2.2 Vdd.

Just my thoughts. Hope you can find the answer.

Daryl

Just a quick update:

- my scope is not good enough to really measure problems on the supply lines (an old all-tubes Tektronix I got cheap on a garage sale more than 20 yrs ago...)

- I soldered an MLC bypass cap directly between pins 16 (GND) and 32 (VCC) to hopefully stabilize the power supply, but did not help
[Edit: I also soldered direct traces from the board's bus power supply pins to the chip's power supply pins, but this also did not help]

- Not there are no power planes, and not even thicker power supply traces (as I now do on all newer designs - this board is from 2004)

- Next is I ordered replacement chips of a (hopefully) different type. All of the 5 512k RAM I currently have are of that same type. Sometimes you order a "622512" and get a "624006" or so.

- And yes, as the RAM chip is able to run at 3.3 and 5V, I got the idea that the inputs might be CMOS-style, not TTL-style, and might be acting up on the TTL address and data lines. I'll try to check that with replacing the bus drivers on the CPU board with HCT types

- Another idea was that the output drivers of the RAM IC are not strong enough, as they have to drive the full bus (no driver between RAM and bus), which includes a passive backplane (with no termination resistors or such like - forgive me, the bus design is from 1989 :-)
That's also why I ordered replacement chips.

- the datasheet for the 512k RAM chips should be here: http://www.digchip.com/datasheets/parts ... 06-pdf.php

André

Even better would be 74ABT where possible.

I've replaced the address bus drivers on the CPU board with 74HCT245 (before they were 74ALS245). The system is running the basic test - but after about 1.5h it has the first error. This is better than the about 30-60min that were required for an error before that.

With the 32k chip I've run up to about 4h without problem, multiple test runs, total maybe over 10h without any problem.

I couldn't replace the data bus driver, as this one is soldered in (under the CPU) in the board I currently use.

Although ... I have two older versions of the CPU board (one even with a completely manual layout and lots of extra wires :-), maybe I can test with one of those if I still get them to work. Or my 65816 CPU board - but that runs the bus at 1MHz only... And I found more 32k RAM chips from different vendors, maybe I'll test them too. Unfortunately these tests all take their time...

André

A couple of things come to mind, in no particular order:

1 ) Defective 512k SRAM.

2 ) Temperature rise, which could explain why the circuit runs for a relatively long time before errors start. Try cooling the SRAM when the circuit starts acting up.

3 ) Attempting to read/write the SRAM before Ø2 goes high.

4 ) Some kind of decoding error that occurs only with certain addresses.

5 ) Not asserting /CS as soon as A0-A15 become valid. It's possible that if /CS isn't asserted until Ø2 goes high, the SRAM may not be "opening" D0-D7 until late in the bus cycle.

6 ) Asserting /WE or /OE before /CS. Most literature I've read implies that it's never safe to assume that a chip will correctly behave if /WE and/or /OE are low before /CS is brought low.

7 ) Lazy control signal transitions due to capacitive loading.

8 ) "Dirty" Ø2 waveform. CMOS version of the MPU are somewhat fussy about Ø2 rise/fall time.

9 ) Crosstalk between board layers.

10 ) Too much prop delay in the glue logic.

Perhaps it's time for you to invest in a new(er) 'scope to help you solve this mystery.

Thanks for your comments. Some things I've already thought about, see my comments.
I've tested two different RAM chips, both of the same type though. I ordered a (hopefully different type) replacement, which already is in the mail. IIRC one of the original tests were with an improvised heater - a 100W light bulb close to the boards lighting them, but I'll probably do them again. Nevertheless, the boards have no case, and after an hour (or even 30min) I'd expect the board to reach a steady state) /CS is gated with phi2 The MMU I use in the CPU board is set such that all A16-A18 are low. I've also replaced the MMU in some tests, but no change. That is interesting. In my understanding the RAM internal control logically "and" the CS, OE and WE lines appropriately so it does not matter which one is first. The 32k RAM chips never cared. In the board I have in fact gated /CS with phi2, and only now also gated /WE with phi2. I'll try to change that to directly use /CS (and possibly gate /OE with phi2) instead.

How does your comment 5) here actually go together with 3)? When Ax become valid, it's some time before phi2 goes high actually.

Do you have any links to the literature you mention? Normally I'd say no problem with 1MHz or even 2MHz, but signal edges have much higher frequencies in them, esp. with faster logic chips.
What makes me wonder, though, that the 32k RAM chip uses the same control signals and works. Could very well be the case, although, again, the (slower!) 32k RAM chip works. The same symptoms appear in 1MHz and 2MHz, so if it's that it could only be on the falling edge of phi2 - but again, the 32k RAM works. It's on my wishlist (actually for some time now) but the qualitative results I still get with it have helped me enough so far. In winter it's also a nice additional heating - only in summer it's too hot to use ;-)

Currently an older CPU board with all drivers (even data bus) being 74HCT245 is running for over an hour without fault. I'll still have to check though if this board also produces the error when I use (A)LS type ICs instead.

André

Some updates and corrections...

First the old CPU board was not running with all 'HCT style, but with all 'LS, only the data bus driver was a 'HCT one - and it was running ok as described. Then I changed to the very same chip types as in the failing situation, i.e. all 'ALS245 drivers, except for the data bus driver, which is an 'LS type (the one that's soldered in). This one was also actually running almost two hours without problem. The old board (CSA-CPU V1.2A) was routed and printed out many years ago on an Atari ST, and "manually" etched, i.e. soldered from both sides to get the through-connections and so on. The main difference concerning the current problem seems to be that the traces are much thicker...

So I checked the failing CPU board (CSA_CPU V2.0G) and found that the board is actually horrible in terms of power supply traces and nets. GND was actually a tree instead of a net, and all power supply lines had the same .01 thickness as the signal lines. The currently published version (2.0H) at least has the power supply lines with 0.016 width - but I should really add a note to the web page about that. The current (not yet published) version 2.0J is much better in that respect, but could surely be improved as well.

Anyway, I've added some additional power supply wires to the cpu board to add strategic connections to the existing power supply, and have started a new test. Note sure if I can give a result today, as it's getting late here.

André

I'd try circuit cool on the SRAM just for grins to see if it affects it. Yuh never know.
That could be part of your problem. See below.
I'd gate both /OE and /WE only when Ø2 is high, as that is the only time D0-D7 are guaranteed to be valid.
In examining the timing diagrams of the 512k SRAM you are using, it appears that most reliable operation will be achieved when /CS is asserted before /OE or /WE. The data sheet doesn't specifically indicate what the setup time will be if /OE or /WE are low before /CS. That is, chip behavior really isn't defined if /CS is asserted after /OE or /WE.

Way back when I was in school (Nixon was US president back then), we were taught to assert the chip select as soon as the address bus became valid, which on a 65xx MPU, occurs part way through Ø2 low. With the 65xx, by the time Ø2 goes high, the device should be ready for access, and you can gate /OE or /WS as soon as Ø2 is high. That gives you the earliest possible access to the device, which technique I was able to prove to my satisfaction on my POC design.

Disregarding I/O device access, any area of SRAM on the POC unit can be reliably addressed at a 20 MHz Ø2 (I'm using 74ABT logic), indicating that the /CS before /OE or /WE sequence (with /CS asserted while Ø2 is low) works.
By literature, I mean data sheets and application notes. I've also inferred some of the above from empirical bench work (my scope's only tube is the CRT ).
Different part, much smaller row/column decoding, ergo probably faster internal logic.
Again, differ part and probably not as fussy.

Ceramic discs are not very good for this. Use a monolithic ceramic X7R (no 5's as in Z5U, Y5V, etc.). Still, if it works for the 32K, it should work for the 512K, if the connections between the capacitor and the SRAM are just as short.

My best guess (which is probably not very good) is that if the 32K 70ns ones work and the 512K 55ns ones have problems, the latter with probably faster slew rates is a little beyond the design of the board which has no ground plane, causing ground bounce that messes up the reference; ie, ground is no longer ground. My workbench computer has no ground plane and is wire-wrapped and it works with 55ns SRAM, with power and ground distributed from the center in a star. Next time I'll have faster parts and definitely go for the ground plane and maybe a power plane too though.
Unlike the processor, there's nothing in the memory that's edge-triggered. It's all level-sensitive; so the edges shouldn't matter there, as long as setup and hold times aren't violated.