IRF

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

In light of the above, I'm not sure my notion of an 'Item-Collection Patch Vector' quite fits in with the definitions? I suppose it's a modification of the concept: rather than each item definition holding a unique two-byte address where the Item-Collection Patch is stored, the exact nature of the special effect associated with the collection of each item is hard-wired to the item number [effectively; although it's actually determined by the item's position in the Item Table at #A4xx-#A5xx, which amounts to the same thing]. In that sense, it's more similar to the checks of the current room number in original JSW, which are the way in which the special effects in The Nightmare Room, The Bathroom and the Master Bedroom are implemented.

Have you tried it? I don't think Willy will be able to jump up and land on the single-cell platform in 'Under the Roof' (the one attached to the left-hand side of the 'trunk')? That single-cell platform is one row too high up, and Willy's Airborne Status Indicator is reset when he jumps up from one room to the next one above, so I believe that he will briefly appear in the bottom-left of 'Under the Roof' but will just fall straight back down again... Figs, since it's a Banyan Tree. B)

I've implemented the principle successfully, in several instances, in 'Mini'. :)

I wonder whether we've been getting the terminology correct here? Having given some thought to the matter, I now believe that: - The 'Patch Vector Subroutine' is the four-byte subroutine that is CALLed from the Main Loop (or from the Room Setup Routine), which picks up a two-byte address stored within each room's data, and jumps to it; - 'Patch Vector' is the term for the jump destination address, stored across two spare offset bytes within the room data for each room (i.e. the Patch Vector refers to the coordinates where the Patch for that room is located); - A 'Patch' is a subroutine, located at the address that is pointed at by the 'Patch Vector' for the current room; the Patch is CALLed up from the Main Loop (or from the Room Setup Routine) via the 'Patch Vector Subroutine'. So for a game in which the Main Loop contains a CALL to the Patch Vector Subroutine, all rooms have one Patch Vector (no more, no less), although a room may feature more than one Patch if several are 'daisy-chained' together before a RETurn command is encountered during flow of execution. In such a game, if a room's Patch Vector points directly at a RETurn command, then it would be the case that that room doesn't have a Patch, but it does have a Patch Vector. ****** Following the above definitions, one would say that each room in the SE of 'Willy's New Mansion' has exactly one Patch Vector, and one or more patches. ****** Another example: in the recently-released 'Jet Set Mini', there is a CALL to a Patch Vector Subroutine from both the Main Loop and the Room Setup Routine. Every room therefore has precisely two Patch Vectors - a Room Setup Patch Vector and a Main Loop Patch Vector. However, some rooms don't actually feature any Patches at all (both Patch Vectors point straight at a RET command); some rooms contain a Main Loop Patch but no Room Setup Patch (or vice versa); some rooms feature both a Room Setup Patch and a Main Loop Patch; and some rooms contain more than one Room Setup Patch and/or more than one Main Loop Patch. Furthermore, some Patches may be shared by more than one room (where the Patch Vectors for both of those rooms point at the same address), or a Patch might be partially shared by more than one room (if two Patch Vectors point at different entry points into the same Patch). Finally, some Patches in 'Jet Set Mini' make use of existing subroutines within the original JSW code (e.g. by setting appropriate values for the register-pairs and then CALLing up the 'Print a sprite' subroutine at #9456). Where such a feature forms the only or final element of a room's Patch, then JUMPing to the subroutine instead of CALLing it means that there is no need to insert a RETurn command at the end of the Patch; the RET at the end of the existing subroutine will do the job of returning the flow of execution back to the Main Loop (or to the Room Setup Routine).

Based on my recent observations, JSWII items cycle through five colours - blue, red, green, cyan and white.

View File Jet Set Mixup 'Jet Set Mixup' is a redesign of Matthew Smith's classic ZX Spectrum 48K game 'Jet Set Willy'. It can be played on a real Spectrum, on the Sinclair ZX Spectrum Vega/Vega+ or on a computer, game console or another device using a ZX Spectrum emulator. The layout of 'Jet Set Mixup' is almost identical to that of 'Jet Set Willy', but most of the original guardians have gone on holiday, and have been replaced on duty by sprites from 'Manic Miner' and 'Jet Set Willy II'. Furthermore, the player is offered a choice of sprites with which they can play the game. We hope you enjoy this 'mixup'! Submitter IRF Submitted 07/21/2017 Category JSWMM Releases  

View File Jet Set Mini "Willy has fallen on hard times. After living the high life for several years, he had frittered away his mining fortune, and found himself struggling with the upkeep of his sprawling mansion. So he had no choice but to downsize to a more modest pile. Things settled down for a while, but then he made the mistake of inviting a few of his old friends over to his new gaff for a housewarming party: 'Just a few quiet drinks, nothing major...' The morning after the night before, Willy wakes up in the bath with a throbbing hangover, to observe a disturbingly familiar scene. His house is trashed, all his friends have deserted him, an assortment of dangerous denizens have taken up residence - and his tyrannical housekeeper Maria won't let him go to bed until he's tidied up the place..." *********************************** 'Jet Set Mini' is a redesign of Matthew Smith's classic ZX Spectrum 48K game 'Jet Set Willy'. It can be played on a real Spectrum, on the Sinclair ZX Spectrum Vega/Vega+ or on a computer, games console or another device using a ZX Spectrum emulator. Willy's new abode in 'Jet Set Mini' is rather scaled down in comparison with his original mansion. But size isn't everything! Much of the code which was freed up by paring back the layout has been recycled, in order to insert a whole host of special effects into the game! Many of these changes are implemented via tools known in the trade as 'Patch Vectors', which are called up on a room-specific basis. There are also a number of generic modifications and enhancements to the game engine. However, the essence of this 8-bit, 48K game will be very familiar to connoisseurs of 'Jet Set Willy'. We hope it gives you 'no small measure of pleasure'! Submitter IRF Submitted 07/21/2017 Category JSWMM Releases  

Just back from pub - LOL!!!!

Norman Sword, you have reappeared here at a fortuitous moment! We are about to release a game called 'Jet Set Mini' (possibly later today, or tomorrow), which includes a fairly comprehensive readme file. This is an excerpt from the readme, which relates to a contribution that you made on jswmm.co.uk If you would care to have a quick read and pass comment, then we can take any such comments on board prior to the game's release. There is also an individual credit for you, see below. (We can change it if you would prefer to be credited as Derrick P. Rowson - if indeed you are he?)

Try the method I suggested, your new subroutine would only need to be six bytes I think. ;) Alternative sprite - have you tried replacing the value of #8726, from the default '82' to '81'. That should work, although the sprites picked up in some caverns might look a bit odd. :o

That should of course read "AND #07 would work instead"! (Original post corrected.)

You could insert an AND #0F just before the LD B, A at #8717. That way, no more than fifteen remaining lives would be displayed. You'd need to check whether that leaves room for the 'Cheat Mode' Boot sprite - I think it would, but if not, then using an AND #07 would work instead. ****** Either way, it would require two more bytes to be inserted near the start of the Main Loop, which is quite a tight part of the code. The simplest way I can think of to do that (with minimal code-shuffling) would be to replace the three-byte command at #8711 with a CALL to a subroutine located elsewhere (e.g. the spare addresses that are filled with source code remnants). Then at the remote location, insert the following six bytes: AND #0F (to bring A within the range 00-0F) LD HL, #50A0 (to replace the command which was displaced from #8711( RET

Ignore the part in bold in my previous post - the code counts seven digits, via the E register, so it won't wrap around into an eighth digit! :blush: However, I was quite correct in my assertion that time won't run out when the clock reaches 0000000 - having just tried running a Geoff Mode game in SPIN until that point, it just starts again at 9999999! Geoff admits in the 'Time Counter' section of his 'Guide to Geoff Mode' webpage that: This no longer shows a time, but a 7-digit number which counts down from 9999999. This dates from the earliest days of Geoff Mode, and I can no longer remember why I did it. What he doesn't admit, though, is that the Time Counter is seemingly completely pointless! :D

One other observation with respect to the Geoff Mode game engine - I don't think that anything will actually happen if the time counter (which counts down from 9999999) were ever to reach 0000000!? i.e. I can't see any evidence in the code that the game comes to an end, although the number of items collected up to that point might start to be decremented!?

You would also need to change the value of #86D0 from #20 to #40 (that's to print the word 'AIR' in the right character-row).

Did you apply the fix for the sound effect, when Willy clears a cavern? And I should emphasise: you'd have to change the value of the appropriate Offset Byte in the data for all twenty caverns, not just for Central Cavern.