IRF

Please see the attached test file, based on the JSW64 game engine, which features experimental/novel implementations of each of the four 'special' Manic Miner 'guardian' types. Skylabs/Droplets: The opening room, a modified version of 'The Bridge', features an unprecedented mixture of 'standard' Skylabs, and Droplets of various types, all operating simultaneously. (They don't actually pose a threat to Willy in this test file, unless he jumps up and hits one.) All of the Droplets display distinct behaviour: - The white Droplet doesn't have any horizontal displacement in between consecutive incarnations, and drops down consistently in the centre of the screen; - The yellow Droplet has a horizontal displacement of 16 columns, so that it alternates between two positions half a screen-width apart; - The cyan Droplet has a rightwards horizontal displacement of 8 columns, so it progresses from left to right across the screen through four possible 'drop zones', just like the classic Skylabs in Manic Miner; - The green Droplet has a leftwards horizontal displacement of 4 columns, so it progresses from right to left across the screen through eight possible 'drop zones'. N.B. the starting columns of all four Droplets have been carefully selected so that they shouldn't ever collide! Angry Eugene: If you walk rightwards from the start-up room and enter 'The Off Licence', there is a vertical guardian which displays 'Eugene' behaviour, but with a twist... Your mission is to try to collect the item and escape safely from the room (it's a 'No Kamikaze' room, so the item will be reinstated if Willy loses a life before exiting). I suggest that you first try walking rightwards into the room without stopping, proceeding under the guardian and up the ramp, then jumping to collect the single item as soon as possible, and watch how events proceed. Then try taking a bit more time before collecting the item, and see the difference. Solar Beam: If you walk leftwards from the start-up room into 'Under the MegaTree', you can see that I have implemented a fix for the Solar Beam Bug which meant that, in original Manic Miner, the Solar Beam did not always kill Willy as soon as the air supply ran out. i.e. in this test file, the Solar Beam does kill Willy at the instant when the air supply is depleted to zero. Ditto for the Kong Beast (see below). Kong Beast: There is also a Kong Beast in 'Under the MegaTree' that displays a novel feature, the idea for which was inspired by the following exchange between John Elliott and Andrew Broad in a post on the Yahoo Group: Well, in the attached test file, there is an incentive to kill the Kong Beast - because it also saps Willy's air supply in 'Under the MegaTree'! See how quickly the air supply is being depleted in that room, even when Willy isn't standing in the Solar Beam! (N.B. The 'lethality' of the Solar Beam and of the Kong Beast can be set independently of each other.) In order to survive in 'Under the MegaTree' for more than a few seconds, it is necessary to flip the Switch (the yellow thing in the branches at the top-left, which uses 'Willy's head' as its sprite) and thus kill the Kong Beast. Note that there is a handy flashing Portal which provides a shortcut up to the Switch from the bottom of the screen, and Willy's progress is further assisted by the room's Portal Patch Vector, which automatically sets him jumping leftwards as he exits it - another technical novelty, I believe? - so that he lands just a few steps away from the Switch! Note that there are also a few bug fixes implemented in the attached test file, including some tweaks to the Kong Beast code to make it more 'generic' (for instance, making the Kong Beast's animation dependent on the global 'tick' counter rather than the current air supply, so that Kongs are still animated even if they appear in rooms without an air supply limit), and a patch for the bug in JSW64 which causes the Air Supply bar to become invisible (albeit still operational!) when you pause and unpause the game (something which remains in Dr Andrew Broad's 'to do' list for his 'Advanced JSW/MM Trainer project!). ****** A final word: I was wondering whether the scale of the interventions in the attached file (if they were extended to all six JSW64 variants) would mean that it could perhaps be considered to be a 'Hack Level 13' of the JSW64 game engine? Any thoughts? MM Specials Test File a JSW64X v.0.01 HL 12.tap

I've just noticed that the 'Willy is falling' sound effect in Manic Miner is somewhat different from the equivalent sound effect in JSW (in terms of how the pitch of the sound 'loops') - I don't know how this fact had escaped my attention for so long!! :blush: EDIT: In JSW2 it's different again (and different for jumping as well) - the pitch seems to be determined by Willy's current y-coordinate in JSW2.

At least one of SkoolKid's patches makes use of some of the commands in the TRS code, in order to minimise the number of POKES required by the patch.

I've edited the first post in this thread (and the link to the download) to make it clear that 'Ligan' is the third party author, in accordance with his earlier confirmation that this is the case. :)

I've just posted this on the MM&JSW Yahoo Group; I thought it would bear repeating here:

My 12 POKE fix for the bug that occurs when the air supply runs out whilst Willy is inside a Solar Beam, could've been done in 10 POKES (SkoolKid's self-declared upper limit), if only I hadn't taken care to tidy up the stack!

There's plenty of room on the stack, so it's only a hypothetical concern really. But it's good programming practice not to let the stack build up in that way.

I think that will cause stack build-up over time. It would be better to edit the jump address to #8FDB (Software Projects version; may be different for other versions), to clear the RET address.

So 'ASAP' is actually a bit too soon in the circumstances then!

On that note, try POKE #CE6A, #02 and POKE #CE6B, #01 and then enter 'Miner Willy meets the Kong Beast'. I haven't tried it out yet, so it will either give the player a helping hand or lead them to infinite death...

Well spotted! I would add: #E269, #03 #E669, #03 #F269, #00 to sort out the animation frames.

I believe that in a game with fewer than 256 collectable items, it would be possible to use the spare range of addresses at the top of pages #A4 and #A5 for other purposes. However, extreme care would need to be taken if subsequent editing of the item definition bytes is carried out - individual entries would need to be edited in the hex editor. If items are deleted in the JSWED GUI, then all other entries above in the item tables are shunted down, which would mean any Patch Vector subroutines would be brittle. A 'safer' use of the spare addresses at #A4xx / #A5xx would be for data such as graphics, or an in-game tune. (I resisted the temptation to use the spare bytes in this range when working on 'Jet Set Mini'.)

And with another three POKES that I've just come up with, you can also have an initial value of 0,1,2 or 3 for the game counter, without causing the aforementioned glitch: POKE #86DA, #23 POKE #86DC, #24 POKE #9F23, #52 EDIT: In decimal that's: POKE 34522, 35 POKE 34524, 36 POKE 40739, 82 The first two POKES adjust the 'Cavern entry' routine, so that the entire air supply bar is drawn, in the first instance, one character further to the left. Whilst the third POKE 'disguises' the leftmost character of air supply, by assigning Bright red INK (as well as red PAPER) to the 'blank' character in between the word 'AIR' and the air supply bar. So the air supply is now drawn across the 'blank' character to the right of the word 'AIR', but this isn't visible on the status bar, because the INK and PAPER settings for that character are identical. Meanwhile, the rightmost character of air supply isn't drawn until the first pass through the Main Loop, at which point only the correct number of pixels of air are filled in (and there is no danger of leaving any pixel undeleted by setting the game counter to zero at the start of the cavern). And the air supply still runs out when the character of air at address #5A24 in the attribute file has been cleared of pixels, just as before (there remains one character of air bar left undeleted at that point, but it is invisible to the player). With the above POKES as well as Norman's in place, a cavern can have any pair of values at Offsets 700/701 within the range from '#25 #00' [a single character of air = 64 time-frames] to '#40 #00' [28 characters = 1792 frames], without causing a glitch or freezing up the game. EDIT: With a single POKE #86E2, #25, you can have any value for initial air supply from #26 #00 [two characters of air = 128 time-frames] to #40 #00.

Am I right in thinking that using a one-byte DEC A wouldn't work in lieu of the two-byte SUB A, #01 ; because the INC and DEC instructions don't set the Carry Flag? (And therefore the conditional jump which follows won't be triggered when the value of A wraps round below zero.)

I think the 'c' should be lower case, or else the 'G' and 'L' from 'Grid Location' should be upper case for consistency.

SkoolKid's excellent assemblies, available in both decimal and hexadecimal. :)

John Elliott's cunning and efficient use of the Stack Pointer register, in his code which handles Triggers in JSW64, can only be described as audacious! :o

There's an example in one of Geoff Eddy's games, check out his Patch Vector disassemblies. :)

One other thing I should mention is that the minimum valid value for the initial air supply requires that at least one character of air supply is filled in at the start of the game. This equates to a value of #25 in Offset 700, since the 'Cavern Setup' code subtracts #24 from it in order to draw the air bar in the correct place on the status bar: http://skoolkid.github.io/manicminer/asm/8684.html#8691 (If you try to select a value of #24 for Offset 700, then I believe the Spectrum will crash, as the air bar is drawn via a LDIR loop in the 'Cavern Setup' code, and using an initial value of BC=00 in a LDIR loop will cause BC to wrap around to #FFFF, leading to an attempt to overwrite all 65536 bytes of memory!) So selecting an initial value of air supply = 0 for a cavern, in the current JSWED drop-down menu, equates to #180/4 = #60 time-frames (96 in decimal) before the air supply runs out. Whereas it is possible, under my suggested alternative 'initial air supply' regime, to have a cavern with #41 time-frames of air supply, or 65 time-frames in decimal. (You can achieve this by inserting the values #25 and #04 manually at Offsets 700 and 701 via the hex editor, or the equivalent if it is a JSW64 game. However, if you subsequently open up the 'Room Properties' menu, then JSWED may over-ride those values and try to reinstate what it considers to be 'valid' values.) Whether having a cavern with such a tight time constraint is a desirable feature - barely enough time to cross half the width of a cavern! - is a moot point, but it illustrates the increased flexibility (as well as the more rational distibution of permissible values) in the alternative regime.

There is a misconception in Dr Andrew Broad's otherwise excellent 'Manic Miner Room Format' document, regarding the matter of Miner Willy's Air Supply. Furthermore, John Elliott's JSWED editor seems to have followed Andrew's lead on the matter. And both parties were, in all likelihood, "led up the garden path" by Matthew Smith's original choices for the values of the initial air supply in the original MM caverns. Here is the pertinent excerpt from Andrew Broad's Manic Miner Room Format document: The possible values for Offset 701 recommended by Andrew are not linear, or proportionate to the number of pixels of air displayed in the final character of the air bar. The number of pixels that are initially drawn within the final character of air are as follows: 10000000 (denary 128) - 3 pixels 11000000 (denary 192) - 5 pixels 11100000 (denary 224) - 6 pixels 11110000 (denary 240) - 7 pixels 11111000 (denary 248) - 7 pixels 11111100 (denary 252) - 7 pixels (The only difference between the last three values, is a small variation in the number of time-frames which elapse before the first pixel of air supply is erased from the air bar.) In JSWED, John Elliott has established an Air Supply drop-down menu which allows possible values from 0 to 161, representing 6 possible values for each of the 27 available characters of air supply. i.e. seemingly in accordance with Andrew's recommended values above. [N.B. A value of 162 may be selected in a JSW64 game, but this assigns a value of #FF to Offset 701, as an indicator that the room/cavern does not have a limited air supply.] Now, as it happens, all of Matthew Smith's original caverns contain a value at Offset 701 which matches one of Andrew's values. The specific values are detailed here: http://skoolkid.github.io/manicminer/reference/facts.html#variableAirSupply However, any value could be selected for Offset 701 (this can be done via the hex editor in JSWED), as long as it is a multiple of 04. Which, as Andrew points out, rules out denary 254 or denary 255. (They cause the Spectrum to lock up when Willy exits a cavern, because the air supply countdown is decreased in decrements of 4, and so Offset 701 never reaches the target value of zero.) Andrew is also correct about the harmless glitch caused by selecting an initial value of zero for Offset 701. (The glitch occurs because, when the 'Decrease the air supply' routine at #8A3C is run in that circumstance, the number of characters of air supply is decremented before the routine gets a chance to wipe the pixels from the first [rightmost] character of air supply - the whole bar of air having being drawn in the first instance by the 'Cavern Setup' code which starts at #8691). I believe that Andrew must have - without the benefit of SkoolKid's excellent MM disassembly being available at the time, of course! - mixed up the possible values of the A register, emerging from the AND #E0 gate at #8A55, with the possible values of the E register which is used to determine how many pixels of air supply to draw in the rightmost character of air (individual bits of E are set, via a DJNZ loop, after A has been divided by #20 and fed into the B register - see #8A57-65). http://skoolkid.github.io/manicminer/asm/8A3C.html ****** There is a more refined possible approach to the gradation of the air supply. The air supply is graded at three levels, listed below in decreasing order of magnitude: - The number of characters of air within the air bar (derived from Offset 700); - The number of pixels of air within each character of air (determined by the value of Offset 701, in steps of #20, and so eight pixels disappear before the byte wraps round past zero and the character is fully erased); - The number of time-frames that elapse between the removal of consecutive pixels of air supply (eight time-frames, equating to a decrease in the value of Offset 701 of 8 x #04 = #20). Andrew's approach involves assigning values to Offset 700 in a linear manner, but his suggested values for Offset 701 are a non-linear hybrid of bullet-points 2 and 3 above. My suggested alternative would be to use the following possible values for Offset 701: 00100000 (#20, denary 32) 01000000 (#40, denary 64) 01100000 (#60, denary 96) 10000000 (#80, denary 128) 10100000 (#A0, denary 160) 11000000 (#C0, denary 192) 11100000 (#E0, denary 224) 11111100 (#FC, denary 252), or alternatively 00000100 (#04, denary 4) (The final value would fall slightly outside of the linear pattern, causing a pixel-increment to occur either one time-frame early or one time-frame late; but this is necessary in order to prevent the visual glitch which Andrew reported when a value of 0 is selected.) This alternative air-supply regime would translate into possible values, in an equivalent JSWED drop-down menu, of 0 to 215, representing 8 possible values for each of the 27 available characters of air supply. (In which case, a value of 216 should be used for a room without a limited air supply.)

Et voila! Please see the attached recording! I believe that in order to prevent Willy jumping out of a room with the Up Exit set to itself, is to apply Richard's POKES (available here: http://skoolkid.github.io/jetsetwilly/reference/bugs.html#fromTopToBottom ) and set the value of #8FAA to #E9. As opposed to the value #EC for #8FAA which I previously suggested. N.B. The original value for #8FAA in JSW is #F0. Therefore, preventing the jump off the top requires a delay of 7 additional time-frames between Willy dismounting a rope, and being able to climb back onto it, compared with original JSW. And as before, the above fix won't work in a room with more than one rope! Yes Top to Bottom!.rzx

Actually, it was my scrutiny of the code which made me wonder if it was theoretically possible, which I subsequently confirmed to be the case in practice. And it involved a change in technique to that which you tried before - I still maintain that it is impossible via your previous approach!

Except that it now turns out that it isn't impossible! :D

Danny, I've just proved myself (and you) wrong on this point!! I managed to jump off the top of the single-rope room via the rope, notwithstanding the code change which I thought would prevent such a manouevre! I'll do an .rzx later!

Yes, in fact some rooms have several items (e.g. Ballroom West), each of which have different effects on Willy in 'Mixup'. :)