IRF

Oh, I also meant to say: if you take up the idea of activating the 'Screen Flash' routine at the point when Willy has collected all the items, you could make an intervention at #9429 (just after the LD A, #01) with a CALL to another spare space in the code, then at that new location, insert: LD (#85DF), A [this is the existing command relocated from #9429 to make way for the CALL] LD A, #08 [or #10, which in decimal is 16; I recommend a value that is a multiple of 8] LD (#85CD), A [set the Screen Flash Counter to that value] RET The Screen Flash Counter will then be decremented once for each pass through the Main Loop, as the screen PAPER cycles through the colours, until it reaches a value of zero and the flashing stops. :)

Any savings you might make, may be eaten up by the extra code required to set up a loop to perform the repetitive bits?

I think we might have changed it to him/his bed in The Nightmare Edition, although I haven't checked. It's an easy thing to change though. Edit: Thinking back, I think the main reason for the change was to free up one character, because we had replaced the word "midnight" with "high noon", which is one character longer. But thinking about the subtext, it does perhaps make more sense as his/him. The last character of the scrolling message (the final +) doesn't get used anyway (try replacing it with something daft and you'll see what I mean).

...except that might not work if you altered the Screen Flash routine, in the process of making recent changes to the AMI game file (such as doubling the clock speed)?

Thanks for the latest code, Norman. I've tweaked and replaced the 'Norman' file attached to my post from last night (the one with three files attached for 'compare and contrast' purposes: unfixed, Ian's fix and Norman's fix). EDIT: In implementing your latest tweak, this time I have left the two additional spare bytes at the end of the screen-drawing code (instead of bothering to consolidate it with the six spare bytes at the start). They might be useful for some other purpose (such as adding an AND #80 prior to the nearby check of the internal 'ticker' [see #8A50], which has the effect of doubling the speed of the digital clock on the status bar).

By the additional JR, I presume you are referring to the jump forward (on occasions when you're not copying the attributes) to the INC L and then the jump back to LOOP? (Whereas in your previous code, if it wasn't time to copy the attributes, you jumped straight back to LOOP.) Aside from that drawback, you could have implemented the above in the version with the XOR A command, thereby saving a further two bytes (no need to do the DEC L and INC L in order to set the Zero Flag at the end of the final iteration of the drawing loop)?

If you try POKING 34253 to a value such as 8 or 16 whilst the game is running, you'll see the Screen Flash effect working. :) Either that, or play Manic Miner until you've collected 10,000 points.

For the record, this is how I tweaked Norman's latest code (one additional byte compared with post no. 33, changes in bold): EDIT: Note that this method leaves six spare bytes very usefully located in the spare loop, just prior to the screen-drawing code (at #89F5-#89FA). That's enough to insert a CALL to the Screen Flash Routine (which would have to be reinstated elsewhere) AND a CALL to the Main Loop Patch Vector. :) org #89FB LD HL, 05C00H LD DE, 05800H EXX LD A, #04 ld HL, 08200H loop ld e,(hl) inc l push hl ld d,(hl) ld l,e ld h,d res 5,d ld bc,32 ldir pop hl inc l JR Z, #0E If L has reached zero, then jump forward to the code which doubles Willy's speed during the Toilet Dash inc a and 7 jr nz loop exx ld bc,32 ldir exx dec L inc L JR loop Jump back to draw the next pixel-row (always necessary at this point, as the attributes are copied midway through the drawing of each cell-row) ;---------------------------- ld a,(34271) ;23 ; this code is moved down in memory and 2 ;25 rrca ;26 ld hl,34258 ;29 or (hl) ;30 ld (hl),a ;31 jr 35377 ;33

Okay, please see the three attached test files. (Ignore the fact that Willy jumps upon start-up, and walks backwards; those are relics from some earlier testing.) The 'Ian' fixed file has my latest iteration of a patch for the 'Delayed Attribute Effect', woven into Norman's original fix for the 'Jagged Finger Effect' as per my disassembly in post no. 32. I've also attached an unfixed file to allow for a Before vs. After contrast. The difference is striking, and the 'Delayed Attribute' is almost entirely eliminated. N.B. I tried to create an additional file, based on Norman's latest code (post no. 33), but that is still work in progress. Following Norman's code exactly (with the XOR A at the start) it worked okay, but the suppression of the 'Delayed Attribute' wasn't as effective as it is in my version (see previous discussion). So I tried to swap the XOR A for a LD A, #04. Alas, that caused the file to crash soon after the game started. So I need to look into what's going wrong (I know that it arose out of my minor departure from Norman's code, but I haven't yet figured out exactly why it doesn't work). EDIT: The screen is actually drawn prior to the crash, and I think that the problem is arising because the drawing loop doesn't know when to come to an end. That in turn is because the copying of attributes to the bottom cell-row doesn't follow on immediately after the final pixel-row has been drawn (i.e. the point at which L, the index to the table at #8200, has wrapped back round to zero). So the end of the outer loop might need to be tweaked a bit... UPDATE: I've also attached a 'Norman' file in which I've implemented Norman's fix from post no. 40 33, only I've modified it slightly so that As with my fix, the attributes are copied for each cell-row, mid-way through the process of copying the graphic bytes for that cell-row (i.e. after the first four pixel-rows have been drawn). Norman's fix required three (UPDATE: five) fewer bytes than mine, but I get the impression that the improvement in terms of the Delayed Attributes is slightly greater with my fix in place (EDIT: or maybe not?) However, there's not much in it, and both fixes offer a vast improvement in comparison with the 'unfixed' file. :) Jagged Finger & Delayed Attributes Ian Fix.z80 Jagged Finger & Delayed Attributes Bugs.z80 Jagged Finger & Delayed Attributes Norman Fix.z80

There are a few instances in the JSW code where the following sequence of commands are used: LD A, (#0000) INC A LD (#0000), A That's seven bytes in total. This can sometimes be replaced with the following four bytes (saving three bytes): LD HL, #0000 INC (HL) e.g. the updates within the Main Loop to the game's internal 'ticker' (#85CB), or to the Music Note Index (#85E1). EDIT: And to the Jumping Animation Counter in Move Willy (1). N.B. This approach couldn't be used in circumstances where the HL register-pair is currently in use for another purpose (e.g. to update the Game Mode Indicator during the course of the 'Draw the items' routine), without bookending with PUSH HL and POP HL (which negates two of the three byte saving). EDIT: in circumstances where the program subsequently does something else with the updated variable, then you'd have to follow the above with LD A,(HL), thus reducing the saving to two bytes.

My replies in red:

Norman, thanks for your latest post (which crossed over with one of mine). Looking at my latest code, I believe there are four instructions that you would term 'extra overhead' (#89FB-#89FF in my latest disassembly, in post no 32). Would that slow down the game considerably? (I haven't tried it out yet.) Balanced against that, my understanding of your latest code which copies the attributes at the same time, is that all eight rows of graphic-bytes would be copied to a particular cell-row before its attributes are distributed. That means that there would be a delay caused by up to 256 graphic bytes being copied, before a bitmap in the top pixel-row of its cell-row is united with its associated attribute. Of course, the situation would be much better for the bitmaps in the bottom pixel-row of a cell-row, because only 32 bytes would have to be copied in the intervening period. But my latest effort is an attempt to 'evenly spread' the delays, because last night I came up with a similar solution to yours [EDIT: similar in terms of the sequencing, not the execution], but I noticed that there was still a residual (albeit improved) 'Delayed Attribute Effect' - particularly for (fast-moving) Arrows located in the top pixel-rows of their host cell-rows. EDIT: Would replacing your XOR A (at 35317+7) with a LD A, #04 achieve what I'm after? i.e. Copying the attributes after the four pixel-rows but before the bottom four pixel-rows, for each cell-row in turn? ****** Looking at the length of your code, I believe it pips mine to the post by one byte in terms of efficiency. :) EDIT: Or it would be exactly the same length if we were to set the initial value of A to #04.

In contrast, in Matthew's original regime, there were considerable delays involved, which varied according to the position on the screen. Considering two extreme examples: - after the final graphic byte was drawn at the bottom-right corner of the playing area, there was a relatively short delay whilst the 512 attribute bytes were copied (as well as the time taken to enact the Toilet Dash double-speed effect and, if applicable, the 'Screen Flash' routine); - after the first graphic byte was drawn at the top-left corner of the screen, its associated attribute wouldn't get copied until every other graphic byte had been drawn - that's 32*16*8=4096!

This should do it - with this 'regime' in place, the maximum delay between a graphic byte being drawn, and its associated attribute byte being copied to the screen, should be the length of time it takes to draw 128 graphic bytes (equivalent to four whole pixel-rows). So it should minimise the 'Delayed [or Premature] Attribute Effect' (as well as the 'Jagged Finger Effect'). It's a bit more efficient than my previous attempt so it also restores the three bytes spare for a CALL to the Screen Flash routine at the start. I'll try it out later: (Norman

Danny, I've removed the files for now, so I can carry out further tweaking, and then re-upload a (hopefully) new and improved version. That'll save you from looking at various iterations, with slight improvements each time - it would be better for you to see the final article, and observe the greatest 'Before vs After' contrast in one hit!

That's exactly what was happening during my previous 'semi-successful' attempt to fix the 'Delayed Attributes' bug. In fact, some of the arrows actually had red 'trailing edges' instead of red 'leading edges', particularly where an arrow occupied a pixel-row towards the bottom of its cell-row - the white attribute was being advanced ahead of the arrow's graphical bytes. A kind of 'Premature Attribute Update' effect, so to speak. I suppose the optimum fix would be, for each cell-row, to draw the top four pixel-rows, copy the attributes for that cell-row, and then draw the bottom four pixel-rows. That would balance out/minimise the 'delays' between any particular graphic byte and its associated attribute being distributed across the whole screen. It might further complicate the code though!

Maybe it ended up impressive once I'd resolved a couple of silly mistakes! I'm still not convinced it's as byte-efficient as it could be though?

Hopefully you won't need to be able to follow the details to appreciate the qualitative difference between the Before and After scenarios? The improvement in terms of the 'Delayed Attributes' is easily seen in the starting room (Swimming Pool), and it you wander left and then up the long staircase as far as Conservatory Roof, you can hopefully see the improvement in terms of the 'Jagged Finger' - watch Willy's sprite as he goes up the ramp (particularly as he passes from bottom to top half of the playing area), and the horizontal guardians in Conservatory Roof. EDIT: Other places to watch/compare/contrast: - watch Willy jump and fall in Front Door (highly noticeable improvement in there because the Air INK is Black against Cyan PAPER, both of which contrast well with Willy's customary White); - drop him down into Entrance to Hades; - observe the fast-moving vertical guardians in 'I'm sure I've seen this before', and 'Rescue Esmerelda'; also the beak of the horizontal Bird in both rooms, and the Arrows in the former.

I don't think I've quite got the attribute part of the loop working properly. I think each cell-row is having its attributes drawn before the graphic bytes for that cell-row, but the first cell-row isn't getting coloured in until the very end of the loop (after the rest of the screen has been drawn). That's why the top two arrows haven't been 'fixed' to the same extent as the others. A further tweak is required... EDIT: I''ve cracked it! In the end I needed to use the three spare bytes which I thought I had left over, as well as an OR A which I had previously indicated would reset the Carry Flag, but which on reflection wasn't necessary for the patch to function properly. I think the improvement is now very noticeable from the 'Before' to the 'After' scenario. B) I've swapped the file which I'd previously uploaded for the 'properly fixed' version (I don't think anyone had downloaded it before I swapped it?), and I've also updated/corrected the disassembly which I provided in post no. 22 of this thread. Thanks again to Norman for his part in this fix - I was able to 'piggy-back' onto his code, in order to implement my more comprehensive patch for both the 'Jagged Finger' AND the 'Delayed Attribute Update' bugs.

If you compare the effect in the Swimming Pool between the two snapshot files (the earlier one and the 'fixed' one), there is definitely less of a pronounced 'leading edge' to Willy as he walks/jumps/falls across cell boundaries. The effect is still quite prominent for the two arrows at the top of the screen (UPDATE: not any more!), but less so for the lower arrows. Since arrows move horizontally one cell at a time, I would expect the effect's prominence to be most acute for arrows. However, I would have expected the delay between the arrow being pixel-drawn and attribute-rendered to be greater for the first arrow from the top (which occupies the second pixel-row of the top cell-row), compared with the delay for the second arrow down (which occupies the seventh pixel-row of the top cell-row). So I am a bit surprised that the effect seems to have roughly equal prominence for those top two arrows(?) UPDATE: I had made a small error when writing my patch, which I have now fixed. Still, my latest code changes seem to have improved the situation for most UPDATE: ALL of the arrows in the test file. :) EDIT: And the 'Green Legs' effect when Willy falls into 'Entrance to Hades' is greatly reduced in the latest file (although you'll have to navigate over there yourself to see that).

I just tried it out and it crashed the emulator, with random coloured squares everywhere!! Either my idea is completely off, or I've made a tiny mistake that may take ages to track down - or possibly some scenario in between!! EDIT: At first glance, I think it's something to do with the way in which I've incorrectly used the PUSH and POP commands, causing a stack overload. UPDATE: Yes, that was the problem, a PUSH in the wrong place. I've swapped the code around slightly and it works fine now. I'll edit the previous post accordingly (DONE). Please see the latest test file attached to this post. The 'Delayed Attribute Update' effect is still present, but it is much less prominent than it was before. EDIT: I've also reattached the earlier test file here (renamed slightly for clarity), which displayed the bugs prominently and has the same starting position (the Swimming Pool, with Red Air INK, Cyan Air PAPER and eight arrows at various heights), so that the 'Before' and 'After' can be compared and contrasted. FURTHER UPDATE: I've removed the files temporarily, as I want to work a bit more on the code to increase its effectiveness and efficiency.

I think the above can be done in 26 29 bytes. That should nicely leave exactly three spare bytes, which would be best left in situ prior to the start of Norman's code (to allow a CALL to elsewhere to reinstate the Screen Flash routine - otherwise the Screen Flash effect wouldn't be able to influence the screen's PAPER colour - or alternatively to add a CALL to the Main Loop Patch Vector sub-routine). I haven't tried this out yet, but here's my first stab on the basis of studying the code (I prefer to work in hexadecimal): org #89F5 89F5 Three spare bytes Then First comes most of Norman's code, highlighted in bold: 89F5 LD HL, #8200 89F8 LD E, (HL) Start of LOOP, each iteration of which copies 32 graphic bytes across a single pixel-row (raster line) of the screen 89F9 INC L 89FA PUSH HL 89FB LD D, (HL) 89FC LD L, E 89FD LD H, D 89FE RES 5, D 8A00 LD BC, #0020 8A03 LDIR 8A05 POP HL 8A06 INC L 8A07 LD A, L 8A08 AND #0F Check if L is now exactly divisible by #10 8A0A JR NZ, LOOP If not, then we haven't yet drawn all eight pixel-rows of the current character-row to the screen, so jump back to LOOP to draw the next pixel-row 8A0C PUSH HL 8A0D LD A, L 8A0E SUB A, #10 8A10 LD L, A 8A11 LD H, #5C 8A12 OR A Reset the Carry Flag in preparation for the next command (N.B. This may not be necessary?) 8A13 SLA L This sets the Carry Flag if (and only if) we are now considering a character-row in the bottom half of the playing area 8A15 LD E, L 8A16 JR NC, #01 This jump only occurs if we are in the bottom half of the playing area 8A18 INC H Point H at the bottom half of the playing area; HL now points at the left-hand end of the appropriate character-row in the attribute buffer 8A19 LD D, H 8A1A RES 2, D DE now points at the left-hand end of the appropriate character-row in the screen's attribute file 8A1C LD BC, #0020 There are 32 bytes to copy 8A1F LDIR Copy the attributes along the current character-row 8A21 POP HL 8A22 LD A, L 8A23 OR A Check if we have finished copying the whole of the playing area (i.e. the graphic bytes and attributes for all sixteen character-rows) 8A24 JR NZ, LOOP If not, then jump back to LOOP to consider the next character-row This command marks the end of Norman's code That would then be followed by the original code which makes Willy run at double-speed during the Toilet Dash (which fortuitously fits exactly into the space where the original attribute-copying code was located): 8A26 LD A, (#85DF) 8A29 AND #02 8A2B RRCA 8A2C LD HL, #85D2 8A2F OR (HL) 8A30 LD A, (HL) Finally, the original Main Loop routine resumes at #8A31 (starting with the code which prints the current time, then the number of items collected, etc). Let's just hope it works!! :P

Hey Mickey(!) I'll shortly be working on another bug fix (building upon Norman's - see the 'Jagged Finger Effect' thread), which could benefit your 'As Manufacturer Intended' project. Over on that other thread I've given some examples, as has Norman, of the two interlinked 'bugs' that the fix should be able to address. :) EDIT: I think I've made some progress on the above, although I've not yet tested it out to see if it improves the way the screen is rendered to the extent that I hope. ****** I also had something else in mind, for which I've left a contingency plan in place... I was thinking about the unused 'Screen Flash routine'. It was left in the JSW code as a relic from Manic Miner, where it takes place whenever Willy gains an extra life. But there is no mechanism for gaining lives in JSW. However, thinking about the concept of 'as manufacturer intended' - perhaps the routine was left in place for a reason? I'm speculating, but maybe it was originally intended that the screen would flash to signify that all of the items have been collected? Only, that would have given the game away, for the competition that was held at the time of the game's original release... Just a thought!

Another thing that I meant to point out last night, but forgot: the only moving elements that aren

Please find attached a snapshot (Z80) file and a screenshot, taken in the Swimming Pool where I've set the background to Cyan PAPER and Red INK, and added eight arrows (of the same class) at various heights on the screen. If you open up the snapshot file, you can watch the way in which the y-coordinate of an arrow determines how prominent the 'Delayed Attribute Update' effect is. There's a general pattern of the higher arrows' graphic bytes being more visibly 'detached' from their attributes than is the case for the lower arrows, but it isn't a linear effect (see previous discussion). In the screenshot, you can also - in the topmost arrow - observe the 'Jagged Finger' effect. The top two pixel-rows of the arrow have moved on into the next cell (which still has Red INK), whilst the bottom pixel-row of that arrow hasn't been updated yet and has been left behind in the previous column (where it is still rendered in White INK). This is a strong indication that the two effects are linked, and I intend to come up with a comprehensive fix for both, using Norman's code as a starting point (and thank you for that code Norman, which not only brought attention to the 'Jagged Finger' phenomenon that I wasn't previously aware of, but also provides the basis for a fix for the 'Delayed Attribute' phenomenon which I was previously aware of!) EDIT: It won't be possible to fix the 'Delayed Attribute Update' phenomenon entirely, but if you watch the bottom arrow in flight in the attached Z80 snapshot file, that one shows the effect least prominiently, because the arrow occupies one of the last pixel-rows to be drawn to the screen, and so the time delay before the associated attributes for that cell-row are updated is minimised. That should be possible to achieve for all cell-rows, by modifying Norman's approach as I suggested in post number 17 on this thread. I will try to do that later this week (unless someone beats me to it!) :ph34r: Jagged Finger & Delayed Attributes.z80