GeoCities will close on 26th October 2009, so I will be moving this page to my new website (when I have thoroughly checked and edited it):
Please update your links and bookmarks ASAP, because there will be no redirection after 26th October.
This document was last updated on 11th January 2006 - changes since previous version (20th August 2004):
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 when I first published it in 1998, none of the existing editors appeared to have all this knowledge built into them - except my own Manic Miner Screen Editor, which I released shortly afterwards (in 2004, John Elliott added a MM editor to JSWED v2.1.0 and higher). 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 had already put a JSW Tech Page on his now-sadly-defunct JSW Ultimate Fan Page, so there goes my novel contribution! ;-( I still plan to write up my JSW Room-Format at some point in the future. In the meantime, this document is worth reading because many of the tips mentioned here apply to JSW too! Serious hackers may also be interested in John Elliott's room-formats for Jet Set Willy II and his own JSW64 family of game-engines, and in the various disassemblies of MM/JSW.
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, 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 automatic transformations (e.g. mirroring, and converting between MM and JSW).
I assume that 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 some Manic Miner games for it! :-)
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, but if you do, please have the decency to let me know.
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://oocities.com/andrewbroad/spectrum/willy/mm_format.html) to see if it has been updated.
Known `mirror sites' for this document (please let me know of any others):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 tunes, 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.
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: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.
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.
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.
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).
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).
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)!
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.
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).
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.
John Elliott's Manic Miner Patch allows a Kong Beast in any room, as specified by Offset 627.
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").
John Elliott's Manic Miner Patch allows solar rays in any room, as specified by Offset 627.
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).
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.
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.
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".
`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.
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 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).
John Elliott's Manic Miner Patch interprets Offset 627 as follows (see Appendix D):
627 ESVKPBBBwhere:
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! :-)
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: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.
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"! :-)
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.
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).
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):
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):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: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.
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.
Note that, in Manic Miner, a horizontal guardian will (almost always) start on the leftmost frame of its graphics (Sprite 0) if it goes right initially, and (almost always) on the rightmost frame of its graphics (Sprite 7) 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 (Sprite 0 or Sprite 4) regardless of whether they go right or left initially - hence, in JSW, the start-column appears to be one column to the left of that specified in the room-data.
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! ;-)
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!
John Elliott's Manic Miner Patch allows any room to have vertical guardians (or a Eugene), as specified by Offset 627.
For rooms which don't have vertical guardians, 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 room for which vertical guardians are enabled (whether because of the room-number, or by using MM Patch) 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):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: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! :->
0YYYYyyy
where YYYY is the number of characters down from the top of the screen, and yyy is the number of pixels below that (i.e. you can specify positions which straddle characters).
Vertical guardians have unorthodox semantics in Room 13 ("Skylab Landing Bay" in the original Manic Miner). Instead of going up and down, they come down from the top of the screen and explode at the bottom of their path! The way this is implemented is that after a vertical guardian has exploded, it starts again at the top of the screen, shifted horizontally 8 characters to the right (under modulo-32 to give screen wraparound). Thus, in the original version, there are three vertical guardians in this screen, giving the illusion of twelve!
You can edit the vertical guardians in Room 13 like any other vertical guardians, but you must bear in mind the special conditions stated above. You have to make sure the vertical guardians do not clash or straddle the screen under modulo-8 (i.e. avoid having a vertical guardian in columns 7 & 8, or 15 & 16, or 23 & 24, as this would cause them to straddle the vertical borders of the screen).
I have experienced a lot of trouble with Skylabs crashing into the floors they explode on and killing you, when you try to change their paths or speed! The best way I know to cure such a problematic Skylab is to change the number of pixels (the three least significant bits of the third byte) below the starting position to some number between 0 and 7 and to set the number of pixels below the top position (the three least significant bits of the sixth byte) to that same value. This requires at most eight experiments before you cure the problem (unless of course the guardian is faulty for other reasons! ;-)).
The graphics for these guardians are also unorthodox (see the section on Guardian-Graphics).
John Elliott's Manic Miner Patch allows Skylabs in any room, as specified by Offset 627.
John Elliott's Manic Miner Patch allows any room to have a Eugene, as specified by Offset 627.
Exactly which sprites are used for what varies from room to room. In particular, some rooms are allowed to have bidirectional graphics for the horizontal guardians, while others are not, because some of the sprites are used for other purposes (mainly vertical guardian-graphics).
The rooms which have bidirectional graphics for horizontal guardians are:John Elliott's Manic Miner Patch allows any room to have vertical guardians, Skylabs or a Kong Beast, as specified by Offset 627 - which therefore determines whether horizontal guardians have unidirectional or bidirectional sprites.
FBPPPIIIwhere:
An 8x8 graphic is represented as a sequence of eight contiguous bytes, where the first byte is the top row of pixels and the eighth byte is the bottom row of pixels.
Within each row, each of the eight bits represents a pixel, where the most significant bit is the leftmost pixel and the least significant bit is the rightmost pixel.
If a bit is set to 0 then the corresponding pixel is `off', whereas if the bit is set to 1, the corresponding pixel is `on'.
In other words, it's exactly how normal people would visualise it! :-)
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
In other words, go left to right and then top to bottom through the whole of the graphic. Don't think of it as 2x2 characters or you'll get your head in a tangle! ;-)
Stuart Brady suggests that it might be better to think of a 16x16 graphic as a sequence of sixteen 16-bit words, each representing a row of pixels. Take your pick! :-)
For data which are best understood at the level of bits, I have adopted a generic template in which I depict the byte(s) in binary to show how each bit is used.
Bits which are always 0 or always 1 are depicted as `0' or `1', while bits which vary are depicted as letters. Where several bytes fulfil the same functional role, they are shown side-by-side, with the offset above, e.g.
621 620 0101110Y YYYXXXXXThis depicts that the bytes at Offsets 620 and 621 form a 16-bit word (which happens to partially represent Willy's start-position in a Manic Miner room), where the seven most significant bits at Offset 621 are fixed (so it's always 92 or 93 in denary, depending on whether the least significant bit is 0 or 1), and there are variables:
In this example, which is typical of many in Manic Miner and Jet Set Willy, these data represent the position of a 16x16 sprite as the number of characters down from the top of the screen (YYYY) and the number of characters to the right of the left border of the screen (XXXXX) - or, if you prefer, the row and column of the top-left 8x8 character of the 16x16 graphic.
Though this document is primarily concerned with the upper 20K of Manic Miner (addresses 45056 to 65535, where the room-data are stored), I have discovered various useful bits and pieces about the lower 12K (addresses 32768 to 45055), which are the subject of this appendix.
The following addresses - 33902 to 35881 - apply to the Bug-Byte game-engine only. For games based on the Software Projects engine, add 6 to addresses in this range. Thanks to John Elliott for this information.
Addresses 35882 to 35954 apply to the Bug-Byte game-engine only. For games based on the Software Projects engine, add 13 to addresses in this range.
Addresses 35955 to 37718 apply to the Bug-Byte game-engine only. For games based on the Software Projects engine, add 11 to addresses in this range.
Addresses 37719 and onwards do not need to be adjusted for the Software Projects game-engine.
The above two pictures are stored in the same format as the Spectrum's video RAM (you can display both pictures together by copying the contents of 40960-45055 to 16384-20479).
The emphasis of this document has been on the anatomy of a Manic Miner file rather than the dynamic aspects of the room format at runtime. However, while Garry Lancaster was working on a Z88 conversion of Manic Miner, he discovered some details of how the game engine copies the room-data to buffers at runtime and updates these data during play, and he was kind enough to share this information with me. I'll let his own words tell the story...
"The first thing to understand is the way Manic Miner uses the level data. When a new level is entered, the first 512 bytes are copied into an area I call the "background attribute buffer". These are then used to generate the "background screen buffer" - basically everything except the items, guardians and Willy himself.
"The other 512 bytes are copied to a work area and are used throughout play, with the positions being updated in the copy. This explains why several of the locations appear to be unused, as they only get initialised during play.
"Secondly, the positions of various things on the screen often appear twice in odd formats within the level data. This is because the program sometimes needs an attribute address and sometimes a graphic address; if both are needed, only three bytes are required since the low byte of an attribute address is the same as that of a graphic address. To add to the confusion, some positions are given within the "background" buffers mentioned above, and others are given within the "secondary" graphics/attribute buffers.
"To make sense of this, you need to understand how the screen is displayed. At the start of a new level, the background buffers are generated (as discussed earlier) and these stay the same except for conveyors and certain special features in the Kong screens. Every move, the background buffers are copied to the secondary buffers, where guardians, items and Willy are added (checking for collisions). Finally the secondary buffers are copied to the screen.
"Anyway, the various positions in the level data correspond like this:
0111Y000 : background graphics buffer (for conveyors only)
0110Y000 : secondary graphics buffer
0101110Y : secondary attributes buffer"
I have since discovered that the bit pattern for the background graphics buffer should be 0111Yyyy, where yyy is the number of pixels below the specified character-row. So the vertical position of a conveyor-animation can be given in pixels, not just characters. The bit pattern for the secondary graphics buffer should similarly be 0110Yyyy in principle, which would allow you to specify the vertical positions of items, portals and horizontal guardians in pixels. However, there are bugs associated with this, so it's not recommended (the Manic Miner game engine doesn't cover the three character-rows that such a graphic would straddle with the colour-attribute, and there seem to be other bugs too which cause nasty corruptions).