Norman Sword

Re clock update: ; 01234567890123456789012345678901 ; text for position *1 L8554 DEFM "Items collected 000 Time00:00:00" ; This data is directly changed by item collection and time L857F equ L8554+24 ; references to the old data, changed to reference directly the data above L857C equ L8554+16 ; as above ;L857C DEFM "000" ; This data is deleted ;L857F DEFM " 7:00:00" ; This data is deleted I have just tried the simple equate change and deleted the other clock update. I have also now added the item equate as well, and deleted the item update This works... for data on the status line L8554 I was experimenting with differing clock formats so Clock data is different and in a different position NOTE *1 . The position find is not displayed on this forums page, due to this forum using proportional fonts. The assembler uses a fixed size font.

Off hand can see no problem with that approach in JSW. In MM the score can overflow its allocated space. So needs to be separate. It also removes the annoying update flicker when a new room is entered.

re clock update I moved the print the clock status line into a subroutine. I then changed the clock up date routine to finish by calling the clock print subroutine. the original code does this the other way round. (the abort to time over needs to include the clock update) I moved the print dancing willies into a subroutine: because of the problem you have also experienced on not clearing the data I moved the room update code into another subroutine. On room update it clears the screen then draws the room and updates various other routines. e.g. The room is updated, but before returning CALL DISPLAY_LIVES ; updated because lives might be lost and the number of willies displayed will be different CALL SHOW_CLOCK ; clock must be updated it is only shown on time change CALL SHOW_ITEMS ; only updated on item collection

re conveyor:- MOVE_CONVEYOR: ;L94F9 LD A,(CONV_LEN) OR A RET Z LD B,A The test for length is the first test I do in that routine The next test I do is the bit that declares if the conveyor is animated or not. (not part of Matthew's routines) Speed slow down is accumulative. But sometimes the code can be as sloppy and slow as needed. This normally occurs when a single event has been triggered and the game can practically stop whilst the event happens. E.g. You can increase the length of item collection sound by a considerable degree. Even to the extent of being able to see the slow down on the screen. The player will not mind as this is part of his reward. On the other hand that pesky clock is printed on each game loop along with the items collected text. This type of slowdown is caused by not bothering to update on an update only basis, and because the game has to have additional code to display the text on each new room. Easier to just print on each loop. The speed increase by moving the test from the near the middle of the conveyor routine to the beginning might be around 20 to 80 t-states. (depends how much code) On the other hand going back to the clock print routine. around 150 t-states per letter . so if it prints 6 letters that's 900 t-states per game loop to print text that has not changed. I will always attempt to go for the faster or shorter routine. Normally one is the same as the other. But sometimes you need to look at why something is being done, and perhaps not rewrite it. But redesign it. Re conveyor- The code I list tends to be the easiest edit I can do that follows the original layout . so if it has all the line numbers and references to line numbers then it is a quick edit. (and probably not tested by me)

Byte saving. This is something that Matthew does as part of the code to move down the screen from raster line to raster line. ld a,l ;line 1 add a,$20 ; 2 ld l,a ; 3 and $e0 : 4 ret nz ; or jr nz (depending on version) I just wonder why the opcode -and $e0- is used on line 4. The addition on line 2 - add a,$20 - has set the carry flag for all the conditions that are wanted. The code should be. ld a,l ;line 1 add a,$20 ; 2 ld l,a ; 3 ret c ; or jr c (depending on version) This save two bytes. Since various mods have been used around this area, The exact condition Carry or no carry, will depend on what else is happening around this code area.

The reason I only rotate once is simply because I do not like the original animation. When willy or a sprite is animated on a conveyor, the speed the conveyor moves is exactly the same speed as willy moves. (or a standard horizontally moving sprite) Simple logic dictates that if the conveyor is moving in the same direction as willy and at the same speed then the conveyor is static below willies feet. It then follows that willy should not be animated. He should stay in the same frame and move graciously and serenely along the conveyor without moving a limb. The game does not provide that kind of animation, so my compromise is to move the conveyor at a slower speed to justify the animation. The speed change is also linked to the direction byte. (not listed in the code because it is not part of the original) but in my versions, the direction byte also stores animation status bits. The bits switch on/off animation. e.g. In this manner/style (done by me, in various edits) bit 5 no animation of the conveyor. Return immediately. bit 6 no lower animation of the conveyor . point high of register pair to "0" bit 7 reverse animate the conveyor (reverse animate, just to confuse) .xor bit with direction bit before testing By testing a bit in the direction byte. Either HL or DE can be set to point to the ROM. By setting "D" or "H" to 0. This allows the following code to stay the same. But the registers pointing to the ROM will stop the appropriate animation from being shown. The code as used by Matthew can easily be modified to use a consistent check on the direction byte. e.g. ignore all the other bits, which then become available to use. .

The listings I have provided are created ad hoc. ; the version I have currently looks like this. Next week it might be changed again JR Z,TOTHER EX DE,HL TOTHER LD A,(DE) :>>>>>> the opcode in question LD C,(HL) RLC A RRC C CON_DO LD (DE),A LD (HL),C INC E INC L DJNZ CON_DO RET But I will go back and change the opcode... The link back to the code, does not provide any means of editing the code.

If the code had been written as Ld a,(ix+$06) ld (hl),a inc h inc h ld (hl),a dec h ld a,(hl) and c ld (hl),$ff jp nz,#90b5 ;>>>> kill willy jp #93b3 Then it might have been a valid point on drawing the arrow Otherwise you have returned and not drawn the arrow shaft. Byte code is purely a guide. (the count is indicating a trend- nothing more)

When running JSW on an emulator, it quickly becomes evident that the emulator has problems scanning the keys. This problem manifests itself, if the cheat code has been typed in and key combinations are required to jump to rooms. This can/could be a problem caused by either the host hardware, the emulator, or both. This short program will simply display key presses as interpreted by the host machine and passed through the emulator. I find it fascinating that on one of the emulators I use ("FUSE") has so many problems. For example Press and hold "F" and "G" ., the rest of the row will now be ignored, except "ENTER". e.g. "A", "S", "D", "H", "J", "K", "L" will not register A newer version is listed a few posts later. (the update is only a graphic update) key_test.tap

Expanding on the theme ; The value in (ix+$05) is only used locally X9278 ;>>9278 LD (IX+$05),$00 LD BC,$700 ;-1 B=7 C=0 X927C LD A,(HL) ;>>927D AND $07 ;>>927F CP $07 INC A ;-2 AND B ;-3 X9281 JR NZ,L_9286 ;>>9283 DEC (IX+$05) DEC C ;-5 L_9286 LD A,(HL) ;>>9287 OR $07 OR B ;-6 X9289 LD (HL),A X928A INC DE X928B LD A,(DE) X928C LD H,A X928D DEC H X928E LD A,(IX+$06) LD B,A ;-5 X9291 LD (HL),A X9292 INC H X9293 LD A,(HL) ;>>9294 AND (IX+$05) AND C ;-7 X9297 JP NZ,$90B7 ;>>>>> kill Willy X929A LD (HL),$FF X929C INC H ;>>X929D LD A,(IX+$06) ;>>X92A0 LD (HL),A LD (HL),B ;-9 X92A1 JP $93B3

Original posted elsewhere but an hour after that post (several days ago) I revisited the data. With the intention of getting rid of half of it... Numbers are extrapolated from the data here. Original rope table consisted of 86 bytes of data, 42 zero's, 86 bytes of data and another 42 zero's The original modification was to shorten it to 86 bytes of data followed by 170 zero's This final mod shortens it yet again to 43 bytes of data followed by 213 zero's Of course the 213 zero's are now free to use, This code/data mod will free 86+43=(129) bytes. But will also make the space continuous. ; ; ok the full compression from the original 256 byte data table down to 43 bytes a saving of 211 ROPE_TABLE x8300 DEFB (6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0 x8304 DEFB (6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0 x8308 DEFB (6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0 x830C DEFB (6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0,(6*2+0)*16+6*2+0 x8310 DEFB (6*2+1)*16+6*2+1,(6*2+1)*16+6*2+1,(6*2+1)*16+6*2+1,(6*2+1)*16+6*2+1 x8314 DEFB (6*2+1)*16+6*2+1,(6*2+1)*16+6*2+1,(6*2+2)*16+6*2+2,(6*2+2)*16+6*2+2 x8318 DEFB (4*2+2)*16+6*2+2,(6*2+2)*16+4*2+2,(6*2+2)*16+4*2+2,(6*2+2)*16+4*2+2 x831C DEFB (6*2+2)*16+4*2+2,(4*2+2)*16+4*2+2,(6*2+2)*16+4*2+2,(4*2+2)*16+4*2+2 x8320 DEFB (4*2+2)*16+4*2+2,(4*2+1)*16+4*2+2,(4*2+2)*16+4*2+1,(4*2+1)*16+4*2+2 x8324 DEFB (4*2+1)*16+4*2+1,(4*2+2)*16+4*2+2,(4*2+3)*16+4*2+2,(4*2+3)*16+4*2+2 x8328 DEFB (4*2+3)*16+4*2+3,(4*2+3)*16+4*2+3,(4*2+3)*16+4*2+3 L930E: LD A,(IX+rope5) ;$05;rope pixel LD E,A ;TEMP SAVE of rope5 OR (HL) LD (HL),A ;pixel drawn LD A,(IX+rope9) ;$09 ;Point HL at the relevant entry in the rope animation table at 8300 LD D,A ;TEMP SAVE of rope9 ld c,(ix+rope1) add a,c ;$01 AND $7f ;$7f=%01111111=127 sra a ;get rid of bit 0 but set/reset the carry LD L,A LD H,High ROPE_TABLE ; $83 ld a,(hl) jr nc,high_set rrca rrca rrca rrca high_set: ld b,a and 1100b rrca add a,iyl ld iyl,a ld a,b and 3 ; update the x-position (if need and the draw bit) JR Z,L9350 LD B,A ; BIT 7,C ;$01;Is the rope currently right of centre? LD A,E JR Z,rope_right ; rope_left: RLCa ;$05;Rotate the drawing byte left once JR nc,hop1 ;complete rotation ? DEC (IX+rope3) ;$03;adjust x-coordinate hop1: DJNZ rope_left ; JR SAVE_A rope_right: RRCa JR nC,hop2 ;complete rotation INC (IX+rope3) ;$03;adjust the x-coordinate hop2: DJNZ rope_right SAVE_A: LD (IX+rope5),A L9350: LD A,D :the segment counter CP (IX+rope4) ;$04;all segments drawn yet? JR Z,L935E ;Jump if so INC (IX+rope9) ;$09; adjust segment counter JP DRAW_ROPE ;L92B6 ;loop for next segment of rope ; the above just about fits into the available space

On the theme of byte saving ; this code has been rewritten to save around 41 bytes L8CE8 DJNZ L8CE8 ;Delay for about a millisecond LD A,C LD HL,ATT6+10 ;$58CA CALL TWINKLE ;Change the INK colour of "Game" at (6,10/11/12/13) LD L,LOW ATT6+18 ;$58D2 LOW=$D2 CALL TWINKLE ;Change the INK colour of "Over" at (6,18/19/20/21) DEC C ; JR NZ,L8CE8 ; DEC D ; JR NZ,L8CE8 ; JP L87CA TWINKLE: LD B,4 TWNK: AND 7 OR $40 LD (HL),A INC HL INC A DJNZ TWNK RET FREE SPACE UP TO $8D33 AROUND $29=41(DECIMAL)

You probably noticed that the code listed, used labels for the offsets into the data. e.g ld a,(ix+rope5) This usage of labels is something I have tended to do more and more over the years. It stems from needing to do rapid changes of data caused by changes in how I write something. By using labels it becomes an easy global change (in an assembler) to change an offset via the label. In the case of JSW the rope data suffers from an overflow of data, and the solution (in my case) was to reassign the offsets and to move the allocation of one bit from bit 0 to bit 7. The changes needed in the code was minimal. It also makes it obvious that it is rope data that is being used.

; 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