IRF

Another consequence of the bug in 'Ultimate Manic Miner'... There is another room in the game (other than 'Eugene Lair') which contains Skylabs, namely 'Reservoir Pumping Station'. However, the game is quite linear in its layout, and following the usual route through the game, the player would encounter 'Reservoir Pumping Station' before any of the rooms which contain Droplets (namely, as far as I am aware, 'The Menagerie', 'The Stonehenge Mine Subway', and 'The Bank'). Therefore the corruption of the Skylab code will not have taken place by the time you reach 'Reservoir Pumping Station' after you first load up the game file. However, if you were to play the game up until one of the rooms containing Droplets, but then lose all your lives and start another game, then when you reach 'Reservoir Pumping Station' the second time around, the gameplay will be different than it was the first time through! (Because the Skylabs in that room will have morphed into Droplets i.e. always dropping down at the same x-coordinate, with no variation to their horizontal 'dropzone' as is the case for classic Skylabs.) This is reminiscent of the bug in certain Manic Miner mods where Willy jumps off the top of the screen, causing overwriting/corruption of some of the data for other caverns.

It seems that the above suggestion came too late for your initial walk through of UMM, as I've just noticed that you did complete it and uploaded a video of it to your YouTube channel. However, the 'Eugene Lair' in that version looks a lot easier than (and not in the spirit of what) Igor originally intended*, so perhaps another walk-through if the bugfixed version could be put on your to-do list? *Those volcanic flares are supposed to shoot up at different points in the cavern, in the same way that Skylabs drop down at different horizontal positions, so that nowhere is safe to stand for long! For reference, the room in question can be seen 26 minute in to this video: Now watch those flare-ups - because of the big they only pop up in two places - imagine trying to navigate around whilst the fireballs continually switch x-coordinates - a whole different proposition!!

Daniel, when you do get round to completing 'Ultimate Manic Miner', I recommend you use the version which I patched to fix the bug that affected the room 'Eugene Lair', which caused the Skylabs in that room to behave as Droplets (ie they no longer varied their horizontal position). My fix (which required a change to the game engine) brought the game in line with the author Igor Makovsky's original intentions (as expressed in a comment by him on the Yahoo! MMJSW forum). Come to think of it, I don't think that patched version ever had an official release? I was in email contact with Igor about it at one point, he expressed gratitude for the suggested fix, and from memory had an intention to update the game himself at some point, including the fix. But that was several years ago now and I haven't heard anything from him since. My fixed version is probably attached to a topic here somewhere, but it would be nice if you could include it in the relevant entry at JSW Central? UPDATE: I just checked, and I didn't actually attach a bug fixed gamefile in the topic that I created on this subject* back in the day. Rather, I included a list of the POKES which may be used to fix the game engine to allow for both functional Skylabs and Droplets in a single game. (John Elliott's Droplets patch for JSW64 permanently erases the code which determines the Skylabs' behaviour). *The topic is called 'For fans of Ultimate Manic Miner', which in hindsight seems somewhat ironic (given Danny's subsequent description of how much criticism the game got when it was originally released - for its overuse of quirky features - which I wasn't aware of when I created the topic!)

I guess many people like to stick to the 48K limit. (If you're going 'retro' with your games, then you may as well go the whole hog, and the 128K Spectrum came later than old rubber keys - although the ZX81 was even earlier, its 16KB limit perhaps takes that concept too far/limits the size of the games too much?) If you add up the MM(48) and JSW48 mods from your list above, they amount to about two-thirds of the total (with JSW128 and JSW64 games collectively only making up about a third). So with that in mind - now that Norman Sword has managed to devise an optimised MM game engine which allows significantly more caverns within the 48KB constraint (how many more exactly? I don't believe Norman specified?), perhaps more such modified, more expansively cavernous games might be forthcoming in future?

My reading of Danny's post wasn't that it was a criticism of your endeavours, more of a lament that it isn't (currently) presented in a more accessible format that would allow people to create games using your nicely optimised MM engine with ease. I do seem to recall you releasing a version of Manic Miner with a fairly user-friendly in-built editor? But that was incorporated within the 48KB of the game itself, if I recall correctly, which I guess limits the amount of additional caverns that could be included within the 48KB memory limit? Danny is suggesting (perhaps as a pipe dream, but I believe in a positive, non-critical spirit) that someone [else, if not yourself] might at some point create an editor which runs on a PC or other similar platform, incorporating a user-friendly GUI, and into which 48KB MM game files (optimised as per your recent upload) could be loaded and edited by Joe Bloggs.

I would just add that, in relation to Andrew Broad's 'JSW64 Manic Miner: James Bond' game, the determining factor for the number of caverns was the number of (canonical) James Bond movies that had been released at the time of the game's publication. (Each cavern being dedicated to a single Bond movie, in chronological order.) The original version (1.0, released in 2007) contained 21 caverns, the last one being 'Casino Royale' (which was the most recent movie at that point, having been released in 2006); the game was updated with version 1.1 in 2009 to include an additional cavern 'Quantum of Solace' (film released in 2008). In the readme file released with v1.1, Andrew Broad said: "I plan to extend my game as future Bond-films are released. At the time of writing, Bond 23 is due in cinemas in 2011, so that will be added in v1.2" [However, in reality the next movie wasn't released until 2012, followed by two more in 2015/2021, and no further versions of Andrew's game have been released to date to incorporate caverns covering those movies.] So in the hypothetical world where more than 30 James Bond films had already been released prior to 2007, Andrew would probably have taken the opportunity provided by the JSW64 game engine to create a MM game containing more than 30 caverns from the outset.

Actually Andy, you might need to think again there. Did you actually try that out? Because looking at it again, E isn't actually updated when the tune note index is increased, so when DE is added to HL (the second definition of HL) at #8B50, it won't pick up the new note during the current pass through the Main Loop. So you would need to use that spare, NOPped out byte at #8B4C for a LD E, A instruction. Edit: Thinking about it, the effect of E not being updated straight away probably just means that the tune will be playing 'one note behind'. It should play at the right speed. But the first note (first pitch value) will only play half as long as it should when you start playing the game. (And the normal fix for that - setting the music note index to #FF during game initialisation - won't work this time; I think that would cause the last note of the tune to be played during the first pass through the Main Loop.)

I must admit I used AND #01 to affect the Zero flag - to decide when to increment (or not) the music note index - but it never occurred to me to just directly add the value of A (after the AND command) to the note index, which has the same effect since A can only hold 00 or 01 at that point. A very elegant and efficient solution! (Mine might be slightly more adaptable, as you can decide whether to advance the music on an 'odd' or an 'even' game tick, by selecting the polarity of the conditional jump: JR Z or JR NZ. However, mine needed an extra precious byte compared to yours, so yours wins!)

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!

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.

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

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.

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.

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!!

The simplest way to have a 256 byte in-game tune is this: Extend your tune data to 256 bytes. Then just NOP out the commands at #8B47 and #8B49. **** However, that by itself will cause the tune to play too fast (as the note counter will be incremented during every pass through the Main Loop). To slow it down to the regular speed, a bit more editing is needed. Insert this into the range of addresses #8B40-#8B4C: LD D, A (for the addition later on - N.B. this assumes that A is still set to zero as a result of the command at #8B3C) LD A, ($85CB) (game_tick_counter variable) AND #01 (test bit 0 of the game tick counter) LD HL, #85E1 (point HL at the music_note_index variable; NB this doesn't affect the Zero Flag) JR Z, #8B4C (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) - the conditional jump above jumps to here if the condition is met Then #8B4D onwards is as normal. P.S. You could check that part of the Main Loop in the Jet Set Mini code to see the above in situ.

First paragraph - that's how I feel whenever I hear the short, 64-byte version of the Radetzky March in-game tune, after having implemented a 256-byte version (score courtesy of Richard Hallas) in Jet Set Mini. How to achieve a 256-byte tune? I'll get back to you - although the answer may be in an earlier post of this thread?

If I Were A Rich Man. And ITHOTMK = In The Hall Of The Mountain King.

In the case of 'In the Hall of the Mountain King', I believe I did that classical piece of music justice in 'Manic Mixup' - implementing a quite faithful 128-byte loop during gameplay (which doubles in speed of play when the air supply in each cavern reaches the 'red zone' - replicating the way that ITHOTMK gains pace towards the end), and a coda that is played during the 'cavern completion' sequence (when Willy goes into a flashing portal), which matches the finale of Greg's original composition. 😎 I look forward to hearing what you've done with it, and also your extended rendition of 'If I Were A Rich Man'. 😊

I devised a similar setup for my long-gestating (currently in abeyance) project: 'Willy's Recurring Nightmare':- If Willy enters a new 'tune zone', the music note index is reset so that the new tune starts from the first note. (Incidentally, the music note index is set to 0, not to 1 as it is in the original JSW, in which the first note of IIWARM is curtailed when you first start playing a new game.) But if you enter a new room within the same tune zone (or lose a life), then the existing tune carries on seamlessly. I also added another feature - if you enter a new tune zone, the 'tune on/off' flag is reset so that the new tune starts playing even if the player had opted to turn off the music whilst Willy was in the previous tune zone. I figured that this would increase the exposure of the individual tunes - I appreciate there's a danger that it might annoy a player who wants to play without any music, but then they always have the option of just muting their laptop (if they're playing on an emulator, as most people do these days).

This cavern is interesting, in that it is both possible and impossible to complete the cavern without losing a life! A kind of Schroedinger's cavern! If you know what I mean?

I don't believe the portal in that cavern reveals itself during the 'lose a life' screen flash effect, although there is another visual effect during gameplay which helps you to locate the portal (which is at different position in the easy and hard variants!) - and having done that, Willy ends up in a position where there is no way out other than by sacrificing a life.

On that note, I recall that I was a bit precious about 'spoilers' immediately after the release of some of the games I was involved in a few years back. But I'd be happy for JSW Central to include screenshots of all the rooms in Jet Set Mini, Manic Mixup, etc, at a time of your convenience. (If they're not already there.)

Further to my previous post, I've refreshed my memory of the cavern layout (thanks to the screenshot on JSW Central, an ever-useful resource!), and it was the following aspect of the game engine that helped me to solve the cavern: Because...

I've just noticed that cryptic comment of mine from a couple of months ago, and I'm trying to remember what I was referring to! I think it was something to do with the way that items are drawn in the moment of Willy losing a life. From memory, I think there's a slight difference in the sequence of when an item is drawn in the main loop? Or maybe it's to do with the fact that each item is assigned its own PAPER setting in MM, as well as its own INK setting (which cycles through a palette of colours) - whereas in JSW, the INK colour cycles through the palette but that is then superimposed on the PAPER colour of the air cells for the host room. Anyway, the net effect was that I was able to solve more easily the puzzle in the cavern in question, in Manic Person, because... I think if the JSW game engine was operating, the would have remained

It looks like you have to exploit a game engine bug/quirky feature in order to be able to collect the uppermost item in that starting room.