Manic Miner Air Supply - a more refined approach

[IRF]

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:

 

 

Offsets 700 to 701: Air

The amount of air you have in a room is held in Offsets 700 and 701:

 

• The value held in Offset 700 is a+32, where a is the column that the air goes up to (effectively, you have a-4 characters of air, as the air starts at column 4). The default value for Offset 700 is 63 (i.e. a=31), but in many of my caverns, I give you a reduced air supply! :->
• The value held in Offset 701 is the number of pixels of air you have (in addition to characters of air, as encoded by Offset 700), represented as one of the following bytes (shown in binary to help you visualise it):

  10000000 (denary 128)11000000 (denary 192)11100000 (denary 224)11110000 (denary 240)11111000 (denary 248)11111100 (denary 252)

  There are bugs associated with using 00000000, 11111110 or 11111111 as the value for Offset 701, so it's derecommended (and my Manic Miner Screen Editor doesn't allow it - actually, it does allow 11111110 because I only discovered that this value was problematic after I released MMSE):

  • Using 00000000 (denary 0) causes a fairly harmless glitch in the graphics (see Room 10 of Manic Miner: The Buddha of Suburbia, "The BUDDHA OF SUBURBIA : suburbs");
  • Using 11111110 (denary 254) or 11111111 (denary 255) confuses Manic Miner when it is supposed to subtract a character of air from Offset 700, resulting in an infinite amount of air and causing the Spectrum to lock up when you exit a cavern. I used this trick in the final room of both Manic Miner 4 and Manic Miner: The Buddha of Suburbia, but it's not to be recommended, especially not in earlier levels! ;-)

 

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

Edited August 4, 2017 by IRF

[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.

Edited August 7, 2017 by IRF

[Spider]

 I have read this although I do not fully understand it, I do appreciate the writeup as (like other things I've read) when knowledge is gained re-reading them and then they 'gel' perfectly. :)

[jetsetdanny]

It's a very impressive analysis, Ian - thanks! :)

[Norman Sword]

; THE GAME CLOCK

;original

35389 LD A,(32957) :GAME CLOCK
35391 SUB 4
35393 LD (32957),A
35396 CP -4
35398 JR NZ,35413

35400 LD A,(32956) ;AIR SUPPLY
35403 CP 36
35405 RET Z
35406 DEC A
35407 LD (32956),A
35410 LD A,(32957)

35413   AND 224

 

;change to

 

35389 LD A,(32957)
35391 SUB 4   ; Now becomes possible to change (not recommended)
35393 LD (32957),A
35396 nop ;<<<< poke 35396,00
35397 nop     ;<<<< poke 35397,00
35398 jr nc,35413 ;<<<< poke 35398,48

35400 LD A,(32956)
35403 CP 36
35405 RET Z
35406 DEC A
35407 LD (32956),A
35410 LD A,(32957)

35413   AND 224

 

; this will remove the restriction on having the game clock
; fixed to 4,8,12,16,etc

 

; any value will now work

 

; as far as I can see no routine uses the bottom two bits

; horizontal guardians use the toggling of bit 2 - so unused bit 0-1

 

; Eugene uses the value/4 for colour - so unused bit 0-1

 

; Kong beast uses the value/32 - again unused bit 0-1

 

; I can find no usage for the lower two bits

 

; for example if the value of SUB 4 is change to say sub 2 the game will still run
; the (slow) horizontal sprites will become jerky
; the value can be changed to SUB 1, the (slow) sprites will become even jerkier, but the game will still run
; this change (not recommended) also changes the decrease in air supply speed.
; SUB 1 gives you four times as long in a cavern, and big points when it is finished

; Of course this type of change also affects the animation of Kong and the colour change in Eugene,

;both of which are cosmetic

 

;---------------------------------

 

; More on the value in game clock.

; The game uses two routines to draw the air supply
; the first routine (R1) draws the full bytes remaining, and is drawn on entry to a cavern
;
; The second routine (R2)(which is the one part listed at the top of this comment)
; is concerned with the drawing of the part byte (bits) at the end of the air supply
; this routine erases the air bar as it draws, and for most values that are multiples of 4 no
; problem will be encountered.
;
; However if on the first pass after initialisation, if it ecounters a "0" then this routine (R2) will
; immediatly move the air supply position left one byte. This will result in the initial drawing
; having a glitch, at the end of the air supply graphic. Due to the last portion being un-erased
;
; Any initial values that are not multiples of 4 will also hang the game on finishing a cavern
; Plus the air supply will remain cycling on the end of the air supply bar

;
;
; AFTER MODS--

;

; first pass after initialisation (GAME CLOCK)
; This byte can now hold any value, that does not set the carry on the first pass after initialisation
; Since the carry will be set for values of 0,1,2 and 3 they should be avoided.
; This is because on the first pass, the routine (R2) will immediately move the whole byte counter left by one byte.
; This will leave the graphic at the end of the air supply un-deleted. (a cosmetic glitch)
;
; No other value should cause a problem, because the restriction of being a multiple of 4 will have been removed.

 

; In summary, modify with three pokes.. Any value bar (0,1,2,3) for the Game counter

[IRF]

 

; SUB 1 gives you four times as long in a cavern, and big points when it is finished

 

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

[IRF]

Quote

 In summary, modify with three pokes.. Any value bar (0,1,2,3) for the Game counter

 

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.

Edited April 19, 2021 by IRF

[IRF]

Furthermore, inserting a CALL* to #8A52 into the Cavern setup routine (just after the full characters of air supply have been initially drawn) means that you can draw the correct number of pixels of air supply at the start of each cavern, which removes a visual glitch that can occur when Willy first enters a cavern (whereby the rightmost character space of air is initially fully filled in [or fully empty with my previous three POKES in place], and then gets adjusted on the first pass through the Main Loop to reflect the proper value for the initial air supply.

 

(*Needs consolidation to get it to fit.)

[Spider]

I think that's a much more elegant solution perhaps than my erm 'grace period' thing although I do think that also has its potential uses.

[IRF]

A word of warning: when adjusting the initial air supply in a cavern, you would be wise to increase or decrease the value by a multiple of 8 (equivalent to two units of air).

Increasing or decreasing the initial air supply by 4 can upset the balance in caverns with a Slow horizontal guardian (which are only moved during every alternate frame), causing the guardians to fall 'out of sync' with each other.  This effect can be seen, for example, in the Solar Power Generator - where it actually causes the distribution of the solar beam over time to be different.