Restoring The Bilestoad March 2013 Recently Roger acquired an original copy of The Bilestoad off ebay for US$130, and posted an inquiry about being able to make a backup copy of it. Several suggestions were offered, and I followed up with some additional possibilities. Soon, we were off on the adventure of decoding and capturing all the original data intact, so it could be reconstituted on a normal (i.e. DOS 3.3 compatible) format and preserved with greatest flexibility. Besides whatever original disks have survived in readable/working form, copies of The Bilestoad do exist. Most are in the form of file-based conversions, some of which sacrificed parts of the original intro, and/or introduced modifications to the graphics (aka 'crack screens'). All of these examples have lost the original boot load sequence. A goal of this preservation was to leave as much as possible intact and unmodified, other than to let it work on a normal format. This goal was made fairly easy, due to the original using a very similar format to regular DOS 3.3 - but with a few twists. I started out by sending Roger a copy of my old utility disk, which boots and loads The Inspector, and also has a copy of Advanced Demuffin on it. Those two tools will help accomplish just about any conversion task. The Inspector has an option ('N') to do a nibble read of a track, which can then be saved like a picture file. So I had Roger take a read of track 0, save the file, and then send it to me. [Side note: throughout this whole process, only Roger had access to his original disk; I just had him send me bits of data at a time. Although we now have more modern tools like email, the Internet, and ADT, this process is still *very* similiar to how things were done 30 years ago when we used modems.] Once I had the image of track zero, I could see things like this: 000000f0: 96 96 96 df aa eb eb f5 ba fd fa fd fd fd fd fd 00000100: fd fd fd fd fd fd fd fd fd fd fd fd d5 aa 96 ff 00000110: fe aa aa ae ae fb fa df aa eb 96 fa ff e9 fe ff 00000120: ff ff d5 aa ad b4 ed db af e5 b4 ed e9 f6 ce f5 00000130: f4 f4 ce bc e6 b4 96 af dc af f4 ae b9 a7 e7 f4 00000140: bb be ee ee ff e6 b3 ec e9 ab 97 b4 fc 9d b3 fd (of course it looked a bit different on an Apple II screen) But this nibble data tells me that at least for track zero (after looking at all the nibble data for it), the disk used a standard address marker of D5 AA 96 and data marker of D5 AA AD, but had a modified epilogue of DF AA instead of the usual DE AA. This was good, since it indicated that we might be able to easily convert the data using Advanced Demuffin. So I next had Roger fire up Advanced Demuffin, and just modify the default DOS 3.3 RWTS that's already loaded to use DF AA instead of DE AA and see how it went. With this one change, tracks 0 through 6 were able to be converted before the disk started grinding and wouldn't read any more tracks. Roger then sent that to me as a disk image. With this data in hand, I was then able to perform a regular boot trace and see just what was going on under the covers of the code. I knew I'd have to change an expected DF to a DE (since this was now normalized format), so my goal was to see how far I could get it to boot. Today we may still have crosswords and things like Sudoku, but there's still nothing quite like a clever and interesting boot to present a good puzzle. This is a snippet of The Bilestoad's boot0: 0801- 46 27 LSR $27 0803- 90 29 BCC $082E 0805- A5 2B LDA $2B 0807- 45 27 EOR $27 0809- 0A ASL 080A- 45 27 EOR $27 080C- 0A ASL 080D- 8D 00 08 STA $0800 0810- 2A ROL 0811- 2A ROL 0812- 2A ROL 0813- 8D 2D 08 STA $082D 0816- 49 2B EOR #$2B 0818- 29 F8 AND #$F8 081A- A8 TAY 081B- B9 6F BF LDA $BF6F,Y 081E- 99 68 BF STA $BF68,Y 0821- A5 27 LDA $27 0823- 85 3D STA $3D 0825- B9 6A BF LDA $BF6A,Y 0828- 99 6C BF STA $BF6C,Y 082B- 4C 5C 08 JMP $085C 082E- 08 PHP 082F- 85 27 STA $27 0831- CE FE 08 DEC $08FE 0834- A6 2B LDX $2B 0836- 6C 3E 00 JMP ($003E) 0839- EE FE 08 INC $08FE 083C- EE FE 08 INC $08FE 083F- EE FE 08 INC $08FE 0842- 20 89 FE JSR $FE89 0845- 20 2F FB JSR $FB2F 0848- A6 2B LDX $2B 084A- 6C FD 08 JMP ($08FD) 084D- 00 BRK 084E- 0D 0B 09 ORA $090B 0851- 07 ??? 0852- 05 03 ORA $03 0854- 01 0E ORA ($0E,X) 0856- 0C ??? (All of this is still intact on the restored normalized version.) Without spoiling for those who'd like to figure it out on their own, I'll just say that it includes some nice obfuscation, self-modifying code, and a neat twist in the chase. But, by following the boot, I was able to see that the RWTS does load into the text screen area ($400-$7FF), and so I was able to correlate that to its location on disk, which allowed me to modify the compares for #$DF to be for #$DE instead. With that small change in place, the disk was able to boot and I was presented with the original title screen and intro animation, after which it waits for a keypress. By studying what happens in the code after it gets a keypress, I could see that it made several calls to the RWTS in succession, each one loading in a whole track at a time to specified starting page. Eight of them to be exact. But the twist was that just before making this run of loading eight consecutive tracks, it makes one call to its SEEKABS routine (which is the routine to 'seek absolute', or locate to a track) to locate to track $0D. Or rather to a count of $0D half tracks - yes, the RWTS is based on using half track counting rather than whole track counting. The ending boot track of $06 is $0C (i.e. 2x the whole track count) in terms of half tracks, so positioning to $0D places it on track $06.5 in advance of the next loading sequence. With the disk positioned now on track $06.5, the next eight tracks would be $07.5 through $0E.5. No other changes to markers or anything, so it seemed pretty straightforward - I needed Roger to just use Advanced Demuffin and convert those eight tracks, and then I could stitch it all together. And then if I just had the program skip the little half track position, everything would line back up and it would use tracks $07-$0E instead, none the wiser. Best laid plans. Roger did try that, using the info I'd previously provided for getting tracks 0-6, but the disk just ground, and the reads all failed. I was puzzled. I dug back through some ancient info on Advanced Demuffin, because I knew that it supported half tracks. But what I failed to remember was that regular DOS 3.3 (through the normal IOB entry points and such) doesn't. The default IOB (which is the "I/O Block" for setting up the call to the RWTS, with things like what track, sector, and memory location to read into) in Advanced Demuffin does receive the track info in terms of half track counts, but immediately divides it by two before calling into DOS's RWTS. Doh! So, I had to find a replacement RWTS that I could use and preserve the use of half track counts. I rummaged around the old collection of code bits and scraps I have of assorted RWTS and loaders, and found MINI RWTS, which was another creation of The Stack (I think). This little gem allows you to create a small RWTS (or R_TS, more accurately, since it only reads) that takes up only $297 bytes and locate it on any page boundary (below $A000). And it's simple to set up, since it just uses a few zero page locations for track, sector, count, and buffer. But, it also wants to use whole tracks. So I modified it to instead use and preserve half track counts in and out, and while I was at it, use #$DF instead of #$DE, so it could read all the Bilestoad disk straight away. I made a new IOB module to go with it, and sent the RWTS and IOB files to Roger. With these new tools, Roger was able to successfully read tracks $07.5 through $0E.5 and convert the data. I then stitched that data onto a disk with the tracks 0-6, and the only other change to the code I made was that instead of a JSR to the SEEKABS routine that would position the original disk to half track $0D, I made the JSR a BIT instruction (so the $20 became a $2C). This leaves the overall flow intact, along with the intent still in place, just not the execution. On the original disk, tracks beyond $0E.5 didn't read, so are likely not formatted (we tried both half tracks and whole tracks, just in case). Now there's a restored Bilestoad image, nearly identical to the original, including its original boot and RWTS. Thanks to Roger for making available a rare disk, and helping to preserve it. Later, Hot Rod [One footnote: I found out afterwards that this same protection scheme was also used on Mating Zone, also from Datamost. Krakowicz describes it in his Basics series number 106.]