Close

CPU

A project log for LittleSixteen - Commodore 16 Mainboard

Let's do justice to this mistreated machine, at last!

SukkoPeraSukkoPera 4 days ago0 Comments

The C16 architecture is mostly based on off-the-shelf integrated circuits. There are only three custom chips: the CPU, the TED and the PLA. Let's focus on the CPU for a start.

The C16 CPU is a MOS 7501 or 8501 (x501 from now on), which are actually the same thing as far as we are concerned (they are just manufactured with different processes, which is beyond our scope). Finding one of these chips at a reasonable price is next to impossible and that is because they have a notorious tendency to self-destroy after a while, which is exactly what had happened to the very C16 I got in 1988, even though it took me more than 30 years to find out. This means that only a few have survived and those are much sought after by people wanting to repair their broken C16s (or Plus/4's).

So let's see what this chip is in detail, maybe we can find an alternative: the MOS x501 is a CPU based on a 6502 core with a few additional features, such as a tristatable (does such a word exist?) address bus, an integrated 7-bit I/O port and the ability to run at 2 MHz. Does that ring a bell? Yes, those extras sound similar to what was implemented in the MOS 6510, the CPU used in the Commodore 64.

While I certainly don't want to suggest people to rip CPUs out of their C64s to make C16s, that means that 6510 CPUs are definitely easier to come by, so wouldn't it be great if we could get a 6510 to work on our C16? It turns out this is actually pretty easy, all that is required is a rather straightforward remapping of the pins. There are only two points that will require some thought:

The first thing you'll notice is that there's no obvious match for the x501 Gate In pin. There is a lot of misinformation about this signal, even though its description in the TED System Manual is quite clear:

TTL level input, used to gate the R/W line to prevent the R/W line from going low during a read cycle, before RAS and CAS go high (resulting in a Read/Write cycle). Normally connected to the MUX line in a system configuration to synchronize the DRAM memory cycle to the processor clock cycle.

If AEC is low when Gate In makes a low to high transition, the R/W line will go to a high impedence until the next transition of the Gate In line and AEC is high prior to the transition.

It even has a timing diagram to make that even clearer. More recently, some clever people have dissected and reverse-engineered the die of the 8501 CPU, which should hopefully settle all questions. In any case, it turns out that DRAMs might be able to handle the unmodified R/W signal correctly, so this pin can be left unconnected as a first attempt (it is pulled-up internally anyway). I don't have the skills to come up with any useful observations about this but I might have a go at a circuit that can replicate the Gate In logic later on.

The second issue is that the 6510 only has a 6-bit I/O port, while the x501 has a 7-bit one and the individual bits are even numbered differently (for some odd reason there's no P5). Of course there's no perfect solution for this, one of the pins must be sacrificed and the others rearranged. Luckily someone has already taken care of this burden and that is Andrew Challis, who has built a functional 6510 to x501 adapter and shares all the information needed to recreate one. He ditched the pin that is in charge of controlling the Datassette motor (P3) and replaced that with a diode on the mainboard, so that the motor will spin whenever one of its keys is pressed. This means that the tape will run to the end when the loading of a game is finished unless it gets stopped manually but it's a necessary compromise. It might be an issue on multi-program tapes though. Andrew also did some clever remapping of the other bits but he had to patch the KERNAL in order to maintain full functionality of the Datassette and of the IEC bus (i.e.: of the floppy disk drive). This unfortunately implies that disk fastloaders will not work (unless modified in turn), but since most people today will use an SD2IEC, which isn't compatible with most fastloaders either, this is not going to be much of a problem.

OK, since we can get a C64 CPU working on a C16 somehow, why not integrate it into LittleSixteen? So I did, following Andrew's design, here's what it looks like:


I placed the diode for the Datassette motor in the top left area, together with an additional pull-up resistor for added insurance:

Someone might argue that there are other open projects striving to come up with a 1:1 x501 replacement out there that would require no modifications to the CPU pinout, but none of them is really ready for "production": solutions using similar CPUs always have issues with the I/O port, while "synthetic" solutions (i.e.: reimplementations of the 6502 core on FPGAs) struggle with the so-called illegal opcodes, which might seem a marginal problem but which is just a different compromise. Therefore, all in all, I thought this solution was good for the time being: it will definitely be better than having a non-working C16 and will not prevent using the original CPU anyway. It wasn't even too big an effort to be honest ;).

Speaking of similar CPUs, while discussing the subject, Jani made me aware that the WDC65C02 is a 6502-based CPU that is still in production and officially runs at speeds up to 14 MHz. It is a CMOS variant which might not implement all the illegal opcodes (it actually has 2 new "official" opcodes), but it could be a very good candidate for an x501 replacement if it did, provided that the missing features (I/O port and tristate address bus) are reimplemented somehow (i.e: CPLD or discrete logic). Another promising project is MockA65xx by androSID, if the final design and code will be made open as promised.

And here's a fascinating suggestion...

Discussions