Special events in Level 13 are a little flawed

Discussions about all other tools (CusPop, SAV/HOF editors) and hex editing.
T0mmiTheGreat
Sheikh
Sheikh
Posts: 25
Joined: February 22nd, 2021, 8:48 pm
Location: Czech Republic

Re: Special events in Level 13 are a little flawed

Post by T0mmiTheGreat »

David wrote: August 14th, 2021, 1:05 pm
T0mmiTheGreat wrote: August 9th, 2021, 10:26 pm *When talking about segment addresses, I guess we mean "within the relocation table"…?
What do you mean?
I wanted to highlight that "segment address" doesn't mean "segment's offset within the .EXE", although they are both expressed as a hex number. Took me a minute to realize. Though, judging by your confusion my guess was a little off the mark :).
I would edit that note. Unfortunately, I'm not allowed to do changes in the post anymore.
David wrote: August 14th, 2021, 1:05 pm They represent the segments of the call instruction.

Two things from my previous post are relevant here:
1. The same linear address can be represented by multiple different segment-offset pairs.
For very simple example, 0001:0000 and 0000:0010 both point to linear address 0x0010.

2. The PRINCE.EXE which comes with Apoplexy is unpacked for easier editing, but PRINCE.EXE was distributed in packed (compressed) form.
Before Broderbund packed their PRINCE.EXE with EXEPACK, the entry in your example probably was 0532:04C0, or C0 04 32 05.
EXEPACK compresses the relocation table as well, it stores linear addresses in the packed EXE (at the end of the file).
When UPACKEXE decompresses the relocation table, it only knows the linear addresses, 57E0 in your example.
It converts them to segment-offset addresses in a simple way I described in my previous post: A linear address like 0x12345 becomes 1000:2345.
57E0 becomes 0000:57E0.

If you look at other DOS EXEs (which are not packed or extracted from a packed EXE), you can see non-zero segments in relocation table entries.

T0mmiTheGreat wrote: August 9th, 2021, 10:26 pm Though, in the .EXE file there are addresses that end with 10 (e.g. B2 BC 00 10) starting from 0x13B8 offset. Are they related to procedure calls?
They are for procedure calls with linear addresses above 0xFFFF.
B2 BC 00 10 means 1000:BCB2, i.e. 1000 × 10 + BCB2 = 1BCB2.
I have suspected that those "10's" are for 5-digit offsets, but didn't understand why they aren't "01" instead. Now I do. Neat explanation! :)
David wrote: August 14th, 2021, 1:05 pm You could point it to uninitialized data, i.e. to an address marked with question marks in the disassembly.

But the "proper" way of removing an entry is this:
1. Move all the following entries back by 4 bytes.
That is: delete the bytes of the entry (this makes the file 4 bytes shorter) and then add four zero bytes after the end of the relocation table (before the 0x55 byte which was at 0x18B0).
2. Decrease the relocations count field at offsets 6-7 in the EXE file.
Oh, yes. The "proper" way. I always do things the "proper" way…
*inconspicuously changes the relocation to "30 E1 00 10"*

And finally, (I've already said this many times) huge thanks for your help, David. I must put you in the credits in my mod for "Programming assistance" or something :D .
Post Reply