[Nathanial Hendler]’s Apple2Idiot expansion card for the Apple II family of computers is a nifty mix of modern and vintage, and provides a clever means of allowing the host computer to (indirectly) access the internet over WiFi while keeping things simple from the host computer’s perspective.
It does this by embedding an ESP32 module and a dual-port RAM chip onto an expansion card. The Apple2Idiot, when installed into a host machine, presents as a memory location which the host machine can access. The ESP32 then takes care of all the WiFi communications and tasks requiring internet access, and the host computer directs these tasks (and reads their output) via PEEK and POKE commands.
This means that there are two pieces of software for any given task: one running on the ESP32 doing the actual work, and one running on the Apple II that communicates with the ESP32 on the card by reading and writing to memory. It’s a simple system, and one that [Nathanial] thinks works quite well for specific tasks.
Example programs include things like scanning and selecting a WiFi network, fetching weather data, and sending a message to Slack. Making new applications does mean having to write software on two ends, but the simplicity of the system also means flexibility, because anything the ESP32 does can have its complexity abstracted away by the time its data is presented to the host machine. Not that the Apple II is incapable of dealing with the modern internet more directly; we’ve seen a basic Apple II web server written in BASIC.
The two machines are paired using a vintage digital-to-analog logic controller pack. This DAC was originally used to control model trains using your Apple II – something that we now desperately need to see in action. The pack can output voltages between 0 and 2.55 V at 8-bit resolution (or 256 steps), which is plenty for a retro synth.
With the card installed in Slot 7 of the Apple II and the DAC wired through to the synth’s CV/gate, it’s then a trivial matter of writing POKE statements in Applesoft BASIC to control the synth. The video after the break demonstrates playing a simple melody, as well as how one might use the Apple II keyboard to ‘play’ the synth in real time.
If you’re interested in building your own, the video below has all the information needed, as well as helpful advice on where to find a DAC for your preferred model of vintage computer. If all that doesn’t tickle your musical fancy, make sure to check out our coverage on the Game Boy MIDI synth, or perhaps this peculiar synth and visualizer combo.
We can still remember when the WS2812 LED first came into our consciousness, way back in the mists of time. The timing diagrams in the datasheet-of-questionable-veracity made it sound quite tricky, with tight timing tolerances and essentially a high-speed two-bit PWM data protocol at 500 kHz. It was a challenge to bit-bang with an ATtiny85 back then, but there’s no way something as old and crusty as an Apple II would be up to snuff, right?
Specifically, [Anders] abuses the 74LS165 parallel-in, serial-out shift register for his dirty work. Instead of bit-banging the WS2812’s “long high is a 1, short high is a 0” signal directly, the first few bits of the shift register are hard-wired to VCC and the last few to GND.
The bits in the middle determine if the pulse shifted out is long or short, and they’re set by the 6502, through a 6522 VIA chip, just like the Apple II would have. Clocking the data out of the shift register handles the timing-critical stuff. Very clever!
In prior centuries, it was common practice to tie the operation of a program to a computer’s clock speed. As computers got faster and faster, the programs tied to that slower clock speed sometimes had trouble running. To patch the issue temporarily, some computers in the early 90s included a “TURBO” button which actually slowed the computer’s clock speed down in order to help older software run without breaking in often unpredictable ways. [Ted Fried] decided that he would turn this idea on its head, though, by essentially building a TURBO button into the hardware of old computers which would greatly increase the execution speed of these computers without causing software mayhem.
To accomplish this, he is running CPU emulators on Teensys (Teensies?), but they are configured to be a drop-in replacement for the physical CPU of several retro computers such as the Apple II, VIC-20, and Commodore 64 rather than an emulator for an entire system. It can be configured to run either in cycle-accurate mode, making it essentially identical to the computer’s original hardware, or it can be placed into an accelerated mode to take advantage of the Teensy 4.1’s 800 MHz processor, which is orders of magnitude faster than the original hardware. This allows (most of) the original hardware to still be used while running programs at wildly faster speeds without needing to worry about any programming hiccups due to the increased clock speed.
The video below demonstrates [Ted]’s creation running in an Apple II but he has several other cores for other retro computers. It’s certainly a unique way to squeeze more computing power out of these antique machines. Some Apple II computers had a 4 MHz clock which seems incredibly slow by modern standards, so the 800 MHz Teensy would have been considered wizardry by the standards of the time, but believe it or not, it’s actually necessary to go the other direction for some applications and slow this computer down to a 1 MHz crawl.
In its day, the Apple II computer didn’t typically require active cooling. However, the increasing scarcity of replacement hardware convinced [Joshua Coleman] to come up with a more robust active cooling solution for his Apple II+, increasing the likelihood that it will keep on crunching numbers for decades to come.
Joshua mentions that he recorded temperatures inside his Apple II+ peaking at 110 Fahrenheit (over 43 Celsius). This isn’t totally unexpected for a fully-loaded Apple II system, and components were built to handle this – the original datasheet for the 6500 microprocessor family reveals that the CPU can handle temperatures as high as 158 Fahrenheit (70 Celsius). Unfortunately, we’re not dealing with brand new components anymore. Decades-old microprocessors don’t necessarily have the same thermal tolerance as they once did. All components will eventually wear out, and heat can certainly accelerate the aging process.
In the interests of maintaining his system, Joshua cobbled together an Arduino-based cooling system for his Apple II+. A temperature/humidity sensor continuously monitors the heat situation inside the case – when things get too toasty, a 12V fan powers up to draw fresh air over the logic board and expansion cards. A simple cooling curve reduces wear on the fan motor and relay.
This is hardly the first active cooling system for the Apple II line – in the 1980s, Kensington produced a popular (if not stupendously ugly) ‘System Saver’ accessory, an external bolt-on fan that kept things running cool. These were often deployed in schools and by power users looking for added reliability when maxing out the Apple II expansion slots, a configuration that could increase temperatures due to the extra power requirements and reduced airflow.
For those who might have missed it, there was a brief period in the mid-00s where gamers everywhere eschewed consoles and PCs in favor of simple Flash-based games to be played in a browser. Among these was the game Peasant’s Quest, created by the folks at Homestar Runner and modeled after video games from the 80s. [deater] was a fan of this game and wondered if it would actually be possible to play this retro-styled game on actual retro hardware.
For the experiment he decided on using an Apple II since this computer is featured as a prop rather often by the developers at Videlectrix. It turns out that with some determination it’s actually possible to run this game on the late 80s hardware with very little modifications. Squeezing the sprites into the required space was a challenge, as well as getting the sound tracks to play properly, but in the end the game runs within the hardware’s 280×192 resolution with 6 colors. There are also detailed notes on how the complicated graphics system on the Apple works for those willing to take a deep dive. There’s a lot going on here, but surprisingly few compromises needed to be made to get this to work.
The game itself is available on the project’s webpage for anyone who still has an Apple II kicking around, or for anyone who is willing to try it out in an emulator. Of course you could always play the original Flash version but that’s missing a certain charm that decades old retrocomputers have with games. We certainly aren’t seeing video game controllers like those built for the Apple II anymore, for example.
These days, if you want to code a game for the original Nintendo Entertainment System, it’s about as easy as downloading an assembler, firing up Notepad, and running the ROMs you cook up in any one of a variety of emulators. In the 1980s none of those things existed, and the process was a little more complicated – as demonstrated by [Tyler Barnes] in the video embedded below.
[Tyler] has put together a 40-minute guide on what it takes to get to “Hello World” – or more accurately, a simple pink screen – on the NES, using period-correct hardware. He starts the process by formatting some floppy disks and whipping up some basic assembly code on an Apple IIe, which gets run through the Merlin assembler for the 6502. It’s particularly convenient as the Apple II line and the NES both run the same CPU. From there it’s a case of using a standalone EPROM programmer to verify some appropriately-datecoded chips are empty, before programming them in a special add-on card for the Apple II. From there, the EPROMs are loaded into a cart custom modified with chip sockets, where it can be inserted into a NES for testing.
It’s a tedious process, with just the programming side of things taking on the order of ten to twenty minutes with a few fiddly steps along the way. While there are likely some efficiency gains to be had that were used by studios back in the day, it remains clear that development in this era was a much slower process.