Norman Sword Posted November 3, 2017 Report Share Posted November 3, 2017 (edited) 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,4TWNK: AND 7 OR $40 LD (HL),A INC HL INC A DJNZ TWNK RET FREE SPACE UP TO $8D33 AROUND $29=41(DECIMAL) Edited July 8, 2019 by IRF IRF, jetsetdanny and Spider 3 Quote Link to comment Share on other sites More sharing options...
IRF Posted November 3, 2017 Report Share Posted November 3, 2017 (edited) Nice one Norman! I came up with an optimisation which placed the INC, AND and OR in a subroutine, that is then CALLed eight times - but it only yielded a net saving of about ten bytes or so. Edited November 3, 2017 by IRF Spider 1 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted November 3, 2017 Author Report Share Posted November 3, 2017 (edited) Yes, it's a really good one, Norman Sword, thank you! Now you will be really impressed by this :lol: : When creating the Sprite Selection Screen in "Jet Set Mixup", Ian set the attributes for the various numbers which are printed on the screen using a sequence of LD HL,&0000 - LD (&0000),HL instructions. So you have e.g. 21 41 41 22 a4 58, to set some attributes to BRIGHT blue. He went through most (or almost all) colours like this. Now, when working on a similar selection screen related to a project which is discussed elsewhere, I introduced the following optimisation: I grouped the colours, I introduced the first one (say, non-BRIGHT red, i.e. 02) using the same instruction, so 21 02 02 41 a4 58, and then I introduced the following colours using INC H and INC L instructions (24 2C), thus saving one byte with the definition of each new colour, with the exception of when I had to "jump" from the last non-BRIGHT colour to the first BRIGHT one, which had to be done using the LD HL,&0000 instruction once again. The total net saving was of 8 bytes, I believe. Not too impressive, but if it should happen that you just need one or two (or five) spare bytes in the vicinity, it could come in quite handy. Edited November 3, 2017 by jetsetdanny Spider and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted November 4, 2017 Report Share Posted November 4, 2017 Danny, if the BC or DE register-pair weren't being used at the time, then maybe you could have done for example a LD DE, #0101 and then four ADD HL,DE commands (7 bytes in total), replacing four INC H and INC L (8 bytes)? Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted November 4, 2017 Author Report Share Posted November 4, 2017 So that would save another byte, wouldn't it? Quote Link to comment Share on other sites More sharing options...
Norman Sword Posted November 4, 2017 Report Share Posted November 4, 2017 (edited) 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_TABLEx8300 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+0x8304 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+0x8308 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+0x830C 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+0x8310 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+1x8314 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+2x8318 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+2x831C 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+2x8320 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+2x8324 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+2x8328 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 rrcahigh_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-coordinatehop2: 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 Edited November 4, 2017 by Norman Sword jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted November 4, 2017 Report Share Posted November 4, 2017 (edited) So that would save another byte, wouldn't it? Two bytes - one per set of five colours, there being ten coloured number buttons (five BRIGHT and five non-BRIGHT). But I haven't checked whether, in the context, DE (and BC) are being used in a loop to keep track of something else - if so, then having to PUSH and then POP would negate the saving! Edited November 4, 2017 by IRF jetsetdanny and Spider 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted November 4, 2017 Report Share Posted November 4, 2017 (edited) Norman's latest contribution looks ingenious! I haven't fully got my head around it yet, but the basic principle is that, in his previous incarnation, only the lower nybble of the rope data table were used, so now he's merged pairs of entries so that it takes up half the space! Edited January 12, 2018 by IRF Spider and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
jetsetdanny Posted November 4, 2017 Author Report Share Posted November 4, 2017 Great stuff, Norman Sword, thank you! :) IRF 1 Quote Link to comment Share on other sites More sharing options...
IRF Posted November 6, 2017 Report Share Posted November 6, 2017 The following sequence in the arrow-drawing code, at #927D, is used to detect a cell containing white INK: AND #07 CP #07 JR NZ... In Geoff Mode this is replaced with the following sequence, providing a saving of one byte (it is in a slightly different location in Geoff Mode, at #9271): INC A AND #07 JR NZ... This trick could be repeated at #93ED, in the item-drawing code, which also seeks out white INK cells. Spider 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.