IRF

As an early Christmas present to the jswmm community, this project has been updated with the addition of a 'Mega Bonus' Cheat Mode (activated during the loading process by pressing $ whilst the BASIC loader is being executed). This allows you to accrue even higher scores than in the 'Big Bonus' edition! Who will be the first person to score a million points, I wonder? B)

To fix the 'Sticky Bed' bug: POKE 58326,254

There's an inconsistency in the previous post - is the game called "Still Stealin'" or "Steal Stealin'" (or maybe "Steel Stealin'")?

I just posted a new message on the Yahoo group with no bother. ?

Actually, there's probably no need to pause the game at all is there really? Just hit the 'Print Screen' button whilst the game is running on your emulator, then paste into MS Paint (or whatever), crop the image and save it as a JPEG/PNG/whatever. That's what I tend to do (and, like you, take another one if there's an obvious glitch).

It should be accessible by pressing all the keys from 1-6 along with the 9 key (111111 in binary = 63 in decimal). It's only when you go beyond that that you would need to pick up an additional number key. However, depending on what emulator you are using, not all number key combinations are always possible... Another possibility would be to POKE the value of the room number (33824/#8420) to a value of 63/#3F. But then you might (or might not?) enter an IDS before the screen layout is refreshed! [in the same way that POKING the room number in order to try and access The Bathroom can initially cause the toilet to appear in the room you are attempting to teleport from - guardians can even crash into the toilet in such circumstance, killing Willy! - but then the room is refreshed after losing a life, taking you 'properly' to The Bathroom.] ...Anyway, the room name "How on earth did you get here ?!" is very appropriate, it seems! There's also a room called 'Cheating?' in Jet Set 40-40, although you haven't yet created a suite of screenshots for that game in any case.

If you pause the game using the emulator's pause function, then you might chance upon a moment during flow of execution when sprites have only been partially updated - something which Norman Sword refers to as a 'jagged finger' effect, except in this circumstance it would be frozen in time (and therefore very obvious), rather than being an instantaneous (but visible to the keen eye) flicker. Ditto with the updating of the colour-attributes - if you pause at a moment when the pixels have been updated during the current time-frame but not yet the attributes, then you could for example have arrows drawn in an INK colour other than white [assuming the engine isn't hacked for non-white arrows anyway], if the screen in question has Air cells with non-matching INK and PAPER colours [which is usually the case with rooms that have a rope]. So I personally think that pausing the game using the in-game pause button is a more sound approach in order to capture a comprehensive screenshot - but you then have the problem (usually) that the screen colour-cycling kicks in before long. So I would say that a combination of pausing in-game, and then hitting the emulator's pause button before the colour-cycling commences, would probably be the best approach for grabbing screenshots. The quote above appears contradictory to me - I'm not sure whether you're saying that you do include screenshots of rooms that are only accessible by WRITETYPER, or whether you don't tend to include screenshots of such rooms in JSW Central? EDIT: By which I mean, the 'Correction' does not appear to contradict your original statement, despite being labelled a 'correction'! However, the entry for 'Jet Set Mini' certainly does include a screenshot of the unaccessible (other than by using WRITETYPER) room called 'Cheating?' But in that case, accessing the room does not necessarily cause an Infinite Death Scenario [unless you happen to teleport into the path of a guardian], although it does cause Willy's INK colour to turn yellow - with the consequence that even if you teleport back out of that room and back into the mansion, Willy can no longer collect items - a suitable punishment for trying to cheat! I would add that, depending on what causes the instant death, a screenshot captured by pausing the game within such a room may or may not show the full picture. e.g. if Willy collides with a guardian that appears early in the guardian list for the room, and is therefore drawn first, then later guardians in the list would not be displayed. If Willy hits a Fire cell (or if all the Air cells in the room are effectively Fire cells, because the attributes for Air and Fire match), then no guardians will be drawn at all, because the Main Loop reacts to Willy hitting a Fire cell before it gets chance to CALL the Draw the Guardians routine.

Obviously there was a typo there (in my previous post; now corrected). Although the notes do sound as though they are suffering!

In the post linked to below (and the files attached to that post), I experimented with the Manic Miner theme tune. The 'pulse wave difference' which Norman refers to is caused by Mathew selecting pitch values for pairs of notes (the second and third byte in each group of three bytes which define the tune) that differ by a value of 1 (on the original game). Giving a disharmony quality to those notes that differ by 1. In the attached experimental files (see link), I changed those notes so that they differed by a value of 2/4/8/16. The resultant 'magnitude of disharmony'* increases accordingly. (*A good Manic Miner room name, perhaps?) http://jswmm.co.uk/topic/458-free-space-and-code-optimisation-in-manic-miner/page-2?do=findComment&comment=10459

Actually, I've just noticed that the author of the above link is none other than J.G. Harston, occasional visitor to this parish! I wonder if Jonathan will read this, and if so, would he be able to explain the rationale behind the format of the operands which I referred to above?

Further to the above, the Z80 Heaven website which I quoted makes no distinction between the number of T-States for LD HL, (xx) or LD IX, (xx) hl, (XX) 20 ix, (XX) 20 iy, (XX) 20 (XX), hl 20 (XX), rr 20 (XX), ix 20 (XX), iy 20 Clearly the source I quoted is wrong (and Norman's source was right), because the shift byte inevitably slows down the operation (by 4 T-States). The Z80 Heaven site also fails to give a T-State value (correct or otherwise) for LD rr, (XX) operations e.g. LD BC, (XX). Which presumably does take 20 T-States because again there's a shift opcode involved. (EDIT: Another source confirms this: http://z80.info/z80flag.htm ) **** An unrelated query: I've often wondered? why the operand of relative jumps is sometimes given in the format &4546 e.g. at http://www.z80.info/z80oplist.txt you see these examples: 10 DJNZ &4546 18 JR &4546 etc

I forgot to add: the hidden message disappears when you exit from The Nghtmare Room of course, because the status bar's pixels are all wiped clear by the Room Setup routine upon entry to another room. But walk back into the Nightmare Room and the message will re-appear [unless you paused the game in the intervening period], because the status bar's attributes are NOT cleared by the Room Setup routine!

I've just noticed that the two commands in the raster copy routine which you previously struck through: ld b,0 ; this was set for usage in a different routine ld c,32 ; this was set for usage in a different routine are no longer struck out in posts 59 and 60. Although the accompanying comment after the semicolon remains in place, suggesting that those commands are still not necessary (and from my interpretation of the code, they aren't needed). Perhaps the strikethrough font 'fell off' in the process of copying and pasting? **** The LDI subroutine in post 60 gets around the problem in the 'Lose a Life' routine (#8C01), whereby the screen attributes are updated repeatedly on a loop, whilst the A register is used to count down the INK colours (the 'fade to black' moment). :)

Sorry, crossed wires - when you suggested "modify[ing] this routine to use a similar raster copy routine as the one posted above", I thought you were referring to amending the substantive raster routine, rather than self-modifying the subroutine to truncate it with a RET. Hence my reference in my previous post to: "if you are using a shared (and not self-modified) subroutine". ...except before and afterwards, where 'A' is used to self-modify the code (toggling an early RET in and then back out again). But I think that could be done using HL as a pointer instead (if necessary?): LD HL, S_M_C_New_Mod LD (HL), $C9 ; ;opcode for RET and LD HL, S_M_C_New_Mod LD (HL), $EA ;opcode for JP PE,xx

Surely the raster copy code would have to revert back to your earlier method of using the Accumulator to keep track of when it is time to copy a row of attributes. Because if you are using the shared (and not self-modified) subroutine Shift_block32, then that subroutine always RETurns with the same conditionality of the Overflow Flag. e.g. use the same code as in this post, only replacing the two LDIR commands with CALLs to Shift_block32: http://jswmm.co.uk/topic/299-file-jsw-jagged-finger-effect-demo/page-4?do=findComment&comment=6069

As I recall Danny, your preferred route through a standard Jet Set Willy 'mansion layout' (which this game has, broadly speaking, albeit laterally inverted) leads you to complete The Nightmare Room last of all, before making your way to the Master Bedroom for the Toilet Dash. Now, in Jet Set Mini, there is a double-height 'periscope' guardian in 'First Landing', which you can jump over from a high vantage point on the First Landing ramp in order to enter The Nightmare Room. But you can't jump back over the periscope if you exit from The Nightmare Room into First Landing. So that is - apparently - a one-way route, which appears to force you to go from The Nightmare Room via a circuitous route through The Banyan Tree, down the Back Stairway and through the Kitchen screens and the Main Stairway.

The wall in The Nightmare Room appears to be entirely solid. However, upon entry to the room, a Room Setup Patch overwrites part of the wall with a different attribute value to that assigned to the rooms' Earth blocks, creating a pair of 'pseudo-Earth cells'. You can see the same process going on in the adjacent room 'The Banyan Tree', where there is another 'pseudo-Earth cell' (just under the ramp and above/to the left of the Barrel sprite). Note that this 'pseudo-Earth cell' has the same pixel pattern as the regular Earth cells, but a different colour attribute, meaning that Willy can pass through it [in either direction; not just because of the asymmetrical test for head height Earth blocks] - bear in mind that Water cell behaviour is the default status of all non-standard room blocks. However, whilst the pseudo-Earth cell in The Banyan Tree is visibly a different colour to the rest of the Earth cells, that is not the case in The Nightmare Room. Because in that room, there is also a Main Loop Patch which colours the two pseudo-Earth cells (at the level of the secondary attribute buffer) back to the same colour as the regular Earth cells! So there is no visible difference between any of the Earth cells. (The pixel patterns being identical because the pseudo-Earth cells started off as regular Earth cells, and the Room Setup Patch is implemented after the room data has been decompressed and the pixels for the block types have been expanded out.) But these pseudo-Earth cells behave differently, in terms of their ability to block Willy from passing through them [or in this case, their lack of being able to do so - Water cell behaviour being the default status of all non-standard room blocks], because the Main Loop Patch is implemented after the 'Move Willy' routine has been CALLed from the Main Loop. So at the moment when 'Move Willy' is executed, these cells hold a non-Earth attribute value 'behind the scenes', which is then overwritten by the Earth colour attribute prior to the physical screen update (so what you see, apparently, is regular Earth blocks). And then during the start of the next pass through the Main Loop, the cells in question are restored back to their default Water behaviour, when the primary attribute buffer is copied to the secondary attribute buffer (only for those cells to be 'disguised' again, after the next execution of 'Move Willy', by the Main Loop Patch. And so on.) **** All of the above led me to include this credit in the Readme file for 'Jet Set Mini': EDIT: You may also notice that there is another 'disguised' cell in 'The Banyan Tree': the cell underneath the uppermost item is a 'pseudo-Water cell' (it has the same pixel pattern as the regular Water cells, but with a different colour attribute) - but here it unexpectedly behaves as an Earth cell! At the level of the primary attribute buffer, this cell has the same red/yellow colour attributes as the Earth blocks (thanks to a Room Setup Patch), but that is then overwritten by the Main Loop Patch, giving it the cyan colour you see that distinguishes it from the regular, darker blue colour of the Water cells in the Banyan Tree.

Explanation for Point 1 above: The message in 'The Nightmare Room' is printed across the top of the status bar, upon entry to the room. However, by default, the top character row of attributes for the status bar (addresses #5A00-#5A1F) hold the value zero. So the message is printed in black INK on black PAPER, and thus is normally invisible. **** Now, you may recall that in the Kitchen diptych of rooms, a flickering screen effect takes place - as you climb up through that pair of rooms, the screen flickers first in yellow, and then in red (it's hot in the kitchen, and heat rises!) That flickering effect is implemented by overwriting the physical screen attributes (addresses #5800-#59FF) with yellow or red INK during each game tick. (As opposed to the 'standard' screen flash [such as you see in Manic Miner when you gain an extra life], which is implemented by overwriting the secondary attribute buffer (addresses #5C00-#5DFF) before the secondary buffers are copied across to the physical screen.) However, when I wrote the patch for the Kitchen screens, I made sure that the overwriting of the screen attributes 'overshoots' the range of addresses that you would expect - instead of a LDIR length of #0200 (or rather #01FF) for the sixteen character rows of attributes of the playable screen, I used BC = #021F for the length of the LDIR loop, so it covers seventeen character rows. This causes the yellow or red INK also to be spread across addresses #5A00-#5A1F - although this is not noticeable in the Kitchens (because nothing is printed across that character row's pixels in that room). Now, unlike the top two-thirds of the screen attributes during the Kitchen flickering, which are all refreshed during the next tick of the game, the overwriting of the top character row of the status bar's attributes is semi-permanent. Therefore if you climb up through the Kitchen screens, emerge in the Banyan Tree and then proceed into The Nightmare Room, then the previously invisible message in that room becomes visible! (In red INK - although if you climb halfway up the Kitchen screens until the yellow flickering occurs, but then abandon that route and instead make your way back up the Main Stairway to approach The Nightmare Room from the other direction, then you can actually see the message printed in yellow INK!) **** Note that I said the change in colour of the top character row of the status is semi-permanent. If you abandon the game and start another game, then the black INK of that character row will be restored and so the Nightmare Room message reverts to invisible. The same is true if you pause and unpause the game ('in-game', so to speak, using keys A-G), since the Main Loop compensates when you come out of a pause for the colour-cycling which takes place during the pause, by restoring the attributes of the whole of the status bar back to their default values. (See #8B07-#8B11.) So if you try pausing and then resuming the game in The Nightmare Room at a time when the 'hidden' message is initially visible, you'll notice that the message promptly disappears - even if you don't actually pause for long enough for the colour-cycling effect to begin.

Sorry if the above typo caused any confusion! :wacko: BTW, thanks for checking your code in post 49 works okay. :)

I was just thinking in terms of the code which copies the 'master copies' to the 'working copies' [for pixels and for attributes], which would run faster* as you originally wrote it, with the countdown of raster lines embedded within the subroutine containing the chain of LDIs. (*For the reason which I outlined earlier today - despite my initial thoughts last night - that you only have to CALL the subroutine once for the pixels and once for the attributes. Whereas putting the loop counter commands in the Main Loop, as I suggested in post 54 44, means that you have to have execute multiple CALLs and RETs for copying each raster line in turn.) I assume that your 32-LDI subroutine is available as common code for both purposes [master buffers -> working buffers, and then working buffers -> physical screen]? It would seem wasteful to have 32 x LDI / RET in one subroutine, and a separate subroutine which goes 32 x LDI / DEC A / JR NZ / RET.

Thanks for that explanation, Norman! Going back to your version of the LDI method, did you manage to get it to work in conjunction with the Jagged Finger fix (with the rows of attributes being updated alongside the associated pixel-rows)? Because if your subroutine is in the format (as you explained previously): BLOCK_MOVE32: rept 32 LDI endm DEC A JR NZ, BLOCK_MOVE32 RET ...then the DEC A would affect the Overflow Flag, and therefore the JP PE,n_raster in the main routine wouldn't be responding to BC having counted down to zero, but to the decrement of A to zero (and thus the Overflow Flag would always have the same status when the code RETurns back to the main routine). How do you get around that?

On reflection, if I did want to use the same subroutine in the context of overwriting a block of code with a single value (e.g. to implement the Screen Flash effect), then it could be done like this (at the cost of five more bytes): ; 16 character rows to colour, so use A=#0F (15 in decimal) for the later loop. LD HL, xxxx LD DE. xxxx +1 ; No need to define BC; it's not used now LD (HL), colour_value ; Either copied from A, or a fixed value specified here LD A, #01 CALL subroutine_late_entry LD A, #0F loop: CALL subroutine DEC A JR NZ, loop subroutine: LDI subroutine_late_entry: rept 31 ; I presume "rept y" means 'repeat the following code (up to the end marker) y times'? LDI endm ; I presume this means 'end marker'? RET

Thanks Norman! I believe that relies on the fact that the LDI command resets the Overflow Flag if (and only if) the value of BC reaches zero after the operation?

Compare and contrast (for each pass through the Main Loop): Primary to secondary pixel buffer = 128 raster lines Primary to secondary attribute buffer = 16 character rows So my method uses 144 CALLs and RETs. Norman's method only requires 2 CALLs and RETs (for the pixel loop and for the attribute loop). Unconditional CALL = 17 T-States Unconditional RET = 10 T-States So the difference in T-States is 142 x 27 = 3888 T-States (the amount by which Norman's method is faster than mine). [There should be no difference in terms of the copying of the secondary buffers to the physical screen, because the Jagged Finger fix means that the data isn't copied contiguously (in terms of the way that it is stored in memory). So there are separate CALLs to the subroutine for each individual raster line, in both Norman's and my method.] **** However, that 3888 is only a modest difference when you compare it with the overall saving achieved by abandoning LDIR in favour of the 32-consecutive-LDI method. Norman worked out that copying the pixels (4096 bytes) between buffers is faster by 22528 T-States. For the 512 bytes of attributes across 16 character rows of the playable screen, there is an additional saving of 2816 T-States. So the total saving (per Main Loop pass) achieved is 25344 T-States before you account for the time taken to perform CALLs and RETs.

... And it seems I got completely the wrong end of the stick! The number of T-States for a conditional relative jump loop is based on how many times the relative jump has to be executed (here determined by counting down the value of A, which doesn't change between Norman's method and mine), rather than the distance back through the code that each relative jump spans (the operand of the JR command), as I had previously understood to be the case. :blush: So Norman's code (featuring only one CALL and RET per chunk of code copied) is certainly faster than my version!