IRF

I just found this audio review of "JSW The Nightmare Edition": http://www.everygamegoing.com/landing/items/spectrum_48k/jswmm/tapes/Jet_Set_Willy_The_Nightmare_Edition.html If he thought TNE was hard, wait till he tries out "Willy's Recurring Nightmare"... :P

It's bumped up the number of downloads anyway!

I've posted about this over on WoS now: http://www.worldofspectrum.org/forums/discussion/53733/new-micro-game-jsw-heaven-hell I wasn't sure whether or not you can add attachments to posts over there... then again, I've provided a link to here so it's probably best that way as it potentially gives this site a bit more traffic.

Yes!

The quirk is mainly to do with the rope, although the arrows play their part. I won't say too much just yet; I still have yet to 'announce' the game on World of Spectrum (for which I shall have to subscribe to WoS first!) Interestingly, the classic 'Infinite Lives' POKE 35899,0 doesn't work on this game (or indeed, on any game where Willy doesn't start off with any spare lives other than the one he begins with). That's because all the POKE does is remove the instruction that decrements the number of lives remaining - it doesn't stop the program from checking if any lives remain (and terminating the game if not).

Did you manage to get to Heaven?

I am pleased to present the JSWMM community with a brand-new 'micro-game' that I have created, entitled 'Jet Set Willy Heaven and Hell'. There are 25 items in the game, spread across three rooms. Try to ascend to Heaven, without descending into Hell. It's just a little bit of fun, but it does showcase a particular 'quirky' feature of the Jet Set Willy game engine which, to the best of my knowledge, has never previously been documented or exploited in a JSW game. I pray that you prevail! Jet Set Willy Heaven and Hell.zip

Richard has recently updated his JSW and MM disassemblies. Amongst other interesting additions, he has made a useful distinction between the 'Start the Game' routine, and the 'Initialise the Current Room' entry point into that routine: http://skoolkid.github.io/jetsetwilly/asm/88FC.html http://skoolkid.github.io/jetsetwilly/asm/8912.html

It turns out that I was sort of half-right about the above (which related to James Bond's trials and tribulations in the room 'GoldenEye'). However, the scenario didn't involve the player jumping up and 'bouncing off' the bottom segment of the rope. Rather, the player was trying to grab the rope near the top (in a room with the Up Exit set to itself). And crucially, the length of the rope in that room is set to a value less than the 'maximum climb height' (which is 12 in a normal game; 15 with Richard's POKES in place). The key to successfully completing this manoeuvre in GoldenEye (without wishing to overtly 'spoiler' Andrew Broad's game) can be found amongst the recent discussions in this thread. EDIT: Actually, there are two quirky rope-based manoeuvres in 'GoldenEye', one of which does involve bouncing off the bottom segment of the rope when jumping up from below (or trying not to!)

Thanks, Richard!

Perhaps it arose as a result of the 'rush to release' JSW in advance of Xmas 1984? It doesn't seem to make any difference though, as far as I can tell?

Congratulations to Danny! And good luck to Willy!! :lol:

Further to the above, I've noticed that the equivalent routine in Manic Miner (which is actually present, although unused, in the JSW code) does in fact use an OR command to merge the guardian's INK with the background's PAPER colour, not an XOR! http://skoolkid.github.io/manicminer/asm/8DF8.html#8e5f http://skoolkid.github.io/jetsetwilly/asm/93BB.html

This query doesn't relate to the AND instruction, rather it concerns OR and XOR:- Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR? http://skoolkid.github.io/jetsetwilly/asm/91BE.html It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells. Since neither of the two values that are being 'merged' will have any 'common bits' set in this particular case, the 'toggling' effect of the XOR will never be brought into play, and so it's exactly the same as using an OR (except that using XOR is arguably less 'elegant')?

I think this thread probably belongs in 'Chat' (alongside Danny's 'Language Questions' thread), rather than in 'Remakes'?

Perhaps you could think of it as 'Most Recent Best Answer', and mark Andrew's as such? :)

"a value of #01".

Or maybe the former in the readme, but the latter in the 'press release'?

Either is fine, I guess the former is more 'formal'.

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. :)

I was probably a bit lazy and should have put: the original "JSW". On the latter, probably: the Air's INK. Technically, perhaps it should be: the Air cell's INK. But that might start to get a bit unwieldy when you're saying it lots of times.

I guess "reenter" looks okay, but off the top of my head aren't there instances where you used the word "reentered" or "reentering" or "reentrance"? I thought that it started to look a bit 'unwieldy' without the hyphen, so I suggested with the hyphen for consistency. Either is permissible though, it seems.

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]

For clarity, perhaps the entry at #85CC should be described as "Lives remaining (after the current one)"?

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!