Apple Stellar Invaders - full disk version (Pascal)

[Hot Rod <hotrod.apple2@gmail.com>]

Greetings,

Another of the remaining nibble copies I found in my disks was Apple Stellar Invaders (from 1980), written by Mark Allen (who also wrote Sabotage).  Pretty landmark stuff.

Anyway, I know ASI is floating around in file form, but this is the full disk, which boots the Apple Pascal system. I thought it might be interesting to preserve the full disk, since there may be bits and pieces of info still on it (or perhaps someone more knowledgeable about Apple Pascal or UCSD Pascal can do more with it).

But then I remembered why this is still a nibble copy.  Did I mention this was Apple Pascal?  Ever try boot tracing P-code?  It can be done, but is pretty painful.  Since the game is single-load, I suspect the file-version that's available was captured via other means (but I don't know for sure).

All of the disk was actually copyable, except for track $01 sector $0D (DOS 3.3; physical sector $04).  I thought at first maybe all they used was an intential 'bad sector', and the scheme just checked for a 'failure', but that's not the case.  A nibble dump of the track shows that physical sector $04 has an address epilogue of DE AB instead of DE AA, and valid data following the data marker of DE AA AD.

Just changing the epilogue from DE AA to DE AB still resulted in a disk grind, and wouldn't read the sector.  So there was more to it.  I also noticed that the volume number was 1.

I suppose I could have spent more time on the real Apple trying to determine what it was doing, but I just don't have that kind of time any more.  So I cheated.  I took the image I had and loaded it up into AppleWin to have a look around.

What I found was that fairly deep into the boot/load, there was code that modified the disk routines to replace the check of the epilogue #$AA with a jump to a new routine.  This new routine instead did an EOR with #$AB, followed by an EOR with $CD, which is where the volume number resided.  It then did a few more operations on the result, finally storing it at $46 (I'll skip those details).

The disk code was further modified in the routine that does the 6+2 decoding, such that instead of loading A with #$00 before starting to decode the nibbles, it was loaded from $46.  This told me that for this one protected sector, I needed the correct 'seed' value for doing the decoding.

So, back on the real Apple I modified normal RWTS to use #$AB instead of #$AA (although I could have just told it to ignore it), and then right after the 6+2 decoding routine, instead of branching to $B942 (when it fails), I modified it to save the A register value.  The expected final value is normally #$00 on a good decode. Since the whole sequence is a consecutive series of EORs, on a 'bad' decode the final value will be the 'seed' value that is needed to correctly decode this sector.  That value turned out to be... #$01 (probably not a big surprise, given the difference between #$AA and #$AB).

Then just modifying the seed value from #$00 to #$01 at $B900 in normal DOS 3.3 RWTS, finally track $01 sector $0D could be read correctly and saved.  That gave me a completed full disk image.

The only remaining challenge was to circumvent this modified decoding.  Since the .dsk image also didn't have the volume number of 1, I opted to tweak the routine that was doing an EOR with $CD, and just change it to do an EOR with #$01 instead.  That allowed all the sectors to be read 'normally' and keep the code happy.  I found this code on track $04, sector $07, but also out on track $16, sector $01 (with nothing else on that track; which makes me think a test copy was held there possibly). I changed both, just in case.

Now the .dsk image boots in AppleWin, and the game can be played.

I don't know if more can be extracted from the disk, but the Pascal file structures do appear via CiderPress.

I've uploaded the image to Asimov.

]HR