IRF

I seem to recall ages ago Stuart (Zub) suggesting that the item might have been meant for another room, but eight rows lower - since the item definition byte which holds the room number also tells you which half of the room it is located in. i.e. a single POKE would still put it back in its place. I can't recall whether anyone ever investigated that possibility though?

The former would be more consistent with the 'second attempt' message.

The I register is something different I think (and is still a bit of a mystery to me - it controls the Interrupts). I was referring to the IX and IY register-pairs, which work just like HL, but you can specify bytes at a specific offset from the 'origin'. e.g. look at how the guardian code works. You access them by using a 'shift byte' in front of the regular Z80 operation byte ('DD' for IX, 'FD' for IY). :)

I just tried the above and it works fine! :) The IX (and IY) registers come into their own when you're reading and/or updating a sequence of consecutive bytes (such as an ASCII string), or using a lookup table (such as #8200-FF), or when you're dealing with the likes of the guardian buffer (addressing each eight-byte definition in turn, to move or draw the guardians). The ability to use an offset-byte operand saves you from having to constantly redefine the index pointer. But the 'Print a message' routine doesn't do any of those things, it just uses IX like any other register-pair to hold an address (the start of a ASCII message). I suspect the only reason Matthew didn't use HL is because that also is used by the subroutine which prints each character in turn. But PUSHing and then POPping HL gets around that. ;)

The inactivity timer code is fairly unnecessary in this day and age.

The 'Print a message' routine at #9680 uses the indexed IX register-pair to point at the start of the message to be printed. However, I believe it would be more efficient to use the HL register-pair instead. The only pitfall is that 'Print a message' calls 'Print a single character' (#9691) as a subroutine, which uses HL. But if the CALL to #9691 from #9683 was bookended by a PUSH HL and a POP HL, then the three-byte LD A, (IX+$00) command at #9680 could be replaced with a single-byte LD A, (HL) command. So far the code changes are 'byte-neutral'. But it would allow further efficiencies throughout the program. For starters, the INC IX at #9686 could be replaced with INC HL (saving one byte). But it would allow all the commands which set up IX prior to a CALL to #9680 to be replaced with commands that set up HL. This removes the need to use the 'DD' shift-opcode, and in some instances the offset byte operand. e.g. at #8835, #88C8, #8965, #8971, #8A31, #8A3D, #8CCB and #8CD7, you could replace the four-byte LD IX, $0000 commands with three-byte LD HL, $0000. (Although the commands in red are already ones that I have identified as potentially redundant, because those routines print two messages in quick succession which are stored in adjacent addresses in the code, so IX [or the suggested HL] will already point at the correct location to pick up the message.) At #88CF, the two-byte ADD IX, DE could be replaced with a single-byte ADD HL, DE. Some of the above changes could be very useful in freeing up bytes in tight spots in the code (such as the Main Loop). :)

The same is true of the four-byte command at #8CD7-8CDA.

I guess the 'vertically-rolling' screen only works in black-and-white, or else the attributes would sometimes be noticeably non-aligned with the graphical bytes that they are supposed to be associated with. (Unless it rolled down by a character-row at a time, as opposed to the smooth rolling by pixel-row.) But the black and white fits the 'nostalgia' theme, so it's all great!

Thanks for those, NS. :)

I was wondering why some of the room numbers ended with a digit, from '3' to '6', and also where '1' and '2' might be? I imagine that 'Demolition Site-bomb Blast' and 'Demolishing this place soon' would have been '1' and '2' respectively? Looking at the screenshots during 'attract mode', each of the two inaccessible rooms does have one item, so it seems that I got as close as is possible to completing the game last night (without POKING to move Maria out of the way - but even that might not be an easy task if the pertinent addresses in the code have been altered from the original). How easy would it be to extract the code which causes a particular room's special effect? e.g. 'Nostalgia' or 'Mine Entrance'? Sounds intriguing and fiendish in equal measure! It would be a shame if such a guardian didn't see the light of day at some point... See 'The Nightmare Room' in 'Jet Set Mini' for a room that has two independent animated conveyors (located in different cell-rows, although they both animate in the same direction). Also, the conveyor in the same game's 'East Bedroom' is animated at pixel-rows 0 and 2 (as per usual), and at pixel-rows 5 and 7 as well. (Both of which are achieved by calling the 'Animate the conveyor' routine every tick, with a later entry point than the usual #94F9.)

I've collected 192 items, and I can't see any more in the layout, but Maria is stubbornly refusing to budge! :huh: EDIT: Looking at the list of rooms, there are two I haven't discovered yet: 'Demolition Site-bomb Blast' and 'Demolishing this place soon'. Any clues as to which part of the layout they might be found in?

I just reached The Forgotten Abbey during Willy's last remaining life. I believe it is impossible to complete the screen (collecting the item) without sacrificing a life, and therefore it was Game Over for me! In original JSW, Willy has to walk leftwards through a wall block at head-height - the one sticking out just below the item - in order to get back down again afterwards. Because you've made Willy's movement symmetrical (and more logical with regard to wall tiles), that is no longer possible. Replacing the single protruding wall block with a floor block would resolve this problem. EDIT: Actually, after a rollback, I managed to collect the item and jump through the wall block in question via a single, perfectly-timed jump. (I had assumed that you had eliminated such quirky jumps.) However, you only get one go at the jump; if you mistime it, there is no chance to try again because Willy can't drop down onto the conveyor and walk back far enough (against the flow of the conveyor).

Here is the 'Fat Rope' test file - this is comprised of just two ropes, so it runs faster. The Fat Rope is exactly centred horizontally in the room. Fat Rope Test.z80

If it's the room I'm thinking of, I did think it led to an unfair 'Infinite Death Scenario' when Willy walked in. But I did manage to make it across the room, by jumping rightwards from the rightmost edge of the room to the left, which allowed Willy to just about land on the conveyor. He then fell off the other end of the conveyor, but safely fell down and appeared at the top of the same room. It sounds like that was probably a bit of a shortcut, and Willy is supposed to climb his way up to the top of that room? ****** As for why the floor disappears, could it be because the attribute of the floor is set to the same as the air cells?

Incidentally, aside from the perhaps frivolous 'composite ropes', as seen in the test files above, the ability to set a rope's horizontal position at the individual pixel level could be useful for fine tuning a difficult game, where you want to ensure that a tricky jump onto or off of a rope is just about possible (if the player gets the timing exactly right), without actually becoming impossible!

I'm quite pleased with my successful implementation of the patch to 'Draw the Ropes', so that each rope's exact pixel-position can be specified on an individual basis. Firstly, the use of the XOR command to separate out, in a byte-efficient manner, the two components of a rope's definition byte 2 (i.e. the starting column in Bits 0-4, and the pixel-position in Bits 5-7). Secondly, the use of the SCF and RRA commands and a DJNZ loop, to convert Bits 5-7 in order to infill the appropriate pixel (set the correct single bit), in the graphic byte where the top segment of rope appears. I'll type up a disassembly when I get a chance. :)

There are some cool special effects in there - particularly the room where Willy is upside-down, and the one which looks like an old black & white TV set in which the picture drifts vertically - I was almost tempted to thump the top of my PC to see if it would fix it! :lol:

I noticed that the movement keys to climb up or down a rope have been reversed (in relation to the direction that the rope is swinging at a particular moment in time). That takes a while to get used to!

I've made a minor variation to the previous file - see the attached. The patch* has been re-written slightly more efficiently, saving three bytes. And in the test room I've put all eight ropes into adjacent pixels (the top segments are all located within the same cell-column, although they could just as easily have straddled two columns), so the composite whole now resembles a swinging rope ladder. That can be scaled back to achieve a 'fat rope' by having, say, just two ropes sitting adjacent to each other, one pixel apart - which would have the benefit that it doesn't slow the game down to the same extent (as well as only requiring two guardian instances, of course). EDIT: *I forgot to say last night: the patch for this and last night's test file is contained in a subroutine at #9718 (which is CALLed from #92AC, near the start of the 'Draw the Ropes' code). Swinging Ladder Test.z80

I must admit that the 'new' Solar Beam is the least developed of the four 'Specials', as all I did was fix the bug which means that sometimes it doesn't kill you instantly when the air supply runs out. However, In terms of enhancing the Solar Beam with something 'a bit different', Norman Sword has come up with the goods in his Manic Miner rewrite by giving the Beam a neat 'sapping' sound effect whenever Willy stands inside it. :o ****** Another thing which I should mention is that, in order to achieve the maximum flexibility in the 'Skylab/Droplet regime', I had to redivert one of the Eugene Guardian Types to a different number (i.e. a different value for Definition Byte 0). Non-colour changing Eugenes are now classed as JSW64 Special Guardian Type #48 instead of Type #18. Type #18 was reassigned for use by leftwards-moving Skylab/Droplets. This was essential in order to prevent the 'Draw the guardians' routine from picking up incorrect frames of animation for some of the Skylab/Droplets. (Type #08 is used for rightwards-moving Skylabs and for 'horizontally static' Droplets, whilst Type #78 has been freed up for other purposes. Previously, Type #08 was used exclusively for 'standard' Skylabs, and Type #78 was used by John Elliott's original Droplet Patch.)

Please see the attached test file. PREAMBLE: In 'Jet Set Mini', I managed to implement perfectly laterally-inverted ropes, partially by changing the position of the top segment of each rope within its host cell. (i.e. In original JSW, the top rope segment occupies the leftmost pixel in the defined start-column; whereas in 'Jet Set Mini' the top rope segment occupies the rightmost pixel.) This test file extends that concept further. I have slightly rewritten the 'Draw the Ropes' routine, so that the precise horizontal pixel-position of the top of each rope in the game may be specified separately. i.e. on a 'rope instance' basis. The pixel position of the top segment is stored in the highest three bits* of Byte 2 of the Rope Definition (which is copied over, from the second byte of each rope's specification in the room's guardian list, when the 'Room Setup' routine is executed). The value of that three-bit number is then translated into the correct pixel to infill for the top segment, using a similar principle to that which is used in Manic Miner to draw the remaining pixels of air supply at the right-hand end of the air bar (except that I've used the RLC E command here, instead of RRC E, and there is no setting of additional bits during each pass through the DJNZ loop). Within the the start-up room (Swimming Pool) in the attached file, there are eight** ropes which are very closely spaced horizontally (only three pixels apart). I have called this effect a 'Swinging Curtain', as that's what I think it looks like! Note that the game is slowed down somewhat in the room in question, because of the need to perform eight complex rope-drawing operations during each time-frame. ****** * One consequence of this change is that you lose the ability to create an 'Invalid Rope' like the one in the 'Overgrown MegaTree' in 'Jet Set Mini' (the top segment of which is drawn further down the screen than is usually the case, because I assigned an 'invalid' value [greater than #1F] for the x-coordinate of the top segment of rope, in the room's guardian table). However, that's probably not a great loss - Invalid Ropes can be very 'quirky', especially if they extend down beyond the boundary between the top and bottom half of the playing area, which causes segments to appear in strange places (the one in 'Jet Set Mini' is sufficiently short to prevent this from happening). ** Note that because there are eight ropes present in the room, it can be quite difficult to dismount the ropes/curtain! The 'Draw the Ropes' routine usually allows Willy 16 time-frames to elapse, after jumping or falling off a rope, before he can be caught by a rope again. However, with eight ropes being drawn consecutively in each time-frame, that reduces to two time-frames! (Although that is not a result of the changes that I made in the attached; it is a curious feature of the JSW game engine, and would be the case in any JSW room with eight ropes.) Swinging Curtain Test.z80

The new sound effects are good, particularly the one which occurs when Willy stands in the Solar Beam. :) Incidentally, I notice that you have fixed/eradicated/prevented the bug in the original Manic Miner which meant that Willy didn't always die as soon as the air supply ran out if he was standing in the Solar Beam at the time. (i.e. The final character of air could reappear, and be re-depleted, several times before the air supply - and Willy! - finally expired.)

Okay, 'patch' wasn't the right word - I was going to say 'bug fix' but I wasn't sure that the 'Jagged Finger' effect is classed as a 'bug'? (You originally referred to it as a 'flaw'.)

Am I right in thinking that you've implemented the patch which re-orders the way in which the graphical bytes and attributes are copied across from the buffers onto the physical screen? The 'Jagged Finger' effect is much less pronounced, and the attributes don't seem to lag behind the graphics to the same extent. This is particularly noticeable in 'Eugene's Lair', where previously Willy's head/feet, and parts of the yellow toilet guardian, could momentarily be observed to turn black at times (because the background INK in that cavern is set to black, whilst the background PAPER is non-black), but now that phenomenon is almost eliminated. :)

The alternative style of jumping and movement is similar to that found in JSW2, I believe? (e.g. the ability to turn around more quickly in between sideways jumps in opposing directions.) Although I don't think it is identical to JSW2 movement? (In JSW2, Willy progresses an additional frame of animation at the end of a sideways jump, in contrast with JSW/MM, or with this MM remake.)