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)


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

  • The third byte (i.e. Offset 735, 742, 749 or 756) represents the vertical start position of the guardian, as an 8-bit word in the following format (see Appendix D):
    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).

  • The fourth byte (i.e. Offset 736, 743, 750 or 757) represents the horizontal position of the vertical guardian, in characters from the left border of the screen (i.e. the character column of the left half of the sprite).

  • The fifth byte (i.e. Offset 737, 744, 751 or 758) represents the vertical guardian's velocity as an 8-bit two's complement integer (i.e. you can poke it in the range -128 to +127 inclusive, and if peeking it returns a value x in the range {128 <= x <= 255}, the value should be interpreted as x-256). A positive value means the guardian goes down initially, a negative value means the guardian goes up initially, and a value of 0 means the guardian is stationary. The magnitude represents the speed of the guardian in pixels per time-frame, which means you can create super-fast vertical guardians compared to those in the original Manic Miner which never went above 4 pixels per time-frame. I wish I'd known that when I wrote Manic Miner 4! :->

  • The sixth and seventh bytes (i.e. Offsets 738/739, 745/746, 752/753 or 759/760) represent the top and bottom positions, respectively, of the vertical guardian, in the same format as the third byte (see above).

Skylabs

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


Offsets 736 to 767: Special Graphic (Rooms 0, 1, 2 and 4)

Rooms 0, 1, 2 and 4 have a special 16x16 graphic (see Appendix C) associated with them, which is held in Offsets 736 to 767. On all other screens, Offsets 761 to 767 are zeroised (Offsets 736 to 760 are also zeroised on screens which don't have vertical guardians).

  • Room 0 ("Central Cavern" in the original Manic Miner) holds the swordfish graphic that appears in Room 19 ("The Final Barrier" in the original Manic Miner) when you complete the game (only if you haven't cheated by using 6031769 (Bug-Byte edition) or TYPEWRITER (Software Projects edition) ;-)).

  • Room 1 ("The Cold Room" in the original Manic Miner) holds the plinth graphic that appears on the Game Over screen.

  • Room 2 ("The Menagerie" in the original Manic Miner) holds the boot graphic which appears on the Game Over screen, and also next to your lives when you use the 6031769 or TYPEWRITER cheat.

  • Room 4 ("Eugene's Lair" in the original Manic Miner) holds the Eugene graphic which appears on that screen. This is a special `vertical guardian' whose path and colour attribute (white ink on whatever paper you define for the room's Background) are hardwired into the game engine. It goes up and down the middle of the screen (columns 15 and 16, rows 0 to 12), and when all the items have been collected, starts flashing and immediately goes down to stop at rows 11 and 12. If you do not want the Eugene in your Room 4, I suggest zeroising Offsets 736 to 767 to blank out the special graphic, which will leave a harmless shadow on the screen.

Offsets 768 to 1023: Guardian Graphics

Eight 16x16 sprites (see Appendix C) for the guardians are held in Offsets 768 to 1023:

  • Offsets 768 to 799: Sprite 0
  • Offsets 800 to 831: Sprite 1
  • Offsets 832 to 863: Sprite 2
  • Offsets 864 to 895: Sprite 3
  • Offsets 896 to 927: Sprite 4
  • Offsets 928 to 959: Sprite 5
  • Offsets 960 to 991: Sprite 6
  • Offsets 992 to 1023: Sprite 7

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:

  • Room 0 ("Central Cavern" in the original Manic Miner);
  • Room 1 ("The Cold Room" in the original Manic Miner);
  • Room 2 ("The Menagerie" in the original Manic Miner);
  • Room 3 ("Abandoned Uranium Workings" in the original Manic Miner);
  • Room 4 ("Eugene's Lair" in the original Manic Miner);
  • Room 5 ("Processing Plant" in the original Manic Miner);
  • Room 6 ("The Vat" in the original Manic Miner);
  • Room 9 ("The Endorian Forest" in the original Manic Miner);
  • Room 15 ("The Sixteenth Cavern" in the original Manic Miner).

The sprites are used in the following different ways, depending on which number room it is:

  • Rooms which have bidirectional graphics for horizontal guardians (i.e. those listed above) use Sprites 0 to 3 for the right-facing frames and Sprites 4 to 7 for the left-facing frames, where Sprites 0 and 4 are the leftmost frames, and Sprites 3 and 7 are the rightmost frames. For smooth horizontal guardians, I suggest having a normative width of 10 pixels, which you shift 2 pixels to the right on each successive frame.

  • Rooms which do not have bidirectional graphics for horizontal guardians (i.e. those not listed above) use only Sprites 4 to 7 (Offsets 896 to 1023) for the horizontal guardian graphics.

  • Rooms which have vertical guardians (see the section on Vertical Guardians) use Sprites 0 to 3 (Offsets 768 to 895) for the vertical guardian graphics, so these screens do not have bidirectional graphics for horizontal guardians. Note that this does not quite cover all screens which do not have bidirectional horizontal guardians, because...

  • Rooms 7 and 11 ("Miner Willy meets the Kong Beast" and "Return of the Alien Kong Beast" in the original Manic Miner) use Sprites 0 to 3 for the Kong Beast graphics: the standing Kong Beast in Sprites 0 and 1, and the falling Kong Beast in Sprites 2 and 3.

  • Room 13 ("Skylab Landing Bay" in the original Manic Miner) uses Sprites 0 to 7 (yes, all of them!) for the Skylab graphics: the falling Skylab in Sprite 0 and the exploding Skylab in Sprites 1 to 7. Note that this conflicts with the horizontal guardian graphics, but does not prevent you having horizontal guardians in this room (though no versions of Manic Miner so far released do have horizontal guardians in Room 13!). See the Skylabs subsection of the Vertical Guardians section for the special conditions on the guardians themselves.

Appendix A: Colour Attributes

A colour attribute is represented as an 8-bit word in the following format (see Appendix D):

FBPPPIII

where:

  • F represents flash (0=not flashing, 1=flashing);
  • B represents brightness (0=not bright, 1=bright);
  • PPP represents paper colour (000=black, 001=blue, 010=red, 011=magenta, 100=green, 101=cyan, 110=yellow, 111=white);
  • III represents ink colour (as above).

Appendix B: 8x8 Graphics

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


Appendix C: 16x16 Graphics

A 16x16 graphic is represented as a sequence of 32 contiguous bytes. Start with your understanding of 8x8 graphics (see Appendix B), where a byte represents a row of pixels. In a 16x16 graphic, the bytes (numbered 0 through 31), are aligned as follows:

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


Appendix D: Word Formats

For data which is 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 YYYXXXXX

This 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:

  • YYYY: 4 bits (giving a range 0 through 15). These bits happen to straddle the two bytes, with the most significant in 621 (this happens to be the least significant bit of 621, but this is not always the case in general!);
  • XXXXX: 5 bits (giving a range 0 through 31).

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.


Appendix E: Addresses 32768 to 45055

Though this document is primarily concerned with the upper 20K of Manic Miner (addresses 45056 to 65535, where the room data is stored), I have discovered various useful bits and pieces about the lower 12K (addresses 32768 to 45055), which are the subject of this appendix.

  • Addresses 33280 to 33535 hold the sprites for Miner Willy. Each sprite is a 16x16 graphic (32 bytes) as described in Appendix C, and the sprites are organised in the same way as for bidirectional horizontal guardians (see the Guardian Graphics section):
    • 33280 to 33311: Sprite 0 (Miner Willy facing right - leftmost frame)
    • 33312 to 33343: Sprite 1 (Miner Willy facing right)
    • 33344 to 33375: Sprite 2 (Miner Willy facing right)
    • 33376 to 33407: Sprite 3 (Miner Willy facing right - rightmost frame)
    • 33408 to 33439: Sprite 4 (Miner Willy facing left - leftmost frame)
    • 33440 to 33471: Sprite 5 (Miner Willy facing left)
    • 33472 to 33503: Sprite 6 (Miner Willy facing left)
    • 33504 to 33535: Sprite 7 (Miner Willy facing left - rightmost frame)


  • Address 33792 is the machine code entry point to Manic Miner.

  • I have found various bits of text lying around (all in regular ASCII format):
    • 33816 to 33818: "AIR" (3 characters)
    • 33839 to 33870: "High Score 000000 Score 000000" (32 characters)
    • 33871 to 33874: "Game" (4 characters)
    • 33875 to 33878: "Over" (4 characters)


  • The in-game tune is stored in addresses 34188 to 32451 in the Bug-Byte edition of Manic Miner, and in 34194 to 34257 in the Software Projects edition. The format of this data is explained in Richard Hallas' music document.

  • There appears to be some assembly code between addresses 37709 and 40186 in the Bug-Byte edition! I don't fully understand the text format (I don't know which assembler Matthew Smith used), but it looks very interesting!

  • The scrolly message (displayed after the playing of the title screen music) is stored in addresses 40192 to 40447 (thus it is 256 characters long, ASCII text format).

  • Addresses 40960 to 43007 hold the pixels for the picture that appears in the upper eight character rows of the title screen and of Room 19. The colour attributes for this picture are stored separately in the screen layout for Room 19 (i.e. in addresses 64512 to 64767).

  • Addresses 43008 to 45055 hold the pixels for the picture that appears in the middle third of the title screen (where it says "MANIC MINER", "STARRING MINER WILLY" and "PRESS ENTER TO START"). The colour attributes for this picture are stored in addresses 40448 to 40703.

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

  • Addresses 40704 to 40959 hold the colour attributes for the bottom third of the screen - the eight character rows below the playing area, where the room name, air, score and lives are displayed.

Appendix F: Runtime Buffers

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


Back ] JSW Remakes Home ] Up ] Next ]

View the JSW Remakes Guestbook Sign the JSW Remakes Guestbook

JSW1-bathroomfloor.gif (1468 bytes)
From the original location of Gawp's Jet Set Willy Pages

Last updated: September 12, 2001.

Thanks to Emulation Unlimited for providing the web space.
willy3.gif (249 bytes) eulogo.gif (19565 bytes) Willy3reflected.gif (285 bytes)