jetsetdanny

Very interesting! :)

My comments in blue:

If it is, then so is setting the flying pig as Willy's sprite in "The Nightmare Room" in the original JSW, isn't it? And *if* the Jukebox routine is called 'Danny's Jukebox routine' (which is an honour to me, of course :blush:), it should be called (as of "Willy's New Mansion SE", when it's released) 'Danny's Jukebox routine perfected by Ian', or something like that, since Ian has noticed and suggested a very significant increase in its efficiency since the release of "The Nightmare Edition" (in the sense of using significantly fewer bytes while achieving the same effect) :) .

Ian, I believe the fact that Willy gets stuck in this particular place is related to the conveyor. If there was no conveyor there (or if it had a different direction), Willy wouldn't get stuck (he could always walk left).

Well done, Ian! :) Will you document the fix later on (the modifications to the code)?

Twenty days before the planned release of the Special Edition of "Willy's New Mansion", I am pleased to confirm that the game should indeed be released on 10th May 2016, as scheduled. A Release Candidate is currently undergoing playtesting and the main task which remains to be done is finishing the Readme file :) .

I am pleased to say I *think* I have completed the last code consolidation in "WNM SE" and I *hope* it's really the last one. I have inserted Stuart's Cell Graphics Bug Fix into the main loop thanks to Ian's technical tips. Hats off to both gentlemen for their contribution! :) I have consolidated the code related to some of the patch vectors and moved things around a bit. As a result, apart from finding "secure" space for the "border colour restoration" code (which I had to move from the "endangered" area in A3...), I also inserted another "customised"* patch vector (PV) into the game, bringing the total of rooms with PVs to 63 out of 66. The three rooms which do not have patch vectors are: "The Multi-Toilet Bathroom" (a special room in itself, obviously), "Jump 'n' Jive" (the very first JSW room I ever designed) and "Copin' with Ropin'" (a room which doesn't need any PV for the kind of challenge it has). There are several "customised" PVs in "WNM SE" which comprise the following parts: an "introductory" part setting a variable or some variables within the PV proper and then the "PV proper" which executes whatever is supposed to happen. So the "introductory" parts are different for each room this PV is applied in, while the "PV proper" is just one and the same for all.

I'll try to provide a short update on "WNM SE" tomorrow, time permitting. There's work in progress, still :) .

Congratulations, Ian! You are quickly becoming an expert on Z80 machine code :). For my part, I have successfully inserted Stuart's Graphic Bug fix into the main loop in "WNM SE" (thanks to your technical tips). More about it later.

Thanks for your explanation, Andrew!

It could be a rope, certainly. I do have the 'adjacent ropes patch' in place. It even occured to me that *it* could be using this space to write data to (instead of the buffer at 81..). In any case, this area is now 'too suspicious' for me to place any code...

I've done just that and the results are not encouraging. I put the code which stops the border from getting stuck on the wrong colour for the room Willy is in, if Willy collects an item or the arrow warning sound occurs whilst the in-game music is switched off (called from 925E and 941D) at A3F9

My preference is to leave some rooms without patch vectors, for various reasons, both room-specific and general, the general one being to prove that it is also possible to have rooms *without* any PVs ;) . Not all rooms where there are active PVs have PVs which are exclusive. In other words, there are several PVs which are applied, without any variation, in more than one room. So it wouldn't be a problem to add some of them to the rooms which have no active PVs at the moment. However, I don't think I will be doing it.

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