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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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.


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.


Yep! We should soon know.

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

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.


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.

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

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.

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

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:

         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.

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

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.

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.


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.


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.)

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

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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.


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).


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.


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.


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.


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.


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.


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


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.


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).


<Groan>


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."

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

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.


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.


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.

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.

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

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

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

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

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

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

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

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