IRF

It's sometimes said that the unused Room 47 in original JSW was meant to be located above 'Conservatory Roof'. This seems to be based on the fact that the value at #EFEC, in the code remnants that occupies the place where the room data usually sits, is set to #2D (Conservatory Roof's room number in hex). Offset #EC in a room's data usually defines the Down Exit, but in this case the '2D' actually forms part of the operand of an unused CALL command. So it's a rather spurious claim. Indeed, the Up Exit from Conservatory Roof is set to The Off Licence. However, the Right Exit from Tree Root is set to Room 47 (#2F) in the code, so the likeliest place where Room 47 would have been located, if it had ever been present in the original game, is to the right of Tree Root. (Several modified games have in fact placed it there, I believe.) Perhaps this merits a small mention in the Unused Room Trivia entry? http://skoolkid.github.io/jetsetwilly/reference/facts.html#unusedRoom

I'm just wondering what would happen if you were to NOP out the bytes at #925F-#9266 in the code that draws Arrows. I believe (without having tried it yet) that, instead of only being drawn on the screen for 32 'ticks' out of every 256, an Arrow would continually 'wrap round' and pass through the screen again, in the same direction and remaining within its designated cell-row, but moving down one pixel-row each time it went beyond the edge of the screen (looping back to the top of its cell-row once each time it reached the bottom of the cell-row)!? Of course, it would cause some interesting Invalid Arrow side-effects when the Arrow passed along the top and bottom pixel-rows!

Okay, so the disassembly at that link is of Geoff Mode 1? But if nothing else, my message above provides clarification about exactly how the CALLs in the first link relate to the routines in the second link. (Given that there isn't a link available for a Geoff Mode 2 disassembly, or is there?) EDIT: The specific bit of code that is called up by the Patch Vectors in Rooms 10 and 53 of Willy Takes a Trip, starts at #8D96 in the Geoff Mode disassembly.

Anyway, I think in Base 16 now, so Millenial Milestones mean nothing to me. :P

Here are a couple more useful links: J.G. Harston's page: http://mdfs.net/Software/JSW/ Geoff Eddy's Patch Vectors: https://web.archive.org/web/20030701143440/http://www.cix.co.uk/~morven/jsw/patches.html UPDATE: Later version, featuring additional PVs for ZX Willy the Bug Slayer: https://web.archive.org/web/20080511161939/http://www.cix.co.uk/~morven/jsw/patches.html http://www.worldofspectrum.org/pub/sinclair/games-info/z/ZXWillyTheBugSlayer.txt [some additional disassembly for ZX Willy the Bug Slayer is in the above txt file] However, in the PV disassemblies, I have noticed a couple of errors. Firstly, the PVs that change Willy's colour in 'Willy Takes a Trip' (Rooms 69 59, 61 and 62) all contain (directly or indirectly) several Calls or Jumps to #9673. However, the pertinent sub-routine in the Geoff Mode disassembly (link below) seems to start at #9679 (ending at #967F). Secondly, the PVs in Rooms 10 and 53 of 'Willy Takes a Trip' both call up #97C8 to print a room element, but the 'Print the room' routine in the Geoff Mode disassembly is at #8D33-#8DB0 (the pertinent part starts at #8D96). Geoff Mode disassembly: https://web.archive.org/web/20030701143111/http://www.cix.co.uk/~morven/jsw/geoff_dis.html Geoff's JSW pages: https://web.archive.org/web/20030805002513/http://www.cix.co.uk:80/~morven/jsw/index.html https://web.archive.org/web/20030818082654/http://www.cix.co.uk:80/~morven/jsw/geoffmode.html Yahoo Group: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/info Broadsoft Lifts disassembly: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/6608 Discussion of Superjump: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/5030 Discussion of Kong Beast: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/4417 https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/6454 Laterally-Inverting arrows: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/1867 Message re: Willy's Hoard: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/5868 Message re: 'It's Oh So Quiet!": https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/messages/2233 Message re: Spectrum file formats: https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/4766 Some Top Tips collated by Sendy (including the Droplets Patch, and variable-deadliness Solar Beam): https://groups.yahoo.com/neo/groups/manicminerandjetsetwilly/conversations/topics/5624

The JSW Disassembly Trivia section mentions an unused Entity Definition (#2B - a vertical guardian, which draws upon the page of sprite data that contains the Skull and the Evil Priest sprites), and the unused guardian sprite (the 'Periscope', whose graphic bytes are on page #B1 - it subsequently appeared in JSW2). However, I have just noticed an unused Entity Specification (sometimes referred to as a Guardian Instance), in the room data for 'The Hall'. It seems to be another instance of the static 'Chandelier', one of which is already present in that room. The second instance of it is there in the room's guardian list data, but because it follows after the 'FF' Terminator byte in the Guardian List, a second Chandelier doesn't actually appear in the game. That's just as well, as its specified x-coordinate of 00 would cause it to block the route up the Ramp in that room, and cause an Infinite Death Scenario if Willy walked in from 'Ballroom East' along the middle platform! (Presumably its second specification byte would have been adjusted to place it further to the right, if it had ever been used. EDIT: In fact, now that I think about it, a value of '00' would also have caused it to select one of the 'Centipede Segments' from The Attic as its base sprite, which would look distinctly odd without a head! Rather than the Chandelier base sprite, which would fit thematically with the room. So it's clear that the second specification byte is simply set to '00' by default.) Anyway, it's nice that the original game's data can still throw up the odd surprise, all these years later! Perhaps this merits a Trivia entry in Richard's disassembly? Incidentally, in recent projects (such as JSW The Nightmare Edition), we have been inserting more than one of the 'Chandeliers' into The Hall. Following this discovery, it would appear that we may have been coming close to Matt Smith's early vision for this room?! P.S. I've checked the data for the other rooms, and there aren't any other such instances of 'unused guardian specifications' in the original game code.

I was going by the hyperlink, which has '#entry4027' at the end. My post above has it thus: http://jswmm.co.uk/topic/198-post-4000/?do=findComment&comment=5000 However, looking at the homepage, it currently says: 4,959 Total Posts (That's at the time of typing; I guess it will say 4,960 Total Posts when I go to check after submitting this.) So it seems that my 'virtual party poppers' were premature. :blush: The disparity between the two figures must arise from posts having been deleted by the Moderators. :huh:

I'm not sure if that was post #4000, Danny? (If you hover over the '#1' hyperlink at the top-right of the first message in this thread, it says: http://jswmm.co.uk/topic/198-post-4000/?do=findComment&comment=4027 However, this post of mine is Post #5000!!! Let's get the party poppers out!!!

The following quote is taken from Geoff Eddy's description of his 'Geoff Mode' remix of the JSW game engine. Am I right in my interpretation that it isn't possible to have Invalid Arrows in Geoff Mode (because of the aspect highlighted in bold)? https://web.archive.org/web/20030818082654/http://www.cix.co.uk/~morven/jsw/geoffmode.html

It might be helpful for game designers incorporating Rooms 61-63 into a JSW48 game, if the disassembly were to provide the WRITETYPER Teleport codes for those Rooms. (As you're aware, in the original game the addresses where those rooms would be are just filled with unused code. Note that the JSW disassembly does provide the WRITETYPER code for Room 47, even though that room is also unused in the original game!) As an educated guess, I would suggest that the pertinent Teleport codes should be as follows: Room 61: 134569 Room 62: 234569 Room 63: 1234569 (Actually, it might be fun to try those out in original JSW and see where Willy ends up!!!)

I thought I'd copy the following two suggestions here (from a PM) for the 'wider readership'. (And rather cunning they are too, if I do say so myself!): And:

If the instruction at #8985 (setting the Rope Status Indicator to 0) was relocated to immediately before #894A, then it would benefit from A having been decremented to zero in the preceding loop, and therefore the single-byte XOR A command at #8984 would become unnecessary and could be recycled.

The Encroaching Rope: I believe that a Rope's data spilling beyond its alloted eight bytes in the Entity Buffer, falls firmly into the 'Bug' rather than 'Trivia' category. Furthermore, placing a Guardian directly after a Rope in a room's Entity List can potentially cause corruption through the game code, in a similar way to the Attic Bug! May I humbly suggest that your JSW disassembly could provide the POKEs that implement the Adjacent Ropes Patch (assuming the prior, kind permission of John Elliott for such, of course!)? Ropes before Arrows: This Trivia entry could perhaps point out that this scenario is sometimes, but not always, fatal to Willy. (Depending on whether the Arrow and Rope have sufficiently diverged in the next time-frame, when Willy's sprite is first drawn on the Rope.) Also, if the Arrow's pixel y-coordinate is such that it passes between the Rope's segments, then a pixel-collision might not take place, in which case 'teleportation' would be avoided!

To clarify, a Rope teleports Willy onto it, if one of the Rope's pixels collides with something that was drawn prior to it in the current game 'tick'. If that's an Earth cell, for instance, then he's fine. If it's a Fire cell, or a Guardian that sits earlier in the room's guardian list, then Willy in turn collides with that fatal element, and is killed. But it's not actually the collision of the Rope with the Guardian or Fire cell that kills him directly, just the fact that the 'teleportation' brings him into close proximity with the nasty! In fact, Willy can sometimes survive such encounters. e.g. if an Arrow is drawn before a Rope and the Rope hits it, sometimes the Arrow has moved on in its flight path in the next time-frame, sufficiently that Willy avoids being hit by it, and he is safely deposited on the Rope by the Rope-Arrow collision! Sometimes that's not the case though, and instead he is struck by the Arrow during the first (and indeed only!) 'tick' that he's on the Rope.

Indeed! I take it they are restored each time you leave and then re-enter a room? If so, the frustrating scenario I envisaged above would be repeated if the player had to pass through such a room more than once! :excl: :lol:

It would if they were Fire cells, or a guardian. But touching a Crumbly cell doesn't kill Willy!

But then the Crumblies in the middle (in the path of the Rope) may as well be Air cells... EDIT: Actually, Willy would be teleported onto the Rope every time it hit a Crumbly's 'on' pixel. So you could have quite a frustrating room with a few Crumblies in the path of the Rope, so that Willy keeps getting teleported onto the Rope before he gets chance to walk to the far side of the room! He would have to continually dismount from the Rope at the right place, clearing the Crumblies in turn (perhaps having to jump back onto the Rope at the last moment, after clearing the final pixel row of each, to avoid a fatal fall onto some Fire cells at the bottom of the screen?) Then only once all the Crumblies has been cleared from the path of the Rope, could Willy jump clear of the Rope and exit off the far side of the screen without being teleported back onto the Rope!

I suppose that's one option. However, I've considered it a nice challenge to find 'efficiencies' in the existing code and therefore try and pack as much into the available space as possible, without compression. And if nothing else, taking on the task has helped me get my head around how the Z80 machine code works. (I was clueless just a few months ago!!) :wacko:

(I wasn't sure whether to put this in the Manic Miner or the JSW thread!) Theoretically, if Willy were to descend onto a Crumbly cell whilst he's swinging on a Rope, presumably the Crumbly wouldn't actually crumble? (In the same way that Earth cells don't block Willy's progress, etc whilst he is on a Rope.) Because the Move Willy routine (from which the 'Animate a crumbling floor tile...' sub-routine is called) is bypassed when Willy is on a Rope (apart from the 'detect the movement keys being pressed' elements). Of course, such a situation wouldn't normally arise in a Manic Miner game (as the MM game engine doesn't feature Ropes), or in a JSW48 game (because Crumbly cells aren't supported). EDIT: Although, having pointed out this 'quirk', I can't actually think of a practical application of it in a game!? Any difficulty that the Crumbly cells crumbling away might present, in terms of proceeding upwards in a room, could simply be bypassed by climbing up the Rope! Having to clear a Crumbly cell away from the path of an oncoming guardian is a 'quirky' challenge, and putting the Rope in the way might make clearing the Crumbly away more difficult (if Willy keeps getting caught up on the Rope) - but then the guardian would be prone to being hit by the Rope, which would itself kill Willy (by teleporting him to the point of collision)! FURTHER THOUGHT: I suppose a nearby Rope might slow down the process of clearing away Crumblies that have Items on top of them (which can only be collected once the Crumblies have been cleared).

Further to the above, I've just observed that this particular efficiency is present in 'Geoff Mode', so it is 'tried and tested'!

N.B. The Cyan 'Kong caverns' guardians are present when you play the game!

Richard, I've just noticed that neither of the two 'Kong Beast' screenshots in the MM disassembly display the Cyan horizontal guardian!? Also, the comment at #91EE caused me momentary confusion; perhaps it should read: "The Kong Beast is drawn with Yellow Ink when he is falling"?

We already used or recycled a lot of those elements in The Nightmare Edition, but it's good to have them catalogued here in this thread for the 'wider audience'. :) Note that 'AIR' is used by JSWED to determine whether or not a file may be edited using its GUI.

Comparing the 'The game has just loaded' routines for MM and JSW (contrast the two links below), the latter seems to go about sending the program to the 'Display the title screen...' routine in a rather roundabout way. Perhaps this was originally done to try to confuse potential hackers who were attempting to bypass the 'Code entry screen' security element of the game? But now that the 'Code entry' routine is a bit of a 'relic', maybe the MM approach could be used in JSW? It would only take 7 bytes to disable interrupts, set the stack pointer (in the case of JSW, to #5BFE) and then make a direct jump to #87CA. http://skoolkid.github.io/manicminer/asm/8400.html http://skoolkid.github.io/jetsetwilly/asm/8400.html

Funny you should mention the Spectrum ROM, I've been experimenting recently and a familiar shape has popped up - see if you recognise it from the attached screenshot (the Black thing at the top-centre of the screen)... Also, you might be able to answer a query I had a while ago about the area of the 'contended memory' #5B00-5BFF. The 'top end' of it seems to be used for the stack addresses in JSW (starting at #5BFE-FF), but does it have any other use than that? #4000-#57FF is the display file, #5800-#5AFF is the attribute file, and the JSW buffers begin at #5C00 - so 'page' #5B fits in between those. I came round to your way of thinking on Willy's Jumping Animation Counter (when he makes a quirky jump 'Through the Wall') and the way the Rope Animation Table works (in calculating the offsets of each Rope segment) - although I had a couple of suggestions for 'clarifications' in the Trivia entry for the former, and the introductory text for the latter - and I've bombarded this thread with a host of other ideas since!