Getting the IBM 6715 Actionwriter 1 to print.

This took a bit longer that I had expected. Sorry, I got distracted.

So, by blatantly stealing information from Computer-Magazine - Wenn der Atari ST mit der Gabi anbandelt (Teil 1), which discusses the Triumph Adler Gabriele 9009 typewriter and the corresponding computer interface box named IFD, I managed to write a little proof of concept program that can talk to the Actionwriter and make it print things under computer control.

(Note that there is a part 2 which talks about the computer interface side of things)

Let's start with a bit of background to explain what is happening. The original Triumph Adler Gabriele 9009 typewriter, on which the IBM 6715 is based, had a special feature port, and one could buy an adapter device called IFD that would interface standard parallel (Centronics) and serial (RS232) computer printer interfaces to this feature port. IBM apparently sold a similar interface device for the Actionwriter under the product name IBM 5002 Printer Option. Unfortunately, other that the name, I have not been able to find any online information about this device.

The feature port is based on RS232, but uses 5V TTL level signalling. It operates at 4800 baud, and it uses a very specific control protocol based on a set of 2-byte commands.

To print a character, you have to convert the ASCII/UTF-8 code to a daisy wheel position code, and then send this code, along with a second byte indicating hammer strength …

Continuing work on the IBM 6715 Actionwriter 1.

After I took the dead machine apart, I first checked out the power supply, suspecting a possible blown capacitor.

Well, that wasn't it. The power supply looked perfectly healthy and generated all the expected voltages. So the next thing to check was the main circuit board.

A visual inspection of the board showed nothing obviously wrong. An electrical check of the power inputs showed no short circuits or broken connections. The next step was to gradually plug things back into the main board and see what happens. The first thing that happened when I plugged in just the power connector was a beep. That's a good sign; it means the logic is at least partially working. When I then plugged in the motors, at first nothing happened, until I remembered the cover open switch, which prevents movement when the cover is open. I pushed the button, and the motors went through their power on reset sequence. Good, next step, plug in the keyboard. Well, so long as I kept that cover switch pushed in, everything just worked exactly as it should. I tried several power cycles, just to be sure that it wasn't a one-off fluke. The machine just works perfectly, as if there had never been any problem.

At this point, the most likely explanation is that the cover open switch was dirty and dodgy, and didn't make contact after I had opened the cover to take out the ribbon. I …

Some years ago I worked for a company making an analytical SQL Database system. At some point I was asked to think about possible new storage method that would be optimized for high speed SSD storage. In the end, this project wasn't further pursued as other projects took precedence, but ever since I have had this weird idea of log structured btree storage in my head.

A few years later, when I got more serious about actually implementing this wild distributed file system idea of mine, I needed a suitable key/value store library that could use an append only object store as underlying storage. Unfortunately, none of the existing golang key/value store libraries offered this capability. After some careful thinking I realized that the Log Structured BTree idea, although originally coming from an SSD flash storage context, is in fact perfectly suited for this particular use case. So I started writing a Log Structured BTree key/value store library, LSB.

It took some time, but I got something working. But then, when I started thinking about how exactly I would use it to implement the logical equivalent of the inode table and directories in my file system, I realized I was going to need some kind of transaction support in the library to avoid excessive complexity in the file system code. This meant that I now had to implement some kind of transaction support. That took a bit of time, and when I had it implemented, I found …

A recent addition to my little technology museum has been the IBM 6715 Actionwriter 1.

There were two reasons why I chose to get this machine when I found one on sale for cheap.

First, this typewriter has been described as a bit of a unicorn. It's an IBM, but not really. IBM had been making professional heavy duty office typewriters for many decades. By 1985 these had evolved into the first models of the Wheelwriter line, big electronic devices with a separate printer unit using a daisywheel print element. However, at that time IBM did not have a suitable model for the home, school, and small business markets. Rather than build their own low end model, IBM turned to Triumph Adler in Germany, who had the successful Gabrielle 9009 electronic typewriter. Triumph Adler agreed to build the IBM 6715 Actionwriter 1 for IBM, based on the Gabrielle 9009, but with an IBM keyboard, similar to the IBM Model M keyboard used with computers at the time, and a slightly modified case. It was sold as both 6715 and Actionwriter 1, and I haven't found anyone able to say what determined what label it got in what market at what time.

Second, this typewriter has a computer interface. Now, this interface appears to have been intended as only a printer interface, but I was hoping that with a bit of trickery, it might be possible to convince the device to operate as a terminal device, much like a Teletype, DECwriter …

I run quite a few computers at home (too many, don't ask). Some of these are servers that I want to have a reliable internet connection, even when I'm not at home for some time. For this reason, I set up two redundant upstream gateway routers, and used ucarp to manage the automatic failover. Ucarp is a portable implementation of CARP (Common Address Redundancy Protocol). At the time, this seemed like a fairly simple and straightforward tool for the job. Unfortunately, after some time I found that it wasn't always 100% reliable, so I started looking for alternatives. I found that the selection was somewhat limited. There were some abandonware tools that hadn't been maintained for a while, some tools that only work in combination with a full Quagga router setup, etc, but nothing that was current, fully functional, and reasonably simple to set up.

So I set about to write my own. I mean, what else would you do?

My goal was to make something that is relatively simple, has relatively few external dependencies, and is preferably portable to other UNIX systems, such at *BSD, even though I develop mostly on Devuan/Debian these days.

The implementation of the core functionality is necessarily kinda tricky, as you are working on raw IP packets, not TCP or UDP, with even a bit of Ethernet MAC frame magic thrown in for good measure, and that automatically gets you into the slightly murkier parts of the socket interfaces on most systems. Still …