Norman Sword

The way the logo is stored is poor design. It is possible (i have done so) to reduce the size of the title screen and its data by around 200+ bytes, it might be nearer 300 bytes.

The remnants of a deleted post.Simply because its content was misinterpreted. A simpler response. The game file included at the end of POST #1 is the only version. All other versions of JSW VL5 DEMO and the slight revisions have been deleted.

Amsrad CPC Jet Set Willy. Cheat invocation. Any room and stood on the lower floor. This will be reset by any key that is not part of the cheat code. I have invoked this several times recently. All done in the bathroom. The easiest way to invoke. (but it will freeze the game) is to make the assumption that it could be either of the cheat codes I have mentioned. press <space> this will clear the cheat buffer then type in the longer of the two cheat codes- <HIEMMRAIDNAPRRRTT> From this point onward, game abort, will take you to the cartography room. This was designed as a cheat, To actually abort the game you need to loose all your lives. Break while playing the game will draw the cartography room. A big if here. If the cheat mode worked, the cursor on the screen can be moved around the map. When over a room on the map that is the target/designated room that it is desired to go to, press <enter> The cartography room will disappear and the selected room will be displayed. The cursor will again be flashing and again it can be moved. The cursor this time is indicating the position Willy will be drawn in the room. Press <ENTER> and the game will resume with Willy at the designated position. -------------------------------------------------------------------------------------------------------------- The above is what is supposed to happen. (after invocation of the cartography room and its cheat) The first problem concerns the inaction of the keyboard to input. This could be just configuration problems. But since I could not on my brief test get the cursor in the cartography room to move, the game was locked onto that screen. (so progress to the next part did not happen) The next problem, one I did not get as far as testing. Is that table of corrupt data. The code in the cartography room uses the data to find what room you are selecting as you move around the map. Very simple code. The little squares on the map are simply counted off (the squares indicating rooms) by starting in the top left hand corner and scanning each line to find a room square. If it finds a square it then steps one byte through the cheat table. If the cursor is flashing over the square picked and <enter> is pressed, it takes the value in the cheat table, and uses that as the new room number. Otherwise it just keeps scanning through the cartography room and stepping each time it finds a marked square indicating a mapped room. When it reaches the end of the screen, it knows you did not select a room, and loops through the movement code again. The cheat table is a list of the rooms as defined in the cartography room. Without that table, the data is random. What happens is the room is selected and the selected room should be drawn. The code looks up the room number and (in most cases) draws a pile of junk on the screen. Which indicates to me that the room number extracted from the cheat table is higher than the room count. So in most cases the cheat table must have values over 140ish , which are room numbers outside of the game data. At other times if it finds data that is within the room number total it draws the room that corresponds to that number. Since this is basically a random room number. We get shown a random room in the game. This mismatch between the map and the room shown, makes the cheat worthless. The problems I am encountering now, seem to be greater than the problems encountered five of six years ago. Which is why I assume that the inability to move in the cartography room is a configuration problem only. -------------------------------------------------------------------------- As stated above it is indeed the break key, that invokes the cheat jump into the cartography room. One of the many flaws of Matthew Smith's game (spectrum) is the way it asks for a colour code. If you run the game in an emulator you will find that it will ask for the same code on every single game that is played. It will even ask for the same code on the second attempt. Every time the game is played. This is due to usage of one of the spectrum's variables as its random number seed. Since this is fixed on every load of the game when using an emulator, that is why you get asked the same input code. This problem is not a new problem, it existed back in the 80's. You can save a snapshot of the game. If the snapshot saves the system variable, then the game will ask for the same code every time it is loaded via a snapshot. The simplest method of stopping that simple problem is to force the user to have some interaction with the game before asking for the input code. So to update the variable it would have been better if the simple question/statement had been presented to the game player. Which is <Press enter to continue> or something similar. To stop this question being negated by pressing enter as the game is loading,. Which would immediately upon completion of loading bypass the question, because the <enter> key is being pressed. You set up the loop to wait for its release as well. The wait for key and wait for key release will generate a better random number, and a snapshot will still ask for a new colour code on every run. Even the modern versions run on an emulator would give a new number on each run of the game... The above is why the Amstrad version asks for the user to press a key. All the time the question is on the screen the games code is changing the value of the code to ask. If the end user has enough skill to bypass this code (asking for enter to be pressed), you can assume that he is or she is already delving into the code. ------------------------------------------------------ Searching for the cheat code activation text. Derrick thinks that the code might be written backwards, and even have a simple addition of setting bit 7 on the letters. Any decent debug/monitor allows the toggling of ASCII in its output display. The setting of bit 7 on ASCII is a common practice, and the debug/monitor should permit you to see the ASCII from values over 128 by toggling the display output. -------------------------------------------------- footnote:- The hacking of the game for infinite lives will also make it impossible to exit the game once cheat is invoked. (if it worked)

The whole scope of this topic is the missing Cheat code table on the CPC Amstrad. ----------------------------------------------- Information direct from Derrick. The conversion from CPC Amstrad back to the spectrum, involved a game redesign. The CPC has an interrupt set for every 300th of a second. These are arranged to occur on frame flyback and five others per frame. This enables the screen to be recoloured on every screen frame. The top part of the screen has one set of four colours, and the lower part of the frame has another set of four colours. The interrupt is supposed to occur as the raster passes over the screen in the area of the room name. So the room name area has two colours that are common to both the upper part of the screen and the lower part of the screen. This enables the game to have six colours in some rooms. (in 4 colour mode) The game uses xor on and xor off. One of the advantages of this method is that it is fast, another advantage is that the Amstrad game does not then need to have any copy screens. This means that the sprite is erased on the visible screen and for a moment it is possible to see the difference between the new and old sprite. Think about the spectrum and the way It was pointed out the jagged finger effect. The visual affect of xor ing off a sprite and xor ing on a new sprite makes that effect look tame. You end up with a very visible jerking or tearing on the large sprites. The worst offender is the three sprites joined together to make the large skull. Drawing that looked a mess. What would normally happen in this type of update, would be the game waits for a specific interrupt and then tries to beat the raster before it overtakes the drawing routine. Instead of possibly waiting nearly a whole frame for a specific interrupt, Derrick decided to uses the interrupts as a screen position indicator. Then only wait then, if the raster would overtake the sprite while it was being xor'd on and xor'd off. A very slight change but a dramatic change in the visuals. The point of part explaining the XOR on, XOR off problem. Is to partially explain why that could not happen on a rewrite from the Amstrad back to the spectrum. The spectrum needed to have a copy screen to stop the problems of screen updates. A copy screen uses a big chunk of Ram, and this game was being converted from a 64k amstrad to a 48k spectrum. All un-needed code was immediately deleted. The first deletion was all the cheat code. The 2nd problem of moving from the CPC to the spectrum was collision detection. The CPC has pixels with colour. This is changed to the spectrum having pixels that are coloured via an attribute overlay. The CPC used the colour of each pixel for its collision detection. In essence a white pixel under a sprite indicates a collision. The spectrum has to use a whole new logic to detect a collision. And that new logic made a need for a copy screen to be implemented Collision detection moved from sprite drawing on the cpc, to sprite collision based only on Willy on the spectrum. This was a major change in collision detection. ---------------------------------------- So any time I mention cheat code on an original from the CPC or the cheat code in JSW2 . You can immediately assume I am not including any spectrum version of JSW2. So only two tape versions written for the CPC. And only one tape version written for the spectrum. Any spectrum version that does not include the colour code input question is also a hack of the original, in the same manor as the hacks generated for the Amstrad versions. But in the spectrums case, there was no mysterious data to worry about.

STEP2_INDEX: is/was used by another routine as you suggested. The unused bits. The routine was written to encompass change in the data. So the length of each data table was selected to enable editing. 3 bits for time and five bits for pitch change. The subroutine contains an "AND 31" which is handy for the pitch change data. No point in adding another instruction somewhere just to reclaim the bit that is/was not used in the data. The notes length still needed to have an "AND ?" added somewhere, and here I felt the editing of the data was unlikely to add longer notes. So "AND 3" was selected and then the additional bit was free. The point of including the statement that this is unused. Was to emphasize that the bit is available if wanted. and the "AND 3" can be changed to "AND 7" and additional note lengths can be added. I can think of no use for the spare bits, apart from the what they were originally designated to be used for.

I delved briefly into the Amstrad world again. Just not welcoming enough to pursue further. As shown I managed to get as far as invoking the cheat. To progress further I needed to move the cursor etc. This did not happen. Every time I ran the program on this particular emulator, it managed to place the interrupts in the wrong place (hence the yellow band across the screen) Five emulators later and several versions of JSW tried, I lost interest. The emulators and their presentation/interface does not inspire any interest to me. I will stick with an emulated spectrum. The cartography room on the small 60 room version- Does not need to have the room name in memory, only the data for the rooms. I would expect the data to be just tagged onto the end of the 60 rooms. On examining that area on the emulated Amstrad , all I found was a message saying "What's this then"..... Typing in the cheat on the 60 room version has no effect. Derrick has stated that only two tape versions of JSW exist (master taped by him) and any other version was not mastered by him and must be an edited version- (scope of editing being how the game loads) And I myself will not be looking any further into this.

The versions of Jet set Willy available. (CPC Amstrad) S.Wetherill left Software Projects just after completion of writing the game, D.P.Rowson stayed on at Software Projects long enough to reduce the game to 60 rooms for the "they sold a million" compilations. The MASTER GAME tapes used at software projects were not just copies of the game, they were versions of the game that saved the game. For both Manic Miner and Jet Set Willy on the Amstrad, a version of the game was provided that saved itself, or more specifically the game from within its data. The MASTER GAME version was used by the duplicators to generate a clean copy of the game to duplicate. The above MASTER GAME tape version is used every time a new batch of tapes is duplicated. Since D.P.Rowson and S.Wetherill had left Software projects the creation of any new MASTER GAME tapes (the one that saves itself) is a problem. The programmers that created the originals have left the firm. So any decisions from that point onward, that forces a need to change how the game works or its environment, creates a need for the creation of a new MASTER GAME tape, or if the media is changed the creation of a MASTER GAME disc Looking at the versions that have been released by Software Projects we are presented with slight changes in how the game loads. These changes can only be achieved by creating a new MASTER GAME tape or disc. Problems created by the master tape - I assume software projects decided at some stage to release the game via the budget software labels, or it was decided to put the game on disc or perhaps just remove the colour code entry part. What ever the reason this decision involves the creation of a new MASTER GAME tape or disc. The problems presented to anyone who has tried to copy or break into the original game are now presented to the actual software house who want to do a re-release, any change needs to have a new MASTER GAME available. So someone is tasked with hacking into the game and changing it. I would assume that since the colour code entry part and the part that scrambles the data are the same. It was necessary to invoke that code and unscramble the game. Thus removing the protection and the code entry part. The person who managed to remove the protection (possibly) also casually removed the cheat code table. The in house hacker is perhaps not aware of its existence and so its removal seems to do no harm. (assumption) Without reloading all the various versions I believe that any commercial version that does not have the code input question are derived from the in-house hacked version. The programmer who created the new MASTER GAME version had (possibly) destroyed the cheat table. From that point onwards it becomes easy to save the game to disc minus the code input. While I had an emulator for the CPC running, I could not find a version that allowed the full usage of the cheat code. And that is the basis of this assumption. The cheat code has two variations. The first as mentioned EMMRAIDNAPRRRTT and the second is the same code with the addition of the letters HI before it. This by logic must be the cheat code for the 60 room version of JSW on the Amstrad, and this means the 60 room version has the cartography room in it. The cheat code was extended for the other version of JSW, and I only know of two versions on the Amstrad CPC Is the cheat table intact on the 60 room version ? Far less memory used and thus far easier to put on disc or re duplicate with the data intact. This version was not checked. The above is concerned with versions that were commercially sold, on top of that we have the versions that are hacked versions of the commercial versions. These could have the cheat code only if hacked from the original tape (I did not find any when I was looking) ------------------------------------------------------------------------------------------------------------- The above is fragmented, just like a badly fragmented hard disc. So very difficult to discus a topic, when it is possible a sentence contains snippet of information that is open to misinterpretation or its details are unknown to the reader. ------------------------------------- Edited to be hopefully clearer.

The original version of Jet set Willy written for the Amstrad, and was subtitled "the final frontier". It was only at a later date that this was reduced back into Jet Set Willy. (e.g. removal of around 77 rooms from the 137 rooms. And the reduction to the mere 60 of the original) The reason for the re-write was that is was going to be included in a compilation tape, and the original 60 room (short version) was deemed to be more in line with the original spectrum version. The original Amstrad version was undertaken on a 464 and at that time the 664 and all the subsequent versions were not known about. Weeks (perhaps days) before the release of the Amstrad version of JET SET WILLY the 664 was released. A version of the 664 was obtained and the game was checked to see if it would run. It was found that Amstrad had moved the location of data concerning the keyboard. This change made the keyboard inoperative from a games perspective. This was easily solved by modifications to the games code made from basic. This is the reason that the question is asked before the game is run. The above is the time frame of the game game in relation to its release onto the market. The point of interest is the statement that the 664 was not available at the time of writing the game. This shows that discs and disc drives were not considered in the games writing. *** The above (two paragraphs) was edited to be crossed out. The reason it was crossed out was the assumption I was incorrectly thinking about Manic Miner. Since then I have loaded the game and it does indeed ask for the machine type. The game, loads from tape and the tape version (original) has a full cheat code and cheat routine built into the game. When a disc drive is added to the operating system, The disc drive is allocated a chunk of memory just for disc operation. The allocation of the disc drives and the memory allocation of the game clash. The memory allocation that is overwritten by the disc drives and the disc routines (especially the loading from disc) is crucial to the cheat code and the way it works. Unfortunately the memory overwritten seems to have no effect on the game. So every copy since the original tape version seems to work fine with the data missing. However the very extensive cheat code relies on the missing data, and it seems that for many the cheat code was a mystery, and therefore it's omission was not noticed. The cheat data is a small table of values (around 150), whose purpose is to index into the data from the cartography room. Since this data is ommited from all disc and subsequent versions, when the cheat is invoked the translation from a position on the cartography room map into a real room number does not happen. This makes invoking of the cheat pointless. ( another reason most people do not know of its existence- once cheat is invoked, it does not seem to do anything worth having) Anyone familiar with the Tandy and its operating system will be aware that a similar problem was occurring on that machine. Through its evolution and need to be backward compatible, the machine also needed to allow programs to load via tape, and run. But be able to load the same programs from Disc. The conflict in memory was overcome by the simple addition of another routine to the games loading routine. This routine would load the game into memory that was NOT occupied by the disc system. Once the game had loaded it would, shut the disc system down and then move the game into the area used by the disc system and then run the game. The game Jet Set Willy could be fixed in a similar way. In this case it does not need the whole game moving, It needs just the data from the area that is missing from all the games since the original. If the game is loaded (as normal) from disc, and at the point of normally entering the machine code from basic, we instead load the missing data to the screen. The missing data around 150 bytes can have a very simple LDIR routine appended. The procedure then is to run the code and move the data over the area used by the disc operating routines and directly enter the game. The area overwritten by the LDIR copy will be corrupted by the game anyway, and doing this will have no impact on the machine. But it will fix the cheat. Loading such a small amount of data should be so rapid that it would hardly noticeable. In JSW Amstrad the cheat code is Invoked by typing hiemmraidnaprrrtt. This will bring up the cartography room and from there you can select a room. Then you can select a position to start the room. The finer details of the cheat invocation and usage are not listed here. It is such a long time since I have looked at the CPC Amstrad version, I can not even remember what exactly is done to invoke cheat, (it might be pressing the break key) It is a shame no has looked into doing this. At present I do not have the CPC set up and Emulated. (deleted many years ago) and the set up. emulation , modification, save etc needed to do this modification is not something I plan on doing.

; MANIC MINER PIANO ROUTINE for the ZX spectrum ; The only reason for this updated routine is the change in lighting the keyboard on silent notes ; if two notes are defined, and with the same values the keyboard will still light up. For silence use 0,0 ;the complete title music routine for Manic Miner manic_tune: LD DE,L33902 ; music data manic_loop: ; is the music finished LD A,(DE) ; length and pitch shift OR A ; terminate on zero RET Z ; else find out the note length AND 3 ; a third bit is available if needed LD HL,TIME_SHIFT CALL STEP_INDEX LD C,A ; NOTE LENGTH ; and extract the pitch shift LD A,(DE) ; THE note shift INDEX LD HL,NOTE_SHIFT CALL STEP1_INDEX LD B,A ; THE NOTE SHIFT INC DE ; extract the first note and light keyboard LD A,(DE) ; (NOTE 1) INC DE PUSH DE ; the data pointer saved - we want to use the registers LD D,A ; (NOTE 1) ;This must calculate at least one value for HL CALL NOTE_PLACE ; we want HL the pointer PUSH HL ;calculate 2nd NOTE LD A,D ; NOTE 1 ADD A,B ; NOTE 1+NOTE SHIFT = NOTE 2 LD E,A ; NOTE 2 ; here we light the keyboard only if this NOTE HAS A VALUE INC D DEC D JR Z,same_notes1 LD (HL),PAPER2+BRIGHT ;#50 ; press the key #50=(PAPER RED +BRIGHT) same_notes1: CALL NOTE_PLACE ; returns HL PUSH HL ; same as above, only light if this has a value DEC E INC E JR Z,same_notes2 LD (HL),PAPER5 ; PAPER5=40=$28 PAPER5=(PAPER CYAN) same_notes2: LD B,0 ; initialise b LD A,L ; the border is set from L ; XOR A ; an alternative to the line above, force no border flash LD L,E ; NOTE 2 (LOWS) LD H,D ; NOTE 1 (HIGHS) ;what's what now ;E = L - NOTE 2 (low registers) ;D = H - NOTE 1 (high registers) ;BC = - overall duration ; note B=0 length is in "C" ;A = last piano keyboard position and this dictates the border colour tune_loop: OUT (#FE), A ; note 1 (HIGH REGS) DEC D JR NZ,tl_1 LD D,H XOR #18 tl_1: DEC E ; note 2 (LOW REGS) JR NZ,tl_2 LD E,L XOR #18 tl_2: DJNZ tune_loop DEC C JR NZ, tune_loop ; noise completed, erase the pressed keys POP HL LD (HL),PWHITE ; PWHITE=56=$38 ; the default keyboard colour 56=$38=(paper white + ink black) POP HL LD (HL),PWHITE ; PWHITE=56=$38 ; ; restore the data pointer POP DE ; restore the note pointer ;check for exit and then loop CALL test_enter ;#9337 ; Check whether ENTER or the fire button is being pressed RET NZ JR manic_loop ATT15 equ $59e0 ; The attribute position of the piano, which is defined as line 15 ; calculate the screen position to press a key based on "a" the note NOTE_PLACE: LD HL,ATT15 ; this address is free to move up or down the screen SUB 8 CPL STEP1_INDEX: RRCA RRCA STEP2_INDEX: ;used by the delay routine RRCA AND 31 STEP_INDEX: ADD A,L LD L,A ADC A,H SUB L LD H,A LD A,(HL) RET ;: Title screen tune data (The Blue Danube) ; The tune data is organised into 95 groups of two bytes ; two bytes of data for each dual note played. ; The first byte is split into two values. ; ; byte 1 ------xxb the xxb value is an index into the TIME_SHIFT array. This supplies the note duration. ; byte 1 xxxxx---b the xxxxxxb value is an index into the NOTE_SHIFT array. this supplies the shift from the first note to the second note ; byte 1 -----x--b the xb value is unused in this data ; ; byte 2 xxxxxxxxb the xxxxxxxxb value is raw data and is the value of the first pair of music notes. This value is identical to the middle ; value in the original 3 byte layout. It is the NOTE value for NOTE 1 ; ; The value extracted from the NOTE_SHIFT array is simply added to the value of NOTE 1 ; the sum of NOTE 1 and the NOTE_SHIFT value is the value for NOTE 2 TIME_SHIFT: ; 0 1 2 3 ; notice I have used 75 (which is the logical value to use) DB 25, 50, 75, 100 NOTE_SHIFT: ; 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DB 0, 1, 6, 8, 10, 11, 13, 20, 21, 24, 32, 43, 75, 77, 128, 154 ; L33902: DB 2+8*1,128 DB 2+8*1,102 DB 2+8*1,86 DB 1+8*1,86 DB 1+8*10,171 DB 1+8*3,43 DB 1+8*3,43 DB 1+8*10,51 DB 1+8*6,64 DB 1+8*6,64 DB 1+8*10,171 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*4,86 DB 1+8*8,171 DB 1+8*4,43 DB 1+8*4,43 DB 1+8*8,171 DB 1+8*7,48 DB 1+8*7,48 DB 1+8*8,171 DB 1+8*1,136 DB 1+8*1,136 DB 1+8*1,114 DB 1+8*1,76 DB 1+8*1,76 DB 1+8*8,171 DB 1+8*8,38 DB 1+8*8,38 DB 1+8*8,171 DB 1+8*7,48 DB 1+8*7,48 DB 1+8*8,171 DB 1+8*1,136 DB 1+8*1,136 DB 1+8*1,114 DB 1+8*1,76 DB 1+8*1,76 DB 1+8*10,171 DB 1+8*6,38 DB 1+8*6,38 DB 1+8*10,171 DB 1+8*6,51 DB 1+8*6,51 DB 1+8*10,171 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*1,64 DB 1+8*11,128 DB 1+8*5,32 DB 1+8*5,32 DB 1+8*11,128 DB 1+8*3,43 DB 1+8*3,43 DB 1+8*11,128 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*1,64 DB 1+8*9,128 DB 1+8*2,32 DB 1+8*2,32 DB 1+8*9,128 DB 1+8*4,38 DB 1+8*4,38 DB 1+8*0,0 DB 1+8*1,114 DB 1+8*1,114 DB 1+8*1,96 DB 1+8*1,76 DB 1+8*13,76 DB 1+8*1,77 DB 1+8*1,77 DB 1+8*13,76 DB 1+8*1,91 DB 1+8*1,86 DB 1+8*15,51 DB 1+8*1,51 DB 1+8*1,51 DB 1+8*15,51 DB 1+8*1,64 DB 1+8*1,102 DB 1+8*1,102 DB 3+8*1,114 DB 1+8*1,76 DB 1+8*1,86 DB 1+8*12,128 DB 0+8*14,128 DB 0+8*1,128 DB 1+8*12,128 DB 0 ;End marker

The missing room was room 47. ( was that the original "]" room ? ) The file has again been updated with the whole 128 rooms. I suppose I should delete the game file and update that as well (not done)

The colouring is just another product of the game design. Four pictures . 1 and 3 use "OR" for sprite draw. pictures 2 and 4 use "XOR" We are looking at the pixels and not the colours. In picture 1 ("OR") Willies head is merged into the background, and the pixel pattern of the background is lost beneath his head. In picture 2("XOR") Willies head now exhibits the pixels of the background beneath the outline of his head. The differences in picture 3 and 4 have been lost due to the collouring changes. But the black shape of Willies lower body in picture 4("XOR") is a classic look due to "XOR" on the screen. The area of note here is the conveyor as it passes through the body of willy. The conveyor "Xor"s his body. In the "OR" version we can not see the conveyor beneath his body outline. I will find some better examples ADDED pictures. again in groups of two. Pictures 5 and 7 use "OR" and pictures 6 and 8 use "XOR" Notice the difference in First Landing (pictures 7 and 8) using "OR" the stair merges into the form of Willy. In the usage of "XOR" the stair can be clearly seen Again the differences in pixels in "Ballroom West" (pictures 5 and 6) the rabbit platform merges into the outline of Willy with "OR" picture 5. In picture 6 "XOR" the outline and Willies shape are now undetermined.

Using XOR in the game JSW The present layout of JSW would need a lot of changes in its code. The separation of movement and drawing brings up two immediate problems. 1) The arrow routine draws and moves in one routine. This would need to be split into move and draw. Since the original arrow code is small, I would think that splitting the arrow code into two parts would not expand the routine a great deal. 2) The rope has embedded in its drawing routine the ability to move willies position. This would need heavily modifying. The game engine would need tweaking to rearrange the flow Move willy move sprites draw sprites+willy (xor on) copy screens draw sprites+willy (xor off) loop Possible to do, yet I have shown that it is not needed. --------------------------------------------------------------------- JSW2 uses XOR for its drawing. JSW uses a pixel based collision detection, which makes all sprite drawing check each pixel for collision. The arrows only check the main shaft for collision and not the line above or below (Sidetrack here: I do not think it would be possible to be in a square with the arrow parts above and below the shaft, because of the method of drawing the arrow. It assumes the arrow parts are within a character block. If they are drawn either above or below a character then other design flaws come into play) JSW2 does not do any collision detection on sprite movement, and this includes the arrows. Yet it will detect collision from anything on the screen that moves into its path. The above may seem to be a contradiction, when looking at the game engine for JSW. This is busy checking sprites and Matthew wrote into his sprite routine a switch that permits the collision part to be turned off. Needed for simple things like the boot crushing willy on the game over plinth. If that switch to turn off collision and change the drawing mode was not present, then the boot would be flagging willies death on collision with the boot. JSW2 has no collision detection in its normal sprite drawing routines. This is why it is possible for the sprites to go wherever they want. The Birds in JSW2+ are permitted to fly over the background in the secret lab. In JSW2 the eggs in eggoids collide with each other and no collision is detected. These collisions would prove to be a major problem in JSW. **** NOTE **** The Amstrad version does not use this method- This method is used only on the spectrum. So how can it detect a collision? MAGIC - Monitored Active Graphic Image Collision Every time Willy is drawn on the screen the local area behind Willy is modified. The game looks up the graphics that are defined behind willy and erases them. It then draws Willy to the screen. The drawing of willy is the only sprite draw that checks for collision. Since the graphics have been erased, the only graphics left in the area behind willy must be the other sprites drawn on the screen. So a pixel collision here indicates a sprite collision with willy. (or a rope- I am not widening the scope to include the ropes here) After willy is drawn the graphics are replaced in the area behind willy. This means that only one of a possible 16 sprites (jsw2+) needs to check for collision. The other sprites are drawn using a very simple drawing loop. The above is the idealised image of collision detection in jsw2 which uses XOR for drawing.

One of the differences between JSW and JSW2 is the method of screen updates. JSW2 uses XOR for all sprite updates. This does introduce a visual change to the game. One that is easy to spot. To implement XOR you basically run the game drawing routines twice in every loop. So movement and drawing are completely separated.

When I first saw this edit, I was surprised that the scrolling was based on willies x position alone, and did not incorporate his animation phase as well. By using the x position of willy as the basis for the scroll copy, the screen is scrolled in blocks of two characters at a time. It does not take a lot of code to change the scroll to one character by using the animation phase of willy. The buffer copied to, is set at 34 wide instead of 32. Then the start position of the copy is either set at the start of the copy buffer (animation phase 0 or 1) and move along by 1 byte if the animation phase is 2 or 3. This then halves the increment on the scroll and it would look a lot better.

The speed changes The biggest factor in overall game speed is the four innocent looking LDIR instructions that copy the screens. Those four ldir's move 9216 bytes of memory mentioned numerous times:- using ldir takes 21*9216 T states to copy the screens on each and every loop. A very big chunk of time. Using LDI takes 16*9216 T states to copy the screen on each and every loop (idealized times) . A noticeable increase in speed. Using stack copy can push the idealized times up to 11*9216 T states, a very noticable increase in speed. At this point in speed increase we can make more and more changes in the games background speed, but we have hit a basic speed limit. The screen copies dwarf all other speed considerations. There is however another factor that is adding a major slow down. One that is not looked at because the normal scope of editing does not bring into its remit the placement of the copy screens. ALL the copy screens sit below #8000 and this means all the screen data is written to contended memory. And all the copies to and fro are copies that are in contended memory. Every single sprite draw and screen copy is affected by the contended memory issue and this speed decrease is not within the scope of editing JSW. The small program included here, just loops and draws to a dummy screen (filling it with data). it then copies the dummy screen to another dummy screen. And finally copies the 2nd dummy screen to the visible screen.(similar to the game copy routines in JSW) Each loop of fill and double copy, moves a visible pointer on the screen, and a text line displays what memory is being copied. The small routine does this copying using two sets of screens. The first set of screens is sat below #8000 and all the data is moved from contended memory to contended memory (which is how JSW is set up). The 2nd routine uses the same routine, but now the two copy screens are sat above #8000. This moves the same amount of data and it is only the final copy that is moving data into contended memory. (the copy to the visible screen) What this small program shows is the speed decrease that contended memory gives a 256 loop of this routine in contended memory 26.73 seconds a 256 loop of this routine in high memory 23.13 seconds A slowing down due to contended memory of 3.6 seconds. The contended memory issues show that a speed increase of around 14% is available on LDIR just by moving the screens. Not a great deal of time on its own, but once the screens are moved. That 14% increase is mirrored by all the other methods of screen copy. A stack copy using un-contended memory is a lot faster than the same stack copy with contended memory. So in the JSW GAMES version VK and version VL. I use un-contended memory for the copy screens. From version VK and onward the whole game allocation is changed. And no amount of editing the basic game will achieve these speed increases, until they are also reconfigured in a similar way (or rewritten) Vesion VL DEMO goes one stage further and uses a change of strategy. This adds a great deal of code and complexity, but the result is evident in the speed increase. CONTEN~1.tap

The dancing was based on the games Ticker. This quick update--- updates from the games current playing note index. This keeps his dancing at a more fixed speed (in tempo to the music) Now with a file actually attached:- -------------------------------------------------------- Addendum a couple of hours is a long time:- jsw VL5 DEMO revision3.tap The animation is based on the tempo of the music, and is too Manic (right frame of mind but wrong game). I could slow it down to look less Manic. (Tried it and was still not happy.) jsw VL5 DEMO revision3a.tap The animation in this version is based instead on the note being played. So if a note is sustained, the animation will not change. The sequencing of the animation is solely dependent on the value of the note played. So the animation is fixed by the music. I feel this whilst erratic frantic (not Manic) better suits the game. Alas I am out of memory so the next addition I did corrupted a pile of data. Some visual screen data is deliberately placed at the end of available space, and if I exceed my code space. The data will be displayed on the screen as a mess. this indicates visually to me the limits of editing. Whilst I had to delete this routine the idea was to actually play the wording of the tune across the bottom of the screen as Willy danced -- Looked interesting, just not interesting enough to accommodate into the space available. Something would need to be deleted and the routine was not exciting enough to progress any further.

The way this plays music bears little resemblance to the way Matthew played music. His was just an incremented pointer, playing at a fixed rate. Code wise :- 35648 LD A,(34273) Increment the in-game music note index at 34273 35651 INC A 35652 LD (34273),A 35655 AND 126 Point HL at the appropriate entry in the tune data table at 34399 35657 RRCA 35658 LD E,A 35659 LD D,0 35661 LD HL,34399 35664 ADD HL,DE at this point (hl) holds the note data "BC" will be set with a fixed value of 3 and my code --- minus most of the comments and data ; this plays variable length and variable note repeat and even mutes the music if needed the call to STEP_INDEX- this adds "A" to "HL" and returns the contents of "(HL)" : A=(A+HL) The routine below plays the in game music, changed from just being a variable delay. snail_run: ld hl,var_flag ; this is the speed factor LD a,(MUSIC) ; the music flag (on/off) bit 1,a ld a,(hl) LD D,0 jr Nz,set1_version add a,4 LD D,#18 set1_version: or a ret z ; this loop is repeated less than 20 times at maximum slow down ;(the speed to execute this code compared to the delay this is calculating, means it is insignificant) ; on a flat out game (music off and fastest speed) this code is not executed. ld e,a ld bc,$190 ; a delay value ld hl,0 sgk: add hl,bc dec a jr nz,sgk ld c,l ld b,h ld hl,repeating_note ; table of Blip values (how many times the note will blip) ld a,e call STEP_INDEX LD E,A S_M_C_RECHARGE: EQU $+1 ld a,2 dec a jr nz,se1_note inc (hl) ld a,E se1_note: ld (S_M_C_RECHARGE),a ld a,(hl) and 63 LD HL,Music_data ; table of note data CALL STEP_INDEX ld e,a E= note BC= duration L= mic toggle D=mic toggle (the routine uses "L", so this must be copied, somewhere) Note standard in all my code. if something starts with S_M_C_ it is indicating the value or variable is part of inline code that will be modified e.g. Self Modifying Code ;-------------------------------------------- The game notes are still played as designated minimum of two blips per note, However on the first pass the blip count is set to two and is similar to the problem in the original JSW. This is decremented and the first blip is played. This is one blip before the note index is moved to the next note. On first game start up the speed index is set to very fast and in this instance the number of blips is set to 5 for all the subsequent notes and the blip counter should be set at 5 (or even 6) . Not as stated above at 2. Playing one blip is equivalent at the game start to playing 1/5 of a note, Which is more noticeable than the equivalent problem in the original. All the changes in speed reset the blip count after each note. The routine has no external counters and does not get updated outside of the music/delay routine. The note index is reset on each game. The technical problem is the blip count, which was not reset and due historically to this being a two blip game was left as 2 (which would have still omitted the first half of the note, even if the game was started at the slowest speed). I thought it would take too much code to actually adjust the blip counter at reset to the required value on a game reset (I knew it was a problem- just was not bothered, to actually fix it--- this does have a great big banner on it saying DEMO of speed) addendum to the paragraph above......( on subsequent slow speed game, playing, with 2 blips per note) Not resetting the blip count can make it either skip one blip on subsequent game resets or skip the whole note. The chances are 50-50 I have now fixed this problem and inserted a blip reset, and changed the note index to the last note. This ensures on the first pass the blip count is reset to the correct value for its speed, and the note is stepped to the next note, which will be the first note. This was done by changing the data in a data reset list from (NOTE_INDEX ,0) to (NOTE_INDEX ,63) and inserting 2 more values (S_M_C_RECHARGE , 1). The modification was far easier than I thought at the time of writing the original. ------------------------- As I mentioned before I do not listen to the music, it is turned off. If the game had crashed or started playing very obvious long note sequences.I might have checked it a bit more or at least bothered to investigate how I could reset the data. It played and it was not the focus of what I was doing.

Noted the one note... Duly changed. I tend to not listen to the music. And I normally have no sound output on my PC. Others in the room do not appreciate the sound playing.

I have uploaded the Demo version of JSW 128 VL5.tap The slight name change is to JSW VL5 demo.tap. This is up loaded as a revision of JSW128 vl5.tap This demonstrates a very very very fast version of Jet set willy. This version also now plays music and not blips for the in game music. The tempo of the music is adjusted as the games speed is changed.. Since the basic music note is played twice, it was not possible to do step-less adjustment, for the faster versions. A large amount of extra graphics and routines added. All the graphics are displayed bit by bit in the extra title screens added. (over 21 variations on the title screen- based on the main five ) To see full speed, turn off the music. Since the option to upload is here (as well) I will attach the file here. ----------------------- One note changed. Typing error. The tune routine like most things was changed and speeded up. This meant all music data needed to go through a translation table to adjust its speed. The data had a misplaced digit. The note was only played once. ---------------------- I will attach the last version here (19th January 2019) JSW VL5 DEMO revision 3b.tap -------------------------------------------------- All the main screens. JSW VL5 DEMO revision3b.tap

Modification of Manic miner tune. The above routine was an exercise in compacting the code. Code that was never used. The original modification from. SUB 8 RRCA RRCA RRCA CPL OR #E0 TO RRCA RRCA RRCA NEG OR #E0 --- my code has OR L where L=#e0 This modification works fine and gives exactly the correct results. And does not need any additional code. my error was just swapping the routine around, whilst still thinking about the CPL instruction used in the first routine NEG RRCA RRCA RRCA OR #E0 --- my code has OR L where L=#e0 Moving the NEG from after the RRCA instructions to before the RRCA instruction changed what it did. Simpler to revert back to the sequence SUB 8 CPL RRCA RRCA RRCA AND 31 OR L Since the above code has been tested. I know it works for all values, in exactly the same way as the original. Works 100% The routine is still 70 plus bytes smaller than the original. Addendum. The AND 31 instruction was added before the code change to compacted data. The reason for its inclusion was to permit the moving of the piano graphics to any screen line, and not be forced via the old code to one of 3 fixed screen positions. 2nd addendum: The code I reference is the original layout. Unfortunately for me, I have edited so much code and done so many changes in the code, that I would need to keep going backward and forward checking items for reference. The code listed in the Manic Miner music routine, is a derivative of the original code, which because of dual usage no longer OR's in the screen address, It now adds it. This slight change is what the next post #12 is referring to as the difference in opcode usage. The code I listed is relocatable and not fixed to any memory address. In the context of being placed back into Manic Miner, it can again have the restrictions imposed on it. The tune data and the two data tables used for data expansion, can be fixed into a page, along with the fixed screen keyboard reference. This can remove several opcodes and make it even smaller. (something I will not do). I prefer the options of being able to have code where ever I place it

Edited and swapped some registers around - another 2+ bytes smaller This code can be placed anywhere in ram. ;The complete title music routine (data and code) for Manic Miner ; Manic_Miner_Title_Music: ld de,Tune_Data ; manic_loop: ld a,(de) OR A RET Z AND 3 LD HL,TIME_SHIFT CALL STEP_INDEX LD C,A << added LD (S_M_C_ahead),A LD A,(DE) LD HL,NOTE_SHIFT CALL STEP1_INDEX LD B,A << added LD C,A INC DE LD A,(DE) inc de push de ld d,a ;NOTE 1 CALL NOTE_PLACE push hl ld (hl),#50 ld a,d add a,b << added add a,c ld e,a :NOTE 2 call NOTE_PLACE push hl ld (hl),#28 LD A,L ld l,e ;NOTE 2 (lows) ld h,d ;NOTE 1 (highs) ld b,0 <<added S_M_C_ahead: equ $+1 ld bc,0 tune_loop: OUT (#FE), A DEC D :NOTE 1 (highs) JR NZ,tl_1 LD D,H XOR #18 tl_1: DEC E : NOTE 2 (lows) JR NZ,tl_2 LD E,L XOR #18 tl_2: DJNZ tune_loop DEC C JR NZ, tune_loop POP HL LD (HL),56 POP HL LD (HL),56 POP DE CALL test_enter ;#9337 RET NZ JR manic_loop ; NOTE_PLACE: LD HL,#59e0 ; with this code, the piano address can be at the start of any attribute line SUB 8 CPL STEP1_INDEX RRCA RRCA RRCA and 31 STEP_INDEX: ADD A,L LD L,A ADC A,H SUB L LD H,A LD A,(HL) RET ; TIME_SHIFT: DB 25,50,80,100 NOTE_SHIFT: DB 0, 1, 6, 8, 10, 11, 13, 20, 21, 24, 32, 43, 75, 77, 128, 154 ; Tune_Data: DB 2+8*1,128 DB 2+8*1,102 DB 2+8*1,86 DB 1+8*1,86 DB 1+8*10,171 DB 1+8*3,43 DB 1+8*3,43 DB 1+8*10,51 DB 1+8*6,64 DB 1+8*6,64 DB 1+8*10,171 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*4,86 DB 1+8*8,171 DB 1+8*4,43 DB 1+8*4,43 DB 1+8*8,171 DB 1+8*7,48 DB 1+8*7,48 DB 1+8*8,171 DB 1+8*1,136 DB 1+8*1,136 DB 1+8*1,114 DB 1+8*1,76 DB 1+8*1,76 DB 1+8*8,171 DB 1+8*8,38 DB 1+8*8,38 DB 1+8*8,171 DB 1+8*7,48 DB 1+8*7,48 DB 1+8*8,171 DB 1+8*1,136 DB 1+8*1,136 DB 1+8*1,114 DB 1+8*1,76 DB 1+8*1,76 DB 1+8*10,171 DB 1+8*6,38 DB 1+8*6,38 DB 1+8*10,171 DB 1+8*6,51 DB 1+8*6,51 DB 1+8*10,171 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*1,64 DB 1+8*11,128 DB 1+8*5,32 DB 1+8*5,32 DB 1+8*11,128 DB 1+8*3,43 DB 1+8*3,43 DB 1+8*11,128 DB 1+8*1,128 DB 1+8*1,128 DB 1+8*1,102 DB 1+8*1,86 DB 1+8*1,64 DB 1+8*9,128 DB 1+8*2,32 DB 1+8*2,32 DB 1+8*9,128 DB 1+8*4,38 DB 1+8*4,38 DB 1+8*0,0 DB 1+8*1,114 DB 1+8*1,114 DB 1+8*1,96 DB 1+8*1,76 DB 1+8*13,76 DB 1+8*1,77 DB 1+8*1,77 DB 1+8*13,76 DB 1+8*1,91 DB 1+8*1,86 DB 1+8*15,51 DB 1+8*1,51 DB 1+8*1,51 DB 1+8*15,51 DB 1+8*1,64 DB 1+8*1,102 DB 1+8*1,102 DB 3+8*1,114 DB 1+8*1,76 DB 1+8*1,86 DB 1+8*12,128 DB 0+8*14,128 DB 0+8*1,128 DB 1+8*12,128 DB 0 ; Addendum:- slight change shortens code by 3 more bytes so around 73+ bytes smaller.

Compressed the data and the optimised the code routine size. I have since chopped another fives bytes of the routine, so around 62 bytes smaller. Going solely from your data of eight bytes. I assume a saving of around 70 bytes from the original.

The delay in response is simply caused by having no knowledge that comments had been placed here. The yellow target sprite. Signifies that objects collected in this room, will increase the rubber tipped darts catch that Willy fires at other sprites. I am pleased that the icon I drew managed to convey what is was.... A dart hitting a dart board. (at no stage is another sprite harmed by being hit by these very soft rubber capped darts. All that happens is they are instantly transported to a safe place. To await re-emergence in the room) The version VL5 is old . The version I have now is considerably faster, and has several improvements. The increase in speed is significant and I realised that rather than just slowing down the game when the slower modes are activated. It is just as easy to play the music. This means that rather than the background clicking of a note, in the slow game versions, I play actual notes (if music is turned off, it still uses the music routine, but sound output is disabled from the routine) I have also added a new set of title graphics and a lot of other changes. No room or game layout changes. The speed increase as stated is considerable, I am tempted to re-visit version VK and implement the changes to allow that to benefit from the change in logic. ( the amount of code change is vast - A couple of days work minimum, copying and changing routines from VL to VK. No plans to do in the near future ) ------------------------------------------------------------------------------------------------------------------------------------ The speed increase was caused by wondering if I could change the format of JSW so that it plays a full screen game. The bigger screen size would cause a possible 50% drop in speed. So I added some code to increase the game speed to compensate for a possible slow down. The previous statement does not indicate that the added code was actually a major change in how the game works. I was curious to see how much effort it would take to do this change and a demo version of Vl5 was written ----Expecting major problems ------ So I was pleased when I found that the basic idea worked, and it has subsequently been updated and improved. My speed standard , the double room walk, in this demo version can be done in 8.3 seconds. (the origin JSW takes 20 seconds) The tests conclude that a full screen game is an option. The problem for me is that the amount of change needed is, as always, considerable. Which is not really an option from the game data layout that I have at present. To implement a full screen game I would need to start back at the basic original code. To start again I would need to yet again construct an assembler listing that is relocatable. (*** note 1) For example taking Skoolkits listing, the source code generated is far from being a usable source listing for what I aim to do. There are far too many fixed page references, and offsets specific to the game. These all need changing and this in itself is a big job. This I do by manually editing the code, line by line reference by reference. If you saw my listings you would see the difference in layout. I let the computer/assembler do the calculations. The source code I generate from doing this is quite a lot different from what is seen in typical listings. Perhaps I should set my next task as being the output of a workable source code for JSW. ------------------------------------------------------------------------------------------------------------------------------------ Note 1. When constructing my version of the source code, I always succumb to temptation and edit the code as I edit the layout. This means I have never had an unmolested relocatable working source code. , . ! ,,, ...! .''...

My original edit of this from around six months ago is only 12 bytes shorter than the post #0 I admit I have had numerous attempts at shrinking the code, in most case the end result stayed about the same size. So those numerous attempts where deleted months ago. I did however try one more time to edit this routine, and I did save a few bytes. My final edit for the overall Manic Miner Music routine is around 57 bytes smaller than the Music routine from post #0 I did however try one more time to edit this routine, and I did save a few bytes. My final edit for the overall Manic Miner Music routine is around 57 bytes smaller than the overall Music routine from post #0 So you know it can be done. Addendum The music routine consists of two parts. The code to play the music and the music data. One without the other serve no purpose in the game.

If the zero's are changed to any other value you can move the illuminated note up to any position, as long as they both stay the same value, you will still have silence. Which does not change the fact that the keyboard illuminates. Since the design of the keyboard looks like it was constructed from several broken ones. Lets just assume that the far left key is not working, and when struck the keyboard makes no noise.