Norman Sword

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  

One observation from the loader routine. The stack is situated at 63796: the program loads from 16384 (#4000) and loads in 47416 bytes. This means all data in memory from 16384 to 63800 is overwritten....This has two consequences.. 1) the code you are reading is overwritten by the loader. Thus the lines jp nc, 0 jp 36864 will not exist when the program is loaded 2) the return address from the loader is pushed onto the stack. The stack is overwritten so after the program has loaded, it will not return to the routine that called it. The return address is written by the code that is loaded. The above proved enough protection, that further duplication (MASTER TAPE) resorted to a snapshot loader

Chronology of JSW2+ . As far as I am aware there have been 4 releases of JSW2+ original listing scanned 14th October Two prototypes testing ideas, which could not be finnished. (which have been deleted) Then the J Wiseman version 12th November 2016 This was changed and developed further up until the end of 2016. Cutoff point for all development was 31st December 2016 The Final version was Ve22 and released on Facebook on the 10th January 2017. I will seek more information on chronology/development. (this may take some time)

In JSW2+e.22 To complete the game it is necessary if collecting all the items for Willy to be killed only once. The Glitch rooms are accessed by killing Willy, the life will be given back due to the number of objects collected in those four rooms. There is no need to kill Willy in any other place. The exit from "water supply" does not need a suicide jump. The rope that permits exit, cycles and after a short wait will re-appear.

View File JSW+ Ve22 rv1 The last update of JSW2+. This version was written to correct escaping the "Off licence" in the final game sequence. Submitter Norman Sword Submitted 03/08/2017 Category Jet Set Willy [Remakes]  

The Julian Wiseman site contains a version of JSW2+ that as mentioned in comments somewhere. Contains a problem with being able to escape from the "Off licence" in the end game sequence. As a result of that problem, it was decided to continue the development of the game. The final version is version +E22. Which has around 298 objects to collect, and 145 rooms. In version +e22 the game starts with the title loader screen from JSW2. The game was edited up to the end of 2016. And every version was just a test platform, to see how much could be added to a standard 48k spectrum. Posted the latest version +ve22 on this website in downloads Jet Set Willy And Manic Miner Community ? Downloads ? Jet Set Willy ? Jet Set Willy [Third Party] ? JSW+ Ve22 rv1