If you would be (hypothetically) out to build a TTL implementation of the C64, this would cause "a little incompatibility",
because PHI2 then can't be slower than 5MHz.

On the other hand, replacing the jumper with a (software controlled) switch (by adding another chip to the design) would give us some other problems,
because the PLL inside the ZDB needs up to 1ms to lock (datasheet page 6, tLOCK).


Did those 600mA include the SBC (and the LEDs on the SBC) ?

Another interesting question is, how much current the CPU draws from the power supply when running at 1MHz.
From the datasheet, the 6510 draws 130mA max. at 5V.
(Page 3 of the 6510 datasheet)
So maybe plugging that CPU into the 6510 socket of a C64 running at 1MHz might work.

From the manual, TK20 (which stopped to work reliable at 16..20MHz) drained 18W, since it seemed to have a power supply integrated
I think those 18W were measured at the primary side of that power supply.
It's a pity, that we had no success in finding any more technical info about the TK20.
For instance, we don't know if TK20 had a conventional (and not too efficient) linear power supply or a switchmode power supply.

Anyway, 600mA at 5V means 3W, and compared to TK20 we really have a "low power CMOS" CPU.


Amazing !
And considering TK20, that's just 5MHz below the "world record".
Go, Drass, go.

That's fantastic Dieter, thank you for doing this! I knew the problem was related to the BCD carry, but tracking it down would have been quite a challenge.

Yes, the ALU&CU PCB has very little room indeed, but correcting this just might be worth it -- especially if the change does not delay the NMOS BCD path! Certainly it would be great to eliminate this caveat to 65C02 compatibility.

That said, it doesn't seem like something I can patch on the current boards. I'd like to press on with them as they are and then return to this when it's time to order the next revisions. There are a few changes that are going to be needed, and those will trigger some re-routing for sure. That would be the ideal time to deal with this problem as well.

Thanks again for diving into this one (it reminds me of when you tackled decimal mode ARR. Go, Dieter, go! )

_________________
C74-6502 Website: https://c74project.com

Yes, that's true, but the ZDB should enabled only if (1) we're trying to get above 15MHz, and (2) the host system uses the input clock of the CPU as the system clock ("PHI2" on the 65C02 or "PHI0" for the the NMOS 6502). The ZDB is not needed if the system runs from the CPU's output clock (PHI2O), which is a feasible arrangement for the TTL CPU (although not recommended for 65C02 systems).

The SBC uses a Maxim DS1813 to hold reset low for 150ms after startup, so there is plenty of time for the PLL to settle. Of course that doesn't help when switching to it on the fly!

The diagnostic LEDs were off at the time, but the figure is from the power supply display, which would include the SBC.

The SBC (LEDs off) + CPU draw 155mA at 1MHz. It could be close to 130mA for just the CPU.

I love it - "suitable for battery-operated portable applications"
Thanks Dieter. It would great for "Team C74" to set a record ... but those last 5MHz might be pretty tough!

_________________
C74-6502 Website: https://c74project.com

Thanks for the kind words.
You could try in Logisim if the little modification from the C code solves the problem.
But I'm not sure if the flag evaluation would work as intended, especially for the C_Flag.
You better check...


Of course, _if_ you would be building a TTL implementation of the C64, and you would like to have the C64 expansion port in the design,
old hardware that plugs into the expansion port probably would insist to run at ca. 1MHz.
The ZDB can't go below 5MHz, and maybe that's too fast for old hardware cartridges.


Then maybe it's about time to get hands on an old C64 (where the 6510 still is plugged into a socket) at ebay or such.


Why sure.... battery-operated doesn't state anything about the size of the battery.
So using a car battery won't be cheating.


I think that grounding and signal integrity might be an issue for making those last 5MHz.
Good luck with replacing the connectors in those PCBs for being able to stack them.
You need to take a lot of care not to damage any PCB traces when soldering the old connectors out of the PCBs.

BTW: before ordering the next set of CPU PCBs, maybe it would be a good idea to make the signal traces at the connector pins a little bit more thick
(32 mil maybe) for reliability reasons... if there would be enough free space on those PCBs, that is.

I'll definitely try it in Logisim. Just a matter of finding some time ...Ah! Had not thought of that. Thanks for noting it.
That's definitely the plan. One aspect of the project is to test interfacing with various systems - other 65C02 SBCs for sure, but also NMOS systems. It will be very interesting to see if the pinout and bus timing is correct. Also excited to try to run some games that use illegal opcodes and see if at least some of them work! I'll be looking for a C64 in good working order to try that. I do have a VIC 20, but I'm afraid it's a little flaky. I will probably want to find a better one to work with as well.
Thanks. I'll keep that in mind when looking at the next revisions.

_________________
C74-6502 Website: https://c74project.com

Wrestling the bad inter-card connectors off the boards proved a right mess. I ended up tearing a few annular rings from the plated through-holes and otherwise scarring the PCBs here and there - painful. Finally, though, I did get the new connectors on and the assembly properly stacked, with the SBC on top of the CPU. The whole thing is much tidier now, and should provide good signal quality for the 20MHz test:
A quick run confirmed 16MHz operation even without resorting to the SLOW clock. That surprised me, since access to the 45ns ROM exceeds the available time. It suggests either the ROM or the CPU is faster than spec, which is good news either way.

I felt optimistic for the next step, but alas, the CPU refused to run at the target speed. Figuring out exactly why is likely to be very interesting, and I got started today by rigging up an USB Logic Analyzer to the various CPU pins. The test program consisted of a 16-bit increment of the VIA ports running from RAM (at 16MHz to begin with):

Here's the capture:Two Sync cycles in sequence, one 3 cycles long and the next 6 cycles long, corresponding to BNE followed by INC absolute. A little later in the sequence, we see a 2-cycle instruction, which means the branch failed and the loop will go on to increment the high-byte. During the INC instruction, we see A15 go high for the right Read and Write cycles of the RMW sequence. And Finally, the R/W line goes low for the write cycle.

Looking more closely at the write cycle showed that the CPU was producing an address 20ns after PHI2 goes low and well before PHI2 rises again at the 30ns mark. Of course the half cycle is actually 31.25ns long, but sampling is at only 200MHz (which provides a 5ns resolution so we can't expect a more precise rendition of events. Even so, it looks great and the CPU appears to be running slightly faster than spec.
I couldn't make any sense of the 20MHz capture -- some very strange behaviour there. Definitely looking forward to digging into it. The Logical Analyzer can sample 4 signals up to 400MHz, so I'm hopeful it will do the job from here. More debugging to come ...

Cheers for now,
Drass

_________________
C74-6502 Website: https://c74project.com

Fortunately 45ns is only the worst-case limit, and most parts are faster than specified.

Congratulations on the progress. That's a neat-looking sandwich!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The fetch-time of the CPU-internal microcode ROM is even more critical. Nice to know there may be a margin of safety there!

Thanks Garth. Appreciate the feedback.

Cheers.

_________________
C74-6502 Website: https://c74project.com

Gettin' ready to do some debugging this weekend with the Logic Analyzer:I get lots of information by tapping the various CPU pins and using the frequency counter to measure the blink-rate of an output pin. I've started using a 16-bit blinky-light INC loop, which has (16 * 255 + 32)/256 = 16.0625 cycles per blink. It's a good test - the INC instruction runs a full pass through the ALU, with a read and a write to boot, and a BNE after that tests that setting flags and branching works. It's also very easy to see in the LA when the high-byte is incremented every 256 iterations. I managed to get hold of a 35MHz oscillator through the week and confirmed the CPU runs perfectly at 17.5MHz in the stacked configuration. Now it's time to really dig in and figure out what's wrong at 20MHz. On paper, it should work!

_________________
C74-6502 Website: https://c74project.com

Interesting challenge!

I had some thoughts about this. I think how I would do it (not necessarily the only way, or the best way) would be to run tests using Klaus's test suite, with progressively faster and faster clock rates. Maybe this is already part of your plans.

When you get to a speed when a failure occurs, track down the reason for that failure. IOW don't focus too much on the blinky-light program, because it doesn't exercise all instructions and thus is unlikely to reveal the timing constraint you care about most: the one that's the limiting factor for real-world operation.

BTW instead of swapping crystal oscillators, you can consider making a variable oscillator that's continuously adjustable with a trim-pot. Here's a photo of one I use for testing KK's 16x clock (ie, 80MHz, plus or minus). It's basically just a 74AC14 and the potentiometer. It uses a single inverter section and an RC. The pot is the R and the gate's input capacitance is the C. (I don't recall what value pot I used.) I shielded the pot with grounded copper foil but that's probably unnecessary, especially if an actual capacitor were in-circuit. And you'd wanna add that cap anyway to lower the frequency.

Edit: another approach (offering different tradeoffs) is to use a fixed-frequency oscillator but feed its output through a PLL-based programmable multipier-divider IC like this:
-- Jeff

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

For home-made VFOs, see also viewtopic.php?p=10619#p10619 and the rest of that topic. (It's linked in the clock-generation page of the 6502 primer.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I know ... as my daughter would say: "so fun!"

I thought of using Klaus' suite after blinky-light (if I can get it to work, that is). I like blinky because it's easy to follow on the analyzer and it exercises a whole lot of the CPU, including the basic piping. It's true that problems at slower speeds might remain undiscovered until the full test suite is completed, but so be it -- chasing 20MHz just too much fun and I want to see if anything will run at that speed.

Thanks for these suggestions! I was already scratching my head wondering about various "divide-by" circuits. This approach is MUCH better and just the ticket. A "VFO" will certainly be required to find the maximum operating frequency, whatever that turns out to be! For now, I'm heads down running tests using a 40MHz oscillator with the divide-by-2 flip-flop in the SBC. All I can say is, it's sure hard to type with the fingers on both hands crossed.

_________________
C74-6502 Website: https://c74project.com

Before going on to the 20MHz tests, I re-worked the 16-bit blinky-loop to use the 6510 port for the low-byte. We know the time required for the TTL CPU to produce a valid address violates the VIA setup time at 20MHz. The 6510 port, on the other hand, has minimal setup time, and implements a full 8-bits internally (even though only 6 of those are presented at the CPU pins). It was an easy change to the code as far as it went, but of course the 20MHz capture I then ran still looked like nonsense:Looking at it, though, it did seem like R/W was going low co-incident with the rise of PHI2. Without considering much else, that spells trouble, especially given that the measurement is accurate only within 2.5ns. R/W could in fact be missing the rise of PHI2 altogether, and worse, extending also into the next cycle to interfere with, say, an opcode fetch. That would certainly explain the erratic behaviour on the capture.

On the schematic, the signal path for R/W looked suspicious immediately:The tolerances at play in the CPU are very familiar by now, and it’s safe to say three gates in series are just bound to cause trouble. Sure enough, MEM.W, which indicates a write-cycle, comes from the microcode through a decoder, and right-away, we’re beyond the 25ns half-cycle and in the red-zone:Interestingly, that turned out to be just fast enough for the 17.5MHz test that succeed previously, but it’s certianly not good enough for the 20MHz target.

The "DPH+1" signal going into the first (OR) gate in the sequence above is used only by a three undocumented opcodes. It allows the CPU to combine an increment of DPH with a write to memory in the same cycle. An easy fix, therefore, is to split the two operations into two consecutive microcode steps. Of course, that would make the CPU cycle-inaccurate, so a better option is to replace a couple of these gates with faster 74LVC1G equivalents and get R/W down in time. Now that requires a new PCB, so for now, I decided to just patch the existing board and bypass the initial OR-gate to put MEM.W straight into the 3-AND gate in the series. The next rev of the boards can include the permanent fix.

After the patch, the increment of the 6510 port seemed to work, but then the CPU went crazy on the high-byte. Just to validate, I limited the increment to 8-bits and took a capture:This looked great! R/W is behaving itself and going low for the write-cycle of every INC instruction (which start at the second SYNC pulse of every pair). The low-bit of the 6510 port is also blinking nicely. All very encouraging, but what was wrong with the high-byte? The BranchTest signal-path was fine and so was the early BranchExit logic. Certainly there is nothing different about the second INC in the loop. Could be some sort of signal integrity problem? After a pause, the CPU seemed to run correctly just once before things went haywire again. Temperature? No way, really? ...

Then it hit me. I remembered the video Garth pointed out, which warns of the potential perils of probing a board that has high-edge rates. Suddenly, those test leads on the cheapy analyzer looked mighty long and noisy to me! I pulled them all off the CPU pins and left only the frequency counter on the low-bit of the 6510 port. Fingers crossed: if everything worked, it would cycle at just under 1.25MHz ...

Tada! ...
Man, it was the probes! Amazing! The blinky-loop was now running at 20MHz. Next up was the Dormann test suite, which I had re-jigged to repeat endlesley. I recall that each iteration had taken about two minutes at 1MHz. Now the TTL CPU was striding along, completing each in less than 5 seconds! Woweee ...

Ok, lots more validating to be done, but it may be root beer time again!

_________________
C74-6502 Website: https://c74project.com

Nice! Go, team C74, go!

Thanks leepivonka! After a hiatus for the holidays, testing has now resumed. The good news is that 20MHz operation appears stable, which is great. But a problem surfaced with the 6510 port and it's got me stumped.

It has to do with the port's chip-select signal at high clock-rates. The address detector circuit driving the chip-select works just fine at clock-rates below 16MHz. Above that, it gets pretty interesting: if the code reading or writing to the 6510 port is executing below $0400, as with the blinky-loop above, it all works perfectly. However, if the code is running higher in memory, the chip-select does not turn on and the 6510 port fails. (Frustratingly, any reads and writes go to the RAM "behind" the port in that case, so everything seems well as far as the code is concerned. Tricky , I only noticed a problem when I hooked up some LEDs and saw nothing happening with the port).

The address detector circuit is top-left on the 6510 port schematic:PB.CS is the chip-select signal in question. The address bus lines A[15..1] come in at the bottom of the detector circuit and pass through some 3-input NOR gates. Interestingly, addresses above $0400 have at least 1 bit high in A[15..10], and these bits go through the rightmost AND gate (74LVC1G11) above the NOR gates. For some reason, PB.CS fails to turn on when the bus address immediately preceding a read or write of the port is $0400 or above (as it would be if the code executing resides in memory at $0400 or higher) and this particular AND gate needs to transition it's output -- BUT, this only happens at high clock-rates.

Don't know why A[15..10] should be any different than A[9..1], nor why this IC misbehaves at high clock rates, but therein lies the mystery. I can't actually confirm exactly what's happening though -- the circuit fails the moment I touch a probe to the output of that AND gate, even with a slow clock! Probing anywhere else is fine, but that trace is very touchy for some reason. Digging deeper will have to wait until next weekend, but I thought I would share the adventure in the meantime.

On a different front, I've ordered some ACT parts to deal with the TTL voltage levels of my VIC 20, which now sits open awaiting a CPU transplant. The CPU can be made to accept TTL levels by replacing a couple of socketed DIP parts with "T" variants. Should be straight forward, but it's going to be interesting to see if the thing runs after the procedure!

Cheers for now,
Drass

_________________
C74-6502 Website: https://c74project.com