The uncompressed file has a size of about 220kB. So if it is that size, then yes it is uncompressed.
To decipher the map file in mem dump you do not need to know assembler. The map merely contains a list of coordinates that have certain meanings, and a couple of texts (like mouths in the wall etc)
However in the C64 version the SPECIAL events in fact were small code snippets in assembler that were loaded from files, this will definitely be different in the DOS version.
The game texts are undecoded in bards.exe, maybe the events are in there. Maybe they are in the bigpic file.
Maybe at least the routine that loads and decodes files should be identified to get the decoding algorithm.
msdos dissasembly
28 bytes after the Harkyn's Castle lvl 3 map, the following begins:
070809FFFFFFFFFF00FF00FFFFFFFFFF
040001000003A0C3E1F3F4ECE5A0A0DC
050C01150503FFFFFFFFFFFFFFFFFFFF
1FFF20FF21FFFFFFFFFFFFFFFFFFFFFF
010EFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
0406150A06001409130A140BFFFFFFFF
00000C14140A100010001000FFFFFFFF
02130214011201130114001200130014
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
050B0203FFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
20FD4AFD20FD20FD20FD20FD20FD20FD
C1A0F3E9E7EEA0EFEEA0F4E8E5A0F7E1
ECECA0F2E5E1E4F3ACA0A2D4E8E5A0C2
E1F2F2E1E3EBF3AEA2DCD7F2E9F4F4E5
EEA0EFEEA0F4E8E5A0F7E1ECECA0E9EE
A0E2ECEFEFE4A0E9F3BA0000D4E8E5A0
C3F2F9F3F4E1ECA0D3F7EFF2E4A0F7E9
ECECA0ECE5E1F6E5A0F4E8E5A0E3F2F9
F3F4E1ECA0E7F5E1F2E4E9E1EEA0E9EE
A0EDE1EEF9A0F0E9E5E3E5F3AEDC3738
332C32353500DD0D9001B93738342C32
30333AB93738352C37363AB93738362C
3234383AB93738372C31393800FA0DA4
018C3736383AB220494E4954204F4D4E
494E4554204341524400150EAE01B220
4E4F57204C4F41442052454144204452
49564552
Since the the rest was identical to the C64 version, one can assume this is an overview of the events.
The last 44 bytes of this serie reads in a hex editor: INIT OMNINET CARD NOW LOAD READ DRIVER
Just checked with the C64 version and the events are indeed the same. For example:
at address 442 (039c:19710 in my memory dump) it reads: 010EFFFFFFFFFFF...; 01 0E (1 north, 14 east) is the location of the only anti magic zone in Harkyn lvl 3.
070809FFFFFFFFFF00FF00FFFFFFFFFF
040001000003A0C3E1F3F4ECE5A0A0DC
050C01150503FFFFFFFFFFFFFFFFFFFF
1FFF20FF21FFFFFFFFFFFFFFFFFFFFFF
010EFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
0406150A06001409130A140BFFFFFFFF
00000C14140A100010001000FFFFFFFF
02130214011201130114001200130014
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
050B0203FFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
20FD4AFD20FD20FD20FD20FD20FD20FD
C1A0F3E9E7EEA0EFEEA0F4E8E5A0F7E1
ECECA0F2E5E1E4F3ACA0A2D4E8E5A0C2
E1F2F2E1E3EBF3AEA2DCD7F2E9F4F4E5
EEA0EFEEA0F4E8E5A0F7E1ECECA0E9EE
A0E2ECEFEFE4A0E9F3BA0000D4E8E5A0
C3F2F9F3F4E1ECA0D3F7EFF2E4A0F7E9
ECECA0ECE5E1F6E5A0F4E8E5A0E3F2F9
F3F4E1ECA0E7F5E1F2E4E9E1EEA0E9EE
A0EDE1EEF9A0F0E9E5E3E5F3AEDC3738
332C32353500DD0D9001B93738342C32
30333AB93738352C37363AB93738362C
3234383AB93738372C31393800FA0DA4
018C3736383AB220494E4954204F4D4E
494E4554204341524400150EAE01B220
4E4F57204C4F41442052454144204452
49564552
Since the the rest was identical to the C64 version, one can assume this is an overview of the events.
The last 44 bytes of this serie reads in a hex editor: INIT OMNINET CARD NOW LOAD READ DRIVER
Just checked with the C64 version and the events are indeed the same. For example:
at address 442 (039c:19710 in my memory dump) it reads: 010EFFFFFFFFFFF...; 01 0E (1 north, 14 east) is the location of the only anti magic zone in Harkyn lvl 3.
First little success! 
I managed to unpack bard.exe. I can't run the unpacked executable. I'm getting an overlay error.
However, I am able to modify the unpacked bard.exe and then recompile it. The recompiled bard.exe works fine.
I can now buy Pizza for 5 gold at Garth's
I can't find any map in bard.exe, so I'm guessing that info is in the BIGPIC file (for the city map) and the LEVS file (for the dungeons).
@Maven (if he still reads this): I saw you mentioning somewhere you found the Huffman encoding tree... you still have that somewhere around?
I managed to unpack bard.exe. I can't run the unpacked executable. I'm getting an overlay error.
However, I am able to modify the unpacked bard.exe and then recompile it. The recompiled bard.exe works fine.
I can now buy Pizza for 5 gold at Garth's
I can't find any map in bard.exe, so I'm guessing that info is in the BIGPIC file (for the city map) and the LEVS file (for the dungeons).
@Maven (if he still reads this): I saw you mentioning somewhere you found the Huffman encoding tree... you still have that somewhere around?
Ok, so you see the map file format is completely the same as it seems. The text you encountered has nothing to do with the map file, I dunno how the text pointers in the DOS versions are given. Where there are meant to be text pointers, you probably find a pointer to a mem location at that the proper text (e.g. for a wall inscription) is.
Also, the texts might be encoded in the BT style (see the regarding sections in my C64 threat for that).
To be able to decode and encode the BT DOS files were handy to create a level editor, but not more.
I made one for the C64 version (well, decoder and limited encoder), and Darendor made new levels for the C64 versions with the information I collected with the help of others.
The first line
070809FFFFFFFFFF00FF00FFFFFFFFFF
means:
To the harkyns castle belong the levels 07 08 and 09. Five more bytes could give 5 more levels.
Next three bytes mean:
Levels 07 and 09 allow teleport, level 08 doesn't. Five more bytes for possible more 5 levels.
Second line means
040001000003A0C3E1F3F4ECE5A0A0DC
Random encounter monsters are of level 04, i.e. all monsters of that level can randomly occur.
00 = PHDO is enabled
01 = style of wall textures (in C64 it were cellar style)
00, 00 point of return into Skara Brae, of course u can't return from level 09
03 = level is a tower, i.e. diretion is UP for next and DOWN for previous level stairs. If that byte were 00 it were a cellar and next were DOWN while previous were UP
The rest of line indeed is a BT encoded text, the dungeon name, and reads
"Castle"
Line 3
050C01150503FFFFFFFFFFFFFFFFFFFF
8 coordinates for special events
N 5 E 12: in C64 version this will load file NM2D, which is the berzerker event
N 1 E 21 will load in C64 the file NM2E, the event with the Mad God statue
N 5 E 3 file NM2F, skull tavern riddle
5 coors are unused
etc etc etc, it seems to be pretty same, except that you likely won't find event files to be loaded but rather function pointers to be called for events and the text offsets will be slightly different.
Also, the texts might be encoded in the BT style (see the regarding sections in my C64 threat for that).
To be able to decode and encode the BT DOS files were handy to create a level editor, but not more.
I made one for the C64 version (well, decoder and limited encoder), and Darendor made new levels for the C64 versions with the information I collected with the help of others.
The first line
070809FFFFFFFFFF00FF00FFFFFFFFFF
means:
To the harkyns castle belong the levels 07 08 and 09. Five more bytes could give 5 more levels.
Next three bytes mean:
Levels 07 and 09 allow teleport, level 08 doesn't. Five more bytes for possible more 5 levels.
Second line means
040001000003A0C3E1F3F4ECE5A0A0DC
Random encounter monsters are of level 04, i.e. all monsters of that level can randomly occur.
00 = PHDO is enabled
01 = style of wall textures (in C64 it were cellar style)
00, 00 point of return into Skara Brae, of course u can't return from level 09
03 = level is a tower, i.e. diretion is UP for next and DOWN for previous level stairs. If that byte were 00 it were a cellar and next were DOWN while previous were UP
The rest of line indeed is a BT encoded text, the dungeon name, and reads
"Castle"
Line 3
050C01150503FFFFFFFFFFFFFFFFFFFF
8 coordinates for special events
N 5 E 12: in C64 version this will load file NM2D, which is the berzerker event
N 1 E 21 will load in C64 the file NM2E, the event with the Mad God statue
N 5 E 3 file NM2F, skull tavern riddle
5 coors are unused
etc etc etc, it seems to be pretty same, except that you likely won't find event files to be loaded but rather function pointers to be called for events and the text offsets will be slightly different.
Well, I'm a bit stuck atm...
I'm able to do some minor cosmetic changes, but that's about it.
I'm unable to decode the Huffman encoded files (BIGPIC, LEVS,...) so I can't read/modify the actual maps.
It will most likely be impossible to derive the source c-code from the extracted BARD.EXE.
on a side note: In the extracted BARD.EXE there is
Pa Troy P. Worrell LO 9876 1234 1234
Ma BRIAN THE FIST LO 9999
Ba EL CID -9 96
Ro MARKUS -3 83
So SIR GRADY 2 64
Wi MERLIN -1 96
Ma OMAR 0 62
Seems like the coder had some fun
I'm able to do some minor cosmetic changes, but that's about it.
I'm unable to decode the Huffman encoded files (BIGPIC, LEVS,...) so I can't read/modify the actual maps.
It will most likely be impossible to derive the source c-code from the extracted BARD.EXE.
on a side note: In the extracted BARD.EXE there is
Pa Troy P. Worrell LO 9876 1234 1234
Ma BRIAN THE FIST LO 9999
Ba EL CID -9 96
Ro MARKUS -3 83
So SIR GRADY 2 64
Wi MERLIN -1 96
Ma OMAR 0 62
Seems like the coder had some fun
Well what I see in the file "levs" is, that it starts with a table of 16 offsets into itself at that most likely the encoded level data is.
All 16 addresses point to chunks of different size, which indicates that the level data is somehow compressed.
Each level starts with the fixed byte series "00 00 08 00 00 00".
From that quick look I can't identify any common compressing algorithm.
All 16 addresses point to chunks of different size, which indicates that the level data is somehow compressed.
Each level starts with the fixed byte series "00 00 08 00 00 00".
From that quick look I can't identify any common compressing algorithm.
So, the LEVS file starts with the following:
00 00 00 40 00 00 05 AE
00 00 0B CE 00 00 11 DF
00 00 18 06 00 00 1D EE
00 00 24 02 00 00 2A 2B
00 00 30 2D 00 00 36 2B
00 00 3C 20 00 00 42 3A
00 00 48 90 00 00 4E C2
00 00 55 11 00 00 5A D1
Which is probably info about the encoding being used. Followed by the first serie of:
00 00 08 00 00 00
followed by $568 bytes of data (probably the first dungeon - sewers?)
followed again by 00 00 08 00 00 00 and so on...
I checked my memory dump of the sewer, it contains $6B4 bytes of data. If the first set of data in the LEVS file is the sewers, the encoding reduced the size from $6B4 to $568 bytes of data.
EDIT: i just randomly modified the LEVS file. I changed $48 from 01 to 2B. This changed my sewers drasticaly... darkness and traps all over
00 00 00 40 00 00 05 AE
00 00 0B CE 00 00 11 DF
00 00 18 06 00 00 1D EE
00 00 24 02 00 00 2A 2B
00 00 30 2D 00 00 36 2B
00 00 3C 20 00 00 42 3A
00 00 48 90 00 00 4E C2
00 00 55 11 00 00 5A D1
Which is probably info about the encoding being used. Followed by the first serie of:
00 00 08 00 00 00
followed by $568 bytes of data (probably the first dungeon - sewers?)
followed again by 00 00 08 00 00 00 and so on...
I checked my memory dump of the sewer, it contains $6B4 bytes of data. If the first set of data in the LEVS file is the sewers, the encoding reduced the size from $6B4 to $568 bytes of data.
EDIT: i just randomly modified the LEVS file. I changed $48 from 01 to 2B. This changed my sewers drasticaly... darkness and traps all over
Since I found the term "ZIP" in uncompressed bard.exe I tried to unzip a chunk of data, with no success.
So it is not the standard deflate algorithm.
I do not have a debugger for dosbox, else I could try to disassemble the
subroutine that loads the "levs" file and analyze the decompression
algorithm used.
So it is not the standard deflate algorithm.
I do not have a debugger for dosbox, else I could try to disassemble the
subroutine that loads the "levs" file and analyze the decompression
algorithm used.
I'm using this:
http://vogons.zetafleet.com/viewtopic.php?t=7323
http://vogons.zetafleet.com/viewtopic.php?t=7323
Some remarks:
the text "INIT OMNINET CARD NOW LOAD READ DRIVER" also is in the
C64 and afaik in the original Apple II version... It simply seems to be a
leftover of unused mem space when the original coder Burger saved the
mem dump of the level to a file. It has simply been copied from version
to version....
the level map texts are in fact in the level itself, right after the text offset
pointers, and they are still BT "encoded", which in my information was
one of Apple II's character encodings, iow: on an Apple II version you can
read the texts directly, while all other versions have to translate the texts
to other character tables.
I installed the debug version of Dosbox, however I do not find the
debugger neither handy nor comfortable. But it shows when it accesses
a file. I wished it showed, from what mem address the file is accessed.
I do not think, that all files are encoded with the same Hufmann algorithm.
The filename "BIGPIC" suggests, that it probably is one of the first files
that is encoded with EA's ".big" file format, but I didn't check yet.
I was unable to find the routine yet that opens the "LEVS" file, but after
loading a chunk of that file, representing one level map, it should call the
decompressing routine.
It can be, that the dictionairy/tree for all files that are compressed may be
at a central place in code (to save file size), maybe in the bard.exe.
But the decompress routine disassembly will show details.
the text "INIT OMNINET CARD NOW LOAD READ DRIVER" also is in the
C64 and afaik in the original Apple II version... It simply seems to be a
leftover of unused mem space when the original coder Burger saved the
mem dump of the level to a file. It has simply been copied from version
to version....
the level map texts are in fact in the level itself, right after the text offset
pointers, and they are still BT "encoded", which in my information was
one of Apple II's character encodings, iow: on an Apple II version you can
read the texts directly, while all other versions have to translate the texts
to other character tables.
I installed the debug version of Dosbox, however I do not find the
debugger neither handy nor comfortable. But it shows when it accesses
a file. I wished it showed, from what mem address the file is accessed.
I do not think, that all files are encoded with the same Hufmann algorithm.
The filename "BIGPIC" suggests, that it probably is one of the first files
that is encoded with EA's ".big" file format, but I didn't check yet.
I was unable to find the routine yet that opens the "LEVS" file, but after
loading a chunk of that file, representing one level map, it should call the
decompressing routine.
It can be, that the dictionairy/tree for all files that are compressed may be
at a central place in code (to save file size), maybe in the bard.exe.
But the decompress routine disassembly will show details.
When entering a dungeon it calls for bard.exe and the LEVS file.
In the decompressed bard.exe, I can find all the texts for all the dungeons, so it certainly requires that. The decoding information for the LEVS file is probably also in the bard.exe file.
I haven't checked the BIGPIC file yet.
A first search on the www reveals a few tools to open .big files, haven't tried it yet, though
In the decompressed bard.exe, I can find all the texts for all the dungeons, so it certainly requires that. The decoding information for the LEVS file is probably also in the bard.exe file.
I haven't checked the BIGPIC file yet.
A first search on the www reveals a few tools to open .big files, haven't tried it yet, though
The BIGPIC file is the graphics library, it seems. Whenever a new picture
is shown on the screen, that file is accessed 3 times by the engine.
In the C64 version all special events within city or dungeon where small
overlay files in assembler that were loaded from disk. In the DOS version,
as I suspected earlier in this threat, it seems that all events are included
in the main program and the "event load" table that I explained in my
C64 threat will likely only give an offset into a jump table to call the proper
event routine.
is shown on the screen, that file is accessed 3 times by the engine.
In the C64 version all special events within city or dungeon where small
overlay files in assembler that were loaded from disk. In the DOS version,
as I suspected earlier in this threat, it seems that all events are included
in the main program and the "event load" table that I explained in my
C64 threat will likely only give an offset into a jump table to call the proper
event routine.