Westbury Mystery

Games for Spectrum, C64, Amstrad, Amiga, Apple ][ and the rest of the 8-bit and 16-bit platforms. Pleas for help, puzzles, bug reports etc.

Moderator: Alastair

Message
Author
ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#16 Post by ahope1 » Mon Nov 23, 2020 10:56 pm

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?

User avatar
auraes
Posts: 81
Joined: Sun Jul 12, 2015 6:13 am

Re: Westbury Mystery

#17 Post by auraes » Tue Nov 24, 2020 6:58 am

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.

ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#18 Post by ahope1 » Tue Nov 24, 2020 8:35 pm

auraes wrote:
Tue Nov 24, 2020 6:58 am
Unquill doesn't seem to have a problem with The Illustrator; I've already decompiled several games with graphics and it seems to work.
Are you in contact with the author of Unquill? Do you think it might be worth letting him know about this problem?

User avatar
auraes
Posts: 81
Joined: Sun Jul 12, 2015 6:13 am

Re: Westbury Mystery

#19 Post by auraes » Wed Nov 25, 2020 6:56 am

ahope1 wrote:
Tue Nov 24, 2020 8:35 pm
Are you in contact with the author of Unquill? Do you think it might be worth letting him know about this problem?
I had contacted John Elliott about this.
auraes wrote:
Mon Nov 23, 2020 9:06 am
John Elliott modified UnQuill because the code in Westbury Mystery made it crash. That's no longer the case, but the problem remains in the decompilation of the code.
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.

ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#20 Post by ahope1 » Wed Nov 25, 2020 10:05 am

auraes wrote:
Wed Nov 25, 2020 6:56 am
I had contacted John Elliott about this.
auraes wrote:
Mon Nov 23, 2020 9:06 am
John Elliott modified UnQuill because the code in Westbury Mystery made it crash. That's no longer the case, but the problem remains in the decompilation of the code.
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)?

auraes wrote:
Wed Nov 25, 2020 6:56 am
It is Dorothy Millard who must have the solution to the problem.
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..?

User avatar
auraes
Posts: 81
Joined: Sun Jul 12, 2015 6:13 am

Re: Westbury Mystery

#21 Post by auraes » Wed Nov 25, 2020 11:23 am

ahope1 wrote:
Wed Nov 25, 2020 10:05 am
Does John already know about this latest problem (the apparent "data-corruption" in the decompiled game)?
He fixed UnQuill for this game so I guess so.
ahope1 wrote:
Wed Nov 25, 2020 10:05 am
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.
She could tell us if there is something between TWIS * and JUMP * that is missing.

User avatar
Strident
Posts: 351
Joined: Fri Aug 12, 2011 2:57 pm

Re: Westbury Mystery

#22 Post by Strident » Wed Nov 25, 2020 11:42 am

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.

User avatar
auraes
Posts: 81
Joined: Sun Jul 12, 2015 6:13 am

Re: Westbury Mystery

#23 Post by auraes » Wed Nov 25, 2020 1:18 pm

Strident wrote:
Wed Nov 25, 2020 11:42 am
Are you using the extracted database for a particular purpose? Are you porting the game to another format?
I adapted it for zQuill and I would try to translate it, but I won't publish it without the author's permission.

ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#24 Post by ahope1 » Wed Nov 25, 2020 11:48 pm

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...
Last edited by ahope1 on Thu Nov 26, 2020 12:45 am, edited 2 times in total.

User avatar
Garry
Posts: 197
Joined: Sun Oct 28, 2012 11:43 am
Location: Sydney, Australia

Re: Westbury Mystery

#25 Post by Garry » Thu Nov 26, 2020 12:27 am

Nice work.

ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#26 Post by ahope1 » Thu Nov 26, 2020 12:44 am

Garry wrote:
Thu Nov 26, 2020 12:27 am
Nice work.
Ta!

:thumb:

User avatar
auraes
Posts: 81
Joined: Sun Jul 12, 2015 6:13 am

Re: Westbury Mystery

#27 Post by auraes » Thu Nov 26, 2020 6:27 am

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.
ahope1 wrote:
Wed Nov 25, 2020 11:48 pm
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
This 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: No idea what caused Unquill to glitch at this particular point in the data. That's up to John to find out!
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.

ahope1
Posts: 68
Joined: Sun Mar 18, 2012 7:33 pm

Re: Westbury Mystery

#28 Post by ahope1 » Thu Nov 26, 2020 12:11 pm

auraes wrote:
Thu Nov 26, 2020 6:27 am
This 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.
So my guess was more or less correct, then:
ahope1 wrote:
Wed Nov 25, 2020 11:48 pm
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...

auraes wrote:
Thu Nov 26, 2020 6:27 am
Unless you fix UnQuill yourself; you seem to be on the right track for that.
The only problem is I'm no good at actually programming in C!

auraes wrote:
Thu Nov 26, 2020 6:27 am
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.
Yes, and in the case of Westbury I'm afraid it might be the most fun way..!?

:?

Post Reply