In the context of what we build, I think my statement can stand.

If one is in hair-splitting mode, it could be argued that Q and /Q are not exactly in step due to the sub-nanosecond times required for electrical impulses to navigate their way through the flop's internal circuitry. I'd readily concede that. However, in the practical world in which a high-speed 65C02 or 65C816 system may have a 50ns machine cycle time, the Qs can be considered to be exactly 180° out of phase.

Your post got me curious, so I once again put the logic analyzer to work to see just how closely the flop's outputs complement each other. Below are some signal captures gotten from a 74AC74 flop in POC V1.2. This is the flop that the clock stretcher replaces. Sampling rate is 500 MHz and the capture trigger is the rising edge of Q. Other than one signal in the final trace in the set, signals are being picked up right at the flop's pins, with the jig's lead length being approximately 210mm.


Trace descriptions:

• The first trace is a "high altitude" view of the flop's Q and /Q outputs with the scale resolution set at 10ns/div.
  
  
• The second trace is the first trace with the scale resolution increased to 2ns/div.
  
  
• The third trace was a fresh capture with scale resolution set to 1ns/div, which is the finest resolution to which the logic analyzer's software can be set. Q and /Q appear to be 180° out of phase. The uncertainty is ±1ns.
  
  
• The final trace is a little different than the previous three. Here Q is being picked up at the flop, as before. The Ø2 Out signal is Q being passed through a 100 ohm metal film resistor, which is present to dampen ringing. Triggering is still from Q. Note that Ø2 Out lags Q by 2ns (interval A-C on the time scale).

I think for our purposes, the Q and /Q outputs may be considered to be exactly 180° out of phase

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

Yep! That's what I'm talking about.

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

Hmm, glad to see some experimental data. And indeed those first three traces seem to verify one case of a flipflop whose complementary outputs do switch simultaneously. I'm kind of glad to hear it, actually. Nevertheless, the datasheet doesn't guarantee this, as I already explained.

I don't object to someone collecting experimental data and using it to help achieve their diabolical goals! Like so many decisions, it's a tradeoff. The upside is, you may gain a benefit from relying on the undocumented behavior. And the downside is the greater or lesser risk of disappointment you face, commensurate with how casually or thoroughly you yourself personally verify the parts.


As for the fourth trace, can you elaborate, please? It seems to bear on a different topic altogether. You're comparing the waveforms immediately before and immediately after the damping resistor, is that right?

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

I agree: testing one or two flops doesn't make a whole data set (although testing the flop in V1.1 produced identical results to the one in V1.2). My point is at the levels we hobbyists work, the Qs can be considered to be exactly 180° out of phase.


Diabolical goals? There is no goal, other than a quest for information.


The timing diagram of the flops I am using clearly shows Q and /Q changing state at the same time (page 6). The references are tPLH and tPHL. Nothing in the data sheet says those two parameters can be expected to differ.



Correct. That capture was strictly for curiosity's sake and had nothing to do with the observation of the Qs' change-of-state relative to each other.

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

Sorry, I should have been more precise.
I intended that Q1 (PHI-1) is the 180 degrees shiftet Q2 (PHI2).
So refering to the schematics that DrJefyll posted @3:58, use the /PHI2 for the latch and the PHI2 delayed as the "normal" PHI2.
In effect, the delayed PHI2 would make it look like the latch is activated earlier. (by the delay time of the inverter in red)
Would this fit the timing that's needed?

Probably not. What that would do is cause Ø1 to lead Ø2 by the amount of prop time in the red inverter. Closing the latch a little earlier would not be a problem, but opening it earlier would, as it would open the door to the latch transmitting data bits to A16-A23 instead of address bits.

Using a single inverter to derive Ø1 from Ø2, which is what the black inverter in Jeff's schematic is doing, would make the closing of the latch timing-critical. The lag from when Ø2 goes high and the latch closes would be the sum of inverter's prop time and the amount of time required by the latch to respond to the change of state of its LE input. A 74AC573's response time to LE varies from 2ns to 10ns. Assuming worst-case for the inverter and the latch, the latter would close 16.5ns after the rise of Ø2. Unfortunately, tBH, the bank hold time after the rise of Ø2, can be as short as 10ns. Hence use of an inverter to generate Ø1 to control the latch will not be reliable.

On the other hand, if the clock generator can emit Ø1 and Ø2 exactly 180º out of phase then the time required for the latch to close would be the time required for it to respond to its LE input, which is 10ns worst-case. Even there the circuit may not be reliable because tBH could potentially be equal to the latch's response time to LE. All bets are off if that happens.

I really wish WDC would produce an updated 65C816 in a PLCC52 package, with A16-A23 brought out on separate pins. The rationale for multiplexing the bank on the data bus disappeared when the Apple ][GS went out of production.

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

That chip you want would be a new chip design, I think, and I don't expect WDC have the money (or, possibly, want to spend the money) on a new mask set, new test program, and new batches to make stock for the distributors. It's the same with the bugs on their other chips: everything is now frozen. The fact that the change would be minor doesn't come into the economics of it.

Scratch that.

While a single-chip solution to four TIA-232 channels is enticing, the reality is the two 28L92 DUARTs can handily out-perform the 28C94, especially in the all-important area of handling communications interrupts. With the 28C94, the determination of which channel interrupted and whether it was a receive or transmit interrupt has to be made by reading two separate registers. With the 28L92, four of its general-purpose I/O (GPIO) pins can be rigged up to act as active-low interrupt status outputs. one for each receiver and transmitter. V1.2's circuit aggregates these outputs into a single location in the memory map that can be read, with active interrupts setting a bit in the 8-bit value read. Shifting out bits in a loop quickly and efficiently determines which channels need servicing, a much better arrangement than analyzing two non-contiguous registers in the 28C94.

Also, the 28L92 has deeper FIFOs than the 28C94, which further reduces the interrupt processing load. The only negative is the increased use of PCB real estate.

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

I can wish, can't I?

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

It turns out it is the DUART. In fact, I tried several DUARTs and all behaved in the same fashion. Output to the console at 14 MHz was fine, but the DUART would not process any input. The 28L92 has an official read-data access time of 40ns,¹ a bit too slow for reliable operation at 14 MHz. So a failure is to be expected.

In an effort to prove that the problem was nothing more than a good, old-fashioned timing violation, I disconnected the bodge wire going to the RTC chip select and connected it to DUART #1's chip select—that DUART is what drives the console. After doing so, I first verified that the unit would POST with Ø2 at 12.5 MHz (25 MHz oscillator) and accept console input. So far, so good.

Next I installed a 30 MHz oscillator in place of the 25 MHz one and powered up. V1.2 POSTed and accepted console input, indicating normal operation. Going over the entire keyboard demonstrated all was well and V1.2 was stable at 15 MHz. I even used the console terminal's ability to send entire character strings when a function key is pressed to force-feed the input side of the DUART with data. Everything worked okay.

The last step was to install a 40 MHz oscillator—Ø2 would be 20 MHz. No dice—there was no sign of life. So for now, 15 MHz is top speed. I may do some analysis later on to see if I can determine why it won't post at 20 MHz. I'm sure the fact that the 65C816's maximum speed rating is 14 MHz has nothing to do with it.

————————————————————
¹The DUART's "read access time" is the parameter that determines how quickly the device responds to a request to fetch a datum from the receiver FIFO.

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

There is a topic I started several years ago about generating wait-states with clock stretching. I will likely tack something on to that topic as soon as I get done testing another wait-generation method that stretches the clock.

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

I just realized I was looking at the wrong PDF schematic for POC 1.2 (the POC presently under discussion). In case anyone else has gotten confused, be sure you're referring to the final, "as built" PDF attached to this post, not the PDF in the more conspicuous post here.

It's notable that the "as built" version uses 64K only; the 816's Bank Address is ignored. Thus the discussion upthread about timing for the Latch Enable signal is only theoretical, because in this case there is no latch.

( These are *very* nicely presented schematics, BTW. I like how a reasonable proportion of the connections are actually drawn, rather than having the source and destination linked only by reference to a signal name. And in cases where signal names are used they are located along the left and right edges of the page, not helter skelter all over the place. This is a friendly touch; they're easy to skim over when you're asking yourself, "what else attaches to this?" )

The PDF schematic doesn't include the adapter, of course. So, in place of the 74AC74 we have this '163 circuit instead.

Good idea. And if you suspect the clock-stretcher is failing to behave properly at 20 MHz then you might wanna prove that's the case before proceeding. For example, can a failure be observed using your Logic Analyzer?

I mention this because in your very latest post you mention "testing another wait-generation method that stretches the clock." Perhaps I've misunderstood, but it almost sounds as if you're contemplating a change of course. IMO that would put you at risk of a frustrating and fruitless detour.

-- Jeff

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

Theoretical for now...


Thanks for the compliment. There's a certain amount of survival instinct at work here. Reading has become a challenge, so I try to organize my drawings so I can myself read them.


I've gotten as far as examining the clock stretcher's output as seen by the MPU and glue logic. It's symmetric, with only a little ringing, and is swinging from ground to Vcc with a rise and fall time that is barely visible on my (275 MHz) scope. So I don't think clock quality is the problem.

I'm thinking the logic analyzer will reveal something that isn't apparent on the scope. With 2ns resolution, a significant timing discrepancy that would cause failure should be visible.


Well, I don't want to give away the plot too soon. I will say the alternate wait-state generation I will be testing will involve another one of your creations.

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

One way or the other (scope or LA) it's important to confirm that the chip-select signals become valid early enough. Those signals feed into the clock stretcher circuit, which surely will fail if there's not enough setup time before the '163 counter gets clocked near the midpoint of the 65xx cycle.

If you can confirm there's enough setup time then IMO your problem does not involve the stretcher circuit. Hence, replacing the stretcher circuit with the RDY circuit you linked to won't solve anything.

I have some notions of what to try instead, but POC is your toy and I won't insist on how you ought to play with it. But do let us know, please, if you're able to confirm sufficient setup time.

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

It'll be mid-week before I'll be able to resume figuring this out.

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


I'm always interested in reasonable suggestions. I hardly have all the answers.

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