6502.org

Ok, back to the matter at hand. As I mentioned, things were all set up for a C64 test. I was hopeful for a fist-time run, but no go! Nothing but a blank screen! Dieter sent me this amusing link to a "Commodore Diagnostician" chart confirming that a faulty 6510 IC would in fact cause a blank screen. Ah, good to know!

After confirming that all the pins on the 6510 pinout header were hooked up correctly and working, it was time to have a closer look. The analyzer showed PHI2 working nicely and lots of activity when /RS went high. I could see the CPU trigger the RESET sequence, but there was nothing on the address lines that looked like a fetch of the RESET vector.

One thing I noted was the BE signal (AEC on the 6510) changing state more or less in phase with PHI2. This is as it should be on the C64 since the CPU shares the bus with the video (VIC) chip. The VIC chip drives AEC low in PHI1 and takes over the bus; then it drives AEC high again for PHI2 and relinquishes the bus to the 6510. That means only address values in Phi2 are from the CPU, but these still looked random at best.

After some head-scratching, the problem became apparent. The bus management scheme on the TTL CPU drives the internal address bus (ADL/ADH) only during PHI1 to avoid collisions during transitions. There are bus transceivers between the internal and external address bus which the BE signal enables. However, I replaced the 74AC245s which were performing that function with faster CBT parts as part of the nanosecond-hunt to 20MHz. That has worked fine to this point, with BE always held high, but now on the C64 there is nothing to drive the external bus in Phi2.

74CBT3245s are only FET switches and, unlike 74AC245s, they provide no drive at all when enabled in Phi2. They only end up connecting together an un-driven internal bus with a floating external one. There are bus hold ICs there, but I suspect those don't have enough oomph to charge the external bus by themselves. No wonder things looked strange on the analyzer.

So, the fix is to put those 74AC245s back (the footprints are compatible with the CBT parts, which is nice). Speed is not an issue when working with a C64, but earlier tests also showed that the critical path at high speeds is in fact R/W, not the address lines. It's likely that 74AC245s will do just fine in this role for keeps.

Now, having no spare 74AC245s on hand, I decided to make a quick patch to temporarily disable the bus-management scheme just to prove the point. That seemed to work, but unfortunately it's still a blank screen when power is applied.

Even so, it's progress. I can now see the address lines behaving properly and the CPU picks up the reset vector at $FCE2 correctly. It then jumps to and executes this code:

LDX #$FF
SEI
TXS
CLD
JSR $FD02

Now THAT looks better!

But, we still get a blank screen. Hmmm, this one 's gonna be tricky ...

Found a disassembly listing of the C64 ROMs here.

JSR $FD02, this subroutine checks for presence of an autostart ROM at $8000.

Would be interesting to know, if the RTS at $FD0F (at the end of this subroutine) works as intended.
Hey, if it would be easy, some more hobbyists would be building TTL CPUs.
Keep up the good work !

Yup. Good idea. I’ll check this next.

Out of interest, I looked up the code snippet in the Kernal ROMs that modifies the 6510 port: And here is the reset sequence: It will be interesting to see how far along the CPU gets ...

Datasheet for the 6510 can be found here and there.
It's funny, that RDY and the RDY timing don't seem to be mentioned in those datasheets.

Datasheet for the VIC-II is here, sort of a timing diagram is at the end of the datasheet.

Don't have a datasheet at hand for the 4164 DRAMs, sorry.

;---

In my opinion, we should check if OurCPU releases the bus too early after the falling edge of PHI2 (compared to the 6510),
something like this could have the effect that the data written to the DRAM might be getting corrupted,
including the return address pushed on stack during the first JSR instruction.

So it's an interesting question, if the CPU correctly makes it back to $FCEA from the first RTS at $FD0F after a RESET.


Hmm... on the 'Card A_Registers' PCB, you could try to remove the R100 pullup resistor, change R47 to 4k7..10k,
and then see what happens if OurCPU responds to AEC a bit slower.

Maybe it's about time now to buy an oscilloscope, would suggest to go for a used Tektronix TDS2024 at ebay.
If the price for an oscilloscope won't matter, take a look at Rohde&Schwarz.

Good luck with debugging !

Time to share in the fun!

Just had enough time for a quick capture ... It's easy to see the effect BE (AEC) has, causing some odd behavior in signals in various places as the bus is exchanged between the CPU and VIC. The first cursor in the capture marks the end of the SYNC cycle of the JSR $FD02. The second is at the RTS that follows. It seems the CPU is NOT making it back (good instincts Dieter ). The value written to the stack appears to be $FCE9, which would be correct. But the RTS reads back $48FF ?? -- not good.

As a reminder, here is the code being executed: R/W sure looks a little strange on the first write cycle of JSR. It's going low early in Phi1 and it appears that the VIC chip is driving it high again when it takes the bus. Then the CPU takes it back low when it gets the bus back. Not sure what's going on there but it might not be benign. Here is a closer look at the write cycles (for reference, we're sampling at 100MHz):Alright, gotta run ...

That R/W glitch to LOW starting at ca. +30.40us looks odd.

IMHO it looks like OurCPU changes its outputs (including R/W) faster after the falling edge of PHI2 than the 6510 does.
So OurCPU strobes R/W to GND for a short moment after the falling edge of PHI0 before BE (AEC) takes effect.

R/W then goes back to HIGH because of bus line capacitance versus R51, a 1k5 pullup resistor to +5V in the C64.
R51 is in the south west corner of page 2 of the C64 schematics.


But that R/W glitch doesn't explain why RTS is reading garbage.
Feels like something odd happens on the address bus at the falling edge of PHI0, too.
Edit: 'something odd' from "the point of view" of the 4164 DRAMs maybe.

Yes, seems plausible. I won't be able to investigate until the weekend. For now, just managed to run a capture with some address lines:Certainly there is some movement there triggered by BE (AEC).

I had a peek at the C64 schematics. R/W goes directly to /WE for RAM, without being qualified. I don't know how dynamic RAM works, but according to this datasheet, the write cycle can be controlled by either /WE or /CAS. I am assuming it must be /CAS on the C64 since R/W is unqualified. Maybe a capture showing /CAS will clarify the timing?

IIRC the DRAM write cycle is controlled by /CAS, /CASRAM from pin 18 of the address decoder PLA that is.

Those glitches on the address lines pretty much are looking like that glitch in the R/W signal,
and I take this as a sign that OurCPU changes the address lines too fast after the falling edge of PHI0
before AEC takes effect. And I think this might be a bit "confusing" to those DRAMs.

Ok, forget tinkering with the AEC signal, try delaying the PHI0 input of OurCPU instead... maybe by 50ns or so.
On the 'Card A_Registers' PCB, try to change R37 to 1k .. 4k7 and see, what happens to those glitches.

Of course, delaying PHI0 also means that the data to be read from the CPU has to be stable for a longer time
on the data bus, but I think for using the CPU in a C64 this won't be too critical.


Hmm... when building the next CPU, it would make sense to use transparent latches as buffers for all of
the output signals of the CPU for getting around that sort of timing problems somehow.

On the C64 data bus, we don't have bipolar (74LS) loads.
For the address bus, it's different.

A15..0: 74LS257 2:1 MUX -> DRAM
A11..9: 74LS139 decoder
A15..12: 82S100 address decoder PLA // 82S100 is bipolar. Later, 7700 and 8700 manufactured by MOS were NMOS.
A15..12: RP4 3k3 pullup resistor to +5V

;---

Found some info about the input\output characteristics of 74LS chips at TI:
Design considerations for logic products, 1997, file size is ca. 11MB.
Page 1-69 (page 87 of the PDF).

74LS pin capacitances (2.5V at the pin):
Input: 3.5 pF
Open collector output of gates and output with low drive capability: 3.5 pF
Bus driver: 5pF

Just in case that somebody at TI might notice that somebody has linked to an _old_ PDF that still happens to be on the server
and then decides to remove it, I would strongly suggest to make a backup of this PDF.

Had some time for a closer look. From the 4164 DRAM datasheet: Not sure I have this right, but it appears that the DRAMs have latches internally and capture the row and column addresses on the falling edge of /RAS and /CAS respectively. On my C64, the DRAMs are HM4864-3 ICs. For these DRAMs, the Row Address Hold Time (tRAH) is 25ns and the Column Address Hold Time (tCAH) is 55ns. The setup times don't seem to be an issue, so it seems everything should work if we meet the hold times. Here is a capture showing a relevant write-cycle:The "glitch" on A0 is clearly evident, but it happens over 200ns after /CASRAM has gone low, and presumably also after both row and column addresses have been safely latched.

I agree that absent the internal latches, the timing is a problem (and of course, we do have a problem since the machine won't boot!). The glitch on A0 is clearly triggered by things happening "too fast" after the fall of PHI2 (btw, who knew "too fast" would turn out to be an issue!). If the address lines have to remain stable until /CAS rises, then for sure the glitch will "confuse" the DRAMs. Delaying PHI0 is a clever solution in that case (which would have never occurred to me!). Your estimate of 50ns for that delay seems about right based on the LA capture.
I agree. The above capture shows that the data lines remain unchanged for quite some time after the fall of PHI2. There should be plenty of time to grab the data on a read even with a delayed input clock.
I remember you tried to explain this to me before, many months (years?) ago, and I remember also not understanding it then! Now I get it. Maybe a special C64 socket-adapter is in order, one that incorporates some transparent latches enabled by /PHI0 for the address bus. For now, I'm very open to trying the PHI0 delay to see what it does. I do wonder, though, if the DRAM latches mean that something else might be going on.

On another note, thanks for sharing the TI Application Book! I was interested to read the section on "Bus Conflicts" which happened to start on page 86. I always find these things so interesting!

Looks like the DRAMs have latches internally.
The timing diagrams on page 4 of the PDF are a bit hard to read, but I agree on the address hold time values for tRAH and tCAH.
The setup times don't seem to be an issue.
Of course, after some years of working in hardware design your confidence in chip datasheets might become somewhat... limited.
Looks safe, but at the moment those glitches are the only hint we seem to have.
BTW: at which frequency your logic analyzer samples those signals ?
Timing in a C64 is a bit tricky, and if something is too slow or too fast the C64 won't be running stable.
Hmm... if we would have wanted a computer that won't be running stable we just would have bought another PC instead of building a CPU.
I think that the problem is more related to the address bus than to the data bus.
If delaying PHI0 won't fix the problem, maybe we would be going to need a logic analyzer with more inputs...
...don't worry, building your own logic analyzer ain't too difficult (except for transferring the sampled data to a PC and processing it there).

Edit: buying a used HP1630D at ebay might be cheaper than building your own logic analyzer.
Edit2: check shipping costs for "boat anchors" first.
Ja, tried to explain this to you in 2016. But back then, to me it didn't look like a real and serious problem.
Point is: as a hardware designer, you are getting paid to be a little bit paranoid about what could go wrong with your design,
so if you "smell" that something in a design could cause trouble later, your duty is at least to mention that possible\hypothetical problem.
IMHO speculating about what might have gone wrong and how to properly fix it would be a waste of time and effort now.
First, we need to collect some more "evidence" for identifying the source of the problem, and it feels like delaying PHI0 would be a good starting point.
Ja, there might be "issues" when bringing together chips from different logic families on the same bus.
Insisting to have resistors plugged into a socket for all of the signals between the CPU and the host computer sure didn't simplify
making the PCB layout, but it might simplify debugging now.

About delaying PHI0:

The simplest/crudest way to go is to "experimantally" change the value of R37 on the 'Card A_Registers' PCB,
which forms a low pass filter together with the input capacitance of IC17 (74ACHT132).

;---

A nicer approach would be building a delay chain from 74AC (74ACT ?) logic and to tap into it by using DIP switches.
Here a picture from the schematics of Dennis Kuschel's MyCPU:
Would work with 74245 instead of 7408, too.

;---

Maxim is building delay lines, DS1135 looks nice.
Unfortunately, DS1124 delay needs to be set by SPI.

I spent some time tinkering with resistor values to delay the input clock to the CPU -- with mixed results.

First the good: the capture below shows that the address lines are now clean and steady through the write-cycles of the JSR.A 2k resistor delays PHI0 just enough to be nearly co-incident with BE. As a result, the bus is in the hands of the VIC chip when the CPU changes the address lines after the fall of PHI0, and the glitches are gone. There are still some glitches on the data lines when BE rises, but there seems to be plenty of time for the data to settle. I'd say it looks pretty clean at this point.

On power-up, the screen now shows the standard border and square display area. It's in black and white and there is no text, but it still seems an improvement. Perhaps the VIC chip is a little happier with the timing.

Now the bad: the RTS still fetches an invalid address. It seems something else is messing up the works.

Not quite sure where to go next ... one possible line of inquiry is to look at what's happening closer to the DRAMs as the write is being executed. Up to this point, I've been tapping most signals at the CPU, but it may be that somehow things get messed up elsewhere. There are a pair of 74LS257s on the address lines that switch between the ROW and COL addresses as /RAS and /CASRAM are pulsed (top left here). It might be revealing to take a capture of the signals there with the CPU and the 6510 in turn. Perhaps that will catch this elusive little gremlin in the act! We'll have to see ...

Sorry to hear this.

First:
The cheap 40 pin 6510 socket on the C64 motherboard isn't designed for many insertion cycles.
Replacing a defective 40 pin socket on the C64 motherboard won't be fun,
especially if PCB traces would be getting damaged during the process.

Would suggest to take a 40 pin precision socket, to solder a 40 pin ZIF socket on top
(because the 6510 socket on the motherboard might be getting damaged when plugging the ZIF socket _directly_ into it),
then to plug the precision socket into the 6510 socket on the C64 motherboard.


Second:
When looking at the timing diagram above, IMHO R/W changes a bit too fast after the rising edge of /CASRAM,
same thing for the address and data lines, too.

Would suggest to run the C64 with an original NMOS 6510, and to check the signals with a logic analyzer again.
This way, we know for sure what those signals are supposed to look like before we start "creatively tinkering"
with PHI0, AEC and maybe R/W of OurCPU.

65C02 in a Beeb, and HM4816A-3 DRAM timing.

Now that's interesting: the HM4864-3 DRAMs in our C64 are from Hitachi, too.