jetsetdanny

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 :) .

Back in 1999-2002 Geoff Eddy released four games which used a modified JSW48 game engine (by JSW48 I refer to the original game engine of "JSW", as distinct from the game engines later developed by John Elliott, known as JSW128 and JSW64). The game engine of the first three games ("J4 (The Fourth Remix)", "Willy the Hacker" and "Willy Takes a Trip") came to be known as Geoff Mode 1, and the game engine of the fourth game ("ZX Willy the Bug Slayer") as Geoff Mode 2. One of the characteristic features of these game engines is that they use the so-called patch vectors. As Geoff himself explained over a decade ago: "Two bytes within the room data specify the location of a subroutine which is called every tick, after Willy and all the guardians, items and arrows have been displayed but before the room data is finally copied to the screen. This subroutine, which may be different for each room, is known as the 'patch vector', for now-forgotten reasons." Geoff's website has sadly been offline for a while, but it can still be accessed on the Wayback Machine, e.g. at: https://web.archive.org/web/20031012234840/http://www.cix.co.uk/~morven/jsw/ https://web.archive.org/web/20030818082654/http://www.cix.co.uk/~morven/jsw/geoffmode.html https://web.archive.org/web/20030701143111/http://www.cix.co.uk/~morven/jsw/geoff_dis.html The above pages basically give all the information one needs to apply patch vectors. I used them in recent months while working on the Special Edition of my 2004 game "Willy's New Mansion" (to be released on 10 May, if all goes well). There were some things I had to understand before applying the patch vectors, however, and so now that I have been through it, I would like to share the information a little more "manual-style" than Geoff did in his notes, so that anyone interested can apply these changes in their own projects. First of all, what I call "the main patch vector" (which Geoff simply calls "the patch vector", but they are all patch vectors, so I think it's good to distinguish this one from all the other, room-speficic ones) has to be called from the main game loop. Geoff does it at #89F5-#89F7. I'm not sure if it has to necessarily be in this very spot, but I have just followed what Geoff did and placed it there and it works fine. So at #89F5 you have to insert the following code: CD x y CD is the CALL instruction, and x y are the two parts of the address where your "main patch vector" will be, in reversed order. So, for example, if you place the main patch vector at #8141, the CALL instruction at #89F5 has to be: CD 41 81 Now, in order to be able to insert the call instruction at #89F5, you need to have three bytes of unused space there. These are easy to achieve in a non-modified JSW48 game, because there is code which is unused at #8A0B - #8A25. So my suggestion is to (for example): - Move the code at #89F5-#8A0A three bytes down to #89F8-#8A0D (this frees up #89F5-#89F7). - Insert "CD 41 81" at #89F5-#89F7. - NOP out (set to zeroes) the addresses #8A0E-#8A25. In this case, the main patch vector is set to be at #8141. This address is the beginning of unused space which extends until #81FF in an unmodified JSW48 game. The main patch vector is 5 bytes long and it is the following code: 2A EE 80 E9 C9 So you need to insert this code at #8141-#8145. It could be inserted somewhere else where free space is, of course; in such case the CALL command at #89F5-#89F7 would have to be adjusted accordingly (to show the correct address). Now, as quoted before, the main patch vector uses two bytes within the room data of each room to specify the location of a subroutine which will be called to achieve some special effects. These bytes are always at #nnEE and #nnEF in the room data. So, for example, they would be at #C0EE and #C0EF in "The Off Licence" in the original "JSW". Incidentally, the preceding byte within the room data (at #nnED, so for example at #C0ED in "The Off Licence") is also unused by an unmodified game engine. It can be used for other purposes. Andrew Broad used it to determine Willy's character in each room in his game "Jet Set Willy: The Lord of the Rings". It has also been used to determine the in-game tune in each room in "Jet Set Willy: The Nightmare Edition" and in the soon-to-be-released Special Edition of "Willy New Mansion". Now, after applying the instruction to call the main patch vector and the main patch vector itself, the value of the addresses #nnEE and #nnEF in *every* room has to be modified adequately, i.e. it has to hold the address of the patch vector meant for this room or - if no patch vector is meant for this room - it *has* to point to the address where the C9 (RET) instruction is in the main patch vector. So in the example we are discussing, in every room where no patch vector is to be applied, the value of #nnEE and #nnEF *has* to be 45 81 - because the instruction C9 at the end of the main patch vector is at 8145. Otherwise the game will crash upon entering a room where this has not been set properly. In the rooms where specific patch vectors are to be applied, the value of #nnEE and #nnEF should point to the addresses where these patch vectors start. So, for example, using the free space extending between #8141 and #81FF, we we could insert a patch vector which will do something special in "The Off Licence". We could place this patch vector right after the main patch vector, starting at #8146. So the value of the addresses #C0EE and #C0EF would have to be, respectively, 46 and 81, to point to the address 8146 where the patch vector for this room begins. [EDIT: Additional info added following Ian's advice]: Every patch vector should end with a RET (C9) instruction, so that after executing it the program jumps back to the main loop. It has to happen at the very end of the patch vector, of course: some patch vector themselves call subroutines with CALL instructions within them; others may comprise several chunks of code with JP instructions in-between them. The important thing is that at the end of everything a patch vector is supposed to do there must be a return to the main loop or else the program will (most probably) crash. This is all concerning the general rules of how to apply patch vectors. Now, what can be achieved using them, can be seen in Geoff Eddy's games. It will also be very apparent in the Special Edition of "Willy's New Mansion", where the majority of the rooms (62 out of 66) will have specific patch vectors, both copied from Geoff's games (and modified in some cases) and of my own design :) . In fact, I believe the Special Edition of "Willy's New Mansion" will be the most-patch-vector-intense game ever released (among the ones using the JSW48 game engine, at least). I hope this is helpful. If you have any questions, I will try to answer them to the best of my knowledge :) .

Please post an RZX. It's interesting. I tried it on Spectaculator 7 (I have 8 as well, but I prefer the display in 7) and I *think* I tried it with the music off and without jumping and still didn't notice it. Having said that, my test may have been not comprehensive enough (I also tried it on Spin and I couldn't guarantee right now that I tried all the possible options [music on jumping, music off jumping, music on non-jumping, music off non-jumping, etc.] on *both* emulators).

Thanks for your feedback, Metalmickey! What emulator are you using? I have tried to check the quirk you mention in that collecting an item leaves the border at a different colour until Willy jumps. However, I don't see it happen either in Spin or in Spectaculator! :unsure:

Thanks again!

I agree that Rowson did a great job. I enjoyed exploring and struggling to complete "JSW II" immensely back in the days of the real Spectrum :) .

Thanks for the tip, Richard!

Thanks, Andy. How about something PC-based that would dump the room names from a JSW game into a text file? Would you be able to create something like this?

Promised fulfilled! Andy, below is an RZX walkthrough of "JSW 2015 Bug Fixed Edition" completed with no loss of life at 8.06 am in-game time :) . Please feel free to send it to Daren if you would like it be hosted on RZX Archive as well (have you got his e-mail?). JSW 2015 Bugfix.rzx

Bug alert! Andy, I have decided to make good on my promise to record a smooth RZX walkthrough of the "Bug Fixed 2015" edition. Attached below is a partial effort. The recording was made from the file "Jetset Willy_BugFixed2015Edition_V2.tzx". As you can see at the end of it, there are some rogue cells in "The Off Licence". The red vertical guardian collides with one of them, making the Bug Fixed edition impossible to complete :o . If you release a corrected version, I will do the recording for you. Incidentally, playing the original JSW after playtesting "The Nigthmare Edition" various times makes me feel that we done a good job on "TNE". The original feels empty and trivial in comparison... :) JSW 2015 Bugfix.rzx

This is an important discovery, Andy, and one that John Elliott should be made aware of. I'm not sure he is following the forum regularly - perhaps sending him a PM would be a good idea?

Well, I don't think I can help with this, but do post the files, just out of interest. I'll have a look at them. If there is any specific problem with JSWED, it's best to let John Elliott know about it, as he should be able to address *any* issues that arise.

I am thrilled to announce that

What format did you save the game in? IIRC, as far as JSWII is concerned, JSWED does *not* (hopefully - yet) support saving TAP files, only Z80. Could this be the cause of the problem?

Thanks for this, Andrew. I've also had a go at solving the problem, and it is indeed the vertical guardian which is causing it. A solution to it is to edit the guardian's range and starting position. The following POKEs do the trick: In Decimal: 65245,5 65247,64 65250,64 65251,80 or in Hex: #FEDD,05 #FEDF,40 #FEE2,40 #FEE3,50 I'll let Softwarecete know about it and I hope they will release a bug-fixed version of "Jet Set Luis" soon :).

The release of "TNE" is mentioned in Chronology. However, the game doesn't appear on the Game list, because it doesn't fit in any of the categories present there, being a remix of the original which doesn't claim to be a new game. I will probably create such a category In the future, for remixes and various versions of the original JSW.

I am very pleased to say that the creators of "Jet Set Luis" responded to my private message immediately and answered all my questions. :) The people behind Softwarecete (tu software de Albacete) are: