Re: Wizardry IV bootstrap bug in SYSTEM.INTERP

On Saturday, October 11, 2014 4:42:46 PM UTC-5, qkumba wrote:
Hi Tommy,

The full list looks like this (TT=track, PS=Pascal Sector, DS=DOS Sector):



TT PS   DS

0A 09 06

0A 0B 04

0A 0D 02

0A 0F 0f

0B 00 00

0B 02 0d

0B 04 0b

0B 06 09

0B 08 07

0B 0A 05

0B 0C 03

0B 0E 01

0B 01 0e

0B 03 0c

0B 05 0a

0B 07 08

0B 09 06



The DOS Sector is based on your translation table.  However, the first 
physical sector that is read (taken from a dsk image) is T $10 S 03.  It 
starts "04 C6 06 00 C7".  It is the only occurrence on the disk.

The algorithm appears to be this:

track = block number / 8;

tmp = (block number & 7) * 2;

carry = 0;

if (tmp >= 8) carry = 1; tmp = tmp - 8;

sector = (tmp * 2) + carry;

Hi qkumba,

One of us (or both of us) are terribly confused.

"The full list looks like this (TT=track, PS=Pascal Sector, DS=DOS Sector):"
 "...first physical sector that is read (taken from a dsk image) is T $10 S 03".

Your list does not include any TT=$10.  I'm not sure what you are trying to say 
here.

Here is an important question to ask:

How do you know that you are tracing the loading of the segment KANJIREA and 
not the segment COMBAT?

Hopefully we are both using the same disk image (or an identical one) from 
ASIMOV as a starting point, otherwise all this might be moot.

The Segment Dictionary for SYSTEM.PASCAL has this entry for COMBAT:

  10 00 E0 03

The start of SYSTEM.PASCAL is $46, and the relative start for COMBAT is $10.  
$46 + $10 = $56.

Is this where your $56 is coming from?

I will describe the "in memory" segment table after PASCAL.SYSTEM is loaded in 
a minute, but first we need to examine the second sector of the PASCAL.SYSTEM 
Segment Dictionary:

01 42 07 42 08 42 09 42
0A 42 0B 42 0C 42 0D 42
0E 42 0F 42 10 42 11 42
12 42 13 42 00 00 00 00

These are word entries and each word corresponds to the compiler assigned 
segment number.  The first segment, WIZARDRY, is assigned segment 1; the next 
segment, COMBAT, is assigned segment 7; the next one is assigned segment 8.

The segment KANJIREA is assigned segment $0C.

Part of the segment load table in memory starts at $C19 and after PASCAL.SYSTEM 
Dictionary Segment is loaded it looks like this:

$C19:  0E 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 00 00 00 00 
....

$C3A: 47 56 58 66 70 77 85....
$C4A: 00 00 00 00 00 00 00....
$C5A: 66 E0 3A FC E6 DE 4E....
$C6A: 1C 03 1B 13 0C 1A 10....

The table at $C19 is a translation table from the compiler / linker assigned 
number to the entries in the $C3A, $C4A, $C5A, and $C6A tables.  The way to 
read these tables is in vertical columns (e.g., 47, 00, 66, 1C, then 56, 00, 
E0, 03).  Recall that runtime segment numbers 0, and 2-6 are reserved, so a 
program occupies segments 1, 7, 8, 9, etc..

Segment 1 translates to:  Entry 00 in tables $C3A, etc.
Segment 7 translates to:  Entry 01
Segment 8 translates to:  Entry 02
Segment 9 translates to:  Entry 03

Segment 0C translates to: Entry 06

Those values in the table at $C19 are indexes into the $C3A, $C4A, $C5A, and 
$C6A tables.

For runtime Segment 1, the value at $C19,1 is $00, so that is used as an index 
into $C3A, $C4A, etc.

$C3A and $C4A are the Pascal block address for the segment, and $C5A, $C6A are 
the length (in bytes).  So we see that for runtime segment 1, has Block $0047, 
and length $1C66.

Now let's look at the next segment in the Segment Dictionary, which is COMBAT.  
It was assigned segment 7 by the compiler.  $C19,7 has the value 01.  The 
entries in $C3A etc., say this segment is at block $56 and has length $3E0.

Once again, it looks to me like COMBAT and not KANJIREA is the segment that 
occupies Pascal block $56 on the disk.

Also, your conversion algorithm for Pascal Blocks to Tracks / Sectors is the 
same as I posted earlier.  

For example, "track=block number / 8" is the same as looking at the block 
number in binary and looking at just the top 5 bits (00000 000).
$56 = 01010110 = 01010 110.  The 01010 is $A which is the same as INT($56 / 8).

And Antoine, never disagree with a mad man.  You will never win.  Solving 
software problems by voting is not an option. :)

At this time I will continue my disassembling of the Pascal runtime system for 
Wizardry IV and then start working on Segment 0 (WIZARDRY).  This discrepancy 
will be solved at some point.

Tommy