IRF

Actually, #A4C7 should hold a value of #5C at the start of the game (i.e. Bit 6 is set, marking the item as 'uncollected'). i.e. 42183, 92. It'll go to #1C (Bit 6 reset) once you collect the item. (Although having said that, restarting the game should have sorted that out.)

Have you tried making the change in the hex editor?

Hmm, strange! Is the other byte for that item correct? #A4C7 should read #1C (that's 42183, 28 in decimal).

You won't see the item, because it's still invisible! Didn't the item count increment when you dropped into First Landing? (I just double-checked the POKE and it seems to work for me.)

If you move items around using JSWED's GUI - i.e. by deleting it from the old location (above the cross) and re-adding it at the top of the ramp - then in the intervening period, JSWED will have shuffled all the other items from earlier in the item list to 'fill the gap'. Then when you add the item again, JSWED will put it at the top of the list. So that's probably what's confused you? If you get a 'fresh' copy of JSW and apply the POKE I provided, then it should do the trick?

That should be doable in a single byte change - you could in theory place it anywhere in the top half of First Landing, just by changing the value of #A5C7 (let's say to #35). As you say, if it's near the top of the ramp, then Willy will have to pass through it on the way down. So in a sense it wouldn't matter that it's invisible (although it's not ideal). EDIT: Try POKE 42439, 53. That's definitely an improvement on the 'official' POKE which moves it to The Hall, because as you pointed out, the player could be jumping to avoid the Flying Pig/arrow and miss the item, at least in theory. (Although it's extremely unlikely that they'd miss it twice - both on the way out to The Front Door, and then on the way back again! :lol: )

That's true about West of Kitchen. Higher up would be better. The problem with West Wing and West Bedroom is that there's no item shape defined, so even though it would be within reach, it would still be invisible.

Further to the above, I've had a quick look at all the rooms in JSWED. There are seven possible locations which would see the item resting on a platform after applyin a single POKE to the address #A4C7 - see the attached screenshots. In three of these, I used the square cursor to highlight the location, because (just as in First Landing) the rooms don't have a defined item graphic (although in the case of West of Kitchen, there is an unused graphic next door in The Kitchen). In those three cases, a visible item couldn't be achieved using a single POKE, because you'd also have to give the item a shape to allow it to be seen by the player. So we can probably rule those three rooms out as being 'As Matthew intended'! I'd say the most plausible locations are Tree Root - where the 'slope' of the item means that it sits nicely on the ramp - or Swimming Pool - where the additional item provides some symmetry with the existing one, although it appears to be 'floating' on the water so it would probably look better a couple of columns to the right*. (*But to do that you would have to adjust the other definition byte #A5C7, which defeats the purpose of the exercise - if we're going to edit both item definition bytes, then we might as well put the item anywhere in the mansion!)

I seem to recall ages ago Stuart (Zub) suggesting that the item might have been meant for another room, but eight rows lower - since the item definition byte which holds the room number also tells you which half of the room it is located in. i.e. a single POKE would still put it back in its place. I can't recall whether anyone ever investigated that possibility though?

The former would be more consistent with the 'second attempt' message.

The I register is something different I think (and is still a bit of a mystery to me - it controls the Interrupts). I was referring to the IX and IY register-pairs, which work just like HL, but you can specify bytes at a specific offset from the 'origin'. e.g. look at how the guardian code works. You access them by using a 'shift byte' in front of the regular Z80 operation byte ('DD' for IX, 'FD' for IY). :)

I just tried the above and it works fine! :) The IX (and IY) registers come into their own when you're reading and/or updating a sequence of consecutive bytes (such as an ASCII string), or using a lookup table (such as #8200-FF), or when you're dealing with the likes of the guardian buffer (addressing each eight-byte definition in turn, to move or draw the guardians). The ability to use an offset-byte operand saves you from having to constantly redefine the index pointer. But the 'Print a message' routine doesn't do any of those things, it just uses IX like any other register-pair to hold an address (the start of a ASCII message). I suspect the only reason Matthew didn't use HL is because that also is used by the subroutine which prints each character in turn. But PUSHing and then POPping HL gets around that. ;)

The inactivity timer code is fairly unnecessary in this day and age.

The 'Print a message' routine at #9680 uses the indexed IX register-pair to point at the start of the message to be printed. However, I believe it would be more efficient to use the HL register-pair instead. The only pitfall is that 'Print a message' calls 'Print a single character' (#9691) as a subroutine, which uses HL. But if the CALL to #9691 from #9683 was bookended by a PUSH HL and a POP HL, then the three-byte LD A, (IX+$00) command at #9680 could be replaced with a single-byte LD A, (HL) command. So far the code changes are 'byte-neutral'. But it would allow further efficiencies throughout the program. For starters, the INC IX at #9686 could be replaced with INC HL (saving one byte). But it would allow all the commands which set up IX prior to a CALL to #9680 to be replaced with commands that set up HL. This removes the need to use the 'DD' shift-opcode, and in some instances the offset byte operand. e.g. at #8835, #88C8, #8965, #8971, #8A31, #8A3D, #8CCB and #8CD7, you could replace the four-byte LD IX, $0000 commands with three-byte LD HL, $0000. (Although the commands in red are already ones that I have identified as potentially redundant, because those routines print two messages in quick succession which are stored in adjacent addresses in the code, so IX [or the suggested HL] will already point at the correct location to pick up the message.) At #88CF, the two-byte ADD IX, DE could be replaced with a single-byte ADD HL, DE. Some of the above changes could be very useful in freeing up bytes in tight spots in the code (such as the Main Loop). :)

The same is true of the four-byte command at #8CD7-8CDA.

I guess the 'vertically-rolling' screen only works in black-and-white, or else the attributes would sometimes be noticeably non-aligned with the graphical bytes that they are supposed to be associated with. (Unless it rolled down by a character-row at a time, as opposed to the smooth rolling by pixel-row.) But the black and white fits the 'nostalgia' theme, so it's all great!

Thanks for those, NS. :)

I was wondering why some of the room numbers ended with a digit, from '3' to '6', and also where '1' and '2' might be? I imagine that 'Demolition Site-bomb Blast' and 'Demolishing this place soon' would have been '1' and '2' respectively? Looking at the screenshots during 'attract mode', each of the two inaccessible rooms does have one item, so it seems that I got as close as is possible to completing the game last night (without POKING to move Maria out of the way - but even that might not be an easy task if the pertinent addresses in the code have been altered from the original). How easy would it be to extract the code which causes a particular room's special effect? e.g. 'Nostalgia' or 'Mine Entrance'? Sounds intriguing and fiendish in equal measure! It would be a shame if such a guardian didn't see the light of day at some point... See 'The Nightmare Room' in 'Jet Set Mini' for a room that has two independent animated conveyors (located in different cell-rows, although they both animate in the same direction). Also, the conveyor in the same game's 'East Bedroom' is animated at pixel-rows 0 and 2 (as per usual), and at pixel-rows 5 and 7 as well. (Both of which are achieved by calling the 'Animate the conveyor' routine every tick, with a later entry point than the usual #94F9.)

I've collected 192 items, and I can't see any more in the layout, but Maria is stubbornly refusing to budge! :huh: EDIT: Looking at the list of rooms, there are two I haven't discovered yet: 'Demolition Site-bomb Blast' and 'Demolishing this place soon'. Any clues as to which part of the layout they might be found in?

I just reached The Forgotten Abbey during Willy's last remaining life. I believe it is impossible to complete the screen (collecting the item) without sacrificing a life, and therefore it was Game Over for me! In original JSW, Willy has to walk leftwards through a wall block at head-height - the one sticking out just below the item - in order to get back down again afterwards. Because you've made Willy's movement symmetrical (and more logical with regard to wall tiles), that is no longer possible. Replacing the single protruding wall block with a floor block would resolve this problem. EDIT: Actually, after a rollback, I managed to collect the item and jump through the wall block in question via a single, perfectly-timed jump. (I had assumed that you had eliminated such quirky jumps.) However, you only get one go at the jump; if you mistime it, there is no chance to try again because Willy can't drop down onto the conveyor and walk back far enough (against the flow of the conveyor).

Here is the 'Fat Rope' test file - this is comprised of just two ropes, so it runs faster. The Fat Rope is exactly centred horizontally in the room. Fat Rope Test.z80

If it's the room I'm thinking of, I did think it led to an unfair 'Infinite Death Scenario' when Willy walked in. But I did manage to make it across the room, by jumping rightwards from the rightmost edge of the room to the left, which allowed Willy to just about land on the conveyor. He then fell off the other end of the conveyor, but safely fell down and appeared at the top of the same room. It sounds like that was probably a bit of a shortcut, and Willy is supposed to climb his way up to the top of that room? ****** As for why the floor disappears, could it be because the attribute of the floor is set to the same as the air cells?

Incidentally, aside from the perhaps frivolous 'composite ropes', as seen in the test files above, the ability to set a rope's horizontal position at the individual pixel level could be useful for fine tuning a difficult game, where you want to ensure that a tricky jump onto or off of a rope is just about possible (if the player gets the timing exactly right), without actually becoming impossible!

I'm quite pleased with my successful implementation of the patch to 'Draw the Ropes', so that each rope's exact pixel-position can be specified on an individual basis. Firstly, the use of the XOR command to separate out, in a byte-efficient manner, the two components of a rope's definition byte 2 (i.e. the starting column in Bits 0-4, and the pixel-position in Bits 5-7). Secondly, the use of the SCF and RRA commands and a DJNZ loop, to convert Bits 5-7 in order to infill the appropriate pixel (set the correct single bit), in the graphic byte where the top segment of rope appears. I'll type up a disassembly when I get a chance. :)

There are some cool special effects in there - particularly the room where Willy is upside-down, and the one which looks like an old black & white TV set in which the picture drifts vertically - I was almost tempted to thump the top of my PC to see if it would fix it! :lol: