IRF

For consistency and elegance, wouldn't it be best, in the case of operations which are self-modified by the code, to insert NOP command(s) (opcode #00) wherever they appear in the source code listing? That way the default value held at the pertinent address(es) would be zero, as is the case with the operands that are self-modified. e.g. For your example of a direction label, list it in the source code as: S_M_C_direction: NOP And then use: LD A, #3C [for INC A] or LD A, #3D [for DEC A] or XOR A [to restore the default NOP] followed by: LD (S_M_C_direction), A for movement in whichever direction (or no direction).

On reflection, I suppose it's obvious from the context how many bytes are affected (i.e. how many are going to be self-modified by the program).

Would it be worth making a distinction between a single byte being subject to modification, and a two-byte word? Like LD D, $- versus: LD HL, $-$- Or something?

Regarding the format here: Does the "$-$" bit refer to the fact that the operand is a two-byte word? EDIT: Apparently not - I've just noticed the self-modifying code in your source listing for Matthew's original code: In that case, the operand is only a single byte, yet you still use the same format: "$-$".

Thanks for the explanation, Norman!

Question: what do the initials 'S M C' stand for here?

Should presumably read "Then change the routine at $8D33"? It's another good idea though!

However, a byte could possibly be saved by replacing this (commands in green): with this: LD A, D ADD A, #08 LD D, A JP PO, tile_do or JP PE, tile_do ; Overflow Flag is set when ADD 8 takes D from #78 to #80, but not when D goes from #70 to #78 RET Again, I've not tried this out yet. And I'm not currently sure if, when the Overflow Flag is set, whether that translates as Parity Odd or as Parity Even? (But if one doesn't work - presumably causing the routine to bail out after drawing the pixels for the top half of the room only - then the opposite conditionality for the jump should do the trick.) EDIT: In this instance, testing the Sign Flag (i.e. JP P or JP M) would have the same effect as testing Overflow. In either case, there is only an absolute jump available for this purpose, not a relative jump. So only one byte can be saved, not two.

I think I might(?) have come up with a further optimisation of the room expansion code - I haven't tried it out yet though... Suggested changes are in red: EDIT: Now that I've tallied up the 'before versus after' difference, it might not be any more efficient in terms of memory after all! There are fewer commands overall though, so perhaps it's marginally faster? In addition to the above, the 'Print a message' (#9680) and 'Print a single character' (#9691) routines would need to be rewritten, as follows: ORG #9680 LD A, (IX+$00) ; Collect a character from the message CALL Print_ASCII_character ; Print it INC IX ; Point IX at the next character in the message INC E ; Point DE at the next character cell LD A,D ; (subtracting 8 from D compensates for the operations performed by the subroutine at 9691) SUB $08 LD D,A DEC C ; Have we printed the entire message yet? JR NZ,$9680 ; If not, jump back to print the next character RET Print_ASCII_character: ; Formerly #9691 LD H, #07 LD L, A SET 7, L ADD HL, HL ADD HL, HL ADD HL, HL Print_non_ASCII-character: ; Formerly #9699 ; Label renamed for clarity LD B, #08 ; There are eight pixel rows in a character bitmap Loop: ; Copy the character bitmap (or triangle UDG, or item graphic) to the screen (or screen buffer) LD A, (HL) LD (DE), A INC HL INC D DJNZ Loop LD A,D ; Subtracting 8 from D compensates for the operations performed by this subroutine SUB $08 LD D,A RET As I say, I haven't tested this out yet. Off the top of my head, I can't think of any reason why it wouldn't work, but careful consideration is needed bearing in mind that the 'Print a (non-ASCII) character' late entry point into the 'Print a single character' subroutine is also used by other code (such as the Impossible Triangle and item-drawing routines).

These labels (in the room expansion code) made me chuckle: ****** Regarding the clock update, I came up with the use of XOR to toggle between 'am' and 'pm' independently, and suggested it to Metalmickey for his 'As Manufacturer Intended' project. But the rest of the method is an innovation - ditching the use of an indexed register (IX) saves quite a few bytes (no need to use the 'shift opcode' DD), and the comparison against a table of 'upper limit values' for each digit ("clock_master") is rather ingenious!

Did the project present any unprecedented problems because of the protagonist's prominent proboscis? (Collecting the item in The Chapel, perhaps?) **** Out of interest, I wonder if, after completing the game, you pressed SHIFT+SPACE whilst still recording, in order to showcase (as part of the recording) the final passage of the Noseybonk theme, which is played during the Game Over routine? (Note to self for when I get round to watching your recording.)

I thought it might be a deliberate reference to Willy's grand abode...

Deliberate typo, m'lud?

Your compression of the Title Screen is impressive, Norman Sword. This is small beer in the scheme of things, but instead of the commands in bold: You could just test BIT 1, D. (And swap the conditionality of the jump to JR Z, logo_draw). Saves another byte! :)

Are all the different heads stored in a table? You could almost call this "JSW: The Worzel Gummidge Edition"! :lol:

I guess this means that it's time to say "Happy Birthday Andy!"

"Words fail me" that no-one has cracked this yet...

Thanks Norman. I notice that that method overwrites the intermediate byte twice, with the same value (not that it matters).

Small rewrite in the JSW game initialisation code which saves a byte: 87F5 LD HL,$857C 87F8 LD (HL),$30 87FA INC HL 87FB LD (HL),$30 87FD INC HL 87FE LD (HL),$30 LD HL, #857C LD BC, #0330 loop: LD (HL), C INC HL DJNZ loop

Well done Danny! I wonder if your statement here: was facilitated by your having utilised the SPECSAISIE comparison tool for the task? (Which you recently installed and used in relation to the MM10CC project.)

76+16=92, but in any case doesn't the LD HL, (counter) require 20 T-States (source: http://z80-heaven.wikidot.com/instructions-set:ld ) Plugging that in yields about 8 T-States for the overhead per byte in the Stack Copy method, therefore a total of 18.5 T-States per byte. i.e. the LDI method is even more efficient in comparison with the Stack Copy method than your rough calculations suggest(?)

Is anyone "seeing red" in frustration over this yet?

Having refreshed my memory, the flaw doesn't work in the way that I outlined in my previous post. The items jiggle up from their default position, not down (as I had misremembered). If you have an item in the top cell-row, then it discolours the cell in the bottom cell-row directly below it. (The top graphic byte of the item is interpreted as an attribute byte, overwriting the primary attribute buffer.) This is normally disguised, because in Mono mode, everything is overwritten in black-and-white anyway, even though technically all the room blocks remain retain their colour attributes (upon which Willy's interaction with them is based). So it's normally a harmless effect (an 'invisible visual glitch'!) But if the top pixel-row of an item's graphic definition matches the attribute byte of a defined room block type, then other effects can occur. In the attached test file, I have defined an item shape in West Wing and added some items in the top and bottom cell-rows. There is no collision with the vertical guardian, as I had initially expected, but there are a couple of effects: (1) If you try to walk down to the bottom of the ramp, you will notice that Willy is killed for no apparent reason. The item's top pixel-row is entirely filled in - all eight pixels are on; it holds the value #FF - this matches the defined attribute byte for Fire cells, so there are two invisible Fire cells created in the bottom cell-row; (2) The bottom two items disappear after two time-frames - because the #FF Fire cells hold white INK, collecting the items. (The slight time delay occurs as the secondary buffers take a while to catch up with the corruption of the primary buffers.) Jet Set Willy - Mono Jiggle Test File.tap

I seem to recall that I identified a flaw with the Jiggle patch, which causes the bottom pixel-row of the graphic of an item located in the bottom cell-row of the screen, to spill over into the top pixel-row of the top cell-row on the screen, causing a permanent overwriting of that graphic byte. Such graphical corruption would be prone to collision with guardians, imperilling Willy. I identified an easy fix for that flaw, which is detailed somewhere in the Yahoo! Group. This problem shouldn't affect the games you've just uploaded, since (as far as I can recall) there are no items in the game which are located in the bottom cell-row of any of the rooms. But if the game were modified to that effect, then the flaw could rear its head. Though if the graphical corruption were to occur in an air cell in the top cell-row, then it may not be visible unless the Air's PAPER and INK settings are different, such as in a room with a rope.

Correct! Hip hop hip Hooray!!