Norman Sword

And the version 6a won't work until I remove the additional check for logic flow. The phase change is rem 'd out Now version 6b - 3 in one day

Eventually found the problem...A deleted opcode. The direction of change indicated by the "+" or "-" symbol was added to the graphic index. Well it was until I deleted the opcode. I have just swapped to a new Pc. I need to swap back to my old Pc keyboard or reconfigure the editor a bit better. This Pc has some very strange buttons on it, or more specifically buttons in places I never had buttons before. The one I do not like is having a button to turn the Pc off, situated on the keyboard. Pick the keyboard up, accidentally brush against a sticking out memory stick on the destk top unit, and the pc suddenly switches off. (who ever thought that was a good idea, must have missed the on - off button that desktop units have) I have managed to turn this Pc off, just by pushing the keyboard up against the main unit, and have a usb memory stick turn the computer off .....

Re changing sprite in v6- downloaded the version that is present in post #1- no problems---

Placing platforms in a room has been substantially improved. By changing a lot of code and logic order. Added a Phase change in Mode 5 - pressing "P" changes phase on horizontal sprites. Mode 5 uses colour to indicate options. yellow(editable), red( not editable) Blue background(8 Phase ) Black Background(4 phase) These changes are not notified, because to me they are one of thousands of changes I will make. And as mentioned in post #'48 that version is already obsolete due to a flaw.

In every version up to now that has a mode 5; The "+"(plus) sign or the "-" (minus) sign would change to red if the sprite was un editable. Graphically I have forced a distinction between yellow and editable and a big five in red saying < Yes you are in mode five. But I can not allow editing whilst displaying the hex screen or the graphic trail screen> change display till the "+" or "-" are seen. This version is flawed- I have found a flaw in the assembler which has introduced problems. The assembler can sometimes incorrectly value a variable, with the wrong value. E.g. A-B should be the same as -B+A. or written another way that removes it from looking like assembler opcodes. X-Y should equal -Y+X. What has happened is during a re-write of variables I changed some around. ( a layout change) ld hl, Flag-100 should be the same as ld hl,-100+Flag The assembler for thousands of these type of calculations has no problem. But I have found in the last check I did. That the assembler can sometimes give the wrong answer. What the parameter for the error is. Is not going to be investigated further. I have written giga bytes of assembly using this assembler. And I have found a problem on less than a handful of occasions.

I am amazed I have got this far without the collection sound being included. I had written the code a long time ago, just never bothered to call the routine. -------------------------------- That was yesterday. And today having revised around 1700 lines of code / comment/ data. I have added a new key "C" in mode 5 The figure of 1700 for the lines of code/comment/data, show what started as a trivial add onto the program, is now consuming a lot of memory. What follows are very quick and rough figures. Size wise the code is just over 1.5K for the editor To put that in perspective:- The code for Manic 40 Miner without the data is around 4.75k A quick look at the original Manic miner , gives a code size of around 3.5K. Which shows the trade off between having nice simple data layout, and compressing everything in sight. So I have added around 1.25k in code just for the compression of data. ----------------------------------------------------------------------------------------------------- The addition of 1.25k in game code, plus re- writes of most of the other code, has permitted the addition of 20 more rooms and the addition of more features. Plus I have also managed to have 1.5k of free space (used by the editor) as well. Without the extra code and compression, those extra 20 rooms would need an extra 20k of space. That would somehow need to be fitted into the unused memory from #934c to #9d00 around 3.25k ---------------------------------------------------------------------------------------------------- The end result is, after juggling the figures around. I have fitted the extra 20 rooms in 1.75k of the memory that was free. ----------------------------------------------------------------------------------------------------

The guardians can occupy any slot in any order. Matthew's data layout, is complicated by the addition of two control codes into the data. If zero skip, if #ff then end. Editing a colour needs to check for past end of enabled sprites. The 00 skip colour or the #FF terminator. Try doing that in less than five bytes. Ld hl,data ld de,offset --- out of memory

I ran out of memory way back in version 1 since then I have added:- 1) the ability to define the keys used in a room 2) the ability to delete keys in a room 3) the ability to add keys to a room. 4) the ability to move portals 5) the ability to define the start position of willy 6) the ability to define the start phase of willy 7) the ability to identify which sprite uses which sprite slot 8) the ability to increment a sprite page in a sprite slot 9) the ability to decrement a sprite page in a sprite slot. The above are editor specific additions. I also added a variable tune speed playing routine I can not keep adding routines to Ram I do not have. --------------------------------------------------------- When editing in mode 5: The colour indicated when pressing a numeric key is only to identify which sprite occupies which sprite slot. The colour change is not stored. Evident if any drawings is done then the sprite will revert back to the colour it is defined as. Last time I looked there was about five bytes of memory left. The figure for memory left changes with each edit of the code. It looks very tempting to enable sprite colour changing. But even if the space available was around 50+ bytes, I can see no way of enabling such a change, and I have repeatedly tried. Bar a major re-think on this code. There will be no more additions. I will look for quirks and flaws and sort them out. --------------------------------------------------------- Re -organised memory to place all the game data in a continuous block and not variable depending on code.

Attached to the end of Post #1 version V4 Changed text in Post #14 to reflect the change from earlier posts. The amount of data that can be changed is immense, and every time I add something it reinforces to me the vast scope of options that can be edited and are not editable by this part game editor. Quick list:- Portals colour- definition sprites phases - colour - direction - min - max - start -step -colour change - adding - deleting specials Skylab - phases - sound - direction - min - max - step specials Eugene - phases - min - max specials lightbeams - any activations music speed room names editing sprite definitions editing portal definitions Etc Perhaps the space occupied would be better suited to game additions after I actually created a proper set of rooms.

The original file was written in a week, mainly due to using the available space and copying routines I had written elsewhere. As stated elsewhere the main purpose was to show how easy it is to extend past 20 rooms, with just a slight compression of the room data. I added bits and pieces and posted the result V1,V2 and then V3. Re visiting the file and playing around with editor, I became aware of the inability to progress past KONG. The Kong routine had been tested repeatedly and worked, yet try as I might, I could not get the second switch to trip without dying. Looking at the code gave no clues, until I spotted a line of code I had added at the very last minute to implement a red Kong as Kong fell. The simple instruction to change the colour. One instruction, also turned on sprite collision and instant death. So as can be imagined it took just changing the value of that one instruction to fix the problem. Several other problems were found and removed I rewrote a lot of routines, that gave up a few more bytes of memory. I have used that space to add a mode 5 onto the four existing room edit modes Mode five is a bit convoluted and not much help in editing a game. It was added because I could. To enable mode five:- Stand on your left leg and using your right arm place your right elbow on your nose. with your left hand touch your left knee and chant "Jet set willy edit thee" 3 times. then... Not as bad as the above, but close to it. Mode five allows very primitive and very very unhelpful changing of individual sprites in a room. This only allows the definition to be changed and does not adjust the sprites basic parameters to match. So an improved version 4 with a few flaws removed is next.

Considering the origins of Manic Miner. (from Miner 2049'er). Every time I type the full file name I am thinking Manic 49'er. So I guess that is why I would type Manic 49 Miner and not give it a second thought. Duly changed the second file to Manic 40 Miner V3 in post #1 (deleted original and uploaded new version (just to correct file name)) Its taken a long time to change a file that started out as a test file with an addition and no plans on changing it. What it did show me was I needed far more space than what was left, after the data for 40 rooms was included.

I have added "Manic 40 Miner V3.Tap" as an amended version to the end of post #1 I have revised the Manic 40 miner - editor keys in post #14 ---- Not much change I will start with a WARNING. If the program file is edited so that the first room is unplayable. Then going back to the title screen can cause a lockout of the editor. The room needs to be drawn and the first loop of the game passed before the keyboard is scanned for both the cheat code, the cheat type in, and all the editor keys. If the sprites are set to start with a collision on the first room or Willy started over any Nasty graphic. Then death will occur before any other action can take place. This means that further editing and even game play can not proceed. If the start of any other room causes instant death then the editor is still reachable via any other room, and the problem area can be changed via editing. (hopefully) It is the first room that can remove access to editing and for that reason editing the first room needs more care than any other room. I will copy the WARNING text into post #14 Noticeable change for V3 The last cavern has had a routine added that was rem'd out in my code. (a switch able room option) I assume that is noticeable that I redrew most of the title screen text. And changed yet again the title screen piano graphics.

Shuffled the data around - Included the ability to change and store animation phase. (I do not like the code I wrote- so will re write) The above worked but not to my satisfaction.... Graphic trails was the only mode that updated the screen - sprites can pass over willy and make him disappear. Fixing the rare occurrence of a sprite passing over willy is adding more and more code. Whilst it is easy to write additional code - I do not have the space to do so. Jumped the gaping pit. performed a quirkaflleg. No closer to my goal

One of the multitude of data bytes removed from the start of a room was the animation phase. Starting in a particular animation phase is a cosmetic addition, for 99% of room starts. The left and right start phase is fixed.

I added the ability to move the item/keys. The amount of code was a lot bigger than the available space. So as I stated on a previous post I used some of the unused graphic data. The problem that exists for me is that the code has had nearly everything compacted, re written multiple times and re structured multiple times. Those compaction's of data and rewrites are what has enabled me to have 40 rooms in 48k. For my own curiosity - - - - - - - I wondered how easy would it be to add more edit functions. The task of adding the code to enable such change's. First involves going through all the other code looking for areas that I can compact even further. When I have compacted further some of the code, I can then add more functions. Having spent a day just looking at the routines , I managed additional re structuring and code re writes to squeeze out a few more bytes ;------------------------------------------------------ I have added the ability to display Willies start position ------------------------------------------------------ I have added the keyboard letter "P" This additional code letter "P" allows the portals to be moved on screen. Where "P" stands for portals ------------------------------------------------------ I have added the keyboard letter "N" This additional code letter "N" allows the start position of willy to be moved. ----------------------------------------------------- I have added the ability to turn Willy to face either way on room start. ----------------------------------------------------- Just adding the code to respond to a keyboard key takes an accumulative larger and larger chunk of code. --------------------------------------------------- I can think of nothing I can add now that is feasible in terms of the amount of memory it would take to write. Each addition sounds like it would only take a simple key check to implement it into this editor. That is simply not the case. For example when allowing the re positioning of portals. The x and y positions on the screen need checking for the edges. Simple checks, but the amount of code needed just grows and grows. The above additions have not been added to the program on post #1 I am reluctant to keep adding revisions. I normally have hundreds of updates for everything I write. So this update is being held back until such time as I feel it is the last one for some time.

Key is the original description.

Z H O key combination was just random keyboard keys- as far apart as possible and unlikely to be pressed by accident. Some keyboard keys lock the keyboard and wait for release. So that group was excluded --------------------------------------------- A list of the unused keys - at present that could be used as an item/object/key/etc Y O S G Z X V N + K (used now) Y = O = Objects S = Specials - Skeleton Key I = Items (duel usage) G = Z = X = specials (as in X marks the spot) V = N = K = Keys I have no hurry to change code ------------------------------------------------------------------ A quirk on editing keys- remove all keys from the room and the portal will flash)

I have revised the revised revision of the revised revisions for the keys/items explanation. ( post #14 ) The revisions as explained below are specific to post #14 *** post #14 only deals with versions up to V5. further versions have the editor details along side the downloads in post #1 The word Key if meaning a keyboard key - is preceded by the word keyboard. The word Key if meaning a collectable Item is written as Item/key. Addendum:- If it was necessary I can do dual usage of the "I" key There is no conflict; changing (I)nk is not in conflict with changing (I)tems

Re wrote the code and made smaller. There was really no memory to add the edit key function. What I have done is delete some of the space allocated for extra graphics and portals, and used that memory for code. Revised the editor explanation code - spent a lot longer typing the revised explanations than I did to writing the code. I will shortly attach the revised code to the first post- Manic 40 Miner v2

Managed to add a key edit function. Works well enough. But I will analyse my code and possibly rewrite.

Item location and editing. The items are in the global table and can be edited. Position and definition --- Easy to edit in the source listing - It uses a macro for x,y,number. Since I last looked I think there was about 15 bytes of spare memory in the 48k. Not enough space to even permit the changing of the definition (or enough space to change the definition - but no easy way of showing it was changed and to what it was changed) ----------------------------------------------- In the process of going out. - I will think about this whilst out. But I can not en visualise a solution in the memory available. ---------------------------------------------

Quirk that was unknown to me before doing this.... When Ms Kong is knocked of her perch, she falls down the screen. The platform she was standing on is erased. And Kong is moved down the screen. Because it can pass over one of the lower sprites Kong has her collision detection turned off for her fall. I mention the above due to playing around with the position of KONG and the position of the switches. It became possible (and still is) to enable the KONG sprite to pass over Graphics as it falls and also pass over Willy without flagging collision. I can think of no other sprite that turns off its collision in such a way. (the toilet in JSW is always off - Kong changes from active to passive)

Side track on those editor keyboard keys --- Which have all probably been worked out--- ************** NOTE 1 ***************** The original program that was at the beginning of this topic has been deleted. I added a piece of code just before I assembled it and then placed the code on this website. The code that I added was a bypass of the cheat code. This was done so that you would not need to have knowledge of what the cheat code is. Unfortunately that addition has made the code ( see the key combination Z H O ) Unable to remove the cheat code. ************ NOTE 2 ****************** I have attached a revised program. V2 The revised program has been modified to include (Item/key) editing This has changed the way this programs keyboard responds. *********** NOTE 3 ******************* I have attached a revised program. V3 The revised program has been modified to include 1) moving Willies start position and start animation frame in a room 2) Moving the position of the portals *********** NOTE 4 ****************** I have attached a revised program V4 The revised program has been modified to include. removal of Kong switch Bug removal of score Glitch A lot of small changes The addition of editor Mode 5 mode 5 permits altering a sprites room definition *********** NOTE 5 **************** I have attached a revised program V5 The revised program has been modified to include a means of defining a sprites room colour removed fixed colour on Kong - Still Red it it falls Rather than have multiple explanations of what the keyboard keys are. I will edit the text below. Since I have revised the code, I see no point in keeping an explanation of the old code current. (for now I will part indicate the changes) Explanation below is for V5 (Version 5) **************************************************************************** * This has not been updated to V6 - The explanation for V6 is available alongside the file in post #1 * **************************************************************************** ======================================================== I will start with a WARNING. If the program file is edited so that the first room is unplayable. Then going back to the title screen can cause a lockout of the editor. The room needs to be drawn and the first loop of the game passed before the keyboard is scanned for both the cheat code, the cheat type in, and all the editor keys. If the sprites are set to start with a collision on the first room or Willy started over any Nasty graphic. Then death will occur before any other action can take place. This means that further editing and even game play can not proceed. If the start of any other room causes instant death then the editor is still reachable via any other room, and the problem area can be changed via editing. (hopefully) It is the first room that can remove access to editing and for that reason editing the first room needs more care than any other room. ===================================== At present the game starts with cheat enabled and this part editor in memory. It allows normal game play with cheat, and the ability to jump into this limited Editor. The editor does have the ability to delete/encrypt itself and turn the cheat and editor off. When that is done, it is still possible to type in the cheat code and again use the cheat. The editor and all its function will however not be available, Manic 40 Miner -- Editor While playing the game. When the game is played and the boot is shown on the lower portion of the screen. Beneath the cheat boot is the active room number. active keyboard keys for cheat. the "3" key is the cheat activator 3 - Reset the room to its start position 3 Plus 1 - Move back a room. Wrap around to 40 if on room 1 3 Plus 2 - Move forward a room. Wrap around to 1 if on room 40 3 Plus 0 - Activate the Editor (If available) Pressing the keyboard keys three and zero at the same time will enter into a limited editor. Provided the editor is still in memory ============================================================= From here onwards keyboard keys described are for the environment of editing the game ============================================================= There are a great deal of keyboard keys active. And remember that this also has the data for 40 rooms. The memory restriction placed on me due to the extra rooms, has forced convoluted keyboard key usage. In all modes (keyboard keys operational in mode 1, mode 2, mode 3, mode 4, mode 5) L - Toggle between the graphic room display and the hex room display modes K - toggle between hex with zero and hex with spaces (hex room display) J - toggle between graphic trail and no graphic trail (graphic room display) J - Toggle full screen display If in graphic room display mode - (switch Items/key, portals and sprites ) - on/off (switch graphic trails) on/off If in hex room display mode - (switch full hex) - on/off M - Toggle between the five screen edit modes 1) room tiles ------ (mode 1) - (define tile colours) 2) global tiles ----- (mode 2) - (define which tiles to use in (room tiles and edit tile)) (define item/key graphic) 3) edit tile ------ (mode 3) - (edit a tile definition) 4) edit room ------- (mode 4) - (define where the platforms etc are in a room) (define Willies start position/face direction/phase) (define the Portals start position) (define the position of keys) 5) edit sprites ------ (mode 5) - (identify sprite allocation) (change a sprite definition for the current room) (change a sprite colour for the current room) R - Move the cursor left - wraps on left edge T - Move the cursor right - wraps on right edge U - Move the cursor up - stops on the top H - Move the cursor down - stops on the bottom Q - Move to previous room W - Move to next room <ENTER> - exit room editor and resume play NOTE the purpose of allowing Graphic trails by switching the sprites on. Is so the user can see where the sprites move in any room. This enables the user to keep the rooms graphics out of their paths. ================================================= Room edit mode for room tiles (define tile colours) 1) room tiles. (mode 1) These are displayed in the lower left part of the screen There are 16 tiles, each tile is displayed as follows line 0 - The graphic as defined for the room. line 1 - The paper colour of the tile line 1 - can also have a dot displayed in the paper colour A dot indicates bright is set line 2 - The ink colour of the tile line 2 - can also have a dot displayed in the ink colour A dot indicates that flash is set line 3 - A hex digit signifying what key is designated to what graphic A room is built from these 16 tiles The cursor when moved will jump across the gaps between the upper eight tiles and the lower eight tiles. Whilst it moves it will stay illuminating the hex digits for the tile. The only method of changing the selection is via the cursor move keyboard keys. [ R-T-H-U ] active keyboard keys for room tiles in addition to the global keyboard keys (additional mode 1 keyboard keys) I - change the Ink P - change the Paper B - change the Bright - Note the dot - indicating bright F - change the Flash - Note the dot - indicating Flash all changes to the tiles will be seen instantly in the playing area ================================================= Room edit mode for Global tiles (define which tiles to use in (room tiles and edit tile)) 2) Global tiles. (mode 2) these are displayed on the lower right of the screen. 8 rows of 16 tiles in yellow. allowing access to 128 tiles The space for tiles is shared with the space for portals. The ability of expand past 128 is not included There exists a big block of empty shared memory for the portals and the tiles. When moving the cursor round the Global tiles using those pesky keyboard cursor keys.[R-T-H-U] It will be evident that the tile graphic under the cursor is displayed next to the room tiles. (middle lower left of the screen) The tile under the cursor can be selected as a room tile. Just by pressing one of the keyboard keys representing the 16 room tiles. E.g. pressing "1" will transfer that selection into position "1" of the room tiles The graphic is copied into the room and also if the room has those graphics displayed then the room graphics will also be updated instantly. *** Note *** transferring graphics into the room tile graphics does not affect any tiles colour. They are defined only via the room tile editor. Since the transfer of graphics is instantaneous, it pays to just mess around transferring graphics into the room tiles. active keyboard keys for Global tiles in addition to the global keyboard keys (additional mode 2 keyboard keys) 0 - copy current tile into graphic slot 0 - Background 1 - copy current tile into graphic slot 1 - Floor 2 - copy current tile into graphic slot 2 - Collapse 3 - copy current tile into graphic slot 3 - Wall 4 - copy current tile into graphic slot 4 - Conveyor ( moving from right to left) 5 - copy current tile into graphic slot 5 - Nasty 1 6 - copy current tile into graphic slot 6 - Nasty 2 7 - copy current tile into graphic slot 7 - Switch 8 - copy current tile into graphic slot 8 - Conveyor (moving from left to right) 9 - copy current tile into graphic slot 9 a - copy current tile into graphic slot a b - copy current tile into graphic slot b c - copy current tile into graphic slot n d - copy current tile into graphic slot d e - copy current tile into graphic slot e f - copy current tile into graphic slot f - Ignore tile (continuation of mode 2 keyboard keys) When the main screen is displaying the flashing keys e.g. when you can see the Items/keys flashing K - copy the current tile into the Item/Key graphic A note on the ignore tile (tile F). All tiles can be walked on. Manic Miner and Jet Set Willy treat any tile that is found under Willies feet as a tile that can be walked on. It treats collapsing floors as a special case. but everything thing else can be walked on. Walking on nasties will still kill you. Tile "F" is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on. This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy. An extra note on the ignore tile (tile F) We could use similar colours to tile 0 the background tile, to construct a platform or graphic area from. This would also be treated by the game as a platform that can not be waked on and would seem to make the need of (tile F) superfluous. Unfortunately the graphics are then treated as a background graphic, and willy passing over that graphic will change its colour, which is not what happens to every other game graphic used in conveyors, platforms, collapsing floors etc. So yes the graphics would look the same, but they will not be treated the same visually, and the difference is very noticeable. The plus side is you can define two non interactive sets of colours and willies interaction is different for the two graphically. But not in game movement. Light beams can pass through a platform generated by using the background colours. A light beam will not pass through an ignore tile. --- What happens if the ignore tile and the background are the same colour. Then the ignore tile is treated the same as the background. Willy passing in front of the tile will colour it in. A note on on Switch tiles (Tile 7). The switch tile is checked only when a Kong sprite is defined in a room. In any room that does not have Kong, this tile will act as a normal walk on tile. =============================================== Room edit mode for editing tiles (edit a tile definition) 3) edit tile - (mode 3) this is where the cursor is flashing on the graphic for the last tile that was under the cursor in Global tiles. The cursor can be moved around - space will toggle a bit on/off/on etc ***** NOTE **** all editing will affect all the graphics seen on the screen. If you are editing a tile, then if the tile is a graphic used in the room then you will see the rooms graphics changing as a result. ***** TIP ***** do not leave the sprite trails on while doing this. It is very distracting. If shift is pressed whilst moving the cursor then the tile definition will scroll. active keyboard keys for edit tile in addition to the global keyboard keys (additional mode 3 keyboard keys) space - Toggle the bit on/off/on etc shift + cursor = scroll the tile ============================================= Room edit mode for editing room layout (define where the platforms etc are in a room) 4) edit room layout- (mode 4) the top two thirds of the screen. The cursor can be moved around over the hex or graphic data. ***** TIP ***** do not leave the sprite trails on while editing tiles. It is very distracting. (and slow) pressing any of the alphanumerics 0123456789abcdef on the keyboard will place that tile on the screen at the cursor position. Because nearly all keyboard keys are active. I added the ability to lock a selection onto the keyboard space key. If a long platform is needed in say type 4 conveyors then press four on the keyboard to start the drawing off and then use the keyboard cursor keys [RTUH] along with the keyboard space key to move and deposit conveyors. (because of redraws the action is slow) active keyboard keys for edit room in addition to the global keyboard keys (additional mode 4 keyboard keys) 0 - place tile 0 at cursor location 1 - place tile 1 at cursor location 2 - place tile 2 at cursor location 3 - place tile 3 at cursor location 4 - place tile 4 at cursor location 5 - place tile 5 at cursor location 6 - place tile 6 at cursor location 7 - place tile 7 at cursor location 8 - place tile 8 at cursor location 9 - place tile 9 at cursor location a - place tile a at cursor location b - place tile b at cursor location c - place tile c at cursor location d - place tile d at cursor location e - place tile e at cursor location f - place tile f at cursor location space - place last tile selected (additional mode 4 keyboard keys) (added for V2) When the main screen is displaying Willy the portal and the keys e.g. when you can see the Item/keys flashing K - Place an Item/Key in the current position if no item/key available - request is ignored if an Item/key is already at this position - the item/key will be deleted (additional mode 4 keyboard keys) (added for V3) When the main screen is displaying the start position of Willy and the portal e.g. when you can see Willy and the Portal P - Move the portal to this position. only legal screen positions are allowed for the portal N - Move Willies start position. If already at this position then cycle through the frames and reverse. ===================================================== (added for V4) Room edit mode for room sprites (define room sprites) 5) edit sprites (mode 5) When in this mode the graphic that is normally displayed just left of the centre on the lower portion of the screen changes colour. It will change from the normal black and white with blue underlying text to one of two sets of colours 1) Red and black, (no underlying text) 2) Yellow and black (no underlying text) There will be no screen cursor. The graphics drawn in the normal graphic box will be either a "+"(plus) or a "-"(minus). The symbol shown is indicating the direction that graphics will be changed. Pressing the letter "S" will toggle the "+" to "-" or toggle the "-" to "+" If the screen is NOT showing static sprites. Then the "+" or "-" will be shown in red. Red indicates No changes can be made If the screen is showing Static Sprites. Then the "+" or "-" will be shown in yellow. Yellow indicates sprites can be changed What follows below is when the sign indicated > the "+" or "-" is in yellow. Each room has eight sprites slots. And a Guradian/sprite can occupy any of the eight slots. Pressing the digits 12345678 will flash an active sprites colours if it is in the sprite slot indicated by the digit. This is used to identify which sprite is in which sprite/Guardian slot. A number if when pressed, gives no visual indication on the screen. Is indicating that that sprite/guardian slot is not used. Having identified a sprite/Guardian, we can change the sprite/guardian by pressing the shift key and the corresponding number for that sprite. The direction of change is defined by the "+" or "-" seen on the screen The sprites can be changed, but no help is given with adjusting sprites from 8 phase to 4 phase. No help making sure that horizontal sprites are placed in horizontal definitions. And the same with verticals. No boundary restriction on where the data is taken from. This means we scan the full 32 pages , and not all are used or defined. In addition V5 adds the ability to force a sprites colour active keyboard keys for sprite edit in addition to the global keyboard keys (additional mode 5 keyboard keys) (from V4 onward) S - Change the sign and direction of change When Sign is Yellow 1 - Identify sprite slot 1 2 - Identify sprite slot 2 3 - Identify sprite slot 3 4 - Identify sprite slot 4 5 - Identify sprite slot 5 6 - Identify sprite slot 6 7 - Identify sprite slot 7 8 - Identify sprite slot 8 shift +1 - Alter sprite in slot 1 (direction of change is indicated by the "+" or "-" sign) shift +2 - Alter sprite in slot 2 (direction of change is indicated by the "+" or "-" sign) shift +3 - Alter sprite in slot 3 (direction of change is indicated by the "+" or "-" sign) shift +4 - Alter sprite in slot 4 (direction of change is indicated by the "+" or "-" sign) shift +5 - Alter sprite in slot 5 (direction of change is indicated by the "+" or "-" sign) shift +6 - Alter sprite in slot 6 (direction of change is indicated by the "+" or "-" sign) shift +7 - Alter sprite in slot 7 (direction of change is indicated by the "+" or "-" sign) shift +8 - Alter sprite in slot 8 (direction of change is indicated by the "+" or "-" sign) In addition from V5 onwards Pressing a number will up cycle the sprites colour. Used to identify a sprite slot. If the "C" key is held down then the colour is stored. The border will also change colour to match the sprites colour. added keyboard keys for V5 C +1 - Set colour of sprite in slot 1 C +2 - Set colour of sprite in slot 2 C +3 - Set colour of sprite in slot 3 C +4 - Set colour of sprite in slot 4 C +5 - Set colour of sprite in slot 5 C +6 - Set colour of sprite in slot 6 C +7 - Set colour of sprite in slot 7 C +8 - Set colour of sprite in slot 8 Method to use... Find a sprite/guardian slot with keys 1 to 8 When the sprite that needs its colour changed is found, hold down the keyboard "C" key and tap the number that corresponds to that sprite slot. The border and the sprite will up cycle colour. The colour remembered for the sprite is the border colour while up cycling and the keyboard "C" key was pressed. Subsequent changes of colour are ignored if the keyboard "C" key is not held down. This changes only one sprite's colour at a time. Not a logical or easy set of operations to follow - (the best I can do in the space I have) ===================================================== This is a global keyboard key press that changes everything (available in all modes -- e.g. mode 1, mode 2, mode 3, mode 4, mode 5) While in the editor ... Holding Z H and O <all are letters> will result in a block slowly moving across the screen. ( on a red screen this might not be noticeable) The amount of time it takes to fully activate, is deliberate. Once done all the code for the editor is deleted. The game will be put back into a standard uneditable game, without cheat activated. If this is aborted part way through the screen might need refreshing by pressing any key that updates the screen. ==================================================== The storage of the tiles was made as simple as possible. This was to enable editing from any hex editor. The rooms have no compression and are very simple to edit. The colour of each tile defines what action is taken by the game. If a tile is defined with multiple tiles in the same colour it will exhibit normal Manic Miner duplication of actions. Tile "0" is the background. Tile "1" is the standard floor tile. (can be walked on) Tile "2" is the crumbling floor tile. (can be walked on but crumbles) Tile "3" is Wall tile. (Blocks movement through it) Tiles "4" and tile "8" are conveyors in the opposite directions. The tiles are scanned on building the room to display. The positions of the conveyors are noted and copied into a list. This list has a finite size. Any more than the maximum number of conveyors will just be ignored. This means they will still be conveyors- but not animated. Tile "5" is Nasty 1 (kills if touched) Tile "6" is Nasty 2 (kills if touched) Tile "7" ( the switch tile) is also tracked when a room is built. The first two switches found in the room (scanning from the top left) are the active switches for Kong. They can be placed anywhere in the room, or even omitted. Tile "9" Free to use. Tile "A" Free to use. Tile "B" Free to use. Tile "C" Free to use. Tile "D" Free to use. Tile "E" Free to use. Tile "F" (ignore tile) is specifically checked for and deliberately ignored as a tile. What this means is that all tiles with the same colour as tile "F" can not be jumped or walked on. This does not permit the ignore tile, if it contains graphics, to be placed in the path of a sprite. That will still flag a sprite collision and result in the demise of Willy. ============================================================ Room events Editing these is not undertaken in this editor skylabs 1) Can descend or ascend 2) They can step left or right after each ascent/descent 3) The sound of crashes are selectable from a list of four 4) They can animate or stay static Light beams 1) standard light beam - down and left 2) left light beam switching on and off - down and right 3) moving light beam - down and left switching periodically to down and right 4) Light beams can be mixed and can be used in any room. Kong 1) Kong's switches can be anywhere in a room 2) the order the switches are pressed is unimportant 3) Kong can be anywhere in a room 4) Kong's distance if Fall is definable 5) The wall opening is part definable 6) It still has a fixed sprite that can pass through a fixed opening. Eugene 1) Eugene can be placed anywhere 2) Range definable Sprites/guardians 1) any type of guardian/sprite can occupy any rooms sprite/guardian slot this means you can/could have eight verticals or eight horizontals in any room 2) any type of guardian/sprite can be mixed with any other 3) Eugene is a guardian/sprite and not a room event 4) Skylabs are a guardian/sprite and not a room event 5) Kong is a guardian/sprite and not a room event ============================================================= The edit function was added as a mess around. Its purpose (to me) was to see how much code it would take to add an edit function. I ran out of space and the amount of code needed to expand the scope of editing is not available with 40 rooms as well. What it does not edit PORTALS - NO - (V3 now includes altering start position of portal) SPRITES - NO - (V4 now includes altering sprite definition) (V5 Includes basic colour changing) START POSITION - NO - (V3 now includes altering start position and animation frame) ROOM NAME - NO

Spotted a few errors in the above - . This is a general walk through and not specific. A room now consists of:- (This is a draft layout (A lot of data and scope for errors) and might get updated) The lines starting with > are what was originally in the room and comments on that data > Room name - original 32 bytes 32 bytes the room name - no change in data size > tile definitions (expanded from the original 8 types) - original 8 by 9 bytes - 72 bytes 16*2 bytes the 16 tile definitions *** NOTE this defines 16 tiles and not 8 as originally *** 1 byte the key definition - Originally stored elsewhere - the original was 8 bytes Carrying on through the room data > The next 7 bytes define Willies start position etc > 1 byte - The pixel y is defined by the attribute - so can be deleted > 1 byte - animation frame and direction is less than 4 bits > 1 byte - Direction and movement flags --- can be described in 2 bits > 1 byte - Airborne status > 2 bytes - Willies attribute position - can be described in 9 bits > 1 byte - jump animation counter > The macro below :- defines all the wanted data from above in two bytes WILLY 0,0,13,2 --- this defines Willy at 13 down and 2 across + various flags >The next four bytes are copied to 806F and specify the direction, location and length of the conveyor. > 1 byte Direction of conveyor > 2 bytes Location in the screen buffer of the conveyor > 1 byte Length of the conveyor The above is not needed. The room layout data contains enough information to decode the position and direction of conveyors > The next byte is copied to Border_Col_32883 and specifies the border colour. - Originally 1 byte 1 byte - Border colour ; MOST BITS used > the next byte was not used - so deleted > The next 25 bytes specify the location and initial colour of the items in the cavern >The below macro's reduce the key data from 25 to 10 bytes;- we do not need a starting colour key1 3,0,9 ;23561 ;Item 1 at (0,9) key1 4,0,29 ;23581 ;Item 2 at (0,29) key1 5,1,16 ;23600 ;Item 3 at (1,16) key1 6,4,24 ;23704 ;Item 4 at (4,24) key1 3,6,30 ;23774 ;Item 5 at (6,30) > The next 37 bytes define the portal >the portals have had their graphics moved out of the data portals reduced to 4 bytes + exterior data for the portals 1 byte defines the Attribute 1 byte gives the definition index 2 bytes the location in the attribute buffer > the next eight bytes define the object - moved to one byte after the graphic definition index data > The next two bytes define the game clock and air bar The following macro in 1 byte defines the game clock and air bar GamePeriod 63,252 ;===============Guardians=============== the space for the guardians the terminators and the guardian definitions > 4 horizontal guardians at 7 bytes each > 1 byte terminator > 2 unused bytes > 4 vertical guardians at 7 bytes each the above 59 bytes are replace by 8 by 8 byte definitions - original 59 now 64 --- more data, but allowing more scope to change order, definitions and actions. and again the guardian definitions are moved into a continuous space and indexed into ----------------------------------------------------------- The above to extract uses a lot of code. But the savings are worth the effort.

Space for 40 rooms. The numbers game. From this point on we start to play the numbers game. Here we look at the data and do a simple calculation on how much code is needed to compress the data. For manic Miner and twenty rooms, compression is rather pointless in most cases. To save a byte in the room data needs to take less than 20 bytes to extract from the data. In JSW the bytes saved for each room needs to take less than 60 bytes to save any memory and then we loose the nice page alignment that makes the data so easy to use. In expanding JSW to 128 rooms we now have the bigger savings. Each byte saved in a rooms data, can be offset by needing 128 of code to make the saving not worth while. 128 bytes of code is a large piece of code. Back to 20 rooms and Manic Miner. If we look at the bigger room count of 40 rooms, we can see that each byte saved in a room now can be matched against needing less than 40 bytes of code to justify its inclusion. The definitions for each tile are stored in each room. Manic miner has space for the definitions used in 20 rooms, each room storing its own tile definitions for space/floor/wall/collapse/nasty 1/nasty 2/key/conveyor. That is 8 character/tile definitions per room or 160 tile definitions in total. Manic Miner does not use anywhere near that amount of tile definitions. Scanning the data it was found to use less than 80 tile definitions. If the room count is expanded to 40 rooms. Manic Miner, if left unchanged would store enough tile definitions for 320 tiles. Whilst the original 20 room Manic Miner manages with less than 80 definitions, this suggest we have leeway in reducing the amount of tile definitions used. It would not compromise how the rooms are stored and drawn. If we undertook a massive reduction from the 320 tile definition possible, down to 128 tiles in total. From past usage this would not introduce a great restriction. Saving (320-128)*8 bytes . The problem now is now how does the room store the new data, and how much code does it take to expand out. One problem at a time. 1)The tile data is very rarely referenced. Its main and biggest reference is drawing the rooms. So the room draw routine needs changing to reference tiles in a more obscure way. The room draw routine has been changed to uses nibbles for its data, changing the room draw routine to permit tile numbers instead of the tile graphic data does not take much code. Probably less than fifty bytes. which is dwarfed by the amount of data potentially saved. 1a) The keys use the tile data to repeatedly draw the keys. It is easier and quicker to copy each rooms key data into a buffer (when drawing the room) and use that data. 1b) The storage of the graphics is separated from the room data. This changes how the room stores the graphic data. I kept the colour byte and replaced the eight definition bytes for each tile with a tile index value. This changes the original layout and reduces the size of the tile data from 64 bytes per room to 8 bytes per room. (At a later date this was expanded to use the whole 16 possible tile definitions) 1c) The room and its data size is now less than a nice page aligned value. We now need to calculate the offset to each room. Playing the numbers game. Data reduction by shifting the graphics(tile) data out of the rooms into a separate list is reduced by having to write several pieces of code and having to incorporate a new set of indexes into each room. Data lost from each room for a 40 room version of Manic Miner is 56 bytes. but we also now have a big table of data being all the tile definitions which is (128*8) bytes overall for 40 rooms the figures are. 40 rooms reduced in size by 56 bytes or 2240 bytes against adding the tile data (128*8) byes or 1024 byes + the code. It is a very large piece of code that consumes nearly 1116 bytes - it is worth the convoluted effort to use separate tile graphics The above is a start. we can compress .... (edited --- 2)