During last week's tests, the CPU ran reliably at 12MHz, but failed at 16MHz. Given that jumpers are still very much in use between the PCBs, it's easy to assume poor grounding is the culprit at the higher speed, or perhaps that 12MHz might be the ceiling on performance. I wanted to find out. But first I needed to deal with the fact that 16MHz was going to be impossible while running the code from ROM (at least until V2 of the SBC is built).
Easy enough. The CPU can copy the "blinky-light" loop to RAM using the SBC's half-speed SLOW clock before jumping to it. Then the 16MHz FAST clock can be manually engaged to run the remainder of test from RAM. I calculated bit 0 of the VIA Port would flicker at roughly 890KHz if things were working correctly (the blinky loop is just 9 cycles, so 18 cycles for a full "blink", at 16MHz / 18 = 888.88KHz blink-rate). But alas, the CPU only sputtered and locked-up when I ran the test -- no blinking at all. Ok, so something else was gumming up the works.
I then remembered that there are two gates in series on the CPU's internal clock pin, one implements RDY and the other the 2-cycle-BCD internal wait-state. That's all well and good, but two gates translates into a 10ns
delay after the fall of PHI2 before the CPU can start to work! Including these two gates, the minimum half-cycle is a full 33ns, or a top speed of only 15MHz -- there's no way this was going to work under those circumstances!
Thankfully, the CPU includes a
Zero Delay Buffer ("ZDB" - datasheet attached below) to deal with exactly this problem. The idea here, I learned from dr Jefyll, is to synchronize the internal clock
after the gates with the input clock
before the gates, such that the edges of the two signals are co-incident. The ZDB does just that by way of an additional brief
delay it calculates automatically. Of course the downstream logic can't tell one cycle from the next, so the gate delays are eliminated altogether and the CPU responds 10ns more quickly than it otherwise would! (I know, magic right?). Here is the circuit in question:
Attachment:
Card A-Registers Sch p3.png [ 23.03 KiB | Viewed 1193 times ]
Now the ZDB requires that the input clock-rate be no lower than 5MHz, so single-stepping the CPU for debugging is impossible when the ZDB is engaged. I had therefore placed it behind a solder-jumnper so it could be safely disabled until needed. And clearly, it was now very much needed! So, I soldered the jumper closed and hooked up my cheapy-ebay frequency counter to read bit 0 of the VIA port. I paused for a moment to look at the frequency readout before flipping to the FAST clock, and then:
Attachment:
Freq 888.jpg [ 38.51 KiB | Viewed 1193 times ]
Bang on, unbelievable!
The fan on the power-supply was churning away and the display showed 600mA at 5V. Man, oh man, that TTL CPU was hammering the VIA port at 16MHz!!! Amazing ...
On other news, I was able to confirm that the 6510 port works, as does the 6502+NOPs alternate microcode. It seems further patches to the PCBs might be less likely at this stage of testing (I hope), so it's finally come time to stack the CPU boards together. Unfortunately, the inter-card connectors I used don't actually fit together.
The new ones I ordered have arrived, so it's likely I will spend next weekend wrestling with the boards to replace the connectors.
Cheers for now,
Drass
EDIT: removed the mention that the ZDB requires a 50% duty-cycle. I must have been confused about the requirement.
Login
Register
FAQ
Search
