Playing around with the in-game tune in JSW

[IRF]

P.S. If you have already recycled the 'inactivity code' (#8B3C-3F), then you'll need to find an extra byte from somewhere else (two bytes to define LD D, #00 but you won't need the earlier single-byte LD D, A command).

EDIT: In fact, if you're trying to apply this to a Manic Miner game then you'll have to find an additional byte from somewhere anyway, as the inactivity code doesn't exist in that game engine.

FURTHER EDIT: Actually, you would have bigger fish to fry if you're trying to implement this in a Manic Miner game. The code in my previous post relies upon the minute/tick counter (#85CB in JSW) to decide when to increment the music note index. But there is no similar minute counter in the MM game engine. So you would have to introduce one (it wouldn't need a whole byte; just a single bit which acts as a flag and toggles between set & reset (probably via a XOR) every time that the Main Loop is executed.

I suppose you could use the lower byte of the air supply variable (#80BD) for this purpose - it is decremented by a value of 4 each time, so you would have to test bit 2 (AND #04) for the purpose of playing the music at the regular speed. Or you could test bit 3 (AND #08) for an even slower rendition. But then you might have an odd effect in the solar cavern whereby the music either occasionally plays faster, or else gets stuck on the same note, whenever Willy is inside the solar beam? But then I suppose that could be quite a fun, quirky effect!!

Edited January 4 by IRF

[IRF]

Okay, with a bit more rearrangement, this should work to enable a 256-byte in-game tune for the Manic Miner game engine - insert the following at addresses #883A to #8851:

LD A, ($80BD) - lower byte of the air supply

AND #04 - test bit 2

LD HL, #845B - point HL at the music_note_index variable; NB this doesn't affect the Zero Flag

JR Z, #8845 (or JR NZ, whichever polarity doesn't cause the first note to be missed or curtailed upon game startup) - conditional relative jump past the next single-byte command

INC (HL) - the conditional jump prior to this command will ensure that the code which increments the music note index is only executed when the game tick counter holds either an odd or an even value, thereby slowing down the rendition of the tune.

LD E, (HL) - pass the value of the music note index to E

LD BC, #0003 - this command was previously at #884F

LD D, B - resets D to zero in a single byte

LD HL, #858C - point HL at the table of tune data

ADD HL, DE - adjust HL to find the current note

LD E, (HL) - pick up the note pitch value

LD A, (#8073) - pick up the current cavern border colour

Then #8852 onwards is as normal.

Edited January 4 by IRF

[IRF]

Overnight, a couple of other things have occurred to me in relation to the above patches.

In relation to the JSW patch, there's no need to use the trick of initialising the music note index to #FF at the start of the game - that might actually cause the game to begin by playing the last note of the tune first! (if the conditionality of the relative jump is such that the note index isn't incremented during the first pass through the Main Loop). 

And for the MM patch, because of the fact that the initial air supply differs between caverns (some start off holding an even number of units of air; others start off with an odd number), that patch will mean that in some caverns the first note will be played shorter than usual. That can be fixed by ensuring that all caverns start off with either an even or an odd number of air units (bearing in mind that a single air decrement is a value of 4). 

EDIT: D'oh! Sorry, that second point isn't an issue unless your game initialises the music note index at the start of each cavern. Which doesn't happen in the original Manic Miner - ITHOTMK just carries on where it left off after you go through a portal to the next cavern. But I suppose it might be the case if someone were to devise a game with a different tune for each cavern, and they wanted each tune to begin playing with its first note as the player encounters them.

 

Edited January 5 by IRF

[Spider]

Nopping out #8B47 and #8B49 would do but its too fast then. So...

XOR A                            ;8B3C      ;                  clear the inactivity timer at L85E0 
    LD (inactivity),A            ;8B3D      ;L85E0
    LD D,A                           ;8B40      ;                   initialise the mSB
    LD a,(game ticker)       ;8B41      ;L85CB        the game ticker at 85CB
    AND 1                            ;8B44      ;                   issolate odd or even game ticker bit
    LD HL,(ingame_music) ;8B46      ;L865F        set HL to the music offset pointer
    LD E,(HL)                       ;8B49      ;                   get the present offset
    ADD A,E                        ;8B4A      ;                   add the ticker (odd/even) value
    LD (HL),A                      ;8B4B      ;                   store the updated offset
   NOP                              ; 8b4C      ;
back to the original code
   LD HL,ingame_music    ;8B4D     ;L865F
   ADD HL,DE                    ; 8B50    ;
>>> HL IS POINTING AT THE NOTE value 

[IRF]

That's similar to my solution, but not identical. You seem to have a spare byte in there, so you could afford to retain the original two-byte LD D, #00 command, instead of the single-byte LD D, A. That would mean the patch isn't reliant on A having been reset to zero beforehand. (Since a lot of game designers ditch the preceding inactivity code which sets A=0.)

[IRF]

I should add that your more efficient solution wouldn't work in Manic Miner (if you were using the air supply variable #80BD to keep track of when to advance through the tune), because bit 2 of #80BD acts as the game clock, not bit 0. You would have to rotate the bits of A (twice) after the AND #04, eliminating the byte saving.

[jetsetdanny]

13 hours ago, IRF said:

EDIT: D'oh! Sorry, that second point isn't an issue unless your game initialises the music note index at the start of each cavern. Which doesn't happen in the original Manic Miner - ITHOTMK just carries on where it left off after you go through a portal to the next cavern. But I suppose it might be the case if someone were to devise a game with a different tune for each cavern, and they wanted each tune to begin playing with its first note as the player encounters them.

That's exactly what happens in "Manic Person"!

[IRF]

1 hour ago, jetsetdanny said:

That's exactly what happens in "Manic Person"!

Indeed! Only 64 bytes per tune though. If you had 20 tunes of 256 bytes each, that wouldn't leave much room for anything else! 

[jetsetdanny]

11 hours ago, IRF said:

Indeed! Only 64 bytes per tune though. If you had 20 tunes of 256 bytes each, that wouldn't leave much room for anything else! 

Exactly. Even with 64-byte-long tunes there was no room left for any extras. A suggestion was made after the game was released that it could do with a non-standard font. It was a very good suggestion, but unfortunately impossible to apply without far-reaching changes to the game engine that would optimise the code 'a la Norman Sword' and free up enough space to implement a new font.

[jetsetdanny]

Ian, I never thanked you for answering my request and for all the information and code solutions you have provided! Thank you so much, it is all greatly appreciated! 🙂 👍

I remember once in the past I did have a look at the Jet Set Mini code, but couldn't make enough sense of it to be sure what you had done there. I probably didn't try hard enough (I didn't need a 256-byte-long tune 'seriously', I was only toying with some ideas). In any case, it's great to have everything explained plainly in this thread! So thanks again 🙂.