Free space and code optimisation in "JSW"

[jetsetdanny]

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

[IRF]

There are two chunks of unused code, each 42 bytes long, in the 'Rope animation table' set of data:

 

http://skoolkid.github.io/jetsetwilly/asm/8300.html

 

It would appear that these 84 bytes (at #8356-837F and #83D6-83FF) can be used for other purposes, without affecting the game.

[jetsetdanny]

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?

[IRF]

Good question!

 

I suppose - like inserting data into the unused addresses in the Rope Animation table - you could 'suck it and see'!

[jetsetdanny]

Good question!

 

I suppose - like inserting data into the unused addresses in the Rope Animation table - you could 'suck it and see'!

 

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

[IRF]

Possibly a rope's data is overwriting it? Or do you have the 'adjacent ropes patch' in place?

[jetsetdanny]

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

[IRF]

If you don't mind having a shorter Title Screen tune - or none at all - then up to 99 bytes could be available for other purposes where the Title Screen tune is currently located in the code (#85FB to #865D).

 

The value 'FF' at #865E terminates the playing of the music on the title screen (and progresses the program to the screeching noise/scrolling message), so if you are shortening the music, then the 'FF' should be located to just after the shortened tune code (or to #85FB in the case of having no Title Screen tune).

[IRF]

There are 2 spare bytes here:

 

http://skoolkid.gith...y/asm/8C01.html
8C20 OR $10 Set bit 4 of A (for no apparent reason)

The command sets (assigns a value of 1) to bit 4 of A. But then it is immediately followed at #8C22 by XOR A, which resets all the bits of A (including bit 4) to 0.

So I am quite confident that those two bytes can be reused for other purposes.

[IRF]

I believe that everything from #840C to #841E is redundant code.