Apple Bard's Tale I Disassembly

[Quantum Reality]

In parallel with ZeroZero's efforts I am initiating the project of disassembling Bard's Tale 1 on the Apple ][. The scope of this will be similar yet different, since I am not only looking to disassemble a memory dump, but also look for similarities and differences to the codebase of the C64.

First off, here's a snippet showing what I think is the relevant section of the randomizer that drops items in BT1:

Click for screenshot

Second of all, the memory managament of the Apple is different and that will impose fundamental constraints on how similar the codebases are.

$2000-$3FFF are absolutely forbidden to the Bard's Tale 1 code on the Apple because that's the high-res page. $4000-$5FFF may or may not be forbidden if the code modifies the same memory page all the time. Typically, however, this lack of page flipping usually causes the screen to flicker because the screen updates aren't synched to the vertical blanking interrupt.

The BT1 code folks may have purposely synched all page updates to $2000-$3FFF with the VBL, though.

As well, all memory above $BFFF is forbidden with one exception, because $C000-$CFFF are reserved for expansion slots and hardcoded EPROMs on them. $D000-$FFFF are the system ROMs.

However, on the Apple, $D000-$FFFF can be "swapped-out" for what's called language card memory. The original purpose of this was to add software support for Integer BASIC on Apples that didn't have it. However the versatility of being able to swap between ROM and RAM that maps onto it gives an extra 12K of RAM, and to top it off, thre is a SECOND 4K bank of $D000-$DFFF that can be swapped-in so in fact there can be three concurrently existing $D000 banks that can be swapped-in and out - the ROM, Language card bank 1, and language card bank 2.

Total: 16K of RAM available above the 48K hardcoded limit for Apples.

So the disassembly of the Bard's Tale will have to include the language card, and I suspect the savestate has this information, since the image is >128K in size.

Anyway, my hold-up on disassembling the savestate is for me to find a disassembler that will disassemble ALL of the savestate. The ones I could find either don't let me save to a text file, or only disassembled a portion of the savestate.

[Quantum Reality]

Some words on the character set as used in BT1 (ZeroZero's post here). The actual bytecodes are essentially identical to the so-called "high ASCII" that the Apple ][ used.

In essentials, and doing some handwaving, the ASCII values for 0-127 are simply repeated with the high bit set for 128-255, although some detail behind the handwaving is that natively in the ROMs, the routine that prints letters will normally internally shift the low bit to high if printing from an Applesoft program.

(Which makes it nice since my character editor doesn't need to do any bit translation or shifting to make character names readable. )

TODO LIST:

1. Disassemble savestate in its entirety (savestate is as of the end of bootup into the Adventurer's Guild)
2. Do a byte comparison of savestates from the AG to savestates when the dungeon disk is loaded
3. Trace the boot process of the Bard's Tale 1 disk to determine the extent to which the operating system is customized. There will be unavoidable changes from the "deprotect" used to get rid of the copy protection by the release group. Aside from that, routines to handle disk access should be traceable and valid for original purchased disks too.

[Darendor]

Are you proficient at Apple BASIC at all? If so you could compare the dungeon editor I wrote if you liked.

[Quantum Reality]

I've been relearning the language pretty rapidly since I began writing my BT1 char editor, so I could certainly look at your dungeon editor.

[Quantum Reality]

Ok, I disassembled track zero, sector zero of the BT1 boot disk. I have added copious comments to the code so you should read the thing with a very LARGE screen.

http://filebin.ca/kueup/compasm2.txt

*** EDIT: I made a mistake: NOMON is the DOS command to turn off monitoring of DOS stuff. MON would turn ON monitoring, so you would see all LOADs, SAVEs, etc normally hidden from you when executing commands. ***

You can grab it there to take a look. Disassembly of the rest continues.

EDIT - I've already caught a couple sneaky code realignments that aren't obvious if you just naively disassemble the code. In one case what looks like garbage is actually a clear-screen JSR.

Code: Select all

614E-   AD 89 C0    LDA   $C089 ; this soft-switch switches in the ROMs, but enables storing to the language card RAM.
6151-   20 58 FC    JSR   $FC58 ; this clears the screen
6154-   A2 00       LDX   #$00

Bwahahaha! Check this. Look at $6156 and notice the text load + exclusive-OR.

If you copy that code and run it against the memory location specified (well, changed for where I loaded the sector), you get this text:

Code: Select all

* CRACKED BY NUMERO 6 FROM THE VILLAGE *

Bravo, gentlemen. Bravo. Just over twenty years ago, this guy wrote up stuff on the Merlin Pro assembler for the Apple.

[Quantum Reality]

Update:

I have a hex dump and complete disassembly of track zero. However, I suspect two things:

1. The code is obfuscated in some way.
2. There is a different track and sector interleaving on the disk than is typical for Apple DOS 3.3. This is not surprising, you can program in a fairly quick different T/S interleave if you know a few things about how to make sure nothing seizes up when you do.

I don' t know when I'll be ready to really plunge in and effectively "hand disassemble" the code, but I will try to take it a bit at a time.

The second prong of this strategy is to disassemble the memory image I have of the savestate. This is waiting on me writing a complete and simple 65C02 disassembler that can disassemble any file of any size. The disassemblers I have found all have serious limitations with respect to a ~200K image.

Update:

The ASM.CODE.2 that showed up is not replicated anywhere on the boot disk, meaning that if there is a catalog track of files, it's heavily obfuscated or simply doesn't exist.

[Quantum Reality]

Further discussion:

I've found that the Computist magazine is absolutely invaluable for figuring out how BT1 was originally copy-protected. Apparently deprotecting it was fairly straightforward.

Also, Computist reports that in fact the DOS 3.3 interleave and track/sector ordering is unchanged from conventional DOS; there were deliberate errors introduced on track 6 and the actual "deprotects" are on track 1.

So what I need to do is figure out how the boot loader on the disk redirects control to track 1, as it appears most of track 0 is gibberish and/or data.

The plot thickens, people!

[Quantum Reality]

I'm learning more about the guts of Apples now than I ever did when I used an Apple //c all the time.

F'r instance I just learned that the boot loader on the Apple is more sophisticated than I first thought.

Apparently the bootloader can natively read up to the ENTIRE first track of a floppy disk if so desired; in the case of the disassembly I did, the first byte at $6100 (Really, $800) is $05. That means five sectors get loaded on boot from zero to 5, so the disassembly shall focus on that area first before seeing what happens next.

[ZeroZero]

On the C64 several parts of the boot disks code is xor'ed with $EA. It is decoded after loading, when the loaded mem is copied/moved to its final place in computers memory. Maybe on apple there is something similar?

[Darendor]

We should all quit our jobs and rent an office block together so we can work on this 9-5.

I get the corner office.

[Quantum Reality]

More updates:

Apparently, for track zero and ONLY for track zero, the way the sectors get loaded using the native disk ][ bootloader is different than the way the RWTS translation table in DOS 3.3 uses. Since I don't have the desire to try and hand translate all of it just for one track, I'm going to have to go with very carefully tracing the code as I mentioned previously when looking at the first five loaded sectors.

- QR, now wishing there were a way to emulate the disk ][ boot loader without automatically passing execution to $801.

[Darendor]

More updates:

Apparently, for track zero and ONLY for track zero, the way the sectors get loaded using the native disk ][ bootloader is different than the way the RWTS translation table in DOS 3.3 uses. Since I don't have the desire to try and hand translate all of it just for one track, I'm going to have to go with very carefully tracing the code as I mentioned previously when looking at the first five loaded sectors.

- QR, now wishing there were a way to emulate the disk ][ boot loader without automatically passing execution to $801.

So...

Even though the game runs the exact same on the Apple II and C64, the two versions operate differently on disk or something?

[Quantum Reality]

C64 DOS is hard-coded into the 1541, as I understand it. There's a REASON why that disk drive is so bloody BIG (seriously. Go look at a picture of one). The boot stage of that OS, as I understand it, boots off a completely different track and sector. ZeroZero can also confirm that the C64 BT1 uses the C64 OS's file structure, which makes it WAY easier to edit dungeons.

The Apple ][ DOS is largely in software and has to be loaded off the disk being booted. This is an artifact of the company wanting to save as much $$ as possible on the disk controller because in the late 1970s a disk drive cost $600.

So yes, there are fundamental differences in the underlying disk-access architecture which makes it harder to see what's going on with the Apple version.

I've been kind of moseying off getting ProDOS disk images so I can start work on the Bard's Tale 3 character editor at long last.

[Darendor]

C64 DOS is hard-coded into the 1541, as I understand it. There's a REASON why that disk drive is so bloody BIG (seriously. Go look at a picture of one). The boot stage of that OS, as I understand it, boots off a completely different track and sector. ZeroZero can also confirm that the C64 BT1 uses the C64 OS's file structure, which makes it WAY easier to edit dungeons.

The Apple ][ DOS is largely in software and has to be loaded off the disk being booted. This is an artifact of the company wanting to save as much $$ as possible on the disk controller because in the late 1970s a disk drive cost $600.

So yes, there are fundamental differences in the underlying disk-access architecture which makes it harder to see what's going on with the Apple version.

I've been kind of moseying off getting ProDOS disk images so I can start work on the Bard's Tale 3 character editor at long last.

I've used a 1541 to defend myself before.

So, this is going to be challenging to work together on a BTI editor that runs on either a C64 and/or Apple II I take it.

[Darendor]

I get a funny feeling this is your cracker group from years ago.

Check this. Look at $6156 and notice the text load + exclusive-OR.

If you copy that code and run it against the memory location specified (well, changed for where I loaded the sector), you get this text:

Code: Select all

* CRACKED BY NUMERO 6 FROM THE VILLAGE *

Bravo, gentlemen. Bravo. Just over twenty years ago, this guy wrote up stuff on the Merlin Pro assembler for the Apple.