The Adventurers' Guild

Is it possible under say WinVICE to obtain the source assembly language code of Bard's Tale and have a look at it? Anyone know?

It's possible, only I don't know how to do it. The crackers use machine language monitors while running a program in order to compose their cracked versions.

A cross-disassembler might be able to produce assembler from the BT executable, but I'm not sure of how to get files off of disk images. I've never tried any of this stuff.

I took a few "snapshots" in Vice. They should be just about as useful as monitoring live memory. I took one in the cellars, and one on the first level of the sewers. I ought to be able to get a general idea of wear in memory the dungeon is loaded by comparing them.

Every square needs several bits of information, at minimum.

In each direction you can have nothing, a wall, a door, or a secret door. That's two bits times four directions--one byte. Next you need one bit for each attribute a room can have: spinner, darkness, anti-magic, stairs, portal up, portal down, -hp, and specials. That's one more byte at least. Finally, specials need some way to point to a message or possibly arbitrary code that will be run when you step on a square. On a C64 you need 2 bytes store an address, though you might be able to get away with a 1-byte offset instead if code is stored along with the data.

So that's a minimum of four bytes per square times 22 times 22, or roughly 2K per dungeon, plus whatever is needed for special text and special code.

I've got some suspects.

Sadly whenever I tried to foray into 6502 assembly language my head began to hurt and all I ended up was uttering "?SYNTAX ERROR".

Darendor wrote:Sadly whenever I tried to foray into 6502 assembly language my head began to hurt and all I ended up was uttering "?SYNTAX ERROR".

Yeah, I did get the machine language monitor in Vice to work. On Linux, you have to run Vice from a console for it to work. Anyway, Alt-M and you are there. You can then step through the disassembled code, view stack traces, and generally do what you'd like to.

I expect the trouble I'll have is that the deciphering of the map data is probably wrapped up in the rendering code.

I'm probably too stupid for this.

A version of BTCS for the C64 maybe?

I remember reading somewhere that Mr Cranford wrote his own little utility that let him put darkness and such wherever he liked.

Hum. BTCS is bad.

One thing that hopefully won't be too hard to figure out is how the game calls for the fixed monster encounters. In places like the catacombs, there are fights with 99 zombies and skeletons and what not -- I would imagine these locations aren't too hard to find in the source code. (how often would the number 99 or its hexadecimal equivalent come up?) It would then be possible to substitute the monsters in the encounters, given that we have a list of all 127 monsters and their hexadecimal numbers. Then we would finally be able to see once and for all what the monsters that were found on the disc but not in the game: Death Denizen (#73) and Lich (#7C) look like.

Marco.

I would venture that LIches look like the Lich King.

I'm sure I've fought the liches on the square in Mangar's Tower, but I'll be dashed if I can remember if it was the Apple 2e or C64 version of the game.

Perhaps playing the game on the emulator for the machine it was ORIGINALLY coded on is in order?

I dunno, any time I want to review the source, I access my perforce server and look at the BTI, BTII and BTIII directories.

It has things like labels, comments and programming notes, plus as an added bonus, all my complaints for the GS/OS, C64 and Apple ][ gotchas I had to program around.

Woo-hoo!

It's awesome to see one of the implementors in the neighborhood.

I noticed in the memory dump that the C64's kernel code isn't even used. I would've thought that stuff was essential, but I suppose if the code was going to be at all portable you'd have to write sort of your own 6502 operating system layer.

See, I'm just talking out of my bum, now. Nerd excitement! I didn't hear about your blog until just a few days ago. I gotta check it out.

Horpner wrote:Woo-hoo!

It's awesome to see one of the implementors in the neighborhood.

I noticed in the memory dump that the C64's kernel code isn't even used. I would've thought that stuff was essential, but I suppose if the code was going to be at all portable you'd have to write sort of your own 6502 operating system layer.

Yes, I wrote my own disk subsystem to speed up I/O to the 1541 drive and to save memory so I can load bigger art files and keep a data cache (To reduce disk I/O)

I had several versions of my "OS" with a single API so I wrote the game code once and it ran on all platforms instantly.

burgerbecky wrote:I dunno, any time I want to review the source, I access my perforce server and look at the BTI, BTII and BTIII directories.

It has things like labels, comments and programming notes, plus as an added bonus, all my complaints for the GS/OS, C64 and Apple ][ gotchas I had to program around.

Hi there.

Any way for us non-programmer types to get a look at these directories and such?

Thanks.

Darendor wrote:
Hi there.

Any way for us non-programmer types to get a look at these directories and such?

Thanks.

Which one? The project directories?

A
AP
B
B.a65
B.S
Bard.Rez
BardList
BUNDLE.a65
BUNDLE.S
CD.a65
CD.S
Dem.a65
Dem.s
Demo
DemoList
L
M
Misc
O
P
PP
RBUNDLE
RezEqu.a65
RezEqu.s
S
W

burgerbecky wrote:

Darendor wrote:
Hi there.

Any way for us non-programmer types to get a look at these directories and such?

Thanks.

Which one? The project directories?

A
AP
B
B.a65
B.S
Bard.Rez
BardList
BUNDLE.a65
BUNDLE.S
CD.a65
CD.S
Dem.a65
Dem.s
Demo
DemoList
L
M
Misc
O
P
PP
RBUNDLE
RezEqu.a65
RezEqu.s
S
W

The Commodore 64 source code, I was referring to.