J. G. Harston's extension allowing more than 64 rooms in JSW48

[jetsetdanny]

On his website, Jonathan Graham Harston discusses his extension, which allows the JSW48 game engine to handle more than 64 rooms.

 

He says,

 

---

JSW48 uses 6-bit room numbers, giving rooms 0 to 63, with room 0 in memory at &C000. However, the only place where this is fixed is the code that fetches a room into the room buffer and the object location table. The current room variable and the room exits in the room data are all 8-bit values.

 

This patches the code to allow 7-bit room numbers to increase the number of rooms that can be used. Rooms.hex is an Intel Hex patchfile that can be applied to the original JSW48 game engine.

 

The room fetching code uses OR &C0 to map a room number from 0 to 63 to an address from &C0xx to &FFxx. This could be changed to ADD &C0 to use the whole 8-bit value, mapping rooms 192 to 255 to the spare memory within the code. I chose to change it to XOR &C0, as this maps the spare memory to rooms 64 to 127, running on from the existing 0 to 63. Also, a 7-bit room number is easier to fit into an extended object table.

 

Patching with POKE 35093,238 gives the following change:

 

Original code:                                              Changed to:

8912  3A 20 84    LD   A,(&8420)         8912  3A 20 84        LD   A,(&8420)

8915  F6 C0        OR   &C0                 8915  EE C0           XOR  &C0

 

This gives 8-bit room numbers, mapped to the following areas of memory:

 

Room numbers                 Memory

0 - 63                            &C000 - &FFFF

64 - 127                        &8000 - &BFFF

128 - 192                      &4000 - &7FFF

192 - 255                      &0000 - &3FFF

---

 

I have to admit this description is a little confusing to me and so my question is:

 

Does POKE 35093,238 make the game engine use 7-bit room numbers or 8-bit room numbers?

 

 

I need this clarification for the Readme file accompanying the Special Edition of "Willy's New Mansion" (to be released soon).

 

Jonathan's extension is used in this game, which features two rooms more than the Original Edition (66 in total). It has been used in the past in "Willy's Hoard" (75 rooms, an all-time high for a JSW48 game so far), the Final Edition of Steve Worek's "Jet Set Emily: Baby on the Go" (71 rooms) and "Jet Set Willy: The Nightmare Edition" (65 rooms).

 

Thanks for your invention, Jonathan!  :)

Edited September 7, 2016 by jetsetdanny

[IRF]

I think you're only using 7-bit room numbers in practice, as any room number that is 128 or greater (i.e. extending into the highest bit) would be contained in the ROM (Rooms 192-255) or the 'contended RAM' where the buffers sit (Rooms 128-191 ... N.B. There's a typo in Jonathan's table where he states Rooms 128-192 for this memory range).

 

So perhaps you're theoretically able to have an 8-bit room number, but it isn't possible in practice?

 

i wonder if Andy can add anything useful to the debate?

Edited September 7, 2016 by IRF

[Spider]

He is a member here so he may see this and reply. :)

 

Room numbers, well with 8 bits you can have 256 (0 to 255) 'numbers' as such'

[jetsetdanny]

Thanks, guys.

 

My question really arose because I have the following sentence in "WNM SE" Readme:

 

The value of the address #8916 (corresponding to #8915 in the original "JSW") has been changed to #EE, which allowed the game engine to use 7-bit room numbers instead of 6-bit ones. 

 

and I'm not sure whether it should say "7-bit" or "8-bit" here - in this particular context. 

 

My feeling is that it should read "8-bit", but I'm not 100% sure.

[IRF]

I would argue that the statement, as quoted above, is certainly true.  The fact that you might also be able to use 8-bit room numbers does not negate the truth of the statement that the change allows 7-bit room numbers.  And it is questionable whether 8-bit room numbers are possible in practice.  The change from OR to XOR may open up the possibility, but other factors (i.e. the use of the lower memory for other purposes) preclude room numbers beyond 127.  So for simplicity, I would stick with what you have put. :)

Edited September 7, 2016 by IRF

[IRF]

You might get away with creating a Room Number 155 (occupying the memory range #5B00-5BFF), if you didn't have any guardians in the room (i.e. just an 'FF' terminator byte at #5BF0, followed by 15 NOPped out bytes from #5BF1-5BFF).

 

The bottom end of that 'page' of memory is the beginning of the stack, so Return addresses from CALL commands and register-pair values placed there by PUSH commands would occupy the area where the Guardian Specifications would otherwise sit.  Depending how much the stack is utilised during the game*, the rest of the room's data might be left alone?  (The stack entries would get copied to the end of the Room Buffer upon Willy's entry to Room 155, but with no adverse effect on the running of the game if they are preceded by the 'FF' Guardian List Terminator byte.)

 

However, I don't think that any items could be displayed in a room in the range 128-255, unless the Draw the Items code were to undergo further modification.  As things stand, Bit 7 of the first byte for each item's definition stores part of its y-coordinate, which is discounted (reset) for the purposes of comparing each item's room number with the current room number at #93DF.

 

 

* Obviously the stack as an entity is used a lot, but if values get PUSHED on and then POPPED back off, then you don't progress 'up' the stack as a result; so what I really mean is how many consecutive entries (which fill up two bytes each time) get put there, starting at the bottom (#FBFE-FBFF) - i.e. consecutive PUSH commands, sub-routines called from sub-routines (generating multiple RETURN addresses on the stack), that kind of thing.  Any more than six of those, on top of the two-byte entry which defines the game's starting point (namely #869F, or #87CA if the 'code entry routines' have been expunged), and you'll reach the location of (and overwrite) the room's Guardian Terminator byte at #5BF0.  Which could lead to corruption of the whole game file, a la 'The Attic Bug'!

 

Perhaps one were to insert the value 'FF' at #5BF0 in a test file, and then PEEKed at the value of that byte during the course of a game, then one could verify that it isn't ever modified from its initial value throughout the game, and so anything from that point upwards in 'memory page #FB' could safely be used to define a Room 155?  But for the sake of a single room with no guardians and no items, there's probably no point other than as an 'academic exercise'!?

 

 

EDIT: The memory range #5B00-5BFF is also apparently used as the 'Printer Buffer' - I presume that harks back to days of yore when you physically plugged a Spectrum into a Dot Matrix Printer or suchlike, and that alternative function wouldn't affect the values in that range, in this context?

Edited September 7, 2016 by IRF

[jetsetdanny]

I would argue that the statement, as quoted above, is certainly true.  The fact that you might also be able to use 8-bit room numbers does not negate the truth of the statement that the change allows 7-bit room numbers.  And it is questionable whether 8-bit room numbers are possible in practice.  The change from OR to XOR may open up the possibility, but other factors (i.e. the use of the lower memory for other purposes) preclude room numbers beyond 127.  So for simplicity, I would stick with what you have put. :)

 

Thanks for your reply, Ian.

 

I do have this bit in "WNM SE" Readme (as a quote from J. G. Harston's explanations):

 

---

This gives 8-bit room numbers, mapped to the following areas of memory:

 

Room numbers                 Memory

0 - 63                            &C000 - &FFFF

64 - 127                        &8000 - &BFFF

128 - 192                      &4000 - &7FFF

192 - 255                      &0000 - &3FFF

---

 

and this is probably why I felt uncomfortable mentioning 7-bit numbers earlier on, because it seems not quite logical to say "This allows the game engine to use 7-bit numbers" and then go on about "8-bit numbers".

 

Perhaps a reasonable compromise between logic and simplicity would be to say, in the sentence I quoted above:

 

The value of the address #8916 (corresponding to #8915 in the original "JSW") has been changed to #EE, which allowed the game engine to use 7- or even 8-bit room numbers instead of 6-bit ones.

 

Do you think this would be factually correct?

Edited September 7, 2016 by jetsetdanny

[IRF]

How about: "allowed the game engine to use 7-bit (or, in theory, even 8-bit) room numbers, instead of 6-bit ones"?

 

Also, if you're quoting the bit from JG Harston's page, perhaps you could correct the typo thus:

 

Room numbers                 Memory

0 - 63                            &C000 - &FFFF

64 - 127                        &8000 - &BFFF

128 - [191]                    &4000 - &7FFF

192 - 255                      &0000 - &3FFF

 

With the square brackets signifying that you're correcting an error in the original source article.  Then you'd be neither stating an inaccurate fact, nor misquoting the original article.

[jetsetdanny]

That sounds good, Ian, thanks!