Overclocking an 8-bit computer

Question

I've been thinking about the possibility of overclocking 8-bit computers of the late seventies and early eighties, and it seems to me that the things most likely to break, would be:

1. Cassette save and load routines, on all computers that used cassette tapes; these are inherently timing-sensitive, and if you change the clock speed by more than a few percent, you lose interoperability with tapes written by the original hardware.

2. Sound in cases like the Apple II and CoCo, where instead of a tone generator you have a DAC that has to be toggled by the CPU at the desired frequency.

Is this a correct assessment? In particular, are there any computers that use cassette tapes in a way that would not break if you change the CPU speed?

Answer 1

If you're changing just CPU clock speed, leaving the other components as is then amongst those that would continue to read tapes correctly are:

The Vic-20 and the Commodore 64. In the case of the Vic-20 tape input is connected to one of the control lines of a 6522 VIA. Wave length determination is achieved by loading a timer on that VIA and checking its value upon the interrupt triggered by the change in the control line. So if the VIA retains its original clock, tape loading will work as per usual. The same is true of the C64, but substitute a 6526 CIA for the VIA. You'd have to change your disk signalling routines though, because they're entirely dependent on the CPU toggling lines.

The BBC Micro and the Acorn Electron. In the former case a serial ULA feeds a Motorola 6850 ACIA. In the latter case a custom ULA does the whole thing. But in both cases the CPU does whatever it is normally doing and is informed by interrupt of tape events.

The MSX would likely not be affected for many pieces of software, depending on the degree of overclocking. It picks the speed it thinks data is on the tape based on measuring the initial tone, and supports a range from about 600 baud up to about 3600 baud. Commercial tapes are likely to be at around 1200 baud because it's one of the two fixed speeds built in for saving, and is more reliable than the alternative faster 2400 baud. So you could probably double the CPU clock rate and the BIOS would still cope — 1200 baud would look like 600 baud.

Machines that would definitely be broken that I'm aware of, in all cases because the CPU directly polls an input bit and counts time for itself:

• the ZX80, ZX81 and ZX Spectrum;
• the SAM Coupe;
• the Amstrad CPC*;
• the TRS-80 Model 1.

On the Oric tape input is wired to CB1 on a 6522 but I've never disassembled the ROM to figure out whether that is counted against a 6522 timer like the Commodores or something else. So that could go either way.

*) with the caveat that on the 464 and 4128, the tape drives are built in. So if you're modifying the machine, you could try just also overclocking the speed of the tape drive and hope for the best in terms of analogue filtering. Definitely worth a go in the scenario where you've managed to overclock the CPU somehow. And the same comment goes for the Amstrad Spectrums.

Answer 2

Since you mentioned the Apple II, it is worth pointing out that accelerators were available for that platform "back in the day". I can speak to how the CPU replacement ones worked (e.g. Zip/RocketChip) since some others simply took over the bus and some did RAM mirroring with faster SRAM which is a bit more complicated than a simple overclock.

As with most of the other platforms at the time, much of the machine was driven by a single clock. If you increased this clock, you'd effectively speed up everything. However, you'd also speed up non-software things such as its concept of the NTSC video signal timing which wouldn't be desirable. I've read that a system clock replacement with the Commodore VIC chips would cause similar issues.

The approach the Zip / Rocket chips took on the Apple II was that the CPU had its own clock for instruction speed and thus was able to drive the bus faster because it was working and signaling faster. Video display wasn't corrupted because it was still using the original clock from the main board. While this works well for most of the system, there were a few parts which couldn't get sped up and thus the CPU had to be conscious of this and throttle itself down to 1MHz as appropriate. In particular, the 5.25" floppy disk controller was entirely software timing based and would fail under anything but stock speeds. So while the platform could be running at (say) 4MHz, it would slow down for floppy access and then speed back up when finished. Given that floppy access was always a blocking operation on the Apple II, you wouldn't notice the machine slowing down.

The RocketChip came with a few utilities that allowed you to tweak what parts of the system would be subject to throttling. This included the speaker, standard ROM WAIT routine, and then some aspects of each expansion slot (floppy disk was done by throttling any access to slot 6 - the standard 5.25" controller slot). With some experimentation, you could find out what combination worked best and what expansion devices didn't mind being sped up.

So what does this mean in general? If you were able to increase the speed of the clock signal to the CPU itself, you could probably achieve a somewhat compatible overclock. However, there most likely are aspects of the target platform that wouldn't like the CPU being fast and thus a simple clock replacement may not cut it.

Answer 3

And the main problem here is that in most cases, you'll have to overclock the entire computer, not just the CPU.

For example, in ZX Spectrum CPU clock is generated by ULA, so you'll have to overclock it in the first place.

In C64, CPU works in tight sync with VIC, so again overclocking CPU means overclocking VIC.

And then, once you overclock video chip, you'll get complete garbage instead of video signal out of it:

• Frame rate will increase
• Line frequency will increase
• Color subcarrier frequencies will increase

So even overclocking it to 10% would lead to colors failing and probably to sync fail in TV.

Answer 4

I think your bigger problem is going to be dynamic RAM refresh. Particularly in Z-80 systems where the CPU controls DRAM timing, overclocking already tight memory timing specs are undoubtedly going to cause glitches.