A week or so ago, I happened to remember this, and in particular that the last two Soviet probes to Venus both happened to go to the comet as part of this effort. The notable thing to me from the Wikipedia page and others about these probes is that they both carried a television camera with them, and had imaged the comet with this camera. 

I’ve never seen this footage online, and I have never seen a video of a comet, so I figured that I’d spend an evening or two putting this together from the data.

The data itself is (are?) located on an arcane University of Maryland-hosted NASA site, called the Small Body Node. https://pds-smallbodies.astro.umd.edu/data_sb/missions/ihw/index.shtml. From the site and from some of the supporting documentation, it is clear that many scientists spent much of the 80s and 90s going through this data, cleaning it up, and writing about it. I wasn’t really concerned with science though - I just wanted a video of a comet.

I downloaded the data and cracked open the archive. Inside each instrument’s dataset are a set of folders organized however they felt like leaving it when uploaded in 1995. For Vega 2, the data are organized by what post-processing has been applied. To start, I used the data in the main folder.

The images here had (and still have) a .img file extension. Opening the .lbl or .hdr metadata files didn’t really help me out with figuring out how to open the images for viewing, but they would be useful later. Some googling told me that the images should either be in Erdas Imagine format or from an obscure old Windows competitor called GEM.

I’m familiar with Erdas from my university days, so I cracked open my copy of SAGA GIS and attempted to import the files as this format.

No dice.

Next, I installed DOSBOX-X to give me a good DOS platform to work from, and installed GEM onto it. GEM is an interesting OS for the weird cross between Windows 3.0 and Macintosh it looks like. It’s got the ever-present file menu/desktop view that Windows 3 has, but the menu bar feel of Mac. I might have to revisit it in the future.

GEM really didn’t like .img files. Loading one into GEM Paint locked up the system bad enough to need a full reboot regardless of how I tried to do it.

The last thing I could think of was that the documentation included in the files mentioned that this was supposed to be in FITS format. As I learned while writing this blog post, FITS is an image format allowing for the wide variety of wavelengths and supporting data that astronomical imagery needs. I googled FITS format reading, and found that both GIMP and Python (through the Astropy package) should support it. Opening in GIMP did nothing, and neither did Astropy - many dead ends here.

So, it seemed that this wasn’t going to be as easy as I hoped and I was going to have to parse this myself. Luckily, the header/label files I mentioned earlier could help out. The label file told me that the image data was stored as 8-bit integer data, using most-significant bit encoding, and with a 128-length line. 

Using a hex editor, I verified that there was nothing that looked like a header in the data itself, and wrote a script to parse out lines of 128 integers from each image, and write those lines as image data to frames of a GIF to see if this really was a television recording. Note that the images here are provided at original 128px by 128px size, except where they were “big” (my name, the actual files aren’t differentiated) 512px images.

Now that I had a script that worked, I looked around the various folders included in the dump. There are a number of versions included, but the “post” version is the most interesting (IMO). This contains a set of smaller and larger files, with the larger files being higher resolution, and all of them having notably higher quality than the rest of the dataset. Since this is just the footage they got after the closest approach, I can only assume that they took the most time to get the exposure right.

Most of the images were taken about 30 seconds apart, so the probe recorded more of a timelapse than it did a realtime broadcast. There are some larger gaps here and there, so I made another script (included in the Github) that adds extra frames to scale the animation accordingly.

I also found the frame from Vega 2 that tends to make it to any articles about the Vega spacecraft. This frame was cleaned up by Abergel, J. et al as part of their 1997 article.

The original (or at least the version still around in the data looks like this:

And a “smoothed” version is also provided. I rotated it to match the version usually provided online.:

The most striking thing to me about all of these images was how cool it is to see what seems to be a flyby of the comet, and also how little exists about this. It seems to me that this animation (or a further retouched version) should be the first thing that anyone sees of Halley’s Comet, but as far as I can tell it has never been shared in this way. 

All I can say is that if you’ve ever seen some kind of weird loose end on some Wikipedia rabbit hole you’re on, you too should track down whatever little source data is hanging around out there and look at it for yourself.

If you want to look at my processed versions, a .zip is available here

Try the system for yourself!

The CN Electronic Passenger Reservation System was a system used by CN and later Via Rail from April 1, 1967 to 1980. It used a Collins C-8401 computer located in Toronto Union Station and operators at stations across Canada used a combination of a mark-sense reader and a modified Teletype Model 32 teleprinter.

The system was designed and managed through Canadian National Telegraph and was hosted in their offices in Toronto, while the efforts of the rest of CN to computerize were largely managed in Montreal, as I will surely discuss in future blog posts and publications.

I rebuilt the system using the CN manual from Libraries and Archives Canada. I had found the manual while looking through their material related to TRACS and Car Control (if you have any resources on these, please contact me!) and realized that it was a complete enough manual for it to be possible to recreate thanks to a reasonably deep description of both input and output for each operation that the station agents and computer supervisors were expected to perform.

When recreating the functionality, I started with a few assumptions based on systems that came later, leaning heavily on a relational database using SQL to manage the relationships between different data managed by the system. As I’ll describe, each of these had some flaw with them.

The main assumptions I made were:

1. Every leg of a trip existed independently of each other, but had to be validated against an allowed train. Almost every operation described can be done on a subset of stations that each train went to, and there is explicit mention of legs as constraints.

2. Every leg had to be tied to a specific allowed route (or edge in a graph) and was only validated through these edges. This one was the most correct, and came from the specification of specific cities that were used. My understanding here was flawed in that the validation was against the edges allowed per train, rather than every train using all allowed edges for legs.

3. Every booking made was saved as a specific reservation with a unique identifier. This was a modern assumption based on every system I’ve used today. I expand on this below.

4. Alternate trains along a route were directly tied to each other. I assumed this based on the discussion of the cross-continental and multi-destination Super Continental trains in the manual, but the behaviour described is more consistent with the system finding literally any train that goes to the same stations rather than having some alternate train tracking.

Taking the booking assumption as an example, here is a relevant section of what the manual says about reservations and what the computer does with them:

…If the seats are available, the Computer will decrease the inventory over the legs involved by the number of seats requested and reply:

OK00101 FEB12 040/1045

The meaning of the reply "FIELDS" is as follows:-

"OK" - The reservation has been made for the seats, legs and train requested….

Given my modern understanding of reservations, I assumed that each reservation would result in a record added to a table somewhere to track it, and it would be managed at that level.

However, this assumption was disproven in two ways. First, when implementing the cancellation logic, I ended up having to randomly grab reservations from the reservation table to match the behaviour described in the EPRS manual. See:

Input format:

MTLAKZ TORMTL 06 06410 045»

(Cancel six coach seats in car 06410 for Feb. 14).

And also the response:

Inventory will be adjusted upward, and the reply will be:

CL06410 FEB14 040/1053

The meaning of the FIELDS is similar to that of the "RESERVED" reply.

Given that I implemented the reservation system before the cancellation system, it was easy to justify storing that specific reservation rather than a simpler inventory system. But especially by the cancellation formats it became clear that there was no actual tracking of each reservation, and instead only the inventory of seats in each car is tracked.

I further confirmed this in two ways. First, the description of functionality for supervisors to add and decrease inventory expresses this behaviour more plainly:

THE "ADD" TO INVENTORY COMMAND

Except for FIELD 1 ("Action" requested) this command is identical in format and activity to the "CANCEL" card. It is provided as a separate card basically for operating convenience,

THE "DECREASE" INVENTORY COMMAND

Except for FIELD 1 ("Action" requested) this command is identical in format and activity to the "RESERVE" card.

However, I did not closely read this section until later as I was focused on implementing the core operators’ functionality. By that time, the reservation by specific bookings system was done and can be viewed as a long-passed commit on the Git repo for this system.

Once I discovered this mismatch in implementation, I re-worked my implementation to match the descriptions of the manual better. I was also able to confirm this in a second way at the Real Rails convention in Burlington this year where I talked to the fine people at the Via Historical Association booth about the system. While talking with them, someone who had travelled in this period and remembered the process in enough detail to provide me some certainty in my understanding joined in on the conversation.

This person had travelled regularly through the 70s from Quebec to Saskatchewan. He remembers clearly that the station agent would use a mark-sense card to check the availability and reserve seats and sleeper cabins (notably not in the manual) for travel. The agent then did the further action of issuing a ticket directly, not involving the EPRS machine.

Finally, I bought a 1966 manual for sales agents at CNR. This manual describes that the agent would use the EPRS machines to check inventory, but was ultimately responsible for writing a ticket manually. As well, it directly confirmed that the computer had no capability to register or otherwise track each customer:

Another interesting confirmation of my implementation came from an unexpected source: the file sizes involved in my implementation. I ended up with a system that used a ~11MB database. While I don’t have any documentation on how the data were stored for the original system I do know, courtesy of the Computer Society of Canada Census of Digital Computers in Canada of 1967, that the original system had 17.3MB (well, MegaWords, close enough) of storage attached to it. This tells me that I am storing the right magnitude of data and suggests strongly that I was right to remove the extra detail on routing and bookings.

In order to share this system with others I figured I needed to host it online and point a front end web application at the system. I had been using an AWS EC2 instance to run the Postgres DB and host the development environment for the iPad I was working on this during my cottage vacation. This made an easy core for the tech stack. 

As well I did not want to figure out running an API from an actual (or at least virtual) server given that the majority of my experience is around serverless applications, so I set up the backend to work within an AWS Lambda, and that Lambda would contact the EC2 instance. Finally, I put an API Gateway in front of the Lambda to run the API keys and provide a more seamless experience.

For a front end, I have been hearing developers that work on my products rave about the cross-platform abilities of React, so I figured it was about time to learn at least the basics of it. I made a simple page in React with a lot of help from w3schools and some bug hunting with Gemini. I hosted it on AWS Amplify to round out my all-AWS stack.

You can view the finished application here, the code for the backend is here, and the code for the front end is here. If you have experience with any of the systems that CN used, either freight or passenger, as either a CN employee or as a customer, please let me know!

Here are these scans for your convenience should you also be interested in these! Download

As well, I digitized the office memo for some fun with friends, so if you want a modern PDF version of that, here it is: Download

I aspire to eventually upload the rest, but we will see.

Throughout the first day of the event, I heard (somewhat cheekily) from some of my fellow exhibitors that I was missing the entire Apple II line! While true that I did not have any II’s in my lineup, I thought I had a good excuse - my Apple IIe clone that I have at home had a bad power supply, and besides this was more of a Mac display.

Unfortunately, they got to me, and one of them was selling a IIC in good condition with a second IIC for parts included at a reasonable price. So it was that by 4PM, I was the proud owner of an Apple IIC.

The Apple IIC, for the uninitiated, was Apple’s attempt at a portable Apple II. It comes with a carry handle at the back, and is about as small as a computer with an integrated 5.25” floppy drive can be. It was released at roughly the same time as the original Macintosh, and was essentially a IIe with the usual expansion cards (2x serial, disk controller, mouse, printer) permanently installed.

This computer had that, but unreliably. My trouble started when I tried to write some floppies using ADTPro, a solution for passing data from a new computer to an Apple II. While I could often pass the data TO the machine (although not fully reliably), I could not format a floppy disk and save the data to it. 

So I had two problems:

1. Cannot write floppy disks

2. Cannot reliably use serial connection

My next step after ADTPro was to try a FloppyEmu floppy emulator, which I could not get to work correctly, and through stupidly replugging while the computer was on, I fried. The external floppy drive I had plugged in also appeared to be damaged by this mistake.

So now I had four problems.

1. Cannot write floppy disks from internal drive

2. Cannot reliably use serial connection (a known issue for Apple IICs)

3. Cannot use external floppy drive

4. Cannot use FloppyEmu

Cutting my losses, I asked a friend from the local vintage computing group for some disks to get me started. They gave me some system disks, and a couple copies of MECC Computer Inspector. Running Computer Inspector yielded a report that the disk speed was OK, but the disk was running badly.

With this piece of information, I identified a few potential fixes I could tackle:

1. Clean the floppy drive

2. Swap floppy drive with donor machine

3. Rebuild/recap power supply

The easiest fix was to clean the drive, and so I broke out some 99% isopropyl alcohol and cleaned the head on the drive inside the main machine. Some amount of dirt came off, and the drive appeared to work, but after being on for 10 or so minutes, the drive failed to write, and made a loud sound:

That sound from the drive was somewhat new, so I swapped the donor machine’s drive and the main machine’s internal drive to no success. Finally, I went to the retro computing Stack Exchange so that I could see if I could get some help with diagnosis of the issue. 

The kind folks there advised me that this sound was mostly normal, but indicated that the computer was having some trouble with reading data. The computer makes a more rapid sound when a DOS (e.g. ProDOS or DOS 3.3 in this case) is loaded, since these OSes can allow the drive to work faster, in much the same way as programs on other computers of the time (C64 in particular) can have faster disk access speeds with the right software.

Based on my experience with my IIe, I (mostly wrongly) assumed this was a power issue, figuring that if there was insufficient voltage going to the drive during reads, it would fail to read/write, and that the variable timing of the issue was heat-related. I bought a capacitor replacement kit for both the internal power supply and for the motherboard itself.

A quick note on IIC power: what is a single power supply in a standard Apple II, II+, or IIe, is two pieces in the IIC. The IIC has an AC adapter brick that steps down the voltage from mains voltage and rectifies it to DC, feeding a straight 12(ish)V into the computer, which has a small switching power supply inside it that can take anything from 9-20V and turn it into the various voltages required by different parts of the computer. The AC adapter brick (apparently) generally never acts up, although I will blame it for the disk issue in the next paragraph. The internal power supply, where all the electrolytic capacitors are, can occasionally act up, and is easily removed and repaired.

The caps arrived a few days later, and I spent an afternoon swapping all of the capacitors to very limited success. Figuring that maybe the problem came from the AC brick, I pulled out my oscilloscope and hooked it into the machine, across the switch. This resulted in a nice spark, so I swapped to using two probes with the math function to emulate a differential probe and tried again. Whenever the drive activated, there was a pretty significant voltage drop, and the mean voltage was going down the longer the computer was on, although not by much.

Still, I thought this was the definite sign of a good diagnosis, and promptly chopped up a thrifted modern AC adapter and a dead AC brick from the donor machine to make a more modern power supply. This did not fix the issue.

It was finally time for me to check the schematics (graciously provided thanks to the Woz back in the 80s) and figure out what else this issue could possibly come from.

The vast majority of the connections from the floppy drive to the computer go directly to one chip: the Integrated Woz Machine (IWM; circled on left above). This chip was made specifically for the Macintosh and the Apple IIC to replace the circuit that was an entire card for previous II models. It manages everything to do with floppy and other drives in the IIC, and does all of the data processing to read and write floppies.

Anyway, I decided to swap the socketed chips (the IOU, ROM, and MMU) with the donor machine. The ROM from the donor machine did not work (probably why it was a parts machine), but the IOU and the MMU appeared to have some positive effect. However, after 20 minutes of running, the drive was still acting up.

Finally, I sucked it up and decided to swap out the IWM. Since it was not socketed, this meant desoldering it from both the donor machine and the main machine. I put on a good podcast and got to work. With the soldering iron set to 320C, the solder came off without too much fuss. I took a lot of cooling breaks to avoid damaging the donor chip, and had to add a bit of solder for stubborn pins.

The previously-installed chip was a different story. Most pins desoldered just fine, but 3 pins in particular were very stubborn. It took a bit of force once all pins were clear, and it turned out one of the pins was digging into the side of the hole, and it ripped up part of a trace. After I soldered on the new socket (to avoid this problem in the future), I checked continuity, and the ripped trace turned out to be a problem. I ended up installing a “bodge wire” on the underside of the motherboard.

After all of this, I plugged in the power supply, flipped the switch, and crossed my fingers…

It’s alive! The external drive is back to functioning, and a new FloppyEmu is on the way! 

In the end, the IWM was to blame for my issues, or at least the loading issue. My suspicion is that there was a small issue there that got a lot worse when I live connected the FloppyEmu, and that nothing was wrong with the PSU or the socketed chips, but I guess I’ll never know for sure!

I hope my misadventures and mistakes are helpful to anyone else with an issue with their Apple IIC’s drive!

In my case, I wanted to connect a TRS-80 Model 100 to my laptop, which was running Xubuntu at the time. The most clear guide for this was written in 2008 and was for Ubuntu 6. Needless to say, things have changed since then.

The first thing to do was to make sure the two machines could talk to each other at all. I have them connected via a USB-RS232 DB9 cable, with a null modem connector in the middle, and a DB9-DB25 converter.

In order to get a stable connection with all the text that Ubuntu likes to throw through the terminal, I found that 600 baud was the maximum speed. If you're only sending to the modern computer, 9600 baud works quite nicely.

The connection string for 600 baud is:

48n1e

Taking this apart, this sets the speed to 4 (600baud), number of bits to 8, parity off, 1 stop bit, and XONXOFF flow control.

To confirm connection on the modern computer, you can use the command screen /dev/ttyUSB0 600, substituting ttyUSB0 for whatever your serial solution is.

With that confirmed, it's time to set up the login session, since it's a lot more fun to use the Model T to act as a real, honest-to-goodness terminal for the supercomputer it's connected to.

There are 4 commands required to set up the TTY console. stty to set the getty up that will give us the actual session, two GRUB-related commands to enable it at boot, and a call to systemctl to start up the getty after.

The stty command I found worked best (based on the article here) was:

(sudo) stty -F /dev/ttyUSB0 speed 600 cols 40 rows 13 erase ^H ixon ofdel

Essentially, I made the backspace match, set the baud rate, and set the columns and rows, as well as enabled software  flow control.

Next is the GRUB config. It's described in more depth here, but essentially you add “console=ttyUSB0” to the end of the “GRUB_CMDLINE_LINUX” string. You can (probably) find your default GRUB config at /etc/sysconfig/grub.

Next, run update-grub to update GRUB.

Finally, use the following to start the getty:

(sudo) systemctl start getty@ttyUSB0

And that's it! You should now be able to start a terminal session from your terminal when plugged in!

Some extra notes for usability:

• You probably want to change your bash prompt to something short (“$>” is mine, and the Model 100 will occasionally add more characters)

• Likely, some of the control codes your modern computer will throw at the terminal won't register. I just ignore those, but if you find an easy addition to the stty command (or elsewhere), please let me know!