msdos dissasembly

Any developer realated stuff
User avatar
ZeroZero
Posts: 286
Joined: Tue Mar 10, 2009 9:10 pm
Location: Germany

Post by ZeroZero »

You should find, that the DOS gfx are pretty much the same like the
C64 gfx, except that on the C64 each gfx was an own file, while in DOS
all gfx are in sort of a library file and compressed.

I think, that all versions using the same gfx (Apple II, C64, DOS, CPC etc)
use the same gfx format originated from the Apple II.
Desmet Irkm
Posts: 35
Joined: Fri Nov 11, 2011 2:50 pm
Location: .de
Contact:

Post by Desmet Irkm »

A bit unrelated to the most recent posts, but anyway:

if you decode the levels, the strings are encoded with the C64 encoding as ZeroZero described in the thread on the C64 disassembly. Instead of coding the mapping yourself, you can also read it from a memdump of the msdos version. It starts at 0x000c4742 and goes for 256 bytes.

Decoding the level texts in python looks then something like this (example for the dungeon name):

Code: Select all

# first: load and decode level data into lev1, then ...
dname = lev1[0x0418:0x0422]

data = btfile.load_file("MEMDUMP.BIN", msdos_bt1_path)
start=0x000c4742
c64enc=str(data[start:start+256])
print "".join(c64enc[c] for c in dname)
I haven't been able to find the table directly in bard.exe as that is jumpled by the compression and I can't decompress it on the fly, but that would be much nicer (anybody?).

And BTW: Caracas, when you do a memdump in dosbox, you could also use the memdumpbin command, as that writes out the dump in binary and you don't have to translate the hex chars first.
Caracas
Posts: 89
Joined: Thu Jan 20, 2011 9:16 am
Location: Belgium

Post by Caracas »

I have a script now to do that for me, so I don't mind :D

Besides, dumping the memory in hex format allows me to copy it in a hex editor and makes searching through it a bit easier.
Desmet Irkm wrote:I haven't been able to find the table directly in bard.exe as that is jumpled by the compression and I can't decompress it on the fly, but that would be much nicer (anybody?).
What table do you mean?
Desmet Irkm
Posts: 35
Joined: Fri Nov 11, 2011 2:50 pm
Location: .de
Contact:

Post by Desmet Irkm »

The table that stores the C64 character encoding. For every one of the 256 C64 characters there is the corresponding ASCII character at exactly that position in the table, e.g. 'A' is at 0xC1 in that table, 'B' at 0xC2, 'a' at 0xE1 and so on. So, obviously* the table must contain something substrings like "ABCDE..." and "abcde...". I can find that in memdump.bin, and the other characters then match ZeroZero's description of the encoding, but I can't find the same bard.exe. There is something that looks a bit like the table should look, but much of it is kind of shuffled.

*Well, not quite obvious, there are (old, stupid) character encodings like EBCDIC for which this is not true, but for the C64 encoding it seems to hold. BTW: Is that encoding C64 or is it Apple ][?
User avatar
ZeroZero
Posts: 286
Joined: Tue Mar 10, 2009 9:10 pm
Location: Germany

Post by ZeroZero »

That is the original Apple encoding, since the game was made for that
8-bitter first. Most further versions kept the strings and decoding routines
were added instead.
All the 8-bitters had their own character sets, although most claimed
that they had also an ASCII-mode (7 bit of course), which were on
none of them really true... LOL

Btw. Desmet, did u receive my email?
Caracas
Posts: 89
Joined: Thu Jan 20, 2011 9:16 am
Location: Belgium

Post by Caracas »

I've been checking the bard.exe file a bit closer. It starts with a lot of offsets into itself:

Code: Select all

4D 5A 30 01 65 01 80 04 22 01 F8 05 FF FF 28 31 00 04 00 00 DC 10 66 03 1E 00 00 00 01 00 8F 03 00 00 82 03 00 00 75 03 00 00 6D 03 00 00 54 03 00 00 3B 03 00 00 22 03 00 00 00 03 00 00 ED 02 00 00 E5 02 00 00 CA 02 00 00 AE 02 00 00 86 02 00 00 7E 02 00 00 6B 02 00 00 63 02 00 00 43 02 00 00 2B 02 00 00 1E 02 00 00 16 02 00 00 0A 02 00 00 F5 01 00 00 E9 01 00 00 D4 01 00 00 C8 01 00 00 B2 01 00 00 9C 01 00 00 94 01 00 00 8C 01 00 00 7E 01 00 00 72 01 00 00 64 01 00 00 58 01 00 00 50 01 00 00 48 01 00 00 34 01 00 00 10 01 00 00 04 01 00 00 FC 00 00 00 F7 00 00 00 E6 00 00 00 E1 00 00 00 D2 00 00 00 CA 00 00 00 C3 00 00 00 BA 00 00 00 AE 00 00 00 A5 00 00 00 9D 00 00 00 96 00 00 00 8D 00 00 00 84 00 00 00 7F 00 00 00 7A 00 00 00 72 00 00 00 66 00 00 00 5B 00 00 00 51 00 00 00 44 00 00 00 22 00 00 00 13 00 00 00
(this is just a small part of it)

The actual data - I guess subroutines and functions and whatnot - start at $1220 in bard.exe. The lowest offset I could find is at the end of the code above, 13 00 00 00.
Adding $13 to $1220 gives $1233. That's where the first subroutine (or whatever it is) starts.
The next one starts at $1220 + $22 = $1242
Next one at $1220 + $44 = $1264
and so on...
Maven
Posts: 138
Joined: Sat Apr 16, 2011 9:39 pm

Post by Maven »

Those offsets would be the fixup table in the standard .exe header, wouldn't they?

I'm looking into what it will take to get the debug version of DosBox so I can do some disassembly. I ran some statistics on the character creation, and I think I have a good idea how the 5 attributes and hit points and spell points were randomized, but the starting gold is giving me fits. There were just too many possible outcomes to run a distribution analysis effectively. I might have to break down and disassemble the program after all.

It looks like for the character attributes, they take the last 6 bits of the random number, take the integer square root of that, and add that to the base attribute table. Anything higher than 6 is run again.

Spell points are straight random added to the base, but then extras are added for high int.

It has been fascinating.
Maven
Posts: 138
Joined: Sat Apr 16, 2011 9:39 pm

Post by Maven »

Wow. OK, so here's how it really calculates attributes:

There is a table of minimum attributes for each class, just like the one ZeroZero posted for the c64 version. However, the attributes are not a straight random added to it. It basically rolls two seven sided dice, and takes the higher of the two to add to the base value. Here are the base values:

Code: Select all

Attribute Bases are at 3bc4
Human     0A 06 08 08 05
Elf       08 09 09 06 06
Dwarf     0C 06 07 0A 03
Hobbit    04 06 0C 05 0A
Half-Elf  09 08 09 07 06
Half-Orc  0B 03 08 0B 04
Gnome     09 0A 07 03 04
And it does cap at 18.

Gold is similar. It rolls two 60-sided dice, discards the lower of the two, and adds 110.

Hit Points is different. It rolls one 15-sided die, and adds 14.

Spell points are done in a different place, so I haven't looked at the disassembly for that yet. But from the distribution I saw, I think it is a straight random but with bonus for high int.
drifting
Posts: 153
Joined: Wed Dec 07, 2011 10:21 pm

Post by drifting »

Maven wrote: Spell points are done in a different place, so I haven't looked at the disassembly for that yet. But from the distribution I saw, I think it is a straight random but with bonus for high int.
This is how spell points are generated:
Start with 10 spell points. If intelligence is higher than 15, add
(intelligence - 15). Then roll a random 7-sided die and add.

So for a character with 18 intelligence it would be:
10 + 3 + rnd(0,7)

This is from the PC version.
Maven
Posts: 138
Joined: Sat Apr 16, 2011 9:39 pm

Post by Maven »

Thank you, Drifting.

And welcome to the forum.

Although newly rolled characters can have max Int of 17, if they are Gnomes, right?
drifting
Posts: 153
Joined: Wed Dec 07, 2011 10:21 pm

Post by drifting »

Maven wrote:Thank you, Drifting.

And welcome to the forum.

Although newly rolled characters can have max Int of 17, if they are Gnomes, right?
Thanks. I've been working on the disassembly for I, II and III for a few months now. Never thought that anybody else would be doing the same.

Gnomes can have a max of 17. The table and code in your previous post is spot-on.
Maven
Posts: 138
Joined: Sat Apr 16, 2011 9:39 pm

Post by Maven »

I haven't been able to work on this much lately, except that I did confirm that I was wrong about the hit points being straight random. It also rolls two 15-sided dice, drops the lower of the two, and adds 14.
Caracas
Posts: 89
Joined: Thu Jan 20, 2011 9:16 am
Location: Belgium

Post by Caracas »

Are you sure about the hit points?
No difference between classes or races?
It would mean a starting HP range of 15-29, are you sure 15 is indeed the lowest? I thought I have seen lower then 15, but not sure.
User avatar
ZeroZero
Posts: 286
Joined: Tue Mar 10, 2009 9:10 pm
Location: Germany

Post by ZeroZero »

The starting amount of HP is significantly different for every OS version.
Maven
Posts: 138
Joined: Sat Apr 16, 2011 9:39 pm

Post by Maven »

Well, I rolled a thousand Human Magicians, and ran the distribution on Hit Points. Here's what I got.

Code: Select all

15    6
16   21
17   25
18   32
19   39
20   54
21   60
22   64
23   72
24   86
25   77
26   92
27   89
28  140
29  143
Which matches what I saw when I looked at the disassembled machine code.

There wasn't any significant difference when I ran Hobbit Rogues. I don't think there are any race or class differences. Not even for high Constitution.

The chances of even seeing a 15 are less that one percent. I think ZeroZero is right, though--if you were using a different platform you could see something different.
Post Reply