jetsetdanny

Posted December 22, 2025 · IP You can now download it from https://we.tl/t-Fy10shHs1m . I have added some PC-based games from my archive as well. I did mean to do it first for the Boxing Day and then as a New Year's gift, but I was too busy working on other JSW-related things. So here it is now 🙂 . The download will expire in three days, so grab it as soon as you read this message 🙂 . However, if you read this and it's too late to download, post your request here and I will re-up the ZIP file.

Thank you for your kind words, Willie! I'm very glad my "essay" may be useful for you 😊. Thank you also for your further comments! I would like to add that if anyone would like to use in their games the music I've coded for Herve's games, please feel free to do so, while I would appreciate your mentioning somewhere (in the Readme or release notes or wherever appropriate/possible) that it was coded by me (Daniel Gromann, for credits I prefer my real name than any possible nicknames). Most of the tunes I coded (with the exception of one, well, perhaps 'one and a half') are tunes composed in real life by someone other than myself. I'm curious if those who have played Willy in the Islands of Mystery. Part II: The Temple have recognised any of them. I would prefer not to reveal their identity for the time being (to give people some time to play the game without this spoiler), but I will gladly do so later on, after more time has passed since the release. Should anyone need to know the identity of any tune right now or in the near future, do let me know here at the forum or by e-mail and I will let you know what it is 😊. If anyone should want to use any of the tunes I've coded, as described above, you can identify where an in-game tune starts by looking at the value of the offsets #B6 and #B7 of the first page of the room data (in other words, what would normally be the first two characters of the room name) and you will know where the header is. Then you would need to look at the header and see where the data for each of the three channels is placed. And then copy it to your game (probably manually, or however you manage to transfer these bytes) and adjust the header in your game to show correctly show the addresses of the three channels where their data will end up in your game. For the title-screen tune and the tunes placed where the in-game tune and cheat-mode tune reside by default (the latter two starting at #F700 and at #F902, respectively, in both cases in Memory Bank 0), you could try using the JSWED Music editor to export them. I wouldn't be quite sure if it would work though. Without checking it, I would *think* that if JSWED generally works well in this respect, it *should* work for the title-screen tune and the in-game tune in Welcome to Willy's Fun Park! because in that game new music was coded in place of the default tunes and nothing else was modified (I'm not mentioning the cheat-mode tune because it wasn't modified there, it should be the default one). In case of Willy in the Islands of Mystery. Part II: The Temple, the modifications were more far-reaching. A part of the space in memory meant for the title-screen tune is occupied by other data (the title-screen tune does not occupy the whole length of that space, so the rest of it was used for other data). Where the in-game and cheat-mode tune normally are there may be more than one tune, I used that space to the maximum as well. So I'm not sure what the JSWED music editor would do about these, whether it would be able to export these tunes successfully or not. In any case, they can always be copied manually, which would be my preferred solution, actually.

Conclusion This concludes my write-up on coding the 128K music. I hope it will be useful to those who wish to code their own tunes 😊. I also look forward to any questions, comments, or suggestions for improving what I have presented here 🙂.

Expanding the in-game music Now, something I really wanted to do in Hervé’s games (and only had time to work on it for Willy in the Islands of Mystery. Part II: The Temple) was to “install” different tunes in different groups of rooms, much like I did in a number of 48K JSW games that I collaborated on over the last few years. I managed to achieve it in The Temple, and I will now describe my solution, which could certainly be applied (as-is or with modifications) to other games if the authors so wish. The address of the in-game tune in The Temple is defined in offsets #B6 and #B7 of the first page of the room data. In other words, the address of the tune occupies the first two characters of the room name. You can see this if you open the game in JSWED. This obviously means that these first two characters cannot be used for the room name. The code that prints the room names is adjusted accordingly: it prints the room name starting at the third (not first) column of the line where it appears, and the length of the room name it prints is 29 characters, not 32 (it could be 30, but the last character of each room name is used for the colour of the room name in this room). So, offsets #B6 and #B7 of the first page of the room data hold the address of the in-game tune for this room. For example, the data for room 00, “The Comet”, starts at #C000 in Memory Bank 1. At #C0B6 and #C0B7, you’ll find #08 and #DB. This means that the in-game tune in this room starts at #DB08. This is an example of a tune that resides in Memory Bank 0. The space at #DB00–#DBFF was free, and I used it for in-game tunes. Now, let’s have a look at room 02, “The Grail”, whose data starts at #C800 in Memory Bank 1. The values at #C8B6 and #C8B7 are #E0 and #81, so the in-game tune for this room starts at #81E0. In JSW64 games (at least in the variant that The Temple uses), each room occupies four pages of data (4 × 256 bytes). When the room is initiated, these pages are copied to the current-room buffer in Memory Bank 0 from #8000 to #83FF. So, when The Grail is initiated, its data from #C8.. in Bank 1 is copied to #80.. in Bank 0, its data from #C9.. in Bank 1 is copied to #81.. in Bank 0, and so on for the remaining two pages. This means that while the two bytes in the room names show the address of the start of the in-game tune as #81E0, this effectively corresponds to #C9E0 in Bank 1, because data from #C9.. in Bank 1 gets copied to #81.. in Bank 0 when this room is initiated. I hope this is clear. The Grail is also a good example of how the tune data can be divided. Let’s look at the header of its in-game tune at #C9E0–#C9E5: #E6 81 C9 DB E6 81. This means that the data of the first and third channels start at #81E6, while the data of the second channel starts at #DBC9 (all in Memory Bank 0). The reason for this arrangement is that there wasn’t enough room in the room data for The Grail to store the whole in-game tune. So I put the (identical) data for the first and third channels in the room data, starting at #C9E6 in Bank 1 (when the room is initiated, this data gets copied to #81E6 in Bank 0), while the data for the second channel starts at #DBC9 in Bank 0 (there was spare space there). All right, so the offsets #B6 and #B7 in the room name show where the header of the tune is, and the actual tune data can either follow the header or be located elsewhere, according to what the header indicates. The in-game music in The Temple also has the following feature: when the player enters a new room (either coming from a previous room or respawning in the same room after losing a life), there is a check for which tune was playing before the player entered this room. If the same tune was playing, it continues from the note where it stopped. If a different tune is playing, it always starts from the first note. All this is achieved as follows. There is a call from the “Initialise the current room” routine at #8965 (in Memory Bank 0) to #FAFE (also in Bank 0), where the following code is placed (to quote the actual opcodes): 2A C9 FE ED 5B B6 80 7D D6 06 6F A7 ED 52 28 04 EB CD C6 FE That translates to: LD HL,(&FEC9) LD DE,(#80B6) LD A,L SUB A,06 LD L,A AND A SBC HL,DE JR Z,04 EX DE,HL CALL #FEC6 Most of this code was kindly provided by John Elliott. I added one part, which I will explain in a second. This code checks the value of addresses #FEC9–#FECA against the value at #80B6–#80B7, to see if the tune in the current room was already playing before entering this room. #FEC9–#FECE is the address to which the game engine (the built-in music player) copies the 6-byte header of the last tune selected. This means that addresses #FEC9–#FECA hold the address of the first channel of the tune (the first two bytes of the tune’s header). Since addresses #80B6–#80B7 hold the address of the header (not of the first channel), I added the instruction SUB A,06 to subtract 6 bytes from the value of #FECA. Thus, the value compared against #80B7 is the header address, not the address of the first channel. If the values checked match, the program jumps four bytes to the code that follows (unrelated to music). If the values do not match, the routine at #FEC6 is called, which changes the in-game tune (and the new tune starts playing from the first note). Thanks to the subtraction I added, the code works, but this solution introduces one serious limitation: the first channel of the tune always has to follow immediately after the tune’s header (so that the difference between the lower bytes in their addresses is exactly 6). So, while in general the tune’s header and the data for each of the three channels could be stored in completely different locations, for this solution to work, the data of the first channel only must follow immediately after the tune’s header (the data for the other two channels can be placed elsewhere in memory).

Default tunes in JSW128 and JSW64 games Games using the JSW128 and JSW64 game engine have three tunes by default: The title-screen tune It can occupy up to 2774 bytes (the total length, including the 6 bytes of the header and the data of all three channels). By default, JSWED saves it as the last code block of the TAP file, called “title.tun”, which gets loaded from the address 29994 (#752A). If you want to edit the title-screen tune in JSWED’s Hex Editor, it starts at #F52A in Memory Bank 7. The in-game tune It can occupy up to 256 bytes (the total length, including the 6 bytes of the header and the data of all three channels). By default, JSWED saves it as a code block called “main.tun”, which gets loaded from the address 63232 (#F700). If you want to edit the in-game tune in JSWED’s Hex Editor, it starts at #F700 in Memory Bank 0. The cheat-mode tune (for info about how to activate the cheat mode, have a look here) It can occupy up to 254 bytes (the total length, including the 6 bytes of the header and the data of all three channels). By default, JSWED saves it as a code block called “cheat.tun”, which gets loaded from the address 63746 (#F902). If you want to edit the cheat-mode tune in JSWED’s Hex Editor, it starts at #F902 in Memory Bank 0. Here’s what it looks like in ZX-Blockeditor: JSWED has functionality in its “Music” section for importing and exporting these three tunes: This can be useful if you want to use tunes that already exist, either in another game file or saved as separate files in the .TUN format. When this subject was discussed back in October 2005 on the MM&JSW Yahoo! Group, John Elliott gave the following information about the .TUN format tunes that existed back then: To this, Andrew Broad added: I did try using SPECSAISIE to convert 48K tunes to 128K tunes, but I was not satisfied with the results. It is certainly able to convert the basic chart values, but it can’t cope with the length of the notes, in my opinion. If you try it and have a different experience, do let us know. For what it’s worth, attached to this message are some of the .TUN format tunes mentioned above. I did try to extract the tunes coded by Andrew Broad for Party Willy (JSW128 version) using JSWED's export/import functionality mentioned above, but continued to get an error message when trying to import the exported tunes. tunes.zip

The actual coding I coded all the tunes in Hervé’s “Welcome to Willy’s Fun Park!” and “Willy in the Islands of Mystery. Part II: The Temple” manually. I coded melodies that I knew — that sounded in my head, so to speak. I would play a note or a sequence of notes on a keyboard — either an actual piano keyboard or a virtual one — determine which note goes next, convert it to a Hex value according to the basic tone chart, determine (by ear) how long it should be, determine a Hex value for its length, and input it in JSWED’s Hex editor at the place in memory where I was coding that tune (more about this later). Then I would play the following note or notes and repeat the process. I usually coded the main melodic line first and then coded the accompaniment (the chords) in pretty much the same way, but this time determining a different length for the chords, because in “my” music each chord typically sounds over a few notes of the main melodic line. I used this virtual piano for this work. Please note that I’m not affiliated with them and have no related interests whatsoever; I’m only sharing my experience, and there are certainly lots of other websites out there that would let you do the same thing. This manual coding of the music was a very slow and time-consuming process. It was probably partly because of my ineptitude — from time to time, I made mistakes and had to correct them later. A lot of the time I didn’t get the length of the notes right and had to go back and correct them. So yes, it was a slow, protracted and error-prone process, but also a rewarding one at the end. It seemed a drudgery at times, but I’m very content with the result and believe it was worth it. It’s up to you to judge, of course. I would assume there are better ways of coding the music, but since I didn’t use them, I cannot share my experience about them. I will just mention that: John Elliott offers links to two apps: MAKETUNE and PLAYTUNE. The first one apparently allows you to “write” a tune. I didn’t try using either one, but if someone has, do let us know how it went. There is a user on this forum who has made an app of his own that facilitates the creation of 128K tunes. I cannot give any details right now, but perhaps he will be kind enough to share it with us.

Additional instructions I stated before that the clearest picture of a tune in a JSW128 or JSW64 game is that each note is defined by two bytes: the first being the note on the music scale, and the second being its length. This is true, but the “more technical” reality is that, as John Elliott put it, “each channel is a string of commands, which may be followed by one or two parameter bytes.” So, going back to what I described, you could also say that the first byte of each note — if it is a value between #01 and #F8 — is an instruction which means “Play a note,” at the same time defining the tone of this note, and it has to be followed by a second byte (the parameter byte) defining the length of the note, as discussed before. If the first byte is a value outside the #01–#F8 range, then it is an instruction that has another meaning. The meanings of these instructions are as follows: #00 – rest, i.e., don’t play any note, remain silent. The second byte (the parameter byte) is the length of the rest (silence). So, if the “basic unit” of your tune is, for example, #10, and you want silence to last for three times the length of that basic unit, your values in the code will be: #00 #30. #F9 – set the waveform effect (like "W" in the PLAY command). The parameter byte is the waveform <-- I am quoting this from John Elliott’s description. I didn’t use this instruction in my coding and cannot say anything more about it. I believe the “PLAY command” refers to the PLAYTUNE app, but I didn't use it, so I cannot say anything about it. #FA – set the waveform period (like "X" in the PLAY command). The parameter byte is the duration; I don’t know the units. <-- Again, quoting John Elliott. I didn’t use this instruction, and I cannot say anything more about it. #FB – set the volume (like "V" in the PLAY command). The parameter byte is the volume. I didn’t use this instruction myself, but I can say the following: the “standard” tunes present in previously released JSW128 and JSW64 games did use this parameter. For example, the default in-game tune in JW128 games has three channels, and it sets the following values of loudness for each of them: #07 for the first channel (via an instruction at the very start of the channel, before the first note, reading #FB 07), #06 for the second channel (#FB 06), and #08 for the third channel (#FB 08). I inserted this tune in the room called “The Wings” (057) in Willy in the Islands of Mystery. Part II: The Temple (since this room is from Hervé’s game Jet Set Willy in Paris, using the JSW128 game engine and its default in-game tune). In comparison with the tunes I coded for The Temple — which do not have the volume defined via an instruction, so you could say that they play at a default volume — this tune, with channel volumes defined as #07, #06, and #08, sounded very quiet, much too quiet in comparison with my tunes. I therefore adjusted the volume of the three channels to #0B, #0A, and #0C, respectively, and with this, I felt the tune sounded similar in loudness to my tunes that do not have a custom-defined volume. I hope this gives you an idea of what values can be used to set the volume, but of course, experimenting yourself and a trial-and-error approach is probably the best way to establish what suits you most. John Elliott also mentions that: “If you want to use a waveform effect, you should first set the volume to 16, then set the effect, and then the period.” I did not use the waveform effect, so I cannot say any more about it. #FC – I’ll just quote what John says (he gives decimal values; I have converted them to Hex): "djnz" – used to repeat sections. The first and second parameters should both be set to the number of repeats; the third is the relative address of the start of the section: #FC: Section starts at the DJNZ #FB: Section starts 1 byte before the DJNZ #FA: Section starts 2 bytes before the DJNZ ... #80: Section starts 124 bytes before the DJNZ John warns: “I've only seen this used in title-screen tunes. I don't know how it would get on in an in-game tune.” I have tried using this feature for an in-game tune — it could be very helpful if the length of the data you can dedicate to the tune is limited — but I couldn’t get it to work well. I am not saying it doesn’t work, only that I haven’t been able to apply it successfully. I would certainly be interested in hearing the experience of those who manage to achieve it. #FD – return from a sub-tune; it doesn’t have a parameter byte, it’s a one-byte instruction. #FE – play a “sub-tune,” which must end with a “return” instruction (#FD). It has two parameter bytes which are the address of the sub-tune, in standard Z80 format (little-endian). I can see this is applied in the default in-game tune in Jet Set Willy 64 (JSW64). The header of the tune is at #F700–#F705 (in Memory Bank 0). The first channel starts at #F706, and it begins with the instruction #FE 32 F7. This instruction means that a sub-tune is to be played that starts at #F732. Strangely enough, this sub-tune starts at #F732–#F734 with another #FE instruction to play yet another sub-tune starting at #F742. That sub-tune ends with an #FD at #F741. I think — just from looking at the code, without investigating it in detail — that what happens later is that, after playing the sub-tune starting at #F742, the program goes back to #F735, where it starts to play the “original” sub-tune that was called at #F706–#F708. This one, in turn, ends with an #FD instruction at #F750. I assume that after this the player goes back to the initial part of the first channel, i.e., #F709. There, the sub-tune at #F742 is called again, and I assume the program returns from it to #F70C, where it “finally” plays the regular first channel (no more sub-tunes). This sounds quite complicated, but the main point is that it demonstrates that the #FE — play a “sub-tune” instruction — certainly works in in-game tunes. As mentioned before, this tune has only one channel (channels 2 and 3 are immediately terminated by their start addresses pointing to locations holding a value of #FF each), so calling sub-tunes is probably easier to code than if it had three channels and sub-tunes were called on each channel — although I don’t see any theoretical reason why that wouldn’t be possible. #FF – this is the instruction terminating the channel. The tune on each channel must end with this instruction.

Tune Channels There are three channels in a 128K tune, but you do not have to use all three. You can use just one or two if desired. For channels that are unused, the header still needs to point to a memory location containing #FF (end of tune). For example, the default in-game tune in Jet Set Willy 64 (JSW64) has only one channel. Its header at #F700 in Memory Bank 0 reads: #06 F7 51 F7 52 F7. This means: First channel data starts at #F706; Second channel data starts at #F751 (#FF - it's mute); Third channel data starts at #F752 (#FF - it's mute). In this case, both the addresses #F751 and #F752 hold the same value: #FF. Furthermore, the address #F751 seems to be the end of the first channel, in addition to also being “the entire” second channel (pointing to it as being muted). I believe this same address could also serve as the end of the third channel. If anyone knows of any reason why having a separate ending for the (mute) third channel in the form of another #FF value elsewhere would have any advantages over ending all three channels at the same address, please share this information with us. In most of the tunes I coded, I used the following configuration: First channel: main melody Second channel: supporting notes (chords) harmonising with the main melody Third channel: main melody repeated This approach allowed me to balance the prominence of the main melody against the accompaniment. In practice, I only needed two chunks of data in addition to the header: one chunk for the first and third channels (the main melody) and another for the second channel (the chords). The header pointed to the same address for both the first and third channels and to a different address for the second channel. This method was satisfactory for me, but it is by no means the only way to structure the channels. You may certainly find other arrangements that take full advantage of the three available channels or create different textures for the melody and accompaniment. The reason for my solution described above was also that I did not use the function which sets the volume of the tune. So, let me now describe “the full reality” of the music player in JSW128 and JSW64.

Coding the 128K music From my perspective, the simplest way to understand 128K music in JSW games is to consider each tune as having a 6-byte header and three channels of music. The header contains the addresses for the start of each channel (three sets of two bytes). Each channel consists of music notes represented by two bytes each: the first byte indicates the note according to the music chart, and the second byte indicates the length of the note. Each channel must be terminated with a value of #FF, which signals the end of the channel. This is a simplified approach that does not fully represent reality, but for me it’s the easiest way to think about 128K music. I will present “the rest of the reality” a little later. The header consists of 6 bytes. The first two show where the start of the first channel of the tune is. The address is shown using the little-endian byte ordering system, where the least significant byte (the "little end") of a multi-byte data value is stored first, at the lowest memory address, making it appear "backwards" to humans. For example, if the first channel starts at #F500, the first two bytes of the tune’s header will be #00 F5. Without checking each one individually, I believe that in the released JSW128 and JSW64 games, the header and the three channels are usually placed together. The default in-game tune in Jet Set Willy 128 starts at #F700 in Memory Bank 0. The header occupies #F700–#F705; the first channel spans #F706–#F736; the second channel spans #F737–#F767; and the third channel spans #F768–#F7AA. In this case, the in-game tune (header plus three channels) forms a continuous block of data. Please note that it does not have to be like this. Since the header defines the start of each channel, the header and channels could be placed anywhere in memory, as long as they are, or end up being, in Memory Bank 0 at runtime. By “end up being”, I mean that the tune can reside in room data stored in another Memory Bank (1, 3, 4, or 6), but when the room is displayed, its data is copied to the current-room buffer in Memory Bank 0, so that the music player effectively uses the data from Memory Bank 0 during its operation. Each note has two bytes. The first byte is the note value according to the music chart. Here is the basic tone chart for 128K games, alongside the 48K equivalents. Generally speaking, you will not need the 48K values if you are coding 128K music, unless you want to use a tune already coded for a 48K game and convert it into a 128K tune — in that case, the double chart presented below can come in handy. Note Value in 128K game Value in 48K game X C 54 10 B 53 11 # 52 12 A 51 13 # 50 14 G 4F 16 # 4E 17 F 4D 18 E 4C 19 # 4B 1B D 4A 1D # 49 1F High C 48 20 B 47 22 # 46 24 A 45 26 # 44 28 G 43 2B # 42 2D F 41 30 E 40 33 # 3F 36 D 3E 39 # 3D 3C Top C 3C 40 B 3B 44 # 3A 48 A 39 4C # 38 51 G 37 56 # 36 5B F 35 60 E 34 66 # 33 6C D 32 73 # 31 79 Middle C 30 80 B 2F 88 # 2E 90 A 2D 99 # 2C A2 G 2B AB # 2A B4 F 29 C0 E 28 CC # 27 D8 D 26 E6 # 25 F2 Bottom C 24 FF B 23 0 # 22 A 21 # 20 G 1F As for note lengths (the second byte of each note), John Elliott explains that the unit used is the “jiffy” (1/50 of a second). In practice, I chose different values for what I call the basic unit depending on the intended speed of the tune. For example: The title-screen tune in Willy in the Islands of Mystery. Part II: The Temple is a slow-rolling piece of music. In this case, I used a value of #18 (24 in decimal) for what I call the “basic unit” of the tune — essentially, a single note. Logically, I then used the following values for notes of other lengths: Half-note: #0C Double-length: #30 Triple-length: #48 Quadruple-length: #60 Hextaple-length: #90 At the other end of the “tune-speed spectrum” is the lively tune playing, for example, in the room “The Blades” (012) in the same game. I used #0A (10 in decimal) as my “basic unit” or single-length note and, correspondingly, the following values for the other lengths: #14 for double-length notes (20 in decimal) #1E for triple-length notes (30 in decimal) #50 for eight-times-length notes (80 in decimal). My advice for anyone wanting to code a tune would be to establish what the best value is for a single note (depending on how fast the tune is supposed to play) and go from there. Once you get this right, establishing the code value of the half-length and multiple-length notes is pure mathematics.

Overview The objective of this document is to allow, and make it easy for, authors of JSW games to code their own in-game music for games using the JSW128 and JSW64 game engines. I have prepared one document, but I will post it in several parts to make it easier to read and to reply to the various issues I intend to discuss. Credits The following information draws heavily on (and at times quotes directly) information contained in John Elliott’s document “Jet Set Willy 128: Music format” and in his JSWED v2.3.7 manual (a PDF file that can be found in JSWED’s installation folder). Richard Hallas’s document “A Miner Triad. Music in Jet-Set Willy and both versions of Manic Miner” was used for the JSW48 chart tone. Andrew Broad’s specialised program SPECSAISIE was used to obtain the basic tone chart for the 128K games as equivalent to the basic tone chart of the 48K games. Introduction People interested in creating new JSW games using JSWED will likely design games using either the classic 48K game engine (JSW48) or one of the 128K game engines, i.e., JSW128 or JSW64. How to code music for JSW48 games was described very clearly by Richard Hallas in his document mentioned above. More useful information can also be found in this thread. This document discusses the coding of title-screen and in-game music in games using the JSW128 and JSW64 game engines. Most of the information presented here has already been available for a long time in John Elliott’s documents credited above. My aim is to present it in a slightly different way — which I hope makes it easier to understand what should and what can be done. I also share my own experiences and practices from coding the 128K music. Music in JSW128 and JSW64 games is played by default via a built-in music player by Ian Collier. This music player can be replaced in JSWED with Soundtracker by BZYK (Piotr Baczkiewicz). I have had no experience with Soundtracker, so this document refers exclusively to the default music player. My own experiences with coding 128K music relate to two games by Hervé Ast released in 2025. Hervé kindly allowed me to contribute musical arrangements to them. For “Welcome to Willy’s Fun Park!”, I composed both the title-screen tune and the in-game tune (the same in all rooms). In “Willy in the Islands of Mystery. Part II: The Temple”, I expanded my work significantly: I composed multiple in-game tunes and modified the game engine to allow each room to have its own tune, resulting in different tunes in various rooms.

Thank you, Gyrominiac, it's much appreciated! 😊 I will repeat what I wrote back on 9 November 2015: "It is a very nice game. I've had a few casual goes at it so far. I intend to play it seriously one day, when my other JSW-related priorities allow." It's good to have the SWF file in my archive for the future 👍

First of all, I want to congratulate Hervé on the release of his sixth JSW game and thank him for making the second part of Willy in the Islands of Mystery! Secondly, I want to thank him very much for adding my name to the title screen. It’s a great honour for me! I’m only a little worried that it may lead to some confusion regarding credits for The Temple. From my perspective, Hervé should always be listed as the (sole) author of the game, and if someone feels a need to mention my contribution, it could be done somewhere on the side, in fine print, and describing it precisely with these words: "contribution" to Hervé’s beautiful game. I would like to share more info and reflections about The Temple, but if it gets too long and becomes boring to some people, I will say this: Don’t bother reading it if you’re not interested, but do download and play Willy in the Islands of Mystery. Part II: The Temple. It’s a beautiful, atmospheric game, it’s relatively easy, and it allows for what I believe is a favourite activity for many fans: exploring the game, just roaming around in this fascinating temple on a mysterious island that Hervé has created. OK, so now, for those who might be interested, some background. As you probably know, Hervé is the author of four excellent JSW games released between 2005 and 2007: Jet Set Willy in Paris, Willy on a Transatlantic Cruise, Escape of the Snails and Willy in the Islands of Mystery. Part I: Exploration. That last game explicitly invited the player, at the end, to play Part II of the game, called The Temple. Sadly for me—and I’m sure for a lot of other fans—that second part never materialised in that era, and Hervé stopped being active on the JSW scene. I did hope that he would come back one day and release The Temple, as well as create his other JSW projects—there were several that he mentioned by name and gave some information about. So it was a great joy for me when he joined this forum in January 2025 and announced that he was back on the scene! 😁 Hervé sent me a file with The Temple in early March 2025. I playtested it and suggested just a couple of minor improvements, which he made. At this point the game was practically ready to be released: 64 new rooms, designed in Hervé’s beautiful, atmospheric style, with various references to aliens, Yetis, etc., typical of his earlier projects. It would already have been a great comeback game, but I wanted to make it even more special and asked Hervé to let me add some elements to it, and he kindly agreed. This is why the game wasn’t released earlier. Since I was committed to other projects, I only started working on The Temple in earnest in August. By that time, Hervé had already made his comeback game release, launching the also excellent Welcome to Willy’s Fun Park!. My main idea for enriching The Temple was to code new music for it and allow the game to have varied music in various groups of rooms. This was something that I had done as a contribution to several games by other authors in recent years (please see this thread if you’re interested), but they were all games using the original JSW game engine (which has come to be known as JSW48, to differentiate it from the later 128K game engines) and its music system. My idea was to put into practice the same principle for 128K games, and indeed The Temple is the very first JSW64 engine game ever that features a selection of in-game tunes (no tune plays in more than four rooms; some rooms have individual tunes related to their particular character). I hope that this does enrich the playing experience as far as audio is concerned. I have also added some special effects to each room using the so-called Patch Vectors (PVs) — pieces of code written especially for the room in question, either (or both) as room-entry PVs (which only kick in once after entering the room) or runtime PVs (which run every time the program goes through the loop). Working on the PVs was a very interesting coding experience for me; I did learn a lot in the process. So now everyone interested can enjoy the second part of Willy in the Islands of Mystery and, as Hervé has mentioned, if you haven’t played it yet, do start with the first part of the game, Exploration, which can be downloaded either from its home page on JSW Corner that Hervé has already indicated or from its page on JSW Central. The Temple has so far been released in English and French. More language versions will be created and released in the near future. And a really wonderful thing is that Hervé is back and working on other projects that I'm sure will be released next year (in 2026) and in the following years ☺️. So download, play and enjoy The Temple! 😊

Thank you, Bob! 👍

Thank you for your interest in MM games and for using JSW Central, JianYang! 🙂 Well, there isn't because I have not offered anything like that so far. It did cross my mind that I might make everything that I've got in my JSW Central Download folder available for download as a single ZIP file. I have not decided whether to do it yet. I might do it in the future, but I'm not promising anything right now. *IF* I ever do something like this, it will not be versions of MM (only) or JSW (only), but everything, i.e. game files and my RZX walkthroughs of everything, structured in folders as per their type. For the time being, while I'm not making such a download possible, I can send the zipped Download folder to anyone who is interested. Please let me know - here or by e-mail - if you wish to receive it 🙂. Ethical - for me, no. Legal - if I do decide to publish it, I will do it with an understanding that my action is legal. That's all I can say. No, I wouldn't have any use for it. That would be because: 1) I've obviously got these files myself since they were download from my website; 2) I don't classify games the way you do. Please see my reply to the next point. OK, I can only answer this question indirectly. As explained here, the classification of games on JSW Central is based on the game engine they use. I don't really look at games as being "Manic Miner" or "Jet Set Willy", but rather at what kind of game engine they utilise. It may be a challenging question to define what a "Manic Miner" game is if you don't stick to the game engine criterion. If it were the protagonist, some games that you have included in your list don't have Miner Willy as protagonist (e.g. "Jet Set Luis" or "Eugene Lord of the Bathroom"). If it were the way the game plays, then for example "Clopit!" should definitely be considered a MM game, similarly to a number of other games using the JSW64 engines (obviously "JSW64: Manic Miner", "JSW64: Dragon Manic Miner", "JSW64 Manic Miner: James Bond" and "JSW64: Flash Manic Miner"). But then you can have a game that combines some rooms that play like MM and some rooms that play like JSW - how would you classify that one? So personally, I prefer to stick to the game-engine-based classification. On your list, you've got games that use the MM game engine, but also games that use other game engines. It's a mixture that does not correspond to my classification. Furthermore, you have various editions of the same game mentioned separately, a mere translation ("La miniera 2") mentioned alonside the original game, etc. Of course, I don't mind people creating lists of MM/JSW games based on other classifications that my own (and using JSW Central for it - I'm glad they do!). However, I won't dedicate my (otherwise very limited) time to checking the accuracy of such lists or discussing them in detail. Incidentally, how is your JSW game project going, JianYang? Shall we see it released any time soon? I will be happy to playtest before the release if you should want that 🙂

Manic Miner - 2000 is a MM remake that was originally posted on the alt.binaries.comp.sinclair newsgroup. Stuart Brady announced its existence on the MM & JSW Yahoo! Group in January 2000. For many years, nothing was known about the identity of the game's author. The creator’s name was generally spelled "FELL" (all in capitals), likely because it was unclear whether this was a surname or some kind of abbreviation. Fortunately, earlier this month, I was contacted by Mr Tony Fell, who explained that the author of the game was Scottish, born in Wick, Caithness, that his full name was Aaron Fell, and that he worked for CCP Games in Reykjavík, Iceland, on the online game EVE. I have updated the information about "Manic Miner - 2000" on JSW Central accordingly. 🙂

Hi Bob, welcome to the forum! 😊 It's good to know you want to stay 🙂 You may be sure that you will not get banned from here, and your input will be most welcome at all times 😁.

Today marks the fifth anniversary of the publication of the first videos—starting with walkthroughs of Manic Miner, Jet Set Willy and Jet Set Willy II—on the JSW Central YouTube channel, initially launched as a companion to my JSW Central website. Five years after that modest beginning, the channel now showcases more than 200 videos with walkthroughs of MM and JSW games and variants. As of now, walkthroughs of *all* MM and JSW games for the ZX Spectrum released until June 2025 have been presented on the channel, as well as walkthroughs of the most visually interesting entries among what I classify as “versions and minor mods” of the original MM and JSW. A big thank you to everyone who has subscribed to the JSW Central YouTube channel (close to 500 people now—amazing! 😁). As mentioned in my previous post (sorry for the repetition!) all videos are listed in the “JSW Central videos” section of JSW Central. For each entry, two links are provided: one leading to the YouTube upload, and another to the Internet Archive, where the video can be downloaded in its original Full HD quality or in an AI-upscaled 4K version. These links are also included on each game’s individual page, where the YouTube videos are embedded. While the content of the walkthroughs is the same as in the YouTube uploads, the downloadable versions may include minor refinements, such as adjusted title screens or improved audio synchronisation. Therefore, if you wish to download a JSW Central video, I strongly recommend obtaining the final version from the Internet Archive rather than from YouTube. You can see the whole collection at a glance here. My plans for further development of the JSW Central YouTube channel and of the Internet Archive video collection are as follows: – presenting new MM/JSW games a few months after each release (these will, of course, be very rare, as new games don’t appear that often); – presenting the remaining “versions and minor mods” of the original MM and JSW (from time to time, as showcasing various nearly identical versions in a row wouldn’t be very exciting); – presenting ZX Spectrum platform games that may be of interest to MM/JSW fans (I started with Monty on the Run, as it’s one of my non-MM/JSW favourites). In the future, the presentations on this channel *might* also include MM/JSW and related games for platforms other than the ZX Spectrum, but I’m *not* making a firm promise at this point. And again, to repeat what I posted very recently: I hope this growing collection of videos—based on my RZX walkthroughs, which are also available for download on each game’s page on JSW Central—will serve as a valuable resource for any fans of MM/JSW who are struggling with a game or simply want to see how it can be completed. I also hope it will help promote Miner Willy’s multiple universes to a wider audience 🙂 .

I don't think there is any "problem" as such, it's just a question of someone producing a final file in a "release" form, I would say with a Readme with proper credits, etc. I will be happy to prepare such a file when time permits. I haven't had time to do it so far, even though I have been spending most of my spare time on JSW - please have a look here and here for details. Adding some extra touches to Hervé "Willy in the Islands of Mystery (Part II: The Temple)" before its release is my top priority now, so side projects like this one will have to wait for their turn. When I am finally able to work on this (hopefully, early next year), I'm thinking of doing the following: inserting Norman Sword's code (from his file "INVISIBLE.TAP") into an official release of the original "Jet Set Willy" (with Software Projects POKEs added and the colour-code protection removed), adding a custom loading screen and possibly a custom title screen, and creating a Readme where the history of the project will be described and all due credit will be given. Oh, and I'm thinking of calling this variant either "Invisible Willy" or "Willy the Invisible" - I would be interested in hearing your opinion on these options for the title, especially how they sound to native English speakers 🙂 .

Thank you so much for the update, Hervé! 👍It all sounds very exciting and I look forward very much indeed to each and every one of your JSW projects! 🙂

Thank you for this info, Hervé, and, most of all, for letting me add some special effects and music to your wonderful game 🙂. I have indeed been working on it quite intensely in recent months, adding Patch Vector-based extra elements to various rooms. This task hasn't been completed yet, and I still need to code much of the music intended for the game. I do hope to be able to do it in the coming weeks (during which I should have some time off from work if all goes well) and to make the game ready for a pre-Christmas release by Hervé. I wouldn't want to mention any deadlines right now, but I will certainly do my best for the release to happen soon. Once again, thank you so much, Hervé, for letting me enhance "Willy in the Islands of Mystery (Part II: The Temple)" a little bit, and please bear with me while I complete the envisaged additions 🙂 .

The number of JSW Central videos available to the public has now reached 200 😁. All of the videos are listed in the "JSW Central videos" section of JSW Central. For each video, two links are provided: one leading to YouTube, where the video was originally posted, and another leading to the Internet Archive, where the video can be downloaded in its original Full HD quality or in an AI-upscaled 4K version. These links are also available on each game's individual page, where the YouTube videos are embedded. All videos are available for download, and the final versions are hosted on the Internet Archive. While the content of the walkthroughs remains the same as in the YouTube uploads, the downloadable versions may include minor improvements, such as adjusted title screens or better audio synchronization. Therefore, if you wish to download a JSW Central video, I strongly recommend obtaining the final version from the Internet Archive rather than from YouTube. I hope this growing collection of videos—based on my RZX walkthroughs of the games, which are also available for download on each game's page—will serve as a valuable resource for anyone who is struggling with the game or simply wants to see how it can be completed. I also hope it will help promote Miner Willy's multiple universes to a wider audience. 🙂

Thank you so much, Norman Sword! 👍 I would definitely like to record a variant of JSW with an invisible Willy. However, I'm not sure how to proceed now. Lee Prince's "The Invisible Man" is incompletable. You have provided the code that allows to achieve the idea that Lee came up with. With this, I'm tempted to try to fix Lee's version with your code and make it available to anyone who might be interested as "The Invisible Man" - Bugfixed Version, with all due credit given to you in the accompanying Readme file, on this variant's page on JSW Central, in the JSW Central YouTube video description and in any announcements I would make about it. Would you be OK with this solution?

Thank you for the code, Norman Sword! I will work on applying it to an actual game file when time permits, hopefully soon.

Thank you for taking the time to reply, Norman Sword! 👍 My current coding skills unfortunately aren't enough to write the code you've mentioned (simple as it may be). I did give the issue some more thought, though, and came up with a suggestion for an alternative solution that apparently doesn't work, but I will present it here because I don't understand some of the results of what I've tried to do and would be happy to have some answers. So I thought of the following solution looking at this part of the Main Loop: I thought that after everything that needs to be done with Willy is done (Willy is moved, the items that he is touching are collected), the Screen buffer (room + Willy + entities + items) at #6000 gets copied to the display file at #89F5. My idea was to, at this point, draw Willy to the #6000 Screen buffer again - before the buffer is copied to the display file - but this time using an empty sprite of Willy's. At #89F5, I inserted a call to #9700 where I copied the code from #95C8 ("Check and set the attribute bytes for Willy's sprite in the buffer at 5C00") and the code from #9637 ("Draw Willy to the screen buffer at 6000"), but (at #9772 and #977B in case of "The Nigthmare Room") pointing to an empty sprite instead of Willy's regular sprite. My idea was to erase Willy from the #6000 Screen buffer (by printing him again, but this time using an empty, pixelless sprite) right before the buffer was copied to the display file. The result is that my additional code prints Willy (or whatever sprite I point the instruction to) once again on top of the already printed Willy. It doesn't erase the already printed Willy, it ads pixels on top of him, so to speak, preserving the filled pixels that are already in place. Attached below are three experimental files that illustrate it, called TTMWI (trying to make Willy invisible). In the file "TTMWI (empty)" my additional code at #9700 prints an empty sprite. This results in the game looking normal (as if nothing has changed), because an empty (pixelless) sprite is printed on top of the regular Willy, so all you see is the regular Willy. In the file "TTMWI (bird)" my additional code prints the bird sprite from #BD00. What you see is a mixture of the regular Willy and the (backwards walking) bird, or, in "The Nightmare Room", of the flying pig and the bird (the latter is quite cool, actually). In the file "TTMWI (inverted)" my additional code prints a sprite from #9F00 where I placed an inverted set of Willy's sprites. The result is a solid white block, which demonstrates clearly that the code prints the original Willy's sprite and, on top of it (without erasing it though) an additional sprite selected by my additional code. What I don't understand is why the original Willy's sprite doesn't get erased - why its filled pixels stay in place instead of being wiped out by the empty pixels of the second sprite that is printed by my additional code. An answer to this enigma would be appreciated, as well as an opinion on whether this approach to making Willy invisible could work and, if so, what should be changed in my code to make it work 🙂 . TTMWI (inverted).tap TTMWI (bird).tap TTMWI (empty).tap