Norman Sword

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