Willy-Longwalk.gif (4471 bytes)Willy-Longwalk.gif (4471 bytes)
Manic Miner Room Format

Back ] JSW Remakes Home ] Up ] Next ]
JSW1-bathroomfloor.gif (1468 bytes)

06020
visitors to
this page since
21-09-2000

 

Discussions

View Guestbook
Sign Guestbook


decoboot.gif (4103 bytes)


Manic Miner Room Format

by Andrew Broad

This document updated 5th January 2000 - changes since previous version (17th November 1999):


Introduction

Welcome to my Manic Miner Room Format! I figured all this out for myself by eyeballing the data and experimenting. That was back in 1992, before I had access to the Internet, therefore I had no idea that other people have also written Manic Miner editors and unofficial sequels! But as far as I know, this is the only technical specification for Manic Miner on the Internet, and none of the existing editors - except my own Manic Miner Screen Editor which has now been released - appear to have all this knowledge built into them! Everything you ever wanted to know about the room format is here, plus I impart lots of tips on creating special effects as well as pointing out the pitfalls to avoid!

I did this for Jet Set Willy as well, but Arsen Torbarina has already put a JSW Tech Page on his JSW Ultimate Fan Page, so there goes my novel contribution! ;-( If it's Jet Set Willy you're interested in, I suggest looking there, and also reading this document because many of the tips mentioned here apply to Jet Set Willy too! Serious JSW hackers may also be interested in John Elliott's disassembly of the Jet Set Willy engine and his Jet Set Willy II Room Format.

It is very encouraging to see the inventive uses to which the information in this document is being put. I envisaged that people would use it to hack directly into the Manic Miner code or even to write their own editors (Stuart Brady is writing a Manic Miner level editor for Linux), but it is also proving useful for other tasks such as converting Manic Miner to run on other computers (e.g. Garry Lancaster's Manic Miner `88), or mechanical transformations (e.g. Philip Bee is working on laterally inverting (`mirroring') the Manic Miner rooms, and I'm planning to write programs to map between Manic Miner and Jet Set Willy in the future).

I assume the reader has a basic grounding in data representation and computer architecture, a good working knowledge of the Sinclair ZX Spectrum, and some experience of playing Manic Miner. If not, then take a degree in Computer Science at the University of Manchester, get yourself a Spectrum emulator, and download Manic Miner from World Of Spectrum for it! And do check out my fabulous games!!


Copyright Notice

Copyright in text of this document rests with the Author (Andrew Broad). I'm a very reasonable person when it comes to my own copyright: I don't mind you putting a copy on your own website (my website won't be here forever in any case :-(), but if you do, please have the decency to let me know if possible (my current email address is broada@cs.man.ac.uk but I might have to do a Matthew-Smith-like disappearance in the future! :-)).

If you do publish a copy elsewhere, you may edit the HTML as long as you leave the actual text alone (some introductory text by the host at the top of the document is acceptable, but please leave the rest as it is). You must acknowledge me as the author. You should periodically check the original location of this document (http://www.cs.man.ac.uk/~broada/spectrum/willy/format.html) to see if it has been updated (or reappeared - my website has already gone AWOL once due to personal problems).

Known `mirror sites' for this document (please let me know of any others):


The Technical Stuff

Manic Miner's rooms are stored in memory addresses 45056 to 65535, so although the complete game is stored from 32768 to 65535, there is no need to edit 32768 to 45055 to redesign the caverns! Appendix E contains the odds and sods that I have discovered about addresses 32768 to 45055 (specifically, I have found out about the graphics for Miner Willy, the in-game tune, the title screen/Room 19 picture, colour attributes for title screen and for the bottom eight rows below the playing area; the title screen scrolly and other pieces of text).

Each room r is represented as a 1024-byte contiguous block of memory, starting at address 45056 + 1024*r {0 <= r <= 19}, where Room 0 is the first room ("Central Cavern" in the original Manic Miner) and Room 19 is the last room ("The Final Barrier" in the original Manic Miner).

Each byte of room data is offset from the start address of the room by i bytes {0 <= i <= 1023}, so the datum at Offset i in Room r is held at address 45056 + 1024*r + i.

Contents

The rest of this document specifies the data represented at the various offsets within a room:


Offsets 0 to 511: Screen Layout

The blocks on the screen are represented as a sequence of 16 rows, each of which consists of 32 characters, one byte per character.

  • Each row r {0 <= r <= 15}, where 0 is the top row and 15 is the bottom row, is stored at offsets 32*r to 32*r + 31.
  • Each character c within a row {0 <= c <= 31}, where 0 is the leftmost character and 31 the rightmost character, is stored at offset 32*r + c from the start address of the room.

Each character is the colour attribute of the block at that position on the screen (see Appendix A for a specification of colour attributes). These colour attributes correspond to the ones defined for the block graphics, and care must be taken that they agree, because an attribute in the screen layout which does not map to any block graphic in this way will be interpreted as an undefined blob on the screen! (such blobs usually behave like regular floor, but don't count on it!). Room 2 of Craig Rothwell's Manic Miner 7 ("The Menagerie") has such undefined blobs in it - that room has /nine/ different colour attributes in its screen layout!

Note that it's possible to design a room so that Willy can go off the edge of the screen, though this can never happen in the original Manic Miner caverns. When this happens, he appears on the other side of the screen. Manic Miner 2 uses this trick heavily, but there are bugs associated with it as Manic Miner wasn't really designed to allow this. The manoeuvre is juddery (basically, if Willy goes off the right of the screen, he goes down one character row; if Willy goes of the left of the screen, he goes up one character row), and if it's off the top or bottom of the screen, it corrupts memory so that:

  • In games based on the First Edition of Manic Miner (Bug-Byte, 1983), some blocks in the screen layout of Room 7 ("Miner Willy meets the Kong Beast" in the original Manic Miner) get corrupted. This is ugly but fairly harmless.
  • In games based on the Second Edition of Manic Miner (Software Projects, 1983), the guardians in Room 8 ("Wacky Amoebatrons" in the original Manic Miner) get corrupted, killing you as soon as you enter that room!

So if you want to let Willy jump off the top of the screen or fall off the bottom, as happens on several occasions in Manic Miner 2 and Manic Miner 4, you should base your game on the Bug-Byte version of Manic Miner.

Title Screen Graphics in Room 19

Room 19 ("The Final Barrier" in the original Manic Miner) has the title screen picture on the first eight character rows of the screen (the picture showing the sunny lake, the house and the car). The picture overrides the pixel patterns for any blocks which occur at the corresponding positions in Room 19.

The picture's colour attributes are stored in the screen layout for Room 19, which means they can be edited by editing the room, which changes the colours both on Room 19 and on the title screen, as I do in all my Manic Miner games.

The picture itself (i.e. the pixels but not the colour attributes) is stored separately from the room data (in addresses 40960 to 43007 - see Appendix E). This means that the picture still gets displayed on edited versions of Room 19, independently of the colour attributes defined there. This has implications for the collision detection algorithm for guardians, which is pixel-based (so avoid having guardians in the top half of the screen unless you are sure that their `on' pixels won't touch any of the picture's `on' pixels). It does not affect the behaviour of the blocks as far as Willy is concerned, because that behaviour is attribute-based.


Offsets 512 to 543: Room Name

A room name is represented in exactly 32 bytes, one byte per character, where Offset 512 is the leftmost character and Offset 543 is the rightmost character.

The characters are encoded in the well-known ASCII text format, which I'm sure needs no introduction to serious readers of this document! I would merely recommend that you stick to ASCII characters 32 through 127, using spaces (32) to pad out the name, as codes outwith this range are likely to be interpreted in strange ways! Ignacio Pérez Gil used control characters for the Spanish accents etc. in the room names of Manic Miner 5: Los Peligros del LSD.


Offsets 544 to 615: Block Graphics

Each room has eight block graphics (each of which is represented in nine bytes):

  • Offsets 544 to 552: Background
  • Offsets 553 to 561: Floor
  • Offsets 562 to 570: Crumbling Floor
  • Offsets 571 to 579: Wall
  • Offsets 580 to 588: Conveyor
  • Offsets 589 to 597: Nasty 1
  • Offsets 598 to 606: Nasty 2
  • Offsets 607 to 615: Spare

The nine bytes for each block graphic are used as follows:

  • The first byte (i.e. Offset 544, 553, 562, 571, 580, 589, 598 or 607) holds the colour attribute (see Appendix A);
  • The other eight bytes (i.e. Offsets 545-552, 554-561, 563-570, 572-579, 581-588, 590-597, 599-606 or 608-615) hold the 8x8 pixel pattern (see Appendix B).

The colour attributes defined here must agree with the ones in the screen layout, as this is how the block at each character position is specified, so when you change an attribute here, remember to replace all occurrences of that attribute in the screen layout! Beware the case where you're changing to an attribute that already occurs on the screen (because you will lose the distinction between the two block types), and the case where you're changing from a multiply defined attribute (because, since there's no distinction on the screen layout, it will replace all blocks of that attribute - it is better to decide whether to replace each occurrence of the block by hand, rather than replacing all blocks automatically and indiscriminately).

In general, two block graphics should not have the same colour attribute, because it makes an occurrence of that attribute in the screen layout ambiguous. However, you could try using this technique for special effects such as crumbling conveyors (as in Room 10 of Manic Miner: The Hobbit, "On the Doorstep").

If a block type is not required on a screen, I suggest zeroising the 8x8 pixel pattern and using 255 for the colour attribute as the neatest solution (some rooms in the original Manic Miner use a colour attribute of 0 for this purpose, but I don't like that because it often clashes with the Background attribute).

The Block Graphics Bug

There is a horrid bug in the Manic Miner game engine which can cause one block graphic in a room to corrupt another (typically so that its 8x8 pixel pattern resembles the first block graphic when it is displayed on the screen). You can often fix it by changing the colour attribute of one or the other graphic if you encounter it. The bug can also be due to pixel patterns, however (e.g. if you laterally invert the pixel pattern for Wall in Room 0 ("Central Cavern") of the original Manic Miner, it corrupts Nasty 1's pixel pattern!)

Matthew Wilson has now explained the exact cause of the block graphics bug to me. The Manic Miner game engine looks up each block from the screen layout (Offsets 0 to 511) in the block graphics section (Offsets 544 to 615), and uses the next eight bytes as the pixel pattern to display. However, it interprets the first occurrence of the block byte in Offsets 544 to 615 as the colour attribute, even if it isn't one of Offsets 544, 553, 562, 571, 580, 589, 598 or 607. So the block graphics bug occurs if the colour attribute value happens to occur in the pixel pattern data before its proper occurrence as a colour attribute, and the following eight bytes are used as the pixel pattern (which explains why it resembles one of the pixel patterns for the room but looks as if it has been shifted vertically).

There's a similar bug in the Jet Set Willy game engine, though not identical - try writing "West of Kitchen" or "The Wine Cellar" (Rooms 24 and 49 respectively in the original Jet Set Willy) in Manic Miner, and you'll see that Manic Miner will corrupt some block graphics that Jet Set Willy does not! (you'll also notice that you can't jump onto the ledges on the left-hand side of "The Wine Cellar" in Manic Miner, whereas in Jet Set Willy, you can).

Note on Collision Detection for Guardians

Manic Miner's collision detection algorithm for guardians is pixel-based, which means that you lose a life if a guardian touches Willy, another guardian or the pixels in a block on the screen. That's why the 8x8 pixel pattern for Background tends to be left blank, but it only need be if a guardian would touch any pixels in it which are turned on! Equally, you can safely have a guardian walk through a block of any type, provided it would not touch any pixels. I exploited all these peculiarities in "Dotty" (Room 14 of Manic Miner 4). The first three rooms of Craig Rothwell's Manic Miner 7 are also excellent examples of this.

Note that it does not count as a collision if a guardian touches the portal or an item (though if the guardian is white, it'll collect the item for you! (see Room 12 of Manic Miner: The Hobbit, "Not at Home")), and it does not matter what the Kong Beast touches as it falls to its death in Rooms 7 and 11 ("Miner Willy meets the Kong Beast" and "Return of the Alien Kong Beast" in the original Manic Miner)!

Crumbling Floor

The 8x8 pixel pattern for Crumbling Floor (Offsets 563 to 570) should respect Manic Miner's algorithm for detecting that the floor has crumbled completely: each time Miner Willy steps on a block of crumbling floor, it shifts the 8x8 pixel pattern of that particular block down one pixel, with the bottom row of pixels falling off the bottom of the character and a blank row of pixels being fed in at the top. If the bottom row of pixels is blank after that shift, it infers that the occurrence has crumbled completely and replaces the colour attribute at that character position with that of the Background graphic. Therefore, you should probably avoid having a blank row of pixels in the middle of the 8x8 pixel pattern for Crumbling Floor, because Manic Miner will infer prematurely that it has crumbled completely, leaving a `ghost' (the pixels in rows above the blank line but the colour attribute of Background; you can see the `ghost' in white ink when Willy touches it) at that character position. See Room 0 of Manic Miner 7 ("The Money -O- Meter") for a very clever exploitation of this feature, and Room 0 of Manic Miner: The Buddha of Suburbia ("The Terminator") for a not so clever example! (originally unintended as I didn't understand it back in 1992, but when I revamped the game for an Internet release in 1998, I liked it so I left it in! :-))

Manic Miner's crumbling algorithm can be exploited to create proper fast-crumbling floors, where there are a number of blank rows of pixels at the top of the 8x8 pixel pattern, depending on how rapidly you want it to fall away. Examples of this are "A Hole in the Ocean" (Room 13 in Manic Miner 4), and several rooms in Manic Miner: The Buddha of Suburbia and Manic Miner: The Hobbit.

Conveyors

Note that the specification of the conveyor's direction and position of animation are decoupled from the Conveyor blocks in the screen layout (unlike in Jet Set Willy). What this means basically is that you can have as many conveyors as you like in a room, but they all have to go in the same direction, and at most one `row' of Conveyor blocks can be animated (although all the rooms in the original Manic Miner happen to have at most one conveyor, to which the conveyor animation is applied). But the animation need not be applied to a conveyor - observe the animated floor in "Amoebatrons' Revenge" (Room 17 in the original Manic Miner)! Room 4 in Manic Miner: The Buddha of Suburbia ("Zane Zane Zane - Ouvre le Chien!") illustrates this point very well - any blocks under the conveyor animation have their top row of pixels rotated in the direction of the conveyor and their third row down of pixels rotated in the opposite direction, so this should be taken into account when designing the 8x8 pixel pattern for Conveyor (or whatever the conveyor animation is to be applied to).

Switches (Rooms 7 and 11)

The Spare graphic (Offsets 607 to 615) is usually used as an alternate Floor, but in Rooms 7 and 11 ("Miner Willy meets the Kong Beast" and "Return of the Alien Kong Beast" in the original Manic Miner), it has a special role:

  • When a Spare block occurs at (row 0, column 6), it acts as a switch which, if touched by Miner Willy, turns the blocks at (11,17) and (12,17) into background. The switch at (0,6) should not be omitted unless you want those two blocks to be automatically vapourised on entering the room! Note that the Manic Miner game engine is also hardwired to change the path of the second horizontal guardian when the left switch is flicked. It sets the right boundary column of the second horizontal guardian to 18 (it is initially 15 in Rooms 7 and 11 of the original Manic Miner). The section on horizontal guardians explains how you can get around this effect at the expense of having at most three horizontal guardians - by setting the colour attribute of the second horizontal guardian to 0 to remove it.
  • The switch that kills the Kong Beast (only after flicking the left switch) is located at (0,18). This switch also causes the blocks at (2,15) and (2,16) to be turned into background.

N.B. The above coordinates are all hardwired into the game engine. You cannot, by simply editing the room data, change the positions of the switches (such that they will still work), the blocks that get turned to background, the Kong Beast or the altered path of the second horizontal guardian.

For the switch to work correctly, leave the bottom three rows in the 8x8 pixel pattern for Spare intact, as Manic Miner tries to detect this pattern and laterally invert it when Willy flicks the switch. Note that the switch's colour attribute does not affect this effect.

Solar Rays (Room 18)

In Room 18 ("Solar Power Generator" in the original Manic Miner), the solar rays can be absorbed by Wall blocks or deflected by guardians. They start from the top of the screen from column 23, and go down until they are deflected or absorbed, so the best way to disable this feature is to have a Wall block at (0,23). Bugs will occur if you let a ray go off the screen without being absorbed.

Changing the colour attribute of Background from its original green ink on green paper can result in harmless rays, as in Room 18 of Manic Miner: The Hobbit ("The Last Stage").


Offsets 616 to 622: Miner Willy's Start Position

Some of Offsets 616 to 622 are only meaningful in terms of the way they are used at runtime - when you're actually playing the game, they are copied to the runtime work area and updated there (see Appendix F).

  • Willy's start position for a room is held in Offsets 620 and 621, which form a 16-bit word of the following format (see Appendix D):
       621      620
    0101110Y YYYXXXXX
    

    where YYYY is Willy's vertical start position (the most significant bit is in Offset 621) and XXXXX is Willy's horizontal start position (the number of characters down from the top and right from the left edge of the screen respectively or, if you prefer, the cursor position of the top-left character of Willy's graphic). `0101110Y' refers to the secondary attributes buffer (see Appendix F) - technically, this is Willy's colour attribute start position.

  • Willy's vertical start position is also represented by Offset 616, which has the following format (see Appendix D):
       616
    YYYYyyy0
    

    YYYY is Willy's vertical start position in characters, and had better agree with YYYY in Offsets 621/620; yyy is the number of pixels below that. In other words, Offset 616 contains 2 times the number of pixels that Willy starts below the top of the screen.

  • Offset 618 represents the direction Willy faces when he starts the room: 0=right, 1=left.

  • Offset 617 represents which sprite Willy starts at (see Appendix E), from 0 to 3 inclusive. Sprite 0 represents the leftmost frame and Sprite 1 the rightmost frame of his set of four 16x16 graphics for facing right (when Offset 618 = 0) or of his set of four 16x16 graphics for facing left (when Offset 618 = 1).

  • Offset 619 is 0 in all rooms in the original Manic Miner. If you set it to 1, Willy will automatically jump (straight up) when he starts the level, like in "Tales From A Parallel Universe" (Room 15 in Manic Miner 4 (apologies to Lee Tonks, author of Manic Miner 3: Tales from a Parallel Universe)) and "Queer Lodgings" (Room 6 in Manic Miner: The Hobbit). According to Garry Lancaster, Offset 619 is used at runtime for the jump flag (so this must be the least significant bit) or count of distance fallen.

  • Offset 622 is 0 in all rooms in the original Manic Miner. It is used at runtime to count distance jumped, according to Garry Lancaster.

Offsets 623 to 626: Conveyor: Direction and Position of Animation

Technically, the animation of the conveyor is decoupled from the actual Conveyor blocks (for further discussion of this issue, see the subsection on Conveyors in the Block Graphics section). If you are a lay hacker who just likes to have one conveyor in each room and animate that, then whenever it says "conveyor animation" below, just read "conveyor".

  • Offset 623 represents the direction of the conveyor: which way the conveyor animation animates, and what effect Conveyor blocks have when Willy steps on them:
    • A value of 0 means Conveyor blocks carry Willy to the left (and the conveyor animation animates to the left);
    • A value of 1 means Conveyor blocks carry Willy to the right (and the conveyor animation animates to the right);
    • A value of 2 means Conveyor blocks are `off' (they just behave like regular floor). The conveyor animation animates to the left;
    • A value of 3 means Conveyor blocks are `sticky' (they carry Willy in the direction he's going, but you get stuck if you jump straight up onto a sticky conveyor, or if you fall or jump onto it from a height of one character or more - a sticky conveyor is trying to pull Willy in both directions at once). The conveyor animation animates to the right.

    `Off' and `sticky' conveyors did not feature in the original Manic Miner (or the original Jet Set Willy) at all (and were no doubt unintended by Matthew Smith), but I've started incorporating them in my games since I made this discovery: for example, Room 11 ("Inside Information") of Manic Miner: The Hobbit features sticky Conveyor blocks, while Room 12 ("Not at Home") has off conveyors.

  • Offsets 624 and 625 represent the position of the conveyor animation. They form a 16-bit word of the following format (see Appendix D):
       625      624
    0111Yyyy YYYXXXXX
    

    where YYYY is the character row of the conveyor animation (the most significant bit is in Offset 625) and XXXXX is the leftmost column of that row (regardless of whether the conveyor - I mean, the animation - goes left or right). `0111Yyyy' refers to the background graphics buffer (see Appendix F).

    A more recent discovery is that the three least significant bits of Offset 625 can be used to specify the vertical position of the conveyor animation in pixels: yyy is the number of pixels below YYYY. None of the Manic Miner games so far do this (yyy is always 000), and my Manic Miner Screen Editor does not allow it. So the conveyor animation can be thought of as a row of pixels which animates any blocks in its path in the direction of the conveyor, and against the direction of the conveyor two pixel rows below that. It would appear that setting yyy to 110 or 111 (i.e. 6 or 7 in denary) can cause the Spectrum to lock up, presumably because the second row of pixels falls off the bottom of the character space.

  • Offset 626 represents the length of the conveyor animation. If you don't want a conveyor animation in the room, I suggest having an animation of length 1 over something inconsequential (such as a Background block), as setting the length to 0 causes this bug which corrupts the graphics on one vertical half of the screen.

Offset 627: Border Colour

Offset 627 represents the colour of the room's border (0=black, 1=blue, 2=red, 3=magenta, 4=green, 5=cyan, 6=yellow, 7=white).


Offsets 628 to 654: Items

Each room can have 0, 1, 2, 3, 4 or 5 items. Perhaps you call them `keys' or `objects', but not all the items actually look like keys (the item graphic is defined separately), and in my world view, everything's an object! :-)

  • Up to five items can be stored in Offsets 629 to 653 (each represented by five bytes):
    • Offsets 629 to 633: first item (if present);
    • Offsets 634 to 638: second item (if present, and first item must exist);
    • Offsets 638 to 643: third item (if present, and second item must exist);
    • Offsets 644 to 648: fourth item (if present, and third item must exist);
    • Offsets 649 to 653: fifth item (if present, and fourth item must exist).

    If there are fewer than five items in the room, then pad out the item after the last item with [255,255,255,255,255], and any items after that with [0,255,255,255,255]. So if you delete an item, remember to shunt the ones after it down a place, and pad out as necessary!

    The five bytes of each item are used as follows:

    • The first byte of each item (i.e. Offset 629, 634, 638, 644 or 649) represents that item's colour attribute (see Appendix A). Note that the item's ink colour cycles from magenta to yellow to cyan to green - so the ink colour should be one of these (which is the colour the item will be at the 0th time-frame of the room - i.e. the one before the first time-frame you can pause it on). The ink colours of the items determine what phase they are in with respect to one another. Stylistically, I generally recommend that you use the same paper colour as Background, although unlike in Jet Set Willy, it is possible to have different paper colours for items! (e.g. "The Vat" and "The Warehouse" - Rooms 6 and 16 in the original Manic Miner).

      An item should not have a colour attribute of 0 or 255. Setting an item's colour attribute to 0 removes that item, and setting it to 255 terminates the sequence, removing that item and any others after it. The original Manic Miner has items which are `removed' in this way: Room 14 ("The Bank") has a colour attribute of 255 for the fourth item (which causes the fifth item to be removed also), and Room 15 has a colour attribute of 255 for the fifth item. The other four bytes of these three items suggest that they are genuine items which were deleted (intentionally or unintentionally) by Matthew Smith.

    • The second, third and fourth bytes of each item (i.e. Offsets 630-632, 635-637, 639-641, 645-647 or 650-652) represent the position of that item on the screen, as a 24-bit word in the following format (see Appendix D):
         632      631      630
      0110Y000 0101110Y YYYXXXXX
      

      where XXXXX is the column and YYYY is the row - the most significant bit of YYYY is held in both 631 and 632 redundantly (so make sure those two bits are equal!) - `0110Y000' refers to the secondary graphics buffer and `0101110Y' refers to the secondary attributes buffer (see Appendix F).

      The above word format (632/631/630) is for the first item: it extends to the other four items in the obvious way.

      Do not put items over any non-Background blocks, because Willy will not be able to collect them! The only exception to this rule is that if you put items over Crumbling Floor blocks, you can collect the items after the blocks have crumbled (see "Untitled No.1" - Room 17 in Manic Miner: The Buddha of Suburbia. Matthew Smith could have done this in "The Vat" and "The Warehouse"! :-)

    • The fifth byte of each item (i.e. Offset 633, 638, 642, 648 or 653) is always set at 255.

  • Offset 628 is set at 0 in all Manic Miner rooms. Its counterpart in the runtime work area (see Appendix F) "is used to decide whether or not all the items have yet been collected; just before the items are displayed it is set to zero, then when an uncollected item is displayed, it is changed to the attribute of that item. Thus, after printing items, if this byte is still zero then all items must have been collected." [Garry Lancaster]

  • Offset 654 is always set at 255.

Offsets 655 to 691: Portal

  • Offset 655 represents the portal's colour attribute (see Appendix A). If you define it to be flashing, then Willy can exit the room without collecting the items - I used that trick in "Students Union" (Room 8 of Manic Miner 4).

  • Offsets 656 to 687 represent the 16x16 graphic of the portal (see Appendix C).

  • Offsets 688 to 691 represent the position of the portal, as a 32-bit word in the following format (see Appendix D):
       691      690      689      688
    0110Y000 YYYXXXXX 0101110Y YYYXXXXX
    

    where YYYY is the vertical position of the portal, and XXXXX the horizontal position (the number of characters down from the top and right from the left edge of the screen respectively, or, if you prefer, the cursor position of the top-left character of the portal). Both YYYY and XXXXX are duplicated: 690 and 691 are informationally equivalent to 688 and 689 (`0110Y000' refers to the secondary graphics buffer and `0101110Y' refers to the secondary attributes buffer - see Appendix F). So make sure Y (the most significant bit) is the same in 691 as in 689, and make 690 the same as 688.


Offsets 692 to 699: Item Graphic

The item's 8x8 graphic (see Appendix B) is held in Offsets 692 to 699. Note that there is no colour attribute associated with this - colour attributes are associated with the individual instances of the item (up to five of which are stored in Offsets 629 to 653).


Offsets 700 to 701: Air

The amount of air you have in a room is held in Offsets 700 and 701:

  • The value held in Offset 700 is a+32, where a is the column that the air goes up to (effectively, you have a-4 characters of air, as the air starts at column 4). The default value for Offset 700 is 63 (i.e. a=31), but in many of my caverns, I give you a reduced air supply! :->

  • The value held in Offset 701 is the number of pixels of air you have (in addition to characters of air, as encoded by Offset 700), represented as one of the following bytes (shown in binary to help you visualise it):
    10000000 (denary 128)
    11000000 (denary 192)
    11100000 (denary 224)
    11110000 (denary 240)
    11111000 (denary 248)
    11111100 (denary 252)
    

    There are bugs associated with using 00000000, 11111110 or 11111111 as the value for Offset 701, so it's derecommended (and my Manic Miner Screen Editor doesn't allow it - actually, it does allow 11111110 because I only discovered that this value was problematic after I released MMSE):

    • Using 00000000 (denary 0) causes a fairly harmless glitch in the graphics (see Room 10 of Manic Miner: The Buddha of Suburbia, "The BUDDHA OF SUBURBIA : suburbs");
    • Using 11111110 (denary 254) or 11111111 (denary 255) confuses Manic Miner when it is supposed to subtract a character of air from Offset 700, resulting in an infinite amount of air and causing the Spectrum to lock up when you exit a cavern. I used this trick in the final room of both Manic Miner 4 and Manic Miner: The Buddha of Suburbia, but it's not to be recommended, especially not in earlier levels! ;-)

Offsets 702 to 732: Horizontal Guardians

Each room can have 0, 1, 2, 3 or 4 horizontal guardians. All rooms can have these. Unlike in Jet Set Willy, all horizontal guardians in a room have to have the same graphic (guardian graphics are defined separately within the room data).

Up to four horizontal guardians can be stored in Offsets 702 to 729 (each represented by seven bytes):

  • Offsets 702 to 708: first horizontal guardian (if present);
  • Offsets 709 to 715: second horizontal guardian (if present, and first horizontal guardian must exist);
  • Offsets 716 to 722: third horizontal guardian (if present, and second horizontal guardian must exist);
  • Offsets 723 to 729: fourth horizontal guardian (if present, and third horizontal guardian must exist).

If there are fewer than four horizontal guardians in the room, the sequence is terminated with 255 in the byte after the last horizontal guardian (i.e. 702, 709, 716 or 723), and all bytes after that one up to and including Offset 729 are padded out with 0. So if you delete a guardian, remember to shunt the ones after it down a place, and pad out as necessary!

The seven bytes of each horizontal guardian are used as follows:

  • The first byte (i.e. Offset 702, 709, 716 or 723) represents the guardian's colour attribute (see Appendix A), except that instead of flash, the most significant bit (MSB) represents whether it goes at the normal speed for a horizontal guardian (MSB = 0) or slowly (MSB = 1), like when you walk Willy under a wall with the jump key held down. It is recommended that you use the room's Background paper colour and brightness, otherwise it looks rather ugly! ;-)

    A horizontal guardian should not have a colour attribute of 0 or 255. Setting a horizontal guardian's colour attribute to 0 removes that horizontal guardian, and setting it to 255 terminates the sequence, removing that horizontal guardian and any others after it. A situation in which setting the colour attribute to 0 is useful is to remove the second horizontal guardian in Room 7 or 11 without shunting the third horizontal guardian down because its right boundary column will automatically be set to 18 when the left switch is flicked. An example is Room 7, "Flies and Spiders", of the easy version of Manic Miner: The Hobbit: I wanted to delete the second horizontal guardian without having the right boundary of the third horizontal guardian changed when the left switch is flicked, so I gave the second horizontal guardian a colour attribute of 0. Of course, the disadvantage of this technique is that you are effectively limited to at most three horizontal guardians in the room.

  • The second, third and fourth bytes (i.e. Offsets 703-705, 710-712, 717-719 or 724-726) represent the starting position of the horizontal guardian as a 16-bit word in the following format (see Appendix D):
       705      704      703
    0110Y000 0101110Y YYYXXXXX
    

    where YYYY represents the vertical starting position and XXXXX the horizontal starting position (the number of characters down from the top and right from the left edge of the screen respectively, or, if you prefer, the cursor position of the top-left character of the sprite). The most significant bit of YYYY is redundantly duplicated in Offsets 704 and 705 (so make sure they are consistent) - `0110Y000' refers to the secondary graphics buffer and `0101110Y' refers to the secondary attributes buffer (see Appendix F).

    The above word format (705/704/703) is shown for the first horizontal guardian: it extends to the other three horizontal guardians in the obvious way.

  • The fifth byte (i.e. Offset 706, 713, 720 or 727) represents whether the guardian initially goes right or left (0=right, 7=left).

    Note that, in Manic Miner, a horizontal guardian will start on the leftmost frame of its graphics if it goes right initially, and on the rightmost frame of its graphics if it goes left initially. This is different than in Jet Set Willy, where all horizontal guardians start on the leftmost frame of their graphics regardless of whether they go right or left initially.

  • The sixth and seventh bytes of the guardian (i.e. Offsets 707/708, 714/715, 721/722 or 728/729) represent the extreme left and right positions, respectively, as 8-bit words of the following format (see Appendix D):
    YYYXXXXX
    

    where XXXXX is the horizontal position of the boundary (the number of characters right from the left edge of the screen, or, if you prefer, the character column of the left half of the sprite - for both the left boundary and the right boundary) and YYY is a slice of the vertical position - which is, of course, the same as in the second byte of the guardian (Offset 703, 710, 717 or 724), as horizontal guardians do not change their vertical positions!

    Although the starting position always falls within the left and right boundaries in all the original Manic Miner caverns, it isn't required to do so: I often give my guardians a grand entrance, strutting to their regular paths from the sides of the screen! A prime example of this is "The Flapping Toilets" (Room 4 in Manic Miner 4). But don't let a guardian walk off the edge of the screen, it's ugly! ;-)

  • Offset 730 is a terminator which is always set at 255, and Offsets 731 and 732 are 0 for all Manic Miner rooms.

Offsets 733 to 760: Vertical Guardians (Rooms 8, 10, 12-14 and 16-19 only)

Only the following rooms can have vertical guardians:

  • Room 8 ("Wacky Amoebatrons" in the original Manic Miner);
  • Room 10 ("Attack of the Mutant Telephones" in the original Manic Miner);
  • Room 12 ("Ore Refinery" in the original Manic Miner);
  • Room 13 ("Skylab Landing Bay" in the original Manic Miner);
  • Room 14 ("The Bank" in the original Manic Miner);
  • Room 16 ("The Warehouse" in the original Manic Miner);
  • Room 17 ("Amoebatrons' Revenge" in the original Manic Miner);
  • Room 18 ("Solar Power Generator" in the original Manic Miner);
  • Room 19 ("The Final Barrier" in the original Manic Miner).

The alleged vertical guardian in Room 4 ("Eugene's Lair" in the original Manic Miner) is a special case (see the Special Graphics section) - it is not a guardian in the sense of this section!

In all other rooms, Offsets 733, 734 and 735 are set at 0 (and so are Offsets 736 to 760, except for Rooms 0, 1, 2 and 4 which have special graphics).

Each of the rooms listed above can have 0, 1, 2, 3 or 4 vertical guardians. Unlike in Jet Set Willy, all vertical guardians in a room have to have the same graphic (guardian graphics are defined separately within the room data).

Up to four vertical guardians can be stored in Offsets 733 to 760 (each represented by seven bytes):

  • Offsets 733 to 739: first vertical guardian (if present);
  • Offsets 740 to 746: second vertical guardian (if present, and first vertical guardian must exist);
  • Offsets 747 to 753: third vertical guardian (if present, and second vertical guardian must exist);
  • Offsets 754 to 760: fourth vertical guardian (if present, and third vertical guardian must exist).

If there are fewer than four vertical guardians in the room, the sequence is terminated with 255 in the byte after the last horizontal guardian (i.e. 733, 740, 747 or 754), and all bytes after that one up to and including Offset 760 are padded out with 0. So if you delete a guardian, remember to shunt the ones after it down a place, and pad out as necessary!

The seven bytes of each vertical guardian are used as follows:

  • The first byte (i.e. Offset 733, 740, 747 or 754) represents that guardian's colour attribute (see Appendix A). It is recommended that you use the room's Background paper colour and brightness, otherwise it looks rather ugly! ;-)

    Like horizontal guardians, a vertical guardian should not have a colour attribute of 255. Setting a vertical guardian's colour attribute to 255 terminates the sequence, removing that vertical guardian and any others after it. Unlike horizontal guardians, however, a vertical guardian can have a colour attribute of 0, i.e. black ink on black paper, making it invisible on screens with black on black Background! :->

  • The second byte (i.e. Offset 734, 741, 748 or 755) represents which sprite the vertical guardian starts at, from 0 to 3 inclusive (see the section on