'Guardian Aura' Bug Fix and miscellaneous other patches

[IRF]

That would make sense about the mediaeval scrolls.

 

I haven't had time to process the rest of the previous post yet (will do so later).

[IRF]

So if I understand correctly, in Norman's latest file the item definitions for Rooms 0-63 are stored at Offsets #80-#FF in pages #A4 and #A5 of the code, whereas item definitions for Rooms 64-127 are stored at Offsets #00-#7F on the same pages?

 

If this was ever developed further with 128 (or 120) fully independent rooms (rather than the new rooms 'shadowing' the original rooms), then may I humbly suggest that a similar arrangement could be put in place to what Andrew Broad did in his game 'Party Willy'.

 

Namely that Rooms 64-127 are located on the far side of Maria, and then an AND #7F gate is inserted in between the two commands at #9422 and #9425 (original addresses) in the 'Draw the items' routine.

 

This has the effect of splitting the game into two halves - the player must complete the first 64 rooms (collect the first 128 items) before they are able to proceed to the second half.

 

For reference:

http://www.worldofspectrum.org/pub/sinclair/games-info/p/PartyWilly_TechnicalNotes.txt

[Norman Sword]

Decided to test concept. One hour later I had an up and running 120 room version. 

Both completely independent and both can be remapped. No enthusiasm for doing so.

 

Both sets or rooms are free to cross to the other at any point. This is a full 120 room version. I can not think of any layout restrictions. 

[Norman Sword]

Extending the rooms up to 128. I wrote a couple of posts back of  a method to extend the key tables to have over 64 rooms. I was vague because I do not use the original source layout. So I have had a look at the original source and I am listing what is needed to extend the keys to enable 128 rooms. This is done without wasting a full 256 bytes of data, and uses very little to accomplish this.

 

This method gets around the key reset at game start up (no code change). It also has no need to calculate the total keys (the value is as before)

 

 

AT NEW ROOM set up

 

; use  $A3ff for the lower key OFFSET e.g this value is the numbers of keys in total. as before

.
; use  $A3fe for the upper key, this value holds the start of keys for rooms 64 upward

.

; storage of keys is laid out as follows

: from the value of ($a3ff) up to ($a3fe) the lower room keys 
; from the value in ($a3fe) up to $ff the keys for rooms 64 to 128

 

new code to implement change

 

      ld bc,($a3fe)

 

; c=upper key pointer   ; Changed from what I originally wrote
; b=lower key pointer

 

    LD A,(ROOM_NUMBER)
    AND 64 ;UPPER OR LOWER SET
    JR z,lower_set

    ld b,c ;set c=upper key offset
    ld c,0 ;set limit=0 to stop search

lower_set:

    ld a,b  ;this is the start of search
    ld ($93d4),a ;set the new base for search
    ld a,c
    ld ($9452),a ; set the upper limit of search

 

The above sets up the key collect routine

 

 

;-------------------------------------

modification to the key collect routine

address old code                               replace with

93d3 ld a,($A3ff)                                ld a,0   <<value modified
.                                                          nop

.

93E0 JR NZ,$9452                             JR NZ,$9450  <<< TWO BYTES EARLIER

.

942E JR $9452                                   JR $9450  << TWO BYTES EARLIER

.

 

944c   ld b,8                                         call $9699 ;two bytes earlier
944e   call $969b
944f                                                     pop hl
9450                                                    inc l
9451   POP HL                                    CP 00 <<value modified
9452   INC L
9453   JR NZ,$93D7                            JR NZ,$93D7          << unchanged

;--------------------------------

 

keys are stored in this fashion

START                      OFFSET IN $A3FF                        OFFSET IN $A3FE         THE 255TH ENTRY
OFFSET 0                 v                                                    v                                      v
0,0,0,0,0,0.....,0,0,0,0,L,L,L,L,L.....,L,L,L,L,L,L,L,L,L,L,L,H,H,H,H ......,H,H,H,H,H,H,H

.

WHERE L IS THE DATA FOR ROOMS 0 TO 63 (THE LOW ROOMS)

.
AND H IS THE DATA FOR ROOM 64 TO 127 (THE HIGH ROOMS)

Edited February 5, 2018 by Norman Sword

[IRF]

Ah, so my previous interpretation (i.e. a maximum of 128 items in each set of 60 rooms) wasn't quite right.  You could have, say 60 items in the first set of 60 rooms, and 196 items in the second set of 60 rooms, if you wanted to.

 

One small query regarding this excerpt:

 

 

      ld bc,($a3fe)

 

; c=lower_key offset
; b=upper_key offset

 

I believe the labels should read:

 

; b=lower_key offset
; c=upper_key offset

 

?

 

(Because the LD BC, (#0000) command is 'little-endian' in its operation.)

Edited January 8, 2019 by IRF

[Norman Sword]

Probably, I changed so much as I was writing it. I swapped a lot of the registers around and a lot of the upper/lower references.

I was changing the code as I wrote it.

I will re read and edit.

[IRF]

You could apply the same principle - i.e. at the Room Setup stage, update two variables which bookend the 'Draw the items' routine - to extend this idea from one of your earlier posts (on the subject of reducing 'overheads'):

 

1) sort the object list into room order. (done once at the start of the game). on room expansion, find the first object for the current room and store its offset. On each game loop start at the pre calculated offset and search only until no match for the current room.

 

If both the 'start search' and 'stop search' offsets were determined at Room Setup, then the length of the item-drawing loop would be fixed for each room, eliminating any need to search for an item-room match during execution of the Main Loop. (Thus reducing overheads and speeding up the game?)

 

EDIT: In its simplest form (for a 64 room game), the above would require two additional steps:

 

1) Sort the item list into room order, as per your quote above;

 

2) Take the existing code at #93D7-#93E1, and separate off the two checks which are currently performed simultaneously - the check for room numbers to go into a new 'item-filtering' subroutine called from Room Setup, whilst the check of whether each item has been collected yet (to determine whether to draw or collect it) would be retained in its current location.

 

(N.B. This is a classic case of a trade-off between byte-efficiency versus speed of execution.)

 

The new 'item-filtering loop' at Room Setup would search for the first room number match in the item list, and use the corresponding item index to define the initial value of L at #93D4. (Incidentally, that could just be a direct LD L,#00 command, ditching the following LD L,A.)

 

When the 'item-filtering loop' subsequently finds a room number which doesn't match, then go back one item and use that item index to overwrite the operand of the newly-inserted CP #00 operation at the end of the item-drawing loop (as suggested by Norman, but I think he forgot to insert a LD A,L beforehand, because COMPARE operations always test the A register?)

 

To handle a room with no items, if no matching entry in the item table (whether for a collected or uncollected item) is found for the room Willy is about to enter, then the 'item-filtering loop' could overwrite the address #93D1 with a RET command. That would then have to reinstated with its proper value every time a room number match (collected or uncollected) was detected by the item-filtering subroutine of the Room Setup routine.

 

****

 

Furthermore, the above could be combined with Norman's optimised 128 rooms item-handling code. The values stored at #A3FE-FF could determine the start and end points of the 'item-filtering loop' (to decide which half of the items are to be considered, based on Bit 6 of the room number), and then the item-filtering loop could in turn define the start and end points of the item-drawing loop, as per the suggestion above.

Edited February 6, 2018 by IRF

[IRF]

When the 'item-filtering loop' subsequently finds a room number which doesn't match, then g?o? ?b?a?c?k? ?o?n?e? ?i?t?e?m? and use that item index to overwrite the operand of the newly-inserted CP #00 operation at the end of the item-drawing loop (as suggested by Norman, but I think he forgot to insert a LD A,L beforehand, because COMPARE operations always test the A register?)

 

I made an error in the above, now struck out.

 

Also, in terms of fitting in the additional command LD A,L - if the LD A,(HL) at #943E is replaced with a LD A,D then one fewer RLCA command is needed at #943F-42, which frees up one byte in close proximity to #9450.

[Norman Sword]

:this is the above post rewritten to fix the missed

 

                                 LD A,L

;I could not find a space for the missed instruction so a redesign
.
Extending the rooms up to 128. I wrote a couple of posts back of  a method to extend the key tables to have over 64 rooms. I was vague because I do not use the original source layout. So I have had a look at the original source and I am listing what is needed to extend the keys to enable 128 rooms. This is done without wasting a full 256 bytes of data, and uses very little to accomplish this.

This method gets around the key reset at game start up (no code change). It also has no need to calculate the total keys (the value is as before)

AT NEW ROOM set up

; use  $A3ff for the lower key OFFSET e.g this value is the numbers of keys in total. as before
.
; use  $A3fe for the upper key, this value holds the start of keys for rooms 64 upward
.
; storage of keys is laid out as follows
: from the value of ($a3ff) up to ($a3fe) the lower room keys
; from the value in ($a3fe) up to $ff the keys for rooms 64 to 128

.
new code to implement change

. 
     ld bc,($a3fe)

.
;c=upper key pointer   ; Changed from what I originally wrote
; b=lower key pointer

. 
   LD A,(ROOM_NUMBER)
    AND 64 ;UPPER OR LOWER SET
    JR z,lower_set
    ld b,c ;set c=upper key offset
    ld c,0 ;set limit=0 to stop search
lower_set:
    or $40
    ld (93dc),a ; the room number searched for with bit 6 set
    ld a,b  ;this is the start of search
    ld ($93d2),a ;set the new base for search
    ld a,c
    ld ($93d6),a ; set the upper limit of search

.
The above sets up the key collect routine

;-------------------------------------
modification to the key collect routine
address old code                              replace with

93d1 ld h,$a4                                   ld hl,a4ff ; this is the start offset
93d2
93d3 ld a,($a3ff)
NEW LOOP HERE
93d4                                                  ld a,l
93d5                                                  cp $ff ;this value is the exit offset
93d6  ld l,a
OLD LOOP HERE
93d7    ld c,(hl)                                 ret z
93d8    res 7,c                                  ld c,(hl)
93d9                                                 res 7,c
93da ld a,($8240)
93db                                                 ld a,$ff ;this is the room number with bit 6 set
93dc
93dd  or $40                                     nop
93de                                                 nop
;

the final branch of this routine changed to
.

9453 jr 93d7                                    jr 93d4  ;change the loop address

;

;--------------------------------

keys are stored in this fashion
START                      OFFSET IN $A3FF                        OFFSET IN $A3FE         THE 255TH ENTRY
OFFSET 0                 v                                                    v                                      v
0,0,0,0,0,0.....,0,0,0,0,L,L,L,L,L.....,L,L,L,L,L,L,L,L,L,L,L,H,H,H,H ......,H,H,H,H,H,H,H
.
WHERE L IS THE DATA FOR ROOMS 0 TO 63 (THE LOW ROOMS)
.
AND H IS THE DATA FOR ROOM 64 TO 127 (THE HIGH ROOMS)

.
.
.

Not checked for difference in amount of changes. Removed most of the changes for the lower half of the key routine.

 

The above will only permit 255 keys and not the full 256

 

 
 

Edited February 6, 2018 by Norman Sword

[IRF]

This should allow the old version with a possible 256 items:

 

943E LD A,D

943F RLCA

9440 RLCA

9441 RLCA

9442 AND #08

9444 ADD A, #60

9446 LD D,A

9447 PUSH HL

9448 LD HL, #80E1

944B CALL #9699

944E POP HL

944F INC L

9450 LD A,L

9451 CP #00

9453 JR NZ, #93D7

9456 RET