Norman Sword

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.

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: ld a,b ;this is the start of search ld ($93d4),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 93d3 ld a,($A3ff) ld a,0 <<value modified . nop . 93E0 JR NZ,$9452 JR NZ,$9450 <<< TWO BYTES EARLIER . 942E JR $9452 JR $9450 << TWO BYTES EARLIER . 944c ld b,8 call $9699 ;two bytes earlier 944e call $969b 944f pop hl 9450 inc l 9451 POP HL CP 00 <<value modified 9452 INC L 9453 JR NZ,$93D7 JR NZ,$93D7 << 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)

Decided to test concept. One hour later I had an up and running 120 room version. Both completely independent and both can be remapped. No enthusiasm for doing so. Both sets or rooms are free to cross to the other at any point. This is a full 120 room version. I can not think of any layout restrictions.

Ramblings:- concerning the last part demo program. . I got bored with the standard 64 room limit, plus the fixed memory restrictions, so decided to change how the rooms where stored. . Change 1) Leave the room data alone (e.g. the tile definitions, sprite definitions, room names) but split the room shapes off from this data and compress. I ended up with 60 room data pages and 2 sets of 60 room shapes. This edit has for every room shape, a shadow room shape. It was in the file before last, that I uploaded. Which was why some room shapes changed. . Change 2) I decided to then compress the room data. Not an extensive compression, but enough data was removed so in this version I had 2 sets of room data, and 2 sets of room shapes. This was 60 rooms, and 60 rooms shadowed. The change from one set of rooms to the other permitted new sprite definitions and new tile definitions and new room names. It was effectively a 120 room game with no attempt at changing the alternate room layout. The two sets of rooms still contained a common overall layout and a common set of room keys. . Sidetrack Norman sword Key storage . It is easy to compress the room data, and therefore easy to increase the room count upwards. The simplest method is to ditch the constrictive usage of page boundary data and move to indexed data with variable size. This permits every room to be whatever size it requires. The room exits use a full byte so it is easy to have room numbers greater than sixty three. We can have room numbers up to two hundred and fifty five. But we do not have the memory to store that many, so a realistic figure of one hundred and twenty seven is possible. . The rooms can easily be drawn and stored. The biggest challenge lies in the storage of the keys. Matthew implemented a six bit storage limit into the room numbers stored in the two pages of stored data for the keys. Some attempts have extended this table by adding a new page of data. (256 bytes) When only 32 bytes where needed. What was missed was the simplicity of just using a one bit variable that indicates upper or lower sets. Rooms naught to sixty three are stored in the key list exactly as of present, occupying the upper half of the key page. Any room that is over sixty three, uses the lower half of the table. Its value "AND'ed" with sixty 63 and uses the same data space, but is confined to the lower half. . I use the term "the lower half" when in reality I am storing one set of key data from offset 255 downwards, and the other set of data from offset 0 and storing upwards. As long as the two sets of data do not overlap. Then the two sets of data can happily exists in the same data space. . The changes needed to some of the other routines are minimal. (broad outlook on changes, no detail) :- The reset the keys to uncollected, changed to reset the full page, as opposed to just the top part. :- the number of items uncollected is the top page value - the bottom page value :- The key collection routine can be modified to search upwards or downwards depending on the value of the room number. e.g the key flag :- The drawing of new rooms from the value obtained from room data, sets which set of keys needs to be searched. Rooms 0-63 search upper key list, rooms 64 to 127 search lower key list. e.g set a one bit key flag. Which is used by the key collect and draw routine I do not check the key list in a similar fashion to the original. On room expansion I generate a new key list for the current room. This is the key list used to check for collected items and also to animate the keys. The method I use to generate this new key list is similar to the method outlined above. For the lower rooms I search the top of the key list, for rooms above 64 I search the bottom of the list. . This limits the total key count to 256, but other versions have this restriction. It took me around two hours to implement this data change and also implement the usage of both sets of data. . Having implemented the above change for the keys with each block of 60 rooms having its own tile/sprite definitions/room name, its own room shape and now its own key storage area. It is now possible to implement the next change. (not implemented). . Change 3) The logic added for the shadow routines can be removed. One set of rooms no longer needs to have any reference to the other set of rooms. Both sets of rooms are now free in every aspect. And we can map out a 128 room game I have about 99.9% of the above written, but at present no urge to implement change 3. (which is mainly deleting routines) At present I am editing the version with 120 rooms, but each set is an overlay of the other set. This restricts room layout to enable free switching between the two sets. The designing and editing is still done by using the standard 64 room version. What my program does is incorporate the data from two games, and merge them together. . BASIC As I said above I compressed the rooms because I was reaching the fixed limit of memory that I had available. I was experiencing graphics being overwritten. So I wrote a routine in BASIC to compress the room graphics and output the data in assembler form. I would have liked to say this routine was simple to write. And perhaps it was, the BASIC is a few lines short of 1000 lines and took a week to write. (not in one go) . The BASIC file was edited along these lines . The basic takes a game file and from it extracts the game data, in the Format that is similar to the Matthew room data layout below. This was changed to extract the room data (the shape of the room) into another file after doing a RUN LINE COMPRESSION on the file. This was then changed to have macro's that allowed both versions to be used by the assembler in one file. This was again changed to enable vertical and horizontal RUN LINE COMPRESSION for the assembler file. Another change enabled the stairs and conveyors to be incorporated into the VERTICAL RUN LINE COMPRESSION. Yet another change saw the output of the keys data in a separate file Yet another change saw the program output the data from two files at the same time. The original data and the shadow data Another change and the file was compressing and deleting the unwanted room graphics/exits/room name/unused sprites etc. Then the final change was the merging of both sets of key data into a single key data file. . I am always amazed at how fast modern PC's can do this amount of processing and output. The time between the start and finish of the extraction process is measured in fractions of one second. Yet the output is measured in around 110k of source code data . Whilst I was changing the data, I needed to change lots of parts of the assembler source file in parallel. And I was amazed when I wrote the final leap into having all of the data compressed that it worked first time. . . . example of the size of the data for the room shape. . As stored by Matthew for The Off Licence ; reduced from the uncompressed 512 bytes used in Manic Miner ; this is two bit run line coding ;128 bytes,#80 49152 DEFB 0,0,0,0,0,0,0,0 ;Room shape 49160 DEFB 0,0,0,0,0,0,0,0 49168 DEFB 0,0,0,0,0,0,0,0 49176 DEFB 0,0,0,170,170,170,170,170 49184 DEFB 0,0,0,128,0,0,0,2 49192 DEFB 0,0,0,128,0,0,0,2 49200 DEFB 0,0,0,140,0,0,0,2 49208 DEFB 0,0,0,128,0,0,0,2 49216 DEFB 0,0,0,128,0,0,0,2 49224 DEFB 0,0,0,128,0,0,0,2 49232 DEFB 0,0,0,128,0,0,0,2 49240 DEFB 0,0,0,170,0,0,2,170 49248 DEFB 0,0,0,0,0,0,0,2 49256 DEFB 0,0,0,0,0,0,0,2 49264 DEFB 0,0,0,0,0,0,0,2 49272 DEFB 85,85,85,85,85,85,85,85 . What it is possible to compress to. (variable size) . Data as stored by me for the same room. The Off Licence ;this is vertical and horizontal run line coding ;26 bytes, #1a 102 bytes smaller db #25,#DF,#2D,#5F,#2D,#4C,#97,#33 db #67,#D7,#1E,#3F,#2B,#93,#3F,#0D db #C0,#3F,#3F,#1C,#83,#0A,#84,#3F db #1F,#5F ; Matthews storage of the basic room data ; 128 bytes #80 49280 DEFM " The Off Licence " ;Room name 49312 DEFB 0,0,0,0,0,0,0,0,0 ;Background 49321 DEFB 68,255,222,108,136,18,64,4,0 ;Floor 49330 DEFB 22,34,255,136,255,34,255,136,255 ;Wall 49339 DEFB 5,248,136,158,189,189,158,136,248 ;Nasty 49348 DEFB 7,3,0,12,0,48,0,192,0 ;Ramp 49357 DEFB 67,51,255,51,0,255,0,170,0 ;Conveyor 49366 DEFB 0 ;Direction 49367 DEFW 24371 ;pos 49369 DEFB 12 ;Length 49370 DEFB 1 ;Direction 49371 DEFW 24535 ;pos 49373 DEFB 4 ;Length 49374 DEFB 5 ;Border 49375 DEFB 0,160 ;Unused 49377 DEFB 24,24,60,126,98,98,98,126 ;Item 49385 DEFB 1 ;left 49386 DEFB 0 ;right 49387 DEFB 0 ;above 49388 DEFB 0 ;below 49389 DEFB 0,0,0 ;unused 49392 DEFB 10,138 ;guard 1 49394 DEFB 12,29 ;guard 2 49396 DEFB 44,39 ;guard 3 49398 DEFB 255,0 ;Terminator 49400 DEFB 0,0 49402 DEFB 0,0 49404 DEFB 0,0 49406 DEFB 0,0 . all that is needed. variable size ;82 bytes (this might be an edited version of the above) ;46 bytes smaller . db #09,"The Off Licenc",+"e"+#80 db #00 ; back db #44,#FF,#DE,#6C,#88,#12,#40,#04,#00 ; floor db #16,#22,#FF,#88,#FF,#22,#FF,#88,#FF ; wall db #05,#F8,#88,#9E,#BD,#BD,#9E,#88,#F8 ; nasty db #07,#03,#00,#0C,#00,#30,#00,#C0,#00 ; ramp db #43,#33,#FF,#33,#00,#FF,#00,#AA,#00 ; convey db #45,#18,#18,#3C,#7E,#62,#62,#62,#7E ; (conv/ramp/border)/item db #01,#00,#00,#00; Paths db #0A,#8A; guard 1 db #0C,#1D; guard 2 db #2C,#27; guard 3 db #FF; Terminator Matthew per room 256 bytes ; this room compressed 26+82= 108 bytes + 4 for pointers ; 144 bytes smaller query on terminology. The middle sprite in Mondrain, is used extensively in conjunction with the Monks. The shape and format of the sprite is typical of medieval parchment scrolls.

Re Gaurdians aura This version has a playable "Swimming pool" This is another edit of my "delete me now" file. Only Rooms of interest (reference by the normal room names) Swimming Pool Guardian aura/colouring The Chapel homing sprite The Bathroom arrow volley A lot of other rooms have had minor changes This is a bigger edit of the last file I uploaded. This might look like a normal JSW file but it contains 120 rooms, with each of the normal 60 rooms, having a fully definable clone room. This version could be remapped to be a playable 120+ room game. The game is set to swap between each version of rooms. JSW ALTERED 1.tap

I have added a note to the top of what I wrote, concerning the SET 7,L opcode.

Rough figures... ;**************************************** ADDENDUM **************************************** I originally used the terminology of REM'd out for the SET 7,L in the code. This is only possible in an assembly listing and is not possible with situations such as this. The nearest equivalent would be inserting NOP,NOP. However this makes a slight change in how the text is handled. The stream of text going through the print routine could have any value, and might be over 127 With that in mind, it would make a far better change to use RES 7,L as the alternative to SET 7,L ******************************************* . .From listing of JET SET WILLY Numbers in HEX . 9691 LD H,$07 9693 LD L,A 9694 SET 7,L ;could delete NOP'd >>> use RES 7,L 9696 ADD HL,HL ;*2 9697 ADD HL,HL ;*4 9698 ADD HL,HL ;*8 9699 LD B,$08 . Changing the opcode at #9691-- the LD H,07 setting H to = 0 1 2 3 4 5 6 7 etc muliplied *8 0000/0800/1000/1800/2000/2800/3000/3800 up to f800 setting bit 7 of L and multiplying by 8 gives an offset of 400h . so by combining we can have offsets of 0000/0400/0800/0c00/1000/1400 up to Fc00 . by setting either we have #20 addresses we can use. anything below #8000 is taken by buffers/screen/rom Giving usable addresses such as (in hex) h= 10 11 12 13 14 15 16 17 8000,8800,9000,9800,a000,a800,b000,b800 with RES 7,L REM'ed out 8400,8c00,9400,9c00,a400,ac00,b400,bc00 with SET 7,L left in h= 18 19 1a 1b 1c 1d 1e 1f c000,c800,d000,d800,e000,e800,f000,f800 with RES 7,L REM'ed out c400,cc00,d400,dc00,e400,ec00,f400,fc00 with SET 7,L left in ;---------------------------------------------------------------------------------------------------------------------------- The font needs to be stored at these addresses (data from above adjusted for font position) e.g.+#100 h= 10 11 12 13 14 15 16 17 8100,8900,9100,9900,a100,a900,b100,b900 with RES 7,L REM'ed out 8500,8d00,9500,9d00,a500,ad00,b500,bd00 with SET 7,L left in h= 18 19 1a 1b 1c 1d 1e 1f c100,c900,d100,d900,e100,e900,f100,f900 with RES 7,L REM'ed out c500,cd00,d500,dd00,e500,ed00,f500,fd00 with SET 7,L left in ;----------------------------------------------------------------------------------------------------------------------------- Plenty of memory addresses to play with (back to decimal) I would assume you would use a short font, e.g. just ASCII 32 up to ASCII 127 or less I see no point in ASCII above 128 or below 32 The stored font then needs to sit 32*8 above the base page (listed above) e.g. +256 with a font size less than 800 bytes Stored font is (128-32)*8=768