6502.org

It sounds like you're right on top of it. I have complete faith in your ability to complete the diagnosis and repair.

Mike B.

#metoo

Thanks for the vote of confidence gents! After lots more futzing and diagnosing, I finally relented and replaced that suspicious AND gate -- and indeed that fixed the problem. I can't be certain that the issue was in fact a faulty IC, or perhaps a bad connection somewhere was cleaned up as a side effect of re-soldering - but be that as it may, I'm much relieved it was not a more serious problem!

After confirming correct functioning of the 6510 blinky-loop high in memory, I turned once again to the Dormann test suite. I had modified it to write the current test number to the 6510 port so it was a pleasure to watch it's progress live (although only the exhaustive binary and decimal arithmetic tests actually take long enough to perceptibly blink the LEDs on the port). I ran the suite continuously for a couple of hours at 20MHz with no issues. I think it's safe to say that this much at least seems stable!

I've made a start on building the VFO as per the suggestions above (thanks Jeff and Garth), and I'm looking forward to pushing the CPU to its limit. We'll have to see whether it can exceed the theoretical 20MHz ceiling ... [cue drum roll ].

Cheers for now,
Drass

One of the objectives of the project is for the TTL CPU to be "plug-in" compatible with the target processors. So far we’ve managed to replace the WDC 65C02 on the C74-SBC. But it’s one thing to run tests on a purpose-built machine, and quite another to step into the shoes of an original NMOS 6502 in a vintage system! The plan was to start with my VIC 20 and put the CPU through its paces with a first “real-world” challenge!

To get the CPU ready, a couple of ICs needed to be replaced with ACT variants, and the 6510 port disabled. Pin 1 is grounded in the VIC 20, so the /VP jumper must be disabled on the CPU side. Pin 5, on the other hand, is floating on the VIC 20, so it was safe to leave /ML alone. Finally, the TTL CPU has a pull-up on pin 36 for BE, so again it could be left alone. All other pins are as on the 65C02. And so with that, I plugged in the ribbon-cable into the NMOS 6502 socket on the VIC 20, and things we're ready to go.

It was a little nerve-racking to flip the power switch, but after just a moment, the screen snapped on! Honestly, I was NOT expecting that! That 6502 IC was first installed in or about 1983. Now the TTL CPU sat in its place and the computer knew no difference.

Here are some pics to mark the occasion …
I spent a pleasant couple of hours running some programs and playing various games -- and ne'er a glitch. In the end, I couldn't help but pay a little homage to the original! From 1983 to 2018 - a wonderful 35 year journey.

Fantastic! A brain transplant.

Congratulations !

Playing games would be more fun on a C64, of course.
Go, Drass, go.

I'll bet you let out a whoop! I know I would have.

Go, Drass, go!

[Wait, what? ... screen is on ... cursor is blinking ... what does that mean? ... must be the CPU ... yes, it's the CPU doing that! ... Wooohooo!]
Coming soon (I hope). The C64 requires that the 6510 Pinout Header on the CPU be used, and that pin 6 be bypassed on the Adapter for VDD. Rather than fuzzing with the existing Adapter, it was best to build a new one. Easy enough, but then there was the matter of acquiring a C64! Anyway, all preparations having been made, the plan is to run the C64 test this weekend.

On a related note, I will also want to test with software known to use Undocumented Opcodes. Does anyone know where I might find a list of such software?
Yeah, I know! And you gotta love how unabashedly impractical it is. I mean honestly, replacing a perfectly good IC with two densely-packed PCBs that only replicate its function -- engineering blasphemy!

It can hit 20 times the speed of the original chip. I'd say that capacity is a net improvement on the original.
Mind you, it's possible to do almost the same thing in less space if you adapt a 65C02. But that wasn't the goal of the project, though, was it?

I think that since you achieved your goal, it's perfectly fine. This is a hobbyist thing after all.

Yup!
No kidding! The ratio of benefit versus invested resources is so bad it makes your ears pop just thinking about it!

Usually that sort of achievement is only possible with government assistance.

Nah... we should see this from a different point of view.

In the 70s and in the early 80s, computers were not powerful enough to simulate a whole chip.
So it wasn't unusual to build a TTL prototype of a CPU for testing the concept before building the real chip.
Motorola did this when designing the 6809. // Page 24 of the PDF: 10 PCBs with 80..120 chips each.

Also, there had been a 68020 prototype at Motorola, built from 300 MSI chips on 14 PCBs.
Compared to this, OurCPU is a quite small and compact thing.

Considering the pictures of the Lorraine prototype which eventually had turned into the Amiga,
maybe the idea of building a "TTL equivalent" of a whole C64 isn't as crazy as it may sound...


...So what we are doing here actually is some sort of "de_prototyping".

It was designed to make 20MHz. It seems to run stable at 20MHz. We haven't tried "overclocking"... yet.
Well, the "target machine" is a C64, and some of the C64 software uses those "illegal" NMOS 6502 instructions...
which the 65C02 lacks, sorry. Adding them to a 65C02 means re_inventing Jeff's KimKlone or such.
The nice thing about hobby projects is, that you can put as much time and money into a project as you like,
without that "the suits" stubbornly and constantly will battle you for fractions of a cent.

But it's nice to have a future_proof design:

If WDC should stop manufacturing chips (hopefully not in the near future),
if FPGAs would be getting "impractical" for the mere hobbyist due to IDE software bloat and fancy chip packages,
and if the (not infinite) supply of old 6502 chips at ebay would decline,
We now have proof that building a 6502 compatible CPU running "at a reasonable speed" from non_proprietary parts can be done.

BTW: There were some other projects about building a 6502 compatible TTL CPU in the internet, but AFAIK none of them went faster than 4MHz.

Dang !

8502 has a different pinout than 6510, so we can't plug OurCPU into a C128.

Compared to the 6510, 8502 lacks the PHI2 output, but has an additional I\O pin instead:
P6 is tied to CAPLK_SENSE at the keyboard connector, 3k3 pullup resistor to +5V.

Also, P5..0, D7..0 and R/W are "shifted up" by one pin.

;---

Edit: the CAPLK_SENSE signal in the C128 schematic is pulled to GND by the 'CAPS LOCK' key,
so P6 is supposed to be an input by default.

Wikipedia about the C128 in C64 mode:

"Some of the few C64 programs that fail on a C128 will run correctly when the CAPS LOCK key is pressed down
(or the ASCII/National key on international C128 models).
This has to do with the larger built-in I/O port of the C128's CPU.
Whereas the SHIFT LOCK key found on both C64 and C128 is simply a mechanical latch for the left SHIFT key,
the CAPS LOCK key on the C128 can be read via the 8502's built-in I/O port.
A few C64 programs are confused by this extra I/O bit;
keeping the CAPS LOCK key in the down position will force the I/O line low,
matching the C64's configuration and resolving the issue."

;---

Edit:
After checking on a real C64 how P7,P6 work, it appears that my memory was wrong there: It's been a few years.

$0000 is the direction register, a Bit set to '1' means output.
$0001 is the data register.

When P7\P7 are configurated as output, if the P6\P7 Bit set to 1 in the data register it reads back as '1'.

But when P6\P7 was configurated as output and the P6\P7 data Bit was set to 1,
and then changing the direction of that P6\P7 port Bit to "input",
after 0.2s .. 0.25s the P6\P7 data Bit reads back as '0'.
(0.25s with a cold 6510, 0.2s after one hour of system uptime.)

So that could be done just with tinkering with the values of the P7,P6 pulldown resistors R102, R101
on the 'Card A_Registers' PCB.

;---

Being able to plug OurCPU into a C128 isn't one of the project's goals, it just would be "the icing on the cake".

IMHO it could be done when making a special 40 pin adaptor PCB for plugging into the 8502 socket of the C128
to compensate for the different pinout of the 8502, and to use one of the GND wires in one of the flat cable
between OurCPU and C128 as I\O port signal P6.

But this solution would be a kludge, of course.

Don't know, if we have enough free space on the 'Card A Registers' PCB to make P6 a true I\O pin,
maybe it would do if P6 is an input only.

And we probably would have to add another resistor plus a solder jumper to OurCPU.

Yes, that's true. But to be fair, 65C02 compatibility, Undocumented Opcodes, 24-bit Addressing, 20MHz, etc. all these were also "icing on the cake" at one time! We have a very poor track record of resisting feature-creep.
I agree that a special adapter can be kludged to manage the pin re-assignments. But P6 is an issue. At one time there was a full 8-bit port on the schematic, and pull-downs on P6 and P7 to boot. But then I stole the input tri-state buffers for P6 and P7 (to use between the WAI driver and the RDY pin, and to tri-state R/W if BE is low). Those two bits can only be output. Too bad.

Hey, that's interesting: I could use the P7 output tri-state buffer for R/W and put the P6 input buffer back. As you say, one of the GND pins on the 6510 pinout header might accommodate P6. That would provide full functionality to P6.
As is, P6 will default to "0" so C64 programs running on the C128 will in fact see that I/O line low. But the better solution is probably to implement P6 as above for full compatibility.

I'll make a note of all this -- there is more than enough to do already, so it's something for another day for sure. Thanks for tracking it down Dieter!