Derive Source Code?
Derive Source Code?
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.
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.
Death and drek? WTF?
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.
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.
Death and drek? WTF?
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.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".
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.
Death and drek? WTF?
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.
Marco.
- burgerbecky
- Posts: 9
- Joined: Thu Jan 29, 2009 6:23 am
- Location: Seattle, WA
- Contact:
Source code
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.
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.
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.
Death and drek? WTF?
- burgerbecky
- Posts: 9
- Joined: Thu Jan 29, 2009 6:23 am
- Location: Seattle, WA
- Contact:
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)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.
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.
Re: Source code
Hi there.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.
Any way for us non-programmer types to get a look at these directories and such?
Thanks.
- burgerbecky
- Posts: 9
- Joined: Thu Jan 29, 2009 6:23 am
- Location: Seattle, WA
- Contact:
Re: Source code
Which one? The project directories?Darendor wrote:
Hi there.
Any way for us non-programmer types to get a look at these directories and such?
Thanks.
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
Re: Source code
The Commodore 64 source code, I was referring to.burgerbecky wrote:Which one? The project directories?Darendor wrote:
Hi there.
Any way for us non-programmer types to get a look at these directories and such?
Thanks.
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