Willy disassemblies in hexadecimal

[SkoolKid]

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.

[Spider]

Great. :) Thank you.

 

I'll be honest I prefer decimal as I find it easier. I really only know a couple of #hex values that have been permanently saved in my head.

[jetsetdanny]

That's fantastic, Richard, thank you! I have been using your JSW disassembly all the time while working on various tweaks to the code recently, but I had to convert everything to Hex to be able to compare and use it in JSWED's hex editor. It will be so much easier now! :)

[Spider]

I noted the recent updates too. Its interesting to see (and I'm pleased too) that some of the newer 'bug fixes' you've indicated for JSW are not far off what I did with the 'bug fixed' edition. :)

[IRF]

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.

 

Hello SkoolKid,

 

May I also suggest that the 'White-seeking missile' entry in the Trivia section mentions the fact that arrows can collect items, and also makes it more explicit that if an arrow hits a White guardian, then this is fatal to Willy.  (The implications of an arrow hitting a White rope are pointed out, but not a White guardian in explicit terms.)

 

Neither of these things occur in the original JSW layout, but they are useful to know about if you are designing your own layouts or modifying the original!

[IRF]

Oh, another thing - the hex version of the disassembly isn't fully in hex - the entity definitions (I think this is an equivalent term to Guardian Classes?) are listed in decimal. It would be handier for comparison with JSWED if they were numbered in hex.

 

e.g. Entity definition 49 as listed in the disassembly (Yellow Chef) is Guardian G31 in JSWED. [49 in decimal = 31 in hex.]

 

Although I appreciate it would require a lot more manual work to alter all the entries in the list of entry definitions and the mentions of them in the page for each room!

Edited January 19, 2016 by IRF

[SkoolKid]

May I also suggest that the 'White-seeking missile' entry in the Trivia section mentions the fact that arrows can collect items, and also makes it more explicit that if an arrow hits a White guardian, then this is fatal to Willy.  (The implications of an arrow hitting a White rope are pointed out, but not a White guardian in explicit terms.)

 

Neither of these things occur in the original JSW layout, but they are useful to know about if you are designing your own layouts or modifying the original!

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.

[SkoolKid]

Oh, another thing - the hex version of the disassembly isn't fully in hex - the entity definitions (I think this is an equivalent term to Guardian Classes?) are listed in decimal. It would be handier for comparison with JSWED if they were numbered in hex.

 

e.g. Entity definition 49 as listed in the disassembly (Yellow Chef) is Guardian G31 in JSWED. [49 in decimal = 31 in hex.]

 

Although I appreciate it would require a lot more manual work to alter all the entries in the list of entry definitions and the mentions of them in the page for each room!

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

[IRF]

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 fact, any White guardians can collect items (try placing one in Back Stairway in the path of the 'spinning coin').

[IRF]

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

Hello Richard,

 

The following doesn't relate specifically to the use of base 10 or hex, but I thought I'd point it out here anyway:

 

In the 'Corrupted Conveyors' section of your disassembly, the conveyor in The Nightmare Room has only been partially fixed by the cell-graphics bug patch.

 

If you study The Nightmare Room layout (see the 'Unfixed' attached image), by looking carefully at the ramp graphic you can see that there is an odd 'air gap' at the base of the ramp cells. This is because the bottom row of pixels is supposed to be the colour-attribute byte for the conveyor cell in that room (bearing in mind that conveyors are drawn immediately after ramps in JSW).

 

In all likelihood the bottom row of pixels of the ramp cell was supposed to be entirely filled in (with White Ink); Matthew Smith must have written the colour-attribute byte for the conveyor cells (00000010) one byte too early in the code (N.B. the colour-attribute byte for a particular cell type is located immediately before the 8 bytes corresponding to that cell type's pixel pattern, and also immediately after the 8 bytes for the pixel pattern of the preceding cell type - which in the case of conveyor cells is ramp cells).

 

That then had a knock-on effect on both the colour attributes and the pixel pattern of the conveyor cell, because all the subsequent bytes that determine each row of the conveyor's pixel pattern were shifted one row upwards. With the top row of pixels being misinterpreted as the colour-attribute byte for the conveyor, giving rise to the awful flashing Green/Cyan colouration (which doesn't look good even with the cell-graphics bug fix in place).

 

However, if you look at the attached 'Graphics Fully Fixed' screenshot, you will see that this 'misplaced attribute-byte bug' has been fixed. You can observe that:

• The bottom pixel row of the ramp (the 'air gap') has been filled in, so that now the ramp cells are all White except for an arrangement of Black pixels that exactly matches the pixel pattern that is seen in the adjacent Earth cells (so that the Ramp cells seamlessly 'blend in' with the Earth cells, as is often the case throughout the JSW layout e.g. Master Bedroom, Back Door, The Drive, The Bridge);
• What was previously the pixel pattern of the ramp's bottom row (00000010) has instead now been interpreted (correctly) as the colour-attribute byte for the conveyor (it translates as non-flashing Red Ink on Black Paper). The colour scheme of the conveyor now looks much better than either the 'Before' or 'After' conveyor graphics (as displayed in the 'Corrupted Conveyors' section of your disassembly);
• The byte that was previously (erroneously) taken as the conveyor's colour-attribute byte (10100101 - which translates as Flashing Cyan Ink on Green Paper), has been shifted to become the upper pixel pattern of the conveyor cell;
• All the following pixel rows in the conveyor cell have as a consequence been cascaded down by one row. The conveyor cell now looks much better; notably, you can see that the first and third rows of the conveyor cell have matching pixel patterns (except that the third row is inverted: 01011010);
• Note that it is the pixel patterns in the first and third rows of conveyor cells that give rise to visible animation. And in the previous conveyor graphic for The Nightmare Room (even with the cell-graphics bug patch in place), the first and third rows were either both entirely unfilled in or both solidly filled in - the cell is also flashing so it's hard to tell which of those two is the case - but either way the effect was that there was no animation visible in the conveyor graphic. But now that all the pixel rows have been shifted down by one row, with the top row being filled in by 10100101 (previously misinterpreted as the horrible Cyan/Green colour scheme), and the third row its inverted equivalent (01011010), you can see visible animation in both first and third rows.

Stuart Brady and I came up with this further fix for both the ramp and conveyor cells in The Nightmare Room, and we are convinced that their pixel patterns and colour schemes are now in accordance with what Matthew Smith intended way back in 1984.

Edited February 10, 2016 by IRF