SkoolKid

My earlier answer covers snapshots, but for TAP files, there's always a loader, even if it doesn't look like it. Most emulators have the ability to 'fast load' TAP files, which means the USR command in the BASIC loader is executed almost immediately, without you having to wait for the tape to play in real time.

Are you asking how an emulator knows where to begin execution when loading a snapshot file?
 
If so, the answer is that the emulator takes the value of the program counter (PC) that is stored in the snapshot file. In a SNA file, PC is stored at the top of the stack (and must be popped off before execution begins). In a Z80 file, PC is stored in the header (like all the other register values). In an SZX snapshot, PC is stored in the ZXSTZ80REGS block (along with all the other register values).

Phew! :)
 
I've just read the 'Through the wall' description a few times to get it straight in my head, and I must admit I'm not seeing the discrepancy between the text and the pictures.
 
When I say that there is a nasty tile below Willy's sprite in step 16, what I mean is that when the nasty tile check is made at the point when the jumping animation counter is 16, Willy's x-coordinate has not yet been updated from what it was in step 15 - at which point there is a nasty tile below Willy's sprite. (His x-coordinate is updated before he's drawn during step 16, though.)
 
Perhaps the wording doesn't make that clear enough. Would it help if I stated the actual x- and y-coordinate values when the nasty tile check is made?

Are you asking how an emulator knows where to begin execution when loading a snapshot file?
 
If so, the answer is that the emulator takes the value of the program counter (PC) that is stored in the snapshot file. In a SNA file, PC is stored at the top of the stack (and must be popped off before execution begins). In a Z80 file, PC is stored in the header (like all the other register values). In an SZX snapshot, PC is stored in the ZXSTZ80REGS block (along with all the other register values).

Actually, Willy gets an extra life only when the thousands digit is rolled over from 9 to 0, so that POKE won't give rise to a too-many-lives problem.

Regarding unused code: the table of unused blocks is generated automatically, and I can't add an entry for a section of code/data that's embedded in a block. I could add some intro text to the 'Unused addresses' page that lists such sections, though.
 
Regarding the item below the portal in The Sixteenth Cavern: after looking at the code, I'm sceptical that Willy doesn't get 100 points for collecting the item - the points are added at the same time as the item is collected. You could try POKE 36739,41 to check this - it would award 100,000 points per item collected, which is more obvious than 100. (Actually, that's a good candidate for the POKEs page.)

Rather than announce this in the existing disassemblies thread, I thought I'd start a new one to rebase the feedback (as it were). I've just made a new cut of the MM/JSW disassemblies:
 
Manic Miner disassembly (decimal) (download here)
Jet Set Willy disassembly (decimal) (download here)
Manic Miner disassembly (hexadecimal) (download here - click 'Download ZIP')
Jet Set Willy disassembly (hexadecimal) (download here - click 'Download ZIP')
 
To see what's new, check the changelogs: MM, JSW.
  As always, comments and bug reports are welcome!

Rather than announce this in the existing disassemblies thread, I thought I'd start a new one to rebase the feedback (as it were). I've just made a new cut of the MM/JSW disassemblies:
 
Manic Miner disassembly (decimal) (download here)
Jet Set Willy disassembly (decimal) (download here)
Manic Miner disassembly (hexadecimal) (download here - click 'Download ZIP')
Jet Set Willy disassembly (hexadecimal) (download here - click 'Download ZIP')
 
To see what's new, check the changelogs: MM, JSW.
  As always, comments and bug reports are welcome!

And so the TODO list starts filling up again. :)
 
I've started a new thread in this forum to announce the disassembly updates, but it's still in moderation. Once it's accepted, let the comments and suggestions begin...

Rather than announce this in the existing disassemblies thread, I thought I'd start a new one to rebase the feedback (as it were). I've just made a new cut of the MM/JSW disassemblies:
 
Manic Miner disassembly (decimal) (download here)
Jet Set Willy disassembly (decimal) (download here)
Manic Miner disassembly (hexadecimal) (download here - click 'Download ZIP')
Jet Set Willy disassembly (hexadecimal) (download here - click 'Download ZIP')
 
To see what's new, check the changelogs: MM, JSW.
  As always, comments and bug reports are welcome!

And so the TODO list starts filling up again. :)
 
I've started a new thread in this forum to announce the disassembly updates, but it's still in moderation. Once it's accepted, let the comments and suggestions begin...

And so the TODO list starts filling up again. :)
 
I've started a new thread in this forum to announce the disassembly updates, but it's still in moderation. Once it's accepted, let the comments and suggestions begin...

'AND #C0' sets the zero flag if A holds any value from 0 to 63 (00-3F), and 'AND #E0' sets the zero flag if A holds any value from 0 to 31 (00-1F).
 
Note that you can't use 'AND N-1' to set the zero flag on every Nth pass through a loop that increments A unless N is 1, 2, 4, 8, 16, 32, 64, 128 or 256.

'AND #C0' sets the zero flag if A holds any value from 0 to 63 (00-3F), and 'AND #E0' sets the zero flag if A holds any value from 0 to 31 (00-1F).
 
Note that you can't use 'AND N-1' to set the zero flag on every Nth pass through a loop that increments A unless N is 1, 2, 4, 8, 16, 32, 64, 128 or 256.

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

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, 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? :)

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).

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!

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. :) )

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

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

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