Well, this project got stalled a bit, thanks to a defective part. Also, I've been under the gun to convert a lawyer client's Linux server to support the Samba 4-series, since he is converting all his Windows 7 workstations to Windows 10 to support new practice management software (poor guy—he'll soon find out why a lot of businesses have resisted "upgrading" to Windows 10). As this conversion means moving him onto the Linux 4 kernel, it can't be done live. So I've got my "mule" server set up to do the work in my shop, after which I can swap out his root disk with the new one. It's keeping me up at nights because of some significant changes (stupid ones, I think) in how a Linux system comes up following initial boot. Whomever thought systemd was a good idea needs a lecture about creeping featurism, followed by a swift kick to the rectal region.

Anyhow, back to the defective part...

After getting POC V1.2 up and running, I decided it was time to explore wait-stating. We've had discussion elsewhere about the problems associated with use of the 65C816's RDY input for wait-stating, which I won't recapitulate here. Suffice to say, using RDY can be a challenge and is something I concluded was best avoided in an '816 machine.

Instead of RDY, V1.2 will wait-state by stretching Ø2 when a slow access is needed. With WDC MPUs, Ø2 can be stopped in either phase without causing trouble. In this particular case, Ø2 will be halted in the high phase for one or two clock cycles when a wait-state is required. Doing so is not difficult to implement and in fact requires only one active part—a 74AC163 synchronous counter, which replaces the 74AC74 Ø2 flip-flop that is already in the circuit. As a bonus, this trickery will work with any CMOS 6502, since any of them may be stopped in the same fashion without issue.

My clock-stretching circuit is a close adaptation of the one that Jeff (Dr. Jeffyl) presented here. To implement it, a module has been built that will plug into the Ø2 flop's socket. Unfortunately, the module is presently non-functional because the 'AC163 I got from the distributor turned out to be defective and in fact, created a strange fault in the system that took a bit of troubleshooting to identify. This is the first time in decades that I've gotten a defective, new chip, all the more surprising given that it was a TI part.

Fortunately, V1.2 survived the fault. So I'm waiting for a replacement 'AC163 to arrive and once in hand, I'll be ready to test. I will publish the details, including illustrations of the unit's logic states when a wait-state occurs, as soon as testing is done and she goes or blows. If this circuit works as expected, it can become a reference design others can use in their systems to accommodate slow hardware.

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

Parts received.

For some time, we've been kicking around various methods of wait-stating when a slow device must be accessed on an otherwise-fast machine. It has been noted that there are problems with using the RDY input to wait-state the MPU. As halting the MPU with RDY is tantamount to stopping the clock in the high phase, I proposed an alternate wait-state method that involved stopping the Ø2 generator flip-flop in the high phase. That does work but requires an external timing device to set the duration of the wait-state.

More recently, Jeff (Dr. Jefyll) proposed another "stop the clock" method that makes use of a synchronous counter. Intrigued by the idea of doing it with a single chip solution, I decided to give it a test in POC V1.2, since that unit's purpose in life was to be a guinea pig. So I went to work and whipped up a circuit that accepted the chip select signals for the ROM and the RTC, the latter being the slowest I/O device, and pushed them through a AND gate to drive an input on the 'AC163.

While I was working out the details, Jeff and I kicked some E-mail back and forth on how to best do this, with he proposing that I ditch the AND gate and use several inputs on the 'AC163 in its place. The result of doing so would be a wait-state for one device would be slightly longer than for the other. In this application, that difference wouldn't matter, so I decided to go with Jeff's suggestion and ditch the gate. The resulting circuit looked like this:


When neither the ROM or RTC is selected, the AC163s inputs are all high, which amounts to a preset value of $0F, causing the QD output to follow the clock input at 1/2 its frequency—the change in outputs occurs on the rise of the clock. As QD is where Ø2 is derived, Ø2 is likewise one-half the input clock rate.

If the ROM or RTC is selected, the corresponding input will be low and the preset value will be $0D (RTC) or $0B (ROM). Now the AC163 has to count more clock pulses to get to terminal count and flip Ø2 back to low. Ø2 will stay in the high phase longer, causing the CPU to wait.

The design looked sound on paper, so I was ready to give it a try. The plan was to build this gadget on a small PCB, arranged so it could be plugged into the existing Ø2 flip-flop's socket. Some bodge wires¹ would bring the ROM and RTC chip selects over to the socket on two otherwise unused pins.


The gadget would have to be pretty small to fit in the available space, in fact, not much bigger than the AC163 itself. The decision to build such a thing on a PCB was a concession to my deteriorated vision. However, Jeff offered to build the gadget for me on perf board, sparing me the time and expense of getting a PCB made, as well as the challenges of soldering small parts on a tiny board. The result looks like this:


Cute little thing, eh?

Here's the stretcher gadget installed on POC V1.2:


With the hardware handled, it was time to do some testing and observe the circuit's behavior. The first step was to see if V1.2 would boot with the clock stretcher installed. Running on a 12.5 MHz Ø2 clock, V1.2 booted normally.

The next step was to acquire some data on what Ø2 was doing when a ROM or RTC access occurred. I burned a ROM with the following code:

Code:

toram    =$002000
rtcbas   =$00C300
rombas   =$00d000
resvec   =$00fffc
;
         *=rombas
;
setup    ldx #_tstend_-test-1
;
setup010 lda test,x
         sta toram,x
         dex
         bpl setup010
;
         jmp toram             ;run test code
;
;
;   test code...
;
test     lda rombas            ;gratuitous ROM access
         nop
         lda rtcbas            ;gratuitous RTC access
         bra test              ;repeat
_tstend_ =*

All this does is copy a few lines of code to RAM and run it, causing the '816 to bang away at ROM and RTC. If everything is working, Ø2 will be a 50 percent duty cycle clock until access to either of those two devices occurs, at which time the high pulse should be elongated.

With that ROM installed, I hooked up the logic analyzer and captured the signals that were of interest:


Signal names are at the left end. CLK is the "raw" clock signal being fed to the AC163 by the (25 MHz) clock oscillator. In the trace capture, it can be seen at the points where ROM and RTC are selected that the high phase of Ø2 is extended. Also, VDA remains asserted for the duration of the wait-state, as does /RD (read data). The MPU literally freezes in its tracks until the AC163 reaches terminal count and brings Ø2 low.

Also visible is the behavior of VDA and VPA as the MPU works through the code it is executing, plus the lag between the change in Ø2 and the other signals is quite clear.

The results of this experiment demonstrate that Jeff's solution of using a synchronous counter to stretch the clock is a sound one and one that is painless to implement.

Incidentally, if you try this, I recommend you use a 74AC163, not a 74HC163. The rise/fall times of the HC163's outputs may not meet WDC's specifications, possibly causing instability. Ringing with the AC163 may be a problem in some cases, which can be dampened with a series resistor connected as closely to the device's output as possible. You may have to experiment a bit to find the ideal resistance value. I used 100 ohms in V1.2, and Jeff added 22 ohms to the stretcher gadget. The signal as seen on my 'scope is pretty clean, with just a little ringing.

———————————————————
¹Thanks to British electronics enthusiasts for the term "bodge wire."

Edit: Fix some typos and stuff.

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

Would this work with NMOS 6502s as well, assuming the stretch was kept to a few clock-cycles duration?

I've never seen figures for the 6502, but I do seem to recall reading a spec somewhere for the 6800 and/or 6809 that the chip could not lose internal state so long as you didn't stall the clock for more than 160 microseconds or something like that.

_________________
Curt J. Sampson - github.com/0cjs

It will work with the NMOS 6502. With a 1 MHz 6502, it should be able to tolerate up to four clock periods of wait-state.

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

Depending on whose datasheet you read, the NMOS 6502 can tolerate a clock frequency as low as 100kHz (Rockwell) or 50kHz (MOS). They don't specify a maximum time per phase, only per cycle, so you can use almost the full 10 or 20 µs in one phase as long as the other one is normal. The likelihood of encountering a bus device requiring such a slow access seems remote, and you should probably hang it off a VIA in that case.

Most of the CMOS 6502s can stay in the Phi2 high state indefinitely, and only have a limitation on Phi2 low time; Rockwell specifies 5 µs maximum for the latter. This dovetails neatly with typical wait-state requirements, but less well with DMA granting. WDC's static design can stay in either phase indefinitely, and indeed some earlier WDC datasheets show a 40kHz maximum clock speed at some absurdly low Vcc - think single AA and watch crystal.

Nicely done, BDD (and Jeff) - thanks for the thorough explanation and the measurements.


Hmm, I would advise caution. Certainly the (under)specification might lead you to think so, but in the 6502 each phase has its own purpose, and I wouldn't be surprised to find that either phase, over-stretched, will lead to misbehaviour. (Although I'd also be sure that the spec is very generous: it's hard to test charge-leakage and harder still to put a tight bound on it.)

Another future experiment, then: how slow can an NMOS 6502 run in practice? I would bet the spec is very conservative, especially Rockwell's.

Maybe, in practice, it can run through Klaus' test suite at 10kHz…

(Probably a good time for a new thread on this thought.)

As far as I know, all forms of the 65C02 can be held in Ø2 high indefinitely. In the majority of cases, the inability to hold non-WDC MPUs in the Ø2 low state is not a liability. Jeff's circuit should work fine with any 6502 in existence, provided the wait-state used with an NMOS part isn't more than two or three clock cycles.


I'd be inclined to say there is not a problem with DMA, as long as the DMA controller (DMAC) and MPU are both slaved to the same clock and the glue logic can guarantee the MPU will be off the buses before the DMAC is enabled, and vice versa.


Yep! Although I no longer have any interest in the NMOS 6502 someone else might find such a thing useful.

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

Thanks for sharing your results with us, BDD. I expect you'll soon be trying some faster oscillators to get an idea where POC's new speed ceiling is, now that the CPU needn't dawdle along at speeds suitable for the laggardly EPROM and RTC!

Of course if you continue to increase the speed you'll eventually encounter some other limiting factor, although it may or may not be obvious what that factor is. (The specified limits stated by the datasheets will have already been left far behind.)

So, have fun with that, and keep us posted! And, FWIW, if you really wanna push for maximum speed it may be worth upgrading the 'AC138 decoder you're using to generate chip-selects, as it may be part of the new critical path. The clock-stretcher circuit won't react well if the chip-select signals arrive too late (and neither will the chips being selected).

It's been a while since I checked, but AFAIK the fastest '138 chip available is one of the 74FCT138 types -- there's a "C" version whose maximum prop delay is listed as a mere 5 ns. The output levels are TTL, not CMOS, but I'm guessing that's not a problem in this case. (Surface-mount only, though, so you'll require another adapter board. Luckily, this one is an off-the-shelf item!)

As for NMOS / 'C02 / '816 issues, there's some related material in my original post, RDY vs CLOCK STRETCHING. Includes 2 very simple circuits

-- 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!

I also found the same thing with the SCC2691. Granted, it's an older chip, but exhibits the same issue... transmit still worked at the higher CPU speeds, but receive did not. Perhaps adding a couple NOPs in the ISR for handling receive might help as a debug aid. Now that I mentioned it, I might try the same on my SBC

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

The 28L92 seems to have a "typical" /RD to data-valid delay of 40ns, which is out of spec for the Phi2-high phase of the 6502 bus at 14MHz. The maximum is as high as 55ns. I would be giving that chip a wait-state above 8MHz.

Hmm...your comment about the 2691 being a bit of a laggard during a read cycle prompted me to take a second look at the 28L92's timing:


I think the above may explain what I am seeing and indirectly, what you are seeing with the 2691. In the latter's case, tDD may be as high as 125ns. In both cases, it's an almost-inescapable conclusion that timing is asymmetric, explaining why transmission is okay but reception fails.

It seems the logical thing to do is to rig up yet another bodge wire so V1.2 can wait-state on a DUART access. The problem is there are two DUARTs, so I presently can't wait-state both of them. However, wiring up DUART #1 to trigger a wait-state is enough to prove or disprove the theory about why reception falters at higher clock rates.

Another thing I can try is to swap DUARTs with POC V1.1. As the latter runs cleanly at 14 MHz, if swapping the DUARTs moves the problem to V1.1 then we've got an answer. I will give that a try before heating up the soldering iron.


See above.

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

Swapping DUARTs did demonstrate the DUART in V1.1 is slightly faster than its counterpart in V1.2, but not enough to ensure stable operation. After doing the swap, V1.2 would try to process keyboard input at 14 MHz, but what was echoed to the screen was gibberish. For example, typing 'a' produced 'c'. The backspace key was unresponsive. V1.2 has somewhat greater bus loading than V1.1, which may be just enough to upset the timing apple cart at 14 MHz.

Given this, the next step will be to rig up DUART #1's chip select to generate a wait-state. Stay tuned.

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