Norman Sword

This is a modified version of Matthews Manic Miner. The core code has been edited extensively. All data was left intact from #b000 onwards, but is modified at run time to swap between the Bug-byte version and the Software projects version of Manic Miner. The list of changes is very long. Most of these changes are not evident, some are very evident. keys 1) change the style of jumping and movement after cheat invoke 4) Immortality 3) Platform rebuild - when invoked the "9" key rebuilds the platforms Holding down the "9" key and pressing 1) move back a cavern 2) move forward a cavern BB-SP.tap

The CPC Amstrad has extensive firmware jump blocks to control most of its operations. The firmware was left intact on manic miner for the 464. This was in the era when the CPC did not have Disc drives. One of the calls to the firmware jump block is the request to implement a user vectored interrupt. The firm ware has the ability to permit 6 interrupts per frame. Any of the 6 interrupts can be chosen. The interrupt SHOULD occur at the same place every time, and this was used to change the screen colours twice every frame loop. The Interrupt chosen changes the colours for the lower part of the screen, another interrupt puts he colours back for the playing area. Thus in a normal room there can be six colours. Four in the playing area. Four for the lower screen, and two which are common for both the upper and lower portions of the screen. Giving a room six colours in the mode 1 four colour mode. Every so often the CPC firmware gets the values wrong with the result of the colours being changed at the wrong moment. As far as I am aware this is a problem caused by the amstrads CPC firmware.

The code listed at the end of Jet set willy is the Tandy operating system. Used by the recent hard drive Matthew had bought. The hard drive overlays the top of ram for its operating system. The floppy disc uses another area of Ram. The method Matthew used to handshake the two computers has nothing to do with any of the code seen in that area. The handshaking was done using the parallel printer cable on the Tandy which was handshaked with a board build by Matthew that sat on the back of the spectrum. The board was built using wire wrap and multiple 74LS chips. The software used implemented a primitive source to destination block move. e.g. the source and the destinations address would be the same on both the Tandy and the Spectrum. The hard drive is the reason the extra four rooms, which would have sat at the top of memory, are missing from the game. Since Manic Miner has data in that area, it is apparent that Matthew bought the hard drive between development of Manic Miner and Jet set willy.

; THE GAME CLOCK ;original 35389 LD A,(32957) :GAME CLOCK 35391 SUB 4 35393 LD (32957),A 35396 CP -4 35398 JR NZ,35413 35400 LD A,(32956) ;AIR SUPPLY 35403 CP 36 35405 RET Z 35406 DEC A 35407 LD (32956),A 35410 LD A,(32957) 35413 AND 224 ;change to 35389 LD A,(32957) 35391 SUB 4 ; Now becomes possible to change (not recommended) 35393 LD (32957),A 35396 nop ;<<<< poke 35396,00 35397 nop ;<<<< poke 35397,00 35398 jr nc,35413 ;<<<< poke 35398,48 35400 LD A,(32956) 35403 CP 36 35405 RET Z 35406 DEC A 35407 LD (32956),A 35410 LD A,(32957) 35413 AND 224 ; this will remove the restriction on having the game clock ; fixed to 4,8,12,16,etc ; any value will now work ; as far as I can see no routine uses the bottom two bits ; horizontal guardians use the toggling of bit 2 - so unused bit 0-1 ; Eugene uses the value/4 for colour - so unused bit 0-1 ; Kong beast uses the value/32 - again unused bit 0-1 ; I can find no usage for the lower two bits ; for example if the value of SUB 4 is change to say sub 2 the game will still run ; the (slow) horizontal sprites will become jerky ; the value can be changed to SUB 1, the (slow) sprites will become even jerkier, but the game will still run ; this change (not recommended) also changes the decrease in air supply speed. ; SUB 1 gives you four times as long in a cavern, and big points when it is finished ; Of course this type of change also affects the animation of Kong and the colour change in Eugene, ;both of which are cosmetic ;--------------------------------- ; More on the value in game clock. ; The game uses two routines to draw the air supply ; the first routine (R1) draws the full bytes remaining, and is drawn on entry to a cavern ; ; The second routine (R2)(which is the one part listed at the top of this comment) ; is concerned with the drawing of the part byte (bits) at the end of the air supply ; this routine erases the air bar as it draws, and for most values that are multiples of 4 no ; problem will be encountered. ; ; However if on the first pass after initialisation, if it ecounters a "0" then this routine (R2) will ; immediatly move the air supply position left one byte. This will result in the initial drawing ; having a glitch, at the end of the air supply graphic. Due to the last portion being un-erased ; ; Any initial values that are not multiples of 4 will also hang the game on finishing a cavern ; Plus the air supply will remain cycling on the end of the air supply bar ; ; ; AFTER MODS-- ; ; first pass after initialisation (GAME CLOCK) ; This byte can now hold any value, that does not set the carry on the first pass after initialisation ; Since the carry will be set for values of 0,1,2 and 3 they should be avoided. ; This is because on the first pass, the routine (R2) will immediately move the whole byte counter left by one byte. ; This will leave the graphic at the end of the air supply un-deleted. (a cosmetic glitch) ; ; No other value should cause a problem, because the restriction of being a multiple of 4 will have been removed. ; In summary, modify with three pokes.. Any value bar (0,1,2,3) for the Game counter

Shifting the room base ld a,(room_num) or 0c0h ld h,a ld l,0 looking at #c0 in binary we have 11000000b, notice the lower six bits are free. The room number is between 0 and 63 or 00000000b and 00111111b, note the top two bits are not used when the two valued are or'd together the composite value is the addition of the two values. if you want to move the base value then add it ld a,(room_num) add a,#b5 ld h,a ld l,0

In Matthews game there exists lots of clear logic flaws. Something that is missed, Probably because you are so busy worrying about the spelling of some room name. I will let you get on with it... By the time you work out That ex hl,de is not an opcode you will be celebrating the groups 100th birthday

Another needless quote. You are clueless and still you quote.... Yes you have totally pissed me off

You are prattling again... You squash one byte from a routine and stand back amazed. I rewrite the routine and you start the needless quotes on he did this someone else did that. For what ultimate point You are fiddling whilst I am doing what is needed.

The version I have running has multiple title screens It has collapsing floors It has walls/floors that move It has multiple tunes It has as stated before 102 rooms This was achieved by multiple optimisations throughout the code All done in the space of four weeks.... This group has done what???? Apart from needless quotes, being obsessive over trivia. Not a lot

You are quoting thing just for the sake of quoting. It does not illustrate anything.

without quoting others who have posted posting on this topic JSW2:- General ignorance posted by this group concerning this game. JSW2 does not compress any of its code., and does not run with compressed code. On the other hand JSW runs with compressed data. the same as JSW2 Your scope of ignorance on this subject is why as a group you miss the bigger picture. You are spending so much time on trivia, so much time on conjecture. No one knows what Matthew might or meant to achieve. Because he defined graphics does not indicate he was definitely going to use them. Conjecture on your part.

My code permits me to re write Matthews game in as small a space as possible. I have running in 48k a version of his code with 102 rooms that runs faster. What has your byte by pedantic byte achieved?

What is the point in this statement. You could have done this and didn't, anyone could have done it and didn't. Your statement is pointless.

;In the above I mentioned the conveyor animation org 38137 ;animate conveyor :skoolkit comments L38137 LD HL,(32983) z38140 LD A,H z38141 AND 1 z38143 RLCA z38144 RLCA z38145 RLCA z38146 ADD A,high (7000h) ;112 z38148 LD H,A z38149 LD E,L z38150 LD D,H z38151 LD A,(32985) ;Pick up the length of the conveyor from 32985 z38154 OR A ;Is there a conveyor in the room? z38155 RET Z ;Return if not z38156 LD B,A ;B will count the conveyor tiles ;>added ;>code from here is moved INC H INC H ;point hl to third graphic row z38157 LD A,(32982) ;Pick up the direction of the conveyor from 32982 (0=left, 1=right) z38160 OR A ;Is the conveyor moving right? ;>changed ;z38161 JR NZ,L38182 Jump if so jr,z,L38163 ;** changed from the incorrect L38316 :>added ex de,hl ;The conveyor is moving left. (or right) L38163 LD A,(DE) ; Copy a pixel row of the conveyor tile to A z38164 RLC A ;Rotate it left twice z38166 RLC A ;>deleted ;z38168 INC H ;z38169 INC H z38170 LD C,(HL) ;Copy this pixel row to C z38171 RRC C ;Rotate it right twice z38173 RRC C L38175 LD (DE),A ;Update the first and third pixel rows of every conveyor tile in the screen buffer at 28672 z38176 LD (HL),C z38177 INC L z38178 INC E z38179 DJNZ L38175 z38181 RET ;The 1 added instruction and slight change in logic flow ;removes the need for the code below 9 bytes shorter ;>deleted ;The conveyor is moving right. ;L38182 LD A,(HL) Copy the first pixel row of the conveyor tile to A ;z38183 RRC A Rotate it right twice ;z38185 RRC A ;z38187 INC H Point HL at the third pixel row of the conveyor tile ;z38188 INC H ;z38189 LD C,(HL) Copy this pixel row to C ;z38190 RLC C Rotate it left twice ;z38192 RLC C ;z38194 JR 38175 Jump back to update the first and third pixel rows of every conveyor tile ;------------------------------------------------------------------------------------------------- ;

The number of posts means I have not read most of them. This routine expands the graphics as a room is entered ROOM ATTRIBUTE FIX and SPACE SAVER org 8d33h ; start is 8d33h 36147 ; end of this is around 8da6h 36262 (lower since mods) ; end of Matthews code 8dd2h 36306 ; size is less than 115 bytes saves 44+ bytes L5E00h equ 5E00H ;ROOM ATTRIBUTES L7000h equ 7000h convey_len equ 80d9h convey_add equ 80d7h Ramp_len equ 80Ddh Ramp_add equ 80dBh Ramp_dir equ 90Dah Back_Tile equ 80a0h Char_print equ 9699h ;969bh in my assembler wrong address given (label was moved) ; note **** ; This routine uses only one call ; NO repeated push/pop due to poor register allocation. (in one example I have seen) ; 100% elimination of all attribute cell block drawing effects ; permits multiple graphic definition with the same colour (attribute) ** ; ** Matthews code will still give stair/ramps ramp/stairs stair/floor etc ; ; saves around 44+ bytes Draw_Room ld de,8000h ;room definition ld HL,L5E00h ;5e00h the room attributes EXPANSION ld b,4 ;four cells per byte ld a,(DE) exp rlca rlca ld c,a ;temp save "a" and 3 ; values 00b,01b,10b,11b (types) ld (hl),a ; write the type into the cell ld a,c ;restore "a" inc l djnz exp ; repeat for the byte (4 cells) inc de jr nz,EXPANSION ; first 256 done inc h ; this second check is done twice in the 512 loop bit 5,h jr z,EXPANSION ; part 1a) add conveyor tiles (if any). LD A,(convey_len) OR A JR Z,No_Conveyor LD HL,(convey_add) LD B,A convey_set LD (HL),5 ; write TYPE 5 =CONVEYOR into this cell INC L ; The conveyor animation routine also does inc l/inc e DJNZ convey_set ;part 1b) add ramp tiles (if any) No_Conveyor LD A,(Ramp_len) ; the only reference to this data in the whole program OR A JR Z,DRAW_TILES ld b,a LD HL,(Ramp_add) ; LD A,(Ramp_dir) ; LD DE,-33 ;primary change here is for clarity OR A JR Z,Ramp_set INC E INC E Ramp_set LD (HL),4 ;write TYPE 4=RAMP into this cell ; this does not check for screen bounds (or ramp length) ADD HL,DE DJNZ Ramp_set ; ; NOW EXPAND AND OVERWRITE/DELETE THIS DATA ;L5E00H holds the TYPES in each cell THIS WILL BE OVERWRITTEN BY THE TYPES attribute from its definition ; THE GRAPHICS WILL ALSO BE EXPANDED TO THE COPY SCREEN ;part 2) expand the room definition into a graphic and attribute definition DRAW_TILES ld ix,L5E00h ;start of the TYPE DATA:- CHANGED as each one is read TO COLOUR DATA ld de,7000h ;graphic buffer where the graphics will be drawn loop ld a,(ix) ;get THE TYPE from its cell LD B,A ;calculate the graphic (tile) ADD A,A ADD A,A ADD A,A ADD A,B ; 9 bytes per graphic entry LD HL,Back_Tile LD C,A LD B,0 ADD hl,bc ; the first byte is the graphic (tile) colour ld a,(hl) ; the TILES colour attribute ld (ix),a ; overwrite its type in the attribute buffer with the graphic attribute INC IX ; next source (attributes/type/cell) inc hl ; move from graphics attribute to the graphics definition ld c,d ; temp save d call Char_print ; (what the routine at char_print does) ;char_print ; ld b,8 ;draw_me ; ld a,(hl) ; ld (de),a ; inc hl ; inc d ; djnz draw_me ; ret ; calculate the next char ld a,d ;save modified d ld d,c ;restore d inc e jr nz,loop ld d,a ;reload the modified d cp high(L7000h+1000h) ; 80h defined this way for clarity jr nz,loop ret

Spectacular crash when I tried modifying the xor a. This code is shorter and fixes the problem. I have to admit I do not like the additional Jr inserted into the main loop to overcome this small change. (XOR A changed to LD A,4) In loops of this nature, each change in flow is repeated and repeated. So just this one small change is the equivalent of inserting 255 1 byte opcodes. In itself not a visible factor in JSW's speed. but slowdown is accumulative. org #89FB LD HL, 05C00H LD DE, 05800H EXX LD A, #04 ld HL, 08200H loop ld e,(hl) inc l push hl ld d,(hl) ld l,e ld h,d res 5,d ld bc,32 ldir pop hl inc a and 7 jr nz not_attrib exx ld bc,32 ldir exx not_attrib inc L JR nz,loop

The delay before attribute update, is a swings and roundabout affair. Update before the graphics are updated and then the arrows will be in their old position and have their colours shifted , Update after and the reverse happens. Update in the middle and you might introduce another effect. When I wrote the code I was aware that the original "xor a" could be changed to permit the attribute copying to be set to anywhere needed. You have include the Jr at the bottom in the size of the code- which is missing from yours. The speed of execution will be faster overall for mine, because the attribute calculations are not needed in each attribute copy. The overhead then is exx 4 t-states - copy attribute ld bc,32-ldir exx 4 t-states 8 dec l 4 t states 12 inc l 4 t states 16 which is 4 sets of 4 Tstate operations ... 16 in total yours PUSH HL 10 t-states 10 LD D, #58 7 t states 17 SLA E 8 25 LD L, E 4 29 JR NC, #01 7/12 36 41 INC D 4 40 45 LD H, D 4 44 49 SET 2, H 7 51 55 copy attribute ld bc,32-ldir POP HL 10 61 66 the extra overheads are 61+ Tstates- So mine is faster and smaller. (but this is not a contest)

When the subject of updating the attributes at the same time was mentioned. I jotted down the code below. The +code is the code added to do the attributes at the same time. org 35317 35317 LD HL,05C00H ; +3 LD DE,05800H ; +6 EXX : +7 XOR A ; +8 ld hl,08200H ;3 loop ld e,(hl) ;4 inc l ;5 push hl ;6 ld d,(hl) ;7 ld l,e ;8 ld h,d ;9 res 5,d ;11 ld bc,32 ;14 ldir ;16 pop hl ;17 inc l ;18 inc a ; +9 ;** extra over head 1 and 7 ; +11 ;** extra overhead 2 jr nz loop ; +13 exx ; +14 ld bc,32 ; +17 ldir ; +19 exx ; +20 dec l ; +21 inc l : +22 jr nz,loop ;20 ;---------------------------- ld a,(34271) ;23 ; this code is moved down in memory and 2 ;25 rrca ;26 ld hl,34258 ;29 or (hl) ;30 ld (hl),a ;31 jr 35377 ;33 my main concern was that this loop is executed 128 times per game loop. Which makes any checking done, needs to not introduce too much overhead. The extra overhead needed on (128-16) lines of code. (the extra code lines that are executed but do not result in anything extra being done) is a mere two instructions (indicated by **) The other 16 times through the loop handle copying the atrributes.

And with the above comment, I will no longer elaborate. because your statement is so very wrong. starting at the top the screen updates -- Physical scan line update raster line 00 - screen char 0 line 0 an ldir will update 0 raster line 01 - screen char 0 line 1 8 raster line 02 - screen char 0 line 2 16 raster line 03 - screen char 0 line 3 24 raster line 04,- screen char 0 line 4 32 raster line 05 - screen char 0 line 5 40 raster line 06 - screen char 0 line 6 48 raster line 07 - screen char 0 line 7 56 raster line 08 - screen char 1 line 0 1 raster line 09,- screen char 1 line 1 9 raster line 10 - screen char 1 line 2 17 raster line 11 - screen char 1 line 3 25 raster line 12 - screen char 1 line 4 33 raster line 13 - screen char 1 line 5 41 raster line 14,- screen char 1 line 6 49 raster line 15 - screen char 1 line 7 57 raster line 16 - screen char 2 line 0 2 raster line 17 - screen char 2 line 1 10 raster line 18 - screen char 2 line 2 18 raster line 19,- screen char 2 line 3 26 etc The above is not the layout as it crosses the 1/3 boundaries the raster refresh can/does/will be overtaken by the LDIR.. This is basic in the principle of screen updates.

I will agree with your sprite drawing layout. (hence the title I used Jagged finger look) Below is a quick mock up of the effect. On the left the red square is moving to be in the position of the black underlying square. During screen refresh the screen is being updated from displaying the red square and now needs to display the black square. During the screen refresh the raster overtakes the block move LDIR and we end up with the composite of the red plus the black square- the jagged finger outline on the right. This effect will change from frame to frame and position to position. This is the flicker that follows the sprites around. (depending on how fast they move and in what direction and where the raster is when it is overtaken) I was surprised that Matthew implemented a "Y-table" of offsets then chose to ignore the table when it came to the task of screen copying. The overhead (speed reduction) is very, very small.

The effect is hardware induced/ via Ldir and the screen layout. You are asking me what effect an emulator has on a spectrum's hardware.... I have no idea how it enhances/masks this problem etc

Sorry I forgot to add the code that should be changed in order to fix the LDIR problem ;Matthews ldir ;this is compromised by the copy being overtaken ; by the physical screen updates ; once noticed this defect is hard to ignore 35317 LD HL,24576 ;3 35320 LD DE,16384 ;6 35323 LD BC,4096 ;9 35326 LDIR ;11 35328 LD A,(34271) ;14 35331 AND 2 ;16 35333 RRCA ;17 35334 LD HL,34258) ;20 35337 OR (HL) ;21 35338 LD (HL),A ;22 35339 LD A,(34253) ;25 35342 OR A ;26 35343 JR Z,35366 ;28 ;unused portion of code 35345 DEC A ;29 35346 LD (34253),A ;32 35349 RLCA ;33 35350 RLCA ;34 35351 RLCA ;35 35352 AND 56 ;37 35354 LD HL,23552 ;40 35357 LD DE,23553 ;43 35360 LD BC,511 ;46 35363 LD (HL),A ;47 35364 LDIR ;49 ; change the code above to the code below. ; This routine does a raster style copy. org 35317 35317 ld hl,#8200 ;3 loop ld e,(hl) ;4 inc l ;5 push hl ;6 ld d,(hl) ;7 ld l,e ;8 ld h,d ;9 res 5,d ;11 ld bc,32 ;14 ldir ;16 pop hl ;17 inc l ;18 jr nz,loop ;20 ; for the raster screen copy ;---------------------------- ld a,(34271) ;23 ; this code is moved down in memory and 2 ;25 rrca ;26 ld hl,34258 ;29 or (hl) ;30 ld (hl),a ;31 jr 35366 ;33 ; 5 bytes bigger ;16 unused bytes <here>

I am not going to spend my time elaborating on spectrum hardware.

File downloads and runs on FUSE. (file was originally saved from fuse. Since the only purpose was to illustrate a problem in the screen copying. I have captured some screen shots that show what the problem looks like. This problem is mainly removed by a raster copy.

JSW jagged finger effect (demo) View File In both Manic Miner and Jet Set Willy the screen is copied by a simple LDIR. This simple copy does also have one simple flaw. The look of this flaw can best be described by a jagged finger look. When a sprite is moving the LDIR screen update of the sprite is sometimes overtaken by the physical raster update. This is what causes the break up flicker of Willy as he moves around the screen. The breakup is dependent on the movement of the sprite and thus what part is being updated. E.g. the breakup is dependent on the difference between the old and new position of a sprite as the screen is updated. If Willy is static then no breakup will occur. The most noticeable breakup will occur when willy move diagonally up or down stairs. The screen is physically updated from top to bottom, one raster line after the other. The LDIR instruction just copies one block of ram from one place to another and this copy does not follow the raster layout of the screen. I have modified an original version of Jet Set Willy to have two distinct copy routines. These two copy routines alternate between a simple LDIR and a proper raster screen copy. In this demo version (which will have problems with the end game due to the nature of the modification) the screen will alternate between the two differing methods of screen update 1) when the time ends in an odd number the screen will update with LDIR. 2) when the time is even the screen will update using a simple raster copy routine. This demo is not stable and I do not know how long it will work till problems occur. Its purpose is to demonstrate a problem. Submitter Norman Sword Submitted 03/29/2017 Category Other resources