6502.org

Yes, a major milestone! Thank you Jeff. It's super exciting to see the result. Lots more work to do yet, but we can certainly toast a victory along the way tonight!

Cheers!

(Ahh, nothing like a frosty root beer and the sweet taste of success .. )

Congratulations, Drass !

I know what it feels like to have the hardware up and running for the first time after two years of working on the schematics.

Considering the _complexity_ of the design, I had expected a lot more trouble during debugging.
Successfully running a test suite already is "half of the rent", the final test would be Commodore BASIC.
...Especially those floating point math routines.

Of course, GND connection\distribution is more critical for 74AC logic which gives you signals with fast rise\fall times.
Looking forward to see that CPU running at 20MHz+.

Good luck and god speed !

Dunno about the "root" part.

Brilliant! And a good lesson about signal integrity too.

Drass, just curious: have you noticed switching spikes between phase (Q0-Q4?) changes in ROM E and ROM F outputs?

Axel.

Thank you gents! And thanks for the support in getting here
Looking forward to that ... it will be interesting to see how far these PCBs can get (albeit with lots of surgery perhaps)
Considering these problems persisted even with the manual clock, we can be sure it was not switching frequency that caused them.
Aha! On pins and needles about that ...

Hi Axel,
ROM E and ROM F reside on the K24 Card, which I've yet to build. However, the same circuits are present for the Microcode ROMs on all the cards. Like this:In each case there is a 74AC574 Microcode Instruction Register ("MIR") at the outputs of the ROMs to capture the values of control signals - this is part of the microcode pipeline implementation. There are no other "drivers" to conflict with the ROM outputs so I would expect smooth operation on these lines. I can't confirm that without an scope though. Curious if you're seeing something that might suggest a problem.

Interestingly, I do expect spikes at the outputs of the MIR when switching between MIR and MIR2. This happens in two instances: (1) when adjusting the high byte of an indirect address, and (2) when a branch is NOT taken. The outputs of both MIR and MIR2 drive a common control bus, so we can anticipate collisions and spikes on every switch - this is something I wish I had taken the time to correct!

The design manages to partially mitigate these collision in the first instance above by arranging the microcode to change only 2 of the 32 bits in the control bus when the switch occurs. No such luck in the second instance. In one critical-path operation, however, control signals are "pre-set" in the MIR from one micro-instruction to the next, which in effect provides a "pre-decode" function. It's one of those "get to 20MHz" contortions to squeeze a few nanoseconds out of the critical-path.

No, not frequency per se. But it's a slippery topic, so let's be careful about the distinction between frequency and rise/fall time. It's entirely plausible that fast rise/fall times could cause trouble, even at virtually zero operating frequency.

Each individual rise or fall of a fast output (such as from AC logic) is stimulus that's guaranteed to provoke some degree of ringing. In a well-controlled situation the ringing has low amplitude and also tends to decay quickly, so of course that's the near-ideal case. However, in a very poorly-controlled situation (such as your original test setup) the ringing has much higher amplitude and may be sufficient to introduce beyond-tolerance noise in other circuitry (such as the /Clr input of your IR register). Remember I'm talking about the reaction to one individual transition, such as may occur during single stepping.

Having said that, I'll add that, between the two extremes -- ie, with a design that's neither perfect nor horrible in regard to ringing -- it is possible to encounter a situation where single-stepping and low-frequency operation seem to work alright but the project fails when full operating frequency is applied. The explanation is that each new transition appears before the ringing from the previous transition has decayed, and their combined effect is problematic.

Jack Ganssle illustrates that point on the oscilloscope in the short video at https://www.youtube.com/watch?v=MJpDFnRQw8s&t=1m58s (cued up). It's the rise and fall time, not the frequency, that causes the AC behavior problems on poorly designed boards.

The signals MIR.SW and /MIR.SW both are generated by the outputs of IC32 (74LVC1G74 D_flipflop) on the ALU&CU PCB.
So MIR.SW and /MIR.SW (output enable for MIR and MIR2 registers) are supposed to change nearly at the same time.
I'm not expecting much spikes at the outputs of those registers while switching the output enables.

About the rise\fall times of the signals:
Ground connection between those two CPU PCBs and the SBC PCB probably isn't too good in your test setup,
it would be going to be a bit better if those PCBs are plugged\stacked together.
Well, you could try to add a rather thick GND wire between those PCBs, but I'm not sure if this really helps now...

I didn't expect spikes either... In AComputer TTL CPU there is 74HC163 feeding 4-bit phase signal to Microcode eeproms. Due to fall/rise time of 163 there are clear spikes on outputs of eeproms between phases. This is probably much affected by eeprom type/model but the ones I've been using the threshold level is different enough. Using faster 163 would probably help on this but the faster edge would generate another issue.
I also noticed that mixing 138s and 139s is also generating unplanned behavior.

Axel.

This one is above my pay-grade Axel. My understanding is that HC logic has a gentle rise time compared to AC logic and I do use a 74AC163 exactly in the way you describe. But why should it matter that it's a '163 feeding the ROM inputs rather than, say, a microprocessor? Maybe the microcode ROMs should only be output-enabled once the address has stabilized? Are you getting spikes on the system ROM as well, or only on the microcode ROMs? Pray tell, what behaviour are you seeing? I'm using '138 and '139s in this design as well.

Great video Garth, thanks! The ringing on the scope is very obvious and no change at all as the requency changes. Fascinating!

Hi all,

Typically you set Address first, then CE and OE. Then ROMs work as planned (with MCU for example). In this setup, OE and CE are always enabled so it is not natural that addresses are changed on the fly. This is something I checked on scope almost right after I had the setup ready.
This is what the output of EEPROM looks like when HC163 is calculating: I was expecting spikes but not that strong.
With 138&139 I noticed that there is a slight time difference in practice. In 1-2MHz range, it has absolutely no meaning tho.

That's why I was curious to know how AC performs in the same place. (Also, there are different access times in EEPROMs used so the result is not directly comparable).

Axel.

Hmmm doing some math here... Just wondering how many (xtal) clock phases are there in one opcode (eeprom microcode) phase? 20MHz has 2 x 25ns interval and EEPROM in the circuit diagram has 45ns access time.

Axel.