jetsetdanny

Corrected Corrected! You *are* an astute observer, Ian! :)

Here's some relevant info from another discussion: Ian (IRF)'s idea: I was considering approaching this from a completely different perspective - removing the ability to turn the music off altogether, thinking that would save a fair few extra bytes in the main loop (keychecks etc), it would remove the need to reset the border colour after the item-collection/arrow-fire border 'special effects', and the player can always press the mute button on their hardware if they don't want to hear the music! Andy (Spider)'s reply: That's very easy, you can chop code out but the quick fix is to change: 35626 JR Z,35638 Jump if not Default is: 35626,40 and 35627,10 (#8B2A,#28 and #8B2A,#0A) Change it to this: only one byte needs changing: 35626 JR 35638 Jump anyway! Which is: 35626,24 and 35627,10 (#8B2A,#18 and #8B2A,#0A) Summary: To turn off the ability to turn off ( ! ) the in game tune via JSWED then just do a #8B2A,#18 , to restore it back to normal change that address back to #28

Done as you have suggested, Ian! I have edited my original post, including a mention that it's done on your advice :) . An astute observer will note that in "WNM SE" there will be patch vectors in 62 out of the 66 rooms of the game... ;)

To be honest, I use the word "subroutine" from time to time, but I'm not 100% sure how it should be defined. I perceive it as a part of a "major" routine, if that makes sense. Wikipedia has this to say about it: In computer programming, a subroutine is a sequence of program instructions that perform a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed. Subprograms may be defined within programs, or separately in libraries that can be used by multiple programs. In different programming languages, a subroutine may be called a procedure, a function, a routine, a method, or a subprogram.

Yes, I'll probably change some of them. I'll meditate on it in the coming days :) .

I am wondering about the six bytes from A3F9 to A3FE. IIUC, they would be guardian 7F in JSWED, but it doesn't exist. SkoolKid says in his disassembly, The following entity definition (127) - whose eighth byte is at A3FF - is copied into the entity buffer at 8100 for any entity specification whose first byte is 127 or 255; the first byte of the definition (255) serves to terminate the entity buffer. So A3F8 is out of the question, because it has to be FF, and A3FF is out of the question, because it is the index of the first item. However, the six bytes in-between - are they used by *anything*, for *anything* at all? Any thoughts on this?

As mentioned above, I have applied the fix in the Special Edition of "Willy's New Mansion". I decided to make use of the spare byte which emerged after the mode modifications. In order to do that, I did the following: The 'new' code is from #9BD2 to #9BE9 (for reasons related to the code distribution in "WNM SE") and it goes like this: 7e e6 38 c2 f2 91 dd 7e 01 e6 0f c6 38 e6 47 4f 7e e6 38 a9 4f c3 fd 91 The existing code at #91EE to #91FC has been edited as follows: c3 d2 9b 00 dd 7e 01 e6 07 4f 7e e6 78 a9 4f Therefore, I believe that thanks to the change in the C2 instruction in the 'new' code the spare byte, currently placed at #91F1, is omitted by the whole routine and can be safely used for other purposes (I have moved the music flags there from 85E2). If I have missed something and there is a flaw in the above solution / reasoning, please let me know! :)

Thanks a lot for your explanations, Ian! You've done a great and clever job designing the fix! It's much appreciated :) .

Ian, the bug fix is working fine AFAICT :) . Just one question. The modification you suggest to the original code at 91EE-91F0 makes the program jump to the new code located elsewhere. The instruction at the end of the new code makes the program jump to one byte *after* the modified original code. So it looks like all of the modified original code (after the jump instruction) is simply *bypassed*. How come it plays some role in the whole affair?

I don't know and I would be surprised if he was. Having said that, it's probably high time to get him interested in "JSW" again :) . After all, he wrote on his website: And do I have any plans to create a third JSW game? No serious plans, no; but, for the sake of nostalgia, I do let the possibility run through my mind from time to time. I still have a few good ideas for rooms, and I sometimes think it might be quite fun to create another game. So, in the 'unofficial' words of James Bond: never say never again! :)

Thanks, Ian! A link to Richard Hallas's article about music was already there in my post, but I guess there's never too much quoting (or linking to) such a classic :) .

The original "Jet Set Willy" has a number of addresses which are unused and can be utilised for "higher purposes", such as inserting new code. A list of these addresses is included in SkoolKid's disassembly: http://skoolkid.github.io/jetsetwilly/maps/unused.html (in hex) http://skoolkit.ca/disassemblies/jet_set_willy/maps/unused.html (in decimal) Apart from the addresses mentioned in the list, there are other places in the original code which can be modified safely, such as e.g. everything that pertains to the colour code protection scheme. There are also some places where the original code can be optimised to gain a byte or three. I do not intend to describe all of them now (due to time constraints), but I would like to start a thread in which all the pertinent information can be placed, so that new pieces of information can be added as they emerge. While working on the Special Edition of "Willy's New Mansion" today I have discovered the following instances of possible optimisation of the original code: [the addresses below are in hex and refer to the original "JSW"] 8892 - 8894 The JP NZ instruction can be changed to JR NZ, saving one byte. 8898 The DI instruction is unnecessary (it disables interrupts which are already disabled; IIUC at 8400) - it can be NOPped out. 88AE - 88B0 The JP NZ instruction can be changed to JR NZ, saving one byte. That's a gain of three bytes altogether :) .

Thanks a lot for this, Ian! :)

Some more technical stuff: http://www.icemark.com/dataformats/mirrors/JSW%20Tech%20Page_files/tech.html http://www.seasip.info/Jsw/jsw2room.html http://www.oocities.org/andrewbroad/spectrum/willy/mm_format.html http://hallas.net/Software/music.htm

Personally, I believe in the players' freedom. If someone manages to record an RZX walkthrough of the game, I don't think anybody should try to stop them from publishing it on RZX Archive. However, since you've asked about it, Metalmickey (thanks for asking!), it gives us some legitimation to express our preferences as to your sending your recording to RZX Archive right now or not just yet. I understand the rationale behind asking you to hold it for a while. However, it is possible that while you are waiting, someone else (who may never even post anything on this forum, so we don't even know the person is at it right now) will send their recording to RZX Archive and it will get published there instead of yours (first come, first serve). In such case your satisfaction from completing the game and documenting it with a published recording (thanks to being the first one to do it) will be lost. So, while I have no strong opinion on the subject, I would say, go ahead and send your recording to RZX Archive (especially if it's a good one in that you have completed the game without loss of life). I think that everyone realises that RZX recordings are spoilers. So once it's published, someone who wants to tackle the game and its mysteries themselves will know that they should not download the recording (or refrain from watching it if they do download it), while those who are curious about how the game can be solved without actually wanting to have a go at it themselves will have the freedom to fulfil their desire.

Thanks a lot for playing and for your kind comments, Metalmickey! I am very glad you enjoyed the game... and congratulations on completing it successfully! :)

And one more reflection about inserting two "main" patch vectors. While probably possible technically (why not?), I think it simply wouldn't make much sense. A patch vector is a subroutine, a chunk of code, which does something special in the room, and the two bytes in the room data point to where the patch vector for this particular room should be activated from (where it starts). The patch vector may include various elements, including calls to other subroutines. So, once you have been able to call a patch vector, you can make it perform all the tricks you want for this room. So you don't need a second patch vector. Having said that, perhaps with two patch vectors you could save some space. You need 3 additional bytes in the main loop and 5 additional bytes for the second "main" patch vector, that's 8 extra bytes altogether, not much. And then, if you have a patch vector for room A, and a patch vector for room B, and you want to apply both of them in room C, you could do it without sacrificing any more bytes, by calling them both, I think (thinking aloud, kind of). Perhaps it's not such a bad idea, after all...

You could use these two bytes to determine some room-specific elements. In "Willy's New Mansion" Special Edition, for example, nnED is used to set the in-game tune by room and the nnEE and nnEF are used for patch vectors. If I wanted to add another element set by room using a special routine, e.g. which character Willy should be playing as in any given room, I could use one (or both, depending on the situation) of these additional spare bytes. Something to be kept in mind for the future...

I agree with this. Moreover, if John Elliott's "new adjacent ropes patch" protects these bytes from being overwritten, this could be mentioned, too, if it falls within Richard's "policies" of supplying additional information.

This is certainly true about the original, unmodified game engine. However, JSWED offers the possibility of applying John Elliiott's "new adjacent ropes patch", which eliminates the need to have a blank guardian in the guardian list after a rope. In other words, you can have a "regular" guardian after a rope in the guardian list, including another rope, I believe. So theoretically you can have a room with eight ropes. John Elliott once explained to me that the patch "relocates a couple of bytes of rope state to within the rope's guardian table entry, rather than the following guardian's entry." So the question arises whether applying the patch would protect the addresses 8141-8143 from *ever* being overwritten by ropes, even if a rope is the last guardian in the guardian list. It's a question to John, I guess. It would be interesting to know the answer for sure for future projects :) .

It's not impossible, I believe. You *could* have eight ropes in the same room ;) . And no, the corruption of the in-game tune at some development points in "TNE" was not related to the ropes in any way. It was due to mistakes in the code determining the tunes for certain rooms.

Thanks for confirming this, Richard! :)

They may be unused, indeed. There are question marks next to them in Arsen Torbarina's document.

Perhaps. I am not aware that it has been tried before. I guess the main patch vector would have to be modified, or there would have to be two CALL instructions in the main loop to call two separate main patch vectors, each of which would work just like the one in Geoff Eddy's games. Which are the unused bytes in the room data apart from ED, EE and EF?

This is just a quick note to let you know that I am working on the Special Edition of my first JSW game "Willy's New Mansion". If all goes well, it will be released on 10 May, eleven and a half years after the release of the original edition. It will feature two new rooms and a lot of other enhancements (custom loader and loading screen, "advanced" title screen, a lot of patch vectors, teleportation, several in-game tunes, a serious challenge concerning the time limit, two separate Game Over screens [one for losing all lives, the other for running out of time] and other elements), including some things which have never been seen, TTBOMK, in any JSW game before. The download link will be announced in this thread on the release day :) .