MM/JSW disassemblies: 20160511

[IRF]

It might be helpful for game designers incorporating Rooms 61-63 into a JSW48 game, if the disassembly were to provide the WRITETYPER Teleport codes for those Rooms.

 

(As you're aware, in the original game the addresses where those rooms would be are just filled with unused code.  Note that the JSW disassembly does provide the WRITETYPER code for Room 47, even though that room is also unused in the original game!)

 

As an educated guess, I would suggest that the pertinent Teleport codes should be as follows:

 

Room 61: 134569

Room 62: 234569

Room 63: 1234569

 

(Actually, it might be fun to try those out in original JSW and see where Willy ends up!!!)

Edited August 10, 2016 by IRF

[Spider]

I do like that idea.

 

I seem to remember that given the way (on a PC at least, a Mac might be a bit different) it can be difficult to get all the codes into the keyboard as the way the PC reads multiple keys being depressed is a bit different.

 

I could be wrong... :unsure:

[IRF]

The JSW Disassembly Trivia section mentions an unused Entity Definition (#2B - a vertical guardian, which draws upon the page of sprite data that contains the Skull and the Evil Priest sprites), and the unused guardian sprite (the 'Periscope', whose graphic bytes are on page #B1 - it subsequently appeared in JSW2).

 

However, I have just noticed an unused Entity Specification (sometimes referred to as a Guardian Instance), in the room data for 'The Hall'.  It seems to be another instance of the static 'Chandelier', one of which is already present in that room.  The second instance of it is there in the room's guardian list data, but because it follows after the 'FF' Terminator byte in the Guardian List, a second Chandelier doesn't actually appear in the game.  That's just as well, as its specified x-coordinate of 00 would cause it to block the route up the Ramp in that room, and cause an Infinite Death Scenario if Willy walked in from 'Ballroom East' along the middle platform!

 

(Presumably its second specification byte would have been adjusted to place it further to the right, if it had ever been used.  EDIT: In fact, now that I think about it, a value of '00' would also have caused it to select one of the 'Centipede Segments' from The Attic as its base sprite, which would look distinctly odd without a head!  Rather than the Chandelier base sprite, which would fit thematically with the room.  So it's clear that the second specification byte is simply set to '00' by default.)

 

Anyway, it's nice that the original game's data can still throw up the odd surprise, all these years later!  Perhaps this merits a Trivia entry in Richard's disassembly?

 

Incidentally, in recent projects (such as JSW The Nightmare Edition), we have been inserting more than one of the 'Chandeliers' into The Hall.  Following this discovery, it would appear that we may have been coming close to Matt Smith's early vision for this room?!

 

P.S. I've checked the data for the other rooms, and there aren't any other such instances of 'unused guardian specifications' in the original game code.

Edited August 17, 2016 by IRF

[IRF]

It's sometimes said that the unused Room 47 in original JSW was meant to be located above 'Conservatory Roof'.  This seems to be based on the fact that the value at #EFEC, in the code remnants that occupies the place where the room data usually sits, is set to #2D (Conservatory Roof's room number in hex).  Offset #EC in a room's data usually defines the Down Exit, but in this case the '2D' actually forms part of the operand of an unused CALL command.  So it's a rather spurious claim.  Indeed, the Up Exit from Conservatory Roof is set to The Off Licence.

 

However, the Right Exit from Tree Root is set to Room 47 (#2F) in the code, so the likeliest place where Room 47 would have been located, if it had ever been present in the original game, is to the right of Tree Root.  (Several modified games have in fact placed it there, I believe.)  Perhaps this merits a small mention in the Unused Room Trivia entry?

 

http://skoolkid.github.io/jetsetwilly/reference/facts.html#unusedRoom

Edited August 18, 2016 by IRF

[IRF]

Regarding the above, when Willy jumps off the top of the screen (actually wrapping round to the bottom, as Willy's y-coordinate can't be negative - you can briefly see his head below/within the platform at the bottom of the screen!), it also causes corruption to Room 7: Miner Willy Meets the Kong Beast. See the attached screenshots.

 

This occurs because, in trying to draw Willy at a y-coordinate greater than 224 (#E0), the routine at #927F (that is supposed to draw Willy's sprite to the Occupied Screen Buffer at #6000), over-shoots the bottom of the Screen Buffer Address Lookup Table (#8300-83FF), thus reaching code in the 'The game has just loaded' routine. There it picks up an address (specified at #8404) that corresponds to somewhere in cell-row 6 of page #CC of the code [amongst other addresses, which are mostly in the ROM and are therefore immune from being overwritten, although the stack address at #9CFE - as specified at #8402 - may also be overwritten in the process. I'm not sure whether that would have a detrimental effect on the operation of the program?]

 

The affected addresses are overwritten by some of Willy's sprite's graphic bytes (which are stored in the range #8200-82FF), although the location in Room 7's data to which those graphic bytes are written, means that they are interpreted by the room-drawing code as attribute bytes.

 

More specifically, values of '#3F' and '#F0' are written to #CCCB and #CCCC respectively. The former corresponds to a colour-attribute of 'White Ink on White Paper', hence the solid (non-Bright, non-Flashing) White block.

 

The latter 'F0' corresponds to a colour-attribute of 'Flashing, Bright Black Ink on Yellow Paper'. Because 'F0' also corresponds with a graphics byte specified in the Room 7 data (the top pixel row of the Conveyor tiles), the Cell-Graphics Bug also kicks in, and so the right-hand errant block (at #CCCC) has a non-blank pixel pattern: pixel-rows 0-6 correspond to the 2nd to 8th graphic bytes specified for the Conveyor, whilst the final pixel row of the new block is a graphical representation of the attribute byte for the Nasty 1 tiles (04 - Green Ink on Black Paper).

 

N.B. In terms of Willy's interaction with them, both of the newly-inserted blocks behave as Water cells.

See attached rzx recording.

 

Further to the above, whilst the left-hand 'errant' block appears as a solid White block (because both INK and PAPER are set to White), if you capture a screenshot at the point of Willy's death (when all filled-in pixels on the playing area progress through the spectrum of colours, whilst all non-filled-in pixels are rendered in Black), you can see that there is a pixel pattern 'behind the scenes' in that cell.  Please see the attached screenshot 'MM Room 7 Corruption 3' (which captures the 'Cyan' phase of Willy's 'death throes').

 

If you look at the left-hand rogue block (which lies above the left-hand edge of the conveyor, seven rows above), its pixel pattern doesn't match any of the pixel patterns of the various room elements for 'Miner Willy Meets the Kong Beast'.  (N.B. For comparison, I've also reattached here the earlier screenshot 'MM Room 7 Corruption 2', which was taken during normal play and so the same cell appears in solid White, with no pixel pattern visible.)

 

At the time when I previously reported on this issue, I was slightly puzzled as to where the mysterious pixel pattern came from.  But I've now figured it out!

 

Because the attribute value '#3F' doesn't match any of the attributes or graphics bytes for this room's cell types (i.e. none of the bytes in the range #CE20-#CE67), the CPIR loop at #8A96 progresses all the way to B=0 without finding a match.  At that point, HL has been incremented to #CE68 by the CPIR loop, and so by default the cell's graphics are drawn using the next eight bytes in that room's definition.

 

As the MM disassembly states, the next seven bytes [after the tile data] specify Miner Willy's initial location and appearance in the cavern:

 

CE68 DEFB $D0 Pixel y-coordinate * 2 - #D0 = 11010000 in binary, top pixel-row has Bits 4 and 6-7 set

CE69 DEFB $00 Animation frame - blank pixel-row

CE6A DEFB $00 Direction and movement flags: facing right - blank pixel-row

CE6B DEFB $00 Airborne status indicator - blank pixel-row

CE6C DEFW $5DA2 Location in the attribute buffer at 5C00: (13,2) - of course, these are reversed in the code, so #A2 = 10100010 appears above #5D = 01011101

CE6E DEFB $00 Jumping animation counter - blank pixel-row

 

Then the eighth graphics byte (bottom pixel-row), which just has a single pixel filled-in at the far right (i.e. Bit 0 set) corresponds to the next room definition byte at #CE68, which is actually meant to specify the direction of the conveyor in the room (value 01=right)!

 

P.S.  I believe that the above effect would still have happened with Stuart Brady's Cell-Graphics Bug Fix in place, as the room-drawing routine would still end up (albeit via a different method) with HL pointing at the same address (#CE68), in the absence of a match with the eight possible cell attribute values.

 

Whereas SkoolKid's alternative Cell-Graphics Bug Fix works differently (actually, he only provides one for JSW http://skoolkid.github.io/jetsetwilly/reference/bugs.html#corruptedConveyors, but if the same principle were applied to Manic Miner - even though the bug doesn't actually manifest itself in original MM); I believe that the modified routine would keep on searching through the code, skipping forward by 9 bytes each time, until it eventually finds a match, and then select the next eight bytes to use as graphics bytes for such a 'rogue' cell.  Although I've no idea what would happen if it reached address #FFFF without finding a match?!  (Any thoughts on this matter, Richard?)

 

P.P.S.  In Jet Set Willy, in theory the eight bytes after the room cell data (#80A0 to #80D5) could also be picked up as graphics bytes in a similar way - in that case it would be the Conveyor and Ramp definition bytes (4 bytes each) at #80D6-#80DD in the Room Buffer that would be selected.  However, I don't think that would actually occur in practice within JSW, because the code that distributes attribute bytes across the screen works quite differently, such that I don't think you'd ever end up with an 'errant' attribute value written to the Empty Room Attribute Buffer at the point when the screen is drawn (i.e. during running of the Room Set-up routine).

 

Now, Invalid Arrows (or Vertical Wraparound Guardians) can cause odd attribute values, which don't match any of the six cell types, to be written to the Empty Room Attribute Buffer.  However, this only occurs during the Main Loop, and so while it can alter Willy's (attribute-based) interactions with the affected cells, it doesn't affect how they are drawn (i.e. background cells are left as solid coloured squares - which behave as Water cells by default if they don't match one of the other cell types - and any existing pixel pattern in a non-Air cell, whose attribute is altered by an Invalid Arrow, is left unchanged).

Edited September 27, 2016 by IRF

[IRF]

A bit of further analysis of the above...

 

When Willy wraps beyond the top/bottom of the screen, it is the third pixel-row of the part of his sprite that wraps around, which is responsible for the graphical corruption of the screen 'Miner Willy Meets the Kong Beast'.  Two adjacent cells are affected, corresponding to the two halves of his sprite.

 

In the previous example, the corruption of 'Miner Willy Meets the Kong Beast' was caused by Willy jumping up (in The Warehouse, if I recall correctly) and his head extending above the top of the screen.  (Though in reality, his head was drawn at the bottom, and his legs extended beyond the bottom of the screen, as far as the Willy-drawing code is concerned - he is drawn from top to bottom.)

 

Because of the relatively limited extent to which his sprite wrapped around on that occasion, there was a greater chance of a pixel-pattern being observable in the room cells where the rogue attributes were drawn.

 

But if Willy drops through the floor, then he does so in four stages (half a cell-row at a time), before reappearing at the top of the screen.  In each time-frame when he is wrapped around, the pair of his sprite's graphic-bytes that are currently three pixel-rows below the bottom, are over-written onto the 'point of corruption' pair of room cells, via an OR command.  This means that by the time Willy has passed through the bottom completely (and starts to be drawn in his entirety at the top of the screen), it is more likely that at least one solid, Bright White square (representing a colour-attribute of #FF) will be written to the screen - because all eight pixels of the corresponding pixel-row will have been filled in at some point during the four-stage process of falling-off-the-bottom.  (Especially so if he is falling in his 'legs-apart' frame of animation.)

 

However, if you carefully study Willy's sprite data, alongside the room-cell data for 'Miner Willy Meets the Kong Beast', select the right frame of animation, get him to fall through the floor and then abandon the game at the right moment, then restart the game and revisit the screen, you can get this quirky corruption to 'behave' to a certain extent.

 

Please see the attached .rzx recording.  I managed to get Willy to fall through a hole in the floor in his right-facing Animation Frame 1, but then abandoned the game after only his feet (four pixel-rows, or half a cell-row of his sprite) had fallen through the bottom.  His 'legs together' frame meant that the left-hand half of his sprite wrote '#06' to one of the locations in the screen's attribute data - which is the same as the colour-attribute of the 'Switch' in this cavern - whilst the right-hand half of his sprite had no infilled pixels (i.e. a value of '#00'), so it caused no overwriting of the adjacent cell to the right.

 

You can see that when I restarted the game and teleported (using the WRITETYPER equivalent) to the Kong Beast screen again, a Switch had magically appeared halfway down the screen...

 

Note that the new Switch wasn't there at the start of the recording; it has been created by the process of Willy falling off the bottom of the screen in the previous game.  Note also that it doesn't act as a Switch for the purpose of opening up the doorway between the two halves of the screen, or making the Kong Beast fall.  It does act like a Water cell though; Willy can jump through it, but he can also stand on it.

 

I then went on to fall through the bottom of the cavern completely, and then after losing a life - causing the screen to be refreshed - the Switch had been replaced by a solid White block (which also acts as a Water cell).

Magic Switch.rzx

Edited September 15, 2016 by IRF

[jetsetdanny]

Very interesting, Ian! Thanks for the analysis and the recording  :) .

[IRF]

Incidentally, the first character of the scrolling message at #9400 has also been altered in that 'Manic Miner Corrupted' file (from a full-stop into a 'tilda'), because the message immediately follows on from the base of the stack at #9CFE-FF, which is also overwritten. (Luckily that doesn't seem to affect the contents of the stack, such as Return addresses, etc, which are placed at #9CFC-FD and upwards.)

Edited September 21, 2016 by IRF

[IRF]

Richard, for this section of the JSW disassembly:

 

http://skoolkid.github.io/jetsetwilly/asm/8D33.html

 

regarding the RETURN command at #8D6A, I think it would be helpful to the reader if you added a note adjacent, something to the effect that:

 

The first time this RET command is reached, it returns the program back to $8D42 (in order to draw the tiles for the bottom half of the room to the screen buffer at 7000). The second time this RET command is reached, it returns the program to the

Edited November 7, 2016 by IRF

[IRF]

Manic Miner disassembly, #8E5F is described as "Save the INK colour in the attribute buffer temporarily" (for vertical guardians, etc) - technically, the BRIGHT value of guardians is also stored by this command.  (See three of the vertical guardians in 'The Warehouse', for example.)

 

EDIT: Although the 'Angry Eugene' code that flows straight into #8E5F does discount the BRIGHTNESS bit (via an AND #07 at #9E5D).

Edited November 15, 2016 by IRF