OMG! The answer has been staring us in the face! There is no "extra data" or "corrupted data" or "unparsed data" or "missing data" or whatever! The apparent corruption has to be due to a bug in Unquill.
Look at the first section of decompiled data that Strident
posted upthread (these actions immediately follow the line that says "
TWIS *" and the next two lines ("
MESSAGE 3" and "
DONE")):
Code: Select all
cd0: ??28??
cd1: INVEN
cd2: ??24?? 6 22
cd5: ANYKEY
cd6: ??29??
cd7: ANYKEY
cd8: ??3b??
Now look at the second section from the same post:
Code: Select all
1d5d: JUMP * Conditions:
cd1: AT 36
cd3: WORN 22
cd5: WORN 41
cd7: WORN 59
Actions:
cda: MESSAGE 94
cdc: ANYKEY
cdd: DROPALL
cde: GET 22
ce0: WEAR 22
ce2: GET 41
ce4: WEAR 41
ce6: GET 59
ce8: WEAR 59
cea: PLUS 30 3
ced: GOTO 68
cef: DESC
Does anything strike you about the column of numbers on the left in both sections..?
Yes: they overlap! In no two other sections do those columns overlap in this way. What's happened is that the condition "AT" at address cd1 in the second section is being read from the
same byte of the savestate file as the bogus "INVEN" action at cd1 in the first section! I've looked at the Unquill source-code and checked: the code for the action INVEN is zero, and so is the code for the condition "AT". The byte that follows the "AT" is given as the decimal value "36" in the second section, which just happens to correspond to the hex value "24" in the first section. Then you've got "WORN 22" corresponding to "6 22", and so on. I've followed it all through -- I've even compared it with the raw binary data in the C64 emulator savestate file, and it all checks out!
So, there's no missing data: it's just that there's some sort of bug in Unquill that caused it to read
too much data when it was parsing the conditions (none) and the actions for "TWIS *": Unquill should have stopped at ccf ("DONE"), but for some reason (a bug) it carried on through to cd8. But then Unquill "found its place" again when it moved on to parsing the conditions and actions for the first "JUMP *" entry: it went back to cd1, which is the "AT 36" line, which is the correct first condition for that "JUMP *" entry.
All the other verb entries seem to have been parsed correctly.
No idea what caused Unquill to glitch at this particular point in the data. That's up to John to find out!
EDIT: Actually, I suspect I might know what caused the glitch: the entry for "TWIS *" seems to end at cd0 with the hex byte "28", whereas a normal list of actions should be terminated by the hex byte "255" (or $FF), I
think. So there could well be a case of corruption of a single byte at cd0, but it makes no difference to the running game: it only affects Unquill, which is expecting to see an FF terminator but doesn't, so it just keeps reading data -- until... it
does see an FF, I guess..?! Not sure...