Hard Copy Appendix
Jul. 20th, 2023 08:41 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
krpalmerGetting a word processor from my own salad days running that much better in the relative convenience of emulation had seemed one more small achievement; as ever, the emphasis appeared required. Not everything done in an emulator is locked within a low-resolution window on a more modern computer screen, but Max-10 was more on the unfortunate side of that. I could save something typed into it as “plain ASCII” and export that file from its Color Computer disk image. However, that meant discarding the formatting that was pretty much the whole point of the graphics-based word processor, treating it as just a more awkward predecessor to something like BBEdit. Back then, the point of most “productivity applications” was to produce printouts, and that was the problem.
A few full-featured emulators I’ve come across have offered “virtual printers” that can save PDF files on the computer they run on. All of the Color Computer emulators I know about are more limited to just saving what’s “transmitted out the serial port” to a text file, which at first thought was suited for plain text output but not the graphics of Max-10. Before I’d quite drifted along to something different, though, I did wonder just a bit if there might be something like a “standalone printer emulator” and started searching for it.
The first thing I turned up was a Python program that promised to interpret the “escape sequences” sent in a stream of 8-bit data to an Epson dot matrix printer and create a single-page graphic. It was something to start with; in typing into Max-10 to get a sense of how it compared to word processors before and since I’d saved a single-page document. More than that, I knew it included an “Epson driver.” To eke an extra year’s use out of our family’s Color Computer 3, my father had bought an “Epson emulation cartridge” with a Hewlett-Packard DeskJet to make much speedier printouts than our previous, low-end Radio Shack dot matrix machine could manage. I reconfigured one of my Max-10 disk images to make sure it was using the Epson driver (but also readjusted the screen colours from the default “black on white” back to the “black on light blue” I’d chosen on a whim all those years ago, perhaps influenced by the bluish cast of the compact Macintosh screen in certain magazine photos), set up the “capture serial output” feature in the VCC emulator for what might have been the first time ever, and picked Max-10’s print option for the first time in three decades.
Out of some measure of caution I’d set the serial output rate to a minimal 600 baud. For some time I wasn’t sure if the emulator had just locked up expecting actual signals back from an intelligent printer or something. Then, I noticed the “clock icon” in the corner of the Max-10 screen that had just meant “loading from disk” before changing from dark to light and back, and at last I had control of the program back. Passing the text file along to the Python program, I wound up with an “SVG graphic” I did have to view in a web browser. All I saw there was a black bar at the top of the image.
I at least had an idea of what had happened. There’d been many comments in computer magazines about what particular printers needed the ASCII code for “carriage return” or “line feed” or both to keep rolling the paper up and how to harmonize this with particular computers. The first thing I tried was to open the serial capture file with BBEdit (which showed a simple jumble of characters, just as I’d supposed) and change the end-of-line option. Now, there were recognizable bits of the printout, but only bits separated by wide black strips.
My worried thoughts were jumping now to signals getting garbled out of an emulator still expecting to receive regular acknowledgements back from a printer. I did remember occasional mismatched points in the old DeskJet printouts, if nowhere near as bad as what I’d got. Managing to keep from dwelling altogether on that, I started searching again about Epson dot matrix commands, and turned up another few programs promising to convert them. The only problem was they had to be compiled from source, which I have next to no knowledge to troubleshoot. After every option I tried just returned errors in Terminal, I started up my Linux virtual machine on the impression it was less finicky compiling than macOS. One program did compile, but the file connection between virtual machine and host computer wasn’t working straight off. Before I’d figured that out again I did notice one last link to a program “fork,” and when I tried that it actually compiled in macOS. This new program could produce multi-page PDFs, but still had the same problem with broken-up output.
At this point I launched a hex editor program I use every so often and began searching for old Epson manuals. Bit by bit, I sorted out the commands that switched into graphics mode and printed vertical lines eight dots high. I was also noticing how certain strips just before the blank spaces had stretched-out, filled-in lower-case “a” and “e” letters. At last I started looking for zeroes in the graphics data that separated individual letters, and figured out the first stretched letter contained an odd run of alternating numbers, hexadecimal “0D0A”. With a bit of searching and replacing, I started guessing at what the correct values should have been. Then, I realised a number that looked right was 0A itself, which would have been a “line feed” outside of graphics mode, and adjusting line endings with BBEdit had meant “carriage returns” being shuffled into the file throughout its length. As I sorted out just how the graphics mode command worked I figured out it ordered the printer to count a specific number of characters following it and interpet them as 8-bit patterns rather than ASCII codes; with extra characters added, the spillover amounted to spurious commands. Searching and replacing got things more or less sorted out, but the real challenge was whether I could get further serial captures ready for processing without resorting to endless manual inspection. Then, I did manage to sort out each end of line order had other codes attached to it to set just how far the paper had to advance to hold the graphics together, and some fairly simple “replace all” work in the hex editor could get things ready.
The printouts now looked pretty good, although one remaining issue was that they started some ways down the first page such that the “page break” space spilled onto the second page and so on. I did know what part of the file amounted to that blank space, and by adjusting a number back bit by bit things seemed to settle down there well enough. Inspired by that I did start wondering about all the other old programs that might use Epson commands in their output, only to then notice the conversion program, while it could deal with plain text as well as graphics, didn’t seem to offer “bold” and “italic.” That meant it just might have been better suited for Max-10 than anything. All in all, of course, I don’t know how much “dot matrix aesthetic” I really need these days (and it still takes a while to get out of the emulator, even with the serial output rate set as high as Max-10 can manage), but another minimal achievement remains something. Having to solve problems did mean understanding more than if I’d just commanded a magic trick’s performance.
A few full-featured emulators I’ve come across have offered “virtual printers” that can save PDF files on the computer they run on. All of the Color Computer emulators I know about are more limited to just saving what’s “transmitted out the serial port” to a text file, which at first thought was suited for plain text output but not the graphics of Max-10. Before I’d quite drifted along to something different, though, I did wonder just a bit if there might be something like a “standalone printer emulator” and started searching for it.
The first thing I turned up was a Python program that promised to interpret the “escape sequences” sent in a stream of 8-bit data to an Epson dot matrix printer and create a single-page graphic. It was something to start with; in typing into Max-10 to get a sense of how it compared to word processors before and since I’d saved a single-page document. More than that, I knew it included an “Epson driver.” To eke an extra year’s use out of our family’s Color Computer 3, my father had bought an “Epson emulation cartridge” with a Hewlett-Packard DeskJet to make much speedier printouts than our previous, low-end Radio Shack dot matrix machine could manage. I reconfigured one of my Max-10 disk images to make sure it was using the Epson driver (but also readjusted the screen colours from the default “black on white” back to the “black on light blue” I’d chosen on a whim all those years ago, perhaps influenced by the bluish cast of the compact Macintosh screen in certain magazine photos), set up the “capture serial output” feature in the VCC emulator for what might have been the first time ever, and picked Max-10’s print option for the first time in three decades.
Out of some measure of caution I’d set the serial output rate to a minimal 600 baud. For some time I wasn’t sure if the emulator had just locked up expecting actual signals back from an intelligent printer or something. Then, I noticed the “clock icon” in the corner of the Max-10 screen that had just meant “loading from disk” before changing from dark to light and back, and at last I had control of the program back. Passing the text file along to the Python program, I wound up with an “SVG graphic” I did have to view in a web browser. All I saw there was a black bar at the top of the image.
I at least had an idea of what had happened. There’d been many comments in computer magazines about what particular printers needed the ASCII code for “carriage return” or “line feed” or both to keep rolling the paper up and how to harmonize this with particular computers. The first thing I tried was to open the serial capture file with BBEdit (which showed a simple jumble of characters, just as I’d supposed) and change the end-of-line option. Now, there were recognizable bits of the printout, but only bits separated by wide black strips.
My worried thoughts were jumping now to signals getting garbled out of an emulator still expecting to receive regular acknowledgements back from a printer. I did remember occasional mismatched points in the old DeskJet printouts, if nowhere near as bad as what I’d got. Managing to keep from dwelling altogether on that, I started searching again about Epson dot matrix commands, and turned up another few programs promising to convert them. The only problem was they had to be compiled from source, which I have next to no knowledge to troubleshoot. After every option I tried just returned errors in Terminal, I started up my Linux virtual machine on the impression it was less finicky compiling than macOS. One program did compile, but the file connection between virtual machine and host computer wasn’t working straight off. Before I’d figured that out again I did notice one last link to a program “fork,” and when I tried that it actually compiled in macOS. This new program could produce multi-page PDFs, but still had the same problem with broken-up output.
At this point I launched a hex editor program I use every so often and began searching for old Epson manuals. Bit by bit, I sorted out the commands that switched into graphics mode and printed vertical lines eight dots high. I was also noticing how certain strips just before the blank spaces had stretched-out, filled-in lower-case “a” and “e” letters. At last I started looking for zeroes in the graphics data that separated individual letters, and figured out the first stretched letter contained an odd run of alternating numbers, hexadecimal “0D0A”. With a bit of searching and replacing, I started guessing at what the correct values should have been. Then, I realised a number that looked right was 0A itself, which would have been a “line feed” outside of graphics mode, and adjusting line endings with BBEdit had meant “carriage returns” being shuffled into the file throughout its length. As I sorted out just how the graphics mode command worked I figured out it ordered the printer to count a specific number of characters following it and interpet them as 8-bit patterns rather than ASCII codes; with extra characters added, the spillover amounted to spurious commands. Searching and replacing got things more or less sorted out, but the real challenge was whether I could get further serial captures ready for processing without resorting to endless manual inspection. Then, I did manage to sort out each end of line order had other codes attached to it to set just how far the paper had to advance to hold the graphics together, and some fairly simple “replace all” work in the hex editor could get things ready.
The printouts now looked pretty good, although one remaining issue was that they started some ways down the first page such that the “page break” space spilled onto the second page and so on. I did know what part of the file amounted to that blank space, and by adjusting a number back bit by bit things seemed to settle down there well enough. Inspired by that I did start wondering about all the other old programs that might use Epson commands in their output, only to then notice the conversion program, while it could deal with plain text as well as graphics, didn’t seem to offer “bold” and “italic.” That meant it just might have been better suited for Max-10 than anything. All in all, of course, I don’t know how much “dot matrix aesthetic” I really need these days (and it still takes a while to get out of the emulator, even with the serial output rate set as high as Max-10 can manage), but another minimal achievement remains something. Having to solve problems did mean understanding more than if I’d just commanded a magic trick’s performance.