Norman Sword

This is also probably the bug the lets Willy move into the floor/wall tile when jumping right into the wall gap (next to the priest) in the "First Landing" . Again the check for beneath his feet incorrectly checks the tiles beneath his feet and not the tiles his feet are about to land on. Like so many other parts of the code, other checks can/could prevent this.

What Logic dictates and what actually happens. . . The black squares represent wall tiles . . Left block diagram: part 1: willy occupies the red squares and is trying to move upward and left. All checks to the left indicate that the two blues squares are free but the lower square contains a wall (black square). movement left is blocked. Movement vertically is free. So willy moves upward. . . Middle block diagram: Part 2: willy at this point is cell aligned and still moving upward and left. The orange squares are checked and found to be free. Willy is moved left and upward into the squares. . The arc of his flight moves onward till we arrive at picture 3 Right block diagram: Part 3: willy is cell aligned and wants to move left and downward. The question here is are the cells/squares in green free to move into. The answer being yes. Willy should be moved across the cell boundary into the green squares. . But in part 3 JSW has a specific check, that affects the outcome:- Willy is falling and the code (listed) below checks for what is beneath his feet. Even though at this point willy will not actually enter both of the squares that are checked below his feet. Willy is moving diagonally downward, and he moves both vertically and horizontally across cell boundaries. The check below does not move horizontally across the cell boundary and checks directly beneath Willies feet. (this is a bug) . *** Note the problem is due to incorrect horizontal cell checking. . This incorrect cell check, stops the jump and Willy lands on the wall. . The complete Jet Set Willy RAM disassembly 20171113

The room jump routines -- about 40 bytes shorter ROOM_L EQU $80E9 ROOM_R EQU $80EA ROOM_U EQU $80EB ROOM_D EQU $80EC CURRENT_ROOM EQU $8420 WILLY_Y EQU $85CF AIRBORNE EQU $85D1 ;ANIMATION EQU $85D2 WILLY_ATT EQU $85D3 WILLY_ATT_H EQU $85D4 NEW_ROOM EQU $8912 ;---------------------------------------------- GO_ROOM_LEFT: ;L948A LD BC,$FE1E ;;; OR LD BC $E01E LD HL,ROOM_L GO_NEW_ROOM: LD A,(HL) LD (CURRENT_ROOM),A LD HL,WILLY_ATT LD A,(HL) AND B OR C LD (HL),A ;L85D3 POP HL ; JP NEW_ROOM ;L8912 GO_ROOM_RIGHT: ;L949E LD BC,$E000 LD HL,ROOM_R JR GO_NEW_ROOM GO_ROOM_UP: ;L94B0 LD BC,$1FA0 LD HL,ROOM_U LD DE,$D05D XOR A VERT_PROCESS: LD (AIRBORNE),A LD A,E LD (WILLY_ATT_H),A LD A,D LD (WILLY_Y),A JR GO_NEW_ROOM GO_ROOM_DOWN ;L94D2 LD BC,$1F00 LD HL,ROOM_D LD DE,$005C LD A,(AIRBORNE) CP $0B JR NC,VERT_PROCESS LD A,$02 JR VERT_PROCESS Slight edit to set up variables in a more consistent manner.

The visual differences between the bug byte version and Software projects version in room data The changed data consists of around 240 bytes changed. in 12 separate groups. Ranging from a single byte to a group of 127. Some of the data that changes may or may not be visual. But the program stores the around 480 bytes and swaps the 240 over on each playing. This is on top of the 2*256 bytes for the scrolling message. So Nearly 1k stored for the changes. The room data was left intact, and in the same format. I did consider adding a few more versions and the compressing the lot.

Posted elsewhere on this forum, just moving into the download category as well. This version of Manic Miner contains both the Software projects version of the game alongside the Bug byte version. Each time the game is played it will swap versions. I have edited and revised a lot of the routines. The game should play the same way as the original game. A lot of the changes would need you to be aware of the originals exact format to enable comparisons. Cheat is enabled (bug-byte password) differences that I can remember 1) demo cycle stops and redisplayed the title screen and replays the title music 2) added a credits screen 3) added explosions on credit screen 4) added intermission screen 5) change scroll to pixel scroll and not character scroll 6) will moves with a sprite mask 7) explosion on death 8) willies death stump scrolls onto the screen 9) score scrolls to high score 10) reason given for demise 11) sound effects on solar ray 12) collection sound 13) cheat modes rebuild platforms 14) cheat mode immunity 15) cheat mode move by a single key, and not multi combinations of keys 16) cheat mode plays with all sprites active 17) game swaps between two versions- Bug Byte and software Projects 18) other sound effects 19) less sprite flicker 20) game runs faster 21) multiple icon displays 22) bar graph on title screen 23) Animated version icon on title screen 24) keyboard layout on title screen fixed 24a) title screen. missing pixel on car replaced 25) new screen scrolls 26) easter egg on Credit screen 27) easter egg on Pause 28) skylab landing sound effect 29) skylab does not colour in platforms etc... KEYS standard movement keys e.g. "q" to "p" for left to right "z" to "m" jump" "a" to "g" pause "h to "enter" music on/off The "1" key changes the method of movement. In cheat mode. the boot will still be displayed various icons are active and indicate options selected The "9" key rebuilds platforms the "3" key activates platform rebuild option (tool kit) the "4" key activates immortality (medical kit) The "9" key held plus Tapping "1" will move to a previous screen. If on room 1 then it will go to room 20 The "9" key held plus tapping "2" will move to the next screen. If on room 20 then it will go to room 1 Bug byte cheat is 6031769 Icons displayed are from right to left Paused Alternate movement Music on Cheat invoked medical kit tool kit BB-SP.tap

Just a note on the file I posted: What is happening? In the original JSW, the code for jumping and moving up and down ramps, are set in one overall routine that detects wall blocks and stops movement. Within the code of the original, was two sets of movement code that treated the movement going left and the movement going right differently. Moving left. The code for moving left omitted a check for head height blocks. This permits willies head to pass through blocks moving left. This also permits willies head to pass through blocks at head height when jumping. Another routine at #8df7 detects the passage through the block at head height and immediately pushes willy downward to cell align him into/onto the block below. In most cases this works well if willy is going upwards on a jump. If willy is going downwards on a jumping arc, then the code at #8df7 will appear to move willy suddenly downward. This is the characteristic jerk as willy hits a wall and slides down it into a gap. Moving right This code blocks the movement of willies head through a wall tile. The result is that willy can not jump into slots cut out of walls in the same manner. Because willies body and head do not enter in a wall tile, willy will slide down walls at a normal speed, until his feet land on something. consequence. The slight difference in the movement is why the game has cut outs in vertical walls only in left jumped to walls. The same style cut out that exist in right cut out walls normally have a platform below the cut out, on which willy can land. It also is the reason for the jerk jumping left in certain circumstances that are not replicated going right. Fixs Various fixs can be applied and each fix might cure one or other problem. 1) stop willies head passing through a block. This fix will stop the jumps into cut outs. 2) allow willies head to pass through a block going right. This fix will enable jumps left and right into cut outs. But willy will pass through so many blocks it just looks wrong. 3) rewrite the lot. This introduces so many new variables, that anything can happen. My thoughts on that are GOOD LUCK. DEMO The demo program posted above changes its set of rules depending on what is happening. 1) If willy is walking up or down a ramp then it will check for willies head/body/above head(going up)/below head (going down). When jumping the rules are changed. When jumping upward it checks above his head, his head and also his body. If not cell aligned it will check the third cell (lower body/under foot) 2) When jumping downward it ignores the head check and checks for his body and if free to move also checks the cell below his body (under foot). This double check for body and lower body/under foot is needed to ensure that willy is actually passing into a gap in which he can fit. (two cells high) If the two cells are free then the code permits willies head to pass through a wall block. The code at #8df7 will detect the passage through a wall block and immediately pull willy downwards into the gap. This is what happens in the original game. The only difference in this demo is that it now happens going left or right, but willies head is blocked from passing into wall blocks when walking, walking on ramps, or even jumping upward. Any modification will invariably introduce new problems. Simply because the original game appears to have been constructed around the non symmetry of code. Some of these problems are very easy to fix others are waiting to come to light. ADDENDUM Most of the labels I have in this area have been moved/change/deleted . I have had to use an unchanged version, to find the address I am referencing. Over head wall check, that push's willy downward , as written by The complete Jet Set Willy RAM disassembly 2017 11 13

Meanwhile :- something I wrote last week. ------ Which is an extension of my test files Not meant to be complete or working game. Just a test extension of matt's logic. Which also had tile blocking incorporated. The very jerky jumps, means the jumps happen a lot quicker than the nice smooth arcs of what the jumps should have been. Since the source code for this contains so many obsolete routines. It will probably be soon deleted/purged. jerky set wibble .tap

A viewpoint (which might change) based on code written today. The previous code and several other bits that modify the path that willy can take still have problems. I wrote a routine that shows in real time what tiles are being checked by this program. (allowing frame by frame analysis). What this routine showed was, that the checking has flaws in its design. The original routine was not symmetrical, and it was the non symmetry that allowed for jumping into gaps in walls. (In jsw all the gaps are accessed by jumping left) If symmetry is introduced then those gap jumps become impossible. But the other problems become more noticeable. Passing through a wall In the code that checks for ramps and also checks for blocking the move left and right, was a check for reducing the three cell check to only two, when willy was cell aligned. The primary reason was when willy walks along a platform, the third cell was below his feet. Since he was walking along the top of the cells, they could not block his path. Hence the third cell check is removed for that reason. (otherwise willy can not walk along a wall) However when willy is jumping the third cell is crucial for deciding if willy can move. g00a h00b kcde In the text diagram above willy occupies the four squares with "0" in them, in this case willy is jumping right and is on his way down. The two squares with "a" and "b" are clear. Since willy in this thought experiment is now cell aligned. The present routine has decided that "e" can be ignored. This then permits willy to move diagonally downward to the right to now occupy the cell "e". This is why the jump right on the "FIRST LANDING" passes through a square and lands inside the floor when jumping the gap on the lower floor. If I add a check for falling into the routine that checks for wall blocking when moving. The purpose of which is solely to force the third cell check when falling. Then this particular problem disappears. However it still permits passing though a wall block in "on top of the house" when walking down a stair (because those blocks are NOT checked by the stair check routine) Symmetry The third cell check stops one problem. But Symmetry causes a problem when jumping into gaps. Again looking at the text diagram, the cell "g" was not tested moving left, and that permitted walking through cells at head height. The cell "a" was tested when walking right. It is the lack of cell testing that permits jumping into wall gaps, when jumping left. The symmetrical code I posted will not permit jumping into two cell wide gaps in specific conditions because of the extra check. The jump left in "ball room east" into the gap above the red barrel can no longer be done. The reason is because the checking now stop movement into wall tiles. The gap was only two cells wide only when cell aligned. This does not happen when jumping from a horizontal position (which is level with the gap), because the forward motion has ceased at the exact point that the cells are aligned. From my viewpoint the non symmetry was deliberate, and in looking at the way the code is written, it is possible the change in logic from left and right was a quirk that was exploited I however prefer these anomalies to be written out of the code. Whatever it does one way should be the same the other way. Back to the cell checking.. Introducing a specific check for jumping (downward) to force a third square check, stops the movement into wall cells on jumping downward. It also appears that stopping the check for willies head when jumping and moving downward either left or right. Re-enables the passage into gaps. Removing the check for willies head (cell "g" or cell "a") but forcing the check for the third tile, means that willy can move into a two cell wide gap. In practical terms this is similar to permitting passage through the corner of a wall cell on his way down, only if the two cells below are not occupied by a wall. This Matthew style FIX permits a one frame movement into the gap. I have not had a good look at the code to implement these changes, in a manner that I am happy with. I have however added two additional pieces of code to implement these changes, which seem to do as I want. Which is symmetry in movement. 1) checking head height cell and blocking willy from moving through them ... *NOTE 1 2) ability to still jump into gaps 3) stop passage into wall cells *Note 1 The upper Platform in "the Forgotten Abbey" if left as a wall will block Willy walking of the conveyor underneath it.

If you wish to write a better version, please feel free to do so. My code is simply illustrating a path that can be taken.

Seeing the Ramp code this morning I realised that the subroutine it called was no longer needed. So I have rewritten the code and saved another seven bytes.

slight edit to change a comment, which was from code that no longer exists. The comment confused what was happening when testing for extremes of movement left and right. This code has been edited repeatedly to arrive at what is seen Comments are sometimes the remains of multiple copies, and pastes If I am aware of a misplaced comment, I will delete it or edit it. ;set variables for these offsets ramp_frame equ 0 ramp_animation equ 1*2 ramp_where_1 equ 2*2 ramp_where_2 equ 3*2 ramp_condition equ 4*2 ramp_adjust equ 5*2 ramp_exit_screen equ 6*2 ramp_final_adjust equ 7*2 ramp_animation_reset equ 8*2 ;left data followed by right data left_data db 0, 3 ;0 VALUE TO JUMP FRAME - limit of animation movement at same position DB -1, 1 ;1 STEP TO NEXT animation FRAME - replaces inc or dec DB $1f, $22 ;2 POSITION OF RAMP 1 - ramp walk up DB $41, $40 ;3 POSITION OF RAMP 2 - ramp walk down DB 0, 1 ;4 CONDITION FOR RAMP DIRECTION - decision to check for up or down DB -1, 2 ;5 DIRECTION TO ADJUST HL - where to check vertically DB 31, 0 ;6 CONDITION TO TEST FOR NEW ROOM (limit of travel) DB 0, -1 ;7 STEP BACK - adjust of hl after vert check DB 3, 0 ;8 ANIMATION RESET for next frame ;----------------------------------- . L8FBC: LD A,(ROPE_STATUS) ;L85D6 DEC A BIT 7,A RET Z LD A,(L85D0) BIT 1,A RET Z ; Willy now needs to move left or right ; this movement needs to handle the stairs and check for their presence ; decide if moving left or right ld ix,left_data AND $01 JR nz,skippp inc ix ;switch to right data skippp: ; Willy is moving LD HL,(WILLY_ATT) ;L85D3 LD DE,WILLY_ANM ;L85D2 LD A,(DE) cp (ix+ramp_frame) JR Z,RAMP_CHK add a,(ix+ramp_animation) LD (de),a ;L85D2 RET RAMP_CHK: ; all de increments are positive so preload D ld d,0 LD A,(AIRBORNE) ;L85D1 OR A JR NZ,as_is ; three outcomes going up bc=-32 ; going down bc=+32 ; no ramp bc=0 ld bc,-32 ld e,(ix+ramp_where_1) ld a,(RAMP_DIR) ;either 0 or 1 and 1 ;get rid of other bits cp (ix+ramp_condition) ; the sign test ; this condition swaps on left and right jr z,down_ ld bc,+32 ld e,(ix+ramp_where_2) down_: add hl,de ; add offset to find ramp/stair square ld a,(RAMP) sub (HL) jr z,found_ ;if ramp is here keep bc=shift ;ramp not found so no offset needed as_is: ld b,d ld c,d ;bc=0 no ramp so no offset/shift found_: ld hl,(WILLY_ATT) ; this test is for extremes of position when moving left or right LD A,L ;left edge =0 right edge=30 ADD A,(IX+ramp_adjust) ;move in the direction left or right LD L,A ;left edge =-1 right edge=32 AND 31 ;left edge=31 right edge=0 ; if value is zero then move right ld de,GO_ROOM_LEFT jr nz,exit_other_way ld de,GO_ROOM_RIGHT exit_other_way: CP (IX+ramp_exit_screen) ; have we moved to the extremes? JR NZ,same_room ;we have moved far enough to enter a new room ex de,hl jp (hl) ;now check a vertical line for walls blocking path same_room: ; just move vertically and check the squares ; this code only checks for WALL's nothing else ; after the initial add hl,bc this checks downwards in a line ; the initial adjust is for ramps. e.g. up/down or level ADD HL,BC ;Point HL at the cell at ; ;(y-1) Willy is on or about to go up a ramp ; ;(y+0) just walking ; ;(y+1) Willy is walking down a ramp ld a,(WALL) ;in theory this position could be off the top of the screen bit 1,h jr nz,ignore_head_check cp (hl) ;head ret z ;return if path is blocked ignore_head_check: ; now check vertically down LD DE,$0020 ADD HL,DE ;point hil at the cell one lower ; ;(y+0) Willy is on or about to go up a ramp ; ;(y+1) just walking ; ;(y+2) if Willy is walking down a ramp CP (HL) ;foot RET Z LD B,A LD A,(WILLY_Y) ;L85CF SRA C ADD A,C LD C,A AND $0F ;jumping JR Z,ONLY_TWO LD A,b ADD HL,DE ; check- maybe needlessly- but check anyway. BIT 1,H JR NZ,OFFSCREEN ; ;(y+1) Willy is on or about to go up a ramp ; ;(y+2) just walking ; ;(y+3) Willy is walking down a ramp CP (HL) ;beneath? RET Z OFFSCREEN: OR A SBC HL,DE ; move back to feet ; final adjust back to HL=head position ONLY_TWO: OR A SBC HL,DE ; back to head position (free to move here) ;Adjust HL back LD A,L ADD A,(IX+ramp_final_adjust) LD L,A LD A,(IX+ramp_animation_reset) ; the animation frame :save state: LD (WILLY_ANM),A ;L85D2 LD (WILLY_ATT),HL ;L85D3 LD A,C LD (WILLY_Y),A ;L85CF RET

I decided to ditch the whole of Matthews code for dealing with ramps. That is the code from $8fbc to $90b5 =$105= 259decimal In essence the code repeats for left and right. I wanted it to be exactly symmetrical, with no deviation in how it handles left or right. So the code I use handles both directions by having one routine, which has variables passed to it. The testing is the same in both directions and it is around 187 bytes in length or around 72 bytes shorter than Matthews version. The code in the post below has been edited to move the subroutine to inline code. This has reduced its size by 7 bytes. So length is now around 180 bytes or around 79 bytes shorter than Mattthews version.

Space saving The code from $8aab to $8ac6 8AAB LD BC,$FEFE Read keys SHIFT-Z-X-C-V 8AAE IN A,© 8AB0 LD E,A Save the result in E 8AB1 LD B,$7F Read keys B-N-M-SS-SPACE 8AB3 IN A,© 8AB5 OR E Combine the results 8AB6 AND $01 Are SHIFT and SPACE being pressed? 8AB8 JP Z,$87CA If so, quit the game 8ABB LD A,($85E0) Increment the inactivity timer at 85E0 8ABE INC A 8ABF LD ($85E0),A 8AC2 JR Z,$8AD1 Jump if the inactivity timer is now 0 (no keys have been pressed for a while) 8AC4 LD B,$FD Read keys A-S-D-F-G The code from 8AAB to 8ac6 can be replaced by CALL $1F54 JP NC,$87CA LD HL,$85E0 INC (HL) JR Z,$8AD1 ; c has not been set up yet, so the next instruction sets c LD BC,$FDFE ; ; ;in all the versions of Manic miner or JSW I have posted, I tend to not use BC for the ports Tendency is ld a,port_? ;port_? is assigned to the row or even multiple row of keys that will be read in a,($fe) The code I actually use is defined in a MACRO, so I will type and see Read_Port port_a+port_k ; this sets up and scans both keyboard rows. e.g. row a-s-d-f-g and row h-j-k-l-enter The reason I do this is to ensure the port is fully assigned when addressed. It also frees the BC register pair

Re Game Over. In JSW their are a multitude of sound effects. The title tune and in game tune plays their notes in a differing method to all the other sound FX's. Both the title tune and in game tune attempt to play the note over a fixed period of time. Your simple demo routine plays the tune, were each notes length is dictated by its pitch. The overall length of each note is the product of a fixed length and a pitch variable. This has several repercussions. The obvious visual one is the speed change in the boot as it descends. The obvious audio effect would be shifting tempo. Your routine might benefit from using a routine more similar to the in game tune routine. Whereby the length of each note is fixed (sort of). ;in game tune ;Pitch of note held in D which should be copied to E before playing ;a=border colour 8B60 LD BC,$0003 ;length of the note overall 8B63 OUT ($FE),A 8B65 DEC E 8B66 JR NZ,$8B6B 8B68 LD E,D 8B69 XOR $18 8B6B DJNZ $8B63 8B6D DEC C 8B6E JR NZ,$8B63 Since this plays slower, this would also require new music data

In addition I have rewritten the cheat. Activated as normal, same place same password. It is activated by pressing "9" On the room name banner line, you will see the room number in decimal. Movement around the rooms is the same as another file I uploaded e.g. 1=left 2=right 3=up 4=down to re-enter a room press any movement key for left or right - Can be used as a major cheat, because as a sprite approaches you can press "9" and Willy will vanish. Wait for the sprite to move out of you way. Then press a key to carry on walking. Easier to probably press "F" "G" and remove the sprite. But the cheat mode is far older. I only started to write the "F" "G" feature yesterday afternoon.

Admit it. Your first thought on finding out what this effect did was to use it on MARIA.

Data for the arrows. In the normal set up of an arrow. It uses half of its allocated eight byte slot (after deleting the unnecessary data used at offset 5) e.g 0= direction and type (arrow) 1= 2=y position 3= 4=x position 5= 6=graphic 7= It is relatively easy to make the arrow, use the alternate spaces as the data for a second arrow. I did not go further with this idea, simply because in the games present format. It is difficult to actually define the second arrow to do much. I simply positioned the sprite to have the same Y-position as the first, and left it at that. This means every arrow in the game is paired with another arrow. If a method of changing the y-position of the second arrow (in the same guardian slot) was incorporated, and also a method of changing the default arrow timing. (A Major Change) Then this would allow 16 arrows in a room. The BLOB bouncing across the Bathroom was another Guardian type. That I rapidly lost interest in. It had many versions, some of which became floors that moved etc. Since none of the effects took my interest, the BLOB is all that remains.

This file serves no purpose, apart from toying with an idea, and showing the results of that toying. For years the baddies have dominated this game, and they think they have Willy on the ropes and scared. Take back control. In addition to the normal movement keys I have added (actually reassigned) two more keys. Press "F" for the first effect ---- part restricted in usage. whilst holding down "F" press "G" for the second effect. The room will reset after each visit. (so no sprites were harmed in allowing this effect to happen) When I wrote this I was aware of the BUG caused by stairs which affected the bullet sprite alignment. I was not going to fix it, but since then I have become aware of another problem concerning the time over data. (which was over written). So reluctantly I have rewritten some of the code. Willy 007.tap original File Willy 007a.tap stair fix - sound fx fix - time over fix willy 007.tap WILLY 007a.tap

Curious to see how much of a problem the Cell Graphic Feature is. So I have modified a game with most of the original data in it, just to display the room and show any graphic problems. The room data above $c000 is pretty much as used in the original. (might be a hand edit or two but nothing extensive) This version has had the game rem'd out. It will start in the bathroom minus willy. The initial room will not show the graphic data (too lazy to change this) But from the initial room onwards you can wander around the game using the keys 1=left 2=right 3=up 4=down Along the line below the room name will be displayed data in this format two digit room number in decimal Followed by 3 background tiles/ /3 floor tiles/ /3 wall tiles/ /3 baddy tiles/ /3 ramp tiles/ /3 conveyor tiles Each group of three tiles are generated by the various methods. The first tile is matched using CPIR The second tile is matched using CP (HL) and stepping The third tile is the actual definition. What is noticeable is there are very few incorrect matches. EDIT--- The program now outputs a second line of data (the same data minus the colours) tile_bug.tap

Re Cell Graphic feature: None of the "solutions" posted in this topic address the problem. What every "solution" does is eliminate one problem and ignores the fact that this method simply does not work. As an example a familiar scene from JSW edited very slightly to include a ramp, a stair and a conveyor. JSWED has drawn what should be drawn by the game in the room. If the fix does not draw the graphics as shown, then the fix has not cured the problem. In the case of the three graphics Stair-Ramp-Conveyor all being in the same room. Matthews code can not handle this scene properly. (The conveyor will cause the most problems in horizontal animation/movement) Remove the conveyor and change its colour, then this room would play with these graphics exactly as expected. I have posted a method elsewhere that draws exactly what was defined. (picture edited to remove jswed cursor)

Wrote this months ago, seems to be of the same theme. I had no problems fitting code into the available space. :your code can be rewritten to fit into the available space. My old solution. ; We are dealing with a vertical guardian. L917F push ix pop hl ld a,(hl) xor 8 ld (hl),a and $18 jr z,vert_phase ld a,(hl) add a,$20 ld (hl),a vert_phase: inc hl inc hl inc hl ld a,(hl) ; y inc hl add a,(hl) ;delta y ld d,(ix+7) ;max y cp d ;reached or exceeded max jr NC,reverse_delta ;reverse and save y as max y ld D,(IX+$06) ;min Y cp D ;reached or exceeded min jr Z,reverse_delta ;save MIN as position jr C,reverse_delta ;save MIN as position ld D,A ;save as calculated jr save_y reverse_delta: ld a,(hl) ;reverse delta y neg ld (hl),a save_y: dec hl ld (hl),d ;new ypos jr next_entity ;$93b3 ; around nine bytes of unused space here code from $93b3 ; this label/position is referenced from all other guardian movements, next_entity: LD DE,$0008 ADD IX,DE ;Point IX at the first byte of the next entity's buffer JP L90C4 ;Jump back to deal with any more guardians

replicate the sprite routine? The further I change routines and add my own routines the more likely I will have need for a routine that does the simple task of moving HL to the next raster line. (it is a big chunk of the sprite routine) so I write a routine called NEXT_RASTER that does exactly what it says on the label I use it to draw the logo, I use it to draw the sprites, in fact if I know a routine will draw more the eight raster lines, then I will call next_raster Calling a routine instead of having the code in-line is inherently slower. But look at the usage of IX in the willy sprite routine and compare the time with a call to just move to the next raster and return. (it is comparable) Plus all the in-line routines are removed to a simple call. It was also a deliberate ploy when developing new routines and generally just pushing my luck (experimenting) that I need to be certain that sprite/arrows anything that moved on the screen was constrained to the bounds of the screen. So I force NEXT_RASTER to comply with only returning VALID screen addresses. So if a sprite wanders off the bottom of the screen it will wrap around and emerge on the top , thereby not crashing the machine......Which is what the Y-table is meant to be used for. But in this game it is rarely used for that purpose. It is also easy to add lots of checks for screen bounds, in the experimental stages, which can be removed once the routine has been debugged. Since all the routines use the constraints it makes finding faults so much easier. (The game still runs with junk on the screen) ;--------------------------------------------------------------- In Jsw I think there are 3 separate sprite routines. 1) merge and test collision $9456 c=mode 2) write $9456 c=mode 3) merge with no collision check $9668 since you now use a flag to detect collision, and the routine does not abort. You can delete the third sprite routine. which is the one that draws willy onto the screen around $9670: (also draws the toilet) e.g. at $9670 change to ld c,Flag jp sprite_draw ;$9456 you can delete all code up to $9680 :this is space verses speed. I have split the two functions defined by The "C" register, so I actually use TWO independent routines, which individually are faster than the combined.... ;------------------------------------------- I do all the sprite drawing in a different way. e.g. The LD c,flag has been ditched. Re-stack. Using the bottom of the stack would be a handy form of debug. It would alert you to stack overflow and also screen overwrites.

I ditched the title screen very early in this current disassembly. Which is why I mentioned the title screen data. I do not have such an area of data, If I was aware of any 32 byte area of data that was below $c000 then I can bet I would delete it and implement code to replace it. I manually delete the last willy with a simple djnz loop. I also tried just filling the attributes, no easier so went back to manually deleting willy. The code I am messing with has at the moment no aim or purpose. I am editing this data just out of curiosity.

Using an assembler and ditching the constraints of Matthew's FIXED layout. I had changed every reference and had a running version before I passed any comments. Yes I deleted the 3 calls to dance/score/time. I deleted the screen clear and moved the attribute set up to before the room set up. It took less than a minute to do. It played havoc with two other routines that I have which is the room cheat mode. (in my version the rooms are displayed animated, with no willy) I also have a proper DEMO mode the plays through all the screens. It must have take a good two minutes to implement the changes. I would say there is a very high likelyhood that implementing the changes as you outlined, in the manner you have explained. would indeed result in an outcome that fulfils its need. My only comment is the usage of the Title screen data as a source for the sprite clearing data.

Have you tried this out? As far as I can tell you are one willy out, and need to change the offset added ($a0) to ($9e)