Flakey Kestrel 8K

[kc5tja]

Well, as indicated in the other Kestrel 8K thread, it's pretty flakey. And I'm trying to learn why that is.

Well, just today, I found that the fall-time on the ph2 clock was nearly instantaneous, but the *rise time* was a whopping 244ns!! According to my data sheet, the *maximum* slew delay for the clock is 5ns, period.

Also, I eliminated the latch-up problem by changing the IPL protocol so that R_W is *always* in write mode, and thus allowing me to remove the resistors from the data bus. That helped improve reliability a LOT, but it's still not perfect.

I just tried adding a 74LS08 gate (that's all I had available to me) to buffer the clock from the 555, which improved the timing to 28ns rise time. Still too slow. But at least it's a clean rise time. It didn't improve the reliability of the circuit though.

[wirehead]

Hmmm....

Somebody needs to stock up on crap.

Or at least attack some junkyard circuit boards with a paint stripper and/or chip puller...

I'm not sure what you've got in your parts bin.... There's gotta be a better way to do stuff than the 555.... I think a 555 is just "not meant" to drive a 65816, because the typical rise/fall is 100ns off of a datasheet I found. At the very least, use a 74xx14 which should give you cleaner switching properties. There's a lot of stuff going on around people using 74xC14 CMOS schmidt trigger inverters as oscillators for stuff. Or maybe use a "real" oscillator with a series of latches or counters as a clock divider.

One potential avenue for investigation if the WAI instruction thing is happening is to compare the bit patterns of the WAI with the instructions in your testing code. See if a bit being too high or too low might cause that to occur.

[kc5tja]

wirehead wrote:

Somebody needs to stock up on crap.

I don't have the cash to do something like that though. I need to build my inventory slowly, and on an as-needed basis. Very frustrating, because I have to wait 1 to 2 weeks for all my orders to come in.

Quote:

I'm not sure what you've got in your parts bin....

At this point, nothing. I do have a spare 74LS85 4-bit mag-comparator, but that's it.

Quote:

There's gotta be a better way to do stuff than the 555.... I think a 555 is just "not meant" to drive a 65816, because the typical rise/fall is 100ns off of a datasheet I found.

See, at 80kHz, I did not expect this to be an issue. But, it never occured to me that, with a part designed to run in excess of 10MHz, it will treat all signals as if you were driving them at those speeds.

Additionally, the introduction of flipflops to cut the frequency down will require HC or HCT logic, and those families cannot meet the 1V/ns slew rate that the 65816 needs (according to the data sheet). The only logic family that I've seen so far that can handle that kind of speed is the 74Fxx series, which has slew rates as fast as 0.6V/ns, which should be sufficient to meet the 65816's clock requirements, I'm thinking (since anything above 2.5V is pretty much considered high by CMOS standards).

Also, TTL-LS logic apparently cannot provide enough drive current for even one CMOS load. I cannot find the rise times for a 74LS08 or 74LS00, but I can say with certainty that it is NOT 1.5 microseconds. Nonetheless, the time it takes any signal to go from 0V to 5V is approximately in that ballpark. Now, granted, the signal does breach the 2V mark long before then. In fact, it often does so within the manufacturer's propegation delay specifications. Still, that seems shady to me, though, since 2V is kind of ambiguous as far as what logic level it represents to a CMOS circuit. The fall-times are, however, within nanoseconds. I'm thinking this is resulting in some pretty erratic RAM behavior, at the very least, which could account for the CPU executing instructions I never placed in there.

The time from Phase2 high to _OE or _WE low is 25ns, so that much seems to be working. But when _OE or _WE go high, since they're driven by TTL-LS logic, they tend to hang around the 2V mark for a bit. Can this be causing bus glitching?

[Wally Daniels]

wirehead wrote:

Hmmm....
Somebody needs to stock up on crap. ......8<.......
I'm not sure what you've got in your parts bin.... There's gotta be a better way to do stuff than the 555....
.

Money it seems is a limiting factor for most of us BUT you can consume
alot of time trying to track some of these problems down and never get
a staisfactory resolution.

One approach that has worked well for me in the area of Clock sources
is to use an inexpensive canned oscillator such as the Epson SG-531
series. I have used these on some of my 65C265 projects and they can
be swapped easily, and are availible from DigiKey. Buy a few at different
frequencies working your way up to where you would like your system to
operate. Use a dip socket, and swap them in as you like. No, these parts
are not the optimum, but will give you the confidence in your Clock source
to let troubleshoot from or concentrate on other ideas.

The 20 or 30 $ you may have to spend now will soon pay for itself !

Hang in there, Wally

[kc5tja]

Wally Daniels wrote:

operate. Use a dip socket, and swap them in as you like. No, these parts are not the optimum, but will give you the confidence in your Clock source to let troubleshoot from or concentrate on other ideas.

I have to disagree here. Because, staring at me, right now, on my oscilloscope display, is an image of the _WE signal on the RAM chip. I have the oscilloscope set to trigger on the falling edge of _WE. The bottom trace is _WE, and the top trace is R/W, coming directly from the CPU output. The display shows most of the legitimate writes to RAM. But some of them are not.

The results are in -- the RAM glitches are caused by the CPU itself. The R/W line periodically (but not always) stays low some 70ns after the rising edge of phase-2 during what should be a read-cycle, resulting in a 70ns _WE glitch when accessing RAM. The result: RAM corruption.

Now, the only possible cause I can think of for what could be causing this is the fact that the clock slew is too slow. The specifications clearly state 5ns maximum rise/fall times. The reality is it's more like 25ns. The result, I think is showing itself pretty well on the o'scope display now.

Quote:

Hang in there, Wally

Trust me. I wanted to build my own computer, a serious computer, for a long, long, long time now. This bit of detective work is frustrating to me, but in the end, I have a huge sense of accomplishment. Finding this _WE glitch is huge for me.

Because of this glitch, I cannot use any push instructions, and cannot perform a 16-bit write to random areas of the memory without causing major issues. The only writes that work are 16-bit writes to the VIA (since the RAM's _CS isn't asserted at this time, spurious _WEs don't matter), and 8-bit writes to RAM. The fact that even a simple, 8-bit PHA didn't work really lead me to believe the CPU was bad, and that's what prompted me to put the o'scope on R/W and _WE concurrently. Well, I don't think the CPU is bad; I think the clock source is bad, and a 25ns tR/tF is the #1 culprit, I fear.

Time to get those 74F00s.

[GARTHWILSON]

Quote:

The R/W line periodically (but not always) stays low some 70ns after the rising edge of phase-2 during what should be a read-cycle, resulting in a 70ns _WE glitch when accessing RAM.

I seem to have missed this whole topic, over a year ago. 70ns is way more than a glitch. But the above does make me ask why you didn't disable the RAM-- at least the writing-- anytime phase 2 is low. You wouldn't want to enable RAM-writing as soon as it goes up either, since the address is not guaranteed to be valid and stable before R/W\ drops, so you have to wait for phase 2 anyway.

[kc5tja]

RAM *is* disabled when phase-2 is low. But remember that there were propegation delays and a slow slew rate, so the NAND gates involved didn't turn off until some 10 to 15ns after phase-2 goes low -- plenty of time for RAM corruption.

The problem behind everything turned out to be the phase-2 clock itself -- it had a 10ns or 15ns slew rate. The spec sheet calls for 5ns -- *rediculously* logic would need to be used. Fortunately, most clock oscillator cans come with 5ns slew rates or better. This solved all the hardware-related problems I had.

[GARTHWILSON]

Quote:

RAM *is* disabled when phase-2 is low. But remember that there were propegation delays and a slow slew rate, so the NAND gates involved didn't turn off until some 10 to 15ns after phase-2 goes low -- plenty of time for RAM corruption.

The write data and the address are guaranteed to be held for at least 10ns after phase 2 falls, and I expect bus capacitance would hold it considerably longer. Are the circuit schematics and photographs on a webpage right now? I still tend to think you probably had another problem which, when the rise and fall times weren't super fast, pushed it over the edge. IOW, bringing the rise and falls times down got it just barely into the working range, but that there would be a lot more safety margin if the other problem didn't exist.

[kc5tja]

http://www.falvotech.com/content/kestrel/1p3/

[GARTHWILSON]

I don't see any problem with the schematic (as I'm sure you expected), but now I remember the solderless plug-in breadboard. That's how I made my first 65c02 computer, but with much slower parts. That kind of construction, with the tall loops putting loads of inductance in the wires, plus the capacitance between adjacent rows in the boards, makes for a load of ringing on fast edges. Couple that into a slow rise-time clock on a fast input, and the changes of state from the ringing will cause problems.

Bob Pease, a respected electronics industry guru wrote a short article a few years ago called, if I remember the name correctly, "What's All This SMWISIC Stuff, Anyhow?" (SMWISIC="show me where it says I can't), referring to the problems people have when breadboarding things that are too fast to operate that way because of all the parasitic circuit elements that get into the picture that aren't on the schematic. I hope I kept the article, but so far I haven't thought of the right place to look. That's the trouble with some of these-- what to file them under so you can find them again.

[leeeeee]

http://www.national.com/rap/Story/0,1562,8,00.html

Lee.

[GARTHWILSON]

Doggone-- over 15 years ago! I guess I had permission to forget a few details then. Thanks Lee.