The Adventurers' Guild

Actually, no.

I was just "Bravo-ing" because it's funny how they had to hide their monikers amid the boot code of the disk to make sure the code still worked AND that you can still find them by Googling.

O-KAY, folks.

Got a couple gems for ya. I found, quite by accident, how to do Apple ][ boot tracing using some tricks on pages 21-23 of Hardcore Computist #4, and I used this trick to grab the boot sectors of the Bard's Tale 1 disk as would have been loaded using the Disk ][ ordering rather than the RWTS DOS 3.3 ordering.

First up is a memory dump with ASCII symbols, here.

Working on disassembling and commenting the boot frontend now.

Ok. Grabbed the disassembly. Commenting's gonna take a dog's age and a half because I need to manually trace this and see what the hell's going on here.

ll of the above... .. The authors all receive a program called LOADER.O, which writes the loader.. to disk. To create a new LOADER.O after modifyin..an

That the heck is THAT?

Probably "LOADER.O" is an object file assembled from source. Whether the original Bard's Tale has it or if it's an artifact of the modified disk, I'm not sure. So who knows...

I know on the C64 boot disk there's "LOADER.PRG", or so I've seen anyways.

Gah my brain hurts.

Anyway, here y'all go.. my crappy attempt to document the BT1 frontend loader.

http://filebin.ca/stfdts/Bardboot-disasm.txt

Amuse yourselves.

Whoops, made a minor mistake. The last routine that makes sense doesn't use the text screen holes. It's actually loading from a data table after the code - though to what purpose is not clear.

I'm probably going to go back and re-comment that code because I've been reading more of Beneath Apple DOS and getting a better understanding of how native-level disk accesses work. This'll let me see what's being bootstrapped and where it's going.