The venerable Commodore 64 got a lot of people started in computers, and a hard core of aficionados keeps the platform very much alive to this day. But a C64 just doesn’t have the horsepower to do anything more than some retro 8-bit graphics games, right?
Not if [jim_64] has anything to say about it. He’s created a pair of virtual-reality goggles for the C64, and the results are pretty neat. Calling them VR is a bit of a stretch, since that would imply the headset is capable of sensing the wearer’s movements, which it’s not. With just a small LCD screen tucked into the slot normally occupied by a smartphone in the cheap VR goggles [jim64] used as a foundation for his build, this is really more of a 3D wearable display — so far. The display brings 3D-graphics to the C64, at least for the “Street Defender” game that [jim64] authored, a demo of which can be seen below. We’ll bet position sensing could be built into the goggles to control the game too. Even then it won’t be quite the immersive (and oft-times nauseating) experience that VR has become, but for a 35-year old platform, it’s not too shabby.
Before everyone learned programming on Stack Exchange, things were much different. Computer magazines had BASIC programs in them, which readers would type out, line by line, and hit RUN. In theory, this is a terrible way to learn programming; it’s simply rote recitation without any insight into what the code is actually doing. Of course, copying and pasting from Stack Exchange is exactly the same thing, so maybe these magazines were ahead of the curve.
[0xA000] recently came across one of his old computer magazines containing the type-in listing for Blindganger, a game where you wander a maze blindly. When [0xA000] typed this game into his C64 back in 1988, the game didn’t work. Thirty years later, he decided to give it another go and ended up fixing bugs in an old computer game.
When [0xA000] typed this game into his computer back in 1988, the map just didn’t work, and the final screen revealed a maze where the walls were where they shouldn’t be. A quick Google turned up a disk image of the same game that had the same problem. This bug was obviously in the section of code that draws the map at the end of the game, so [0xA000] started looking there. The offending typo in the code was an $F4 instead of an $F5, or 244 instead of 255. This shifted the colors of the map by 11 positions, meaning the locations marked as visited in the final screen were wrong. Whether this bug cropped up in development or was just a simple typo when typesetting the magazine doesn’t really matter now; after 29 years, this bug is fixed.
The venerable Commodore 64, is there anything it can’t do? Like many 1980s computer platforms, direct access to memory and peripherals makes hacking easy and fun. In particular, you’ll find serial & parallel ports are ripe for experimentation, but the Commodore has its expansion/cartridge port, too, and [Frank Buss] decided to hook it up to a two-line character LCD.
Using the expansion port for this duty is a little unconventional. Unlike the parallel port, the expansion port doesn’t have a stable output, as such. The port contains the data lines of the 6510 CPU and thus updates whenever RAM is read or written to, rather then updating in a controlled fashion like a parallel port does. However, [Frank] found a way around this – the IO1 and IO2 lines go low when certain areas of memory are written to. By combining these with latch circuitry, it’s possible to gain up to 16 parallel output lines – more than enough to drive a simple HD44780 display! It’s a testament to the flexibility of 74-series logic.
It’s all built on a C64 cartridge proto-board of [Frank]’s own design, and effort was made to ensure the LCD works with BASIC for easy experimentation. It’s a tidy mod that could easily be built into a nice enclosure and perhaps used as the basis for an 8-bit automation project. Someone’s gotta top that Amiga 2000 running the school district HVAC, after all!
[Greisi] started by desoldering all the ICs and mapping out a schematic for the board. The design centers around common parts for the era, such as a UV-erasable EPROM and some 74-series logic. [Greisi] decided to then modernise the design and make some improvements. Adding a fuse should avoid the cartridge catching on fire, and a bunch of decoupling capacitors on all the ICs should reduce noise. A FLASH chip is used instead of the old school UV-erasable part, which makes writing to the device much easier.
Back in 2014 [Johan] decided to celebrate BASIC’s 30 50 year anniversary by writing his own BASIC interpreter. Now, a few years later, he says he feels he has hit a certain milestone: he can play Flappy Bird, written in his own version of BASIC, running on his own home-built computer, the BASIC-1.
Inside the BASIC-1 is an Atmel XMega128A4, a keyboard from a broken Commodore 64, a joystick port, a serial to TV out adapter, and an SD card adapter for program storage. An attractively laser-cut enclosure with kerf bends houses the keyboard and hardware. The BASIC-1 boots into BASIC just like many of its home computer counterparts from the 80s.
There’s a lot of reasons you might want to emulate the keyboard on your Commodore 64. The ravages of time and dust may have put the original keyboard out of order, or perhaps you need to type in a long program and don’t fancy pecking away with the less-than-stellar feedback of the standard keys. [podstawek] has come up with the solution: a Commodore 64 keyboard emulator that works over serial.
It’s a simple concept, but one that works well. A Python script accepts incoming keypresses or pre-typed text, then converts them into a 6-bit binary code, which is sent to an Arduino over the serial connection. The Arduino uses the 6-bit code as addresses for an MT8808 crosspoint switch.
The MT8808 is essentially an 8×8 matrix of controllable switches, which acts as the perfect tool to interface with the C64’s 8×8 keyboard matrix. Hardware wise, this behaves as if someone were actually pressing the keys on the real keyboard. It’s just replacing the original key switches with an electronic version controlled by the Arduino.
[podstawek] already has the setup working on Mac, and it should work on Linux and Windows too. There’s a little more to do yet – modifying the script to allow complex macros and to enable keys to be held – so check out the Github if you want to poke around in the source. Overall it’s a tidy, useful hack to replace the stock keyboard.
Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips. Amongst other hardware, Java Grinder supports the Commodore 64, which uses a variant of the 6502 CPU. [Michael Kohn] realized the Atari 2600 shares this processor, and figured he’d get started on making Java Grinder work with the Atari by expanding on the C64 work done by [Joe Davisson]. Together, they brought Java to the Atari 2600 and made a game along the way.
According to [Michael], parts of the project were easy, as some Java routines compile down into as little as 1 or 2 instructions on the 6502. Other parts were harder, like dealing with the graphics subsystem, and modifying Java Grinder to output 8-bit bytecode to fit into the Atari’s tiny 4K ROM limit. Even with this tweak, they still couldn’t fit in a game and title screen. In the end they relied on bank switching to get the job done. [Joe]’s game is pretty solid fare for the Atari 2600 — blocky graphics and bleepy sounds — and they’ve uploaded it to the page so you can try it yourself in an emulator.
At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430. Video after the break.