IRF

You shouldn't have any trouble finishing it, especially with the Infinite Lives facility available in the loader (and the fact that we eliminated most of the IDS's). :)

Nice one Norman. The 'aura' fix is highlighted well by the 'printing press' guardian in the room 'Mondrain', because of that guardian's 'transparency'. The yellow 'bat' guardian also illustrates the fact that when guardians are passing through cells with a non-black PAPER setting, the BRIGHTness settings of the guardians are inherited from the cells through which they pass - rather than the other way round, as was the case in the original JSW. **** I'm guessing that the decision as to which variant of each room to display, at a given moment in time, is based on whether the 'tick' counter (#85CB in the original game) has an odd or even value (i.e. status of Bit 7 of that variable) at the point when Willy enters the room.

Unless, of course, you discover certain things that you haven't found yet! ;)

No worries. :-) A question for Andy, out of interest: did you ever make a complete recording of Jet Set Mini?

I guess what I'm asking is that if you do record an efficient recording, then please let us know as I'd like to have a go at beating your timing before you submit to RZX Archive. So it wouldn't cause too much of a delay between your making the recording and your submitting it (I'd just need to find the time to sit down and have a go at an efficient walkthrough myself). I think this is one of the few occasions where I might have a snowball's chance in hell of beating your completion time (but only because of 'insider knowledge'!)

I forgot to mention that I implemented the above (successfully) in 'Jet Set 40-40'. If I recall correctly, the out-of-situ part of the patch is located at #93BB-CB, just before the short Easter egg message 'ANDYF' in the code. (And in fact, reworking the Guardian Aura Patch enabled me to fit a five-character message into that location.)

Danny, if you do manage to find any such clues, please put any discussion of them in the following thread for now: http://jswmm.co.uk/topic/164-jsw-mini-contains-spoilers/page-126

Also, you might want to try out the POKES provided in the 'Mini' readme, which allow Willy to access the 'invalid rope' in 'Front Door' (if you haven't already).

Maybe let me know your completion time and I'll see if you've beaten mine yet? By the way, look out for a few 'clues' along the way...

I might release it as a 'bonus feature' alongside 'Willy's Recurring Nightmare'.

I believe I've had the best completion time for 'Jet Set Mini' to date (better than yours Danny!), but I'm not releasing the recording because it contains spoilers (there are aspects that even you haven't discovered yet!)

Thanks Norman, I've edited my post above as well accordingly.

There's a big chunk of unused addresses in the Manic Miner code at #934C through to #9CFF (although the very end of that is used for the stack). So you could either: - Use H=#12 (with the SET 7,L command retained), and insert the font characters at #9500 to #97FF; - Or have H=#13 (and replace the SET 7,L with a RES 7,L), with the font being stored at #9900 to #9BFF. Note that the SET 7,L command is at #92CE in the Manic Miner code (that's in the Bug Byte version, it may be different in the Software Projects variant although I don't think the differences extend that far).

"Mid-sprite bounce" it is then! :-)

IRF, on 25 Oct 2017 - 12:06 PM, said: Norman Sword replied: I meant to reply to this earlier but forgot. The Geoff Eddy patch which draws a single moving block (disassembly below) does actually work on the Master Screen, rather than the Working Screen, and so it does have to erase the previous block's position after it has moved. However, it does both of those things during every game loop anyway, which seems like it could be a waste of effort (causing a needless slowing down of the game), based on what you said above. The reason that the block has to be drawn to the Master Screen and not the Working Screen, is because the Patch Vector subroutine is CALLed from the Main Loop after Willy has been moved during each time-frame. So at the point in time where the 'Move Willy' routine tests for a solid platform underneath Willy's feet, the moving block would not yet exist if it was being created at the Working Screen level.

I've now managed to achieve the shared left-right code for horizontal guardians, including a mid-path bounce (a phenomenon which is best exemplified by the Monks in the room 'Gregorian Chant' in the 'total rewrite of JSW in 48k' project that was uploaded by Norman Sword - 'Gregorian Chant' is a very nicely presented room by the way!). This change used up most (but not all) of the bytes that had been freed up by combining left and right movement into a shared piece of code. Starting at #9133 (changes from my initial code are highlighted in bold): PUSH IX ; copy the address of Byte 0 of the guardian definition POP HL ; to the HL register-pair LD DE,#E0FF ; parameters for a LD B A,(IX+$06) ; guardian moving left BIT 7,(HL) JR Z, left LD DE,#2001 ; parameters for a LD B A,(IX+$07) ; guardian moving right left: LD B,A LD A,(HL) ADD A,D ; increment animation-frame of guardian BIT 7,(HL) ; sets the Zero Flag for a left-moving guardian LD (HL),A ; update guardian definition Byte 0 with correct animation-frame JR Z,carry_okay CCF ; Complement the Carry Flag for a right-moving guardian carry_okay: JR C,#91B6 ; not time to update the guardian's x-coordinate; proceed to Move the next guardian XOR #80 LD (HL),A ; time to update the guardian's x-coordinate, so reset the animation-frame to the first one for the next cell-column LD A,(IX+$02) ; guardian definition byte 2 LD C,A ; temporarily save in the C register AND #1F ; extract guardian's current x-coordinate CP B ; has the guardian reached the extremity of its range in the current direction of travel? JR Z,mid_path_toggle ; if so, jump to toggle the mid-path bounce on/off, and then reverse the guardian's direction of travel RLC D ; moving left, Carry is now set; moving right, Carry is cleared INC A ; adjust A to account for width of guardian(?) SBC A,(IX+$04) ; has the guardian reached a mid-path bounce point? ; [N.B. If you use a SUB command instead of a SBC here, then the guardian gets stuck at its mid-point!] JR Z, turn_around ; if mid-path bounce point has been reached, reverse the guardian's direction of travel LD A,C ; retrieve guardian definition byte 2 ADD A,E ; adjust x-coordinate LD (IX+$02),A ; and save JR #91B6 ; proceed to Move the next guardian mid_path_toggle: LD A,(IX+$04) XOR #40 LD (IX+$04),A turn_around: LD A,(HL) XOR #E0 LD (HL),A JR #91B6 ; proceed to Move the next guardian There are six spare bytes now remaining at #9179 to #917E. The mid-path bounce point is specified by the guardian's (previously unused) definition Byte 4. EDIT: Perhaps the term 'Intermediate Bounce Point' is more appropriate; it doesn't necessarily have to be mid-way (i.e. halfway) between the leftmost and rightmost extremities of the guardian's horizontal range. (N.B. If you have a quirky guardian which wraps round past the edge of the screen, then set IX+$04 = #80 to avoid an inadvertent mid-path bounce caused by the default value of zero for Byte 4.)

For reference: http://jswmm.co.uk/topic/390-a-test-file-for-jsw/?p=8162 I presume that after the first of each pair of arrows is drawn, IX is incremented and then the arrow-drawing code is repeated for the other half of the pair?

Yes, I think just black would be suitably sombre. EDIT: For what it's worth, I've just re-uploaded the file with the above suggestion implemented (attached to original post on previous page of this thread). If anyone should be apologising for taking the thread off-topic, it's me, as this doesn't really have anything to do with Norman Sword's original post/attachment (I'm not sure how I ended up diverting it with this particular micro-project!)

I also noticed that there are apparently random changes to the layouts of the first few rooms! (Oh, and by the way there's a typo in the end-of-game message: "Stike a light, what happened?")

Cool! (And nasty for Willy!) How many of the room's eight guardian slots does that take up?

An arrow's y-coordinate can be determined on an individual arrow-instance basis, via its specification byte 1 (which is copied to definition byte 2 in the current room's guardian buffer). However, Bit 0 of that specification byte is effectively unused - it must be left clear, or else the arrow when drawn will corrupt the game file at run-time (because erroneous addresses are looked up from the table at page #82 of the code - that's what caused the infamous Attic Bug). In the arrow-drawing code, the following command picks up Byte 2 of the arrow definition as follows: LD E,(IX+$02) If that were to be replaced with: LD A,(IX+$02) AND #FE LD E,A then this would prevent any accidental occurrences of 'Attic Bug' style problems caused by an odd value being assigned for an arrow's y-coordinate. Furthermore, Bit 1 of the arrow's y-coordinate specification byte could then be used for other purposes. (There are plenty of other unused entries in an arrow's definition, but those are all set on an arrow class basis, so they would hold the same values for all left-moving or all right-moving arrows in the original game.) As an example, you could introduce a check, just before making the arrow warning sound when the arrow is about to enter the current room - if Bit 0 of the arrow's definition Byte 2 is set, then bypass the code which generates the firing noise. So in some rooms, Willy gets an audible warning of an impending arrow, but in other rooms he does not!

Incidentally, the aforementioned Overflow Flag also doubles up as the Parity Flag. I have wondered for some time about a possible viable use for the Parity Flag. And I've now discovered one, which relates to a possible efficiency for one of Dr Andrew Broad's patches from his 'Advanced MM/JSW Trainer' project. From the accompanying TECHNICA.txt document for that project: The three commands in bold above (six bytes) can be replaced with a three byte jump JP PE,skip which responds to the conditionality of the Parity Flag (thus saving three bytes). N.B. In this circumstance (after the AND #21 gate), the Parity Flag is set if a cell's row and column numbers are both even, or if they are both odd. If the row number is even but the column number is odd, or vice versa, then the Parity Flag is cleared.

My third and final attempt at the 'Funeral March' is implemented in the attached. B) (Apologies to Norman Sword for hijacking this thread somewhat!) Game Over Test 3.z80

However, the following method eliminates the need to Complement the Carry Flag. Starting at #9133 (changes from previous code highlighted in bold): PUSH IX ; copy the address of Byte 0 of the guardian definition POP HL ; to the HL register-pair LD DE,#E0FF ; parameters for a LD B A,(IX+$06) ; guardian moving left BIT 7,(HL) JR NZ, left LD DE,#2001 ; parameters for a LD B A,(IX+$07) ; guardian moving right left: LD B,A LD A,(HL) ADD A,D ; increment animation-frame of guardian BIT 7,(HL) ; sets the Zero Flag for a left-moving guardian LD (HL),A ; update guardian definition Byte 0 with correct animation-frame JR Z,carry_okay CCF ; Complement the Carry Flag for a right-moving guardian carry_okay: JP PO,#91B6 ; not time to update the guardian's x-coordinate; proceed to Move the next guardian If we get here then the Overflow Flag has been set (for both directions of travel) XOR #80 LD (HL),A ; time to update the guardian's x-coordinate, so reset the animation-frame to the first one for the next cell-column LD A,(IX+$02) ; guardian definition byte 2 LD C,A ; temporarily save in the C register AND #1F ; extract guardian's current x-coordinate CP B ; has the guardian reached the extremity of its range in the current direction of travel? JR Z,turn_around ; if so, jump to reverse its direction of travel LD A,C ; retrieve guardian definition byte 2 ADD A,E ; adjust x-coordinate LD (IX+$02),A ; and save JR #91B6 ; proceed to Move the next guardian turn_around: LD A,(HL) ; we're not updating the x-coordinate after all, XOR #E0 ; instead we are switching to consider the other set of four animation-frames LD (HL),A ; [assuming it's an eight-frame bidirectional sprite; if not, then filtering out of unwanted frames is done at the 'Draw the guardians' stage] JR #91B6 ; proceed to Move the next guardian [#9166 to #917E is now free - that's four more bytes than with previous method] This effectively reverses the status of Bit 7 of the guardian definition Byte 0, so that Bit 7 cleared = Moving Right, Bit 7 set = Moving Left. ;right adding #20 #00, #20, #40, #60 The Overflow Flag is clear with each addition but not #60+#20 = #80 (which is minus #80 in two's complement) ;left adding #E0 (minus #20) #E0 (minus #20), #C0 (minus #40), #A0 (minus #60), #80 (minus #80) Overflow clear with each addition but not #80+#E0 = #60 N.B. You would now need to adjust all the horizontal guardians' data as follows: - Transpose all the half-pages of the eight-frame bidirectional horizontal sprite (e.g. put right-facing Monk at #B400-#B47F, and left-facing Monk at #B480-#B4FF), so that their sprite-frames are arranged within the data in the same way as Willy's - if you don't do this, then they'll all walk backwards!; - Toggle Bit 7 of Byte 0 for all the horizontal guardian classes (i.e. all the relevant entries in pages #A0-#A3), in order to preserve the initial direction of travel upon Willy's entry to each room (e.g. for the green rolly thing in The Bathroom, change the value of #A1D8 from #01 to #81). All of the above is probably not worth the bother just to save another four bytes in the 'Move the guardians' routine. (Although it will save a few more bytes in the 'Draw Willy' routine as well, because there's no longer a need to swap half-pages when using the Flying Pig as the playing sprite in The Nightmare Room.) It was more of an interesting academic exercise to me, and it allowed me to gain a better grasp of the functioning of the Overflow Flag. :)

It could appear to be an unnecessary duplication by toggling Bit 7 twice (which would leave it back where it started), but if you consider the possible paths through the code, this doesn't always occur. The XOR #80 is used when the animation frame has been incremented/decremented beyond the range of appropriate values for the current direction of travel (i.e. to bring it back into the correct half of the sprite-page). The XOR #E0 is used at the point when the horizontal guardian changes direction. It's effectively doing two things simultaneously: a XOR #80 (to swap to the other half of the sprite-page), and a XOR #60 (to toggle between left-most and right-most sprite-frames, without which the turnaround doesn't occur as smoothly). You've hit the nail on the head. In the original code, the conditionality of the Carry Flag happens in the same way for both direction, but that's because left and right movements are handled via a SUB #20 and an ADD #20 respectively. But here we're using the same operation (an ADD), but changing the operands for left (#E0 = - #20 in two's complement) and right (#20 = +#20 in two's complement). Which means that the effect on Carry is polar opposite for left and right motion, so we have to use a CCF.