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.
If you are a certain age, MOS6581 either means nothing to you, or it is a track from Carbon Based Lifeforms. However, if you were a Commodore computer fan 35 years ago, it was a MOS Technologies SID (Sound Interface Device). Think of it as a sound “card” for the computers of the day. Some would say that the chip — the power behind the Commodore 64’s sound system — was the sound card of its day. Compared to its contemporaries it had more in common with high-end electronic keyboards.
The Conversation has a great write up about how the chip was different, how it came to be, the bug in the silicon that allowed it to generate an extra voice, and how it spawned the chiptune genre of music. The post might not be as technical as we’d do here at Hackaday, but it does have oscilloscope videos (see below) and a good discussion of what it took to create music on the device.
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.
Slack is great, but there are a few small problems with the current implementations. There isn’t a client for Palm, there isn’t a client for the Newton, and there isn’t a client for the Commodore 64. The last of these severe oversights was recently fixed by [Jeff Harris]. He built a native Slack client in 6502 assembly for the Commodore 64.
When dealing with network applications and the C64, the first question that comes to mind is how to talk to the outside world. There are C64 NICs, and ESP dongles, but for this build [Jeff] turned to the C64 Userport. This card edge combination of a serial and parallel port allows the C64 to talk to anything with RS-232, and with a simple adapter, [Jeff] got his old computer talking to a Raspberry Pi connected to the Internet.
The C64 Slack client itself is written in 6502 assembly, and features everything you would expect. The Pi is required to talk to the Slack API, though, and uses a NodeJS app to translate the bits from the C64 to something the API can understand.
Does it work? Of course it does. Slack is just text, after all, and there doesn’t seem to be any PETSCII weirdness here. You can check out a video of the build in action below.