TTL 6502 Here I come

[ttlworks]

Just to sum up a few things:

In the C64, the VIC-II generates /RAS, /CAS and PHI0 from the dot clock.
/CASRAM is generated in the address decoder PLA (82S100 ?) from /CAS.
From the datasheet, 82S100 propagation delay input to output is 35ns typ., 80ns max.

For DRAM write cycles, R/W is supposed to go LOW before /CASRAM goes LOW,
the DRAM latches the data from the bus after the falling edge of /CASRAM.

6510 generates the PHI2 clock from PHI0, but the 6510 datasheets say that the propagation delay
from PHI0 to PHI2 is 0, what (to me) doesn't look correct, somebody please check.
From this text, expect the PHI0 to PHI2 delay of a 6510 to be ca. 30ns.
For OurCPU, I think that the propagation delay PHI0 to PHI2 is 18ns typ.

Timing specs for the 6510 are relative to PHI2, so the propagation delay PHI0 to PHI2 is important.
Side note: for the WDC W65C02, timing specs are relative to PHI0 (not PHI2),
WDC datasheet from March 2000 says the propagation delay PHI0 to PHI2 is <22ns.
Should be taken into account when trying to run a C64 with a W65C02.

The CIAs and the SID are running with the PHI2 clock output of the 6510.
Note, that the VIC-II has no PHI2 input !
IMHO this indicates that the VIC-II register read/write bus timing is "nailed" to PHI0.

Color RAM /WE is generated from /CAS in the address decoder PLA, "nailed" to PHI0, too.


AEC signal responds faster in OurCPU than in the 6510:

Code: Select all

    ------              --------
AEC       |            |
          .------------.
          .     tDED   .     tDES
          .====>tAED   .====>tAES
        -------             ----
A,D,R/W        >-----------<
        -------             ----

;--------------------------------------------------------------

     MOS_6510_1MHz  OurCPU
     preliminary    Jan 2018                      

tAES <75            typ.11 //Address enable  setup time
tDES <120           typ.22 //Data    enable  setup time
tAED <120           typ.10 //Address disable hold time
tDED <130           typ.21 //Data    disable hold time

Values for OurCPU are estimated from the typical values taken from the 74AC\74ACT datasheets.
R/W setup/hold time for OurCPU is similar to address setup/hold time.

Code: Select all

     -------              ------------
PHI2        |            |            |
            .------------.            .------------
            .===>tADS    .            .==>tHA
  ------------- -------------------------- ---------
A              X                          X
  ------------- -------------------------- ---------
            .            .            .
            .===>tRWS    .            .==>tRWH
            .   --------------------------
R/W         .  /         .            .   \
     ----------          .            .    ---------
            .            .            .
            .            .    tDSU<===.===>tHR
            .            .        ---------
            .            .       X         X read Data
            .            .        ---------
            .===>tRWS    .            .
     ----------          .            .
R/W         .  \         .            .
            .   ---------------------------
            .            .            .
            .            .====>tMDS   .===>tHW
            .            .    --------------
            .            .   X              X write Data
            .            .    --------------
            .            .            .

;--------------------------------------------------------------

      MOS_6502_1MHz  MOS_6510_1MHz  WDC_W6502_14MHz  OurCPU
      May_1976       preliminary    May_2013         Jan 2018
      Nov_1985                      

      REF=PHI2       REF=PHI2       REF=PHI0         REF=PHI2

tD02  ?              ?              <22 //March 2000 typ.18 //ttlworks          //delay PHI0 to PHI2
tRWS  typ.100 <300   typ.100 <300   >10              typ.24 =20                 //R/W     setup time
tADS  typ.100 <300   typ.100 <300   typ.30           typ.23 =15                 //Address setup time
tDSU  >100           >100           >10              typ.5                      //Data    stability time period
tHR   >10            >10            >10              0                          //Data    hold  time read
tHW   >30 typ.60     >10 typ.30     >10              typ.22 =15                 //Data    hold  time write
tMDS  typ.150 <200   typ.150 <200   typ.25           typ.22 =15                 //Data    setup time
tHA   >30 typ.60     >10 typ.30     >10              typ.23 =15                 //Address hold  time
tHRW  >30 typ.60     >10 typ.30     >10              typ.24 =20                 //R/W     hold  time

Somebody please correct me if I'm wrong !

[ttlworks]

AEC output from pin 16 of the VIC-II goes through U27 (74LS08 AND gate) to the AEC input of the 6510.

74LS08:
tPLH 8ns typ., 16ns max. \ tPHL 10ns typ., 20ns max.

AEC output from the VIC-II also goes through U8 (7406N open collector inverter with 180 Ohm pullup resistor to +5V at the output)
to the (LOW active) output enables of the 74LS257 2:1 multiplexers which are feeding the DRAM address lines.
Select inputs of those 74LS257 multiplexers are tied to /CAS which is generated from the VIC-II.

7406: (180 Ohm pullup at the output, so I think we can ignore the signal rise time at the output related to capacitance)
tpHL 10ns typ., 15ns max. \ tpLH 15ns typ., 20ns max.

74LS257A: (note, that 74LS257 and 74LS257B might have slightly different propagation delays than 74LS257A)
Din->Q tPLH,tPHL 12ns typ., 18ns max.
sel->Q tPLH,tPHL 14ns typ., 21ns max.
/OE->Q tPHZ,tPZH 20ns typ., 30ns max.


Got the timing parameters for 74xx chips from there:
http://www.bitsavers.org/components/ti/ ... rs_2ed.pdf

[ttlworks]

At OurCPU, try to delay PHI0 input by 20..40ns and the AEC input by 80..100ns,
and see what this does to the DRAM related RTS problem.

If this works, we need to come up with a plausible theory why, what will take some time.
If this fails, we need to come up with a plausible theory why, what will take some time.

Good luck !

[Drass]

Thanks for all the comments Dieter!

Once again I'm pressed for time, but I did get chance to run a pair of captures to compare the TTL CPU and the 6510. This time, I tried to tap the signals as close to the DRAMs as possible as follows:

Code: Select all

/RS     /RS at CPU
SYNC    SYNC at CPU
R/W     /WE at DRAMs
PHI0    PHI0 at CPU
AEC     /OE at U13 (74LS257) - note: this should be labeled /AEC!
/CASRAM /CAS at DRAMs
/RAS    /RAS at DRAMs
/CAS	/SEL at U13 (74LS257)
A0..3   MA0..3 at DRAMs
D0..3	D0..3 at CPU

The idea here is that we can compare exactly what these DRAMs are seeing with each CPU. Here is the 6510:

And here is the TTL contraption:

They are nearly identical! I say nearly because I see slight differences between them, several of which are 10ns variations, and may simply be artifacts of the sampling rate (100Mhz).

I do see the address lines reacting more quickly after AEC changes state. This is most visible during the second write pulse. There A0 drops 70ns after the fall of /AEC when using the 6510, but only after 30ns with the TTL CPU -- a 40ns difference. AEC also governs R/W, and there the TTL CPU is 20ns faster. But none of these things *should* be having an impact!

Even so, I tried delaying the AEC signal with a 1k resistor just for kicks -- no luck. I may try other values just to see, but it's a guessing game at best.

Darn, this one is proving to be very stubborn! To be continued ...

[Drass]

I’ve been away from the project for some time, but recently found opportunity to make some progress. As a respite from C64 bus timing issues, I decided to return to some final speed tests for the CPU ... and that’s been a lot of fun!

I had left off with stable operation at 20MHz, wondering if that could be bettered. My collection of half-can oscillators has grown over time, but I’ve yet to find the critical next one at 42MHz (21MHz after a div 2 flip flop). I did manage, though, to build the Variable Frequency Oscillator (VFO) as Dr Jefyll and Garth suggested.

The VFO will allow a very gradual increase of the clock-rate, which is very handy. Unfortunately, it is also VERY sensitive to voltage changes, and that's been a problem. I was surprised to discover a significant voltage drop between my workbench PSU and the SBC, and the gap got wider with higher clock-rates. Worse yet, the SBC still lacks proper wait-stating, so booting from ROM requires starting with the half-speed SLOW clock, and switching to the full-speed FAST clock manually, once test code has been copied to RAM. That sudden "jump to hyperspeed" turns out to be a messy affair with the VFO, causing the voltage to drop, the frequency to wobble and the CPU’s Zero Delay Buffer to lose its lock on the clock-rate — certainly foibles enough to crash the CPU at critical speeds.

The first line of defence was to improve cabling. I got rid of the handy external power-switch I had installed between PSU and SBC, and it’s long skinny leads as well. Instead, at Dieter’s suggestion, I twisted together three lengths of wire for each lead, and ran “twisted-leads” to the Auxiliary Power inputs of the CPU. That helped narrow the voltage gap, so I felt the CPU was more easily able draw the additional power it requires at high clock-rates.

But it was also high-time I dispensed with the awkward “slow-clock” maneuver at boot up, and more properly addressed wait-states on the SBC. The simplest fix was to build an small wait-state adapter board to fit the empty 65C02 socket of the SBC. This socket goes unused when the TTL CPU is installed, and it conveniently has all the signals we need for wait-stating. I used the wait-state circuit we discussed earlier in this thread to insert one or two wait-states when A15 goes high, as follows:

Recall that the challenge with wait-states on the TTL CPU is that tADDS (the time required for the CPU to generate an address) is very close to the half-cycle at 20MHz. That leaves precious little time for address decoding before the rise of PHI2, and any additional delay for clock-stretching or RDY logic will easily exceed the time available. To overcome this problem, the above circuit capitalizes on the fact that RDY need only go low before the FALL of PHI2 at the end of the cycle. That allows plenty of time, in fact, and this circuit requires only a single gate delay between address logic and RDY, which is about as crisp as you can get. (In this case, we use A15 as a proxy for ROM_CE since Chip-Enable signals are not available at the 65C02 socket). I tested the circuit with the 65C02 on a breadboard and it worked perfectly.

Unfortunately, that was not the case with TTL CPU. It turns out RDY took effect one cycle too late! The CPU’s RDY logic was extending Phase 1 of the next cycle for the wait-state, rather than Phase 2 of the current one. It was a bug, and one that had gone unnoticed to this point. A quick review of the WDC datasheet confirmed the correct RDY behaviour:

”A negative transition to the low state prior to the falling edge of PHI2 will halt the microprocessor with the output address lines reflecting the current address being fetched. This assumes the processor setup time is met. ... The microprocessor will be released when RDY is high and a falling edge of PHI2 occurs. This again assumes the processor control setup time is met.”

After pondering it a bit, I concluded the simplest fix is a transparent latch on the RDY signal to gate the internal CPU clock. A 74LVC1G373 driven by PHI2 would work perfectly, but that would require a new PCB. As a temporary solution, I commandeered the flip-flop that the CPU uses for the 65C02 BCD wait-state, and pressed it into service to fix RDY, like this:

With that, the CPU’s internal PHI11 clock now correctly handles RDY, with the “setup time” being the tpd of the NAND + flip-flop combination in the circuit. So, finally, here is the new test setup for the TTL CPU — the SBC stacked on top, the Wait-State adapter board mounted on the 65C02 socket, and the VFO installed:

For the test itself, I rigged up a copy of the Klaus Dormann test suite to copy itself to RAM and then to write its progress to the 6510 port on the TTL CPU as it went. Having verified proper operation of the RDY circuit, and other preparations having been made, it was time for the big moment ... I inched the VFO along, hitting RESET each time ...

In the end, the CPU ran the full test suite comfortably at 21MHz, with a 5.5V supply! (current draw is 1A with the SBC LEDs off). Now that seems like a lot of work and trouble for just 1 MHz above the previous record, but so be it. I’m thrilled to get anywhere above the 20MHz threshold, even with the help of a little extra voltage.

So, with that, I’d like to officially declare 21MHz at 5.5V as the maximum clock-rate for the TTL CPU, and 20MHz as the “recommended” clock speed at 5V.

Ok, back to more testing with the C64!

Cheers for now,
Drass

[GARTHWILSON]

Drass wrote:

The VFO will allow a very gradual increase of the clock-rate, which is very handy. Unfortunately, it is also VERY sensitive to voltage changes, and that's been a problem. I was surprised to discover a significant voltage drop between my workbench PSU and the SBC, and the gap got wider with higher clock-rates. Worse yet, the SBC still lacks proper wait-stating, so booting from ROM requires starting with the half-speed SLOW clock, and switching to the full-speed FAST clock manually, once test code has been copied to RAM. That sudden "jump to hyperspeed" turns out to be a messy affair with the VFO, causing the voltage to drop, the frequency to wobble and the CPU’s Zero Delay Buffer to lose its lock on the clock-rate — certainly foibles enough to crash the CPU at critical speeds.

Suggestion: The VFO will be used seldom enough that it should be practical to give it its own 9V battery and a 78L05 regulator or even an adjustable LM317L (both being in a small TO-92 package), so it won't be affected by the computer's power-supply voltage.

Congratulations on the success!

[Drass]

GARTHWILSON wrote:

Suggestion: The VFO will be used seldom enough that it should be practical to give it its own 9V battery and a 78L05 regulator or even an adjustable LM317L (both being in a small TO-92 package), so it won't be affected by the computer's power-supply voltage.

Interesting Garth. Does that mean that the VFO’s VCC and GND pins would no longer be connected to the SBC? If so, how does the VFO’s output pin get a return path to ground? Not sure how one goes about mixing two power sources like this.

Quote:

Congratulations on the success!

Thanks! A very gratifying result, especially given the cycle-accurate constraint.

I’m looking forward to updating the schematics with the (by now many!) patches it required to get here, and getting a clean set of boards.

But first, there is still that C64 ...

[GARTHWILSON]

Drass wrote:

GARTHWILSON wrote:

Suggestion: The VFO will be used seldom enough that it should be practical to give it its own 9V battery and a 78L05 regulator or even an adjustable LM317L (both being in a small TO-92 package), so it won't be affected by the computer's power-supply voltage.

Interesting Garth. Does that mean that the VFO’s VCC and GND pins would no longer be connected to the SBC? If so, how does the VFO’s output pin get a return path to ground? Not sure how one goes about mixing two power sources like this.

Ground is still common, but not Vcc. Having multiple power supplies is common (although not so much with 6502 circuits). Even my workbench computer has +5V and ±10V (this one is not critical at all) for the op amps for the A/D and D/A converters, so I use it also for the RS-232 line drivers, and other things. All voltages are referenced to ground though, and a DMM would show zero ohms from any ground pin to any other ground pin.

[Drass]

GARTHWILSON wrote:

Ground is still common, but not Vcc. ... All voltages are referenced to ground though, and a DMM would show zero ohms from any ground pin to any other ground pin.

Ok, got it. Having a separate stable voltage source for the VFO is a great idea. Thanks!

[Dr Jefyll]

A caveat: using two power supplies this way you have to assume there'll be times when one supply is energized and the other is not (or at least not fully). This results in a potential threat which you may choose to address. Or not -- there's a reasonable chance you can ignore the issue and get away with it.

In this case the output of the VFO drives the clock input of the SBC. Anytime the VFO power supply is substantially higher than the SBC power supply (which could happen during powerup or powerdown) you can encounter unexpected current flow. When in the high state the VFO output will forward bias the upper input-protection diode on the SBC IC that receives the signal. IOW the VFO output will attempt to power the entire SBC. If the VFO output is strong enough it'll exceed the (fairly tiny) current-carrying capability of the input-protection diode and destroy it.

Some logic families (including 74AHC IIRC) omit the upper input-protection diode because that makes the input "5-volt tolerant" even when the AHC device is running on 3V or less. So, you'll be OK if the SBS uses only AHC devices to receive the VFO signal.

Otherwise you could consider other strategies. Force the VFO output low (or tri-state it instead) anytime the SBC isn't fully powered up. Or add an external input-protection diode (Schottky type) on the SBC to help the internal diode carry the current. Finally, a low value series resistor (20 or 30 ohms?) on the VFO output will reduce the available current somewhat (and might actually improve signal integrity).

-- Jeff

[Drass]

Dr Jefyll wrote:

Force the VFO output low (or tri-state it instead) anytime the SBC isn't fully powered up.

hmm, I can use a tiny LVC1G IC on the clock line to gate it until VCC comes up on the SBC. I don’t like the idea of any risk to the SBC/CPU, so it’s definitely something I’ll want to do.

Thanks!

[GARTHWILSON]

The VFO kind of falls into the category of test equipment to be connected temporarily; so from that perspective, you could connect it only after both the VFO and the SBC are powered up, then press the SBC's reset button. The protection diodes at the clock inputs of the SBC should be good for 20mA each though (which would be 40mA at 50% duty cycle), and if there's more than one such protected input (ie, more diodes in parallel, for 80mA or more at 50% duty cycle), you won't be putting out that much current from the VFO. If there's a doubt though, note that if you use only 100 ohms, a logic output of nearly 5V, minus a Schottky diode drop, divided by 100 ohms is still over 40mA; so I would make it perhaps 470 ohms, and put a 47pF or 100pF across that resistor so the slew rate at the load doesn't get too slow. Let's say the load were 30pF. 30pF times 470 ohms is a time constant of over 14ns for the rise time and fall time. For CMOS thresholds at .3 and .7Vcc, you'd want at least 1.3 time constants, but that takes you over 18ns. You'd definitely want that capacitor across there to prevent that slowing. WDC's data sheets call for a clock-input rise and fall time of 5ns or better.

[Drass]

Oh my! Look at what that little CPU did!

Turns out the C64 bus timing issues were all red herrings!

The problem was entirely the result of a silly error. After the speed tests, I set about reconfiguring the CPU to run with the C64. Part of that is making sure that the CPU’s bus management scheme is disabled (explained here). Well, when checked it, I found bus management still enabled for Constant Generator High (CGH) — the IC responsible for generating the $01 high-byte of stack addresses. I had mistakenly patched CGL instead when I originally “fixed” the problem. That’s benign, but leaves CGH still disabled during Phase 2. No wonder JSR and RTS failed in the C64 RESET sequence!

Disabling bus management for CGH was a simple matter of grounding one of the enable pins on the 74AC541 IC, and voila! The C64 booted without a problem.

Now here is one of the original objectives of the project as outlined back in 2015:

Quote:

3) The result needs to be a fully functional processor accurate enough to be genuingly called a 6502. The practical “acid test” is to be able to run a game I wrote for the C64 back in 1983.

Alright then, I couldn’t wait to try it! The game is called Neoclyps, sort of a homage to Defender on the C64. In many ways, I’ve been thinking about building this CPU ever since 1983 — and then “oh joy”, it runs!

This is a milestone I’ve been looking forward to. Man’o’man. What a day ...

[GaBuZoMeu]

Congratulations to your success!! Very cool!

[BigEd]

Major milestone, major success - congratulations Drass!