The most collectible items in the realm of vintage computers often weren’t the most popular of their era. Quite the opposite, in fact. Generally the more desireable systems were market failures when they first launched, and are now sought out because of a newly-appreciated quirk or simply because the fact that they weren’t widely accepted means there’s fewer of them. One of the retro computers falling into this category is the Apple III, which had fundamental hardware issues upon launch leading to a large recall and its overall commercial failure. [Ted] is trying to bring one of these devices back to life, though, by slowing its clock speed down to a crawl.
The CPU in these machines was a Synertek 6502 running at 1.8 MHz. With a machine that wouldn’t boot, though, [Ted] replaced it with his own MCL65+, a purpose-built accelerator card based on the 600 MHz Teensy 4.1 microcontroller in order to debug the motherboard. The first problem was found in a ROM chip which prevented the computer loading anything from memory, but his solution wouldn’t work at the system’s higher clock speeds. To solve that problem [Ted] disabled the higher clock speed in hardware, restricting the system to 1 MHz and allowing it to finally boot.
So far there haven’t been any issues running the computer at the slower speed, and it also helps keep the computer cooler and hopefully running longer as well, since the system won’t get as hot or unstable. This isn’t [Ted]’s first retrocomputing rodeo, either. His MCL chips have been featured in plenty of other computers like this Apple II which can run at a much faster rate than the original hardware thanks to the help of the modern microcontroller.
Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.
The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.
But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.
Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.
So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.
Most modern computers are able to dynamically adjust their operating frequency in order to save power when they’re not heavily used and provide instantaneous-seeming response when load increases. You might be surprised to hear that the lowly 8-bit AVR microcontrollers can also switch CPU-speed gears on the fly. In this edition of Embed with Elliot, we’ll dig into the AVR’s underappreciated CPU clock prescaler.