POC Computer Version One

[Dr Jefyll]

BigDumbDinosaur wrote:

BTW, you're misunderstanding my interest in the RDY circuit. It has nothing to do with POC V1.2's speed limitations.

OK, I wondered about that. Thanks for mentioning.

As for suggestions, the first thing, as already noted, is to ensure the ROM and RTC chip-selects go low early enough to provide some setup time for the stretcher circuit.

Next, is it possible that accesses to the DUARTs ought to have stretching? I kind of forgot about them, focusing on the ROM and RTC instead! If you change your bodge wires as shown below then everything -- all devices except RAM -- will get stretched by four extra 2XCLK periods. That's overkill, of course, but it may answer the question about the DUARTs.

Later if we're still stumped, or have gained some ground but then hit another ceiling, it might be good to consider taking Phi2 from Q2 or Q1 of the '163 rather than Q3. As you know, I talk about this in my original post in the addendum.

Right now a stretched cycle get extended quite a bit (2 or 4 extra periods of the 2XCLK), but all the stretch is applied to the Phi2-high portion at the end of the cycle. The Phi2-low portion at the start of the cycle isn't being stretched at all; it's still only 2 periods of the 2XCLK. That may be insufficient for some devices now that you're running faster oscillators. If so, the remedy is to extend the Phi2-low portion of the cycle, which in turn means the device gets a longer period of stable address (register select) before /RD or /WR goes low.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

As for suggestions, the first thing, as already noted, is to ensure the ROM and RTC chip-selects go low early enough to provide some setup time for the stretcher circuit.

That they do. All chip selects are generated as soon as VDA and/or VPA become true. All devices are selected within two gate delays after the address bus becomes valid.

Quote:

Next, is it possible that accesses to the DUARTs ought to have stretching? I kind of forgot about them, focusing on the ROM and RTC instead!

I think I mentioned a few posts back that I had monkey-rigged DUART #1 (console channel DUART) to be wait-stated. That enabled the unit to boot at 15 MHz and achieve stable operation. 20 MHz was a no-go, however, which is something I plan to investigate with the NOP ROM.

Quote:

If you change your bodge wires as shown below then everything -- all devices except RAM -- will get stretched by four extra 2XCLK periods. That's overkill, of course, but it may answer the question about the DUARTs.

Yep! We should soon know.

[BigDumbDinosaur]

Dr Jefyll wrote:

Next, is it possible that accesses to the DUARTs ought to have stretching? I kind of forgot about them, focusing on the ROM and RTC instead! If you change your bodge wires as shown below then everything -- all devices except RAM -- will get stretched by four extra 2XCLK periods. That's overkill, of course, but it may answer the question about the DUARTs.

Yet Another Bodge

I made the above change per Jeff's suggestion, but bodge-wired it to generate one wait-state instead of two when accessing any I/O or ROM. I went that route because I already knew the system was stable at 12.5 MHz. With this change, POC V1.2 is able to POST and run normally at 20 MHz.

After butchering up the hardware, I hooked up the logic analyzer and capture some traces.

Executing LDA $8000 at 20 MHz

In the above, the 65C816 is executing LDA $8000 out of RAM. Prior to that instruction being executed the data bank (DB) was set to $06 so I could see when the bank bits are emitted immediately before the actual data fetch occurred. Operating conditions were Vcc=5.08 volts and the room temperature was 74° F. Prior to capturing this data, I set the logic analyzer to a 500 MHz sample rate, which produces a ±1 nanosecond resolution, the finest resolution available. The timing marks at the top of the graphic are at 4ns intervals. An artifact of the 2ns limit is the logic analyzer thinks the Ø2 clock is asymmetric. So take the above numbers with a small grain of salt.

What is clear from the above is there appears to be a small period of dead time after the '816 turns around the data bus following the emission of the bank address. That is one of the areas where the potential for data bus contention may arise. Also note that 12ns elapse after the fall of Ø2 before the '816 emits the bank address. That is the time a device that was driving the data bus before the fall of the clock has to get off the bus before contention will arise. Measuring some of the intervals displayed by the logic analyzer indicates that /RD is deasserted 6ns after the fall of Ø2, which reflects the prop time of the NAND gate that uses this signal along with RWB to drive /RD. When added to the RAM's response time to the rise of /OE, which has a worst-case value of 6ns, it appears the RAM gets off the bus just in the nick of time. This is a 12ns RAM, so some gain could be had with a faster part. However, the contention issue in this circuit would only arise if all parts concerned were running at the weak end of their specs.

Something else worth noting is the '816 is performing substantially better than what the data sheet indicates it should do. Firstly, I've got it overclocked by 6 MHz and it's running fine. Secondly, the above logic capture shows that even at 20 MHz, there is still a bit of timing headroom left. And don't forget I'm doing this with discrete logic, not a PLD, which means cascaded prop times are involved.

It would be nice if WDC would do a thorough job of sampling production parts with an eye to promulgating more accurate performance data. I suspect the 65C02 with its less complicated architecture and simpler bus protocol, would be even faster.

Incidentally, when I first started with the POC series my goal was to achieve stable operation at 8 MHz. Guess I met that goal.

[BigEd]

Thanks BDD, that's another nice job of measuring what's going on. I wonder, do you happen to have a second '816 - preferably bought at a different time - to see if there's any part-to-part variation visible?

[BigDumbDinosaur]

BigEd wrote:

Thanks BDD, that's another nice job of measuring what's going on. I wonder, do you happen to have a second '816 - preferably bought at a different time - to see if there's any part-to-part variation visible?

Actually, I have an older 0.8µ part that is still in POC V1.0 (the MPU in V1.2 is a .6µ part). I'll dig it up and give it a try. I wouldn't be surprised, though, if the unit failed to POST at 20 MHz.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

BigEd wrote:

Thanks BDD, that's another nice job of measuring what's going on. I wonder, do you happen to have a second '816 - preferably bought at a different time - to see if there's any part-to-part variation visible?

Actually, I have an older 0.8µ part that is still in POC V1.0 (the MPU in V1.2 is a 0.6µ part). I'll dig it up and give it a try. I wouldn't be surprised, though, if the unit failed to POST at 20 MHz.

Well, as suggested by Ed, I tested with the 0.8µ 65C816.

However, I first ran POC V1.2 "under load," using the 0.6µ 65C816 that I installed when I built the unit. Normally, when the computer is waiting for input, it loops on a WAI instruction. Each time an IRQ occurs, WAI is terminated and the monitor input function makes a BIOS API call for input from the console channel. If there is none, the MPU sleeps again on WAI. Since WAI stops the internal clock, the MPU is not running in between interrupts, which means it's using only microwatts. The below code forces the MPU to run flat out.

Code: Select all

         rep #%00010000        ;16-bit index registers
         ldx #$0000
         txy
;
loop     inx
         bne loop
;
         iny
         bne loop
;
         brk

With the 0.6µ part installed, V1.2 will run the above code at 20 MHz, taking a bit under 18 minutes to complete. I ran this test several times to get a baseline time to completion. As it was running, I took the MPU's temperature using the highly scientific method of placing the back of my little finger on the MPU. It was slightly warm to the touch. In normal use where the computer is waiting on typed input, the MPU feels cool.

With that done, I replaced the 0.6µ '816 with a 0.8µ part salvaged out of POC V1.0. The computer would not POST at 20 MHz with that MPU and inspection with a logic probe showed no MPU activity of any kind. I had a Ø2 clock signal, but none of the MPU's outputs showed activity.

Next, I reduced Ø2 to 16 MHz. V1.2 POSTed and seemed to be operating okay, so I ran the above code again. About 10 minutes into it the machine went south, vomiting all over the console screen. The IRQ "heart beat" indicator was on at full brightness, which meant the MPU was no longer processing IRQs. A temperature check showed that the MPU was warmer than the 0.6µ part was when running the test code at 20 MHz.

So once again, I slowed down the clock, this time to 14 MHz. V1.2 POSTed and issuing several different monitor commands suggested operation was normal. I again ran the above test code. This time it was completed without error. So I ran it twice more in succession and during the final pass, checked the MPU's temperature. It seemed to be about the same as that of the 0.6µ '816 running the test code at 20 MHz. Processing time for the final test code run was a hair under 26 minutes, an increase that was almost in exact proportion to the decrease in clock speed.

Lacking the means to accurately take the MPU's temperature while working on the test code, I can't say with any certainty that the crash of the 0.8µ MPU at 16 MHz was thermally-induced. However, the smaller geometry of the 0.6µ '816 certainly has to be helping in supporting higher clock speeds. So it may well turn out to be a thermal problem.

[Dr Jefyll]

Interesting to see the contrast between the 0.6µ part and the 0.8µ part, BDD. For the sake of any of us who'd like to identify 816's in their possession, perhaps you could mention how the markings on the 0.6µ and 0.8µ chips differ -- thanks.

As for the Logic Analyzer traces, they're intriguing and also somewhat confounding, given that their interpretation has some potential pitfalls which I'll mention briefly for anyone who's interested. The LA display shows waves with crisp, instantaneous transitions, but we know that's not the reality. In fact, the voltages take some time to ramp up and down.

So, here are some pitfalls to remember:

1. the transition is already well under way before it's recognized by the LA.
2. the actual time of recognition will vary somewhat, depending on what voltage the LA manufacturer has chosen as the threshold.
3. as BDD noted, timing resolution is limited because samples are taken only every 2 ns.

BigDumbDinosaur wrote:

An artifact of the 2ns limit is the logic analyzer thinks the Ø2 clock is asymmetric.

I agree the trace depicts Ø2 as being asymmetric, but (c) isn't the only possible cause -- (b) is just as plausible, if not more so.

BigDumbDinosaur wrote:

there appears to be a small period of dead time after the '816 turns around the data bus following the emission of the bank address

Are you talking about the brief period around T+148ns when the value 000 (binary) is sandwiched between the initial value of 110 and the final value of 001? The seeming dead time is only an artefact.

Below the excerpt from BDD's diagram I've redrawn the D2, D1 and D0 traces, superimposing (in purple) a coarse suggestion of the actual voltages. Per point (a), the transition is already well under way before it's recognized by the LA. And here's the wrinkle. Per point (b), the LA's threshold can cause falling transitions to be detected sooner than rising transitions. (Also the memory chip itself may be stronger pulling low than pulling high.) That's why the bus seems to change from 110 to 000, then from 000 to 001. But really it's just the unfolding of a single event. All the lines began their transition at the same time. And the transition was simply from 110 to 001.

BigDumbDinosaur wrote:

[regarding the contention issue] it appears the RAM gets off the bus just in the nick of time.

Again I'm not sure when is the event you mention, but I do see an event that shows cause for concern.

Unless I'm missing something, at T+8ns the RAM plainly doesn't get off the bus in time.

We see the bus lines change from 101 to 000, which must surely be the CPU's doing. But /RD is still low, which means RAM hasn't yet been told let go. RAM and the CPU are in contention, and it appears the CPU's stronger drivers won at least a partial victory... enough to cross the LA threshold, that is. (An oscilloscope would likely reveal indeterminate voltages, neither solidly high nor low.)

Quote:

I took the MPU's temperature using the highly scientific method of placing the back of my little finger on the MPU.

Right -- got it! That's called a Digital Wattmeter, I hope you know!

Anyway, it would be interesting to know how much of the MPU temperature rise can be attributed to contention. (The RAM will get some heating, too.) Luckily none of this is serious enough to crash the system. But there'll certainly be some added noise (current spikes) on the power rails and data bus lines.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

Interesting to see the contrast between the 0.6µ part and the 0.8µ part, BDD. For the sake of any of us who'd like to identify 816's in their possession, perhaps you could mention how the markings on the 0.6µ and 0.8µ chips differ -- thanks.

I suppose I should.

• W65C816S6TPLG-14
  
  W65 -- Western Design Center designator
  816 -- Product
  S -- Static core
  6 -- process geometry, 0.6µ in this example; 8 would be 0.8µ
  T -- Foundry that produced the die, TSMC in this example
  PL -- Package type, PLCC-44 in this example; others are P (PDIP) or Q (QFP44)
  G -- RoHS compliant
  14 -- Maximum officially supported clock speed in MHz

There will also be a date code. The combination of process geometry, speed designation and production date can be used to help determine if a device is genuine or counterfeit.

Quote:

The LA display shows waves with, crisp instantaneous transitions, but we know that's not the reality. In fact, the voltages take time to ramp up and down.

Yep! Typical output rise and fall times for 74AC parts are extremely short, well down in the single digit nanosecond range. But they aren't instantaneous. The logic analyzer has an adjustable voltage threshold which when crossed, constitutes a logic 1 (rising edge) or logic 0 (falling edge). There's no in-between and relatively little hysteresis (see manufacturer's specs further down).

Quote:

So, here are some pitfalls to remember:

1. the transition is already well under way before it's recognized by the LA.
2. the actual time of recognition will vary somewhat, depending on what voltage the LA manufacturer has chosen as the threshold.

The threshold voltage can be set. I used 2.5 volts in my testing, since excepting the output of the SRAM and EPROM, everything is CMOS levels. The SRAM produces TTL levels, with a logic 1 defined as 2.4 volts minimum. In practice, that can be up over 3 volts, but not up to a CMOS logic 1 level.

It's patent that I could alter the apparent timings by changing the transition voltage to something else. However, I'm sticking with 2.5 for now, since most CMOS devices can go rail-to-rail when lightly loaded.

At this point, it is appropriate to note that despite what the data sheet says, the 65C816's inputs clearly recognize TTL levels. Scoped samples of data bus activity taken from POC V1.1 running at 12.5 MHz a few years ago showed that a logic 1 did not make it past 2.6 volts in the roughly 30ns that the SRAM was driving the bus. That is well short of the minimum logic 1 voltage (VDD × 0.8 ) specified in the data sheet. If that spec were true, the computer would not be functional.

Quote:

• as BDD noted, timing resolution is limited because samples are taken only every 2 ns.

Considering that Ø2 in this run was 20 MHz, that gave me 25 samples per machine cycle, which is good enough to get a reasonable picture of what is going on.

Quote:

BigDumbDinosaur wrote:

An artifact of the 2ns limit is the logic analyzer thinks the Ø2 clock is asymmetric.

I agree the trace depicts Ø2 as being asymmetric, but (c) isn't the only possible cause -- (b) is just as plausible, if not more so.

That could probably be determined by switching to a clock rate whose half-cycle time is a even number. However, given the manufacturer's claim for voltage threshold resolution (below), I'm more inclined to think it's a limitation of the 2ns resolution. The best the LA can do is 12.5 samples/half cycle at 20 MHz. So it's gonna have to fudge one way or the other.

Quote:

BigDumbDinosaur wrote:

there appears to be a small period of dead time after the '816 turns around the data bus following the emission of the bank address

Are you talking about the brief period around T+148ns when the value 000 (binary) is sandwiched between the initial value of 110 and the final value of 001? The seeming dead time is only an artefact.

N.B., the %001 value is the output from the SRAM—I poked that value into location $008000 before running the test code and capturing activity. The %110 right before it is the bank address ($06).

The %000 in between the bank address and the data is what I thought might be some dead time. You really can't tell if the MPU is driving the bus at that point or if it is floating. I'm pretty sure that the SRAM is not driving it, basing that assumption on the SRAM's timing specs. The SRAM appears to be driving the data bus right around when the data sheet specs would suggest. which is 6-or-so nanoseconds after /RD goes low.

Quote:

Per point (b), the LA's threshold can cause falling transitions to be detected sooner than rising transitions.

Some interesting specifications claimed by the LA's manufacturer:

• Threshold accuracy: +/-(100mV + 5% of setting)
• Channel to channel skew: 0.6ns typical, 1.0ns max
• Timebase accuracy: +/-0.005% over full temperature range

The threshold spec does give some wiggle room for saying when a logic 1 or logic 0 has been detected. However, I think we need to keep in mind the extremely fast edges that are characteristic of 74AC logic. Not much time will be spent in that +/-100mV no-man's land.

Quote:

(Also the memory chip itself may be stronger pulling low than pulling high.) That's why the bus seems to change from 110 to 000 (dead time), then from 000 to 001. But really it's just the unfolding of a single event. All the lines began their transition at the same time. And the transition was from 110 to 001.

The SRAM has a totem pole output, so it will sink harder than it can source.

Quote:

BigDumbDinosaur wrote:

[regarding the contention issue] it appears the RAM gets off the bus just in the nick of time.

Again I'm not sure when is the event you mention, but I do see an event that shows cause for concern.

apparent collision.png

Unless I'm missing something, at T+8ns the RAM plainly doesn't get off the bus in time.

In my previous post, I did say to take the measurements with a grain of salt. Limitations in resolution coupled with some uncertainty as to when the LA thinks something is a logic 1 or a logic 0 can give the appearance of timing anomalies that aren't really there. The only thing I can offer is 1) the machine works at 20 MHz; 2) the SRAM is not as warm as the physically much-larger MPU when running the "torture" code.

Quote:

We see the bus lines change from 101 to 000, which must surely be the CPU's doing. But /RD is still low, which means RAM hasn't yet been told let go. RAM and the CPU are in contention, and it appears the CPU's stronger drivers won at least a partial victory... enough to cross the LA threshold, that is. (An oscilloscope would likely reveal indeterminate voltages, neither solidly high nor low.)

Yep, that is something I'd like to scope. However, my scope is having problems when running it on the highest sweep rates. I'm in the contemplation phase of getting a replacement (see my "Scope Goes Bang" topic), as the cost to fix the one I have now (an H-P 1725A made in the early 1980s) is likely excessive—assuming parts can be gotten (the CRT was custom-made to H-P specs).

Quote:

Quote:

I took the MPU's temperature using the highly scientific method of placing the back of my little finger on the MPU.

Right -- got it! That's called a Digital Wattmeter, I hope you know!

<Groan>

Quote:

Anyway, it would be interesting to know how much of the MPU temperature rise can be attributed to contention. (The RAM will get some heating, too.) Luckily none of this is serious enough to crash the system. But there'll certainly be some added noise (current spikes) on the power rails and data bus lines.

Once I get the scope issue settled I'll be able to further investigate. I will say even with sustained RAM accesses the chip temperature doesn't appear to rise when measured with my "digital wattmeter."

[BigEd]

I'll have to pull you up on one thing BDD, it's an easy mistake to make but I'm sure none of us would want a false conclusion to be drawn.

Quote:

At this point, it is appropriate to note that despite what the data sheet says, the 65C816's inputs clearly recognize TTL levels.

More precisely, you've seen situations in which TTL outputs have successfully driven the '816's inputs. You haven't shown that they always will - and it's impossible to show that, so no surprise.

Quote:

Scoped samples of data bus activity taken from POC V1.2 running at 12.5 MHz a few years ago showed that a logic 1 did not make it past 2.6 volts in the roughly 30ns that the SRAM was driving the bus. That is well short of the minimum logic 1 voltage (VDD × 0.8 ) specified in the data sheet. If that spec were true, the computer would not be functional.

Fine up until the last sentence! What you could say is that if the part barely met the spec, it wouldn't have worked. But it's quite desirable that the part can comfortably meet the spec, and for a given part in given conditions which are not worst-case, it's very much expected.

The spec says that you need to meet a certain level in order to have things work, in all combinations of temperature and voltage and across all parts that passed WDC's tests. The spec does not say that if you don't meet that level your computer will always fail. Your computer didn't fail, but one cannot conclude that the spec is wrong. I'm sure you'd be as interested as any of us if 10% of 816s didn't work in this situation, or if a batch of 816s came out none of which worked in this situation.

I'm sure you'd agree that it's possible and desirable that WDC could be exceeding the spec. You might then argue that they should revise the spec, and if they can always meet that revised spec, I might agree with you.

I think it's pretty likely that you're right to think that the inputs are indeed TTL compatible - and it certainly seems the conclusion is good enough for hobby purposes. But your reasoning and measurements don't prove it, and the specs don't rule it out either.

[BigDumbDinosaur]

BigEd wrote:

I think it's pretty likely that you're right to think that the inputs are indeed TTL compatible - and it certainly seems the conclusion is good enough for hobby purposes. But your reasoning and measurements don't prove it, and the specs don't rule it out either.

However, at least in the case of the 65C02 and 65C802, WDC has implied the inputs are TTL-compatible. Those parts were/are sold as drop-in replacements for the NMOS parts, which were used with 74LS glue logic. Hence TTL-compatibility would have been required for the MPU to function.

I have used, so far, seven different 65C816s in my projects. All of them are functioning with an SRAM and EPROM producing TTL-level output voltages.

[BigDumbDinosaur]

POC V1.2 has been continuously running at 20 MHz for nearly two weeks. Everything continues to work properly.

[BigDumbDinosaur]

Amazing how time flies. Hobby computing languished for a while as I focused attention on my railroad stuff. Plus I purchased an engine lathe last summer and spent a fair amount of time (and money) getting it set up and tooled.

JET 1236PS Engine Lathe, photo taken short after anchoring and tramming it

Later in the year, medical malarkey started giving me some grief. I ended up trading in my pacemaker for a pacer/defibrillator, which involved some dicing and slicing at the hospital. So far, so good, only to then get whacked by the Chinese plague.

Anyhow, I powered up POC V1.2 again in mid-December and it has been continuously running since then. The Ø2 rate is at 20 MHz and it's just sitting there on my desk, humming away. Every now and then, I check uptime and read and write some disk blocks to exercise the hard drive.

I had started on an evolutionary update dubbed POC V1.3 back in May but got sidetracked and set it aside when it was clear I wouldn't be able to finish it right away. I'm hoping to soon get back to it. So far, the SMT stuff is in place (thanks Cecil!) and I have tested the board to verify that it won't turn into a smoke generator when powered. I've got to add the rest of the components and then do a NOP test on it to see if it will work.

V1.3 sports a few changes from V1.2:

• The full 128KB in the SRAM is addressable. Only the first 48KB in V1.2 is addressable. As part of the bank $00 memory map is occupied by ROM and I/O, there will be a total of 112KB of usable RAM. The bank $00 memory map will be the same as in V1.2.
• The Ø2 clock generator now directly supports stretching to produce a wait-state on ROM or I/O accesses. This is in contrast to V1.2, which used a daughterboard with the stretching hardware.
• A single MAX248 drives all four serial ports. V1.2 uses two MAX238s. The parts count is reduced but ironically, the cost of one MAX248 is slightly greater than that of two MAX238s. Also, the MAX248 is in a PLCC44 package, so there's a socket. At least there are fewer pins to solder than with two MAX238s.
• All but one of the glue logic components are SMT. As the location of the vQUART interrupt encoder was relatively uncluttered, I used a DIP (easier to solder).
• Push buttons for reset and NMI are now on the board. The little screwdriver I used in the past to recover after a crash has been retired.

As soon as I can finish assembly we'll see if it goes or blows.

[Dr Jefyll]

BigDumbDinosaur wrote:

V1.3 sports a few changes from V1.2:

BDD, is there any single place where links to and brief summaries of all these various POC's are provided? Just a suggestion.

Quote:

The little screwdriver I used in the past to recover after a crash has been retired.

Well, that's progress, I suppose. But you have to admit... a little screwdriver does have a certain rustic charm!

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

V1.3 sports a few changes from V1.2:

BDD, is there any single place where links to and brief summaries of all these various POC's are provided? Just a suggestion.

I guess I had better make a table of some sort with that info. You know how it is: computer jocks write code, not documentation.

Quote:

Quote:

The little screwdriver I used in the past to recover after a crash has been retired.

Well, that's progress, I suppose. But you have to admit... a little screwdriver does have a certain rustic charm!

It does...until you accidentally poke it in the wrong place and your computing contraption goes belly-up!

[BigDumbDinosaur]

I've been working on updating my string manipulation library, with testing being carried out on POC V1.2. As V1.2 has four serial I/O (SIO) channels, it's convenient for testing because I can issue commands and do debugging on the console, all the while having the program being tested use one of the other SIO channels on which to print test data. That way, the results of testing are not messed up by debugging activity. It's almost like working with a real computer.

Debugging with POC V1.2 Driving Two Displays

Anyhow, everything seemed to be fine until I started debugging the strins function, which inserts string S2 into string S1 at a point in S1 determined by index I (invoked with a macro, the function call is strins *S1,*S2,*I, using C notation for pointers). In order to do this, strins has to "split" S1 at the point of insertion, which is done by shifting up all of S1 beyond the insertion point by the number of bytes in S2. Once that is done, S2 is copied to the point of insertion in S1. The effect is S1 is expanded by the size of S2.

Testing with short strings seemed to indicate everything was copacetic. In order to make strins work harder, I started using longer strings and wrote a test loop that would keep feeding the expanded string (S1) back to the function for further expansion. Problems arose with this more demanding test, as periodically, S1 would be corrupted. Random bytes would appear—almost always these bytes were $00, but periodically some other values were showing up. I determined the corruption was occurring as S1 was being split. When the error occurred, it immediately became apparent there was a problem once S1 was printed after processing.

I pored over the source code looking for the error that just had to be there. I also stared at stack dumps looking for corrupted pointers or other erroneous data. I couldn't see anything wrong. Finally, I added a trap in the split code so execution would stop on a BRK if $00 was loaded into the accumulator.

I started the test loop, which ran for a couple of seconds and then stopped at the trap I had set. A check of the RAM location from which the $00 was loaded showed that $00 wasn't there; that location contained the expected test data. I repeated the test several times and each time the error eventually occurred.

Given the test results, some sort of hardware glitch was occurring, but in a random fashion. In an effort to determine what it was, I reduced the clock speed from 20 MHz to 8 MHz and repeated the test. Once again the error occurred, which eliminated 20 MHz operation as the likely culprit.

Just to prove to myself that this wasn't a software issue, I disconnected POC V1.2 and connected V1.1 (Ø2 is 14.1 MHz on that unit), loaded the test code and ran it. It ran until the test string size had maxxed out at 32,767 bytes—no errors occurred. I ran the test several times in succession and in every case, V1.1 completed it without error.

So it would seem V1.2 has some sort of hardware gremlin. The likely suspects are:

1. Flaky RAM. Rare with SRAM—if I were using DRAM I would be replacing it before doing anything else. Furthermore, at POST, a test of RAM is performed using two different bit patterns. Surely if there was a RAM location that has a problem with retaining content an error would occur during testing—the test would abort and report the error on the console. However, the test only consists of writing %01011010 and %10100101 once per cell and reading it back. So it could be some location is okay with those bit patterns but not with other data. I would need to write a much more elaborate test to fully exercise RAM and prove that it is okay—or not.
2. Flaky MPU. Again, pretty rare—I've never encountered a bad MPU in some 50-odd years of monkeying with computer hardware. However, there's always a first time for everything. I should be able to eliminate this possibility by swapping MPUs with POC V1.1, which completes the test code without error, thus implying it has a good MPU.
3. Glue logic timing. I'm not sure what it could be. All logic is 74AC, with no more than two gates between any one chip select and the address bus, giving the machine ample timing headroom, even at 20 MHz. It could be I have an occasional bout of data bus contention occurring when Ø2 goes high on a fetch cycle. If that were to happen, the 816 and RAM would clash during a fetch cycle, which could explain the occasionally-corrupted byte. However, if contention were occurring, you'd think it would also occur during the fetch of instructions and operands, which should trigger some sort of gross error. That hasn't happened at any point in the testing.

Figuring this out and coming up with a solution will be no trivial matter.