[File] JSW 2015 Bug Fixed Edition

[IRF]

I wasn't aware of the 'Cell Graphics Bug' until Stuart brought it to my attention.  If you ever do a v.2 of the Bug Fix Edition there are a few other things that we discovered along the way which could be fixed as well (such as a couple of guardians that walk backwards because the Sprite Animation settings are askew,  punctuation and justification of screen titles, etc).

Edited March 4, 2016 by IRF

[Spider]

For Vega users, a special keymap is available for this edition here:

 

http://games.zxvega.co.uk/game/jet-set-willy-2015---bug-fixed-edition

[jetsetdanny]

Andy, in "JSW 2015 Bug Fixed Edition", in the version where the in-game tune does not deteriorate, the original code which picks up the number of lives remaining (to be used by the in-game tune routine):

 

8B51  3A CC 85    LD A,(#85CC) 

 

was substituted with the fixed number #08, corresponding to Willy's having eight lives remaining:

 

8B51  3E 08     LD A,#08

8B53  00          NOP.

 

However, in the original "JSW" that number would be #07 at the start of the game. This difference causes the pitch of the tune in the Bug Fixed Edition to be slightly higher than in the original (at the start).

 

So the question arises whether - if you want the Bug Fix to be faithful to the original - it would not be advisable to change the value at #8B52 to #07?

 

Just a thought  :) , with thanks to Ian for drawing my attention to the discrepancy during his proofreading of the "WNM SE" Readme file :) .

[IRF]

Further to the above, the 'tune pitch deterioration' code calculates (28-4xA), where A is the number of remaining lives, and adds the value to each note of the tune.

You can see that inputting A=7 yields an output of zero, and hence no deterioration in pitch when Willy has 7 remaining lives. As A decreases (with each life lost), the values of the notes played are increased, causing the pitch to drop. (In physical terms, the note values correspond to the time delay between consecutive excitations of the speaker diaphragm, thus larger values in the music data correlate with lower frequency notes.)

Using a value of A=8 actually causes a negative offset to be applied to the tune values, meaning the notes are actually played slightly too sharp (the opposite of deterioration - is there a word for that?)

Andy was right in so far as Willy has to be killed eight times before the game is brought to an end, but at the beginning of each game, there are only seven Dancing Willies on the status bar, not eight.

It probably helps to think of the number of lives remaining as being "the number of lives left after the current one expires".

Incidentally, having looked at the code, I believe that if the initial value of the number of remaining lives at #85CC was set to zero (i.e. no dancing Willies on the status bar), then the classic POKE 35899,0 wouldn't actually work in giving the player infinite lives!

Edited October 24, 2016 by IRF

[IRF]

(In physical terms, the note values correspond to the time delay between consecutive excitations of the speaker diaphragm, thus larger values in the music data correlate with lower frequency notes.)

And that's got me thinking - I don't think Richard Hallas is quite correct in his 'A Miner Triad.' document, when he states that the note #00 is one octave lower than the note #FF.

 

The former note is slightly lower in pitch than the latter, but only by a factor of 256/255. ("An octave below" would suggest a doubling of the delay between consecutive excitations of the speaker. i.e. a halving of frequency.)

 

In the Main Loop, the value of a note is loaded (ultimately*) into the E register, and E is then decremented in a loop until it reaches zero - at which point a XOR #18 command sends a signal to the EAR/MIC ports, the original note value is loaded back into E and then the loop restarts.

 

A value of #00 will decrement to #FF in the first instance - before the check for a zero value takes place - and therefore #00 is the lowest note you can possibly obtain by using a single byte to store a value corresponding to the pitch (which I think, to be fair, was the main thrust of Richard's argument) - but it doesn't cause a delay that is twice as long as the delay caused by using the value #FF.

 

 

[* i.e. after accounting for any tune deterioration due to lost lives]

Edited March 7, 2017 by IRF

[Spider]

I'd have to check but I think I tried a couple of methods of this, and in the end just assigned a value (as above) rather than try to change the DEC instruction. As to why I'm not quite sure. :D :unsure:

[IRF]

I'd have to check but I think I tried a couple of methods of this, and in the end just assigned a value (as above) rather than try to change the DEC instruction. As to why I'm not quite sure. :D :unsure:

 

I suspect you probably thought "Willy starts the game with eight lives", but then you forgot to start counting at Life Number Zero!  So you inserted a value of '08' instead of '07' at the appropriate address.

 

At least, that's my best guess - it's probably academic now, as you issued a version with 'tune deterioration' restored as well. :)

Edited March 7, 2017 by IRF

[Spider]

I suspect you probably thought "Willy starts the game with eight lives", but then you forgot to start counting at Life Number Zero!  So you inserted a value of '08' instead of '07' at the appropriate address.

 

At least, that's my best guess - it's probably academic now, as you issued a version with 'tune degerioration' restored as well. :)

 

:) Quite likely the case.

 

Ah yes some on WOS were not too happy about the 'removal' of this as its technically not a bug I guess.

[IRF]

And that's got me thinking - I don't think Richard Hallas is quite correct in his 'A Miner Triad.' document, when he states that the note #00 is one octave lower than the note #FF.

 

The former note is slightly lower in pitch than the latter, but only by a factor of 256/255. ("An octave below" would suggest a doubling of the delay between consecutive excitations of the speaker. i.e. a halving of frequency.)

 

In the Main Loop, the value of a note is loaded (ultimately*) into the E register, and E is then decremented in a loop until it reaches zero - at which point a XOR #18 command sends a signal to the EAR/MIC ports, the original note value is loaded back into E and then the loop restarts.

 

A value of #00 will decrement to #FF in the first instance - before the check for a zero value takes place - and therefore #00 is the lowest note you can possibly obtain by using a single byte to store a value corresponding to the pitch (which I think, to be fair, was the main thrust of Richard's argument) - but it doesn't cause a delay that is twice as long as the delay caused by using the value #FF.

 

 

[* i.e. after accounting for any tune deterioration due to lost lives]

 

On reflection, I think I'll take back my comments above.  Whilst a study of the code would suggest that a note of value #00 should only be slightly lower in pitch than one of value #FF, having listened carefully to the two notes played one after the other in sequence, there does indeed seem to be an octave difference between them.

 

Why this transpires to be the case is a bit of a mystery; perhaps the carry flag is being set as the register rolls over, and this is extending the delay between excitations of the speaker diaphragm in some way?

Edited March 7, 2017 by IRF