Norman Sword

New code:- based on a quick re_write as illustrated by the small heads demo. Part 1) The original uses a big data table to colour in the status area of the screen. And a similar table to colour in the colour table entry screen. That table is just as easy to compress, but I will ignore that data here and concentrate only on the lower screen attribute area and its data. The original lower screen data:- situated in memory in the original game at $9a00 ;9A00: Attributes for the bottom third of the screen bottom_att DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 DEFB $46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46,$46 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $01,$02,$03,$04,$05,$06,$07,$07,$07,$07,$07,$07,$07,$07,$07,$07 DEFB $07,$07,$07,$07,$07,$07,$07,$07,$07,$07,$06,$05,$04,$03,$02,$01 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $45,$45,$06,$06,$04,$04,$41,$41,$05,$05,$43,$43,$44,$44,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $45,$45,$06,$06,$04,$04,$41,$41,$05,$05,$43,$43,$44,$44,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 DEFB $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00 This data was moved to the lower screen with:- Code at $8907 LD HL,bottom_att ; 8907 ;L9A00 LD DE,ATT16 ; 890A ;$5A00 LD BC,$0100 ; 890D ; LDIR ; 8910 ; and code at $8b07 LD HL,bottom_att ;L8B07 ;L9A00 LD DE,ATT16 ; 8B0A ;$5A00 LD BC,$0100 ; 8B0D ; LDIR Both of these LDIR routines are replaced with a call to draw_bottom_att which is new code sitting in ram somewhere. This code is draw_bottom_att ld de,ATT16 ld ix,bottom_att ld hl,bottom_translate ; expander sub expand: ld (S_M_C_translate),hl draw_logo_loop ld a,(ix) inc ix cp 255 ret z S_M_C_translate equ $+1 ld hl,bottom_translate ;logo_translate << edited to remove this undefined label (in the code here) call indexer expand1 ld (de),a inc de djnz expand1 jr draw_logo_loop ;======================================================================= ; expander sub routine indexer ld c,a rrca rrca rrca rrca and 15 inc a ld b,a ld a,c and 15 ; + index into hl via "a" and return (hl+"a") in "a" index1 add a,l ld l,a adc a,h sub l ld h,a ld a,(hl) ret Looking at the lines and lines of code used above, you might be left wondering how all that saves any memory compared to a simple LDIR. A very quick count of the code comes in at 53 bytes. Now remember the original data was 256 bytes, so we need to be able to save at least 53 bytes. Any more than that and it is smaller in size. But we also get a subroutine which can be used in various ways as a bonus. So here is the original compressed bottom_att db $f8,$f8 db $f0,$f0 db $f0,$f0 db $01,$02,$03,$04,$05,$06,$97,$97,$06,$05,$04,$03,$02,$01 db $f0,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $19,$16,$14,$1a,$15,$1b,$1c,$10,$f0 db $f0,$f0 db $ff bottom_translate: ; 0 1 2 3 4 5 6 7 8 9 a b c db 0,$01,$02,$03,$04,$05,$06,$07,$46,$45,$41,$43,$44 The above is less than 60 bytes (around 56) which means the code plus the data is less than 120 bytes. a saving of over 130 bytes. It is possible to use this method to compress the logo. (with decent gains, but there are better ways)

The heads are stored in a table, which stores only one definition for each head. The clever part is to use a pile of code to extract the heads, and reverse and shift each definition and place it over the original. Maybe not as noticeable but all willies animation is changed so that Willy has eight frames of animation in both directions.

Using the source code I provided. I spent a day changing and deleting code. This is an illustration of what can be achieved in a day. Main point to this demo is the change in animation and definition of willy Addendum:- What else was changed 1) The clock routine. re written to correct the am/pm problem. (Smaller code) 2) sprite glitch and screen copying. Uses LDI and raster copy (visual update) 3) Constant update of status line and dancing willies. Only updates if needed (faster+smaller) 4) The room draw uses my method of expansion and no compares. (faster + a lot smaller) 5) deletion of all code asking for the colour code at the start (more free space) 6) rewrite of the cheat input (faster+smaller) 7) changed all the sprite routines (faster) 8) removed rope bug 9) Changed logo draw expansion routine (twice) (a lot smaller) 10) changed method of colouring in the lower screen (a lot smaller) 11) changed every LDIR over 20 bytes to ldi (faster) 12) changed every keyboard reference to ports. Removed usage of BC registers when reading ports (consistent-bug removal-smaller) How many variations of Willy, are their is in this demo. Ignoring the flying pig there are 16 definitions. HeadsJSW.tap

Raw6jsw.zip View File This is just an assembly listing of Jet Set Willy, which is not the same as a disassembly. Since this uses the skoolkit disassembly as its basis, It has been placed here so it is not viewable to none members. The change from a disassembly makes the code a lot easier to understand and also a lot easier to edit. Submitter Norman Sword Submitted 06/21/2019 Category Other resources  

JET SET WILLY SOURCE CODE I mentioned a long time ago that I would eventually upload a source code for Jet Set Willy. This I have done and the code is in the download section, under "other resources". The version is Raw6jsw.asm but the 6 is just indicating that 6 steps were needed in its evolution from a disassembly Hope its of use to someone. The listing will assemble in Pasmo and output the game....

The simpler alternative is as follows LD HL,#3030 LD (#857C),HL LD (#857D),HL 9 bytes. Which is another byte shorter

Checking the ld hl,(counter) Zilog claim 16T states. So that's good enough for me. This was not a clinical dissection, it was me wondering why the game ran so slow. With the heading a stack copy version of Jet Set Willy I was expecting a bit of zip in the movement. The addition mistake and the subsequent error I will correct. ============================================= Just to be doubly sure I have dug out an old copy of Rodney Zaks. Page 334 16 T states

screen copies:- Here I will talk about the main feature of this version, which is the usage of a stack copy routine. Whilst the game is playing, the program has a multitude of screen data to copy. These copies are the main slowing down of the game. The amount of data that is copied consists of an attribute screen and a pixel or data screen. These are copied repeatedly. The order of copies might not be exactly as I write them out. Each game loop:- Starts by copying the Master Attribute area (512 bytes) to the working Attribute area of ram It then copies the Master Pixel area (4096 bytes) to the working pixel area of ram The body of game -- moves and draws the sprites Then game loop continues and:- Copies the working pixel area of ram to the Viewable screen (4096 bytes) Followed by the working attribute area of ram to the Viewable screen attribute area of ram (512 bytes) Goes back and repeats each game loop The above is moving for the copying of screens a total of 9216 bytes This shows a lot of memory is copied on each game loop, and ways to speed this up, will have a dramatic effect on the games overall speed So from here on I will partly discus the main methods for copying huge chunks of memory. The three most commonly used on a spectrum are 1) LDIR 2)LDI 3)stack copy. written in normal order of speed The best way to look at a copying routine, is to look at how long each method takes to move one byte. A copy routine is after all just moving bytes of memory. . Here I will split the time into two parts, the first part is the time it takes to move the single byte in the idealised form. And then the overhead needed to perform the copy in a loop. The reason I split the timing is because the idealised part of the timing has to be performed. The idealised part will always be written and we have no option but to write and execute that part of the code. The overheads are the parts that can be changed by the programmer and the overheads are the programmers responsibility. . The idealised speed of moving a single byte . The idealised times are the times that the basic op code(s) takes to move one byte . Idealised times . LDIR 21 T states per byte . LDI 16 T states per byte . Stack copy - pop and push - 2 bytes at 10.5 T states per byte . . The overheads for the loop With LDIR their are no loop overheads. We set the up the data for the op code, then execute it. The LDIR executes its own internal loop . With LDI the main overheads are dictated by how much the LDI is rolled out. Fastest possible loop, using inline code has only one op code to perform the loop. With a stack copy we need lots of op codes to perform the loop. The amount used is up to the programmers imagination. Here the only code looked at, is the code used by Mark Woodmass. Total time to move the byte adding the overheads LDIR -- this stays at 21 T-states, being the sum of the idealised op coded time and no overheads . LDI -- this would normally be written as a loop macro- but for clarity I will write it out I have picked a roll out of 32 LDI's, the more we have the faster it is. But having more and more rolled out brings decreasing gains. I have picked 32 as a good starting point. The copy loop using LDI loop: LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI LDI jp pe,loop 10 T-states . here we have added for every 32 bytes moved a "jp pe,loop" into the loop overheads . This takes 10 T-states. This overhead is divided by how many bytes where moved in the loop . so the overheads are 10 T-state/32 or 0.3125 T-states or (0.3 T-state approx) , so negligible compared to the 16 T-states of each byte moved. This is moving a byte in around 16.3 T-states . . . Stack copy using Pop push. now lets look at the stack copy as used by Mark Woodmass the body of the loop is ; overhead T-state / Total T-states loop: ld sp,ix 10T 10T pop hl pop de pop bc pop af ex af,af' 4T 14T exx 4T 18T pop hl pop de pop bc pop af ld sp,iy 10T 28T push af push bc push de push hl exx 4T 32T ex af,af' 4T 36T push af push bc push de push hl ld de,$10 10T 46T add ix,de 15T 61T add iy,de 15T 76T ld hl,(counter) 16T 82T 92T << correction of addition. (subsequent text altered to correct mistake) dec (hl) 11T 93T 103T jr nz,loop 12T 105T 115T We move 16 bytes , but we have an overhead to add onto the pop and push ideal of 10.5 T-states The overhead per byte is 115/16 T-states or 7.1875 T-states (7.2 approx) This routine moves every byte at an idealised speed of 10.5 T-states, to which we now add the overheads per byte of 7.2 T-states. Giving an overall speed of 17.7 T-states for each byte moved. ------------------- Summery of total times taken to move a single byte in T-states Total time Ideal Time overheads LDIR 21 T-states 21 T-states 0 LDI 16.3 T-states 16 T-states 0.3 Stack Copy 17.7 T-states 10.5 T-states 7.2 T-states (Mark Woodmass version) Stack Copy 13.1 T-states 10.5 T-states 2.6 T-states (last version I wrote. See addendum) ------------------------- The version of stack copy used in this version of the game has managed to be slower than a very very simple rolled out LDI loop This is a good example of being told that the stack copy method is the fastest method, and then writing some code to show how the version you write, manages to be slower. ***************************************************************************************************************************************************** Addendum:- In order to make a stack copy routine fast, we need to reduce the overheads to a minimum. This is best achieved by rolling the code out in a similar way that LDI is rolled out to cut the overheads. With stack copy rolling out the code consumes a lot of ram. But if we want the benefit of the speed the routine can bring. Then we must roll the code out and sacrifice the ram. In the last version of a stack copy I wrote. The main loop was slightly under 300 bytes in size. but the overheads per byte was around 2.6 T-states (the figures quoted are from a quick look at some of my code. the exact figures are unimportant. I am just trying to show how far the overheads can be reduced) ***************************************************************************************************************************************************** ** NOTE** The idealised times for stack copy can be influenced by using the of IX and IY registers as part of the push pop registers. The above is an attempt at simplicity. We look only at the overheads and ignore the registers used. (I am not trying to explain in great detail) **NOTE** In the original timing for "LDI". I used 1/3 this has been changed from 1/3 to .3. to correct inconsistency in numeric notation.

View File Manic Miner By S.P. And Bug Byte When Matthew wrote manic Miner he released the game originally with Bug Byte. When he re-released the game with Software projects some small changes were made to the graphics. This version is not a new version of the game and its main novelty is the ability to swap between the versions of the game. Whilst I made minimal change to the games playing style or data I changed some of the ways that the game plays. This is not a simple edit of the game it is a rewrite but leaves the basic data intact. I have added :- item collection sounds. sound effects for being hit by the solar ray sprite collision sound effects heavy landing sound effects. death collision graphic and sound effect an extensive cheat. an explanation to why you have died an animation of the high score being added a redraw of the title screen (fixing the keyboard graphics) a title screen animation of a spectrum analyser a credits screen a title screen animation showing the version about to be played (Bug Byte graphic or S.P. graphic) a sprite mask on the main character a redesign on how the screens update (to stop sprite glitching) the list of changes is extensive (Some listed above) the overall feel will still be that you are playing the original Manic Miner. This file is listed elsewhere on this site, Having been asked by several people where this file is listed, I realise it needs to be placed in the Manic Miner Download section so it can be found easier. Submitter Norman Sword Submitted 05/17/2019 Category Manic Miner [Remakes]  

"jagged finger fix by Norman Sword" The fix used to reduce the jagged finger look in the file mention in Post#7 is basically a copy of the code I placed on this website. So it comes as a surprise that someone else has fixed this problem. Have they really? It seems to me that they have used my code. This site mentions so often things like Goeff mode etc that this partial fix to this problem should be call "jagged finger fix by Norman Sword". It was a problem that prior to my posts, was not fully understood in it's nature or how to remove. The code used to partially cure this problem is basically the code I wrote. : ; If you have a problem with what I say here then please show me any code prior to the code I listed that did anything of the same nature. Or any version of jsw(1) that fixed the problem prior to my posts.

The choppy description is basically what I have described as the jagged finger effect, and is nothing to do with television / monitor effects. Otherwise every version would exhibit the same effect on every game format. Since they don't it is evident the effect is game produced on the original spectrum version. Play any of my versions jsw128 VK or jsw128 VL and the problem does not exist.

Slight edit. Due to the original wording, which refers to five bytes. A figure I did not question and repeated ad verbatim. However the figure should be six bytes. So an edit to correct and also change/delete some words which are misleading. --------------------------------------------------------------------------------------------------------------------------------------------------- The code is monitoring 32884 (#8074) for the release of angry Eugene. This can be changed to monitor one of the objects directly, and the best choice is the object closest to the portal. Since the order of collection is well known, this is probably not going to be noticed by the normal player. This suggested change is aimed more at a new room design and pushing towards your original goal of resetting the room in Manic Miner, but not the objects. You can change both the references to 32884(#8074) to one of the following, or even change either reference to one of the following. (mix and match) Object 1 stored at 32885 (#8075) position (1,30) Object 2 stored at 32890 position (6,10) Object 3 stored at 32895 position (7,29) Object 4 stored at 32900 position (12,7) Object 5 stored at 32905 position (12,9) The logical change is to point at 32905 which is the object closest to the portal. The reason for the suggested change is that it would indicate which object triggers the anger of Eugene and collecting that object, would make Eugene change colour and descend. Collecting the trigger object before the other objects are collected would send a powerful message that that object must be left till last. This suggested change was so a room reset, would only need to reset the last object and the room would be re playable. This suggested change unfortunately does not achieve that goal. The player could ignore Eugene and carry on collecting objects. Then the last object collected would no longer be the trigger object and we are back to square one. ----------------------------------------------------------- Still might be interesting to change the logic so it monitors just one object and not wait till all objects collected.

Modifying Angry Eugene Minimum needed to modify both routines is 2 bytes ------------------ The first one byte modification --------------------------------- The first six byte routine, only needs the last JR Z,XX offset changing to 0 S.P. Version: The six bytes in question are 36355 to 36360 36355 LD A , (32884) 36358 OR A 36359 JR Z , 36378 >>>> Poke 36360,0 ---- This changes the code to JR Z,36361 B.B. Version: The six bytes are at 36344 to 36349 36344 LD A , (32884) 36347 OR A 36348 JR Z , 36367 >>>> Poke 36349,0 ---- This changes the code to JR Z,36350 This above just changes how far the relative branch has to jump. ------------- The second one byte modification -------------------------- The second modification is as you stated (slightly edited) Change the byte at 36449 from 32 to 24, this changes the instruction at 36449 from JR NZ,XXX (Jump Relative Non Zero,offset) to JR XXX (Jump Relative, offset) Original: 36449 JR NZ , 36458 Changed: 36449 JR 36458 B.B. Version: Again the same thing just in a slightly different place change the byte at 36438 from 32 to 24 to effect a change from a JR NZ to a JR: Original: 36438 JR NZ , 36447 Changed: 36438 JR 36447 ------------------------------- Total modification 2 bytes

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)