Norman Sword

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)

The purpose and scope of the routine was primarily a proof of concept. After asking myself how easy is it to edit the original Manic Miner and compress the data slightly to enable 40 rooms. I decided to take a new naked listing of Manic Miner and look at how the original stored its data. Matthew stored the room graphic layout as an attribute tile for each and every one of the 512 tiles. In JSW the tiles were stored as a bit stream of pairs of bits describing one of four types, resulting in a reduction from 512 bytes down to 128 bytes plus an eight byte overhead to describe one stair and one conveyor. Manic Miner has more tile types and two bits does not give enough scope to describe the room without more add ons. Manic Miners room layout can be described with a stream of three bits (giving enough scope for all the rooms) . But a three bit stream of data is not easy to visualise or edit, and we still need to tag on one extra bit to describe the direction of the conveyors. Easy enough to write in code- but as I said not easy to edit the bit stream when seen as data. It makes more sense and is easier to visualise if we expand to a four bit stream of data. Here each four bits corresponds to a nibble of data. Very easy to edit, easy to visualise and editable with just a hex editor Expanding to nibbles to describe a room, actually compresses the original 512 bytes of data describing each rooms layout in Manic Miner down to 256 bytes. *** NOTE *** this compression is designed to be primitive in its layout. I could compress down to a quarter of this size if I used a more aggressive method. Editing naked layout data then becomes very difficult. Once I decided on using nibbles to represent each of the tiles, it is obvious I can have more types of tiles described by each nibble. Reducing each basic room layout and definition from 4*256 bytes to 3*256 bytes still does not give enough scope to greatly expand the room count... It has released 20*256 bytes of data, which is nearly enough for seven rooms. So doing just this slight compression allows 27 rooms for Manic Miner. It would not take much effort to do this- an expansion to 27 rooms is very easy. It just needs the indexing of rooms and the drawing of the rooms to be changed. (ignoring the few data reference's that also need changing) 40 rooms needs a bit more effort.

The reason the game has the cheat invoked at run time, was to facilitate the discovery of the other features.

I will post the novelty tomorrow. It is something I have not written for Manic Miner before. The novelty was aimed at a group such as this - It was how ever not finished due to lack of space in 48k. I use an assembler and editing is just a text file to play with. Of interest - In conversation recently with Matthew I asked him about the way he edited Jet Set Willy. Due to the nature of the Tandy hex memory editor it seemed more than likely that the data was page aligned due to the Tandy's method of Paging memory displayed in the editor. This then makes each room a page on the Tandy and each piece of data is fixed in position on the Tandy screen. You can flip pages and the conveyor data for each room stays in the same place. as does all the other room data. Easy to flip through the rooms changing bits and pieces. He confirmed to me that he edited the data for each room directly in hex- no editors- no room editor- no sprite movement editor- each room was edited directly in hex. Think about editing the room shape in hex for every room- without an editor - just editing the hex. Which considering that each of the 60 playable rooms has 256 bytes editable- I find it amazing that he managed to get to the end with just one bit wrong for the arrow. The other errors are the result of not having quick and fast access to each room. The easiest and probably best method of finding errors is having the demo room flash past. The arrow problem (MIGHT) have been spotted. For manic Miner he wrote an editor - What format that took I have no idea.

This starts by default with cheat switched on. If edited, the cheat can be switched off . To enable a normal start to the game.

Changed the wording on the download file from "top 20 caverns" to "Last 20 Caverns". Questionable the depth of the caverns- because the very last cavern provides access to ground level. To jump caverns press the combination of "3" and "1" to move to a previous cavern- or press "3" and "2" to move to the next cavern. Pressing "3" resets the cavern. Each cavern has 16 tiles from which it can be drawn. Kong is movable. Multiple conveyors Switches are movable Any sprite in any room any combination of sprites in any room any event Kong-Skylab-Light beam in any room any combination of events in any room But the above is NOT what is different with this version.

Manic 40 Miner After I stopped developing the JSW128 VK VL VM engine. I spent a week writing a version of Manic Miner called Manic 40 Miner. This does not contain any new rooms. They are the original and Ligans rooms. This is NOT meant to be a playable version. It was just a test routine. The rooms have a lot more scope to edit and have a lot more tiles to play with. NOTE this runs in 48k the same as the original. It does a lot more than is obvious from a quick glance. ---------------------------------------------------------------- addendum. The feature that I mentioned with the comment "It does a lot more than is obvious from a quick glance." was explained in more detail in Post #14. The file size become excessive to edit online. So that explanation in post #14 is only current up to V5. I have attached a file that explains the current version here on post #1 Surprised that the earlier versions are still being down loaded. (i will delete them - they now serve no purpose) V1 was down loaded 4 times V2 was down loaded 9 times V3 was down loaded 6 times V4 was down loaded 3 times V5 was down loaded 3 times V6 was downloaded twice V6a followed by V6b fixing- specific flaws caused by one line of code deleted and an assembler problem Plus too much haste. V6c downloaded 37 times - version was not completable without editing Only the last version V6 revisions has been left. Manic 40 Miner V6 Editor Text.txt Manic 40 Miner V6c6.tap The Final final version V6c6 - this is a data changed version from V6b The version v6c6 is playable through all the 40 caverns. (other versions are not)

Logical progression from version to version. Main changes. Version K was a completable version introducing several aspects of game play, and 128 rooms in 48k Version L removed the superjump, which had no real purpose, and removed the live's bonus. The reason for those two changes was the introduction of a portal. This I felt was sufficiently different to justify a rename of the versions. Version L demo, updates the games structure completely. Which is the reason for the dramatic increase in speed Version L demo update. (this version has never been released) This was an update where I added a lot of (now unseen/deleted) routines that expanded the graphics. Used mainly on pause and demo. These graphic routines redrew the screen in double and quadruple size. Whilst it was interesting to write those routine. I decided I could use the memory taken up by those routines in a better way. ------------------------------------------------------------------------------------------------------------------------------------------------- The standard game and inclusive of version K has a death sequence where when Willy dies, if he has lives left. Then he is shown re-emerging into the same room. Version L changed the sequence to when Willy dies, if he has time left. Then he is shown standing in the last portal he visited. This might be a long way away from where he died and all the objects collected since visiting the portal are all reinstated into the game. This is a major change in logic, and necessitates a lot of routines to be changed ---------------------------------------------------------------------------------------------------------------------------------------------- Version M has the ability to switch between these two basic game formats. The standard "die and re-enter the room" (version K and standard format games) and the extended logic used in version L where the standard "die re-enter the room" is changed "to die emerge from portal" In order to switch between the two differing logics was to me a challenge. I needed to back track all the changes I had made and modify the code to swap logics. Version M is version "K" and Version "L" combined. So in essence it supersedes both of the earlier versions. In order to have the ability to switch the logics I needed the simple addition of a key to press and perhaps a graphic indicating what is being changed. Instead I decided to add a graphic page with options. The memory needed for the options page was taken from the double and quadruple draw routines. Which is why they no longer exist in the game. Version "M" can play in the same basic way as version "K", and also has the ability to switch to the game mode introduced in version "L". It also uses the extended logic written into version "L" demo. The options page adds the ability to start in most of the rooms. selectable for every game start. It permits the ability to switch the shooter on and off. It permits the ability to change the shooter graphics. It permits the ability to use one of sixteen predefined Willies to play the game. It permits the player to switch off the many flashing screen graphics. It adds a proper in game tune playing ability.. The options page and all the changes that necessitated in the game consumed quite a lot of memory. The memory was found by deleting the double and quadruple draw routines. It also cut short the extension of game logics. I had added quite a few and had started to add the features into the game. I think only one or two now remain and the others deleted. The Major problem I have describing changes is that familiarity to the changes blurs what is new to me. For example the cold room has twinkling stars in the room. When those stars started to twinkle and in what version would necessitate my going back through all the versions looking to find when it happened. I have better things to spend my time on, and those twinkling stars are just one of the hundreds and hundreds of changes I have done.

JSW128vM View File The logical sequence from JSW128VK and JSW128VL. The game changes are very few. This final version written very soon after jsw128VK, and has been sitting on my hard drive, for six months - awaiting further changes. Since I have decided to do other things, it has become obvious to me that this will not be updated in any way. short Condensed notes on game. 128 rooms Runs in 48k Can play In long notes for game music and not clicks triple speed multiple game options Game options menu 16 game characters to use ability to use portals ability to change start rooms extensive inbuilt cheat Cheat is activated by typing "IWroteQuip" or as spoken ( I Wrote Quip ) - without the spaces Submitter Norman Sword Submitted 12/25/2019 Category Jet Set Willy [Remakes]  

1) The topic is well known about and has been discussed by various forums. 2) The graphic layout of the piano keyboard although wrong has been copied onto various other machines. It is what Matthew drew, so even though it is wrong, it has been copied with the incorrect layout. 3) The locations of the notes being played and displayed on the graphic keyboard, have no relationship to the music playing. The offsets to each note that is played is based purely on its arithmetic value and this creates a linear offset to each note. The offsets should be logarithmic. 4) The note that is highlighted never encroaches onto the upper portion of the keyboard. The parts illuminated are all identical. 5) The music played is a simple Pulse wave (square wave). Which because Matthew decided to use two waves generates a pulse wave difference. The sound you hear is the characteristic sound produced by the shifts in the values of each pulse. Similar to hearing Doppler shifts and harmony beats. The values used by the music have no bearing on how the music notes are seemingly played on the keyboard. So the values chosen were not influenced by the graphic depiction, With the consequence that no attempt was being made to avoid any part of the keyboard. The light up routine could play play a piano slide and thus light up each note in sequence if it was needed.

Halfway through typing this it posted, with an error message. Hence the retype on post #4

The strike through fell off and is lying somewhere in cyberspace. The op codes in the listings which are unwanted have been rem'ed out and also struck through again. (just in case I paste and copy again) with that statement I am reminded that the original still has only the strike through. So I will edit that as well. Code with the unwanted parts will still work. But since it is not needed best rem'out in addition to the strike through. (or just deleted completely)

Semantics:- Every version of the raster copy routine listed under "source code for JSW" does not use the "a" register. I subsequently added before and after the actual routine a part which modified the Block_Copy routine (which ever variant of the block copy routine as listed in each post). The raster copy routine still does not use the a register, but the modifying code before and after did use the "a" register. I have done the trivial change to each modifying addition to remove the usage of the "a" register throughout the whole raster copy.

All the raster copy posts under the heading "source code for JSW" work as stated. None use the piece of code listed back in APRIL 2017 and quoted in post #62. Because you are reverting between differing pieces of code used over many years, I have expanded each reference to raster copy listed under "source code for JSW" to be self contained. Each and every version works and none use the "A" register.

I have edited three posts to remove the conflict of BLOCK_MOVE32: being used with differing routines. The routine that uses a long line of ldi's and returns without decrementing the "A" register has had its labels changed That block move now uses the labels BLOCKX_MOVE32 and BLOCKX_MOVE31. the inclusion of the X mid label hopefully removing confusion between two very similar routines, which are mentioned sporadically over a few posts.

since the source code for me is just a blank canvas to edit. I am not restricted to worrying about will a piece of code fit in here or there. If I delete a byte in the source code, I immediately have that byte and it can be used anywhere I want in the limits of the memory I am editing. The restrictions are removed. Block move ld hl,source ld de,destination ld bc,size ldir looking at this yet again, but from the no restrictions point of view. The best solution is slightly different Shift_block32: ; new label to distinguish from all the other code ldi Shift_block31 rept31 ldi endm jp pe,Shift_block32 ret we write the code out exactly as specified in JSW but we now use one more byte on each instance and rather than LDIR we use an extra byte and call Shift_block32 or Shift_block31 ; Depending on the value being divisible by 32 or one short This also does not use the "a" register- similar to LDIR on its own. This method also is as close to a replacement LDIR as we can generate in code, returning with the same parameters as would be set with LDIR. so LD HL,CHAR0 ;L869F ;$4000 LD DE,CHAR0+1 ; 86A2 ;$4001 LD BC,$1AFF ; 86A5 ; LD (HL),$00 ; 86A8 ; LDIR ; 86AA ; call shift_block31 This is faster again (marginally) but uses the same registers as the original I suppose you could modify this routine to use a similar raster copy routine as the one posted above. e.g. ----------------------------------------------------------------------------------------------------------------------------------------------------------- ;copy work and attribute screens ld hl, S_M_C_New_Mod ;place to modify ld (hl),$c9 ; modify in a "ret" ld hl,att_work ld de,ATT0 ;;;;ld b,0 ; this was set for usage in a different routine exx ld hl,ytable ld bc,128 ; must be a multiple of 32 ; this is 4*32 ;- that is 4 raster lines before the attributes are written in ;loop executed 128 times on each game loop raster: ld e,(hl) inc l push hl ld h,(hl) ld l,e ld d,h res 5,d call Shift_block32 ;executed 128 times on each game loop jp pe,n_raster exx ; this code is executed 16 times on each game loop ;;;;ld c,32 ; this was set for usage in a different routine call Shift_block32 exx inc b n_raster: pop hl inc l jr nz,raster ld hl,S_M_C_New_Mod ;place to midify Ld (hl),$ea ;opcode for Jp PE,xx rest of code ----------------------------------------------------------------------------------------- Shift_block32: ; new label to distinguish from all the other code ldi Shift_block31: rept31 ldi endm S_M_C_New_Mod Equ $ jp pe,Shift_block32 ;opcode toggled between ( "ret" ) and ( "jp pe,xx" ) ret

Since the last posted raster copy is a lot faster without using the "a" register and we don't want to supply two lots of LDI routines..... Lets just chop up the old LDI routine and make that return without modifying the "a" register. Then we have only one LDI routine. The chopping up of the routine takes 5 bytes to modify and five bytes to put it back. Since these two modifications are executed only once, it is a lot faster than having to re-use the "a" register inside the loop. The Block move from post #58 BLOCK_MOVE32: ldi BLOCK_MOVE31 ldi rept 30 ldi endm S_M_C_fast: equ $ dec a ; change this opcode jr nz,BLOCK_MOVE32 ret ;----------------------------------------------- The raster copy is expanded to become ;modify ld hl,S_M_C_fast ;position to modify ld (hl),$C9 ;opcode value for ret >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ;copy work and attribute screens ld hl,att_work ld de,ATT0 ;;;;;; ld b,0 ; this was set for usage in a different routine exx ld hl,ytable ld bc,128 ; must be a multiple of 32 ; this is 4*32 ;- that is 4 raster lines before the attributes are written in ;loop executed 128 times on each game loop raster: ld e,(hl) inc l push hl ld h,(hl) ld l,e ld d,h res 5,d call BLOCK_MOVE32 ;executed 128 times on each game loop jp pe,n_raster exx ; this code is executed 16 times on each game loop ;;;;ld c,32 ; this was set for usage in a different routine call BLOCK_MOVE32 exx inc b n_raster: pop hl inc l jr nz,raster >>>>>>>>>>>>>>>>>>>>>>>>>>>> ;restore back to old ld hl,S_M_C_fast ld (hl),$3d ;opcode value for dec a ; rest of code which leaves only one ldi routine. That's today's version.....

The original with the "a" register passing the amount of copy was in response to the limited space available in the source code. ld hl,source ld de,destin ld bc,count ldir being 11 bytes in size.. modified to be ld hl,source ld de,destin ld a,count/32 call BLOCK_MOVE32 ; which uses "a" as a counter which is also 11 bytes in size and can be easily fitted into the same size space. IGNORING the raster copy routine for now. Lets look at the format of the original BLOCK_MOVE32 which was BLOCK_MOVE32: ldi BLOCK_MOVE31 ldi rept 30 ldi endm dec a jr nz,BLOCK_MOVE32 ret This has two labels BLOCK_MOVE32 and BLOCK_MOVE31. It could be written out to have every label from BLOCK_MOVE32 down to BLOCK_MOVE01. It doesn't because the other labels would be used infrequently and I am lazy. I can not be bothered writing them all out. Problems using the above routine to move odd amounts........ The bulk of block moves in the game are multiples of 32 and a call to BLOCK_MOVE32 does the job. However we also have cases where we copy a block in a block copy sequence such as. : this code will clear the screen attributes to black on black ld hl,ATT0 ld de,ATT0+1 ld bc,$2ff ld (hl),0 ldir this might seem to not be of the same format. we are copying here $2ff of data which is not a multiple of 32. But look again at the amount. I can re write $2ff in a different way, such as $300-1. Clearly the same value and clearly this is very similar to the format being used in the standard block move. so lets adapt that code ld hl,ATT0 ld de,ATT0+1 ld (hl),0 ld a,$300/32 ; MOVE $300 bytes call BLOCK_MOVE31 ;MOVE $300 bytes -1 e.g. move $2ff bytes <<<<<<< NOTE BLOCK_MOVE31 this has moved $2ff bytes which is what we wanted.... In jsw the vast majority of block moves want to move either a multiple of 32 bytes or one short of a multiple of 32 bytes. Which is why I only expanded BLOCK_MOVE32 and BLOCK_MOVE31 out in the routine to move the data. Going into jsw we have ... And this is just a quick grab from the source code. For all the big block moves LD HL,CHAR0 ;L869F ;$4000 LD DE,CHAR0+1 ; 86A2 ;$4001 LD BC,$1AFF ; 86A5 ; ld a,$1b00/32 LD (HL),$00 ; 86A8 ; LDIR ; 86AA ; call BLOCK_MOVE31 LD HL,code_att ; 86E8 ;L9B80 LD DE,ATT8 ; 86EB ;$5900 LD BC,$0080 ; 86EE ; ld a,$80/32 LDIR ; 86F1 ; call BLOCK_MOVE32 LD HL,CHAR0 ;L8813 ;$4000 LD DE,CHAR0+1 ; 8816 ;$4001 LD BC,$17FF ; 8819 ; ld a,$1800/32 LD (HL),$00 ; 881C ; LDIR call BLOCK_MOVE31 LD HL,logo_att ; 8820 ;L9800 LD BC,$0300 ; 8823 ; ld a,$300/32 LDIR ; 8826 ; call BLOCK_MOVE32 ;recolour line 19 LD HL,ATT19 ; 8828 ;$5A60 LD DE,ATT19+1 ; 882B ;$5A61 LD BC,$001F ; 882E ; ld a,$20/32 LD (HL),$46 ; 8831 ; LDIR call BLOCK_MOVE31 LD HL,ATT19 ; 88B8 ;$5A60 LD DE,ATT19+1 ; 88BB ;$5A61 LD BC,$001F ; 88BE ; ld a,$20/32 LD (HL),$4F ; 88C1 ; LDIR ; 88C3 ; call BLOCK_MOVE31 LD HL,bottom_att ; 8907 ;L9A00 LD DE,ATT16 ; 890A ;$5A00 LD BC,$0100 ; 890D ; ld a,$100 LDIR call BLOCK_MOVE32 LD DE,room_layout ; 891A ;L8000 LD BC,$0100 ; 891D ; ld a,$100/32 LDIR call BLOCK_MOVE32 LD HL,CHAR16 ; 8958 ;$5000 LD DE,CHAR16+1 ; 895B ;$5001 LD BC,$07FF ; 895E ; ld a,$800 LD (HL),$00 ; 8961 ; LDIR call BLOCK_MOVE31 LD HL,att_master ; 89B0 ;$5E00 LD DE,att_work ; 89B3 ;$5C00 LD BC,$0200 ; 89B6 ; ld a,$200/32 LDIR call BLOCK_MOVE32 LD HL,char_master ; 89BB ;$7000 LD DE,char_work ; 89BE ;$6000 LD BC,$1000 ; 89C1 ; ld a,$1000/32 LDIR call BLOCK_MOVE32 LD HL,char_work ;L89F5 ;6000 LD DE,CHAR0 ; 89F8 ;$4000 LD BC,$1000 ; 89FB ; ld a,$1000/32 LDIR ; 89FE ; call BLOCK_MOVE32 LD HL,att_work ; 8A1A ;$5C00 LD DE,att_work+1 ; 8A1D ;$5C01 LD BC,$01FF ; 8A20 ; ld a,$200/32 LD (HL),A ; 8A23 ; <<<<<< a reg problem LDIR call BLOCK_MOVE31 LD HL,att_work ;L8A26 ;$5C00 LD DE,ATT0 ; 8A29 ;$5800 LD BC,$0200 ; 8A2C ; ld a,$200/32 LDIR ; 8A2F ; call BLOCK_MOVE32 LD HL,bottom_att ;L8B07 ;L9A00 LD DE,ATT16 ; 8B0A ;$5A00 LD BC,$0100 ; 8B0D ; ld a,$100/32 LDIR call BLOCK_MOVE32 LD HL,ATT0 ;L8C03 ;$5800 LD DE,ATT0+1 ; 8C06 ;$5801 LD BC,$01FF ; 8C09 ; ld a,$200/32 LD (HL),A ; 8C0C ; <<<<<< problems here with the a register LDIR call BLOCK_MOVE31 LD HL,CHAR0 ;L8C4A ;$4000 LD DE,CHAR0+1 ; 8C4D ;$4001 LD BC,$0FFF ; 8C50 ; ld a,$1000/32 LD (HL),$00 ; 8C53 ; LDIR call BLOCK_MOVE31 LD HL,att_master ; 96F4 ;$5E00 LD DE,ATT0 ; 96F7 ;$5800 LD BC,$0200 ; 96FA ; ld a,$200/32 LDIR ; 96FD ; call BLOCK_MOVE32 LD HL,CHAR0 ; 96FF ;$4000 LD DE,CHAR0+1 ; 9702 ;$4001 LD BC,$0FFF ; 9705 ; ld a,$1000/32 LD (HL),$18 ; 9708 ; LDIR call BLOCK_MOVE31 The above illustrates why we have BLOCK_MOVE32 and BLOCK_MOVE31 . In a game like JSW we are moving multiples of 32 in the vast majority of cases. Only two of the above cases causes a pause and a need to work out how to preserve the a register. (it might contain more instances where the "A" register needs to be preserved) very easy to change and very easy to work out. The problem then comes with , how we manage the raster copy. Which in the recent posting uses a differnt BLOCK_MOVE

Each example I write is self contained unless otherwise stated. The last example I wrote uses no check on the block of 32 ldi's and just returns. The above code "as used in post 54" is an old example which does use "a" as a counter. Give me five minutes and I will test the example as I wrote it and get back to you. But I think it will work as written ;----------------------------------------------------------------------------------------------------------------------- Works exactly as I said it would.

Standard assembler directives:- One of the biggest helps is the macro language that you can build into pieces of standard code that are often used. The standard macro is as such: silly: Macro param1,param2,param3 ld hl,param1 ld de,param2 ld bc,param3 ldir endm. The macro here is defined by the label silly. Every time the word silly is seen in the source code it will replace it with all the code between the MACRO and endm. The word endm is shorthand for "end macro" So How do I use silly in a piece of code ( don't forget this example is called silly, because it is a silly example) I simply write in to the assemble code silly ATT0,ATT1,32 when the code is assembled the above will be substituted with ld hl,ATT0 ld de,ATT1 ld bc,32 LDIR which is the macro expanded and each of the labels re placed with the parameter passed to the macro. e.g ld hl,ATT0 ; here param1 is replaced with ATT0 ld de,ATT1 ; here param2 is replaced with ATT1 ld bc,32 ; here param3 is replaced with 32 LDIR Macros are very helpful to expand code out that is repetitive. another form of macros. is the rept directive. (rept = repeat). so getting back to to the original querry rept 32 ;repeat 32 times ldi endm ; end macro means repeat the line of code between the rept directive and then endm directive 32 times we can create big blocks of code by repeating and nesting : (these examples are just examples not taken from any code) so lets look at move macro count rept count ld a,(hl) ld (de),a inc hl inc d endm endm we can in the assembler now write move 8 and this will generate the inline code ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ld a,(hl) ld (de),a inc hl inc d ; which is the quickest way of doing this operation possible. we have no loop counter. The above probably seems to be pointless, but consider a piece of code I have mentioned several times and written out an example of once. which is the stack copy. To speed up a stack copy we set up a nest macro similar to the example above. When the macro is expanded we end up with a big block of inline code. (the expansion can end up with 500 or more lines of code) we can also pass counters that can be used and acted upon. Macro's are also literally expanded and can cause no end of problems when the expansion does not seem to do what is wanted. ;-------------------------- TOO MUCH INFORMATION ------------------------------------- short answer REPT is short for REPeaT ENDM is short for END Macro