[Casey Bralla] got his hands on a Rockwell AIM 65 microcomputer, a fantastic example of vintage computing from the late 70s. It sports a full QWERTY keyboard, and a twenty character wide display complemented by a small thermal printer. The keyboard is remarkably comfortable, but doing software development on a one-line, twenty-character display is just not anyone’s idea of a good time. [Casey] made his own tools to let him write programs on his main PC, and transfer them easily to the AIM 65 instead.
Moving data wasn’t as straightforward in 1978 as it is today. While the Rockwell AIM 65 is a great machine, it has no disk drive and no filesystem. Programs can be written in assembler or BASIC (which had ROM support) but getting them into running memory where they could execute is not as simple as it is on modern machines. One can type a program in by hand, but no one wants to do that twice.
Fortunately the AIM 65 had a tape interface (two, actually) and could read and store data in an audio-encoded format. Rather than typing a program by hand, one could play an audio tape instead.
This is the angle [Casey]’s tools take, in the form of two Python programs: one for encoding into audio, and one for decoding. He can write a program on his main desktop, and encode it into a .wav file. To load the program, he sets up the AIM 65 then hits play on that same .wav file, sending the audio to the AIM 65 and essentially automating the process of typing it in. We’ve seen people emulate vintage tape drive hardware, but the approach of simply encoding text to and from .wav files is much more fitting in this case.
The audio encoding format Rockwell used for the AIM is very well-documented but no tools existed that [Casey] could find, so he made his own with the help of Anthropic’s Claude AI. The results were great, as Claude was able to read the documentation and, with [Casey]’s direction, generate working encoding and decoding tools that implemented the spec perfectly. It went so swimmingly he even went on to also make a two-pass assembler and source code formatter for the AIM, as well. With them, development is far friendlier.
Watch a demonstration in the video [Casey] made (embedded under the page break) that shows the encoded data being transferred at a screaming 300 baud, before being run on the AIM 65.
That is kinda cool. I would note that the AIM-65 has a serial interface. It is current loop by default and not hard to make it RS232 compatible. There is also a short section in one of the use manuals, maybe the Forth one interfacing floppy drive and block file system. I think all the code fit in less that 1K. (The Forth ROM ran code 30 to 100 times faster than BASIC.)
The most useful item was a card that plugged into the extension interface that could burn EPROMs for one of the empty sockets and also set it up will boot from the PROM. The AIM-65 is compatible with the whole Rockwell Design Center and a family of Eurocards and whatever they called the similar sized cards meant for edge connectors. And the System65 development system. https://oldcomputers.net/AIM-65-40.html I have all of it but the long sought AIM-65/40.
I think my favorite thing on that page is seeing the full-height 5¼” floppy drives in the Development System chassis referred to as “mini-floppy disk drives”. Which I suppose they were, compared to the massive 8″ floppy systems that preceded them!
My second job after leaving the Navy in the early 1980s involved programming an AIM-65 in Forth as part of an ultrasonic breast scanner system. That was fun.
Similar technique to store ZX-Spectrum programs in mp3 files today.
Back in 80s the programs also were downloaded over the air on radio broadcast somewhere in Europe.
Yes, that was in Germany (e.g. the “Computerclub” TV show) and the Netherlands, AFAIR.
For this purpose, they even created a “cross-platform” BASIC so that the software would run on as many different home computers as possible.
West Germany, to be precisely. Germany was still divided before 1990. :)
East Germany had done something similiar via youth radio, I think.
Home computer users sat down with their radio cassette recorder, waiting for their favorite program to be aired.
5,25″ diskettes and diskette drives were rare and very expensive and merely used by business PCs.
GDR had different home computers, though.
KC85 (and successors) and western C64 were popular (typically gifts from west relatives).
The lesser known AC-1 (Amateur Computer 1) in ham radio circles existed, too.
ZX Spectrums also existed, but GDR engineers didn’t like them or so I read.
Because them being too primitive in their eyes, I think.
The U880 was the GDR version of the Z80.
It might have been Basicode.
https://en.wikipedia.org/wiki/BASICODE
Can you even store encoded digital data in a lossy audio format and have it work?
Sure, as long as the data rate is slow enough such that it doesn’t get lost in the “lossy” bit. Cassette tapes were rather lossy as well, after all. Keep in mind the WAV file is much bigger than the actual number of bits it is encoding.
If it uses AFSK/FSK at about 1200 or 2400 Baud, sure. :)
Sharp MZ and C64 use similar datasette drives.
why the hassle. in the documentation there is a small program that turns on the serial port to be used for software loading. its not even that long. i burned it on an eprom for my aim65 so it can be started with just a few key strokes.
i needed no llm fot that.
Great if you have a serial terminal, but not everyone does. Heck, even serial cables/ports are scarce these days, you usually have to resort to a USB serial adapter. This hack just uses the headphone jack in his laptop as the data output port.
Uh, you don’t seem to realize that you were typing all that on a device that is one $10 dongle and a bit of software away from being a serial terminal…
Speaking of software, the DOS and 16-Bit Windows world had lots of terminal and communications software, for example.
Telemate, Telix, Bananacom, Windows’ Terminal (Win 3.x and before), PC-Tools Desktop (built-in terminal), WinComm..
They still were made with computer-computer connections in mind.
The modern Win32 or Linux terminal programs are too focused on Hayes modems, Telnet or SSH connections.
1980s/early 1990s software by contrast often is more period correct and supports older flow controls (DSR/DTR, not just RTS/CTS).
USB serial converters are hit and miss also.
They may not fully work with software using exotic 5-Bit modes etc (cheap PL2303, FT232).
(That’s when DOSBox and other emulators may show serial data errors in debug information.)
The better ones were made with Macs in mind (because former RS-422 platform, more sophisticated) and had a real programmable chip (fpga) with firmware.
Such as USA-19HS and similar.
Also, last but not least: There are RS-232 expansion cards, still!
They have an 16550AFN compatible UART FiFo, but also a native high-speed mode (MBit speeds).
They’re available for ISA, PCI, PCIe bus or PC Card slots and successors (Express Card).
Maybe also for Thunderbolt, because it’s basically just PCIe 1x on a wire.
You can install Minicom or Microcom for Linux, and then use the hardware handshake signals as you wish. Not sure about the 5 bit serial word with a USB serial converter though since Baudot is not particularly popular today.
Isn’t the serial port a 20mA current loop? You need an external conversion circuit.
Besides, given today’s PCs, you need a USB to serial cable which audio is built-in (or have they killed the headphone socket in laptops too?)
My AIM65 is buried in storage.
IIRC current loop to RS232 just took a resistor or two. I soldered it in. And the docs for the Forth ROM have a 1 block (1k of source code max) interface for a floppy disk. One of the aftermarket PROM programmers that plugged onto an edge connector was the best way to expand the system and you have all your extensions when you turn on the AIM. Thinking back, the Monitor ROM had a disassembler and line-by-line interactive assembler. And the Forth ROM includes the Bill Ragsdale assembler which made assembly code much more fun. There must have been a simple block editor because I eventually bought a Heath H19 terminal, a serious expensive decision, and wrote loads of instrument control software. I’m pretty sure it was all saved with the PROM programmer. I wonder if I still have that little board. If anyone sees an AIM-65/40 I have been looking for 35 years :-) By the way, with a GAL for decoding and a single UM61512A chip you can pull the 1K to 4K of RAM chips and have RAM everywhere it is allowed in the 64K address space. It takes a little PCB for an edge connector. I should make some.
“Fortunately the AIM 65 had a tape interface”. The end.
Loving Claude Code for all sorts of vintage computing projects. It makes me giggle to have the latest AI, running on a stack of networking and data centers utterly unfathomable in the 1980s, talk to some of the earliest PCs.
I did a test by asking the earlier AIs how to change the background color on a Commodore 64. Some of them used BASIC commands that didn’t exist on the 64. Some actually used POKE, but to the wrong register address. IIRC, Claude was the only one to actually get it right.
Actually, there was Q&A, Question and Answer in the 1980s.
You could ask the program something in human language and it responded.
Ran on IBM PCs and was often used together with databases.
In Germany also known as F&A (Frage und Antwort).
https://en.wikipedia.org/wiki/Q%26A_(Symantec)
I like the power supply was coil and linear regulators. Forget auto ranging 90-240v, this calls out where to tap for 110, 120, 230 and 240, has 4 settings.
The good news is you can use buck/boost switching power supplies and put this entirely on battery if you desire. Would be pretty easy using a “20v” cordless tool battery and a 5v and 24v converter.
I think the only 6502 computer I used was the Apple //e and //c; x86 took off in a big way and we had 8086-286-486 at home through the 80s and most of the 90s. Matter of fact my first Dell processor overheated to failure, and every one I see to this day has thernal issues if you use it for any real work, cracks me up.
Yes, but … what’s exactly new about that? Saving programs as sound files via the tape interface to a PC with a soundcard and then playing them back is a pretty old technique. Sometimes it was even combined with decoding the (BASIC) programs into a text file that could then be edited on the PC. I was editing Sharp BASIC pocket computer programs on a PC this way about 30 years ago.
Yes, this is not a new idea. You can find encoding/decoding programs for the “Kansas City Standard” (used on S-100 computers, I think). I could not find such a creature for the AIM however.
“If I have seen less far than other men, it’s because I have stood in the footprints of giants” :)
Kansas City Standard was also used by RTTY terminals, I think.
The Tono Theta 7000e had it, I think. It has a switch named “RTTY KCS”.
https://www.universal-radio.com/catalog/decoders/7000E.html
What’s new about it is that there are new people being born and made aware of history every day. Talking and writing about it is how it is kept alive.
The novelty is, you can type the programm with your favorite editor (nano, kedit, notepad) and compile the assemblycode on your big Workstation/Laptop.
Save it there and play the transcoded data via soundcard to the aim65 .
Some type of crosscompiling …