Norman Sword

; because it was a few bytes too big ; I have extended the scope of the modification ;there are now free bytes ROPE_TABLE x8300 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8308 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8310 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8318 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8320 DEFB 6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1 x8328 DEFB 6*2+1,6*2+1,6*2+1,6*2+1,6*2+2,6*2+2,6*2+2,6*2+2 x8330 DEFB 4*2+2,6*2+2,6*2+2,4*2+2,6*2+2,4*2+2,6*2+2,4*2+2 x8338 DEFB 6*2+2,4*2+2,4*2+2,4*2+2,6*2+2,4*2+2,4*2+2,4*2+2 x8340 DEFB 4*2+2,4*2+2,4*2+1,4*2+2,4*2+2,4*2+1,4*2+1,4*2+2 x8348 DEFB 4*2+1,4*2+1,4*2+2,4*2+2,4*2+3,4*2+2,4*2+3,4*2+2 x8350 DEFB 4*2+3,4*2+3,4*2+3,4*2+3,4*2+3,4*2+3 From here X9316 ld c,(ix+rope1) ;$1 this replaces the add a,(ix+rope1) ADD A,c ;remove the rope swing direction bit (bit 7) res 7,a ; it helps to include the full modifications ld l,a ld H,High ROPE_TABLE ; $83 ; extract the data, 00001100b contains the Y-shift ld a,(hl) ;grab data hl=pointer to rope data and 1100b rrca ;instant crash is this value is odd (no possibility with previous AND instruction) ; add Y-shift onto the Y-table offset add a,iyl ld iyl,a ;extract the data, 00000011b contains the data for X-shift ld a,(hl) and $03 ;$03=3=00000011B ; carry on removing excess code JR Z,L9350 ;Jump if so LD B,A ;B is the count for rotations of the drawing byte (the rope drawing data bit) BIT 7,C ; right of centre? LD A,(IX+rope5) ;$05;the drawing bit JR Z,rope_right ; rope_left: RLCa ;Rotate the drawing byte left once JR nc,hop1 ;has the bit rotated around DEC (IX+rope3) ;$03;Decrement the x-coordinate hop1: DJNZ rope_left ; JR SAVE_A ; saving "A" the continue rope_right: RRCa JR nC,hop2 ;has the bit gone full circle INC (IX+rope3) ;$03;Increment the x-coordinate hop2: DJNZ rope_right ; SAVE_A: LD (IX+rope5),A ;save the rotated drawing bit ;end of mods ; There is now space here that needs filling with NOP up to $9350

Curious if the change would do as I expected. Short answer yes.. ROPE_TABLE x8300 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8308 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8310 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8318 DEFB 6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0,6*2+0 x8320 DEFB 6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1,6*2+1 x8328 DEFB 6*2+1,6*2+1,6*2+1,6*2+1,6*2+2,6*2+2,6*2+2,6*2+2 x8330 DEFB 4*2+2,6*2+2,6*2+2,4*2+2,6*2+2,4*2+2,6*2+2,4*2+2 x8338 DEFB 6*2+2,4*2+2,4*2+2,4*2+2,6*2+2,4*2+2,4*2+2,4*2+2 x8340 DEFB 4*2+2,4*2+2,4*2+1,4*2+2,4*2+2,4*2+1,4*2+1,4*2+2 x8348 DEFB 4*2+1,4*2+1,4*2+2,4*2+2,4*2+3,4*2+2,4*2+3,4*2+2 x8350 DEFB 4*2+3,4*2+3,4*2+3,4*2+3,4*2+3,4*2+3 X9316 ADD A,(IX+rope1) ;$01 From here ;remove the rope swing direction bit (bit 7) res 7,a ; it helps to include the full modifications ld l,a ld H,High ROPE_TABLE ; $83 ; extract the data, 00001100b contains the Y-shift ld a,(hl) ;grab data hl=pointer to rope data and 1100b rrca ;instant crash is this value is odd (no possibility with previous AND instruction) ; add Y-shift onto the Y-table offset add a,iyl ld iyl,a ;extract the data, 00000011b contains the data for X-shift ld a,(hl) and $03 ;$03=3=00000011B ;To here X9327 JR Z,L9350 ;Jump if so X9329 LD B,A ;B is the count for rotations of the drawing byte (the rope drawing data bit)

The problem I am having is the fact that any code I look at, has a lot of changes. If I spot a problem I change the code, The code area around this modification has been modified to fix the rope bug and the res 7,A which was before the LD A,L was ignored.. The code that deals with the offset into the rope data is confined to this local area. No other part of the program uses the rope data. Still, I will modify to include the res 7,a in the listing above. (because it should have been included) And yet again change the data. With all sets of data the rope animation was happy to use the data provided

Text has been edited to correct lots of errors --- see post following Which highlighted a problem, which has been edited twice. Also edited to include a missing opcode ------------------------------------------------------------------------------------ Space to spare. I read recently in a post that you were using the rope table space for data/code. It is an very easy matter to delete most of the data and use the space saved to implement the LDI table as mentioned above replace the data table with this data. ROPE_TABLE x8300 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8308 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8310 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8318 DEFB $60,$60,$60,$60,$60,$60,$60,$60 x8320 DEFB $61,$61,$61,$61,$61,$61,$61,$61 x8328 DEFB $61,$61,$61,$61,$62,$62,$62,$62 x8330 DEFB $42,$62,$62,$42,$62,$42,$62,$42 x8338 DEFB $62,$42,$42,$42,$62,$42,$42,$42 x8340 DEFB $42,$42,$41,$42,$42,$41,$41,$42 x8348 DEFB $41,$41,$42,$42,$43,$42,$43,$42 x8350 DEFB $43,$43,$43,$43,$43,$43 X8355 DEFB $21,$21 The continuous data space from $8358 up to $8400 becomes free to use. Change the code as listed below to use this changed data table (assuming it will fit between $9316 and $9327 If it wont fit there is plenty of space created by deleting the second half of the rope table X9316 ADD A,(IX+rope1) ;$01 From here ;remove the rope swing direction bit (bit 7) res 7,a ; it helps to include the full modifications ld l,a ld H,High ROPE_TABLE ; $83 ; extract the data, high nibble is Y-shift ld a,(hl) ;grab data hl=pointer to rope data rrca rrca rrca rrca and $0e ;$0e=14=00001110B ; ;instant crash is this value is odd (easier to just remove possibility) ; add Y-shift onto the Y-table offset add a,iyl ld iyl,a ;extract the data, low nibble is X-shift ld a,(hl) and $0f ;$0f=15=0000111B ;To here X9327 JR Z,L9350 ;Jump if so X9329 LD B,A ;B is the count for rotations of the drawing byte (the rope drawing data bit) ;-------------------------------- from a casual look it would appear the extra code Res 7,a make this mod bigger than the available space. If it MUST fit and you can be bothered altering the data. Then the rope data can be changed to use 2 bits for the x offset and 2 bits for the y offset. eg. 00000011b for xoffset and 00001100b for the y offset. This mod changes the code to remove probably enough opcode to make it fit the y-offset is always even and so has only values of 6 and 4 . two bits allow for values 0,2,4,6 x is extracted with and 3 (not and $0f) The y is extracted with and 1100b rrca ; note only one rrca needed so 3 bytes shorter For me the extra effort was not worth while. I had no intention of only modyifing the original code and restricting my self to the available space

This is a deleted copy of the above.

The ldir block move of data takes 22-T-states to move a single byte of data. When the LDIR is used to move say 4096 bytes of data it takes 4096*22 T-states (90112) T-states in total. Using a long line of 32 LDI's changes the timing to around 16 T-states per byte. Note this is per byte. There is an overhead of dec "A" every 32 bytes and the JR every 32 bytes, this extra overhead is around 16-t-states. But for every 32 bytes you have saved the difference between LDIR (22) and LDI (16) which is 6 T-states times 32. = 192 t-states The saving per 32 bytes is 192 T-states (minus) the loop over head of 16 T-states. so a saving of 176 T-states for every move of 32 bytes. Going back to the initial 4096 bytes moved with LDIR taking 90112 T-states. This is replaced by a repeating loop over the Block LDI code. In this case it will loop 128 times giving an overall saving of 128*176 T-states. or =22528 T-states . The call and the ret to the routine are insignificant compared to these figures. block move 32 bytes using LDIR =32*22 T-states=704 T-states block move using a long line of LDI= 32*16+16 =528 T-states LDIR of 4096 bytes=90112 T-states LDI of 4096 byes =128*528 T-states =67584 T-states a saving of 22528 T-states. Enough time saving in the one loop to execute around another two thousand op-codes Since every game loop:- It copies the master Att screen to the working Att screen it copies the working Att screen to the real Att_screen it copies the Master screen to the working screen It copies the working screen to the real screen. The game moves every loop an enormous amount of data. The jagged finger code for screen copy that I use, incorporates the block move into its code. Getting back to the original statement can I use some sort of sub loop? Short answer is No . We are dealing with tiny timing differences that accumulate into big differences due to the number of times they are executed 32LDI's in line was a compromise between speed and size. It also happens to be the amount of data in one raster line, so I settled on that figure just for that reason. It is not unknown for games to use a vastly larger piece of code to try and improve the speed even more. But then we start to move into the realms of using Stack copy and the associated amount of memory that uses. LDI is simple, easy to slot in, and does a major change in speed. ( since the figures listed above do not tally, there are mistakes in the arithmetic. This should not distract from the overall message conveyed) (edited yet again to get the figures on the arithmetic to match)

Part 3 A quick explanation of terms Master screen. Where the basic screen, minus sprites etc. is drawn Working screen. The master screen is copied here and the sprites added Real screen. Where the working screen is copied and is visible to the player Moving a one cell platform left or right, takes up very little effort or code. Because the rooms are redrawn from the master Attribute copy, and the master screen copy on each game loop. Any additional graphics etc. written just to the working copy screens will be deleted on each game loop, by the copying from the master to the working screens. Thus to move a single square requires just writing to the working screen a single graphic on each loop. Rather than work on the working copy screens. The platform data was written to the master screens. And as above writes just one graphic either a background (erase) or a platform (write) after any necessary delay. The code was written to have expanding contracting floors and not a single moving block. NOTE the difference in action, it looks the same, but the first method has to write the graphic on each and every game loop. The second method only writes when there is a change. The accumulative addition of unneeded code is a major factor in the speed of game play. For example. Unneeded game loop code. Why is the object count displayed on each game loop? It only changes on object collection Why is the time printed on each game loop? It only changes every 256 game loops Why are the dancing willies drawn when they do not dance? And the biggest problem the game has. Why move the data using LDIR? There are numerous methods that are quicker. --------------------------------------------------------- Side track on LDIR. Each byte moved using LDIR takes 22 T-states. To remove all instances of this slow block movement is very easy. First ignore the stack copy method, too many blocks of data and not flexible enough to slot into existing code. Use the simpler LDI method which only uses around 68 bytes and is very easy to insert into the code. start with the typical layout for block move using LDI e.g. set aside 68 bytes like so. BLOCK32 LDI BLOCK31 LDI BLOCK30 LDI BLOCK29 LDI ETC TILL BLOCK1 LDI DEC A JR NZ,BLOCK32 RET Next go through the original code and remove/change the LDIR code in this manner typical block move LD HL,COPY LD DE,SCREEN LD BC,1024 LDIR Change to LD HL,COPY LD DE,SCREEN LD A,1024/32 CALL BLOCK32 A block fill gets changed from LD HL,SCREEN LD DE,SCREEN+1 LD BC,4095 LD (HL),0 LDIR To LD HL,SCREEN LD DE,SCREEN+1 LD A,4096/32 ---- NOTE THE VALUE IS 4096/32 LD (HL),0 CALL BLOCK31 ---- NOTE THIS CALLS BLOCK31 it is possible to change all the current LDIR's in the game with the above style code. This will increase speed by over 20% The smaller block moves of 6 bytes etc are left. (not worth the effort- no speed improvement)

Part 2 The crumbling floors are similar to Manic Miner, but they can have blank lines of data and are not switched off when an empty line of data occurs on the bottom row. All the data has to be removed for the floor to finish crumbling. The routine uses 2 bit room data only because of the evolution from the original. The data is not stored in a comparable method. Crumbling floors do overlay the room data in a similar manner to conveyors and stairs. But the routines complexity is caused not by this overlaying and addition of a new graphic. But by the need to check for the position of any keys in a room and remove crumbling floors that appear in the same place. This means the crumbling floor set up routine has to expand all the keys onto the room map as well. Also unlike conveyors and stairs which overwrite everything underneath them, the crumbling floors have to also check for any graphics that is present and draw around them. In its original form the crumbling floors, expanding walls and other graphics used no extra room data. The data was contained in the 256 byte room block.

Part 1 There are multiple objects in multiple rooms which have removable walls. (all the central cavern style rooms) Matthews logic for handling objects is flawed. It works as long as the game has only a few objects. As the object count increases the logic makes the game slower and slower. However there are ways to overcome this slow method.. 1) sort the object list into room order. (done once at the start of the game). on room expansion, find the first object for the current room and store its offset. On each game loop start at the pre calculated offset and search only until no match for the current room. or 2) On room expansion create a list of all the keys in the current room. On each game loop search only the new list of keys. The above removes the slow key search. Next a specific check for willy. Which enables objects to pass over keys and not collect them. Also ropes and arrows. At the same time as each object is drawn it counts them, so in every room there is a counter for the total keys in the current room. It is the key counter which is used to trigger removable walls. (which could also be used as room blockers) The keys are still stored in the same manner. (sort off)

Other logic besides homing. The file that was posted from the crashed hard drive, uses a mid sprite bounce. On horizontal sprites, one bytes of the guardians data is not used. (I think it is offset 4) e.g. referenced by (Ix+4) On a normal sprite moving left checks for minimum, and moving right checks for maximum. By placing a value into offset 4 the routine was amended to check this value. Moving left check for value (ix+4) and reverse if matched Moving right check the (ix+4)-1 and reverse if matched Moving left do the normal minimum check. If minimum reverse and toggle bit 7 of (ix+4) Moving right do the normal maximum check. If maximum reverse and toggle bit 7 of (ix+4) This type of modification has no affect if no value is placed in (ix+4). So as long as the sprite data has (ix+4)=0 on all horizontal sprites, the game will run as normal. Inserting a value at (ix+4) which is between minimum (ix+6) and maximum (ix+7) will cause the sprite to bounce at a mid point normal movement >>>>>>>>>>>>>maximum<<<<<<<<<<<minimum>>>>>>>>>>maximum Mid sprite bounce >>>>>>>max<<<mid>>>>>>>max<<<<<<<min>>>>mid<<<<min>>>>>>>max<<<<mid>>>max<<<<<<<min Easy to do. But needs to heavily modify the code.

If you're referring to the last game post, i think you will find it has all the correct letters and punctuation. Just not in the right order.

Re Homing guardians. This is a test piece of code to do my implementation of Homing Guardians. Even though this code has a lot of other "speed changes", the interest is concentrated on only three rooms. The Bathroom, the Top landing and the First landing. This is a reimplementation of homing sprites. With no redesign of the room to make use of their abilities. The sprite on the top platform of the Bathroom, is slightly altered in logic --- The sprite the lower platform of Top Landing is slightly altered in logic --- This version will stop the toilet run due to third sprite in the bathroom. ---- But is not meant to be played beyond theses few rooms. ;-------------------------- Updated --------------------- It did not take me long to find a flaw... Caused by testing for a bit on room limits. Unfortunately I tested the bit for Character limits and not Attribute limits. (corrected) and also the apostrophe . homing test2.tap

No idea if this has been mentioned before. When the game pauses and starts its colour cycling, there is an anomaly in the code that handles the colour cycle. For example when the game is paused in the "to the kitchens/main stairway" there is a conveyor in the middle of the screen that due to the nature of this anomaly starts to flash. This is because the code has made the assumption that adding (18 hex) (24 decimal) to its colour. will not overflow into the flash bit. (clearly wrong because it can be seen to flash) The code in question . 8AF3 LD A,(HL) ;get ATTribute 8AF4 ADD A,$03 ; cycle ink 8AF6 AND $07 ;force in bounds 8AF8 LD D,A ;ink colour to D 8AF9 LD A,(HL) ;get attribute ;*** AND 10111000b to stop overflow into flash 8AFA ADD A,$18 ;cycle PAPER ; THE next instruction makes the assumption that the colour can not overflow into the flash bit 8AFC AND $b8 ;10111000B 8AFE OR D ;Merge in the new INK colour Not all that noticeable, but this is an anomaly that was probably not intended. Easily fixed within the realms of an assembler. Probably not worth fixing in the context of the finnished game

inc l djnz exp ; repeat for the byte (4 cells) inc de jr nz,EXPANSION ; first 256 done be careful of any slight editing you might be tempted to do. The routine as shown was modified to use different data (the overall routine works). I have for example listed four instructions from the routine. Of note the first instruction sets the zero flag, the last instruction of the four acts on the zero flag set by the inc L. Note that the DJNZ and the INC DE do not change the zero flag.

The code as listed was not tested (otherwise the mistake would have been obvious on first run). Yes the RRCA should have been RLCA ....

The version I recently posted also has the car changed. But more importantly I fixed the very weird keyboard that Matthew drew. On the long list of changes that have been done to "FIX" JSW, you have left the erroneous square from the title screen unchanged. Inside the lower portion of the letter "S". Is a diagonal square that has the top part green and the lower part black. This should be - top part green lower part blue.

I have not finished the editing. This Forums interface reacts to certain combinations of keys on my keyboard. In most case the result is a few seconds delay In other cases it interprets the keystrokes as an intention to POST Since I was nowhere near finished with my comment I have deleted the lot. And this comment is the result of my inability to delete an unwanted POST

Invert could use the same logic e.g ytable equ 6000h ;;; set to where ever the ytable is org 8000h ld iy,ytable ld ix,ytable invert ld e,(ix) inc ixl ld d,(ix) res 5,d dec iyl ld h,(iy) dec iyl ld l,(iy) ld bc,32 ldir inc ixl jr nz,invert ;That is it ;-------------------------------------------------------------------------------------------------- : this now becomes more complex because the attributes need copying as well attrib equ somewhere (the copy screen) ld de,5800h ld hl,attrib+15*32 exx ld a,4 ; the value that decides when the atrrib is changed ld iy,ytable ld ix,ytable invert ld e,(ix) inc ixl ld d,(ix) res 5,d dec iyl ld h,(iy) dec iyl ld l,(iy) ld bc,32 ldir inc a and 7 jr nz,not_yet exx ld bc,32 ldir ld bc,-64 add hl,bc exx not_yet inc ixl jr nz,invert ;That is it

Quicker to just write afresh Nostalgia ; the attrib must have been cleared else this will look a mess ; which would be done once on room entry ytable equ 6000h ;;; set to where ever the ytable is org 8000h ;enter with a=screen offset ; 0 to 127 ;;; 128 to 255 act the same as 0 to 127 ; ld iy,ytable ; add a,a ; ld c,a ; ld b,0 ; add iy,bc ld iyh, high ytable add a,a ld iyl ,a ld ix,ytable roll ld e,(ix) inc ixl ld d,(ix) res 5,d ld l,(iy) inc iyl ld h,(iy) inc iyl ld bc,32 ldir inc ixl jr nz,roll ;That is it ;;;I was too quick to post . I think that is NOW it

Since this was a program in development that has had its source code deleted. (actually on a burned out hard drive) A number of problems are known about and might have been in the pipeline to be eradicated. All the screens that mention demolition or purchased by the state and several others. Had been earmarked to be changed. The game map was being changed often up until the source code demise. It was known that two screens where inaccessible. If either of theses contain objects then the game can not be completed as it is. This program was a test vehicle to see what could be done. All the elements where starting to be put in place for the room designs to begin. Just before the code was lost. New extended guardian types had been written. More planed known original types not in order Horizontal Guardian Vertical Guardian Arrow Rope To these had been added Logic seeking horizontal Full logic seeking. Moving vertically and horizontally within the screen Of these types only one in in this development game. The Logic seeking Horizontal. Used once in "pruned roses" The first of the full logic seeking sprites was in a redesigned "bought by the state 5" You will have to take my word for it. But this type of sprite did move around both horizontally and vertically, avoiding the rooms graphics and seeking out willy. They moved vertically slower than willy, and they could therefore be enticed into positions that they found difficult to escape from. To play against this type of sprite required the player to manoeuvre the guardian into a trap position. --- That is why the room "bought by the state 5" had the row of upturned box's along the bottom. They where to trap the guardian below whilst moving above them. The final room design for this room was different. And it contained very little of the graphics seen in this room. From the short viewing I saw (and played) the logic seeking sprite where a very good addition to the normal sprite... Rooms where designed and then stored on a different basis to the original. A rooms data starts with a code byte. this signifies if the room has vertical compression or not. If vertical compression a stream of bytes describe the vertical components. This removes stairs and vertical components of the room. after the stream of vertical components comes a stream of horizontal components. These define what is left Placed on top of the room description is the normal conveyor and stair. This convention allows multiple stairs (but all in the same direction) plus multiple conveyors. Of which one is animated (pretty standard convention) The bulk of the remaining room description, sprite/guardians/border colour etc was stripped of all wasteful data. and a flag added to indicate if extra graphics are need or extra events are needed All unused guardian slots were deleted. All guardian definitions were reduced from eight bytes to 7 bytes. The code to do this is small, but saves 128 bytes of data when all the guardians for a room have been extracted, the code looked at the flag byte and started extraction of extras to be over laid on top of the room graphic data. This entails expanding/contractng floors . collapsing floors, wall blockers etc the above explanation is to show that to change a single room block without the source code is very difficult. (with the source code a matter of minutes) without the source code <<quicker to rewrite the game>>

I modified the file that was the last version, to make it more in keeping with what is expected. E.g. start at the title screen and have the start room as the Bathroom. Plus removal of the start status of being in cheat mode. I assumed that the modification to the game file was ok. Well contrary to what I expected the floor in slum clearance area 3 is missing. Which is something I must have done. I will attempt to correct my error.... Assuming I can. The other possibility is to download the original version which starts in a different room, and has the cheats enabled by default. The cheatcode is needed to remove the default cheats. But first I will investigate why the floor is missing ?

First statement is that this program is still running in 48k. These are not changes due to having more memory. These changes are due to rewrites in logic to shrink the core code down. Plus extensive modifications to how the rooms are stored. In this version ropes can be specified for position and length. It will also be noted that the ropes do not pick up willy when they pass though an object. It is permissible for other sprites to cross the ropes path. It is also permissible for ropes to collide with each other. Objects are not collected by ropes or arrows passing over them. The number of guardians in this version is still fixed at 127, however each guardian is modified by a guardian sub class. This permits the guardian to have numerous clone types For example the arrows are sub classed to be movable and have their timing changed. Ropes are moveable and can have their length changed. The movement of sprites has been redefined to include a mid sprite turn (definable and switch-able on a sprite by sprite basis or a room basis) The solar beam is movable and switch-able. The ability to jump into certain wall blocks has been greatly reduced. the code is 100% symmetrical.

I have resurrected this file By Derrick.P.Rowson. Which was on a crashed hard drive. This is Not finished, and never will be due to a catastrophic failure of the hard drive. This is a few weeks work and alas there was no backup of the program. This version does not have any of the new logic playing sprites. E.g. sprites that followed willy around both vertically and horizontally, and were free roaming around the screen. The logic had enough sense to move the sprite wherever it needed. This version was a development towards having the full Manic Miner + Jet Set Willy in 48k This game has inbuilt options. (password protected) jsw1.tap

The air supply. Decrease_Air ;original code at 35388 ld hl,Game_Clock ;original reference 32957 ld a,(hl) sub 4 ld (hl),a ;; ld b,a ;>>>>delete this instruction jr nc,Display_air ex de,hl ;save hl ld hl,Remain_Air ;original reference 32956 ld a,(hl) cp 36 ;if this returns then is should leave the air at "0" jr nz,decrease_bar xor a ld (de),a ret decrease_bar dec (hl) ld a,(de) ;>>>>> change from >>ld a,b ;21 Display_air AND 11100000b ;224 This is the slight change. I do not know if this would sit in the original space. tiny change 1 byte shorter

Scope of the editing. Forget the notion I added patches, this is a source code rewrite from the first byte to the last. I do not think there is any byte from the start of manic miner up to #b000 that is in the same place. This was not a version written using patches, but a version rewritten from the ground up using Matthews code as the basis. For example a walk from the left wall in the central cavern to the right wall in the central cavern. In the original Bug-byte version this takes just under ten seconds (9.83s) this newer version takes abour 7.42s which is a speed increase of 2.41s. This is over 20% faster. Every instance of code that was deemed to be wasting time or memory was rewritten. trivial changes that can be seen/heard Object collection makes a noise the light beam makes a noise if it collides with willy collisions make a noise the skylabs landing make a noise. the skylabs do not colour in the landing platform. logic rewrite collapsing floors could have blank lines. logic rewrite conveyors move slower. Manic Miner screen Game completion screen Sprite Easter egg screen Manic miner easter egg screen credit screen Icons new cheat implementation method the list of changes is vast I will do a count of the number of code changes...... I gave up after passing 2,500 new opcode/instructions in the code. Then there is the matter of the additional data for the icons, sprite mask, explosions The explosions uses 4k of memory 256 bytes extra just to store the 2nd scrolling message there is a big data table that lists the changes data between the two versions Forget the notion I added patches, this is a source code rewrite from the first byte to the last. .