SkoolKid

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

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

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.

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.

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.

Has anyone noticed the instance of the Cell Graphics Bug affecting the Fire cells in 'A Bit of Tree' in the original JSW?
 
It isn't documented anywhere in SkoolKid's JSW disassembly, I don't recall Stuart Brady mentioning it when he introduced his Cell Graphics Bug Fix, and a search in the Yahoo Group has drawn a blank.
 
However, I find it hard to believe (in fact incredible!) that this hasn't been spotted before!?

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.

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

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

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.

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

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

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

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.

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.

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.

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

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.

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

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

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.

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.

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