Not Quite Snowed In
Aug. 17th, 2025 06:34 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
krpalmerRetyping from scratch is one way to produce a second draft, and I can imagine someone telling me reasons why that might be preferable to changing a word here and there. Having to transcribe text out of a window showing the emulated screen of an antique Macintosh with the sense everything I had worked on in the new emulator Snow was locked inside it wasn’t all that pleasant, though. Once I’d posted about that, I went straight back to the emulator and started poking at it a bit more. One menu promised terminals monitoring the emulated serial ports. Digging through my existing archive of disk images, I turned up MacTerminal. A few period criticisms of that program and an awareness of all of the terminal programs that followed it came to mind, but when I tried it out I did find the plain text I’d tried sending in the modem port terminal window, and could copy the text into BBEdit in my modern system. (It had been “hard-wrapped,” though.)
At that point I have to admit my imagination ran away on me. I’d long known how to get full-blown formatted documents out of other Macintosh emulators by selecting the LaserWriter driver and “printing to a PostScript file,” then exporting the file and using a utility to produce a PDF document from it, but I suppose I was thinking of how not everyone had been able to afford a laser printer in the late 1980s. Remembering the command-line utilities I’d got more or less running to turn output from my Color Computer 3 emulator into “retro-printouts” steeped in “dot matrix aesthetic,” I started looking through a familiar repository of antique Macintosh software for Epson printer drivers. I turned up what I thought to be the very collection of drivers my family had used with a serial-to-parallel adapter cable to link our DeskJet 500 to our new Macintosh LC II. While at that point we’d removed the cartridge that had made the DeskJet emulate an Epson FX-80 to work with old Color Computer drivers, the collection did include an Epson FX driver. After managing to load the disk image in Snow, I proceeded to install the driver, even if that had required setting the emulated computer’s clock back into the twentieth century.
I tried printing from MacWrite, but as soon as I’d copied the hex data out of Snow’s printer port terminal window I realised that window only stored the last 8192 bytes of data sent to the port. Even the lowest-resolution output (matching what you saw on a Macintosh screen) required a lot more data to print a single page. While wondering what the most polite way to suggest a future “capture to file” enhancement to the emulator’s developer would be, I did also start thinking of adding an extra step to the “virtual sneakernet” I’d tried before. Snow only writes to floppy disk images using a new “.moof” format (promising to better represent actual disks, including their copy protection) that vMac with its file-export utility can’t read. However, I had managed to load those “.moof” files into MAME before. With the “Ample” front end easing things a bit I tried moving some image files to a disk image vMac could read, only to discover one of them had been corrupted at some point.
It was around this point that I started playing around with the “Disk Jockey” utility that had converted some “hard disk-sized” disk images I’d used with vMac’s somewhat hacked way of access to the more strictly hard disk-like images Snow required. Trying the “Disk-O-Matic” option that could produce disk directories, I discovered it could also extract the data partition back into an image vMac could read. The thought of creating and throwing away disk images on a regular basis did have me wondering about creating a small one just for data transfer, but it amounted to a way to get things out of Snow.
At that point I’ll admit I went back to thinking about the emulated printer port. There’s a toolbar button in Snow that pauses the emulator. After trying it out, I discovered that a quick double-click lets processing run for just long enough to send a few thousand bytes out the port, not enough to overflow the terminal window. I could copy that data into a hex editor I’ve used to poke at “RLE images” and the serial port captures from my Color Computer emulator, then go back to Snow, clear the terminal, and do that over again. The only problem was how many times that had to be done until a page’s worth of data was captured. Every so often, too, the emulated computer seemed to pause itself for further calculations before sending data again.
At last, though, the “printing in progress” message went away, and I fed my captured data into the virtual printer utility I use the most often. All I got out of it was an unusual number of blank pages. Resorting to a different utility did produce some recognizable output, but the amount of glitches in it had me going back to the hex editor and some scanned manuals and books explaining Epson printer codes. After a while, I’d sorted out the “treat this many bytes as graphical data and then expect intelligible commands again” compact with the printer had broken. I’d already realised it was possible to copy only part of a two-digit hexadecimal number from Snow’s terminal, and must have copied some data without realising that. By editing the hex numbers I did massage the most egregious errors out of the printout, but that just made the slim gaps between bands of output more obvious. I’d already noted the line-feed commands in the file all told the printer to roll up the paper so far. Editing them to not roll quite so far closed the gaps. That was peculiar enough, though, that I did think back to when I’d managed to make some modifications to the utility’s source code to close up other gaps. Some double-checking pointed out the driver was issuing yet another line-feed command than the ones the Color Computer programs had used.
Going back to Github to look for the code I’d used before, I did happen on a virtual Epson printer utility I hadn’t remembered seeing. It was supposed to be installed using Python. While it took me a little while to get the necessary steps clear in my mind, I did get the new utility running. It didn’t have the same problem with gaps, although if I went for the full “dot matrix aesthetic” look and had its graphics formed from tiny dots I had to open the PDF output in Firefox and print out again from there to end up with something Preview would display. Returning to my more familiar utility, I figured out what line to adjust this time (line 197) and what number to change there (180 to 216). That solved the gap problem again. For good measure, I took on how the output from Snow produced something with its top lines cut off (I’d never really noticed that with my Color Computer output from Max-10, as it added more blank space at the top of every page) and started increasing a hard-coded constant near the beginning of the file until everything showed up. That, though, was more a matter of cutting and trying than mindful calculations.
As a footnote to all of this I did manage to write the first draft of this post in Snow using MacWrite, copy a plain-text version of that draft to a “small disk image” (although it appears you can’t connect them to the SCSI chain after the Macintosh has booted and have them show up on the desktop), convert that image so that vMac can read it, and export the file from there. At that point, though, I have to admit I’d rethought things enough to split my BBEdit window and retype everything from scratch...
At that point I have to admit my imagination ran away on me. I’d long known how to get full-blown formatted documents out of other Macintosh emulators by selecting the LaserWriter driver and “printing to a PostScript file,” then exporting the file and using a utility to produce a PDF document from it, but I suppose I was thinking of how not everyone had been able to afford a laser printer in the late 1980s. Remembering the command-line utilities I’d got more or less running to turn output from my Color Computer 3 emulator into “retro-printouts” steeped in “dot matrix aesthetic,” I started looking through a familiar repository of antique Macintosh software for Epson printer drivers. I turned up what I thought to be the very collection of drivers my family had used with a serial-to-parallel adapter cable to link our DeskJet 500 to our new Macintosh LC II. While at that point we’d removed the cartridge that had made the DeskJet emulate an Epson FX-80 to work with old Color Computer drivers, the collection did include an Epson FX driver. After managing to load the disk image in Snow, I proceeded to install the driver, even if that had required setting the emulated computer’s clock back into the twentieth century.
I tried printing from MacWrite, but as soon as I’d copied the hex data out of Snow’s printer port terminal window I realised that window only stored the last 8192 bytes of data sent to the port. Even the lowest-resolution output (matching what you saw on a Macintosh screen) required a lot more data to print a single page. While wondering what the most polite way to suggest a future “capture to file” enhancement to the emulator’s developer would be, I did also start thinking of adding an extra step to the “virtual sneakernet” I’d tried before. Snow only writes to floppy disk images using a new “.moof” format (promising to better represent actual disks, including their copy protection) that vMac with its file-export utility can’t read. However, I had managed to load those “.moof” files into MAME before. With the “Ample” front end easing things a bit I tried moving some image files to a disk image vMac could read, only to discover one of them had been corrupted at some point.
It was around this point that I started playing around with the “Disk Jockey” utility that had converted some “hard disk-sized” disk images I’d used with vMac’s somewhat hacked way of access to the more strictly hard disk-like images Snow required. Trying the “Disk-O-Matic” option that could produce disk directories, I discovered it could also extract the data partition back into an image vMac could read. The thought of creating and throwing away disk images on a regular basis did have me wondering about creating a small one just for data transfer, but it amounted to a way to get things out of Snow.
At that point I’ll admit I went back to thinking about the emulated printer port. There’s a toolbar button in Snow that pauses the emulator. After trying it out, I discovered that a quick double-click lets processing run for just long enough to send a few thousand bytes out the port, not enough to overflow the terminal window. I could copy that data into a hex editor I’ve used to poke at “RLE images” and the serial port captures from my Color Computer emulator, then go back to Snow, clear the terminal, and do that over again. The only problem was how many times that had to be done until a page’s worth of data was captured. Every so often, too, the emulated computer seemed to pause itself for further calculations before sending data again.
At last, though, the “printing in progress” message went away, and I fed my captured data into the virtual printer utility I use the most often. All I got out of it was an unusual number of blank pages. Resorting to a different utility did produce some recognizable output, but the amount of glitches in it had me going back to the hex editor and some scanned manuals and books explaining Epson printer codes. After a while, I’d sorted out the “treat this many bytes as graphical data and then expect intelligible commands again” compact with the printer had broken. I’d already realised it was possible to copy only part of a two-digit hexadecimal number from Snow’s terminal, and must have copied some data without realising that. By editing the hex numbers I did massage the most egregious errors out of the printout, but that just made the slim gaps between bands of output more obvious. I’d already noted the line-feed commands in the file all told the printer to roll up the paper so far. Editing them to not roll quite so far closed the gaps. That was peculiar enough, though, that I did think back to when I’d managed to make some modifications to the utility’s source code to close up other gaps. Some double-checking pointed out the driver was issuing yet another line-feed command than the ones the Color Computer programs had used.
Going back to Github to look for the code I’d used before, I did happen on a virtual Epson printer utility I hadn’t remembered seeing. It was supposed to be installed using Python. While it took me a little while to get the necessary steps clear in my mind, I did get the new utility running. It didn’t have the same problem with gaps, although if I went for the full “dot matrix aesthetic” look and had its graphics formed from tiny dots I had to open the PDF output in Firefox and print out again from there to end up with something Preview would display. Returning to my more familiar utility, I figured out what line to adjust this time (line 197) and what number to change there (180 to 216). That solved the gap problem again. For good measure, I took on how the output from Snow produced something with its top lines cut off (I’d never really noticed that with my Color Computer output from Max-10, as it added more blank space at the top of every page) and started increasing a hard-coded constant near the beginning of the file until everything showed up. That, though, was more a matter of cutting and trying than mindful calculations.
As a footnote to all of this I did manage to write the first draft of this post in Snow using MacWrite, copy a plain-text version of that draft to a “small disk image” (although it appears you can’t connect them to the SCSI chain after the Macintosh has booted and have them show up on the desktop), convert that image so that vMac can read it, and export the file from there. At that point, though, I have to admit I’d rethought things enough to split my BBEdit window and retype everything from scratch...