Jump to content

Norman Sword

Member Since 08 Mar 2017
Offline Last Active Feb 21 2018 07:36 PM

#9017 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 21 February 2018 - 03:34 PM

Having tested a room with a cell at head height. 


I find I can jump over it. So the third check is needed.


What is strange is the arc of willy jumping over a nasty compared to the arc of willy passing over a wall. They are nothing alike.


So I need to have a look at the ramp code or any other piece of code that might be relevant, and find out why the wall is stopping the arc in the manner it does. I am not concerned with the heel catch and land on a wall, but the point at which is says it is clear to move. The arcs are so dissimilar that I need to investigate the take off and clear portion. 



This is side tracking me from what I was doing...

#9006 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 21 February 2018 - 01:03 PM

When the nasty(fire cell) is set to the same attribute as a wall then a number of interesting things happen (with no change in code)


A nasty/wall acts as a normal wall. it will not let you pass into the space

Sliding down a nasty/wall we have yet another aspect of the ramp stair code affecting the outcome. The passing through the wall by willies head will kill him.

Walking on a tile that is defined wall/nasty will also kill him




I was investigating another theme. eg. invulnerability.


The code at #961e colours in willies tile as he moves around the screen. It has a check for nasties and kills willy if the area of willy is over a nasty. It also extends the checking to the area below willy for nasties and kills willy if he walks on a nasty.




The code at #8e49 deals with the tiles beneath Willies feet and specifically checks for nasties.


I see no reason for the code at #961e being made to check beneath his feet.

If the attributes of willy are cell aligned then test/ colour in the four tiles. e.g check for nasty/colour in the tile

If the attribute of will is not cell aligned then test/colour in the six tiles


The change is to remove the check specifically for beneath his feet. It is not needed.


This changes two parts of the code


95F8 LD HL,($85D3)

95FB LD DE,$001F  
95FE LD C,$0F         
9600 CALL $961E    
9603 INC HL Move    
9604 CALL $961E    
9607 ADD HL,DE      
9608 CALL $961E    
960B INC HL             

969C CALL $961E  
960F LD A,($85CF) 

9612 ADD A,B           

9613 LD C,A
9614 ADD HL,DE                  
9615 CALL $961E 
9618 INC HL          
9619 CALL  $961e          
961C JR $9637                                ;quick count 38 bytes   




61E LD A,($80A0) 
9621 CP (HL)
9622 JR NZ,$962F 
9624 LD A,C 
9625 AND $0F
9627 JR Z,$962F 
9629 LD A,($80A0) 
962C OR $07 
962E LD (HL),A 
962F LD A,($80BB) 
9632 CP (HL) 
9633 JP Z,$90B6 
9636 RET                                           ;quick count 24  Total 62





; b=the offset for the ramp


      ld  c,2                   ; default colouring height

      ld a,(#85cf)          ; the y pos

      add a,b                ; the y pos + stair offset

     and 14                  ; check for cell aligned

     jr z,cell_aligned     ; if cell aligned then 2 high  

     inc c                      ;else it is 3


     ld de,31                 ;offset to next  


     call colour_me       ;colour left cell

     inc hl                     ; move from left cell to right cell

     call colour_me       ;colour right cell

     add hl,de               ;down a line

     dec c

     jr nz,cell_set_loop ;loop for the height

     jr #9637                ;draw willy                           ;quick count 27



          ld a,(#80bb)         ; nasty

         cp (HL)                  ;is this a nasty

         JP Z,90B6             ;kill if so

         LD A,(#80A0)       ;get the background tile

         CP (HL)                ;is this background 

         RET NZ                ;used so no colouring

        OR #7                   ; set ink white for willy

        LD  (HL),A             ;and colour in

        RET                                                            ;quick count 16 total 27+16=43 


;Which I hasten to add is nothing like the code I use

#8998 Final Barrier Glitch

Posted by Norman Sword on 20 February 2018 - 10:06 PM

The original loop terminates with the ink(1) and paper(0) 



37012 LD A,63                  Initialise A to 63 (INK 7: PAPER 7)
37014 LD HL,22528        
37017 LD DE,22529
37020 LD BC,511
37023 LD (HL),A
37024 LDIR
37026 LD BC,4                
37029 DJNZ 37029
37031 DEC C
37032 JR NZ,37029
37034 DEC A                 

37035 JR NZ,37014 

note this has filled the screen with value 1 when it finishes

37037 LD A,(33882) 
37040 OR A  Are we in demo mode?
37041 JP NZ,34449 If so, demo the next cavern





; a slight rearrange will fix the problem


37012 ld a,63           (or 64 if the same start colour wanted)
37014 ld hl,22528
37017 ld de,22528
37020 ld bc,4
37023 djnz 37023
37025 dec c
37026 jr nz,37023
37028 dec a            set the zero flag
37029 ld bc,511
37032 ld (hl),a
37033 ldir                does not affect the zero flag
37035 jr nz,37014

;this will finish the loop with black ink and black paper


37037 ld a,(33882)   etc.




#8967 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 16 February 2018 - 08:20 PM

This should be under JSW not MM. But I am reluctant to start a new heading.


I extended the headbutt to include the MM collapsing floors. 


The playability of this is restricted to 3 rooms. Hence the white blocking walls/floors added to stop wandering.


Additions:- collapsing floor, in addition to headbutt, gun, 4 logo title screens, and 128 rooms. 


The gun is now disabled in specific rooms.... Note the ammo display disappears for the room when the gun is switched off.


Added some SFX's





Attached Files

#8949 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 13 February 2018 - 09:16 PM

You are probably coming into the routine at 8ebc from one of the two jumps below, which presents a problem


8DF7  LD A,($80B2) 
8DFA  CP (HL) 
8DFB  JP Z,$8EBC  >>>> 
8DFF  CP (HL) 
8E00  JP Z,$8EBC >>>


I have a very small subroutine to handle the above type of tile check. It occurs elsewhere. The sole purpose of the routine is to leave HL alone.


But a quick method of doing the same as my sub routine is


          original                         change to


8DF7  LD A,($80B2)              Ld a,($80b2)
8DFA  CP (HL)                       cp (hl)
8DFB  JP Z,$8EBC  >>>>       jr z,$8e00


8DFD                                     inc hl 
8DFE  INC HL                        cp (hl)

8DFF  CP (HL)                      dec hl 
8E00  JP Z,$8EBC >>>          jp z,   Butt or $8ebc

#8946 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 13 February 2018 - 03:58 PM

Code at $8ebc


          change to             original

8EBC  call Butt               LD A,($85CF)
8EBF  ld a,($85CF)       ADD A,$10
8EC1                             AND $F0
8EC2   ADD A $10
8EC3                             LD ($85CF),A
8EC4  AND $F0
8EC6  call $8E99          CALL $8E9C  see the routine below
8EC9 LD A,$02
8ECB LD ($85D1),A
8ECE LD HL,$85D0
8ED1 RES 1,(HL)


; the call to this routine is moved to the point that "a" is saved

8E94 LD A,($85CF) 
8E97 ADD A,$08 
8E99 LD ($85CF),A          ; moved to call here
8E9C AND $F0                 ;<<<<<<<< original call point
8EA2 ADC A,$5C
8EA5 LD A,($85D3)
8EA8 AND $1F
8EAC LD ($85D3),HL


; a very vague Butt routine


        test if code is wanted, e.g. jump direction, headbutt flag

        return if not wanted
        else call Butt2
        inc hl


;all calls here return with hl intatct


       code to check where  hl is pointing

       return is not wall tile

      act on the headbutt 

      If tile graphics not cleared then return

      clear TILE from Master Attrib





Teaser:   The border bits are very wasteful. The bits 0-1-2 are the border colour and the rest of the byte is wasted. So I use 1 bit for setting the Butt to on or off. That still leaves 4 bits

With the room  fixed to 256 bytes in size,. Conveyors and ramps use

Ramp_dir                 1 byte

Ramp_position         2 bytes

Ramp_length           1 byte

Conveyor_dir           1 byte

Conveyor_position   2 bytes

Conveyor_length     1 byte

That is eight bytes to define these two actions


It is possible on variable room size (as I now have) to delete a lot of the fixed room data. The bytes that store the conveyor and ramp direction are now also stored in the border colour byte. In fact I have deleted all the ramp data and all the conveyor data from the room data. e.g. these eight bytes are reduced to the top two bits in the border flag...   


It uses a big chunk of code to restore these bytes but the code is part of a bigger piece of code. And the ramp/conveyor specific code (the bit dealing with replacing the data, deleted from the room) is no where near 100 bytes


Simple maths will show you why it is worth the effort of removing unwanted data.  Those 8 bytes are repeated 128 times, if using the old room storage method.( in a 128 room game) So the data contained would use 128*8 bytes of memory ( 1024 )  verses the 100 bytes of code


The above is an over simplification. 

#8937 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 09 February 2018 - 08:08 PM



Presumably the 'headbutt' code works in a similar way to the crumbly code, except that it's executed whenever #8EBC is CALLed, and it goes through the pixel-rows 'in reverse'?




Yes it is #8ebc. The code is crumbly floor in reverse. The majority of my code is concerned with checking that the wall tile can be deleted. I have now added a room specific flag. One of the unused border bits (bit 4) in my case. So rooms have head butting as an option via the border flag.(For now) This means only the one room left. And since that is in the original 60 rooms, it should be edited back to the original layout, and have the head butt option removed.


Tested out the full 128 room version. I have it up and running and can now wander around 128 rooms in a 48k Spectrum 


Don't expect any major changes, from other versions... I am testing other things, and I have never tested this to see how far you can get.

Attached Files

#8923 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 08 February 2018 - 09:14 AM

I notice that wall tiles can be headbutted away by Willy jumping sideways against them as well.  (EDIT: Sometimes, depending on what height Willy is in the jump when his head hits the wall tile.)




The wall tile disappearing is the result yet again of the ramp/stair code. So I used part of that code to stop downward detection and deletion of the tiles. The updated file is with the first file. E.g. Two posts ago.

#8915 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 07 February 2018 - 06:18 PM

Test this to see if you like the concept. Yes it my mega edited, must delete, what a mess piece of code.


120 room, bullets,and now headbutting



I have stopped the ability to head butt out of the top of the room. So the top row of wall tiles can not be headbutted away.


Removed the downward movement butt-ability.... That's the second file.


Added a blocking ability. This stops a wall being removed if over another type of tile. That's version 3
The Top Landing is the only room that I have edited to show this. (feature is in every room, but they are not edited)

Attached Files

#8913 Idea for a new cell type in Manic Miner

Posted by Norman Sword on 07 February 2018 - 04:50 PM

Do you need a new cell type?


Most of the lower, and the bottom row is impossible to head butt. If head butting from the room below they would reset anyway, after each room change.


The lazy option is to just enable in certain rooms the ability to head butt a wall tile from underneath. Would have been handy in the forgotten abbey, when the wall tile was accidentally left unchanged and made the room impossible.


If the only tile that can be head butted is a wall tile, and only from below, should be easy enough to design rooms to allow for that fact. 

A vertical wall that is inaccessible from below, still acts as a vertical wall, and is impossible to penetrate by head butting.



Very easy to do,,,, I have a version running now.

#8884 'Guardian Aura' Bug Fix and miscellaneous other patches

Posted by Norman Sword on 06 February 2018 - 08:16 PM

A flurry of posts whilst I sat with the above text in the editor.

  • IRF likes this

#8883 'Guardian Aura' Bug Fix and miscellaneous other patches

Posted by Norman Sword on 06 February 2018 - 08:09 PM

I have no problems with the code as listed here

I changed the ld a,(hl)     (twice)

;-----------------              CODE by IRF       -------------------------





    LD A,(#A3FF)                      ;offset for first key
    LD L,A
    LD H,#A4                             ;base of key list . full address now in HL

    LD A,(#8420)                       ;current room
    XOR (HL)                             ; xor comparison  
    AND #3f                               ; does it match after removing key position page and collection flag. Bits 6 and bit 7
    JR Z,match_found
    INC L                                   ;move to next key
    JR NZ,filter_loop                  ;keep going through list 


; If we get here, then we have been through all the item table entries, and there are no items (collected or uncollected) to consider in this room:

  LD A,#C9                               ;disable item drawing by overwriting code with a "ret"

    LD (#93D1),A                     ; disable/set the Item-drawing routine whilst Willy is in this room
    RET                                    ;finished


    LD A,L                                ; get the position in the list
    LD (#93D2),A                     ; and store offset .value used to initiate the item-drawing loop in this room

    INC L                                  ; wrap around is not a problem
    LD A,(#8420)                     ; the current room
    XOR (HL)                           ; comparison match
    AND #3F                            ;does it match after removing key position page and collection flag. Bits 6 and bit 7
    JR Z,find_last_item

; If we get here, then HL is pointing at the first item for the next room:
    LD A,L                               ;  get  the position in the list
    LD (#9452),A                    ; and store this offset. value used to terminate the item-drawing loop in this room

; Now restore the first byte of the Item-drawing routine:
    LD A,#21                           ;enable item drawing by replacing the LD HL,xxxx opcode
    jr  Pre_exit

  • IRF likes this

#8878 'Guardian Aura' Bug Fix and miscellaneous other patches

Posted by Norman Sword on 06 February 2018 - 04:04 PM

In the context that I have just written this and it is not tested.


As defined in Manic Miner 

HL Address of the crumbling floor tile
35770 LD C,L
35771 LD A,H
35772 ADD A,27
35774 OR 7
35776 LD B,A
35777 DEC B
35778 LD A,(BC)
35779 INC B
35780 LD (BC),A
35781 DEC B
35782 LD A,B
35783 AND 7
35785 JR NZ,35777
35787 XOR A
35788 LD (BC),A
35789 LD A,B
35790 ADD A,7
35792 LD B,A
35793 LD A,(BC)
35794 OR A
35795 RET NZ


ignoring the above, no help to me


; this code moves the tile in hl down by one line

    xor a
    ld d,a
    ld b,8
    ld e,(hl) ;the current line
    or d ;the line above
    ld (hl),d
    ld d,e
    inc h
    djnz loop

;  a=the accumalative value of the bits drawn


    or a    ;if a value exists then the floor is still collapsing

This permits a one pixel line to be moved down the screen

  • IRF likes this

#8873 'Guardian Aura' Bug Fix and miscellaneous other patches

Posted by Norman Sword on 06 February 2018 - 01:42 PM

Definitely a lot easier to write code and not edit a fixed piece of code.


Trying to write source code with proportionally spaced font is a challenge. The presentation leaves a lot to be desired. Then every time I do a cut and paste I am presented with a file that has most of the blank lines deleted. Hence the multitude of lines with a full stop , semi colon or some other marker. This is my attempt at trying to force inclusion of blank lines.....


I do wonder also why the internet has decided that tabs need replacing with a space (or even nothing). If I press tab, as I write this the cursor will disappear and I have no more typing output, until I click with the mouse on the screen. Is the input designed to remove the archaic tabs at source, and is it trying to educate me in the new world order. NO TABS ALLOWED. 

#8871 'Guardian Aura' Bug Fix and miscellaneous other patches

Posted by Norman Sword on 06 February 2018 - 01:08 PM

Revert (partialy) back to the original with the erroneous    LD A,L 


Using original source and I am listing what is needed (up to edit 2(now edit 3.5)) to extend the keys to enable 128 rooms. This is done without wasting a full 256 bytes of data, and uses very little to accomplish this.

This method gets around the key reset at game start up (no code change). It also has no need to calculate the total keys (the value is as before)

AT NEW ROOM set up


;use  $A3ff for the lower key OFFSET e.g this value is the numbers of keys in total. as before
; use  $A3fe for the upper key, this value holds the start of keys for rooms 64 upward
; storage of keys is laid out as follows

;from the value of ($a3ff) up to ($a3fe) the lower room keys
; from the value in ($a3fe) up to $ff the keys for rooms 64 to 128


new code to implement change

      ld bc,($a3fe)


; c=upper key pointer   ; Changed from what I originally wrote
; b=lower key pointer

    JR z,lower_set
    ld b,c ;set b=upper key offset
    ld c,0 ;set limit=0 to stop search
    ld a,b  ;this is the start of search
    ld ($93d2),a ;set the new base for search
    ld a,c
    ld ($9452),a ; set the upper limit of search


;The above sets up the key collect routine


modification to the key collect routine
address old code        replace with
93D1 ld h,#A4             ld hl,#A4ff  << LS of hl modified
93d3 ld a,($A3ff)
93d4                             nop
93d5                             nop

93d6 ld l,a                    nop         << remove this as well


(ironic that the LD a,L was ommited at the end and ommited for deletion at the beginning)
93E0 JR NZ,$9452       JR NZ,$944F  <<< THREE BYTES EARLIER
942E JR $9452            JR $944F  << THREE BYTES EARLIER

943E lD A,(HL)             LD A,D      ; 
943F RLCA                  RLCA
9440 RLCA                  RLCA
9441 RLCA                  RLCA
9442 RLCA                  AND #08
9443 AND #8
9444                            ADD A, #60
9445 ADD A,#60
9446                           LD D,A
9447 LD D,A               PUSH HL
9448 PUSH HL            LD HL, #80E1
9449 LD HL,#80E1
944B                           CALL #9699  ;call address is 2 bytes earlier
944C LD B,#8
944E CALL #969B      POP HL
                                   ;new branch to here
944F                           INC L
9450                           LD A,L
9451 POP HL             CP #00
; old branch to here
9452 INC L
9453 JR NZ,93D7       JR NZ, #93D7    ;UNCHANGED
9456 RET                   RET                  ;UNCHANGED


keys are stored in this fashion
START                      OFFSET IN $A3FF                        OFFSET IN $A3FE         THE 255TH ENTRY
OFFSET 0                 v                                                    v                                      v
0,0,0,0,0,0.....,0,0,0,0,L,L,L,L,L.....,L,L,L,L,L,L,L,L,L,L,L,H,H,H,H ......,H,H,H,H,H,H,H