rob.rho.org.uk

On a recent visit to the Centre for Computing History, our eldest noticed a poster for their upcoming “Bring and Byte” sale and was keen to go along. I’ll admit I didn’t argue too much with the idea, and a few weeks later we were back, cash in hand, poring over the tables of old hardware, software and assorted technical knicknacks.

We picked up a couple of classic devices: an Atari VCS¹, and a ZX81. Neither are rare (in fact, both are notably for selling like hot cakes and jump-starting their respective markets), but they’re interesting from a technical, historical and aesthetic perspective, and I was keen to set them up and explore them hands-on. However, we soon ran into a problem: RF.

Some context, for those who weren’t around in the early 80s (or were around, but weren’t messing around with home micros). TVs of that era didn’t have inputs for external video sources — no composite or SCART, let alone component, VGA or HDMI. Their single input was a connection to an aerial, in order to receive over-the-air broadcasts (Radio Frequency, or RF). Several channels would be sent using different frequencies, and the TV would include a tuner that picked out a particular frequency and decoded that into video and audio to present.

But what if you wanted to use your TV to view something other than live broadcasts? Other devices — VCRs, games consoles, microcomputers — worked like a TV broadcast tower in miniature, and skipped the over-the-air phase. A modulator inside the device would encode the signal at a particular frequency, allowing the TV to be tuned to that frequency and display the result. It wasn’t the most straightforward approach, and it was a bit prone to interference and fuzziness, but it was a practical way to hook up your shiny new technology to the display you already had.

Back in the present, our TV is fortunately old enough to still have an analogue RF input alongside more modern options. I attached the new-to-us devices, hoping that a usable picture would only be a tuning away. No such luck. With the ZX81 there was definitely something there, but with the Atari it was nothing but static.

Asking around, I gathered that more recent TVs only supported standard broadcast formats, and had trouble with the more unusual formats generated by early consoles and computers. I tried again with an old VCR, and with a dedicated RF-to-HDMI converter box. Both gave slightly better results with the ZX81; the text wasn’t legible, but I could at least see where it was, and the way it changed when I typed in some simple BASIC commands gave me confidence that the machine was working, and the problem was just the display. I need to confirm that this is a problem with the RF signal, but if it is it turns out that there’s a straightforward solution — the system can be modded to output composite video, bypassing the RF modulator, with kits as simple as a few resistors and a single transistor. This seems like an eminently doable project, and not too much of a risk as ZX81s are fairly easy to come by.

What of the Atari? Even with the alternative modulators, I still couldn’t get a whiff of a picture. See nothing seemed unlikely, so I began to suspect that the problem might be elsewhere. I decided to open it up to look for any obvious damage, and as soon as I did I spotted the problem. Whoever had been in there last had suffered an off-by-one error when reconnecting the board with the switches and RF modulator to the main unit, leaving an empty connector at one end and a dangling pin at the other.

I corrected the mistake, but I was painfully aware that I’d been powering it on with essentially random wiring to key components. Something could easily have been damaged beyond repair, rendering the whole thing a non-functional (though admittedly handsome) display piece. With some trepidation I hooked everything up again, and flipped the switch… and it worked! Low resolution Space Invaders started immediately marching across the screen to staccato beeps, as colourful and slightly fuzzy as they were in 1980.

Not only was I chuffed that the hardware was working, but it proved a surprise hit with our youngest. The crude-by-modern-standards graphics didn’t put her off, nor did the lack of the gentle learning curve of today’s games. What the VCS does have is immediacy and responsiveness. It can’t do a lot, but what it can do is focussed on the essentials, and four and a half decades later it still shows. I’m glad I was able to bring it back to life, and we’re both looking forward to playing with it some more.

I’ve long been an enthusiastic user of the Kindle — so long, in fact, that my first one had a keyboard. While I’m conscious of the downsides of Amazon’s dominance of the market, and the limitations of a closed device and ecosystem, the user experience of buying and reading books on Kindle is for me a good trade-off. I still enjoy printed books (my reading is approximately 50/50), but I miss the ease of highlighting and annotation, plus the ability to pick up where I left off on my phone, or even in the Audible audiobook. The thing that seals the deal, though, is the eInk screen — especially when paired with a decent frontlight (as it is on all modern e-readers), it offers a great way to access all of this convenience while still being a change of pace from the light-emitting screens I spend much of my time looking at.

My relationship with the iPad is somewhat more mixed. For a long time, I, like many people, couldn’t quite figure out where it fit into a life that already had an iPhone and a laptop. The form factor was appealing enough that I tried to figure out how to use it for “real work”, but the advent of Apple Silicon made it clear that what I was actually after was the iPad’s SoC (and the resulting benefits) in a Mac.

The one thing I did find it consistently useful for was reading. Not fiction — the Kindle knocks it into a cocked hat for that — but things like articles, papers and so on. When compared to a phone screen, the iPad’s additional real estate makes all the difference, especially for documents laid out for print.

Over the years I’ve experimented with a wide array of apps and services to wrangle reading material on the iPad. At present, and for a bit over a year now, I’ve been pretty much all-in on Readwise Reader. This provides a combination of read-later, RSS feeds, annotation and archiving that fits the way I want to work, and now accounts for maybe 80% of my iPad use (probably 95% or more of my non-video use). I’ve disabled all notifications on the device, and removed all apps from the Home Screen. The iPad is my quiet place, one where I can go to read.

Given this clarity of purpose, I began to wonder whether the iPad was in fact the best device to fulfil it. A couple of years ago, I noticed the emergence of a new category of devices — eInk tablets. Led by the reMarkable, these go beyond the functionality of an eReader like a Kindle, and offer more general applications, often with an emphasis on hand-written note taking. I wasn’t particularly interested in that aspect, but the promise of a relaxing screen and distraction-free environment was appealing. I came across the Onyx Boox Note Air 3, with its decent-sized screen and ability to run standard Android apps, and decided to give it a go.

The device gives a good impression right out of the box. Its metal construction is up there with Apple’s; it felt solid in the hand, and I didn’t notice any flex at all. The 10.3” eInk screen is akin to the standard size iPad (a step up from my iPad Mini), with narrow bezels on three sides, and a wider one down a long edge to give a natural place to hold. Overall, it seems like a well built, high end device. If I had a reservation about the physical feel of the hardware, it’s that it’s too well-built. The Kindle’s lighter (and, let’s face it, cheaper) plastic construction makes it a very comfortable device to use for long periods, and one that I have no compunction about tossing into a bag. The Boox is definitely more akin to an iPad in this regard.

The software is essentially a custom shell on top of Android, but crucially it includes Google Play, making it much closer to “normal” Android that the Kindle Fire, the only other Android-based platform I’ve used in earnest. Setting up wasn’t particularly hard, and the note-taking functionality that is pitched as the tablet’s major use case seems to work well. The bundled stylus feels good and works well, and I was impressed by the lack of egg freckles — the hand writing recognition worked near perfectly on my very messy cursive, straight out of the box. The switch between drawing, handwriting and text was often clunky, but no worse than any similar note-taking application I’ve used on the iPad, and better than many.

However, as mentioned, I’m here to take notes. Boox does offer its own book store and RSS reader, but I had zero interest in dipping into yet another ecosystem for either of these. The attraction for me was the Play Store icon, which allowed me to install Readwise and tap into the tools I already use. Unfortunately, this was also where things started to hit trouble.

Installation was easy enough, and I was soon exploring my feed and library. Immediately, it became apparent that the experience had been designed for fast-updating, colour screens, and while the Boox did its best to compensate, the experience fell very short. A variety of screen refresh strategies are available, and it’s possible to select different ones for each app, but even when you go to the effort to do so there’s only so much improvement to be had. Some things that are natural and pervasive on LCDs simply don’t translate to eInk.

The main culprit is scrolling, perhaps the most common navigation paradigm in modern phone and tablet interfaces. On eInk, the display is an unreadable blur when in motion, and even when it stops there’s usually ghosting and smudging left behind. More generally, modern interfaces tend to make extensive use of animation to illustrate transitions (and disguise delays). This is often derided, but serves a useful purpose and is usually a net win on conventional displays. Here, it’s not.

In full awareness that this was something of an experiment, I persevered, and managed to make some improvements. By tweaking settings, and moving to the Beta version of Readwise, I was able to smooth off some of the rough edges. Enabling pagination as opposed to scrolling in the reading view made the biggest difference. However, the experience was still far from ideal. I also downloaded the Kindle app, which offered a pretty direct comparison with my previous eInk experience. Even there, it didn’t quite work as I’d like, as we’re talking about the app designed for phones and conventional tablets, as opposed to eReaders.

Ultimately, it comes down to the fact that the mainstream Android platform isn’t designed for this kind of display. Even with the best efforts of Readwise to accommodate the differences (I don’t expect the Kindle team were trying very hard in this case), the UI conventions and workflows just don’t translate. It might be possible to design, from the ground up, an application platform that worked with eInk as a first class citizen, but perhaps not. Maybe eInk is inherently too specialised for a platform approach to make sense. The Kindle (or Kobo, or reMarkable) can concentrate on doing one task well, rather than diluting its unique advantages by trying to do things it isn’t cut out for.

In the end, I returned the Note 3. It was an interesting experience, and I’m glad I tried it, but I found that, for my use at least, there are too many compromises to justify working it into my digital life. For the time being, I’m sticking with the iPad — it seems to be a better solution to my particular use case. However, I hope that Onyx and others carry on experimenting with new types of device such as this. What we have today is most definitely not all that there ever can be.

In Friday’s post, I described how I’d tried various browsers, but MacWeb was the only one that could run on the very constrained setup I have. I was pleased to get something working, but the results were very basic. It looked like this was as far as I was going to get, but then I remembered one option that I’d not tried: NCSA Mosaic, the very first web browser I ever used (and one of the first anyone ever used).

Mosaic wasn’t the first browser, but it introduced a lot of features that now seem fundamental to the web: inline images, bookmarks, and history navigation. It was the first browser aimed at a broad user base, and was many people’s first experience of the web. Its preeminence was short-lived, however: a student working on the project (one Marc Andreessen) built on the foundations to make Netscape¹, which marked the moment when then the web really exploded.

When I was an undergraduate, my usual haunt was the lab full of SparcStations and Windows/Netware PCs². However, occasionally I’d pay a visit to the more general-use computer room on the floor below, which was intended not for Computer Scientists, but for students of all types to type up essays and check their email. There were more Windows PCs there, but there were also Macs, and it was on one of those that I think I first encountered both Mosaic and the web itself. This was a a long time ago, and I can’t recall the specific model of machine it was — I can’t even recall if the display was monochrome or colour — but I do recall a sense that the web was something very different, and something with a lot of potential.

Back in present day, it was a simple matter to find a period version of Mosaic on Macintosh Repository. Alas, the NCSA FTP archive they refer to no longer appears to be up, so I got it on to the SE via the SD card rather than Fetch, but once there it unpacked fine. I clicked on it with some trepidation, expecting it to fail with an error complaining about the lack of Open Transport, or requiring 8MB of RAM or a 68020, but… it worked! I entered the URL, and up came this site. After a short wait, it even rendered the #MARCHintosh GIF. The presentation was somewhat more polished than MacWeb as well — no CSS, obviously, but a usable if minimal view of the web.

(One interesting note — by default, Mosaic doesn’t show the URL, just the page title. This was a controversial change when Chrome and Safari made it a couple of years back, but it turns out to have a very long pedigree.)

This is pretty much exactly what I was hoping for when I kicked off the project at the start of the month. It seems especially fitting that, in the end, the solution has come full circle to my own first steps on the web.

We went away for a week mid-March, which put my MARCHintosh project on hold. However, we’re now back and caught up, and the Easter weekend presents a chance to pick it up with a few days left. After eliminating iCab (incompatible) and MacLynx (seems to work, but the default window is bigger than the 512x342 screen, making it unusable), I managed to have some success with MacWeb:

This is plain old HTTP, of course — anything like modern TLS seems infeasible. Even then, I hit some problems initially. Some websites would work, but http://rob.rho.org.uk received a few hundred bytes but didn’t actually show a web page.

I suspected that this was a redirect, and confirmed this from the Apache logs, but couldn’t see why. The base domain, http://rho.org.uk, redirects to that one, but the request should be going to it directly. Then I remembered virtual hosts, which rely on the client sending a Host: header. This is required for HTTP 1.0, but it looks like MacWeb wasn’t being 100% compliant. In any case, once I’d figured this out, it was a simple matter to make the blog the default host, and we were off to the races.

As is apparent from the above screenshot, it’s not very racy. There’s no CSS, no images¹, and some modern constructs (notably inline style and script tags) result in source being dumped into the document. However, the basics are there: headings, links, and so on. For a site like this one, with reasonable sensible and semantic HTML at its core, the backwards compatibility story is pretty good. It may be minimal, but I certainly count it as a win: browsing a website from 2024 on hardware that’s older than the web itself.

Side note: I made some progress on the screenshot issue; after a lot of failed attempts to get the screenshots working on modern macOS, and discovering that the obvious ways to convert them to GIFs in classic Mac OS are beyond an SE with 4MB and System 7.0, I’ve come up with a slightly better workflow:

• Transfer the file to the SD card using the BlueSCSI Toolbox. As the SD card is formatted in FAT32, this loses the resource fork and type/creator codes.
• Upload the file to a System 7.0 machine on Infinite Mac
• Use ResEdit to set the type to PICT
• Convert it into a GIF using Graphics Converter there
• Download the result

This is far from ideal, but the result is a pixel-accurate image. I may revisit this rabbit hole at some point in the future, but for now I’m happy to move on to more interesting things.

I’ve not had much time to tinker since the start of the month, but in the time I have had I’ve had some partial success: the Mac SE is now talking to the Internet!

This turned out to be pretty straightforward, mainly following along with the instructions from BlueSCSI. The one wrinkle I hit was that I couldn’t mount the image with the drivers with the software I had. I worked around this by duping it to an actual, honest-to-goodness 3.5” floppy disk. Running from that, everything went smoothly, and pretty soon MacTCP was talking to my router, and from there the world.

So, why am I only calling this a partial success? While, strictly speaking, I’ve already achieved my stated aim, it doesn’t match the picture I had in my mind. When I said “on the Internet”, I was really meaning “browsing the web” — I want to be able to access this very blog from the SE. The networking layer is solved, but when I came to installing Netscape Navigator 2 (which seems like a reasonable baseline), I found that, rather than MacTCP, it requires OpenTransport (an alternative TCP/IP stack — yes, you needed to bring your own back in the day). BlueSCSI/DynaPORT also supports that, so I’m optimistic I’ll be able to sort it out.

Side note: while taking screenshots in System 7 is trivial (just Command-Shift-3), I’ve yet to figure out a smooth way of getting them off the SE in a form readable by modern software. My current workaround is to mount one of the SE’s hard drive images in InfiniteMac, open it there, and then take a screenshot of that. Hence, the above image isn’t of the highest fidelity. I still have the original PICT, and will replace it with a better version once I’ve fixed the workflow.