Category Archives: Sub-Etha Software

Wanted: disassembly of Sub-Etha Software’s MultiBoot

11 Replies

Updates:

  • 2025-11-20 – Thanks to a comment from Jerry Stratton, I have the start of a disassembly for the “DOS” code which would load at $2600. Article updated with what I have, so far.
  • 2025-11-21 – Updating assembly to include the raw bytes that were used.
  • 2025-11-21 – Updating the assembly again, using a tool John Linville pointed me to.
  • 2025-11-21 – Removing asm from this page and linking to the GitHub link instead.

To this date I still think one of the most useful products Sub-Etha Software ever created was MultiBoot. For CoCo hard drive users of the era, most of us had to boot from a floppy disk. That boot disk would contain the necessary drivers to access the hard drive. With boot files, “one size does not fit all” so most of us had a stack of them — one for running a BBS with serial drivers installed, one with the Sierra Online drivers for playing those games, one with all the graphics drivers for that stuff, etc.

MultiBoot allowed putting multiple boot files on one floppy disk. Type “DOS” and a menu is displayed. Choose the one you want, then that boot file is made active and the process continues.

MultiBoot was written by myself and Sub-Etha co-founder, Terry S. Todd. I wrote the OS-9 frontend in C, and Terry wrote the actual MultiBoot code in RS-DOS assembly. He would then provide that code to me as data, then my C front end program would “install” it by copying it out to the boot sector of the boot disk.

That code looks like this in the MultiBoot source code:

char mb_sec34_1[] = { /* Terry's RS-DOS DOS startup code... 50 bytes */
   79,83,134,13,151,211,204,56,0,221,209,12,211,142,0,234,204,2,0,237,132,
   134,33,214,211,237,2,220,209,237,4,173,159,192,4,109,6,38,8,76,129,61,37,
   221,126,57,0,126,215,9
};

char mb_sec33_15[] = { /* Terry's RS-DOS MultiBoot code V1.12... 512 Bytes */
   142,56,0,16,142,38,0,236,129,237,161,140,57,0,37,247,23,1,152,23,1,171,
   32,32,32,32,32,32,32,32,77,117,108,116,105,66,111,111,116,32,86,49,46,49,
   50,13,32,98,121,32,84,101,114,114,121,32,84,111,100,100,32,38,32,65,108,
   108,101,110,32,72,117,102,102,109,97,110,13,32,32,32,32,32,67,111,112,121,
   114,105,103,104,116,32,40,67,41,32,49,57,57,51,32,98,121,13,32,32,32,32,
   32,32,32,83,117,98,45,69,116,104,97,32,83,111,102,116,119,97,114,101,13,
   0,16,142,5,192,16,159,136,23,1,53,32,32,32,32,32,85,115,101,32,85,80,47,
   68,79,87,78,32,116,111,32,115,99,114,111,108,108,13,91,69,78,84,69,82,93,
   32,83,101,108,101,99,116,115,32,32,32,91,66,82,69,65,75,93,32,81,117,105,
   116,115,0,246,58,235,23,1,16,206,4,164,246,58,255,16,39,0,209,240,58,235,
   193,8,37,2,198,8,52,20,223,136,189,58,208,53,20,48,136,32,51,200,32,90,
   38,238,182,58,234,176,58,235,198,32,61,195,4,163,31,1,134,106,167,132,16,
   190,58,253,49,63,38,5,50,98,22,0,151,173,159,160,0,39,241,198,96,231,132,
   198,255,129,94,39,17,129,10,39,36,129,13,39,62,129,3,38,197,15,113,126,
   140,27,182,58,234,39,187,247,1,85,74,183,58,234,177,58,235,36,3,122,58,
   235,22,255,126,182,58,234,76,177,58,255,36,160,247,1,86,183,58,234,182,
   58,235,139,7,177,58,234,36,228,124,58,235,32,223,246,58,234,92,141,112,
   48,27,52,16,142,0,234,204,2,0,237,132,204,0,1,237,2,204,1,218,237,4,173,
   159,192,4,109,6,38,79,16,174,4,49,168,21,53,64,198,5,166,192,167,160,90,
   38,249,134,3,167,132,173,159,192,4,109,6,38,50,126,38,2,134,87,183,149,
   201,134,16,183,255,34,204,63,0,253,255,188,189,246,82,126,169,40,174,228,
   166,128,39,6,173,159,160,2,32,246,175,228,57,166,128,39,251,173,159,160,
   2,32,246,126,215,9,142,59,0,93,39,236,48,136,32,90,38,250,57,0,0,0,0,0,
   0,0,0,0,0,0,0,0,0,0,0,0,0,0,66,66,0
};

Are there any 6809 disassembler gurus out there that might take this data and reverse it back into 6809 assembly source code?

Sadly, the only source code from Terry that I have found is that for his MultiBasic product. I cannot even find the master disks for his InfoPatch, and I do not think I ever had sources to ShadowBBS, OS9Term or anything else he wrote.

Thank you for your attention to this matter.

Disassemblies

The “DOS” code would load into memory at &H2600. The first two bytes must be “OS”, and indeed that matches the first two bytes in the data. Per a suggestion from Jerry Stratton, I wrote a program to POKE this data into memory, then used EDTASM Z-BUG to disassemble and do a bit of cleanup.

Where the “??” comment is was something Z-BUG could not decode. There is a value of 2 there. No cluck. BUT, I see a reference to DSKCON (C004) so I am betting if I look up how that works some of this code might make sense.

Help is appreciated!

NOTE: This is now updated using the f9dasm disassembler that John Linville pointed me to:

https://github.com/Arakula/f9dasm

Closer!

DOS Assembly (f9dasm)

https://github.com/allenhuffman/SubEthaSoftware/blob/main/OS-9/MultiBoot/asm/dos.asm

Multiboot Assembly (f9dasm)

https://github.com/allenhuffman/SubEthaSoftware/blob/main/OS-9/MultiBoot/asm/multiboot.asm

Updates

Tim Lindner pointed me to his online javascript disassembler. It did a great job right in the web browser:

https://www.macmess.org/follow9.html

Wanted: disassembly of Sub-Etha Software’s OS9Term

4 Replies

OS9Term was an RS-DOS terminal program written by Sub-Etha co-founder Terry S. Todd. It emulated the OS-9 text screen control codes. This not only included things like color, move cursor position, and underline, but also the overlay windows! OS-9 Level 2 “windows” on the text screen were all created by sending a series of escape code bytes. Terry’s program would let you dial in to an OS-9 machine using a modem and actually run text-mode windowing applications. I recall modifying my EthaWin interface with an option so it would not create its own window on startup. This allowed me to run the Towel disk utility remotely if I wanted. (EthaWin supported a mouse, but was designed so all functions – including the menu system – could be operated from the keyboard.)

It was a neat product, though I do not recall us selling very many copies. Too little, too late, I suppose.

The DSK image for this is up on the Color Computer Archive site:

https://colorcomputerarchive.com/repo/Disks/Applications/OS9Term%20%28Sub-Etha%20Software%29%20%28Coco%203%29.zip

As I went to find that link, I see this .zip has a Play Now button ;-) So here is a screenshot:

I would love to have a disassembly of this code, if anyone out there might be able and willing to take on such a task. The code is not all Terry’s. This program uses the bitbanger serial routines written by Ultimaterm’s Ken Johnston. At some point, Terry got in contact with him, and he provided his routines to Terry. Sub-Etha’s launch product, Shadow BBS, used the remote terminal driver written by Ken.

I don’t even know where to begin with a task like this, so I thought I’d post and see if anyone out there had some suggestions.

Thank you for your attention to this matter.

Wanted: Sub-Etha Software’s InfoPatch for Infocom

Leave a reply

Sub-Etha Software sold a product called InfoPatch. It would take a stock TRS-80 Color Computer Infocom text adventure game and patch it to work on the CoCo 3 using the 80 column screen. As a bonus, it would speed up disk access by setting it to 6ms step rate.

I cannot find any master copies or documentation for this product, but I know we sold it. Here is what I wrote in my 1993 Middle America Fest trip report (from my book CoCoFest Chronicles).

Sub-Etha Software — There we were with our normal line of software including MiniBanners, CheckBook+, InfoPatch, N*Johnson Software, Carl England Utilities, and the new OSK products such as Etha-GUI and the new Write-Right “what you see is what you get” word processor which was the big hit for us. (Joel, you did a great job on this and I think you left many people quite impressed!)

– CoCoFest Chronicles, page 48.

I also mentioned it 1993 2nd Annual “Last” Chicago CoCoFest report:

Oh, just to get a fair plug in…”the same old stuff” includes MiniBanners, CheckBook+, Etha-GUI, and the recent InfoPatch which converts old CoCo 1/2 Infocom text adventures to run in 80 columns on a CoCo 3. We also had Carl England’s disk utilities and some old N*Johnson software. We promise MORE NEW ITEMS for the next Fest!

– CoCoFest Chronicles, page 65.

Here is text from an ad for the product:

InfoPatch by Terry Todd
Patch classic Infocom(tm) text games to run on 80 columns,
upper/lowercase, 6ms disk on CoCo 3.
RS-DOS Req: CoCo 3, Infocom Disk..........$ 9.95

It was still being advertised in 1995. From the Spring 1995 FARNA catalog:

As I go through my Sub-Etha archives, I find this ad copy from 1993 which notes this patch did not work on Seastalker:

NEW!  InfoPatch - Clever hack which patches old CoCo 1/2 Infocom text adventures (like The Hitchhiker's Guide to the Galaxy, Zork, and others) to work in 80 columns, double speed more on a CoCo 3. (Does not work with Seastalker!)  See Adventure Survivors newsletter.
Req:  CoCo 3, Disk Drive, Infocom Game Disk ........................ $ 9.95

And, it appears we launched this product in 1992. From that edition of the “What is Sub-Etha Software” flyer:

A few Sub-Etha ads ran in the Underground and just in time for the ’92 Atlanta CoCoFest Terry would return (but Mark would not be able to attend). Terry’s new offering was InfoPatch – a program to modify Infocom text adventures to run in 80 columns on a CoCo 3. This was also the show that gave life to the “PVC Nightmare” which spawned from the lack of fancy backdrops. Terry and I set out to a late-night hardware store and bought tubing which we hacked up in the parking lot with a newly acquired saw (to make it fit into my Honda) and would later reassemble in the show area and drape a background from it. It was very unstable, but, then again, the same is often said about us. This was our first ‘Fest with a full booth!

– What is Sub-Etha Software flyer, October 1994.

We sold many copies of it. Did you buy one? If so, any chance you could find it and send me a disk image of it? While the source code is likely lost forever, I’d really like to get this item preserved in the Color Computer Archive site.

Thank you for your attention to this matter.

More Sub-Etha Software MM/1 source code on GitHub

2 Replies

I have located source code to some of the MM/1 programs I wrote. It is now uploaded to my GitHub page:

https://github.com/allenhuffman/SubEthaSoftware

This includes…

  • MiniBanners – ported from CoCo BASIC09 to the MM/1 BASIC by Joel Hegberg (he had an MM/1 and I didn’t)
  • MegaBanners – the updated banner program that made use of Joel’s excellent MFONTS library.
  • Towel – the EthaWin library disk utility.
  • TCWin – my termcap windowing system that simulated many of the CoCo and MM/1’s CGFX text windowing calls. This allowed me to port EthaWin stuff over to OSK and OS-9000 boxes running on terminals. (I even ported it to DOS at one point, but lost all that work in a laptop hard drive crash.)

If you have access to an MM/1, I’d love to know if any of this software can be built and ran.

Dissecting my MiniBanners program – part 1

Leave a reply

See Also: part 1 (with more parts to come).

This series of blog posts will discuss my CoCo program, MiniBanners. It will discuss the things that changed between versions, and dissect the code to explore how it worked. The code referenced in this blog post can be found in my new SubEthaSoftware repository on GitHub:

https://github.com/allenhuffman/SubEthaSoftware/tree/main

Part 1 – Origin and versions

MiniBanners is a banner printing program I wrote and sold through Sub-Etha Software. It made its debut at the 1990 Atlanta CoCoFest. It was written in BASIC and ran on a Color Computer 3 using the 40 column text screen. It “required” a CoCo 3 only because I was making use of CoCo 3 fonts that could be LOADM’d and used on the graphics screens with the HPRINT command.

Unlike most (all?) commercial banner programs of the era, MiniBanners did not require a graphics printer. It would work on small printers like the Radio Shack TP-10 (32 columns) or wider ones (132 columns). It would use any ASCII character to make the banners with. Some printers had a black graphics block they could print (Tandy printers, TP-10, etc.), so it could use that. For non-dot matrix printers, it could use an ASCII “X” or “#” or whatever character the user wanted. This let it print to basically any printer – dot matrix, thermal and even daisy wheel. (Remember those?)

Another feature was the ability to print multi-line banners. You could specify the height of each line and either print a one-line banner using the full 80 column width of a printer, or make it four lines with each line of text being 20 characters tall.

I would even switch printer ribbons and print “multi color” banners, but that was not anything that the program directly helped with. Here is a photo of some of the banners we used at a CoCoFest (except for the top one; I think that was done on an Apple 2 using PrintShop or whatever they had back then).

While our initial lineup of programs were all for Disk BASIC (RS-DOS as we called it back then), so many people at the CoCoFest told us “I’d buy it if it ran under OS-9” that it was soon ported over to BASIC09 as an OS-9 program. If I can find versions of that code, I’ll include it in this series in a later installment.

It all began as a one (or two) liner…

I recall finding a free BASIC banner printing program that had an awful font. I wanted to modify it to make the letters it printed look better. I decided to use the font data that was part of the CoCo 3 ROM. This data starts in memory at &HF09D. Here is a snippet from the disassembly:

* SPECIAL CHARACTERS AND NUMBERS
SF09D	FCB	$00,$00,$00,$00,$00,$00	BLANK
	FCB	$00,$00
	FCB	$10,$10,$10,$10,$10,$00	!
	FCB	$10,$00
	FCB	$28,$28,$28,$00,$00,$00	"
	FCB	$00,$00
	FCB	$28,$28,$7C,$28,$7C,$28	#
	FCB	$28,$00
	FCB	$10,$3C,$50,$38,$14,$78	$
	FCB	$10,$00

Rather than rebuild the DATA in the program I was playing with, I decided to just write my own. I quickly had a simple program that would input a line and then print out a banner using this font data. If I recall, I had the whole program fitting in one or two lines.

I had planned to submit it to Rainbow magazine for their “one/two liner” thing they printed in each issue, but I do not recall actually doing that.

It was this simple program inspired me to create a larger program with more features (such as multi-line banners). MiniBanners became Sub-Etha Software’s third product (after ShadowBBS and MultiBasic, both written by cofounder Terry Todd).

It pretended to be in assembly…

I knew most folks would not buy a program written in BASIC. Ads of the time would exlaim “100% machine language.” Because of this, I decided to disguise that MiniBanners was in BASIC by turning it into a “.BIN” file you had to LOADM and EXEC to run, rather than LOAD and RUN to run like a BASIC program.

In case anyone got suspicious and took a disk editor to my .BIN program, I also “scrambled” the contents so they would not look obviously like a BASIC program. You wouldn’t be able to see the standard patterns for line numbers, strings, etc.

I did this by using a short assembly language routine I called SCRAM.ASM. It would take the BASIC program in memory, then “scramble” it by inverting the bits in each byte using the COM op code. That data was then added to an assembly loader routine that would descramble it and set it up to run like a normal BASIC. The end result was you would LOADM”MINIBAN.BIN”:EXEC and have a program running as if it were a machine language program.

In a later installment, I plan to explore that assembly code and try to re-learn how it worked.

For now, let’s discuss the different versions of the RS-DOS BASIC version of MiniBanners.

Version 0.0 – 9/20/1990

According to comments in the code, work began on MiniBanners on September 20, 1990. The goal was to have it ready for the first Atlanta CoCoFest which would be held about two weeks later on the weekend of October 6-7, 1990. The whole program was created in about ten days, including writing the code and manual, and having the manual printed and getting master disks copied (with serial numbers) and labeled for sale at the Fest.

Since this program only came to exist after we had submitted our booth information for the CoCoFest show guide, our entry there has no mention of MiniBanners:

Our entry in the 1990 Atlanta CoCoFest show guide.

Version 1.0 – 10/1990

This was the initial release version sold at that CoCoFest. It ran only on a 40 column screen.

Version 1.1 – 10/1990

This version added support for 80 columns with a new menu option of “W” to toggle between 40 and 80.

It also made specifying the baud rate easier. The user could now just type in 600, 1200, etc. and it would be calculated. In version 1.0, you had to know the POKE value for the desired baud rate. Examples offered in v1.0 were 180 for 600 baud, 88 for 1200 baud, and 41 for 2400 baud. In 1.1, you could just enter 1200 or 2400 and a routine would figure out the POKE value.

I have no idea where I got this from, but I know I didn’t come up with it ;-)

875 REM * Baud Rate Routine
880 POKE150,INT(.2175+5.7825*2^(5-(LOG(BD/600)/LOG(2)))-4.5):RETURN

It also appears the “instant showing screen” trick was not used in version 1.0, as I find routines in 1.1 that set the text palette to the background color. Then, in the GOSUB routine that does input, it sets it back to white. Clever.

50 REM * Main Menu
55 PALETTE8,BG:CLS:PRINTTAB(TB+9)"/) MiniBanners! "VR$" (\":ATTR1,1:PRINT:ATTR0,0:LOCATE0,22:ATTR1,1:PRINT:ATTR0,0:PRINTTAB(TB+13)"Enter Function";
60 LOCATETB+11,6:PRINT"[1] Print a Banner":PRINT:PRINTTAB(TB+11)"[2] Select Font ("FT$")":PRINT:PRINTTAB(TB+11)"[3] Configuration"
65 LOCATETB+11,17:PRINT"[W] Toggle 40/80":LOCATETB+11,19:PRINT"[X] Exit to Basic"
70 LOCATETB+15,3:PRINT"[D]rive:"DR:DRIVEDR
75 GOSUB1055:A=INSTR("123DWX",A$):IFA=0THENSOUND200,1:GOTO75
...
1050 REM * Inkey$
1055 PALETTE8,FG
1060 A$=INKEY$:IFA$=""THEN1060ELSESOUND1,1:LT=ASC(A$):IFLT>96THENA$=CHR$(LT-32)
1065 RETURN

There are also some new POKEs added when setting up the screen:

PALETTE1,FG:PALETTE9,BG:POKE63395,9:POKE63468,9:POKE63503,0:POKE63567,0:POKE63644,0:POKE63771,0

Let’s see if we can figure out what they do. Consulting Super Color BASIC Unravelled should help, or the source code listing at the toolshed repository on GitHub:

https://github.com/n6il/toolshed/blob/master/cocoroms/coco3.asm

First, let’s convert those decimal values into HEX so we can find them in the assembly listing.

POKE63395,9 - F7A3
POKE63468,9 - F7EC
POKE63503,0 - F80F
POKE63567,0 - F84F
POKE63644,0 - F89C
POKE63771,0 - F91B

At the time I was writing MiniBanners, my Sub-Etha Software co-founder, Terry, was deep into patching BASIC for his MultiBasic product. He had picked up copies of the Unravelled series and would tell me neat POKEs to try. I expect he provided me with these POKEs because, at the time, I had no idea how the BASIC ROMs worked beyond using a few documented ROM calls in small assembly routines I wrote.

POKE63395,9 – F7A3 takes me to this bit in the source code:

SF79F	LDA	>H.CRSATT	GET THE CURSOR ATTRIBUTES RAM IMAGE
	ORA	#$40	FORCE THE UNDERLINE ATTRIBUTE

I expect this location is changing the #$40 from an underline to a 9. The original code was setting bits. $40 would be 01000000. 9 would be 00001001. Since these deal with the cursor attributes, I guess we need to figure out what those 8 bits do. The Unravelled book explains this on page 8:

Bit 7 BLINK 1=Character blinks
Bit 6 UNDLN 1=Character is underlined
Bit 5 FGND2 Foreground Color (MSB)
Bit 4 FGND1 Foreground Color
Bit 3 FGND0 Foreground Color (LSB)
Bit 2 BGND2 Background Color (MSB)
Bit 1 BGND1 Background Color
Bit 0 BGND0 Background Color (LSB)
Figure 4 - Attribute byte

The original code was setting bit 6, the underline bit. That make the BASIC cursor be an underline. But the new code is setting bits 0 and 3 which are setting the foreground color to 100 (4) and background to 100 (4). Or maybe that is reversed (since I see MSB/LSB) and they are both being set to 1. Maybe someone can explain it, but I think this is just setting it to a solid color block.

POKE63468,9 – F7EC looks to be the same attribute, but this time involved when printing a backspace.

* DO A HI-RES BACKSPACE HERE
SF7E2	PSHS	B,A
	LDA	#SPACE	SPACE CHARACTER
	LDB	>H.CRSATT	GET THE ATTRIBUTES RAM IMAGE
	STD	,X	SAVE A SPACE ON THE SCREEN AT THE OLD CURSOR POSITION
	ORB	#$40	FORCE THE UNDERLINE ATTRIBUTE

POKE63503,0 – F80F is also related to the cursor attribute:

SF807	PSHS	B,A
	LDA	#$20	GET THE CURSOR CHARACTER
	LDB	>H.CRSATT	GET THE CURSOR ATTRIBUTES RAM IMAGE
	ORB	#$40	FORCE THE UNDERLINE ATTRIBUTE

POKE63567,0 – F84F is just a bit further down, same thing:

	LDB	>H.CRSATT	ACCB ALREADY CONTAINS THIS VALUE
	ORB	#$40	FORCE THE UNDERLINE ATTRIBUTE

POKE63644,0 – F89C is likely this, again:

	LDB	>H.CRSATT	GET THE CURSOR ATTRIBUTES RAM IMAGE
	ORB	#$40	FORCE THE UNDERLINE ATTRIBUTE

POKE63771,0 – F91B is this a bit further down:

	LDA	>H.CRSATT	GET THE CURSOR ATTRIBUTES RAM IMAGE
	ORA	#$40	FORCE UNDERLINE ATTRIBUTE

I therefore conclude that these POKEs are just changing the cursor from an underline (which screams “I am a BASIC program!”) to a solid block. Running these POKEs on a CoCo 3 emulator confirms. Thanks, Terry!

I find a POKE 282,0 added, which is done before calling a line input routine. That address is:

CASFLG RMB 1 UPPER CASE/LOWER CASE FLAG: $FF=UPPER, 0=LOWER

It appears to change the input to lowercase before the user types in the line to be printed. I suppose this saved the user from having to SHIFT-0 before entering their message.

Another line was added, which checks to see if the printer is ready. If the printer is ready, it just goes on and prints. If it is not, it displays the “Ready Printer or Press [X]” message. Nice.

156 IF(PEEK(&HFF22)AND1)>0THENLOCATETB+6,23:ATTR1,1,B:PRINT" Ready Printer or Press [X]";:ATTR0,0:GOSUB1055:IFA$="X"THEN55ELSE156

There is an error handling routine which got updated with the wording changed from “eliminate” to “exterminate” for some reason. Maybe I thought “exterminate” was more clever for a bug?

735 LOCATETB+6,4:PRINT"[ Error"ERNO"reported at"ERLIN"]":PRINT:PRINTTAB(TB)" Honestly, I thought I had it bug-free!":PRINT:PRINTTAB(TB)"   If this was something other than a":PRINTTAB(TB)"   Disk Full or I/O Error, please let"
736 PRINTTAB(TB)"   us know so we may exterminate it."

I also find a few bug fixes. MiniBanners ran in the “double speed” mode using POKE 65497,0. This would mess up disk I/O unless you switched back to low speed with POKE 65496,0 before doing it. I found I had added the slow/fast POKEs in some places that had been missing it, such as this line which loaded a font:

765 A$=FT$:EX$="FNT":GOSUB840:IFA=0THENRETURNELSEPOKE65496,0:LOADMA$+"."+EX$:POKE65497,0

It also looks like I added a “are you sure” confirmation when you exited the program:

95 LOCATETB+5,23:PRINT"Exit Banners? [Y]es or [N]o :";:GOSUB1055:IFA$<>"Y"THEN55

There may have been some other things I missed, but those were the main ones that I noticed.

Version 1.2 – 4/11/1991

This update had the note “fix reset when exiting” but I find nothing in the code that changed from 1.1 other than the version (“1.2”) and the year (“1991”). I may be missing the actual fixed version, and now I wonder what the problem was when exiting. The exit code looks like:

95 LOCATETB+5,23:PRINT"Exit Banners? [Y]es or [N]o :";:GOSUB1055:IFA$<>"Y"THEN55
96 CLS:PRINTTAB(TB+4)"Thank You for using MiniBanners!":ATTR1,1:PRINT:ATTR0,0:PRINT
97 POKE65496,0:POKE150,18:POKE282,255:POKE63395,64:POKE63468,64:POKE63503,64:POKE63567,64:POKE63644,64:POKE63771,64:NEW

It has the “are you sure” confirmation added in 1.1, then I see it POKEs back to slow speed, POKEs to reset the printer baud rate, and POKEs to restore the cursor before erasing the program using NEW. I expect somewhere in the program I did something else that I forgot to restore, and that is what 1.2 was supposed to address. Maybe I will find another copy of this file somewhere in my archives. If so, I’ll update this post at that time.

Looking at this now, I probably should have just reset the machine, or added something to erase the program from memory. After existing this way, someone could have done two POKEs to change the end location of BASIC in memory and recovered the program and had the source code ;-)

Up next … dissecting the code.

Until then…