SkoolKid

No, there's no trigonometry involved. :) Here's the explanation I've included in the bug description: "The number 15 here determines the highest segment of rope that Willy can reach (originally 12). At segment 15, Willy's y-coordinate never goes below 25 while he's on the rope, and is adjusted down to 24 (see 36782) when he jumps off, which is too far from the top the room (the maximum height Willy can jump is 20 pixels). At segment 14, Willy's y-coordinate never goes below 23 while he's on the rope, but is adjusted down to 16 when he jumps off, which is close enough to the top of the room to be able to jump through it." You can see the full text in the git commit: https://github.com/skoolkid/jetsetwilly/commit/99733c6c4708b86b9c58f2369934d02a43ee7c1b

Thanks for the RZX. I didn't think of trying to get onto the floor tile in The Forgotten Abbey before entering The Wine Cellar! I'll have to give the Dr Jones manoeuvre a try some time...

Ah, I see what you mean. Yes, the images are 'mocked up' in that sense, but then so is every other image in the disassembly. (And every image in the MM/SD/BTS/CSC disassemblies too.) I started playing it, and I have to admit I soon gave up! Does the WRITETYPER cheat work, by any chance? :)

And my own investigations have confirmed that value of 15 as the minimum. I've already written up the bug description, and it includes an explanation of why 15 is the minimum value.

No, I can't say I was aware of that, although it does make sense given how the game engine works. (My lack of JSW modding experience is clearly showing here. :) )

No, I'm pretty sure I intended the images to reflect exactly where Willy is drawn - instead I must have mistakenly assumed that he's drawn at the coordinates where the nasty tile check takes place. I think it would be fairly simple to rearrange the code so that both coordinates are updated before the check takes place - no idea about unintended consequences, though!

And another one for the trivia entry TODO list. Thanks!

I've never seen that happen before. Do you have an RZX that demonstrates this bug?

You're right - I hadn't noticed that before. I'll update the images and description in 'Through the wall' accordingly. Thanks! By the way, the reason for the mismatch you've noticed is that the check for nasty/fire cells below Willy takes place after his y-coordinate has been updated but before his x-coordinate has been updated. In other words, the code is looking for danger at (x-1,y) instead of (x,y) (where (x,y) are Willy's new coordinates).

Can you explain how Willy can get stuck inside Earth cells (wall tiles?) in The Wine Cellar, for example? I'm not seeing it.

Yes, Willy's animation frame is either 0 or 2 during the toilet dash, because it's incremented from 3 or 1 by the 'Move Willy' routine on the next pass through the main loop before he's drawn. I'll add a note to the comment to make that clearer.

Well spotted! Another item for my TODO list...

I don't think it would be a problem. The rope's buffer would extend beyond the entity buffer at 8100 into the first and third bytes of the unused area that follows at 8141. It wouldn't corrupt the layout of any other room. See also The encroaching rope.

I'd definitely count this as a bug too - and I didn't have a description of it anywhere in my notes, so thanks for bringing it to my attention! I'll have to examine the code closely to see what the smallest value is that can be POKEd into 37782/6 to prevent Willy from jumping through the top of the screen...

Bytes DF and E0 are definitely unused in every room. At least in the original JSW.

And here's how to do it using SkoolKit and Windows PowerShell: > echo "b 49280" "T 49280,32" "L 49280,256,60" | sna2skool.py -c - jsw.z80 | select-string DEFM | %{$_ -replace '.*DEFM ', ''} This might not be the best way (PowerShell is not my first language), but I think it works.

Here's how you could do it in one line with SkoolKit (on Linux, and possibly OS X): $ echo -e 'b 49280\nT 49280,32\nL49280,256,60' | sna2skool.py -c - jsw.z80 | grep -o '".*"' This produces the following listing: " The Off Licence " " The Bridge " " Under the MegaTree " ... " The Yacht "

All suggestions duly noted... One thing I didn't mention in my first post is that, just like the decimal versions of the disassemblies, copies of the hexadecimal versions are available for download (for offline viewing). To download the hex version of the JSW disassembly, first go to the gh-pages branch of the jetsetwilly repo on GitHub: https://github.com/skoolkid/jetsetwilly/tree/gh-pages and then click the 'Download ZIP' button. The same applies to the hex version of the Manic Miner disassembly: https://github.com/skoolkid/manicminer/tree/gh-pages Just pointing this out because it's not obvious unless you're already familiar with GitHub's interface.

Very interesting. I find your argument compelling! I'll add a note to the 'Corrupted conveyors' item about this - or add a new item - for the next release. Thanks!

There are other places too in these disassemblies where hexadecimal numbers would be more appropriate than decimal (e.g. the Codes table in JSW), and solving this problem is also on my TODO list for future releases. The tricky part is that the solution must enable me to build either a fully decimal or a fully hexadecimal disassembly from the same source files, with no manual base-conversion work required. I have some ideas about how to do it, but they involve some changes to SkoolKit. In the meantime, feel free to point out other places where the use of base 10 is jarring or inconvenient, and I'll make a note of them. :)

Actually, the fact that arrows can collect items deserves its own trivia entry - I'll add that to my TODO list for the next release. Thanks! In the 'White-seeking missile' entry I hope I've made it clear that arrows don't mix well with anything white, whether it's guardians, wall blocks, floor blocks, nasties etc. The white rope is just a good example of something to be avoided when arrows are around.

Hello all Since I completed and published my MM/JSW disassemblies just over a year ago, one or two people have asked for hexadecimal versions. Now that I have a lazy, scripted solution for publishing such disassemblies on my GitHub pages, I present: The complete Manic Miner RAM disassembly (hexadecimal version) The complete Jet Set Willy RAM disassembly (hexadecimal version) I hope the fans of base 16 among you will enjoy these versions! Of course, the original decimal versions are still available at skoolkit.ca.

Leaving single POKE mode for a moment, here's my first attempt at fixing the bug that misdraws the conveyors in West of Kitchen, The Nightmare Room, The Wine Cellar, and Tool Shed: POKE 36178,151 POKE 36181,9 POKE 36183,205 POKE 36184,38 POKE 36185,255 POKE 65318,9 POKE 65319,190 POKE 65322,75 POKE 65323,35 POKE 65324,201 That's ten (10!) POKEs in total, which is a disgustingly large amount. Does anyone know of a smaller set of POKEs that achieve the same result?

Thanks for the shout-out on the Yahoo! group! Just so it's clear to anyone interested in a hexadecimal version of the JSW (or MM) disassembly, the "maintenance burden" I mentioned has nothing to with building it, and everything to do with publishing it and keeping it up to date. Building it is simple, and in fact instructions on how to do so are included in the readme.txt file in the downloadable version at http://skoolkit.ca/?page_id=113. To build the hexadecimal version instead of the default decimal version, you just need to use the '-H' option of skool2html.py: skool2html.py -H jet_set_willy.ref

jetsetdanny: no offence taken - I really do wish I had called it "Yet another disassembly of JSW", as a nod to all the partial disassemblies already available on the internet! I have considered publishing hexadecimal versions of all the disassemblies on skoolkit.ca, but then laziness kicked in as I realised what an extra maintenance burden that would be. However, anyone else is free to build and publish my disassemblies on their own site, so I encourage that option instead. (Let me know if you need any details on how you or a friend could build a hexadecimal version.) As for the sticky bed bug - you know, I could have sworn I tried all the "right" keys to get off the bed when I was verifying the bug, but obviously not! Thanks for the info. I will add a correction to the next release of the disassembly.