IRF

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!

One more thought on the above - if the number of colours that the items cycle through is 7, then because that isn't an exact divisor of 256, Geoff Eddy's 'flying killer blocks' might eventually collide with one of the items (fatally) at a time when it happens to be White! This could be as late as 7 in-game minutes after Willy's entry to a room which has that PV enabled!

The havoc caused by the Attic Bug (with the POKEs in place to prevent Infinite Death Scenarios) is a classic case of The Butterfly Effect... https://en.wikipedia.org/wiki/Butterfly_effect

UPDATE: The disassembly seems to be of Geoff Mode 2. The Patch Vector disassemblies of Geoff's first three games refer to addresses in Geoff Mode 1, so they don't tally with the disassembly in some cases. However, the PV disassemblies for ZX Willy the Bug Slayer do tally with the Geoff Mode disassembly. e.g. Bug Slayer Room 31's PV calls up the 'Print a Room Element' code (in the same way that Rooms 10 and 53 of Willy Takes a Trip do), but this time from #8D96.

I would also add that in relation to the point above in blue, if you didn't try and shift Willy along the rope, then he sat there quite happily at the 'impermissible' height! (i.e. at a rope segment in the range 1 to 15 - N.B. Richard's POKES were also in place in the scenario being described.) EDIT: In this scenario, you can also turn Willy round to face in the opposite direction without triggering the sudden shift downwards - as long as you don't move him into a different frame of animation! Unfortunately, at the moment I can't share the working file in which I observed the above, but I'll try to recreate the phenomenon in a test file later. As promised above, I've recreated the effect that I was referring to, and I've recorded a .rzx file (see attached). Preamble: I've implemented Richard's POKEs that prevent Willy climbing above Rope Segment 15, changed the initial swing direction of the Ropes, drained the Swimming Pool of water, and set the Swimming Pool's Up Exit to itself. Here's a running commentary of the (short) recording: Starting in The Orangery, Willy drops down and lands on the Rope, at a segment that is higher than the permissible minimum value of 15. There he remains, swinging merrily; he can turn round and face the opposite way without moving (i.e. by pressing the Movement Key in opposition to his facing direction). But when I tried to get him to move along the rope (by pressing the Movement Key that corresponds with the direction he is facing), he jerks suddenly downwards, straight to Rope Segment 15 (as previously discussed). I then repeated the earlier trick of getting him to jump off the top of the screen, in defiance of our earlier analyses. After reaching the top of the screen, he emerges at the bottom (in the empty pool). Finally, I demonstrated another little quirky set of behaviours, which I believe are related to the effects above: - If you stand Willy underneath the Rope's central 'position of equilibrium', and make him jump sideways in the same direction that the Rope is swinging, just as the Rope passes over his head, then Willy doesn't catch onto the Rope, but he bounces off it (the rest of his jump is curtailed and he falls straight downwards); [There are then a couple of 'false starts' in the recording, where Willy jumped but missed the Rope] - If you start at the same position and make Willy jump sideways in the opposite direction to the way that the Rope is swinging, as the Rope passes overhead, then Willy is caught by the Rope - and in fact he moves up a segment (even if you haven't kept a movement key depressed after making the jump) - it then takes two nudges of the appropriate movement key [to climb downwards, you press the same direction as the Rope is swinging] to make him fall off the end of the Rope; - If Willy jumps straight upwards as the Rope passes over his head in the central position, such that he collides with the bottom of the Rope, then he is caught by the lowest segment (as evidenced by the fact that it only takes one nudge of the 'climb downwards' movement key, to make him fall off the end of it). P.S. The Adjacent Ropes Patch is in place, so this is all 'standard' Rope behaviour! [EDIT: Note to Danny: I've just come across an old message of yours on the Yahoo site; from my reading of it, it seems like you may have been encountering the problem of 'bouncing off the end of a Rope'? https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/6355] More Rope Effects.rzx

This is a useful link: http://www.worldofspectrum.org/faq/reference/z80reference.htm In particular, one aspect of the section discussing doubly-shifted opcodes was very illuminating: http://www.worldofspectrum.org/faq/reference/z80reference.htm#DDFDOpcodes To me, the element that I have highlighted in italics in the above quote, is counter-intuitive.

Further to the above, it's just occurred to me that if there was a CALL (HL) command in the Z80 armoury, then that could replace the JP (HL), thereby allowing the Main Patch Vector code (i.e. the 5 byte subroutine that directs the program to the address stored at Offsets #EE-EF for the current room) to be inserted directly into the Main Loop. (EDIT: Any room that doesn't have an associated PV routine could be catered for by pointing its Offsets #EE-#EF at ANY existing 'C9' Return command in the code.) However, it's a moot point, as I don't believe there's such thing as a CALL (HL) command!

Manic Miner disassembly, #8E5F is described as "Save the INK colour in the attribute buffer temporarily" (for vertical guardians, etc) - technically, the BRIGHT value of guardians is also stored by this command. (See three of the vertical guardians in 'The Warehouse', for example.) EDIT: Although the 'Angry Eugene' code that flows straight into #8E5F does discount the BRIGHTNESS bit (via an AND #07 at #9E5D).