Norman Sword

The JSW title screen has a lot of code creating the variances on the JSW logo. The colours (inks and papers) are mixed up by a randomising routine. Which just for the back ground penrose triangle can give 210 differing  colour combinations. On top of those colour changes the text has differing effects and colour changes. So the colour combinations for the title screen should run into the thousands. 

The JSW title screen has a lot of code creating the variances on the JSW logo. The colours (inks and papers) are mixed up by a randomising routine. Which just for the back ground penrose triangle can give 210 differing  colour combinations. On top of those colour changes the text has differing effects and colour changes. So the colour combinations for the title screen should run into the thousands. 

I notice that you've also fixed the errant colour attribute in the sloping inner corner of the impossible triangle which Matthew had in the original JSW (it was partly obscured by the original block lettering, but you could see it if you looked carefully).

The JSW title screen has a lot of code creating the variances on the JSW logo. The colours (inks and papers) are mixed up by a randomising routine. Which just for the back ground penrose triangle can give 210 differing  colour combinations. On top of those colour changes the text has differing effects and colour changes. So the colour combinations for the title screen should run into the thousands. 

When the cash reaches £00000 a new life is not avaialable .... LOOK and observe the FLASHING £00000 value

When the cash reaches £00000 a new life is not avaialable .... LOOK and observe the FLASHING £00000 value

When the cash reaches £00000 a new life is not avaialable .... LOOK and observe the FLASHING £00000 value

The version is now v3.01  ---- it managed to be  just v3 from mid 2022 to jan 1st 2023 --- ... More haste less checks ---

The edit I did was 

if object = nul ---- was changed from
if object = 0 

The edit does not give the same result 

It does however make the objects invisible ----

 
 

View File Manic Jet Set Willy V3
The last version I do of the combined Jet set Willy and Manic Miner. Time wise I only spent a few weeks on the main code. Overall I just kept on changing the file and adding bits and pieces to the game. No overall attempt at changing the original game play. 

This file runs on a standard 48k spectrum and could have been released at the same time as the originals were released.


 
Keys on title screen -
<1>                                  =change playing mode ,
<enter>                           = start game

game keys -
<enter>                          =  toggle music on/off,
<H>                                =  faster game play, shorter music notes
<J>                                 =  slower game play, longer music notes
<ASDFG>                       =  pause, - display the high score
<QETUO>                       =  Move left,
<WRYIP>                        =  move right,
<ZXCVBNM>+<space> =  jump.

objective collect the flashing keys, and accumulate monies

Difference from normal JSW and MM - A heavy fall or touching sprites or baddies will cost monies from Willies ready cash.
The solar beam will cost a lot of monies on contact with Willy.
Dropping Kong gains a lot of monies.

But do keep an eye on your ready cash - when it has all gone - it is game over. 
 
This game is the compaction of Jet Set Willy and Manic Miner both originally 48k games. The compaction of the games allows for both to run (modified) in 48k.
 
 
 
 
 
 
Submitter Norman Sword Submitted 01/01/2023 Category Jet Set Willy [Remakes]  

View File Manic Jet Set Willy V3
The last version I do of the combined Jet set Willy and Manic Miner. Time wise I only spent a few weeks on the main code. Overall I just kept on changing the file and adding bits and pieces to the game. No overall attempt at changing the original game play. 

This file runs on a standard 48k spectrum and could have been released at the same time as the originals were released.


 
Keys on title screen -
<1>                                  =change playing mode ,
<enter>                           = start game

game keys -
<enter>                          =  toggle music on/off,
<H>                                =  faster game play, shorter music notes
<J>                                 =  slower game play, longer music notes
<ASDFG>                       =  pause, - display the high score
<QETUO>                       =  Move left,
<WRYIP>                        =  move right,
<ZXCVBNM>+<space> =  jump.

objective collect the flashing keys, and accumulate monies

Difference from normal JSW and MM - A heavy fall or touching sprites or baddies will cost monies from Willies ready cash.
The solar beam will cost a lot of monies on contact with Willy.
Dropping Kong gains a lot of monies.

But do keep an eye on your ready cash - when it has all gone - it is game over. 
 
This game is the compaction of Jet Set Willy and Manic Miner both originally 48k games. The compaction of the games allows for both to run (modified) in 48k.
 
 
 
 
 
 
Submitter Norman Sword Submitted 01/01/2023 Category Jet Set Willy [Remakes]  

When I finished version 1 of Manic Jet Set Willy. I was already aware of a problem - which was subsequently mentioned by others.
The problem was caused by the editor having a column mode. Which I use occasionally to copy data and very rarely to delete data. The problem with using the column mode is the editor allows hard tabs and spaces to exist in the same text. The column mode struggles to understand where the visual columns are and as a result can do strange things. What it highlights and what it does are two differing things.
At some stage during the last release of MJSW (Manic Jet Set Willy) I deleted a great quantity of old code and at the same time deleted a good deal of the comments that, due to editing, meant nothing for the code displayed.
So I casually deleted a great deal of obsolete comments by using the column select and delete method. What I had not noticed was the delete has a bug in it. Which is different to the mess it normally creates. When a column is selected the program deletes all the data and can delete an extra byte on the last line. So it will correctly delete a column of 40 comments, but for the last comment deletes one byte extra. 
This was not noticed by me, and as I was at that time unaware of the problem (It was unusual usage from me) and it went undetected.
What this did was it deleted a bit from a binary value. So:- (as an example)
h_common:
    ld    a,d                       ; transfer        
    cp    e                         ;  limit  
    jr    nz,h_move           ; 
h_reset:
    ld    a,(ix+#00)         ; data
    and    %000$11111  ; mask
      
is edited by the block delete to    
    
h_common:
    ld    a,d            
    cp    e            
    jr    nz,h_move
h_reset:
    ld    a,(ix+#00)    
    and    %000$1111    
    
which does not look a great deal different amongst 15,000 other lines of data and code.
It does however create a bug.
Since I had already stated I was not updating the code for a year. It also meant I was not updating the code I had written with a fix. 
--------------------------------
A few days after the release I decided to undertake a revamp on the method of compression. (not explained here)
The revamp on the compression method allowed more free memory to be released. 
The chance to change the method of play and integrate the two parts was my next challenge. So a new version was undertaken at the end of December 2021 and completed before the end of the month in 2021. Since I was not releasing an update of V1    I decided that V2 would not be released until 12 months after V1. 

Since it is now December 2022, the file I wrote is included here. 
This file should have a loading picture. I have not attached the loading picture to the game update. I include here only a .PNG image of the loading picture taken from a zx spectrum screen. 
-------------------------------
Mid 2022 I was casually playing with data and sprites - and wondered if I could implement a new method of drawing the sprites which would also store the data differently. Over a couple of days I implemented the new method in JSW and in MJSW. It proved the concept worked and it also released more free memory. I have spent the last 6 months with the help of Spider changing V2 and adding a lot more data and graphics. The new version is known as V3.  V3 is probably more in keeping with what I had originally planned on doing. V3 will be released Next year (probably Jan 1st 2023)  
 
Note - game wise V3 is only modified slightly from v2 - 4 more rooms and slight edits in some rooms- This was not meant to change the game play. The scope of the changes was adding graphics and making the transistions between screens more flowing. These versions contain both Manic Miner and Jet Set Willy. V3 contains more graphics than either of the original game versions. So the Manic Miner part of MJSW has all the necessary graphics of the original version. In a similar way the JSW part of MJSW has more graphics than the original JSW. In fact the JSW title screen has far more variaties than the same JSW title screen, and yet both the games of JSW and MM  and comapcted to fit into the 48k of the original games.

 
------------------------------
Due to circumstances - this is my next to last game file post and the posting of V3 will be my last.
ADDENDUM - I have found the original .scr spectrum screen for the .png picture. So I will add on here the .scr picture - should be attached to the start of the file and displayed as the primary loading screen.
 

MJSw_v2.tap
MSJS_PIC.scr

When I finished version 1 of Manic Jet Set Willy. I was already aware of a problem - which was subsequently mentioned by others.
The problem was caused by the editor having a column mode. Which I use occasionally to copy data and very rarely to delete data. The problem with using the column mode is the editor allows hard tabs and spaces to exist in the same text. The column mode struggles to understand where the visual columns are and as a result can do strange things. What it highlights and what it does are two differing things.
At some stage during the last release of MJSW (Manic Jet Set Willy) I deleted a great quantity of old code and at the same time deleted a good deal of the comments that, due to editing, meant nothing for the code displayed.
So I casually deleted a great deal of obsolete comments by using the column select and delete method. What I had not noticed was the delete has a bug in it. Which is different to the mess it normally creates. When a column is selected the program deletes all the data and can delete an extra byte on the last line. So it will correctly delete a column of 40 comments, but for the last comment deletes one byte extra. 
This was not noticed by me, and as I was at that time unaware of the problem (It was unusual usage from me) and it went undetected.
What this did was it deleted a bit from a binary value. So:- (as an example)
h_common:
    ld    a,d                       ; transfer        
    cp    e                         ;  limit  
    jr    nz,h_move           ; 
h_reset:
    ld    a,(ix+#00)         ; data
    and    %000$11111  ; mask
      
is edited by the block delete to    
    
h_common:
    ld    a,d            
    cp    e            
    jr    nz,h_move
h_reset:
    ld    a,(ix+#00)    
    and    %000$1111    
    
which does not look a great deal different amongst 15,000 other lines of data and code.
It does however create a bug.
Since I had already stated I was not updating the code for a year. It also meant I was not updating the code I had written with a fix. 
--------------------------------
A few days after the release I decided to undertake a revamp on the method of compression. (not explained here)
The revamp on the compression method allowed more free memory to be released. 
The chance to change the method of play and integrate the two parts was my next challenge. So a new version was undertaken at the end of December 2021 and completed before the end of the month in 2021. Since I was not releasing an update of V1    I decided that V2 would not be released until 12 months after V1. 

Since it is now December 2022, the file I wrote is included here. 
This file should have a loading picture. I have not attached the loading picture to the game update. I include here only a .PNG image of the loading picture taken from a zx spectrum screen. 
-------------------------------
Mid 2022 I was casually playing with data and sprites - and wondered if I could implement a new method of drawing the sprites which would also store the data differently. Over a couple of days I implemented the new method in JSW and in MJSW. It proved the concept worked and it also released more free memory. I have spent the last 6 months with the help of Spider changing V2 and adding a lot more data and graphics. The new version is known as V3.  V3 is probably more in keeping with what I had originally planned on doing. V3 will be released Next year (probably Jan 1st 2023)  
 
Note - game wise V3 is only modified slightly from v2 - 4 more rooms and slight edits in some rooms- This was not meant to change the game play. The scope of the changes was adding graphics and making the transistions between screens more flowing. These versions contain both Manic Miner and Jet Set Willy. V3 contains more graphics than either of the original game versions. So the Manic Miner part of MJSW has all the necessary graphics of the original version. In a similar way the JSW part of MJSW has more graphics than the original JSW. In fact the JSW title screen has far more variaties than the same JSW title screen, and yet both the games of JSW and MM  and comapcted to fit into the 48k of the original games.

 
------------------------------
Due to circumstances - this is my next to last game file post and the posting of V3 will be my last.
ADDENDUM - I have found the original .scr spectrum screen for the .png picture. So I will add on here the .scr picture - should be attached to the start of the file and displayed as the primary loading screen.
 

MJSw_v2.tap
MSJS_PIC.scr

Jumping arc of travel.

It is noticable that when Willy does his sumersault jump, that one frame after the rotation part of the sumersault. Seems to be out of sync. This gives the visual feedback of pausing animation and moving horizontal mid jump. Crude picture to try and explain better. (moving from left to right) 
 

The 147 rooms (in 48k) for jsw2+

The 147 rooms (in 48k) for jsw2+

Contended memory stretches timing cycles. It has a big impact.

Note this code is designed to waste time - it rotates a block of memory and then copies the block of memory to the screen. Most of the work is done by the rotate part, but be aware that if it is displayed on the screen then a large chunk of the routine that is  moving data into contended memory is being hampered by the contended memory problem.

The routine starts by changing the border colour (at the top of the video screen) and when finished changes the border again (bottom of the screen). On my pc the border colour change is aligned with the  bottom of the screen for both parts.

The routine running in contended memory,  loops and rotates 625 bytes.   (border BLUE - ends when the border turns RED)

The 2nd routine running in uncontended memory, loops and rotates 625+88=713 bytes E.G it loops 713 times (Border MAGENTA, ends on GREEN)
The timing of both routines is near enough exactly the same. Yet one has managed 625 loops and the other 713 loops.

The difference is very measuarable.

 

    org    #7fA0

amount        equ    625
high_amount    equ    625+88
low_s        equ    #7000
high_s        equ    #9000

start:
    LD    HL,#4000
    LD    (HL),0
    LD    DE,#4001
    LD    BC,192*32
    ldir
    ld    bc,24*32-1
    ld    (hl),7
    LDIR
    ld    sp,#ffff
part1
    ld    hl,low_s
    ld    bc,amount
    ld    a,1
    call    init
loopy    push    bc
    halt
    ld    a,1               
    out    (254),a   ;<<<< set the border BLUE
    ld    bc,amount
    ld    hl,low_s
    push    hl
    push    bc
loop    rlc    (hl)
    inc    hl
    dec    bc
    ld    a,b
    or    c
    jr    nz,loop
    pop    bc
    ld    de,#4000
    pop    hl
    ldir
    ld    a,2
    out    (254),a   ; Set the border RED
    pop    bc
    djnz    loopy
    jp    part2

init    ld    e,l
    ld    d,h
    inc    de
    ld    (hl),a
    ldir
    ret
    org    #8000
part2:
    ld    hl,high_s
    ld    bc,high_amount
    ld    a,254
    call    init
high_loopy:
    push    bc
    halt
    ld    a,3
    out    (254),a    ; set the border MAGENTA
    ld    bc,high_amount
    ld    hl,high_s
    push    hl
    push    bc
high_loop:
    rlc    (hl)
    inc    hl
    dec    bc
    ld    a,b
    or    c
    jr    nz,high_loop
    pop    bc
    ld    de,#4000
    pop    hl
    ldir
    ld    a,4
    out    (254),a    ; set the border GREEN
    pop    bc
    djnz    high_loopy
    jp    part1
    end    start

Contended memory the upper border is BLUE, when the routine finishes it turns RED

Uncontended memory the upper border is MAGENTA when the routine finishes the border turns GREEN

 
 
The 2nd file - sets the loop counter to be the same  (in contended and uncontended) (e.g. it loops 625 times in contended and loops 625 times in uncontended) , the amount of time saved is shown by the movement of the border change.  


 
CONTEN~1.tap
Contend_same amount.tap

Jumping arc of travel.

It is noticable that when Willy does his sumersault jump, that one frame after the rotation part of the sumersault. Seems to be out of sync. This gives the visual feedback of pausing animation and moving horizontal mid jump. Crude picture to try and explain better. (moving from left to right) 
 

Contended memory stretches timing cycles. It has a big impact.

Note this code is designed to waste time - it rotates a block of memory and then copies the block of memory to the screen. Most of the work is done by the rotate part, but be aware that if it is displayed on the screen then a large chunk of the routine that is  moving data into contended memory is being hampered by the contended memory problem.

The routine starts by changing the border colour (at the top of the video screen) and when finished changes the border again (bottom of the screen). On my pc the border colour change is aligned with the  bottom of the screen for both parts.

The routine running in contended memory,  loops and rotates 625 bytes.   (border BLUE - ends when the border turns RED)

The 2nd routine running in uncontended memory, loops and rotates 625+88=713 bytes E.G it loops 713 times (Border MAGENTA, ends on GREEN)
The timing of both routines is near enough exactly the same. Yet one has managed 625 loops and the other 713 loops.

The difference is very measuarable.

 

    org    #7fA0

amount        equ    625
high_amount    equ    625+88
low_s        equ    #7000
high_s        equ    #9000

start:
    LD    HL,#4000
    LD    (HL),0
    LD    DE,#4001
    LD    BC,192*32
    ldir
    ld    bc,24*32-1
    ld    (hl),7
    LDIR
    ld    sp,#ffff
part1
    ld    hl,low_s
    ld    bc,amount
    ld    a,1
    call    init
loopy    push    bc
    halt
    ld    a,1               
    out    (254),a   ;<<<< set the border BLUE
    ld    bc,amount
    ld    hl,low_s
    push    hl
    push    bc
loop    rlc    (hl)
    inc    hl
    dec    bc
    ld    a,b
    or    c
    jr    nz,loop
    pop    bc
    ld    de,#4000
    pop    hl
    ldir
    ld    a,2
    out    (254),a   ; Set the border RED
    pop    bc
    djnz    loopy
    jp    part2

init    ld    e,l
    ld    d,h
    inc    de
    ld    (hl),a
    ldir
    ret
    org    #8000
part2:
    ld    hl,high_s
    ld    bc,high_amount
    ld    a,254
    call    init
high_loopy:
    push    bc
    halt
    ld    a,3
    out    (254),a    ; set the border MAGENTA
    ld    bc,high_amount
    ld    hl,high_s
    push    hl
    push    bc
high_loop:
    rlc    (hl)
    inc    hl
    dec    bc
    ld    a,b
    or    c
    jr    nz,high_loop
    pop    bc
    ld    de,#4000
    pop    hl
    ldir
    ld    a,4
    out    (254),a    ; set the border GREEN
    pop    bc
    djnz    high_loopy
    jp    part1
    end    start

Contended memory the upper border is BLUE, when the routine finishes it turns RED

Uncontended memory the upper border is MAGENTA when the routine finishes the border turns GREEN

 
 
The 2nd file - sets the loop counter to be the same  (in contended and uncontended) (e.g. it loops 625 times in contended and loops 625 times in uncontended) , the amount of time saved is shown by the movement of the border change.  


 
CONTEN~1.tap
Contend_same amount.tap

If only bright was used, then usage was technical. However I do not like the Mud versions of the bright colours. Given a choice I tend to use bright. 
Basic background on JSW on the CPC 464.
When tasked with writing the CPC464 version of JSW, I started with the knowledge that Manic Miner on the CPC managed to use all the memory available. So JSW has triple the amount of rooms and that was why I decided to compress everything I could think of. 
The final version called "JSW the final frontier" was supposed to be just my version of JSW on the cpc. It was never intended to be a new version. In fact most things were toned down to stop it diverging too much from the original.
When I was asked if it could be rewritten back on the spectrum, I tentatively said "probably yes". I knew it would not be an easy task. The reason behind the apprehension was because the way the cpc was doing collision detection was based on colour, but was also being drawn directly on the cpc's screen. The spectrum would need to do things differently, and somewhere along the line I would be forced to introduce a copy screen. 
The cpc version used translation colour bytes for the rooms. Most code was an adaptation of the cpc code. The compacted code needed to be even more compacted due to needing to save 4k when moving from the cpc game onto the zx spectrum. All screen draws on the cpc are done on the viewed screen. To stop flicker the drawing on the zx spectrum is done on a copy screen. (that takes a minimum of 4k) In essence if space was available anywhere then it was used. Most of the games running variable data is stored on the screen for the zx spectrum version 

The cpc version on Manic Miner with written On a Tandy Model 4 - with floopy discs
The Cpc version of "Jet Set Willy the final frontier was written on a Tandy Model 4- with floopy discs
The cpc version of "Jet Set Willy" was written on a Tandy Model 4 - with floppy discs
The spectrum version of "Jet Set Willy 2" the final frontier was written on a Tandy Model 4 - with a 20 meg hard drive
The Tandy was running Newdos 80 (disc operating system). The assembler was EDAS by misosys.
Download from Tandy to CPC was done using a z80 dart.
Download from Tandy to zx spectrum was done using a parallel interface - using my own direct download software - taking the Tandy's loading structure as it basis. Which allowed direct disc to memory transfer. Which was nothing like Matthews fixed memory transfer. Where source and destination occupied the same address.
I will elaborate on the transfer. In Matthews case to transfer from the Tandy to the spectrum.  Data is loaded into the Tandy's memory. That data is transferred byte for byte from a location on the Tandy to the same location on the spectrum. - this lead to bugs.
My method interrogated the Tandy's disc loading system, and transfers the disc contents from the Tandy to the address it was assembled at. This meant a re-org of the assembled program, would also be transferred to the new org. No data (apart from one sector) is loaded from the Tandy's disc, when transferring code.

Matthews method also introduced the loss of four rooms into JSW. What Matthew had not realised, was  that the upper memory of the Tandy was dedicated/allocated just for the Hard disc operating system. The hard disc was bought after development of Manic Miner. So the very upper memory on the Tandy was and could be used, whilst he was writing Manic Miner. That same memory was occupied when it came to develop Jet Set Willy. Simply because he had bought himself that 5 meg hard drive.  (I am surprised he did not notice) The upper memory rooms ended up being corrupted and those rooms, were eventually deleted. The upper memory of JSW still contains the TANDy hard drive code, (instead of room data) 
 
The biggest problem (apart from disc size) was the source code needed to be continually stripped of comments and meaningful labels. After a while you get used to seeing what look like meaningless labels. So a label like "main_control_loop"  (which can not be written - max eight letters), gets shortened to "MCL". and slowly you get multiple versions such as MCLx,MCLp  When I first saw the assembly listing again, a few years ago, it was strange to read a label such as "IAOAL"  and immediately say to myself  "I am on a lift"  It was if I had written the label a few moments before I had read it. Yet the time gap was nearly 30 years.

 

Jumping arc of travel.

It is noticable that when Willy does his sumersault jump, that one frame after the rotation part of the sumersault. Seems to be out of sync. This gives the visual feedback of pausing animation and moving horizontal mid jump. Crude picture to try and explain better. (moving from left to right) 
 

An ommision from the above.

The CPC does not have a version of JET SET WILLY2. It has a version that is identical but is called JET SET WILLY - the  final frontier.  

Yet the cpc also contains a version called simply JET SET WILLY. Which might seem confusing, but in a way it does make sense to have the two versions.

Whilst converting  the game from the CPC to the Zx spectrum, I was asked was it possible to reduce the game (on the cpc) back to the original with a mere 60 rooms, eg delete 70+ rooms and leave just the 60 . I answerd it was not a big task, to reduce the size down to less than half. But did question "for what purpose?". The answer was simply to enable the game to be part of they "sold a million" compilation tapes, and strictly speaking the version I had written was not the original jet set willy, it had been more than doubled in size.  Plus the smaller (a mere 60 rooms) version was not going to be sold as a stand alone product. But only on a compilation tape, which meant that both versions could still be sold on the cpc.

Version 1) JET SET WILLY - the final frontier-- 130+ rooms - written first and sold first on the cpc
Version2) JET SET WILLY a mere 60 rooms - sold only on a compilation tape/disc with they SOLD A MILLION compilation. (Beach head, Sabre Wulf,Jet Set Willy, Daley Thompsom-DECATHLON)

The reduction down to the mere 60 rooms of the original was not that difficult. It was just a case of deleting most of the data. I added a high score table to give immediate feedback to the player that it was a different version. But their are visual changes on the title screen as well. (see picture)

And before anyone says that the tail on the title screen looks like a two. It was just a copy of the squiggle on the graffiti. Which on reflection when doing JSW2, I decided to remove.





 

If only bright was used, then usage was technical. However I do not like the Mud versions of the bright colours. Given a choice I tend to use bright. 
Basic background on JSW on the CPC 464.
When tasked with writing the CPC464 version of JSW, I started with the knowledge that Manic Miner on the CPC managed to use all the memory available. So JSW has triple the amount of rooms and that was why I decided to compress everything I could think of. 
The final version called "JSW the final frontier" was supposed to be just my version of JSW on the cpc. It was never intended to be a new version. In fact most things were toned down to stop it diverging too much from the original.
When I was asked if it could be rewritten back on the spectrum, I tentatively said "probably yes". I knew it would not be an easy task. The reason behind the apprehension was because the way the cpc was doing collision detection was based on colour, but was also being drawn directly on the cpc's screen. The spectrum would need to do things differently, and somewhere along the line I would be forced to introduce a copy screen. 
The cpc version used translation colour bytes for the rooms. Most code was an adaptation of the cpc code. The compacted code needed to be even more compacted due to needing to save 4k when moving from the cpc game onto the zx spectrum. All screen draws on the cpc are done on the viewed screen. To stop flicker the drawing on the zx spectrum is done on a copy screen. (that takes a minimum of 4k) In essence if space was available anywhere then it was used. Most of the games running variable data is stored on the screen for the zx spectrum version 

The cpc version on Manic Miner with written On a Tandy Model 4 - with floopy discs
The Cpc version of "Jet Set Willy the final frontier was written on a Tandy Model 4- with floopy discs
The cpc version of "Jet Set Willy" was written on a Tandy Model 4 - with floppy discs
The spectrum version of "Jet Set Willy 2" the final frontier was written on a Tandy Model 4 - with a 20 meg hard drive
The Tandy was running Newdos 80 (disc operating system). The assembler was EDAS by misosys.
Download from Tandy to CPC was done using a z80 dart.
Download from Tandy to zx spectrum was done using a parallel interface - using my own direct download software - taking the Tandy's loading structure as it basis. Which allowed direct disc to memory transfer. Which was nothing like Matthews fixed memory transfer. Where source and destination occupied the same address.
I will elaborate on the transfer. In Matthews case to transfer from the Tandy to the spectrum.  Data is loaded into the Tandy's memory. That data is transferred byte for byte from a location on the Tandy to the same location on the spectrum. - this lead to bugs.
My method interrogated the Tandy's disc loading system, and transfers the disc contents from the Tandy to the address it was assembled at. This meant a re-org of the assembled program, would also be transferred to the new org. No data (apart from one sector) is loaded from the Tandy's disc, when transferring code.

Matthews method also introduced the loss of four rooms into JSW. What Matthew had not realised, was  that the upper memory of the Tandy was dedicated/allocated just for the Hard disc operating system. The hard disc was bought after development of Manic Miner. So the very upper memory on the Tandy was and could be used, whilst he was writing Manic Miner. That same memory was occupied when it came to develop Jet Set Willy. Simply because he had bought himself that 5 meg hard drive.  (I am surprised he did not notice) The upper memory rooms ended up being corrupted and those rooms, were eventually deleted. The upper memory of JSW still contains the TANDy hard drive code, (instead of room data) 
 
The biggest problem (apart from disc size) was the source code needed to be continually stripped of comments and meaningful labels. After a while you get used to seeing what look like meaningless labels. So a label like "main_control_loop"  (which can not be written - max eight letters), gets shortened to "MCL". and slowly you get multiple versions such as MCLx,MCLp  When I first saw the assembly listing again, a few years ago, it was strange to read a label such as "IAOAL"  and immediately say to myself  "I am on a lift"  It was if I had written the label a few moments before I had read it. Yet the time gap was nearly 30 years.

 

An ommision from the above.

The CPC does not have a version of JET SET WILLY2. It has a version that is identical but is called JET SET WILLY - the  final frontier.  

Yet the cpc also contains a version called simply JET SET WILLY. Which might seem confusing, but in a way it does make sense to have the two versions.

Whilst converting  the game from the CPC to the Zx spectrum, I was asked was it possible to reduce the game (on the cpc) back to the original with a mere 60 rooms, eg delete 70+ rooms and leave just the 60 . I answerd it was not a big task, to reduce the size down to less than half. But did question "for what purpose?". The answer was simply to enable the game to be part of they "sold a million" compilation tapes, and strictly speaking the version I had written was not the original jet set willy, it had been more than doubled in size.  Plus the smaller (a mere 60 rooms) version was not going to be sold as a stand alone product. But only on a compilation tape, which meant that both versions could still be sold on the cpc.

Version 1) JET SET WILLY - the final frontier-- 130+ rooms - written first and sold first on the cpc
Version2) JET SET WILLY a mere 60 rooms - sold only on a compilation tape/disc with they SOLD A MILLION compilation. (Beach head, Sabre Wulf,Jet Set Willy, Daley Thompsom-DECATHLON)

The reduction down to the mere 60 rooms of the original was not that difficult. It was just a case of deleting most of the data. I added a high score table to give immediate feedback to the player that it was a different version. But their are visual changes on the title screen as well. (see picture)

And before anyone says that the tail on the title screen looks like a two. It was just a copy of the squiggle on the graffiti. Which on reflection when doing JSW2, I decided to remove.





 

An ommision from the above.

The CPC does not have a version of JET SET WILLY2. It has a version that is identical but is called JET SET WILLY - the  final frontier.  

Yet the cpc also contains a version called simply JET SET WILLY. Which might seem confusing, but in a way it does make sense to have the two versions.

Whilst converting  the game from the CPC to the Zx spectrum, I was asked was it possible to reduce the game (on the cpc) back to the original with a mere 60 rooms, eg delete 70+ rooms and leave just the 60 . I answerd it was not a big task, to reduce the size down to less than half. But did question "for what purpose?". The answer was simply to enable the game to be part of they "sold a million" compilation tapes, and strictly speaking the version I had written was not the original jet set willy, it had been more than doubled in size.  Plus the smaller (a mere 60 rooms) version was not going to be sold as a stand alone product. But only on a compilation tape, which meant that both versions could still be sold on the cpc.

Version 1) JET SET WILLY - the final frontier-- 130+ rooms - written first and sold first on the cpc
Version2) JET SET WILLY a mere 60 rooms - sold only on a compilation tape/disc with they SOLD A MILLION compilation. (Beach head, Sabre Wulf,Jet Set Willy, Daley Thompsom-DECATHLON)

The reduction down to the mere 60 rooms of the original was not that difficult. It was just a case of deleting most of the data. I added a high score table to give immediate feedback to the player that it was a different version. But their are visual changes on the title screen as well. (see picture)

And before anyone says that the tail on the title screen looks like a two. It was just a copy of the squiggle on the graffiti. Which on reflection when doing JSW2, I decided to remove.





 

If only bright was used, then usage was technical. However I do not like the Mud versions of the bright colours. Given a choice I tend to use bright. 
Basic background on JSW on the CPC 464.
When tasked with writing the CPC464 version of JSW, I started with the knowledge that Manic Miner on the CPC managed to use all the memory available. So JSW has triple the amount of rooms and that was why I decided to compress everything I could think of. 
The final version called "JSW the final frontier" was supposed to be just my version of JSW on the cpc. It was never intended to be a new version. In fact most things were toned down to stop it diverging too much from the original.
When I was asked if it could be rewritten back on the spectrum, I tentatively said "probably yes". I knew it would not be an easy task. The reason behind the apprehension was because the way the cpc was doing collision detection was based on colour, but was also being drawn directly on the cpc's screen. The spectrum would need to do things differently, and somewhere along the line I would be forced to introduce a copy screen. 
The cpc version used translation colour bytes for the rooms. Most code was an adaptation of the cpc code. The compacted code needed to be even more compacted due to needing to save 4k when moving from the cpc game onto the zx spectrum. All screen draws on the cpc are done on the viewed screen. To stop flicker the drawing on the zx spectrum is done on a copy screen. (that takes a minimum of 4k) In essence if space was available anywhere then it was used. Most of the games running variable data is stored on the screen for the zx spectrum version 

The cpc version on Manic Miner with written On a Tandy Model 4 - with floopy discs
The Cpc version of "Jet Set Willy the final frontier was written on a Tandy Model 4- with floopy discs
The cpc version of "Jet Set Willy" was written on a Tandy Model 4 - with floppy discs
The spectrum version of "Jet Set Willy 2" the final frontier was written on a Tandy Model 4 - with a 20 meg hard drive
The Tandy was running Newdos 80 (disc operating system). The assembler was EDAS by misosys.
Download from Tandy to CPC was done using a z80 dart.
Download from Tandy to zx spectrum was done using a parallel interface - using my own direct download software - taking the Tandy's loading structure as it basis. Which allowed direct disc to memory transfer. Which was nothing like Matthews fixed memory transfer. Where source and destination occupied the same address.
I will elaborate on the transfer. In Matthews case to transfer from the Tandy to the spectrum.  Data is loaded into the Tandy's memory. That data is transferred byte for byte from a location on the Tandy to the same location on the spectrum. - this lead to bugs.
My method interrogated the Tandy's disc loading system, and transfers the disc contents from the Tandy to the address it was assembled at. This meant a re-org of the assembled program, would also be transferred to the new org. No data (apart from one sector) is loaded from the Tandy's disc, when transferring code.

Matthews method also introduced the loss of four rooms into JSW. What Matthew had not realised, was  that the upper memory of the Tandy was dedicated/allocated just for the Hard disc operating system. The hard disc was bought after development of Manic Miner. So the very upper memory on the Tandy was and could be used, whilst he was writing Manic Miner. That same memory was occupied when it came to develop Jet Set Willy. Simply because he had bought himself that 5 meg hard drive.  (I am surprised he did not notice) The upper memory rooms ended up being corrupted and those rooms, were eventually deleted. The upper memory of JSW still contains the TANDy hard drive code, (instead of room data) 
 
The biggest problem (apart from disc size) was the source code needed to be continually stripped of comments and meaningful labels. After a while you get used to seeing what look like meaningless labels. So a label like "main_control_loop"  (which can not be written - max eight letters), gets shortened to "MCL". and slowly you get multiple versions such as MCLx,MCLp  When I first saw the assembly listing again, a few years ago, it was strange to read a label such as "IAOAL"  and immediately say to myself  "I am on a lift"  It was if I had written the label a few moments before I had read it. Yet the time gap was nearly 30 years.