SkoolKid

Have you checked whether the Cell-Graphics Bug affects any cavern elements in Manic Miner?

I have, and the answer is no, it doesn't.

Has anyone noticed the instance of the Cell Graphics Bug affecting the Fire cells in 'A Bit of Tree' in the original JSW?

Can't say I have - time to update my JSW disassembly TODO list. :)

By the way, I checked and this is the only instance of a non-conveyor tile being affected by the Cell-Graphics bug.

One advantage of generating an ASM file from the SkoolKit source files is that it retains all the annotations. You can also generate an ASM file that includes several bugfixes:

skool2asm.py -f 2 jsw.skool > jsw-bugfixes.asm

Did you mean it should be possible to generate an as from the skoolkit files?

Yes, you can generate an assembler-friendly ASM file from the SkoolKit source files for MM or JSW. In fact, that's one of the main points of SkoolKit - you can use the same source files to generate both the HTML disassembly and an ASM file.

You will need to download SkoolKit - for which you'll also need Python, version 3.4 or later - and use skool2asm.py to convert jsw.skool into jsw.asm (for example):

skool2asm.py jsw.skool > jsw.asm

I've successfully tested the output of skool2asm.py with pasmo, SjASMPlus and z80asm (the assembler that comes with z88dk), but it might work with other assemblers too.

Is there any good reason (e.g. in terms of the effect on the Flags, perhaps?) why the original game engine uses an XOR command at #91FB, instead of an OR?

 

http://skoolkid.github.io/jetsetwilly/asm/91BE.html

 

It's the instruction which merges a guardian's INK colour and BRIGHT value (Bits 0-2 and 6) with the PAPER colour (Bits 3-5) of its host cells.

No, there's particular reason to use XOR instead of OR here. As you've noted, there's no difference in the resulting value in the A register, and there's also no difference in the effect on the flags (which are not checked anyway).

This bug just got more interesting! :)

I think I know why Willy is relocated further down the rope on your first attempt: in the section of code that handles Willy's movement along the rope, the rope status indicator is reset to 12 if it's found to be 11 or less. How you then manage to circumvent that code in your second attempt, I have no idea yet.

N.B. The Cyan 'Kong caverns' guardians are present when you play the game!

Oh, I know that - what I meant was that they are erroneously skipped by my cavern-drawing code.

I don't know if I've mentioned this before, but none of the images in my disassemblies are derived from in-game screenshots - they are all programmatically generated.

Also, you might be able to answer a query I had a while ago about the area of the 'contended memory' #5B00-5BFF.  The 'top end' of it seems to be used for the stack addresses in JSW (starting at #5BFE-FF), but does it have any other use than that?  #4000-#57FF is the display file, #5800-#5AFF is the attribute file, and the JSW buffers begin at #5C00 - so 'page' #5B fits in between those.

As far as I know, the printer buffer (5B00-5BFF) is used only by the stack - the stack pointer being 5C00 when the game starts.

Richard, I've just noticed that neither of the two 'Kong Beast' screenshots in the MM disassembly display the Cyan horizontal guardian!?

 

Also, the comment at #91EE caused me momentary confusion; perhaps it should read: "The Kong Beast is drawn with Yellow Ink when he is falling"?

Regarding the cyan guardians in the Kong Beast caverns: well, well, well! My first thought is that because the third horizontal guardian in those caverns is unused, the fourth one (the cyan one) is erroneously skipped. I will look into it...

Regarding the comment at 91EE: the comment at the beginning of that section of code (at 91A3) says "The Kong Beast is falling", but I suppose you might have forgotten that by the time you reach 91EE. :)

Just checking in to acknowledge the comments and see what new stuff I should be adding to my MM/JSW disassembly TODO lists! :)

I've been preoccupied recently with SkoolKit 5.3 and the Spectrum ROM Disassembly, but I'm going to take a break from those and concentrate on MM and JSW for a bit. Now, where were we the last time I was here...

Okay, perhaps it should read "From F+1 to F+32", as the table isn't used to calculate an offset when L=0.

But this implies that the first pair of offsets at 8300/8380 are not used, and that the pair at 8356/83D6 are used. You see my confusion?

I need to (re)examine the code closely at some point to figure out what's going on.

32 offsets during each animation frame.

So why should the text read "from F to F+32" (33 offsets) instead of "from F to F+31" (32 offsets)?

I'm really confused now! Let me put the questions another way.

1. How many pairs of x- and y-offsets are used to draw the rope during each animation frame: 32 or 33?

2. Is the pair of offsets at 8300/8380 used?

3. Is the pair of offsets at 8356/83D6 used?

No, they are used.  Segment Zero doesn't have an offset applied to it - it is at the top of the screen, in the same horizontal position regardless of the value of the Rope Animation Frame.  Bytes #8300 and #8380 are picked up to determine where to draw Segment 1 when the Rope Animation Frame is at 0.

Isn't that a contradiction? If only segments 1-33 have x- and y-offsets applied to them, and the bytes at 8300/8380 are used for segment 1, then the bytes at 8356/83D6 are unused - and the text as it stands now is correct: entries from F to F+31 inclusive.

JSW disassembly Rope animation table #8300:

 

"For a given rope animation frame F (0<=F<=54), the 32 entries from F to F+31 inclusive (one for each segment of rope) in each half of the table are used; thus the batch of entries used 'slides' up and down the table as F increases and decreases."

 

That should read "from F to F+32" - the first segment of the rope is Segment 0, so there are 33 in total, not 32.

In which case the zero bytes at 8356 and 83D6 - currently marked as unused - are in fact used. Which also means that when the rope is the leftmost or rightmost extent of its swing, the last segment is not drawn in the correct place (the bytes at 8356 and 83D6 should probably be 3 and 4 respectively). Which is a bug.

Is this actually the case? Investigation needed!

By the way, I hope you don't mind these occasional comments and suggestions? Your disassemblies are fantastic resources, and hugely helpful in gaining an understanding of the code. If I come across as pedantic it's only because I believe that 'tweaks' such as this could help readers who follow after me to gain a similar level of understanding!

No, not at all - keep them coming! I want the disassemblies to be as accurate and comprehensive as possible, and I'm always happy to receive new trivia suggestions and bug reports.

I play files using an online emulator called QAOP.

 

I just click 'Open' and then browse for a file (sometimes they're .tap files, sometimes .z80).

 

The emulator seems to go straight to the Title Screen with no bother. Therefore, as far as I am aware, no 'loader' is involved in the process?

 

I was just wondering how the emulator knows where to begin?

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.

But if I'm running game files on an emulator, with no loader, how does it know to start at #8400?

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

Richard,

 

Sorry to be a pain, but I don't think your latest iteration of the 'Through the Wall' entry in your Manic Miner disassembly is quite accurate yet:

 

[snip]

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?

It's easily checked, especially with that POKE - which incidentally, will set the Screen Flash off (and increment the lives) every time an item is collected!  N.B. Care might be needed in case the remaining lives display runs off the edge of the screen and causes corruption elsewhere?

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

I've just noticed that Richard has made quite a few updates to his Jet Set Willy disassembly, and also to his Manic Miner one.

 

Thanks for the credits, Richard - and also for the handy hint regarding the Solar Power Generator in MM!

 

One thing I just thought of for the next update - you mentioned that the Saw in Cuckoo's Nest only uses four of the eight available frames of animation.  However, there's also the 'disrespectful Monk' in The Chapel, who always faces away from the altar!

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.

Wouldn't POKE 35770,201 turn crumbly platforms off? (And POKE 35770,77 would turn them back on?)

If we could bind this operation to a key in 10 POKEs or fewer, I'd consider including it!

I'm not sure about 'aura', because an aura is usually depicted as brighter than the surroundings (like a halo). If there is a generic name for a field of differing brightness around a body, I'm not aware of it.

'Guardian Brightness Bug' would be more accurate, but also less interesting.

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