Westbury Mystery
Moderator: Alastair
Re: Westbury Mystery
Sorry for the weird post above, but whenever I tried to edit the post after uploading the attachments, they would mysteriously disappear!
The first image was from the unQuill output.
Looks like Westbury might have been built with the C64 Illustrator package -- albeit without any actual illustrations -- for the sake of Illustrator's RAMsave feature..?
I wonder whether unQuill fully understands C64 Illustrator games?
The first image was from the unQuill output.
Looks like Westbury might have been built with the C64 Illustrator package -- albeit without any actual illustrations -- for the sake of Illustrator's RAMsave feature..?
I wonder whether unQuill fully understands C64 Illustrator games?
Re: Westbury Mystery
Good catch! The A06 version of The Quill and the Adventure Writer does not propose in their system messages to save to ram; message 32 is "Disc or tape?
Unquill doesn't seem to have a problem with The Illustrator; I've already decompiled several games with graphics and it seems to work.
Unquill doesn't seem to have a problem with The Illustrator; I've already decompiled several games with graphics and it seems to work.
Re: Westbury Mystery
Are you in contact with the author of Unquill? Do you think it might be worth letting him know about this problem?
Re: Westbury Mystery
I had contacted John Elliott about this.
It is Dorothy Millard who must have the solution to the problem. I had contacted her for Lands of the Giants, through a private message on CASA, and she responded on the Forum. For Westbury Mystery, I contacted her by email and she didn't reply. I'm not going to ask her again, because I don't want to bother her with this.
Re: Westbury Mystery
Yes, I had already seen that post by you. I'm suggesting that the "problem" that "remains in the decompilation of the code" might be due to some sort of flaw in the code which is doing that decompilation: i.e. Unquill. Maybe there's another bug in Unquill that John Elliott needs to find and fix..? Or maybe not. Only he can tell! Does John already know about this latest problem (the apparent "data-corruption" in the decompiled game)?
Why? Dorothy wrote the game using Quill and Illustrator. The game works and can be completed with a 100% score. It doesn't seem as if Dorothy did anything unusual when she created the game... On the other hand, I'm not very familiar with the C64, so I could be wrong.
Do you think there is something different about the way Westbury was created? Do you think Dorothy used some other patch in addition to Illustrator..?
Re: Westbury Mystery
He fixed UnQuill for this game so I guess so.
She could tell us if there is something between TWIS * and JUMP * that is missing.ahope1 wrote: ↑Wed Nov 25, 2020 10:05 amWhy? Dorothy wrote the game using Quill and Illustrator. The game works and can be completed with a 100% score. It doesn't seem as if Dorothy did anything unusual when she created the game... On the other hand, I'm not very familiar with the C64, so I could be wrong.
Re: Westbury Mystery
Are you using the extracted database for a particular purpose? Are you porting the game to another format?
The missing section is highly likely just to have an initial JUMP entry, that should be fairly easy to guess at and recreate from playing the game. It certainly won't be a TWIS entry, as the existing TWIS entry will catch all inputs.
The missing section is highly likely just to have an initial JUMP entry, that should be fairly easy to guess at and recreate from playing the game. It certainly won't be a TWIS entry, as the existing TWIS entry will catch all inputs.
Re: Westbury Mystery
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")):
Now look at the second section from the same post:
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...
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??
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
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...
Last edited by ahope1 on Thu Nov 26, 2020 12:45 am, edited 2 times in total.
Re: Westbury Mystery
Nice work.
Re: Westbury Mystery
Good catch! It's all the fun of these old games. Debugging, understanding, fumbling around in the source code etc.; it's another way to play.
This is what John Elliott told me:ahope1 wrote: ↑Wed Nov 25, 2020 11:48 pmSo, 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
The problem seems to be a corrupt entry in the Response table -- there should be a 0xFF byte after the DONE to indicate the end of the entry, but it seems to have gone missing. So UnQuill tries to interpret the bytes that follow as actions, even though they're out of range, and reads off the end of its arrays.
Check it out with him, I'm unable to explain this to him in proper English. It took him a little while to answer me, but he did. Don't despair... Unless you fix UnQuill yourself; you seem to be on the right track for that.
Re: Westbury Mystery
So my guess was more or less correct, then:auraes wrote: ↑Thu Nov 26, 2020 6:27 amThis is what John Elliott told me:The problem seems to be a corrupt entry in the Response table -- there should be a 0xFF byte after the DONE to indicate the end of the entry, but it seems to have gone missing. So UnQuill tries to interpret the bytes that follow as actions, even though they're out of range, and reads off the end of its arrays.
ahope1 wrote: ↑Wed Nov 25, 2020 11:48 pmEDIT: 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...
The only problem is I'm no good at actually programming in C!
Yes, and in the case of Westbury I'm afraid it might be the most fun way..!?