## Coming Home

This is my first Atari 8-Bit word processing experience, since 1986. 

It's not a completely authentic experience. I'm running the Atari800 Linux emulator, with the a REV3 130XE rom, and a slightly extended configuration including two emulated 1050 drives, an emulated "generic" printer, and an emulated hard disk (which enables instant access to editors on my host machine). It's as close as I'm going to get to the actual physical experience until I can manage to revive one of the three dead machines in my closet. I'm not a hardware guy, though. So, the prospects are slim. In any case, this will do for now.

I'm using the AtariWriter word processor to type out this article, which amounts to my last big "8-Bit Week" personal challenge. The built-in control codes for things like bold-face and underline are more or less useless today, because of modern printing and publishing. So, I'm using Markdown notation, which can be interpreted by the text editor or web renderer that will receive this as input for presentation. 

The point of this exercise, is just to recapitulate the experience of writing, in the 8-Bit environment.

## The Downsides

There are a few things about this editing experience that I had forgotten about. For starters, the Atari has a 40-column display by default. I think Bank Street Writer has either a 60 or 80 column mode, but I can't quite remember. Bank Street Writer was the word processor of choice in the home I grew up in, because it had keystrokes for control-characters that would change the way the printer would render the 9-pin dot matrix output. Things like bold, italics, underline, and a few special characters. AtariWriter does not appear to include such an option. Even the so-called "Plus" version. What it does offer, is a sort of "soft line-wrap" option. By setting this to 60, or 80, or 120, the text line will extend out that far, and your edit screen becomes a sort of "window" that scrolls left and right, to give you visibility of the line. It's like leaning into a book page, and reading it word-by-word with a magnifying glass. Not great.

Another thing I'd forgotten. Is the little plosive "PIP" noise that the Atari makes, with every single keypress on an edit screen or an input field. I've always thought that Atari should have included a way to switch off keypress noises, because after a while, the constant barrage of pip-pip-pip-pippety-pippety-pip-pip-pip-pip will drive you insane. 

The third disadvantage, is the volatility of work in progress. Right now, I'm banging away at this confident in the fact that I've started the emulator with two active virtual-disk-drives. So, I can pause and save at any time. But, if this was real hardware, and I'd forgotten to turn the drive on, it's a coin-toss as to whether the software would recognize the drive if I switched it on after-the-fact. 

And, finally, the primary disadvantage of a system like this, is the amount of active memory you have to work with as a text buffer. After loading DOS, and the AtariWriter software, there was just under 16k of space to write with on this 130XE emulated rom. Which is supposed to be a 128kb machine. So, if I had a particularly large piece of work I was doing, I'd have to break it up into multiple files to work on it. This is something you just don't think about these days. On any standard system with 16GB of ram, and a typical mid-range multi-core processor, you could literally load up an entire 500 page book without even breaking a sweat (well, LibreWriter might get a little sluggish, but you get what I mean). 

## Cheat Codes

As the previous list implies, There are a number of advantages that the emulation environment provides, that would never have been available to me back home in 1985, which vastly improves the overall experience of the 8-bit environment.

Firstly, I have a dual-monitor setup on my desk, and I have the AtariWriter Owner's Manual open in front of me on the alternate monitor. Back home, we had a 13" Zenith color television mounted on a custom elevated corner shelf that my father built for the computer. Which meant looking up all the time. After about three hours of typing, you'd need physical therapy. 

There is another use for the dual-monitors, as well. Next to the emulator, I have an email client open, a music player pumping soothing writing music to stereo speakers, and a web browser with Atari reference pages open right now. Email and Web didn't even exist in 1985 (outside of services like Compuserv or AOL). And if I wanted music or video, I'd have to prop a boom box up on the desk, or turn the nearby TV on and set it to whatever channel was still showing anything at 1AM when I was typing most of my high school term papers.

Lastly, because of virtualization, and the way Linux works, and the extreme performance capabilities of this multi-core system, I could (if I really wanted to) have two or three of these emulations up *at the same time*. Instant replication of a computing environment that costed thousands of dollars, in 1985. What's more, they could all be pointed at the same directories on my host hard disk. This would be like having the equivalent of a magic wand that could *poof* a new 1050 into existence whenever you needed it, and INFINITE SIO addresses for daisy-chaining the devices. This sort of thing was quite literally science-fiction when I was in high school.

Let's not forget, also, the fact that emulation enables me to make endless amounts of clean screenshots, and hours of "ride along" video, if I wish.

## Final Thoughts

As a programming tool, and a platform for building entertaining and useful software, I think the 8-Bit environment is ideal for light-duty applications. Games, data-entry forms, peripheral hardware controllers (especially on the Atari), aysnchronous communications (via emulated modems to the internet) with things like bulletin boards and email; these are just a few of the dozens of functions I think 8-bit machines are eminently still suited to.

There are a variety of programming languages available on the 8-Bit that are not even considered for larger platforms today. You have much more control over the physical machine itself. Even with so-called "low-level" languages on modern machines, there's still the gatekeeper of various layers of the OS, and the virtualization hypervisors, controlling the hardware. But on the 8-Bit machines, you could use programming languages as accessible as BASIC, to reach directly into every memory address on the box and "POKE" whatever you want into it, whether the OS likes it or not. There's a lot of risk in that, but also a lot of freedom. 

That kind of freedom necessitates something modern computing lacks: independence. Today, despite the immense amount of computing power on our desktops, the vast majority of users - even seasoned programmers - are entirely reliant on (and often come to feel entitled to) what is provided to them by others, through layers of opaque abstraction in a labyrinth distributed libraries. With the 8-Bit, however, you are your own resource. What you can do with the machine is limited only by your own imagination and resourcefulness - and for the most part, nobody is going to be there to save you from your mistakes. To be an 8-Bit user, an 8-Bit hobbyist, or an 8-Bit developer, was to be a frontiersman, an explorer, a settler in an untamed land. I miss that
