We just moved to a different server. Please be patient until all files and pages are restored and the MediaWiki software has been updated. Thank you

Indiana Jones in Revenge of the Ancients

From REWiki
Jump to: navigation, search

Indiana Jones in Revenge of the Ancients (DOS)

Developer: Angelsoft
Publisher: Mindscape

Files:

 Size  Filename   Function
69888  GAME.000   Game logic?
25983  GAME.COM   Intialisation, keyboard, screen code?
48128  MESSAGE    Game text
  573  START.BAT  Starting batch file, prints general game info.
 4280  TABLES     ?
 6136  VOCAB      Keywords? Common text substitution table?


Main Executable Info

Main GAME.COM executable file has "Borland v2" written in clear-text in the binary, indicating that may have been used as the linker. A couple of the strings are preceded by a byte, which is the length. This means they are Pascal strings. It doesn't guarantee that the code was written in Pascal, but it's worth keeping in mind when looking closer at the executable.

Data Format of MESSAGE file

The text in the MESSAGE file was compressed by packing 8 ASCII characters into 6 bytes by only using a character set of 0 to 63. This 0-63 is then used as an offset into a string array to select the printable character.

It is split into 512 byte sectors with a two byte header at the start. Each sector therefore contains 510 / 6 = 85 character sequences.

There appears to be a concept of message number. The first text displayed on the screen is message 0x1002.

This somehow gets translated into an offset into the MESSAGE file of 0x606e (there is the * 6 calculation in here plus some offset). This offset 0x606e is the start of the message text.

The first 6 hex bytes at this location are : 2e b7 43 08 32 e6.

These decode into the 8 bytes of 0x0b, 0x2b, 0x1d, 0x03, 0x02, 0x03, 0x0b, 0x26

The first two decoded bytes are the length of the message. In this case, it is 0x0b * 64 + 0x2b = 0x02be.

The next chars are then extracted up to the message length.

But, there appears to be special character sequences which get encoded in the message text.

These character sequences start with :

^
|
*
(
+
$
&
%
=
\

Looking at * which is character 3 in the decoded sequence (0x1d offset into decode string is '*'), the code starts to get complicated. It uses the next parameters in the decoded sequence to index into the VOCAB file.

A theory on the message file is that it also contains the location logic as well.

It was indicated above that 0x1002 was a message number. Perhaps it is a location number and all the extra control sequence gubbins is to do with the location logic. In the previous example, the first text you see on screen about the whining bullets appears quite a way into the complete message structure so the bits at the start must be something to do with the location. The initial '*' which then references the VOCAB table is perhaps the move logic, for example. It might be saying that if the user types NORTH (by cross referencing a token in the message structure to the VOCAB file), then change to location XYZ. The objects may be in there as well.

The following BBC Micro BASIC listing iterates through the MESSAGE file and prints out the vast majority of the text descriptions, interspersed with the various other embedded information discussed above.

  10 DIM B(6)
  20 D$="apetixmbqfujyncrgvkzodshwl ^|*($%@#.,-?';'!:&=+\@@@@0123456789@@"
  30 X=OPENIN"MESSAGE."
  40 FORS=0 TO 512
  50   PTR#X=S * 512 +2
  60   FORI=1 TO 85
  70     FORA=1TO6
  80       B(A)=BGET#X
  90     NEXT
 100     FORA=1 TO 8
 110       IF A = 1 THEN C = B(1) DIV 4
 120       IF A = 2 THEN C = (B(1) AND 3) * 16 + (B(2) DIV 16)
 130       IF A = 3 THEN C = (B(2) AND 15) * 4 + (B(3) DIV 64)
 140       IF A = 4 THEN C = B(3) AND 63
 150       IF A = 5 THEN C = B(4) DIV 4
 160       IF A = 6 THEN C = (B(4) AND 3) * 16 + (B(5) DIV 16)
 170       IF A = 7 THEN C = (B(5) AND 15) * 4 + (B(6) DIV 64)
 180       IF A = 8 THEN C = B(6) AND 63
 190       PRINTMID$(D$, C + 1, 1);
 200     NEXT
 210   NEXT
 220   PRINT
 230 NEXT

This initial data-file interpretation was contributed by Jon Welch.

Personal tools