Norman Sword

1) Differing Versions -- The game cycles every main (Title) screen display, between Bug Bytes and Software Projects version. The animated display on the main (Title) screen (near the house) shows the sprite from the version that will play. There is no option to switch mid game. ***NOTE*** the differing versions are swapped on the Title screen, If a version is displayed and you want the other version. Then start the game, and the abort back to the Title screen. The versions will have been swapped. 2) Toolkit -- The toolkit will rebuild collapsing floors when active. When the toolkit icon is displayed pressing "9" will rebuild all collapsed floors. Needed when you have collapsed all the floors and have no way of returning. Pressing "9" rebuilds the floors to enable escape. This is mainly needed when the medical kit is used and he has managed to get stuck somewhere. 3) Alternate movement -- In manic miner to jump and turn around at the same time requires Willy to do a standing jump. e.g. the sequence from jumping right and holding down the jump key and then trying to turn around. Normal Manic miner movement - Jump right - static vertical jump - jump left. The alternate style of movement removes the static jump. Willy will do the sequence of - jump right - jump left (no static jump) This also happens when walking and turning around. the difference between the two is one frame of movement. The alternate version enables willy to turn around faster. This change was introduced to enable faster movement response. It is subtle but if you are aware of the change it enables faster response when turning, which can be the difference between life and death. Easter egg- When the credits screen is displayed. Hold down "1" and tap enter.

All objects should be now collectable. I have moved the one in "West of Kitchen" 127 rooms now have an object to collect Only "Entrance to Hades", has no object. To edit the game and change the layout or item position, is no more difficult than any edit using the standard edit programs. ;------------------------------ When writing the game ------------------ The repeated editing eventually wore me down. On every edit it must be remembered to put the arrows last. Fine, but a quick edit and putting an extra sprite in here or there, necessitates moving the sprite order around. So easy to forget, when it was just a quick edit. For the above reason, I added a routine to sort the sprites at run time. (just for the arrows) so every room is checked for sprite order, and pesky arrows are automatically moved to the last sprite slots. The routine was meant to be removed, but it uses only 60 bytes and saved me so much time on needed re-ordering, it was left. (having checked the present data, it has little effect - no arrows collide with sprites in the rooms it has need to re-order )

I think this answers your question on my arbitrary selection of 74 arbitrary Dictionary.com subject to individual will or judgement without restriction; contingent solely upon one's discretion: Cambridge Dictionary based on chance rather than being planned or based on reason: Oxford Dictionary Based on random choice or personal whim, rather than any reason or system. Wiktionary Etymology From Middle English arbitrarie, Latin arbitrarius (

My game code checks for "0" and uses this as a signal for the completion of the game. so in my version you can only have 0 to 255 objects. with 255 being the maximum. if the code assumed that a true "0" could not happen unless it was game finished. Which is not an unreasonable assumption. This is just assuming the game has objects at the start. Otherwise we start with no objects and no purpose which is a strange starting point. This is talking about object collection, and ignoring the actual coding used in the game. (the actual game, increments from a negative value) The code for object collection could blindly decrement the object count and check for none. I check for none before collecting an object, and I again check for none after the object is collected as well. This double check is not needed. It was added so I could mess with the number of objects specified at the start of the game. This consisted of inserting a value over the actual item count (after it is calculated in the game) Thus I could collect one object and go to the bedroom to start the game finished sequence. This left the problem of the collecting of an object with the counter at zero (plenty more objects defined in the game) ----this necessitated the double check - not needed but left. --- using a value to represent the objects to collect, as opposed to the actual code in the game---- a value of 1 indicates 1 object, when an item is collected the 1 is decremented to 0 ---- game finished ----- ------ -----2 ---------- 2 objects, ----------------- ------ 2 -- --------------- --- 1 ------ ----- -----3 --------- 3 ----------, --------------------- -- 3 -- --------------- ---- 2 ---- ------- -----4 --------- 4 -------- ,---------------- ----------- ---- 4 ----- -- --------- ---- 3 ------ ----- ----- 255 ------ 255 objects, --------- ----- ----- 255 -- ------------- ----- 254 and finally a value of 0 indicates 256 objects, when one item is collected the value is decremented to 255 --- carry on So if a need arose for 256 objects I would/could change the code to cope. So it is possible to have 256 objects to collect. Space is allocated for this many in the object list.

Addendum JSW 128Vk2 is a file (game) that runs on a 48k Spectrum. ;------------------------------------------------------------------------------------------------------- It is called JSW 128 V?? simply because When I looked at the amount of editing that has/had occurred on Matthews original file. I noticed that the vast majority had stuck to the limitation of 64 rooms as designed by Matthew. Some brave soles had managed to add a hand full of rooms onto the 64 original. As far as I was aware no one had edited JSW to improve on 74 rooms. The figure 74 was an arbitrary figure set as a benchmark to beat. Having devised a method for storing the keys/objects that did not waste memory in the manor used by others, I added some rooms. Keeping to the format that Matthew had devised I managed to keep on adding rooms just by room layout compression. In the end I decided I wanted to add features so I compressed the room data/sprite data etc. I expanded to the limit that my new key layout would permit. The game as played has two versions of JET SET WILLY within its memory. But It could be a totally different plan, their is no layout restrictions. The dual game was just laziness on my part (the need to design 128 new rooms, as opposed to writing the code to add features) Since my target was 74 rooms, which was easily beaten. The room count ended up as 128, which exceeds the old count of 74 by 54 rooms. JSW 128 VK2 is just emphasising that this version has 128 rooms.

JSW 128 VK3.Tap View File Altered Reality. The basic Core of this game is Matthew Smiths original code. Which although edited still runs in the original 48K Due to extensive compression and rewrites of the original code this version. Runs at double the original speed Runs with up to 16 sprites per room Runs with up to 32 arrows per room Has diagonal sprites Has mid sprite bounce Has homing sprites Has 128 rooms and ..... I will leave the user/player to work out what has changed. Uses "G" key- "H" key- and the "K" and "L" key --------------------------------------------- Technical addendum :- files needed to construct the game NOT INCLUDED. These files are used to generate the game file main files:- mnjsw9.asm 15,264 lines in 423,867 bytes manic_edit_copy.asm 342 lines in 10,576 bytes fixed_page.asm 1,249 lines in 48,929 bytes merged.asm 40 lines in 2,096 bytes included data files when assembling x0 1132 lines in 39k ; big data statements x1 286 lines in 20k x2 509 lines in 22k x3 1103 lines in 41k included binary files when assembling edited-edit_3 6.75k control.txt 650 lines in 20k game files jsw0.tap 30.9k jsw1.tap 30.9k the files control.txt jsw0.tap and jsw1.tap are processed by saveab1.bas this is 1651 lines of qbasic in 48.07k The process's includes- read room layout, compress data -output room layout data read sprite data and read control file, change sprite data compress and output reconfigure the key data and output read the room data, discard unwanted data compress and output in essence the basic file is taking the two games and merging into a set of output files, needed to assemble A sprite editor and a room editor, along with an assortment of checking data files . All in, around 790k of associated files and data for version "K". Which is why old versions are discarded when I update the logic I am currently on version "L" - which is a big change in game play Submitter Norman Sword Submitted 07/01/2018 Category Jet Set Willy [Remakes]  

Having tested a room with a cell at head height. I find I can jump over it. So the third check is needed. What is strange is the arc of willy jumping over a nasty compared to the arc of willy passing over a wall. They are nothing alike. So I need to have a look at the ramp code or any other piece of code that might be relevant, and find out why the wall is stopping the arc in the manner it does. I am not concerned with the heel catch and land on a wall, but the point at which is says it is clear to move. The arcs are so dissimilar that I need to investigate the take off and clear portion. This is side tracking me from what I was doing...

This is similar to the ability to jump over a head height wall object. Logic say that we can clear the object and not land on it, yet land on it we do, Therefore I would think the same code layout that says you have landed on a wall, will also detect the nasty and kill you.

When the nasty(fire cell) is set to the same attribute as a wall then a number of interesting things happen (with no change in code) A nasty/wall acts as a normal wall. it will not let you pass into the space Sliding down a nasty/wall we have yet another aspect of the ramp stair code affecting the outcome. The passing through the wall by willies head will kill him. Walking on a tile that is defined wall/nasty will also kill him ;------------------------------------------- I was investigating another theme. eg. invulnerability. The code at #961e colours in willies tile as he moves around the screen. It has a check for nasties and kills willy if the area of willy is over a nasty. It also extends the checking to the area below willy for nasties and kills willy if he walks on a nasty. YET The code at #8e49 deals with the tiles beneath Willies feet and specifically checks for nasties. I see no reason for the code at #961e being made to check beneath his feet. If the attributes of willy are cell aligned then test/ colour in the four tiles. e.g check for nasty/colour in the tile If the attribute of will is not cell aligned then test/colour in the six tiles The change is to remove the check specifically for beneath his feet. It is not needed. This changes two parts of the code 95F8 LD HL,($85D3) 95FB LD DE,$001F 95FE LD C,$0F 9600 CALL $961E 9603 INC HL Move 9604 CALL $961E 9607 ADD HL,DE 9608 CALL $961E 960B INC HL 969C CALL $961E 960F LD A,($85CF) 9612 ADD A,B 9613 LD C,A 9614 ADD HL,DE 9615 CALL $961E 9618 INC HL 9619 CALL $961e 961C JR $9637 ;quick count 38 bytes and 61E LD A,($80A0) 9621 CP (HL) 9622 JR NZ,$962F 9624 LD A,C 9625 AND $0F 9627 JR Z,$962F 9629 LD A,($80A0) 962C OR $07 962E LD (HL),A 962F LD A,($80BB) 9632 CP (HL) 9633 JP Z,$90B6 9636 RET ;quick count 24 Total 62 becomes ; b=the offset for the ramp 95f8 ld c,2 ; default colouring height ld a,(#85cf) ; the y pos add a,b ; the y pos + stair offset and 14 ; check for cell aligned jr z,cell_aligned ; if cell aligned then 2 high inc c ;else it is 3 cell_aligned ld de,31 ;offset to next cell_set_loop call colour_me ;colour left cell inc hl ; move from left cell to right cell call colour_me ;colour right cell add hl,de ;down a line dec c jr nz,cell_set_loop ;loop for the height jr #9637 ;draw willy ;quick count 27 colour_me ld a,(#80bb) ; nasty cp (HL) ;is this a nasty JP Z,90B6 ;kill if so LD A,(#80A0) ;get the background tile CP (HL) ;is this background RET NZ ;used so no colouring OR #7 ; set ink white for willy LD (HL),A ;and colour in RET ;quick count 16 total 27+16=43 ;Which I hasten to add is nothing like the code I use

The original loop terminates with the ink(1) and paper(0) 37012 LD A,63 Initialise A to 63 (INK 7: PAPER 7) 37014 LD HL,22528 37017 LD DE,22529 37020 LD BC,511 37023 LD (HL),A 37024 LDIR 37026 LD BC,4 37029 DJNZ 37029 37031 DEC C 37032 JR NZ,37029 37034 DEC A 37035 JR NZ,37014 note this has filled the screen with value 1 when it finishes 37037 LD A,(33882) 37040 OR A Are we in demo mode? 37041 JP NZ,34449 If so, demo the next cavern ; a slight rearrange will fix the problem 37012 ld a,63 (or 64 if the same start colour wanted) 37014 ld hl,22528 37017 ld de,22528 ........................ 37020 ld bc,4 37023 djnz 37023 37025 dec c 37026 jr nz,37023 37028 dec a set the zero flag 37029 ld bc,511 37032 ld (hl),a 37033 ldir does not affect the zero flag ....................... 37035 jr nz,37014 ;this will finish the loop with black ink and black paper 37037 ld a,(33882) etc.

This should be under JSW not MM. But I am reluctant to start a new heading. I extended the headbutt to include the MM collapsing floors. The playability of this is restricted to 3 rooms. Hence the white blocking walls/floors added to stop wandering. Additions:- collapsing floor, in addition to headbutt, gun, 4 logo title screens, and 128 rooms. The gun is now disabled in specific rooms.... Note the ammo display disappears for the room when the gun is switched off. Added some SFX's COLLAPSE_FLOOR.TAP.tap

You are probably coming into the routine at 8ebc from one of the two jumps below, which presents a problem 8DF7 LD A,($80B2) 8DFA CP (HL) 8DFB JP Z,$8EBC >>>> 8DFE INC HL 8DFF CP (HL) 8E00 JP Z,$8EBC >>> I have a very small subroutine to handle the above type of tile check. It occurs elsewhere. The sole purpose of the routine is to leave HL alone. But a quick method of doing the same as my sub routine is original change to 8DF7 LD A,($80B2) Ld a,($80b2) 8DFA CP (HL) cp (hl) 8DFB JP Z,$8EBC >>>> jr z,$8e00 8DFC 8DFD inc hl 8DFE INC HL cp (hl) 8DFF CP (HL) dec hl 8E00 JP Z,$8EBC >>> jp z, Butt or $8ebc

Code at $8ebc change to original 8EBC call Butt LD A,($85CF) 8EBF ld a,($85CF) ADD A,$10 8EC0 8EC1 AND $F0 8EC2 ADD A $10 8EC3 LD ($85CF),A 8EC4 AND $F0 8EC5 8EC6 call $8E99 CALL $8E9C see the routine below 8EC9 LD A,$02 8ECB LD ($85D1),A 8ECE LD HL,$85D0 8ED1 RES 1,(HL) 8ED3 RET ; the call to this routine is moved to the point that "a" is saved 8E94 LD A,($85CF) 8E97 ADD A,$08 8E99 LD ($85CF),A ; moved to call here 8E9C AND $F0 ;<<<<<<<< original call point 8E9E LD L,A 8E9F XOR A 8EA0 RL L 8EA2 ADC A,$5C 8EA4 LD H,A 8EA5 LD A,($85D3) 8EA8 AND $1F 8EAA OR L 8EAB LD L,A 8EAC LD ($85D3),HL 8EAF RET ; a very vague Butt routine Butt: test if code is wanted, e.g. jump direction, headbutt flag return if not wanted else call Butt2 inc hl ;all calls here return with hl intatct Butt2 code to check where hl is pointing return is not wall tile act on the headbutt If tile graphics not cleared then return clear TILE from Master Attrib ret ;========================================================================================== Teaser: The border bits are very wasteful. The bits 0-1-2 are the border colour and the rest of the byte is wasted. So I use 1 bit for setting the Butt to on or off. That still leaves 4 bits With the room fixed to 256 bytes in size,. Conveyors and ramps use Ramp_dir 1 byte Ramp_position 2 bytes Ramp_length 1 byte Conveyor_dir 1 byte Conveyor_position 2 bytes Conveyor_length 1 byte That is eight bytes to define these two actions - It is possible on variable room size (as I now have) to delete a lot of the fixed room data. The bytes that store the conveyor and ramp direction are now also stored in the border colour byte. In fact I have deleted all the ramp data and all the conveyor data from the room data. e.g. these eight bytes are reduced to the top two bits in the border flag... - It uses a big chunk of code to restore these bytes but the code is part of a bigger piece of code. And the ramp/conveyor specific code (the bit dealing with replacing the data, deleted from the room) is no where near 100 bytes Simple maths will show you why it is worth the effort of removing unwanted data. Those 8 bytes are repeated 128 times, if using the old room storage method.( in a 128 room game) So the data contained would use 128*8 bytes of memory ( 1024 ) verses the 100 bytes of code The above is an over simplification.

Yes it is #8ebc. The code is crumbly floor in reverse. The majority of my code is concerned with checking that the wall tile can be deleted. I have now added a room specific flag. One of the unused border bits (bit 4) in my case. So rooms have head butting as an option via the border flag.(For now) This means only the one room left. And since that is in the original 60 rooms, it should be edited back to the original layout, and have the head butt option removed. Tested out the full 128 room version. I have it up and running and can now wander around 128 rooms in a 48k Spectrum Don't expect any major changes, from other versions... I am testing other things, and I have never tested this to see how far you can get. 128 room.tap

The wall tile disappearing is the result yet again of the ramp/stair code. So I used part of that code to stop downward detection and deletion of the tiles. The updated file is with the first file. E.g. Two posts ago.

Test this to see if you like the concept. Yes it my mega edited, must delete, what a mess piece of code. 120 room, bullets,and now headbutting I have stopped the ability to head butt out of the top of the room. So the top row of wall tiles can not be headbutted away. Removed the downward movement butt-ability.... That's the second file. Added a blocking ability. This stops a wall being removed if over another type of tile. That's version 3 The Top Landing is the only room that I have edited to show this. (feature is in every room, but they are not edited) IRF HEAD BUTT.tap IRF 2 HEAD BUTT.tap IRF 3 head butt.tap

Do you need a new cell type? Most of the lower, and the bottom row is impossible to head butt. If head butting from the room below they would reset anyway, after each room change. The lazy option is to just enable in certain rooms the ability to head butt a wall tile from underneath. Would have been handy in the forgotten abbey, when the wall tile was accidentally left unchanged and made the room impossible. If the only tile that can be head butted is a wall tile, and only from below, should be easy enough to design rooms to allow for that fact. A vertical wall that is inaccessible from below, still acts as a vertical wall, and is impossible to penetrate by head butting. Very easy to do,,,, I have a version running now.

A flurry of posts whilst I sat with the above text in the editor.

I have no problems with the code as listed here I changed the ld a,(hl) (twice) ; ;----------------- CODE by IRF ------------------------- ; ; ; Pre_search: LD A,(#A3FF) ;offset for first key LD L,A LD H,#A4 ;base of key list . full address now in HL filter_loop: LD A,(#8420) ;current room XOR (HL) ; xor comparison AND #3f ; does it match after removing key position page and collection flag. Bits 6 and bit 7 JR Z,match_found INC L ;move to next key JR NZ,filter_loop ;keep going through list ; ; If we get here, then we have been through all the item table entries, and there are no items (collected or uncollected) to consider in this room: ; LD A,#C9 ;disable item drawing by overwriting code with a "ret" Pre_exit: LD (#93D1),A ; disable/set the Item-drawing routine whilst Willy is in this room RET ;finished ; match_found: LD A,L ; get the position in the list LD (#93D2),A ; and store offset .value used to initiate the item-drawing loop in this room find_last_item: INC L ; wrap around is not a problem LD A,(#8420) ; the current room XOR (HL) ; comparison match AND #3F ;does it match after removing key position page and collection flag. Bits 6 and bit 7 JR Z,find_last_item ; If we get here, then HL is pointing at the first item for the next room: LD A,L ; get the position in the list LD (#9452),A ; and store this offset. value used to terminate the item-drawing loop in this room ; Now restore the first byte of the Item-drawing routine: LD A,#21 ;enable item drawing by replacing the LD HL,xxxx opcode jr Pre_exit

In the context that I have just written this and it is not tested. ; As defined in Manic Miner ; HL Address of the crumbling floor tile 35770 LD C,L 35771 LD A,H 35772 ADD A,27 35774 OR 7 35776 LD B,A 35777 DEC B 35778 LD A,(BC) 35779 INC B 35780 LD (BC),A 35781 DEC B 35782 LD A,B 35783 AND 7 35785 JR NZ,35777 35787 XOR A 35788 LD (BC),A 35789 LD A,B 35790 ADD A,7 35792 LD B,A 35793 LD A,(BC) 35794 OR A 35795 RET NZ ; ignoring the above, no help to me ; ; this code moves the tile in hl down by one line ; xor a ld d,a ld b,8 loop ld e,(hl) ;the current line or d ;the line above ld (hl),d ld d,e inc h djnz loop ; ; a=the accumalative value of the bits drawn ; or a ;if a value exists then the floor is still collapsing This permits a one pixel line to be moved down the screen

Definitely a lot easier to write code and not edit a fixed piece of code. Trying to write source code with proportionally spaced font is a challenge. The presentation leaves a lot to be desired. Then every time I do a cut and paste I am presented with a file that has most of the blank lines deleted. Hence the multitude of lines with a full stop , semi colon or some other marker. This is my attempt at trying to force inclusion of blank lines..... I do wonder also why the internet has decided that tabs need replacing with a space (or even nothing). If I press tab, as I write this the cursor will disappear and I have no more typing output, until I click with the mouse on the screen. Is the input designed to remove the archaic tabs at source, and is it trying to educate me in the new world order. NO TABS ALLOWED.

Revert (partialy) back to the original with the erroneous LD A,L . . Using original source and I am listing what is needed (up to edit 2(now edit 3.5)) to extend the keys to enable 128 rooms. This is done without wasting a full 256 bytes of data, and uses very little to accomplish this. . This method gets around the key reset at game start up (no code change). It also has no need to calculate the total keys (the value is as before) . AT NEW ROOM set up ; ;use $A3ff for the lower key OFFSET e.g this value is the numbers of keys in total. as before . ; use $A3fe for the upper key, this value holds the start of keys for rooms 64 upward . ; storage of keys is laid out as follows : ;from the value of ($a3ff) up to ($a3fe) the lower room keys ; from the value in ($a3fe) up to $ff the keys for rooms 64 to 128 . new code to implement change ld bc,($a3fe) ; ; c=upper key pointer ; Changed from what I originally wrote ; b=lower key pointer ; LD A,(ROOM_NUMBER) AND 64 ;UPPER OR LOWER SET JR z,lower_set ld b,c ;set b=upper key offset ld c,0 ;set limit=0 to stop search lower_set: ld a,b ;this is the start of search ld ($93d2),a ;set the new base for search ld a,c ld ($9452),a ; set the upper limit of search ; ;The above sets up the key collect routine ; ;------------------------------------- modification to the key collect routine address old code replace with 93D1 ld h,#A4 ld hl,#A4ff << LS of hl modified 93d2 93d3 ld a,($A3ff) 93d4 nop 93d5 nop 93d6 ld l,a nop << remove this as well (ironic that the LD a,L was ommited at the end and ommited for deletion at the beginning) . . 93E0 JR NZ,$9452 JR NZ,$944F <<< THREE BYTES EARLIER . 942E JR $9452 JR $944F << THREE BYTES EARLIER . 943E lD A,(HL) LD A,D ; 943F RLCA RLCA 9440 RLCA RLCA 9441 RLCA RLCA 9442 RLCA AND #08 9443 AND #8 9444 ADD A, #60 9445 ADD A,#60 9446 LD D,A 9447 LD D,A PUSH HL 9448 PUSH HL LD HL, #80E1 9449 LD HL,#80E1 944A 944B CALL #9699 ;call address is 2 bytes earlier 944C LD B,#8 944D 944E CALL #969B POP HL ;new branch to here 944F INC L 9450 LD A,L 9451 POP HL CP #00 ; old branch to here 9452 INC L 9453 JR NZ,93D7 JR NZ, #93D7 ;UNCHANGED 9454 9456 RET RET ;UNCHANGED ;-------------------------------- keys are stored in this fashion START OFFSET IN $A3FF OFFSET IN $A3FE THE 255TH ENTRY OFFSET 0 v v v 0,0,0,0,0,0.....,0,0,0,0,L,L,L,L,L.....,L,L,L,L,L,L,L,L,L,L,L,H,H,H,H ......,H,H,H,H,H,H,H . WHERE L IS THE DATA FOR ROOMS 0 TO 63 (THE LOW ROOMS) . AND H IS THE DATA FOR ROOM 64 TO 127 (THE HIGH ROOMS)

:this is the above post rewritten to fix the missed LD A,L ;I could not find a space for the missed instruction so a redesign . Extending the rooms up to 128. I wrote a couple of posts back of a method to extend the key tables to have over 64 rooms. I was vague because I do not use the original source layout. So I have had a look at the original source and I am listing what is needed to extend the keys to enable 128 rooms. This is done without wasting a full 256 bytes of data, and uses very little to accomplish this. This method gets around the key reset at game start up (no code change). It also has no need to calculate the total keys (the value is as before) AT NEW ROOM set up ; use $A3ff for the lower key OFFSET e.g this value is the numbers of keys in total. as before . ; use $A3fe for the upper key, this value holds the start of keys for rooms 64 upward . ; storage of keys is laid out as follows : from the value of ($a3ff) up to ($a3fe) the lower room keys ; from the value in ($a3fe) up to $ff the keys for rooms 64 to 128 . new code to implement change . ld bc,($a3fe) . ;c=upper key pointer ; Changed from what I originally wrote ; b=lower key pointer . LD A,(ROOM_NUMBER) AND 64 ;UPPER OR LOWER SET JR z,lower_set ld b,c ;set c=upper key offset ld c,0 ;set limit=0 to stop search lower_set: or $40 ld (93dc),a ; the room number searched for with bit 6 set ld a,b ;this is the start of search ld ($93d2),a ;set the new base for search ld a,c ld ($93d6),a ; set the upper limit of search . The above sets up the key collect routine ;------------------------------------- modification to the key collect routine address old code replace with 93d1 ld h,$a4 ld hl,a4ff ; this is the start offset 93d2 93d3 ld a,($a3ff) NEW LOOP HERE 93d4 ld a,l 93d5 cp $ff ;this value is the exit offset 93d6 ld l,a OLD LOOP HERE 93d7 ld c,(hl) ret z 93d8 res 7,c ld c,(hl) 93d9 res 7,c 93da ld a,($8240) 93db ld a,$ff ;this is the room number with bit 6 set 93dc 93dd or $40 nop 93de nop ; the final branch of this routine changed to . 9453 jr 93d7 jr 93d4 ;change the loop address ; ;-------------------------------- keys are stored in this fashion START OFFSET IN $A3FF OFFSET IN $A3FE THE 255TH ENTRY OFFSET 0 v v v 0,0,0,0,0,0.....,0,0,0,0,L,L,L,L,L.....,L,L,L,L,L,L,L,L,L,L,L,H,H,H,H ......,H,H,H,H,H,H,H . WHERE L IS THE DATA FOR ROOMS 0 TO 63 (THE LOW ROOMS) . AND H IS THE DATA FOR ROOM 64 TO 127 (THE HIGH ROOMS) . . . Not checked for difference in amount of changes. Removed most of the changes for the lower half of the key routine. The above will only permit 255 keys and not the full 256

Probably, I changed so much as I was writing it. I swapped a lot of the registers around and a lot of the upper/lower references. I was changing the code as I wrote it. I will re read and edit.