Hackaday Retro Edition: A New Commodore 64 Case

Some time in the 80s, the plastic injection molds for the Commodore 64C, the Commodore 128, and the Plus/4 were shipped from somewhere in Asia to the great Commodore Mother Brain in West Chester, Pennsylvania. These molds had already produced a million or two cases, but there were some issues with production – too much waste, or something like that. A mechanical engineer took a look at the molds, sent out some recommendations, and moved the 2500 pound molds to a corner of the building.

For some time after a gray day in April, 1994 these molds sat in a West Chester, Pennsylvania warehouse until they were sold off. They made their way to a plastics manufacturer around Dallas, Texas where they sat for twenty years. All things must pass, sometimes several times, and this plastics manufacturer closed down, contacted an auctioneer, and began to sell off some of their equipment.

The hero of our story, [Dallas Moore], owns a small business, buying and selling everything from Barbie dolls to antiques. He found an ad for an auction at a plastics manufacturing plant in the newspaper, and figuring he could find something interesting, headed out to the auction preview.

The auctioneer at this liquidation sale asked [Dallas] what he did, and mentioned there was something pretty cool tucked away in a warehouse full of hardened steel molds. Something about molds for old computers. These were the molds for the Commodore 64C, Commodore 128, and the Commodore Plus/4. A literal crucible of computing history, stacked on a pallet and up for sale.

The auctioneer said one of his friends was interested in the molds, and thought they would make a neat coffee table. Something about this struck [Dallas] the wrong way and for the entire drive home he thought about someone taking history and turning it in to a piece of furniture. He decided to buy these molds and lugged the three 2500 pound pieces of hardened steel to his shop. Not wanting to let a good piece of history go to waste, he contacted another plastics manufacturer, planned a run of a thousand or so Commodore 64C cases in red, white, and blue. [Dallas] is funding the whole production run through Kickstarter.

To me, this is one of the greatest retrocomputing successes in recent memory. There will always be someone putting SD cards in old computers, getting them on the Internet (and especially pointed towards our retro edition), and cloning complete systems in FPGAs. This, though, is a clear example of someone recognizing the historical importance of several thousand pounds of steel, realizing there’s a market out there, and doing the leg work to remanufacture these pieces of history.

I put in my $45 for a red one, and I tipped off [Bil Herd], designer of the C128 and Plus/4, to this Kickstarter. He’s been talking with [Dallas], there I’m sure he’ll chime in on the comments with some retellings of Commodore battle stories.

If it arrives in time, I’ll be bringing my limited-edition red 64C case to the Vintage Computer Festival in Wall, NJ April 17-19. That’s a plug for the event. If you’re in the area, you should come.

EDIT: [Dallas] has a different story of where the molds came from.

A Raspberry Pi SID Player

Of all the vintage chiptune machines out there, the Commodore 64 is the most famous. Even 30 years later, there are still massive gatherings dedicated to eeking out the last cycle of processing power and graphics capability from the CPU and the infamous synth-on-a-chip, the SID. [Bob] wanted to build a SID jukebox. A C64 is capable of the job, but if you want to have every SID composition on an SD card and connect that to a network, a Raspberry Pi is the way to go.

The SID chip, in its 6581 or 8580 versions, is controlled directly by poking registers on the chip through the address and data busses. This means a lot of pins, too many for the original Raspi expansion header. That’s not a problem that can’t be solved with a few shift registers, though. The rest of the circuit is an LM386 audio amplifier, an LCD that displays the current song, and a can crystal oscillator for the SID.

Right now everything is wired up on a breadboard, but making this a Raspberry Pi hat would be a rather simple proposition. It’s only a matter of finding a SID with working filters, and if you can manage that, it’s a pretty easy build to replicate. Video below.

Continue reading “A Raspberry Pi SID Player”

Dual Porting a C64 Flash Cart

The old cartridges for the Commodore 64 use EEPROMs to store their data, and the newer Flash carts use either a Flash chip or an SD card to put a whole bunch of games in a small plastic brick. [Stian] and [Runar] thought that wasn’t good enough – they wanted to program cartridges in real time, the ability to reboot the C64 without ever touching it, and a device for coding and testing. What they came up with is the latest advance in Commodore cartridge technology.

The device presents 8k of memory to the C64, but it doesn’t do this with Flash or an EEPROM. Instead, [Stian] and [Runar] are using a dual-port static RAM, specifically one from the IDT7005 series. This chip has two data busses, two address busses, and /CE, /OE, and R/W lines for either side of the chip, allowing other digital circuits to be connected to one small section of the C64’s memory.

Also in the cart is an ATmega16 running V-USB to handle the PC communications. It takes about 1 to 1.5 seconds to transfer an entire 8k over to the cartridge, but this chip can read and write the RAM along with the C64 simultaneously.

If you want a box that will give you the ability to put ever game in existence on a single cartridge, this isn’t the one. However, if you want to write some C64 games and do some live debugging, this is the one for you. The Eagle files are available, and there’s a video demo below.

Continue reading “Dual Porting a C64 Flash Cart”

A Complete C64 System, Emulated on an STM32

The Commodore 64 is the worlds bestselling computer, and we’re pretty sure most programmers and engineers above a certain age owe at least some of their career to this brown/beige keyboard that’s also a computer. These engineers are all grown up now, and it’s about time for a few remakes. [Jeri Ellisworth] owes her success to her version, there are innumerable pieces of the C64 circuit floating around for various microcontrollers, and now [Mathias] has emulated everything (except the SID, that’s still black magic) in a single ARM microcontroller.

On the project page, [Mathais] goes over the capabilities of his board. It uses the STM32F4, overclocked to 235 MHz. There’s a display controller for a 7″ 800×480 TFT, and 4GB of memory for a library of C64 games. Without the display, the entire project is just a bit bigger than a business card. With the display, it’s effectively a C64 tablet, keyboard not included.

This is a direct emulation of the C64, down to individual opcodes in the 6510 CPU of the original. Everything in the original system is emulated, from the VIC, CIAs and VIAs, serial ports, and even the CPU of the 1541 disk drive. The only thing not emulated is the SID chip. That cherished chip sits on a ZIF socket for the amazement of onlookers.

You can check out some images of the build here, or the video demo below.

Continue reading “A Complete C64 System, Emulated on an STM32″

The Entire Commodore 64 Library In Your Pocket


[sweetlilmre] is just beginning his adventures in retrocomputing, and after realizing there were places besides eBay to buy old computers, quickly snagged a few of the Amigas he lusted after in his youth. One of the machines that didn’t make it into his collection until recently was a Commodore 64 with Datasette and 1541 drive. With no tapes and a 1541 disk drive that required significant restoration, he looked at other devices to load programs onto his C64.

These devices, clever cartridge implementations of SD cards and Flash memory, cost more than anyone should spend on a C64. Realizing there’s still a cassette port on the C64, [sweetlilmre] created Tapuino, the $20 Commodore tape emulator

The hardware used to load games through the Datasette connector included an Arduino Nano, a microSD breakout board, a 16×2 LCD, some resistors, buttons, and a little bit of wire. The firmware part of the build – available here on the Git – reads the .TAP files off the SD card and loads them into the C64.

[sweetlilmre] posted a very complete build post of the entire device constructed on a piece of protoboard, Pop that thing in a 3D printed case, and he can have the entire C64 library in his pocket.

Make that C64 Keyboard Work as a USB Keyboard


Let’s face it, we all have keyboard peculiarities. Don’t try to deny it, everyone who types a lot has an opinion of the keyboard they stroke so frequently. We know [Brian Benchoff] swears by his model M, and we’re guessing he was the one that bumped into [Evan] and convinced him to write about his conversion of a Commodore 64 keyboard for use as a USB device.

This is not [Evan’s] first rodeo. We recently saw him fixing up the worn off letters of his own model M. But this time around there’s some clever microcontroller work at play. Apparently mapping 122 keys using an Atmel AVR 32u4 chip (built in USB connectivity) is quite a task. Luckily someone’s already worked out all kinds of good things and is sharing the love with the Soarer’s Keyboard Controller Firmware. Of course it handles scanning, but also includes debounce, muxing, and the trick to scan more keys than the uC has pins for. We still don’t fully understand that bit of it. But [Evan] did post the config file he’s using so perhaps after we get elbow-deep in the code we’ll have a better understanding.

If you give this a try, we want to hear about it. Anyone have any modern keyboards they’re in love with? Leave a comment below.

Demystifying NTSC Color And Progressive Scan


Black and white NTSC is simple – it can, and was, done with vacuum tubes for a long, long time. Color is just weird, though. It runs at 29.976 frames per second, uses different phases of the carrier for different colors, and generally takes a while to wrap your head around. [Sagar] is doing a series on the intricacies of NTSC, and the latest post deals with color and progressive scanning versus interlacing, or as it is better known, how classic game consoles and home computers generate video.

The test bed for [Sagar]’s video experimentations is a circuit containing an ATMega16, a 4-bit shift register, and a 14.31818 MHz clock. This clock is much faster than the 3.579545 MHz clock in an NTSC carrier frequency – exactly four times as fast – allowing the shift register to output four different phases of the carrier frequency a 0°, 90°. 180°, and 270°. Playing with some of the pins on the ATMega in the circuit results in a palette being generated on any old TV.

NTSC requires interlaced scanning, or sending an entire screen of even lines, then an entire screen of odd lines, at around 60 fields per second. The Nintendos and Segas of yesteryear didn’t bother with this, instead opting to send half the vertical resolution at double the frame rate. This is known as a progressive scan. [Sagar] found that this resulted in some image artifacts when displayed on a modern LCD, and moving back to an interlaced mode fixed the problem. All the code and files are up on the gits. If you’re feeling adventurous, this is exactly how projects like the Uzebox have created homebrew game consoles using little more than the ATMega found in [Sagar]’s build.