Jump to content


Norman Sword

Member Since 08 Mar 2017
Offline Last Active Dec 04 2018 01:03 AM
-----

Posts I've Made

In Topic: Free space and code optimisation in Manic Miner

28 November 2018 - 05:58 PM

Modification of Manic miner tune. The above routine was an exercise in compacting the code. Code that was never used. 

The original modification from.

 

SUB 8
RRCA

RRCA

RRCA

CPL

OR #E0

 

TO 

 

RRCA

RRCA

RRCA

NEG

OR #E0 --- my code has OR L where L=#e0

 

This modification works fine and gives exactly the correct results. And does not need any additional code.

my error was just swapping the routine around, whilst still thinking about the CPL instruction used in the first routine

NEG
RRCA
RRCA
RRCA
OR #E0 --- my code has OR L where L=#e0

Moving the NEG from after the RRCA instructions to before the RRCA instruction changed what it did.

Simpler to revert back to the sequence

SUB 8
CPL

RRCA

RRCA

RRCA

AND 31
OR L
 

Since the above code has been tested. I know it works for all values, in exactly the same way as the original.

 

Works 100%

The routine is still 70 plus bytes smaller than the original.

 

Addendum. 

The AND 31 instruction was added before the code change to compacted data. The reason for its inclusion was to permit the moving of the piano graphics to any screen line, and not be forced via the old code to one of 3  fixed screen positions. 

2nd addendum:
The code I reference is the original layout. Unfortunately for me, I have edited so much code and done so many changes in the code, that I would need to keep going backward and forward checking items for reference.

The code listed in the Manic Miner music routine, is a derivative of the original code, which because of dual usage no longer OR's in the screen address,  It now adds it. This slight change is what the next post #12 is referring to as the difference in opcode usage. 

The code I listed is relocatable and not fixed to any memory address. In the context of being placed back into Manic Miner, it can again have the restrictions imposed on it. The tune data and the two data tables used for data expansion, can be fixed into a page, along with the fixed screen keyboard reference. This can remove several opcodes and make it even smaller. (something I will not do). I prefer the options of being able to have code where ever I place it


 


In Topic: Free space and code optimisation in Manic Miner

27 November 2018 - 12:53 AM

Edited and swapped some registers around - another 2+ bytes smaller

 

This code can be placed anywhere in ram.

 

;The complete title music routine (data and code) for Manic Miner

;
Manic_Miner_Title_Music:
        ld de,Tune_Data
;
manic_loop:
        ld a,(de) 
        OR A          
        RET Z
        AND 3              
        LD HL,TIME_SHIFT
        CALL STEP_INDEX  

        LD C,A                                << added   
        LD (S_M_C_ahead),A
        LD A,(DE)
        LD HL,NOTE_SHIFT
        CALL STEP1_INDEX

        LD B,A                               << added
        LD C,A
        INC DE
        LD A,(DE) 
        inc de
        push de
        ld d,a   ;NOTE 1            
        CALL NOTE_PLACE
        push hl
        ld (hl),#50
        ld a,d

        add a,b                             << added        
        add a,c 
        ld e,a  :NOTE 2           
        call NOTE_PLACE  
        push    hl
        ld (hl),#28
        LD A,L 
        ld l,e  ;NOTE 2   (lows)  
        ld h,d ;NOTE 1 (highs)

        ld b,0                              <<added
S_M_C_ahead: equ $+1
        ld      bc,0   

tune_loop:
        OUT (#FE), A 
        DEC D   :NOTE 1 (highs)                  
        JR NZ,tl_1  
        LD D,H                
        XOR #18                 
tl_1:
        DEC E : NOTE 2 (lows)                   
        JR NZ,tl_2  
        LD E,L                  
        XOR #18                 
tl_2:
        DJNZ tune_loop          
        DEC C                   
        JR NZ, tune_loop        
        POP HL             
        LD (HL),56
        POP HL             
        LD (HL),56
       POP DE
        CALL test_enter ;#9337
        RET NZ               
        JR manic_loop          

;
NOTE_PLACE:
        LD HL,#59e0       ; with this code, the piano address can be at the start of any attribute line
        SUB 8      
        CPL 
STEP1_INDEX
        RRCA
        RRCA
        RRCA
        and 31
STEP_INDEX:
        ADD A,L
        LD L,A
        ADC A,H
        SUB L
        LD H,A
        LD A,(HL)
        RET

;
TIME_SHIFT: DB 25,50,80,100
NOTE_SHIFT: DB  0, 1, 6, 8, 10, 11, 13, 20, 21, 24, 32, 43, 75, 77, 128, 154
;
Tune_Data:  
DB 2+8*1,128
DB 2+8*1,102
DB 2+8*1,86
DB 1+8*1,86
DB 1+8*10,171
DB 1+8*3,43
DB 1+8*3,43
DB 1+8*10,51
DB 1+8*6,64
DB 1+8*6,64

DB 1+8*10,171
DB 1+8*1,128
DB 1+8*1,128
DB 1+8*1,102
DB 1+8*1,86
DB 1+8*4,86
DB 1+8*8,171
DB 1+8*4,43
DB 1+8*4,43
DB 1+8*8,171

DB 1+8*7,48
DB 1+8*7,48
DB 1+8*8,171
DB 1+8*1,136
DB 1+8*1,136
DB 1+8*1,114
DB 1+8*1,76
DB 1+8*1,76
DB 1+8*8,171
DB 1+8*8,38

DB 1+8*8,38
DB 1+8*8,171
DB 1+8*7,48
DB 1+8*7,48
DB 1+8*8,171
DB 1+8*1,136
DB 1+8*1,136
DB 1+8*1,114
DB 1+8*1,76
DB 1+8*1,76

DB 1+8*10,171
DB 1+8*6,38
DB 1+8*6,38
DB 1+8*10,171
DB 1+8*6,51
DB 1+8*6,51
DB 1+8*10,171
DB 1+8*1,128
DB 1+8*1,128
DB 1+8*1,102

DB 1+8*1,86
DB 1+8*1,64
DB 1+8*11,128
DB 1+8*5,32
DB 1+8*5,32
DB 1+8*11,128
DB 1+8*3,43
DB 1+8*3,43
DB 1+8*11,128
DB 1+8*1,128

DB  1+8*1,128
DB 1+8*1,102
DB 1+8*1,86
DB 1+8*1,64
DB 1+8*9,128
DB 1+8*2,32
DB 1+8*2,32
DB 1+8*9,128
DB 1+8*4,38
DB 1+8*4,38

DB 1+8*0,0
DB 1+8*1,114
DB 1+8*1,114
DB 1+8*1,96
DB 1+8*1,76
DB 1+8*13,76
DB 1+8*1,77
DB 1+8*1,77 
DB 1+8*13,76
DB 1+8*1,91

DB 1+8*1,86
DB 1+8*15,51
DB 1+8*1,51
DB 1+8*1,51
DB 1+8*15,51
DB 1+8*1,64
DB 1+8*1,102
DB 1+8*1,102
DB 3+8*1,114
DB 1+8*1,76

DB 1+8*1,86

DB 1+8*12,128
DB 0+8*14,128 
DB 0+8*1,128
DB 1+8*12,128

DB 0 ;

 

 

Addendum:-

 

slight change shortens code by 3 more bytes so around 73+ bytes smaller.
 


In Topic: Free space and code optimisation in Manic Miner

27 November 2018 - 12:42 AM

Compressed the data and the optimised the code routine size. I have since chopped another fives bytes of the routine, so around 62 bytes smaller. Going solely from your data of eight bytes. I assume a saving of around 70 bytes from the original.


In Topic: [File] JSW 128 VL5

23 November 2018 - 02:00 PM

The delay in response is simply caused by having no knowledge that comments had been placed here.

The yellow target sprite. Signifies that objects collected in this room, will increase the rubber tipped darts catch that Willy fires at other sprites.
I am pleased that the icon I drew managed to convey what is was.... A dart hitting a dart board. 
(at no stage is another sprite harmed by being hit by these very soft rubber capped darts. All that happens is they are instantly transported to a safe place. To await re-emergence in the room)  

The version VL5 is old . The version I have now is considerably faster, and has several improvements.

The increase in speed is significant and I realised that rather than just slowing down the game when the slower modes are activated. It is just as easy to play the music.  This means that rather than the background clicking of a note, in the slow game versions, I play actual notes  (if music is turned off, it still uses the music routine, but sound output is disabled from the routine)

I have also added a new set of title graphics and a lot of other changes. No room or game layout changes.


The speed increase as stated is considerable, I am tempted to re-visit version VK and implement the changes to allow that to benefit from the change in logic. ( the amount of code change is vast - A couple of days work minimum, copying and changing routines from VL to VK. No plans to do in the near future )  


------------------------------------------------------------------------------------------------------------------------------------
The speed increase was caused by wondering if I could change the format of JSW so that it plays  a full screen game. The bigger screen size would cause a possible 50% drop in speed. So I added some code to increase the game speed to compensate for a possible slow down. The previous statement does not indicate that the added code was actually a major change in how the game works. I was curious to see how much effort it would take to do this change and a demo version of Vl5 was written ----Expecting major problems ------ So I was pleased when I found that the basic idea worked, and it has subsequently been updated and improved. My speed standard , the double room walk, in this demo version can be done in 8.3 seconds. (the origin JSW takes 20 seconds) 

The tests conclude that a full screen game is an option. The problem for me is that the amount of change needed is, as always, considerable. Which is not really an option from the game data layout that I have at present. To implement a full screen game I would need to start back at the basic original code. 

To start again I would need to yet again construct an assembler listing that is relocatable. (*** note 1) For example taking Skoolkits listing, the source code generated is far from being a usable source listing for what I aim to do. There are  far too many fixed page references, and offsets specific to the game. These all need changing and this in itself is a big job. This I do by manually editing the code, line by line reference by reference. If you saw my listings you would see the difference in layout. I let the computer/assembler do the calculations.

The source code I generate from doing this is quite a lot different from what is seen in typical listings. Perhaps I should set my next task as being the output of a workable source code for JSW.  

------------------------------------------------------------------------------------------------------------------------------------
Note 1. When constructing my version of the source code, I always succumb to temptation and edit the code as I edit the layout. This means I have  never had an unmolested relocatable working source code.


, .  ! ,,, ...! .''...


In Topic: Free space and code optimisation in Manic Miner

23 November 2018 - 11:51 AM

My original edit of this from around six months ago is only 12 bytes shorter than the post #0

I admit I have had numerous attempts at shrinking the code, in most case the end result  stayed about the same size. So those numerous attempts where deleted months ago.

I did however try one more time to edit this routine, and I did save a few bytes. My final edit for the overall Manic Miner Music routine is around 57 bytes smaller than the Music routine from post #0

 

I did however try one more time to edit this routine, and I did save a few bytes. My final edit for the overall Manic Miner Music routine is around 57 bytes smaller than the overall Music routine from post #0

So you know it can be done.


Addendum

The music routine consists of two parts. The code to play the music and the music data. One without the other serve no purpose in the game.