Norman Sword

; update the clock originally at $8a52 to $8aaa This routine is approx 74 bytes, 14 (approx) bytes smaller ld de,mess_time+4 ld hl,clock_master+4 update_clock: ld a,(de) cp ":" jr z,clock_colon: cp " " jr nz,valid_dig ld a,"0" valid_dig: inc a ld (de),a dec a cp (hl) ; are we at max yet jr nz,clock_out ld a,"0" ld (de),a clock_colon: dec hl dec de jr update_clock ; clock_master: DB "29:59" am_2_pm equ "a" xor "p" ; ;do we need to adjust output ; check 1 is from 11:59 am to 12:00pm ;- toggle am/pm ; check 2 is from 12:59 am to 13:00 ; reset to 1:00 clock_out: ex de,hl ld a,l ; which char was last updated cp low +(mess_time+1) jr nz,clock_updated ;we have just updated unit part of the hour (10:00 change updates the tens part) dec hl ld a,"1" ; is the hour 1x:00 ? cp (hl) ; it all happens on either 12:00 or 13:00, so is the "1" present jr nz,clock_updated ; hour can be 11:00, 12:00 or even 13:00 - see comment above on 10:00 inc hl inc a ; change to "2" ; check for 12:00 cp (hl) JR Z,MIDNIGHT ; just gone 12:00 INC A ; change to "3" ;check for 13:00 CP (HL) JR NZ,clock_updated ; clock now says 13:00, so reset to 1:00 ld hl,$3120 ; " 1" NOTE LS MS switch ld (mess_time),hl jr clock_updated ; clock is on midnight/noon change am to pm and pm to am MIDNIGHT: ld hl,mess_time+5 ld a,(hl) xor am_2_pm ;toggle the am/pm ld (hl),a ; if this extra check to abort the game at midnight was not done, we could carry on. The clock has been correctly changed to am cp "a" ; the midnight change jp z,game_over_time ; >>> this can go to the boot routine - game over etc. clock_updated: Routine is smaller and changes from am to pm/ and pm to am- at 12:00am and 12:00pm routine aborts game at midnight possible to chop bytes from the code- clarity suffers greatly for such small changes

;8D33: Draw the current room to the screen buffer at 7000 ; this $8d33 to $8d9a (50 bytes approx shorter) ; original $8d33 to $8dd3 ; No attribute errors- draws exactly what is specified. ; the tile printed is the tile specified (in every case) ; routine executes a lot faster draw_room: ;L8D33 ; start by defining each of the six types into the master attribute area ;e.g. place 0=backround 1=floor,2=wall 3=nasty,4=ramp 5=conveyor into the master attribute area ;first part, expand the lower compacted data for the four types LD HL,room_layout ;Point HL at the first room layout byte at L8000 LD de,att_master ;Point IX DE at the first byte of the attribute buffer at 5E00 mosaic: ld a,(hl) ld b,4 tile_it: rlca rlca ld c,a and 3 ld (de),a ld a,c inc de djnz tile_it inc l bit 7,l jr z,mosaic ;Next consider the conveyor tiles (if any). ;draw_conveyor LD A,(conv_len) ; 8D90 ;L80D9 Pick up the length of the conveyor from L80D9 OR A ; 8D93 ; Is there a conveyor in the room? JR Z,draw_ramp ; 8D94 ;L8DA1 Jump if not LD HL,(conv_add) ; 8D96 ;L80D7 Pick up the address of the conveyor's location in the attribute buffer at 5E00 from L80D7 LD B,A ; 8D99 ; B will count the conveyor tiles L8D9D: LD (HL),5 ;L8D9D ; Copy the attribute bytes for the conveyor tiles into the buffer at 5E00 INC HL ; 8D9E ; DJNZ L8D9D ; 8D9F ; ;And finally consider the ramp tiles (if any). draw_ramp: LD A,(ramp_len) ;L8DA1 ;L80DD Pick up the length of the ramp from L80DD OR A ; 8DA4 ; Is there a ramp in the room? jr Z,tile_grout ld b,a LD HL,(ramp_add) ; 8DA6 ;L80DB Pick up the address of the ramp's location in the attribute buffer at 5E00 from L80DB LD A,(ramp_dir) ; 8DA9 ;L80DA) Pick up the ramp direction from L80DA; A=0 (ramp goes up to the left) or 1 (ramp goes up to the right) and 1 ; 0 or 1 rlca ; 0 or 2 sub $21 ; -$21 or -$1f ld e,a LD D,$FF ; 8DB2 ; L8DBB: LD (HL),4 ;L8DBB ; Copy the attribute bytes for the ramp tiles into the buffer at 5E00 ADD HL,DE ; 8DBC ; DJNZ L8DBB ; 8DBD ; ; now draw the tiles ; take the six defined types and expand into the tile- 100% garanteed the correct definition tile_grout: LD IX,att_master ; 8D36 ;$5E00 Point IX at the first byte of the attribute buffer at 5E00 ld de,char_master tile_do: ld a,(ix) ld c,a add a,a add a,a add a,a add a,c ;*9 add a,low back_tile ld l,a ld h,high back_tile ld a,(hl) ;tile colour ld (ix),a inc ix ;Crosses page boundary at mid point inc l ld c,d call printing_char ;copies data from (hl) to (de):- SCREEN MAPPED see source code for address ld a,d ld d,c inc e jr nz,tile_do ;at this point we cross the page boundary ld d,a cp high +(char_master+$1000) jr nz,tile_do ret saving around 50 bytes - see source listing for references

Cheat code entry:- keyport equ $FE ; this will sit from $8b70 to $8bCd 51(approx) bytes shorter ; original $8b70 to $8c01 ; Here we check the teleport keys. ;CODE FROM $8B70 re arranged and re written teleport_check: ld hl,cheat ld a,(hl) cp 10 jr nz,check_for_cheat ld a,$ef in a,(keyport) BIT 1,A JR NZ,LA_HOP AND $10 XOR $10 RLCA LD B,A ld a,$f7 in a,(keyport) CPL AND $1F OR B LD (current_room),A JP enter_new_room check_for_cheat: LD A,(current_room) CP $1C JR NZ,LA_HOP LD A,(willy_y) sub $d0 JR NZ,LA_HOP ld b,a LD a,(HL) add a,a EX DE,HL ld c,a LD HL,cheat_table add hl,bc ld bc,$21f ld a,$fb cheat_read: in a,(keyport) and c CP (HL) JR NZ,check_cheat2 INC HL ld a,$df djnz cheat_read EX DE,HL INC (HL) LA_HOP: JP main_loop check_cheat2: cp c JR Z,LA_HOP DEC HL DEC HL CP (HL) JR Z,LA_HOP EX DE,HL LD (HL),0 JR LA_HOP - saving around 51 bytes- see source code listing for the references

In response to post #11, how to save a byte. I did wonder why the check was done in such a manner. And went back to the original listed source code. This was an edit of the original source code, and A Mr Matthew Smith chose that method originally, and I just left it. If I was to go through all this code, I have already thought of some areas of code that could be changed. Like a dog chasing its tail, each look draws attention to something else and each change draws attention to something else. Next the clock part 5) Typo manor instead of manner.... changed

Having spent longer writing about what I did than I took to write the code. I will add that this is not how I normally draw the logo triangle. I still prefer the code I created that allows me to scale the logo to any size I need. That code is nothing like the code above.

part 4) ORG $8000 ; fixed screen references CHAR0 EQU $4000 CHAR1 EQU $4020 CHAR2 EQU $4040 CHAR3 EQU $4060 CHAR4 EQU $4080 CHAR5 EQU $40A0 CHAR6 EQU $40C0 CHAR7 EQU $40E0 CHAR8 EQU $4800 CHAR9 EQU $4820 CHAR10 EQU $4840 CHAR11 EQU $4860 CHAR12 EQU $4880 CHAR13 EQU $48A0 CHAR14 EQU $48C0 CHAR15 EQU $48E0 CHAR16 EQU $5000 CHAR17 EQU $5020 CHAR18 EQU $5040 CHAR19 EQU $5060 CHAR20 EQU $5080 CHAR21 EQU $50A0 CHAR22 EQU $50C0 CHAR23 EQU $50E0 ATT0 equ $5800 ATT1 equ $5820 ATT2 equ $5840 ATT3 equ $5860 ATT4 equ $5880 ATT5 equ $58a0 ATT6 equ $58c0 ATT7 equ $58e0 ATT8 equ $5900 ATT9 equ $5920 ATT10 equ $5940 ATT11 equ $5960 ATT12 equ $5980 ATT13 equ $59a0 ATT14 equ $59c0 ATT15 equ $59e0 ATT16 equ $5a00 ATT17 equ $5a20 ATT18 equ $5a40 ATT19 equ $5a60 ATT20 equ $5a70 ATT21 equ $5aa0 ATT22 equ $5ac0 ATT23 equ $5ae0 ;fixed hardware INKS BLACK EQU 0 BLUE EQU 1 RED EQU 2 MAGENTA EQU 3 GREEN EQU 4 CYAN EQU 5 YELLOW EQU 6 WHITE EQU 7 ;hardware colour control BRIGHT EQU 64 FLASH EQU 128 ;================================================= start: call draw_bottom_att call draw_logo hang: jr hang ;======================================================================== draw_bottom_att: ld de,ATT16 ld ix,bottom_att ld hl,bottom_translate jp expand ;======================================================================= ; this draws the attributes for the logo ; ; Slight change in data that is needed for the expansion of the ATT data ; ; If the ink flashes or the ink and paper are the same colour then no graphic overlay ; ; graphic "\" := no bright then set as a "\" graphic ; ; graphic "/" := bright then set as "/" graphic and delete the bright ; draw_logo: ld de,ATT0 ld ix,new_logo_dat ld hl,new_logo_translate ld a,$07 ld (S_M_C_double),a ;an rlca call expand xor a ;the nop opcode ld (S_M_C_double),a ;---------------------------------------------- ; now draw the text on top of the logo ld hl,ATT0 ld de,logo_overlay ld c,FLASH+RED+8*YELLOW ; this can be changed to any flashing colour combination, with differing ink colours text ld a,(de) cp 255 jr z,graphic ld b,8 ;width of data byte text1: rlca ;bit out jr nc,clear ld (hl),c clear: inc hl djnz text1 inc de jr text graphic: ;--------------------------------------- logo_graphics: ; this part adds the graphics LD DE,ATT0 ; 8841 ;$5800 logo_draw: LD A,(DE) ;L8844 ; if ink=paper then ignore or if the flash bit is set then ignore ;$00,$09,$2d,$24 skip ink=paper ; d3 skip flashing tile bit 7,a jr nz,logo_skip ;flashing is the text overlay ld c,a rrca rrca rrca ; rotate paper bit down to ink bits position xor c and 7 jr z,logo_skip ; these are the solid squares ld a,c ; ; NEXT GROUP if bright one way else other ; NOTE the odd value $2c which was changed to $25, this has had its source data changed to $25. ;The other $25's,'s now have bright added ;"\" $08,$29,$2c,$05 ;"/" the rest all have bright now set ld hl,triangle_udg ; set graphics to use bit 6,a ; the bright jr z,logo1_graphic ld hl,triangle_udg+16 and 10111111b ; remove the bright ld (de),a logo1_graphic: ld a,e ; Offset by eight bytes if the position on screen is odd rlca rlca rlca and 8 ; Extract the offset call index1 ; add a to hl returns a=(a+hl) ;ignore the return "a" ld c,d ; save the position HIGH ; Bit 0 in 'd' indicates top or bottom half of screen BIT 0,D ; 8880 ; Set the zero flag if we're still in the top third of the attribute file LD D,high CHAR0 ; 8882 ;$40 Point DE at the top third of the display file JR Z,L8888 ; 8884 ; Jump if we're still in the top third of the attribute file LD D,high CHAR8 ; 8886 ;$48 Point DE at the middle third of the display file L8888: CALL printing_char ; ; Draw a triangle UDG on the screen ld d,c ; ; restore position HIGH logo_skip: ;move to next cell, and check if at the end of the area we are changing INC DE ;L888E ; Point DE at the next byte in the attribute file LD A,D ; 888F ; Have we finished scanning the top two-thirds of the attribute file yet? CP high +(ATT16) ; 8890 ;$5A Jr NZ,logo_draw ; 8892 ;L8844 If not, jump back to examine the next byte ret ;======================================================================== ; sub routine to expand data expand: ld (S_M_C_translate),hl draw_logo_loop: ld a,(ix) inc ix cp 255 ret z S_M_C_translate: equ $+1 ld hl,$-$ call indexer draw_in ld (de),a inc de djnz draw_in jr draw_logo_loop ;======================================================================= ; expand subroutine - find run length and data to write indexer: ld c,a and $f0 rrca rrca rrca rrca inc a ;next opcode changed for double run length S_M_C_double: equ $ nop ;opcode 07 for rlca ld b,a ld a,c and 15 ; - index into hl via "a" and return (hl+"a") in "a" ; general subroutine index1: add a,l ld l,a adc a,h sub l ld h,a ld a,(hl) ret ;=============================== all the logo data ======================= new_logo_translate: ; 0 1 2 3 4 5 6 7 8 9 A B C D DB 0,$68,$05,$2D,$65,$24,$04,$4C,$09,$08,$29,$25,$2C,$44 new_logo_dat: DB $F0 DB $F0 DB $80, $01, $02 DB $c0, $01,$03,$04 DB $b0, $01,$03,$04,$05 DB $a0, $01, $03, $04, $15 DB $90, $01,$03,$04,$05,$07,$05 DB $80, $01,$03,$04,$05,$0d,$08,$05 DB $80, $0a,$03,$0b,$0D,$00,$08,$05 DB $80, $08,$0A,$03,$02,$00,$08,$05 DB $80, $09,$08,$0A,$03,$02,$08,$05 DB $90, $09,$08,$0A,$03,$08,$05 DB $a0, $09,$08,$0A,$08,$05 DB $b0, $09,$08,$08,$05 DB $c0, $09,$08,$05 DB $d0, $09,$0d,$40 DB $Ff ;teminator logo_overlay db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00100010b,11111000b,10001111b,00011110b db 00100010b,10001001b,01001000b,10100000b db 00111110b,11100010b,00101000b,10011100b db 00100010b,10001011b,11101000b,10000010b db 00100010b,11111010b,00101111b,00111100b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db $ff ; manual inspection for value ;======================================================================= bottom_translate: ; 0 1 2 3 4 5 6 7 8 9 a b c d e f db 0,$01,$02,$03,$04,$05,$06,$07,$46,$45,$41,$43,$44 bottom_att db $f8,$f8 db $f0,$f0 db $f0,$f0 db $01,$02,$03,$04,$05,$06,$97,$97,$06,$05,$04,$03,$02,$01 db $f0,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $f0,$f0 db $ff ;------------------------------------------------------------------------ ; these bits of data and code are needed to assemble ; the printing_char routine is part of the games normal print routine. ;8431 Triangle UDGs triangle_udg: ;'\' DEFB $C0,$F0,$FC,$FF,$FF,$FF,$FF,$FF ;L8431 DEFB $00,$00,$00,$00,$C0,$F0,$FC,$FF ; 8439 ;'/' DEFB $FF,$FF,$FF,$FF,$FC,$F0,$C0,$00 ; 8441 DEFB $FC,$F0,$C0,$00,$00,$00,$00,$00 ; 8449 This part is part of the games print text. printing_char: LD B,$08 ; 9699 ; There are eight pixel rows in a character bitmap ;This entry point is used by the routine at L87CA to draw a triangle UDG on the title screen, and by the routine at L93D1 ; to draw an item in the current room. print_char: ;L969b LD A,(HL) ;L969B ; Copy the character bitmap (or triangle UDG, or item graphic) to the screen (or screen buffer) LD (DE),A ; 969C ; INC HL ; 969D ; INC D ; 969E ; DJNZ print_char ; 969F ;L969b RET ; 96A1 ; end start ; everything from above assembles into $1AB of code and data. Just the original data was $300 ** NOTE ** proportional spaced font has destroyed the layout of this data and code. I have slightly redone the layout.

Part 2a: The original logo draw and expansion does a lot of checking for the various colours. The result of all these checks is the decision on how any graphic is finally drawn to the screen. There are in the region of 13 differing coloured blocks, and the code decides what it is going to draw based on the colour of the block. The blocks defined seem to be laid out in no order, and the extraction of the blocks to either draw a graphic one way or draw a graphic the other seems to be haphazard. Then we have the problem that one of the colour blocks is changed in colour as it is looked at. Looking at the part that draws the logo from the attributes we can see the various checks being made at the start of the routine. We need a better look at these checks rather than just using checks for specific numbers. The first set of checks are actually looking at two things. OR A JR Z,logo_skip CP $D3 JR Z,logo_skip CP $09 JR Z,logo_skip CP $2D JR Z,logo_skip CP $24 JR Z,logo_skip These checks are concerned with either the flashing logo letters -- Value $d3 or any colour tile where the ink and paper are the same colour. So Instead of doing checks for specific colours I will check for ink and paper match instead. The $d3 match is best changed to a more vague check of flashing ink/paper. This allows the colour to be changed with one instruction at the part the draws the giant text. (assuming we have split the giant text from the logo) Next we have a lot of checks for the various slope graphics. and a special case where the colour is changed. By looking at the data and looking at what is wanted, we can see that the reason we have a special case colour is because that single colour is odd compared to the rest. When that odd colour tile is drawn it ends up as a sloped tile with the same colour as some other sloped tiles. But slopping in the opposite direction. Which is why it is singled out and treated differently. It is easier and more logical to use the built in attributes of the tiles. The logo itself is drawn with no BRIGHT attributes. so instead of all the various checks needed to draw the logo. Lets just use the BRIGHT bit as a simple indicator for the direction of the slope. So if the tile has the BRIGHT bit it slopes one way and a tile without the BRIGHT bit can slope the other way. Doing this removes the special case tile. The tile has its colour changed to what it should be. After checking the tile for the BRIGHT bit, The bit is immediately switched off. This changes the draw routine to the following. logo_graphics: ; this part adds the graphics LD DE,ATT0 logo_draw LD A,(DE) bit 7,a jr nz,logo_skip ld c,a rrca rrca rrca xor c and 7 jr z,logo_skip ld a,c ld hl,triangle_udg bit 6,a jr z,logo1_graphic ld hl,triangle_udg+16 and 10111111b ld (de),a logo1_graphic ld a,e rlca rlca rlca and 8 call index1 ; add a to hl returns a=(a+hl) ;ignore the return "a" ld c,d BIT 0,D LD D,high CHAR0 JR Z,Llow LD D,high CHAR8 Llow CALL printing_char ;the instruction before the normal call, which loads b with 8 ld d,c logo_skip: INC DE LD A,D CP high +(ATT16) Jr NZ,logo_draw ret ;In my code this is a subroutine ; this uses slightly different data. from the original. Part 4 is all the code placed together. (a working example)

Part 3) I have not forgotten part 2a. (numbers quoted are approximations for the size of data fields. They are approximations not definite numbers) We are drawing the impossible triangle logo on the screen. And for most new iterations of the game we change the graphics to incorporate a new heading text. This is ok if we are restricting ourselves to one boring title screen. But it necessitates redrawing the logo each time to have the new text in it. It is easier to separate the logo from the text graphics. Then any editing done to the text, does not change the way we store the logo. We can compress the logo and leave the logo alone for each and every edit. We can also have multiple title screens and the logo can be placed behind any of the new text we generate. This at first looks to be counter productive. We now have two sets of data to compress and probably need two routines and two sets of set up code. One for the logo and one for the text. I admit it does seem strange, but I wanted the ability to have multiple screens, and separating the data and the text overlay revealed a feature of the logo that has been buried due to the nature of the graphics data presented. This is the revelation that the logo is generated from repeating graphics. Every value in the logo data is repeated. and this revelation means we can do an instant halving of the logo data. Yes the immediate reduction from 512 bytes of data to only 256 bytes of data, just because of this fact. We can then off course compress the half size logo. This will reduce the data to 84 (approximate) bytes... Read that number again 84 (approximate) bytes of data for the naked logo. Which makes the original 512 bytes data look a big waste of space. But hang on we now have no text over laying the logo. We need to add that data onto the logo data. The text overlay spoils the figures. The text overlay will consume a lot of data and we do need a quick and easy method of changing the text. Unless you are up to writing yourself an editor to do so. I settled on a simple bit pattern for the overlay text data, one that is visual and easy to edit. Pasmo the assembler does not make the layout of this data easy, but it is still easy enough to edit. The layout consists of Bits within a byte. Since a byte has eight bits, we can write out four bytes in binary and it can represent the 32 attribute squares across the screen. This data table for the text will use 16*4=64 bytes to define the overlay of text on the screen. It is data that is easy to edit without any other help. logo_overlay db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00100010b,11111000b,10001111b,00011110b db 00100010b,10001001b,01001000b,10100000b db 00111110b,11100010b,00101000b,10011100b db 00100010b,10001011b,11101000b,10000010b db 00100010b,11111010b,00101111b,00111100b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db 00000000b,00000000b,00000000b,00000000b db $ff ; manual inspection for value Proportional spaced font, as used in this forum will change the look of the data presented above. But I hope you can still read the word HEADS in the binary data. And finally we need a method of placing the above data on top of the expanded logo data. Which is as follows. text_overlay: ld hl,ATT0 ld de,logo_overlay ld c,FLASH+RED+8*YELLOW text: ld a,(de) cp 255 jr z,graphic ; or return (depends on how this is set up) ld b,8 ;width of data byte text1: rlca ;bit out jr nc,clear ld (hl),c clear: inc hl djnz text1 inc de jr text The end of the routine graphic: ; the routine above is just 25 bytes (approximate) ----------------------------------------------------------------------------------- So we can draw the logo with its overlay of text in this sequence Draw logo (84 bytes approx of data) onto the attribute area of the screen overlay the text (64 bytes of text) onto the attribute area of the screen. then translate the combined attribute data into the graphics needed (part 2b) The two expansion routine are 53 (approx) for the logo draw routine and 25 bytes for the logo overwrite routine. ------------------------------------------------------------------------ A new screen only requires new text data, so we can generate a new logo screen for 64 bytes plus its set up data. We still save hundreds of bytes on the basic data.....

Addendum:- to the compression of data part 1 and 2 I made no attempt at explaining what the compression routine is doing and no attempt at how I manage to compress the data. I started off by just looking at the data and trying to see patterns. No obvious patterns were evident. I then looked at the spread of data. This is just looking at how many values are in the data that I want to compress. In the lower screen attribute data there are less than 16 different values, so I can immediately assign 4 bits to the spread of data. This leaves four bits in a byte. Which has a range of 0 to 15. If I assign those four bits as a counter then I can increase in range from 1 to 16. There being no point in including a nothing count. The method picked also needs the data to be repetitious, having long enough runs of data to have a running count. If the data changes value often, then this method starts to fail. The failure means the data does not compress, but does not take up more space than the uncompressed data. ( this ignores the code to uncompress the data) Now lets look at some of the data DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 ;line 1 DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 ;line 2 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ;line 3 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ;line 4 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ;line 5 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 ;line 6 DEFB $01,$02,$03,$04,$05,$06,$07,$07,$07,$07,$07,$07,$07,$07,$07,$07 ;line 7 bottom_translate: ;--- 0---1----2----3----4-----5----6----7----8-----9----a----b--- c db 0,$01,$02,$03,$04,$05,$06,$07,$46,$45,$41,$43,$44 Notice bottom translate has a row of numbers written above each of the values in the DB statement. These numbers correspond to the numbers position in the data. The values in the bottom translate are all the differing values in the data we are compressing. Now looking at the data:- The line1 comprises of 16 identical $46. From the bottom translate table we can see that $46 is at an offset of 8 To compress line1 of data we write $F8. The $Fx part of the compression represents the value repeated $f times more- 16 values in total The $x8 part represents the value at offset 8 in the bottom translate data - $46 To compress line2 of data we write $f8 again The $Fx part of the compression represents the value repeated $f times more - 16 values in total The $x8 part represents the value at offset 8 in the bottom translate data - $46 To compress line3 of data we write $F0 The $Fx part of the compression represents the value repeated $f times more - 16 values in total The $x0 part represents the value at offset 0 in the bottom translate data - $00 To compress line4 of data we write $F0 The $Fx part of the compression represents the value repeated $f times more - 16 values in total The $x0 part represents the value at offset 0 in the bottom translate data - $00 To compress line5 of data we write $F0 The $Fx part of the compression represents the value repeated $f times more - 16 values in total The $x0 part represents the value at offset 0 in the bottom translate data - $00 To compress line6 of data we write $F0 The $Fx part of the compression represents the value repeated $f times more - 16 values in total The $x0 part represents the value at offset 0 in the bottom translate data - $00 line7 gets a bit more complicated, here the data is changing and we do not have big repeats so compression breaks down. the first value on line 7 is $01 this compresses to $01 The $0x part of the compression represents the value repeated $0 times more - 1 value in total The $x1 part represents the value at offset 1 in the bottom translate data - $01 the second value on line 7 is $02 this compresses to $02 The $0x part of the compression represents the value repeated $0 times more - 1 value in total The $x2 part represents the value at offset 2 in the bottom translate data - $02 the third value on line 7 is $03 this compresses to $03 The $0x part of the compression represents the value repeated $0 times more - 1 value in total The $x3 part represents the value at offset 3 in the bottom translate data - $03 we can slowly go through all the data and visually compress the data Edited to reformat some data - the data layout is compromised by proportional spaced fonts

Part 2) I write code out of curiosity. So after the quick attribute compress. I wondered how much that routine would compress the logo. The methods I have used before are different in the way they compress, but sometimes just taking a different path shows a better route. So the curiosity part of me did the compression. These compression's are done from visual translations. e.g. I look at the data and work the numbers out. The observant will have noticed that in part 1) there is a label called "draw_logo_loop" and a reference to "logo_translate", which was a good indication that I had written the code and worked out the data. so here is the same kind of data and code for the logo as for the bottom attributes ld de,ATT0 ld ix,LOGO_DAT ld hl,logo_translate call expand ; the routine shown in part 1 logo_translate: ;---------- 0---1----2----3----4-----5----6----7----8-----9----a----b--- c db $00,$28,$05,$d3,$2d,$25,$24,$09,$29,$2c,$04,$08 ;compressed top screen attributes for the logo LOGO_DAT DB $f0,$f0 DB $f0,$f0 DB $f0,$10,$11,$12,$90 DB $30,$23,$00,$23,$00,$23,$00,$01,$23,$05,$23,$00,$23,$30 DB $40,$03,$10,$03,$30,$03,$11,$04,$03,$15,$06,$03,$30,$03,$40 DB $40,$03,$10,$23,$00,$01,$03,$14,$05,$23,$06,$23,$10,$03,$40 DB $40,$03,$10,$03,$00,$11,$04,$03,$15,$16,$0a,$03,$06,$03,$30,$03,$40 DB $30,$13,$10,$23,$04,$05,$03,$16,$0a,$23,$06,$23,$10,$03,$40 DB $70,$18,$14,$19,$1a,$10,$17,$16,$90 DB $70,$17,$18,$14,$12,$10,$17,$16,$90 DB $50,$03,$00,$1b,$03,$07,$03,$08,$03,$04,$12,$03,$07,$06,$03,$20,$03,$50 DB $50,$03,$20,$03,$0b,$03,$07,$03,$08,$14,$03,$07,$06,$03,$20,$03,$50 DB $50,$03,$00,$03,$00,$03,$00,$03,$0b,$03,$07,$18,$03,$07,$06,$43,$50 DB $50,$03,$00,$03,$00,$03,$00,$03,$00,$03,$0b,$17,$03,$07,$16,$00,$03,$70 DB $50,$43,$00,$03,$00,$13,$03,$0b,$23,$06,$00,$03,$70 DB $f0,$10,$1b,$1a,$90 DB $ff Not bad in compression the logo translate uses 12 bytes, while the logo_dat uses vastly less than the 512 bytes of the original. (in the region of 192 bytes (exact figure is not important)) A possible saving of around 430 bytes for this data and the bottom attribute data. whilst this did work, I have modified the data at some point. And it might not work properly now. (it will be very close) What this illustrated to me was my other methods do a better job. In part 2b. I will re_write the part of the routine that draws the logo on the screen, this will save some more memory.

New code:- based on a quick re_write as illustrated by the small heads demo. Part 1) The original uses a big data table to colour in the status area of the screen. And a similar table to colour in the colour table entry screen. That table is just as easy to compress, but I will ignore that data here and concentrate only on the lower screen attribute area and its data. The original lower screen data:- situated in memory in the original game at $9a00 ;9A00: Attributes for the bottom third of the screen bottom_att DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $01,$02,$03,$04,$05,$06,$07,$07,$07,$07,$07,$07,$07,$07,$07,$07 DEFB $07,$07,$07,$07,$07,$07,$07,$07,$07,$07,$06,$05,$04,$03,$02,$01 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $45,$45,$06,$06,$04,$04,$41,$41,$05,$05,$43,$43,$44,$44,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $45,$45,$06,$06,$04,$04,$41,$41,$05,$05,$43,$43,$44,$44,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 This data was moved to the lower screen with:- Code at $8907 LD HL,bottom_att ; 8907 ;L9A00 LD DE,ATT16 ; 890A ;$5A00 LD BC,$0100 ; 890D ; LDIR ; 8910 ; and code at $8b07 LD HL,bottom_att ;L8B07 ;L9A00 LD DE,ATT16 ; 8B0A ;$5A00 LD BC,$0100 ; 8B0D ; LDIR Both of these LDIR routines are replaced with a call to draw_bottom_att which is new code sitting in ram somewhere. This code is draw_bottom_att ld de,ATT16 ld ix,bottom_att ld hl,bottom_translate ; expander sub expand: ld (S_M_C_translate),hl draw_logo_loop ld a,(ix) inc ix cp 255 ret z S_M_C_translate equ $+1 ld hl,bottom_translate ;logo_translate << edited to remove this undefined label (in the code here) call indexer expand1 ld (de),a inc de djnz expand1 jr draw_logo_loop ;======================================================================= ; expander sub routine indexer ld c,a rrca rrca rrca rrca and 15 inc a ld b,a ld a,c and 15 ; + index into hl via "a" and return (hl+"a") in "a" index1 add a,l ld l,a adc a,h sub l ld h,a ld a,(hl) ret Looking at the lines and lines of code used above, you might be left wondering how all that saves any memory compared to a simple LDIR. A very quick count of the code comes in at 53 bytes. Now remember the original data was 256 bytes, so we need to be able to save at least 53 bytes. Any more than that and it is smaller in size. But we also get a subroutine which can be used in various ways as a bonus. So here is the original compressed bottom_att db $f8,$f8 db $f0,$f0 db $f0,$f0 db $01,$02,$03,$04,$05,$06,$97,$97,$06,$05,$04,$03,$02,$01 db $f0,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $f0,$f0 db $ff bottom_translate: ; 0 1 2 3 4 5 6 7 8 9 a b c db 0,$01,$02,$03,$04,$05,$06,$07,$46,$45,$41,$43,$44 The above is less than 60 bytes (around 56) which means the code plus the data is less than 120 bytes. a saving of over 130 bytes. It is possible to use this method to compress the logo. (with decent gains, but there are better ways)

The heads are stored in a table, which stores only one definition for each head. The clever part is to use a pile of code to extract the heads, and reverse and shift each definition and place it over the original. Maybe not as noticeable but all willies animation is changed so that Willy has eight frames of animation in both directions.

Using the source code I provided. I spent a day changing and deleting code. This is an illustration of what can be achieved in a day. Main point to this demo is the change in animation and definition of willy Addendum:- What else was changed 1) The clock routine. re written to correct the am/pm problem. (Smaller code) 2) sprite glitch and screen copying. Uses LDI and raster copy (visual update) 3) Constant update of status line and dancing willies. Only updates if needed (faster+smaller) 4) The room draw uses my method of expansion and no compares. (faster + a lot smaller) 5) deletion of all code asking for the colour code at the start (more free space) 6) rewrite of the cheat input (faster+smaller) 7) changed all the sprite routines (faster) 8) removed rope bug 9) Changed logo draw expansion routine (twice) (a lot smaller) 10) changed method of colouring in the lower screen (a lot smaller) 11) changed every LDIR over 20 bytes to ldi (faster) 12) changed every keyboard reference to ports. Removed usage of BC registers when reading ports (consistent-bug removal-smaller) How many variations of Willy, are their is in this demo. Ignoring the flying pig there are 16 definitions. HeadsJSW.tap

Raw6jsw.zip View File This is just an assembly listing of Jet Set Willy, which is not the same as a disassembly. Since this uses the skoolkit disassembly as its basis, It has been placed here so it is not viewable to none members. The change from a disassembly makes the code a lot easier to understand and also a lot easier to edit. Submitter Norman Sword Submitted 06/21/2019 Category Other resources  

JET SET WILLY SOURCE CODE I mentioned a long time ago that I would eventually upload a source code for Jet Set Willy. This I have done and the code is in the download section, under "other resources". The version is Raw6jsw.asm but the 6 is just indicating that 6 steps were needed in its evolution from a disassembly Hope its of use to someone. The listing will assemble in Pasmo and output the game....

The simpler alternative is as follows LD HL,#3030 LD (#857C),HL LD (#857D),HL 9 bytes. Which is another byte shorter

Checking the ld hl,(counter) Zilog claim 16T states. So that's good enough for me. This was not a clinical dissection, it was me wondering why the game ran so slow. With the heading a stack copy version of Jet Set Willy I was expecting a bit of zip in the movement. The addition mistake and the subsequent error I will correct. ============================================= Just to be doubly sure I have dug out an old copy of Rodney Zaks. Page 334 16 T states

screen copies:- Here I will talk about the main feature of this version, which is the usage of a stack copy routine. Whilst the game is playing, the program has a multitude of screen data to copy. These copies are the main slowing down of the game. The amount of data that is copied consists of an attribute screen and a pixel or data screen. These are copied repeatedly. The order of copies might not be exactly as I write them out. Each game loop:- Starts by copying the Master Attribute area (512 bytes) to the working Attribute area of ram It then copies the Master Pixel area (4096 bytes) to the working pixel area of ram The body of game -- moves and draws the sprites Then game loop continues and:- Copies the working pixel area of ram to the Viewable screen (4096 bytes) Followed by the working attribute area of ram to the Viewable screen attribute area of ram (512 bytes) Goes back and repeats each game loop The above is moving for the copying of screens a total of 9216 bytes This shows a lot of memory is copied on each game loop, and ways to speed this up, will have a dramatic effect on the games overall speed So from here on I will partly discus the main methods for copying huge chunks of memory. The three most commonly used on a spectrum are 1) LDIR 2)LDI 3)stack copy. written in normal order of speed The best way to look at a copying routine, is to look at how long each method takes to move one byte. A copy routine is after all just moving bytes of memory. . Here I will split the time into two parts, the first part is the time it takes to move the single byte in the idealised form. And then the overhead needed to perform the copy in a loop. The reason I split the timing is because the idealised part of the timing has to be performed. The idealised part will always be written and we have no option but to write and execute that part of the code. The overheads are the parts that can be changed by the programmer and the overheads are the programmers responsibility. . The idealised speed of moving a single byte . The idealised times are the times that the basic op code(s) takes to move one byte . Idealised times . LDIR 21 T states per byte . LDI 16 T states per byte . Stack copy - pop and push - 2 bytes at 10.5 T states per byte . . The overheads for the loop With LDIR their are no loop overheads. We set the up the data for the op code, then execute it. The LDIR executes its own internal loop . With LDI the main overheads are dictated by how much the LDI is rolled out. Fastest possible loop, using inline code has only one op code to perform the loop. With a stack copy we need lots of op codes to perform the loop. The amount used is up to the programmers imagination. Here the only code looked at, is the code used by Mark Woodmass. Total time to move the byte adding the overheads LDIR -- this stays at 21 T-states, being the sum of the idealised op coded time and no overheads . LDI -- this would normally be written as a loop macro- but for clarity I will write it out I have picked a roll out of 32 LDI's, the more we have the faster it is. But having more and more rolled out brings decreasing gains. I have picked 32 as a good starting point. The copy loop using LDI loop: LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI jp pe,loop 10 T-states . here we have added for every 32 bytes moved a "jp pe,loop" into the loop overheads . This takes 10 T-states. This overhead is divided by how many bytes where moved in the loop . so the overheads are 10 T-state/32 or 0.3125 T-states or (0.3 T-state approx) , so negligible compared to the 16 T-states of each byte moved. This is moving a byte in around 16.3 T-states . . . Stack copy using Pop push. now lets look at the stack copy as used by Mark Woodmass the body of the loop is ; overhead T-state / Total T-states loop: ld sp,ix 10T 10T pop hl pop de pop bc pop af ex af,af' 4T 14T exx 4T 18T pop hl pop de pop bc pop af ld sp,iy 10T 28T push af push bc push de push hl exx 4T 32T ex af,af' 4T 36T push af push bc push de push hl ld de,$10 10T 46T add ix,de 15T 61T add iy,de 15T 76T ld hl,(counter) 16T 82T 92T << correction of addition. (subsequent text altered to correct mistake) dec (hl) 11T 93T 103T jr nz,loop 12T 105T 115T We move 16 bytes , but we have an overhead to add onto the pop and push ideal of 10.5 T-states The overhead per byte is 115/16 T-states or 7.1875 T-states (7.2 approx) This routine moves every byte at an idealised speed of 10.5 T-states, to which we now add the overheads per byte of 7.2 T-states. Giving an overall speed of 17.7 T-states for each byte moved. ------------------- Summery of total times taken to move a single byte in T-states Total time Ideal Time overheads LDIR 21 T-states 21 T-states 0 LDI 16.3 T-states 16 T-states 0.3 Stack Copy 17.7 T-states 10.5 T-states 7.2 T-states (Mark Woodmass version) Stack Copy 13.1 T-states 10.5 T-states 2.6 T-states (last version I wrote. See addendum) ------------------------- The version of stack copy used in this version of the game has managed to be slower than a very very simple rolled out LDI loop This is a good example of being told that the stack copy method is the fastest method, and then writing some code to show how the version you write, manages to be slower. ***************************************************************************************************************************************************** Addendum:- In order to make a stack copy routine fast, we need to reduce the overheads to a minimum. This is best achieved by rolling the code out in a similar way that LDI is rolled out to cut the overheads. With stack copy rolling out the code consumes a lot of ram. But if we want the benefit of the speed the routine can bring. Then we must roll the code out and sacrifice the ram. In the last version of a stack copy I wrote. The main loop was slightly under 300 bytes in size. but the overheads per byte was around 2.6 T-states (the figures quoted are from a quick look at some of my code. the exact figures are unimportant. I am just trying to show how far the overheads can be reduced) ***************************************************************************************************************************************************** ** NOTE** The idealised times for stack copy can be influenced by using the of IX and IY registers as part of the push pop registers. The above is an attempt at simplicity. We look only at the overheads and ignore the registers used. (I am not trying to explain in great detail) **NOTE** In the original timing for "LDI". I used 1/3 this has been changed from 1/3 to .3. to correct inconsistency in numeric notation.

View File Manic Miner By S.P. And Bug Byte When Matthew wrote manic Miner he released the game originally with Bug Byte. When he re-released the game with Software projects some small changes were made to the graphics. This version is not a new version of the game and its main novelty is the ability to swap between the versions of the game. Whilst I made minimal change to the games playing style or data I changed some of the ways that the game plays. This is not a simple edit of the game it is a rewrite but leaves the basic data intact. I have added :- item collection sounds. sound effects for being hit by the solar ray sprite collision sound effects heavy landing sound effects. death collision graphic and sound effect an extensive cheat. an explanation to why you have died an animation of the high score being added a redraw of the title screen (fixing the keyboard graphics) a title screen animation of a spectrum analyser a credits screen a title screen animation showing the version about to be played (Bug Byte graphic or S.P. graphic) a sprite mask on the main character a redesign on how the screens update (to stop sprite glitching) the list of changes is extensive (Some listed above) the overall feel will still be that you are playing the original Manic Miner. This file is listed elsewhere on this site, Having been asked by several people where this file is listed, I realise it needs to be placed in the Manic Miner Download section so it can be found easier. Addendum To include extra keys - Each game play alternates between Bug-Byte and Software Projects. The version can be seen as an animated graphic, displayed while the title music plays. To enter the cheat -- start game, and in the Central Cavern type 6031769. If the cheat value is accepted a magenta boot will be displayed. Once cheat is enabled. It stays active until the computer is switched off or the computer rebooted. To activate icons. Press 1 - Toggle fast turn - indicated by an icon on lower right with Miner Willie's legs and arrows Press 3 - Toggle tool kit activation - allows collapsed floor rebuild - press 9 to rebuild a collapsed floor Press 4 - Toggle Medical tool kit activation - This stops normal death events. Now the more convoluted keys. Press 9 and hold, now press the 1 key - the Cavern shown will be the previous cavern - if on the Central Cavern if will move to the Final Barrier Press 9 and hold, now press the 2 key - The cavern shown will be the next cavern. - If on the Final Barrier it will move to the Central Cavern Note the 1 key icon toggle - does not need the activation of cheat - it is always available. Submitter Norman Sword Submitted 05/17/2019 Category Manic Miner [Remakes]

"jagged finger fix by Norman Sword" The fix used to reduce the jagged finger look in the file mention in Post#7 is basically a copy of the code I placed on this website. So it comes as a surprise that someone else has fixed this problem. Have they really? It seems to me that they have used my code. This site mentions so often things like Goeff mode etc that this partial fix to this problem should be call "jagged finger fix by Norman Sword". It was a problem that prior to my posts, was not fully understood in it's nature or how to remove. The code used to partially cure this problem is basically the code I wrote. : ; If you have a problem with what I say here then please show me any code prior to the code I listed that did anything of the same nature. Or any version of jsw(1) that fixed the problem prior to my posts.

The choppy description is basically what I have described as the jagged finger effect, and is nothing to do with television / monitor effects. Otherwise every version would exhibit the same effect on every game format. Since they don't it is evident the effect is game produced on the original spectrum version. Play any of my versions jsw128 VK or jsw128 VL and the problem does not exist.

Slight edit. Due to the original wording, which refers to five bytes. A figure I did not question and repeated ad verbatim. However the figure should be six bytes. So an edit to correct and also change/delete some words which are misleading. --------------------------------------------------------------------------------------------------------------------------------------------------- The code is monitoring 32884 (#8074) for the release of angry Eugene. This can be changed to monitor one of the objects directly, and the best choice is the object closest to the portal. Since the order of collection is well known, this is probably not going to be noticed by the normal player. This suggested change is aimed more at a new room design and pushing towards your original goal of resetting the room in Manic Miner, but not the objects. You can change both the references to 32884(#8074) to one of the following, or even change either reference to one of the following. (mix and match) Object 1 stored at 32885 (#8075) position (1,30) Object 2 stored at 32890 position (6,10) Object 3 stored at 32895 position (7,29) Object 4 stored at 32900 position (12,7) Object 5 stored at 32905 position (12,9) The logical change is to point at 32905 which is the object closest to the portal. The reason for the suggested change is that it would indicate which object triggers the anger of Eugene and collecting that object, would make Eugene change colour and descend. Collecting the trigger object before the other objects are collected would send a powerful message that that object must be left till last. This suggested change was so a room reset, would only need to reset the last object and the room would be re playable. This suggested change unfortunately does not achieve that goal. The player could ignore Eugene and carry on collecting objects. Then the last object collected would no longer be the trigger object and we are back to square one. ----------------------------------------------------------- Still might be interesting to change the logic so it monitors just one object and not wait till all objects collected.

Modifying Angry Eugene Minimum needed to modify both routines is 2 bytes ------------------ The first one byte modification --------------------------------- The first six byte routine, only needs the last JR Z,XX offset changing to 0 S.P. Version: The six bytes in question are 36355 to 36360 36355 LD A , (32884) 36358 OR A 36359 JR Z , 36378 >>>> Poke 36360,0 ---- This changes the code to JR Z,36361 B.B. Version: The six bytes are at 36344 to 36349 36344 LD A , (32884) 36347 OR A 36348 JR Z , 36367 >>>> Poke 36349,0 ---- This changes the code to JR Z,36350 This above just changes how far the relative branch has to jump. ------------- The second one byte modification -------------------------- The second modification is as you stated (slightly edited) Change the byte at 36449 from 32 to 24, this changes the instruction at 36449 from JR NZ,XXX (Jump Relative Non Zero,offset) to JR XXX (Jump Relative, offset) Original: 36449 JR NZ , 36458 Changed: 36449 JR 36458 B.B. Version: Again the same thing just in a slightly different place change the byte at 36438 from 32 to 24 to effect a change from a JR NZ to a JR: Original: 36438 JR NZ , 36447 Changed: 36438 JR 36447 ------------------------------- Total modification 2 bytes