IRF

I've added the introductory 'back-story' to the first post of this release topic (and to the download page). New game file (the Special Edition of the game, with enhanced Title Screen music) to be uploaded this Friday... http://jswmm.co.uk/topic/356-file-jet-set-mini/?do=findComment&comment=6775

Skoolkid is correct that the the graphic that you see as the end product gets drawn twice (no 2 and no 3 in your list). But he omits to mention the first occasion that 'something' is drawn to the top half of the screen, although that 'something' (which never gets seen) is quite different. **** More related trivia: The attached screenshot was created by using POKE #8AAE, #C9 in order to disable the special graphic for the top half of the Final Barrier. Any attribute values in the layout of the upper half that aren't recognised as being the attribute of a defined cell type (or, thanks to the Cell Graphics Bug, a graphic data byte), cause the cavern-drawing routine to draw an apparently random pixel pattern into the corresponding screen cells. (See the 'tree trunk' in the attached screenshot, for example.) However, that pixel pattern is not random. In the event that the CPIR loop in the original routine exits without having found a matching value for the attribute value that it is seeking for, (from the list of cell definitions stored in the region #8020-#8067), then HL will be left pointing at the next byte along, namely #8068. The routine then picks up the next eight bytes #8068-#806F and interprets them as a pixel-pattern in order to draw a graphic in the appropriate cell. But the first seven of those addresses are actually the bytes which define Willy's location and movement status upon his entrance to the cavern (#8068-#806E), whilst the eighth byte (corresponding to the bottom pixel-row of the odd graphic) is the conveyor direction byte (#806F). **** P.S. In the attached screenshot, the crown of the tree and the windows of the house are examples of the Cell Graphics Bug in action. The colour-attribute written to those parts of the screen don't match with an attribute from the list of the cavern's cell types, but they do match with a graphic data byte from some of the defined cell graphics for the cavern - the wall tile definition in the case of the crown of the tree, and the 'dangling spider' Fire cell in the case of the windows. You can see part of the wall tile graphic drawn across the tree's crown, whilst the windows of the house are drawn using part of the 'spider' Type 1 Fire cell, and part of the (defined for the cavern but unused) 'stalactite' Type 2 Fire cell. P.P.S. The green and yellow grassy areas provide a perfect attribute match with the wall tiles, so the full wall graphic is drawn across the 'lawn' areas of the upper half of the screen in the attached screenshot.

That fixes the Cell Graphics Bug as well, doesn't it? (The Cell Graphics Bug doesn't actually affect any of the graphics in the original Manic Miner, but that's more by luck than judgement.) The Trivia section of SkoolKid's disassembly has recently been updated with a mention of the dubious room-drawing logic in 'The Final Barrier': http://skoolkid.github.io/manicminer/reference/facts.html#topHalfTwice

That would benefit from a rewrite to take a 'Patch Vector' approach, like Geoff Eddy's JSW games, using a spare pair of offset bytes in the cavern data to determine which special effect routine (if any) to implement.

Sorry, is that a response to my suggestion, or Norman's? Because you wouldn't have to move ANY routines to use caverns #39 and #3A. The addresses that they occupy is unused source code, you can just NOP it out and it makes no difference to the running of the program. So it would just be a case of populating it with 2048 bytes (two caverns worth) of cavern data!

Items should be okay in MM as they are specified in each cavern's data, unlike in JSW where there is a global item table.

Obviously compression of the cavern data would allow a lot more caverns, but as Norman says it would require a lot of work on the code to implement. Just to add to my two penn'orth from earlier, the two new caverns that you could create without compression, by using the spare addresses #9400-#9BFF, would have technical cavern numbers #39 (57 in decimal) and #3A (58 in decimal). You could test this out by copying data from existing 'new' caverns* into those addresses, load up the file and POKE the current cavern number (POKE #8407, #39) whilst the Title Screen tune is playing, and then press ENTER to start up the game. Things will break down once you enter the portal in the second of the two caverns! (*I would suggest something sufficiently distinctive from the 20 original caverns, so that it's clear that the 'invalid caverns' are working properly. e.g. why not choose a couple of caverns from Andrew Broad's laterally inverted version of MM? Make sure you choose two of the later caverns without 'special' features. i.e. two caverns with vertical guardians but no Skylabs, Kong, Eugene, Solar Beam or Final Barrier. Obviously you could just copy two of the original MM caverns from the higher addresses of the same game file, but then it wouldn't be immediately evident that Willy wasn't just occupying one of the regular caverns! I think that '...Mutant Telephones' and 'The Bank' would be best, because the difference in the mirrored version is obvious by the fact that the '10p' coins and the '

It should be possible to calculate a couple of 'invalid cavern numbers' which would map to the following unused areas of code: #9400-#97FF and #9800-#9BFF. That would allow you to have two extra caverns without compressing the existing ones. But you would need to edit the start of the 'Move to the next cavern' routine to get the game to access the two new caverns (and so that Willy proceeds after completing them back to the Central Cavern). As things stand, they would both be 'horizontal and vertical guardians present' caverns by default. And as you say, you would have to manually create the caverns in the hex editor, because the GUI in JSWED wouldn't display them. But you could open a new file, create the new 'invalid caverns' from scratch in the place of two existing caverns, and them copy their definitions wholesale (1024 bytes per cavern) across to the above addresses in the original game file.

POKE #8E7C, #01 has some odd effects on Willy's falling mechanism.

The check for a standonable platform underneath Willy is extending down past the secondary attribute buffer (#5C00-#5DFF) to the primary attribute buffer (#5E00-#5FFF), in the same way that the Fire cells at the top of the screen can kill Willy when he is immediately beneath them at the bottom of the screen. In the previous files, the newly-created permanent water cells are printed at the top of the primary attribute buffer, and Willy can stand on them in the same way. The change to Water comes about because Willy alters the value of the attributes for those cells by imprinting his white INK onto them. The reason that doesn't happen in the last file I uploaded is because those cells - and all the Air cells - already have white INK. (Which also explains why there aren't any items in the cavern - they were there, but get automatically collected [like the one in JSW's Swimming Pool] in the first time-frame. And because there aren't any Water cells created to curtail Willy's fall, he plummets forever!* *Except that he doesn't keep falling forever! Leave it running for a while, and eventually (after approximately sixteen descents of the whole cavern), Willy's airborne status indicator will be incremented to a value of #FF - signifying death!!

Isn't that just because there's a wall in the top row, at either side of the screen?

Please find attached another variant which I quickly knocked up - open up the file, walk left off the end of the platform, and see what happens!! MM Fall Test Four.Tap

The simple explanation for the phenomenon is that when Willy is trascending the boundary between the bottom/top of the cavern, his white INK is permanently written over two pairs of cells at the top of the cavern. That changes the nature of those cells from background to floor cells (Air defaulting to Water cells). So he can stand/land on them! A further recording which I have just created (attached here) proves the point that the second cell-row down from the top of the cavern is also turned to Water, not just the top row. Under the Portal 3.rzx

I think I see what you're getting at. I've just created another recording (attached to this post), which I think illustrates the point well: Willy falls through the bottom of the screen on the first descent, but lands fatally on the second descent when he reaches the bottom of the screen. I'll explain when I have a bit more time, but it's nothing to do with the position of either the portal or of the Water platforms! (At least, not any of the red Water platforms that are present when the cavern is initialised!) Under the Portal 2.rzx

I think it will be a case here where your posts will make more sense once I've watched the recording!

Er, there isn't a floor underneath the portal??

I think I've figured out the reason behind the "sort of" comment highlighted in bold in the above quote from Norman Sword. My first attempt at the Funeral March caused a fixed number of oscillations of the speaker diaphragm. That meant that the higher the pitch, the shorter the delay between each oscillation and therefore the shorter the overall duration of the note. As Norman said, the tune routines play each note for a fixed period, in an attempt to make each note of equal duration. However, there is a slight over-compensation involved, because in reality each execution of the Z80 operation which causes the speaker to oscillate (i.e. each XOR #18) takes a short but finite amount of time (i.e. a certain number of T-States). This is usually insignificant in terms of the overall length of the notes, but when you have an extremely high pitch note, it can start to cause a perceptible increase in the duration of the note. In the previous test file which I uploaded a while ago - 'Game Over Test 3' - I used data bytes with value #01 in the table of Funeral March notes, in order to punctuate the tune. This means that the tune routine attempts to oscillate the diaphragm during each and every pass through the inner loop controlled by the B register via a DJNZ command (that's 256 times per pass through the outer loop, controlled via the C register). The cumulative effect is that those notes are sustained for slightly longer, and the descending foot perceptively slows down at those moments in the tune when the 'silent notes' are being played. I have now created a further test file - 'Game Over Test 4' - in which data bytes holding the value #00 are used to punctuate the Funeral March, instead of #01. The oscillation of the diaphragm now only occurs once for every 256 passes through the inner loop, which is only once during each pass through the outer loop (i.e. 256 times less often than before), so the cumulative impact of the T-States of time spent executing XOR #18 commands becomes insignificant. As a result, the 'silent notes' are of roughly the same duration as the notes of intermediate pitch, and therefore the foot descends much more smoothly (at an even pace) down the Game Over screen. I have attached to this post both of the files referred to above, for convenient comparing and contrasting of the Game Over sequence. Game Over Test 3.z80 Game Over Test 4.z80

Another significant milestone for the site! (Unless you're a hexadecimaphile like myself!!)

Unless they're overhead ones (like in the Wine Cellar) - I presume he can jump up and hit them (because his jump doesn't take him high enough to be 'above' the Fire cells)?

I was expecting that Willy could walk on Water cells (e.g. the floor of The Bathroom), but if he jumped up through them (e.g. the head-height platform at the bottom of the ramp in The Bathroom), then he would fall through (because they would turn to Air and then remain as Air) - but that is NOT the case (because it's only a 'secondary buffer' effect). I did anticipate that he could safely walk through Fire cells (in either direction?) - although he is still killed if he steps onto a Fire cell!

It's only affecting the secondary attribute buffer though - I was thinking it might turn cells through which Willy passes into Air, but that would involve changing the primary buffer (the primary is copied across to the secondary each 'tick', so the colour clash is actually only temporary). So it's not quite as 'quirky' as I had anticipated! :blush:

I haven't tried this out yet, but studying the code, it seems like it should have some interesting quirky effects: POKE #9623, 00

Oops, please ignore the above - when the game file is opened up in SPIN in 48K mode, page #5B of the code just holds values of zero! It is only when the file has been opened up in 128K mode that some seemingly random code manifests itself in that range of addresses. This seems to arise from the way in which the Spectrum 128K mode operates, rather than being newly-discovered remnants of source code as I suggested earlier. :blush:

From the Manic Miner disassembly: http://skoolkid.github.io/manicminer/reference/facts.html#sourceCodeRemnants Further to the above, I've just discovered that in Manic Miner the range of addresses #5B00-#5BFF also appears to contain remnants of source code. (In JSW, the upper end of that range of addresses is used by the program for the stack, but in MM the stack is located elsewhere.) Some editors such as JSWED 'tidy' up these addresses, so they appear to be blank in the hex editor. However, if you open up the game file in SPIN and then use the debugger to PEEK at those addresses, you can see the unused source code in situ.