Vintage Computers With A Real Turbo

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.

Continue reading “Vintage Computers With A Real Turbo”

Apple II computer on a workbench

Simple Fan Controller Helps Apple II To Beat The Heat

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.

Continue reading “Simple Fan Controller Helps Apple II To Beat The Heat”

The Faux-Vintage Becomes Vintage

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.

Continue reading “The Faux-Vintage Becomes Vintage”

What NES Development Looks Like On The Apple II

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.

Of course, if you prefer your Nintendo homebrew a couple generations hence, consider getting stuck in on the Nintendo 64. Video after the break.

Continue reading “What NES Development Looks Like On The Apple II”

Disgusting Apple II Monitors Live Again

[The 8-Bit Guy] recently went to check out a stash of old Apple II Color monitors which had been sitting outside in a trash pile for 20 years, and decided to bring one home to restore. As you can see from the lead photo, they were dirty — really dirty. Surprisingly, the team of volunteers who discovered these monitors had fired them up, and every one of them works to some extent or another.

Check out the video below as he cleans up this filthy monitor and starts troubleshooting. You’ll chuckle aloud when he turns the circuit board over to desolder a mysterious diode, and when he flips the board back over, the diode has disappeared (it actually disintegrated into dust on his lab bench). For the curious, one commenter on YouTube found that it was a glass passivated and encapsulated fast recovery diode called a V19. There’s going to be a part 2, and we have every confidence that [The 8-Bit Guy] will succeed and soon add a shiny, like-new monitor to his collection.

If you’re a collector of old monitors, this demonstrates that they can survive quite a bit of abuse and exposure. We’re not sure that rummaging through your local landfill is the best idea, but if you run into an old monitor that has been exposed to the elements, don’t be so quick to dismiss it as a lost cause. Do you have any gems that you’ve restored from the trash? Let us know in the comments.

Continue reading “Disgusting Apple II Monitors Live Again”

Apple II Talks To 3D Printer With A Little Modern Help

Controlling most desktop 3D printers is as easy as sending them G-code commands over a serial connection. As you might expect, it takes a relatively quick machine to fire off the commands fast enough for a good-quality print. But what if you weren’t so picky? If speed isn’t a concern, what’s the practical limit on the type of computer you could use?

In an effort to answer that question, [Max Piantoni] set out to control his Ender 3 printer with an authentic Apple IIc. Things were made a bit easier by the fact that he really only wanted to use the printer as a 2D plotter, so he could ignore the third dimension in his code. All he needed to do was come up with a BASIC program that let him create some simple geometric artwork on the Apple and convert it into commands that could be sent out over the computer’s serial port.

Unity controlling the Ender 3

Unfortunately, [Max] ran into something of a language barrier. While the Apple had no problem generating G-code the Ender’s controller would understand, both devices couldn’t agree on a data rate that worked for both of them. The 3D printer likes to zip along at 115,200 baud, while the Apple was plodding ahead at 300. Clearly, something would have to stand in as an interpreter.

The solution [Max] came up with certainly wouldn’t be our first choice, but there’s something to be said for working with what you know. He quickly whipped up a program in Unity on his Macbook that would accept incoming commands from the Apple II at 300 baud, build up a healthy buffer, and then send them off to the Ender 3. As you can see in the video after the break, this Mac-in-the-middle approach got these unlikely friends talking at last.

We’re reminded of a project from a few years back that aimed to build a fully functional 3D printer with 1980s technology. It was to be controlled by a Commodore PET from the 1980s, which also struggled to communicate quickly enough with the printer’s electronics. Bringing a modern laptop into the mix is probably cheating a bit, but at least it shows the concept is sound.

Continue reading “Apple II Talks To 3D Printer With A Little Modern Help”

Reconstructing Data From A Corrupt Apple ][ Floppy Disk

Back in 1990 [Benjamin Zotto] wrote – while in elementary school – a dog racing game called Wonderland 2. The BASIC source code and images for the game were stored on a single ProDOS formatted, soft-sectored 5.25″ floppy disk. Fast-forward thirty years to today and [Benjamin] found to his dismay that ProDOS could no longer read the floppy, giving an I/O error. Not deterred, he set about to recover the data, as documented in this Twitter thread.

Applesauce visualization of the patterns on the corrupted disk, with soft-sectoring spiral arms.

The gist of the story is that the floppy disk’s surface could still be scanned with help from the aptly named Applesauce Floppy Drive Controller, which got the following visualization of the magnetic patterns on the disk surface:

This data could then be analyzed sector by sector, with the bad sectors and the cause for ProDOS flaking out with its reading attempts here marked in red.

Checking the data recovered so far confirmed that it was a ProDOS disk. It also confirmed that the sector containing the directory listing was shot. This required diving into the technical reference manual for ProDOS and its filesystem to figure out how to reconstruct the directory layout. This required figuring out the offsets and sizes of the files, assisted by knowing what was likely on the disk, and having some bits and pieces of the original volume listing still intact. This allowed for the directory volume to be rebuilt, one byte at a time.

Sectors on the disk, with bad sectors in red.

At the end of that arduous and highly educational journey success waited, and [Benjamin] was once again able to relive his memories of 1990s BASIC and hand-drawn bitmap graphics.