IRF

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

Something else I've just thought of: the three images that Norman attached in the third post of this thread, were taken in the First Landing where the Air's INK and PAPER are both set to black. I believe that both phenomena would have been visible if the Air INK had been set to another colour. (N.B. It might be worth pointing out that the first of those three images was captured at the point when Willy is passing from the top third to the middle third of the screen. i.e. from the top half of the playing area to the bottom half). EDIT: I've just captured a screenshot, using my emulator's pause function. Please see the attached image, and in particular the Monk guardian. Hopefully you can see that I have replicated what Norman's previous images showed, in terms of the 'Jagger Finger' effect. i.e. the top part of the Monk's head and the upper part of his body have been moved on to the next animation frame, but his jaw and his legs haven't yet been updated (as per the previous discussion). Thus capturing a moment midway through the implementation of the LDIR loop which copies the graphic bytes from the Display Buffer to the actual screen. But because I have changed the Air INK to Red in First Landing, you can also see that the foremost pixels of the Monk (the tip of his long nose and the front of his belly) are drawn in Red INK. That's because he has just crossed a cell-column boundary, and the screen attributes haven't yet been updated to ensure that the cells into which the Monk is advancing is rendered with his Yellow INK.

One other point which I forgot to mention last night: both the Jagged Finger and Delayed Attribute Effects can be clearly seen if you are playing on an emulator and you pause the game using the emulator's pause function. That way, you can capture a 'moment in time'. However, if you pause 'in-game' by using one of JSW's defined pause keys (A-G), then you won't capture either effect, because the Main Loop only checks for pause keys being pressed after it has finished copying to both the Display File and the Attribute File.

Having thought a bit about the above, perhaps another check could be inserted just prior to the JR NZ, LOOP command: Copy L into A, apply an AND #0F, and if that sets the Zero Flag, then it's time to update the attributes for the cell-row under consideration. (N.B. the code to achieve that should be bookended by PUSH HL and then POP HL, to preserve the pointer to the lookup table at #8200). I'm not sure whether it would fit into those spare 16 bytes which Norman identified? (Which could be 18 bytes if you didn't need the JR 35366 / #8A26 at the end of the code which makes Willy run double-quick during the toilet dash.) EDIT: Actually, there would be another 11 bytes to play with (so 29 in all), since the function of the code at #8A26-#8A30 would have been performed instead by the new intervention. So it should be doable within the available space in the Main Loop - I might have a go at it when I get a moment. It would kill two birds with one stone - eliminate the 'Jagged Finger Effect' AND the 'Delayed Attribute Update Effect' (I'm still open to suggestions on the name for that one!)

I appreciate the order in which the screen lines are updated (thanks to explanations given in the past on this very forum by Dr Andrew Broad). I think where I failed was in my interpretation of what your previous diagram (the one with the red and black squares) was trying to represent. And possibly in my lack of knowledge of computer terminology. (I thought 'raster' was something to do with Bob Marley before I Googled it! :D ) EDIT: I think I've grasped what your diagram is showing now (having looked at the diagram on a bigger screen - I was on my tablet earlier). Please excuse my general ignorance! I'm just a humble EHO, dabbling in a bit of coding in my spare time!

I have thought some more about the above, and carried out some investigations. It seems to be a related phenomenon to the one which Norman has identified. PREAMBLE: For my investigations, I inserted several arrows of the same 'Guardian Class' into a room, in which I had assigned differing values for the Air's INK and PAPER settings. (Red INK on Cyan PAPER - both of which contrast well with each other, and also with the White colour of the arrows.) The effect described above was clearly visible, whereby an arrow's graphic bytes are drawn to the next cell along the arrow's path, in advance of that cell's INK setting being updated in the attribute file. This causes the arrow to flicker for the briefest of moments in red (the background's INK setting). Furthermore, the effect was much more pronounced for an arrow that fired along the top of the screen, than for one which traversed along the bottom of the screen. For two arrows which occupy the same cell-row, but different pixel-rows, the effect was more pronounced in the arrow that passed along the upper pixel-row. But within the same vertical half of the screen, an arrow in the top pixel-row of a cell-row at the bottom of the screen (row 15) displayed the effect more prominently than an arrow in the bottom pixel-row of a cell-row higher up the screen (row 8). This pattern is not surprising, bearing in mind the previous discussion about how the screen is drawn in JSW. The prominence of the effect is proportionate to the time delay between the arrow being drawn, and the colour-attribute of its host cell being updated. (With Norman's alternative screen-drawing routine in place, I suspect that the prominence of the effect would follow a simple linear progression down the screen, although I haven't checked that.) ****** This gives rise to the possibility of coming up with a further rearrangement of the code to diminish this effect, building on Norman's methodology. Could Norman's new code be modified so that the attributes along each cell-row are updated from the attribute buffer immediately after all eight pixel-rows for that cell-row have been copied from the display buffer? i.e. Pixel-rows 0-7 of cell-row 0 are drawn, and then the updated attributes are inserted across cell-row 0, before cell-row 1 is considered? EDIT: If such an approach were to be implemented and if you wanted to use the unused 'Screen Flash' routine [a relic from Manic Miner, where it is enacted once an extra life is gained] within a project, then the Screen Flash part would need to be reinserted in the Main Loop (to overwrite the PAPER colour of every screen cell in the secondary attribute buffer) before any of the screen (graphic bytes or attribute bytes) is updated during the Main Loop. ****** Incidentally, I gave the example of arrows because the effect (which we should probably think of a suitable name for) is most noticeable, since arrows are so fast-moving. But you can also observe it with guardians (especially fast-moving vertical ones) in rooms with non matching INK and PAPER settings for the background. See the Cyan Security Guard in the blue rooftop room 'I'm sure I've seen this before' - the top of the guard's helmet or its feet, at the point when those elements cross into a new cell-row - or the horizontal Green Bird in same room - watch its beak as it flies into a new cell-column. You can also observe the effect quite prominently when Willy falls through 'Entrance to Hades' (where the background has Green INK on Yellow PAPER). It isn't generally as noticeable with Willy whilst he is walking, because his sprite is quite narrow, and so his colour-attribute actually moves forward in advance of the inked-in part of his sprite. (That's why he can perch on the edge of a block when it appears there is nothing underneath him supporting him.) But in 'The Nightmare Room', where Willy is in Flying Pig mode, his sprite is quite a bit wider than usual, so if you POKE the Air INK in there from the default Black to Magenta, then as it walks around you can sometimes catch the pig's snout turning pink (appropriately enough!)

Is that example drawing pairs of graphic bytes, vertically-paired? If so, I don't think that's what happens? Except (sort of) during the transition from the top half of the playing area to the bottom half - the bottom pixel-row of character-row 7 is drawn immediately before the top pixel-row of character-row 8. When I said "pairs of graphic bytes", I was referring to a byte from the left half of Willy's sprite, followed by the adjacent byte from his right half.

I can't get the file which you uploaded to work. But thanks to the disassembly which you also provided, it should be a relatively easy task to insert the alternative 'screen-drawing regime' myself into a test file to check it out. :) ****** I think I've got my head around how it works... Considering Willy's sprite (although the effect is also manifested in moving guardians): In the original code, pairs of Willy's graphic bytes are drawn in the following order when he is cell-row aligned: 1st pair of bytes [top of his hat], 9th pair of bytes, 2nd, 10th, 3rd, 11th, 4th, 12th, 5th, 13th, 6th, 14th, 7th, 15th, 8th pair of bytes, 16th pair of bytes [bottom of his feet] This is further complicated when his sprite isn't cell-row aligned (when he is climbing a ramp/jumping/falling/on a rope). e.g. at times when he is exactly half a cell-row (four pixel-rows) out of alignment with the screen cells (such as when he's fallen downwards by one increment off a platform), then the pairs of Willy's graphic bytes would be drawn in the following order: 5th, 13th, 6th, 14th, 7th, 15th, 8th, 16th, 1st, 9th, 2nd, 10th, 3rd, 11th, 4th, 12th. ****** Now, with Norman's fix in place, Willy's sprite is simply drawn a pixel-row at a time [along with the rest of the screen, but I'm just concentrating on Willy here] from top to bottom, regardless of how he is aligned within the cell-rows: 1st, 2nd, 3rd, ... 15th, 16th Is that right?

Doesn't Andrew Broad use something called SPECSAEIE or something, for this purpose?

There's a bug in the 'Cycle the colours' routine (#8AEB): - If you pause the game in 'To the Kitchens...Main Stairway', the non-flashing Conveyor starts flashing once the screen colour cycling effect starts to take place; - Conversely, the normally flashing room elements in 'Nomen Luni'/'Under the Roof' (i.e. Earth blocks in the former, and Fire cells in the latter) stop flashing whilst the screen colour cycling effect occurs when you pause the game. Richard (SkoolKid) has come up with a simple fix: insert an AND #B8 command prior to the ADD A, #18 at #8AFA. For it to work properly, that needs to be followed by the existing AND #B8 at #8AFC, and so two additional bytes need to be squeezed into the routine. The easiest way that I can see is to insert a CALL at #8AF9-FB to elsewhere (somewhere with six spare bytes). Then at the new location, have: LD A, (HL) AND #B8 ADD A, #18 C9

Fair enough, it was more of a 'wondering out loud' type question. It's just that I haven't observed the issue occurring on the online emulator (QAOP) that I tend to use most of the time. Then again, maybe I haven't trained my eye to look for it? I have noticed the separate issue whereby the screen's display file is updated slightly before the attribute file. This is most noticeable in rooms where the background's INK and PAPER settings are different, and fast-moving elements traverse the screen. e.g. arrows in a room with a rope, where it manifests itself in the arrows flickering in a different colour to the usual white (in that example, the arrows would be seen for the briefest of moments in the same colour as the rope).

Does the extent of the problem depend on which emulator you use?

Well #9590 resets the minute counter to zero, so you could put some code after that which gets the thing you want to happen to occur when the minute counter to #FF. That make it recur EVERY minute though, depending on what it is?

Indeed, how would you know that it looked like [resembled] a game which you haven't seen (because it didn't happen!) :D

The way Mickey has it set up is that you have to enter a correct code on the first occasion to get through, if not then you are asked a second time for a code, and that time it will let you through whatever you input. I think that's a good compromise which still keeps the Code Entry facility (you can enter a correct code first time round if you want to), but without inconveniencing the player if they don't have the Code Sheet handy. :)

Or the simplest way to achieve Brightness consistency would be to make the Blue and Red numbers on the left (1 and 2) non-Bright - the opposite of Andy's fix!

Although for consistency, shouldn't the coloured squares on the right be printed with Bright Flashing PAPER colours? http://skoolkid.github.io/jetsetwilly/asm/873C.html POKE #879D, #48 POKE #87A3, #50 POKE #87A9, #58 POKE #87AF, #60 (Sorry the POKES are in hex - I can't work in decimals any more!)

Another possible idea here Mickey: http://jswmm.co.uk/topic/293-keypad-graphics-bright-bug