Redundant instructions / code, part 1
Upon loading, a call is made (at 34428) to 59831 which contains the value 201, corresponding to the RET instruction, so this call effectively does nothing. Because this address lies near the beginning of a block of memory that at this point is not in use, it seems reasonable to assume that call was originally used in debugging or testing.
Coloured creatures' slots
The three coloured creatures' slots on level 3 are defined as entities at 44803 (red), 44816 (yellow) and 44829 (white). At these locations, both the top and bottom y-coordinates are given as 115. This means that the slots are considered to be only one character high in the game's logic, despite the graphic layout data for the three slots at 40138 (red), 40143 (yellow) and 40148 (white) displaying them as six characters high.
Redundant instructions / code, part 2
If Berk has collided with an entity of class 129 (as checked at 36249) causing him to fall to the right, he is made to drop any entity he is carrying by the CALL to 36296 at 36253. After this, the instruction at 36256 loads IY with the address of the definition of the entity Berk has just dropped. However the routine at 36296, which has just been called has already loaded IY with this very same value (instruction at 36305), making the instruction at 36256 redundant. This redundant load does not occur in the analogous block of code (starting at 36171) when Berk falls to the left.
Spiders' timing
It can be tricky to get past the three spiders on level 1; fortunately, players who have difficulty are given some consideration. In the routine at 37718 that controls the spiders' return to their homes, there is a check on the number of times Berk has been killed by a spider, as stored at 34223. The greater this value is, the longer the right-most spider will wait at its home position before beginning its next attack. A poke will ensure that the other two spiders behave in the same way.
Redundant instructions / code, part 3
The instruction at 38617 is a call to the routine at 38756 that moves a stalactite down one character and loads A with the updated y-coordinate of its top edge (see 38762). The instruction (at 38620) subsequent to this CALL loads A with the same value.
Width of skeleton
Level 4's skeleton is defined in an entry at 45404 to have a width of two characters (left and right edges at 128 and 129 respectively), when it is clearly significantly wider. In fact when checking for a collision between the skeleton and Berk, this reduced width has to be compensated for by a subtraction at 41528.
It is possible that this was done so that the cannon's projectile has to visibly penetrate the skeleton rather than merely impact on its left edge.
Flags galore
A large number of flags are used to support the logic of Through the Trap Door. These flags are represented by individual bits in the various entities' complex state data. Although many of these flags are applicable to all entities and use the same bit for each entity, many are applicable only to a single entity, or a subset of entities. For example, bit 6 of byte 10 of an entity's complex state data generally represents that entity's can-fall flag, however bit 4 of byte 9 is the carrying-something flag for Berk only. Some bits are used for several different purposes. Here is a list of the more significant flags, along with the entity / entities to which they apply:
Offset (bytes) Bit Meaning Description
8 7 Spans-full-depth flag Entity is considered to occupy both depth levels as far as collision detection is concerned. For example, this flag is set for Berk when the floating power-up is active. It is also set for markers involved in Berk / Drutt's falls.
9 0 (1 / 2) Must-process-current-script-data flag If set for an entity, then that entity cannot move except as scripted. Berk, for example, will ignore control input while this flag is set, e.g. while he is eating.
9 0 (2 / 2) Ghost's moving-upwards flag Used to denote that level 4's ghost is moving upwards (see routine at 41633)
9 1 Inactive flag Applies to the flying skeleton creature on level 1 only. Plays a role in the logic controlling Boni's kidnap and the behaviour of the Trap Door.
9 2 Trap-Door-opened flag Applies to the flying skeleton creature on level 1 only. Plays a role in the logic controlling Boni's kidnap and the behaviour of the Trap Door.
9 3 (1 / 2) Berk-and-Drutt-through-Trap-Door flag Applies to the flying skeleton creature on level 1 only. Plays a role in the logic controlling Boni's kidnap and the behaviour of the Trap Door.
9 3 (2 / 2) Harmless flag Applies to Bubo (level 2) only. Used to denote that Berk has obtained the "Bubo harmless" power-up.
9 4 Carrying-something flag Applies to Berk only. Used to denote that Berk is carrying something.
9 5 Do-not-update-state flag Applies to Berk only. Used in routines that control large yellow creature (level 3) attacking Berk.
9 6 Is-flying flag Applies to Berk only. Used to denote that Berk is-flying.
9 7 Moving-upwards flag Applies to Berk only. Used to denote that Berk is moving upwards when the floating power-up is active.
10 2 Back-to-level-1 flag Applies to Berk only. Used to denote that Berk has returned to level 1.
10 3 All-home flag Applies to Berk only. Used to denote that Berk, Boni and Drutt have all returned home at the end of the game.
10 5 Is-being-carried flag Used to denote that the entity is being carried by Berk.
10 6 Can-fall flag Used to denote that the entity should respect gravity and fall. If reset then the entity will not fall.
11 0 Walking-right flag Used to denote that the entity is walking / moving right.
11 1 Walking-left flag Used to denote that the entity is walking / moving left.
11 4 Impassable-leftwards flag Used to denote that the entity cannot be passed in a leftward direction but may be pushed.
11 5 Impassable-rightwards flag Used to denote that the entity cannot be passed in a rightward direction but may be pushed.
11 6 Interaction-(11,6) flag Used in collision detection routines.
11 7 Interaction-(11,7) flag Used in collision detection routines.
12 7 Is-jumping flag Applies to Berk and Drutt only. Used to denote that Berk / Drutt is jumping.
Redundant instructions / code, part 4
The address 49934 lies within a block of graphic layout data responsible for defining level 3's glowing tangleweeds. The rendering instructions at this address are used by several different variants of tangleweed. The instruction at this location is one that selects an address at random from a list and jumps to it; this is used to make the tangleweeds blink between green and yellow at random. The random selection is weighted so that green is twice as likely to be selected as yellow, however this is done by defining the green tangleweed twice (at 49942 and again at 49952). The same effect could have been achieved simply by listing the "green" address twice; this would have also saved a few bytes.
A side-effect (and perhaps the originally intended purpose) of this is that a third colour can be chosen for the tangleweeds in addition to green and yellow. Either of the existing instructions relating to the green colour can be changed to introduce the third colour:
POKE 49943,x
POKE 49953,x
where x is the index of the required colour.
The same situation exists further on, at 49971, where another set of tangleweeds is defined in the same way.
Height of weight
The weight on level 3 is defined as being three characters high in its complex definition data at 44933, yet its graphic layout data at 41175 contains instructions for drawing four character rows of UDGs. As a result, the top of the weight is one character above where it should be when held by Berk. This is not a bug, however, and the resulting effect looks quite natural given that the weight is apparently bottom-heavy.
Graphics wider than display
Parts of some graphics (e.g. the stalactites defined at 51202) lie outside the displayed area. Such graphics may still be partially displayed when assigned to a simple or complex entity, as long as that entity's top and left edges are positioned such that part of the graphic falls into the display area.
For example, only the left-most seven of the nine stalactites at defined at 51202 will be shown if the entity to which that graphic layout address is assigned has its left edge at an x-coordinate of zero. If an x-coordinate of -2 is given, then eight of the nine stalactites will be shown. An x-coordinate of -4 will show the last eight stalactites, with the first being off-screen to the left.
Redundant instructions / code, part 5
The routine at 45965 populates the primary display buffer with graphic layout data for an entity. During this population process, a check is done at 46142 to determine whether the x-coordinate we are currently drawing to is zero after incrementing (i.e. was previously 255). However it appears that there is no way for this to be the case, so this check is redundant.
Redundant instructions / code, part 6
If a Kempston joystick is present and functioning, then the instruction at 46930 loads A with 1. This value is stored at 34298 (joystick-mode flag) by the next instruction. Then a jump occurs at 46935 to 46938, at which point the value is stored at 34298 a second time. Ideally, the instruction at 46932 should be removed entirely.
Redundant instructions / code, part 7
In the routine at 52193 that advances the position of an entity pushed right by Drutt, A is loaded with zero at 52233 for no apparent reason. There is no such instruction in the equivalent routine (at 52098) for an entity pushed left.
Redundant instructions / code, part 8
The routine at 52315 handles Drutt's change of depth levels. A check is done at 52315, and if Drutt's current depth level is not 1, then we jump to 52351 where another check is done to see if Drutt's depth level is 1. Since each of these conditions is the inverse of the other, there is no way for them both to be satisfied simultaneously and therefore there is no point in checking both.
Redundant instructions / code, part 9
The motion of Berk's feet when walking is defined in the graphic layout data at 55743 (walking right) and 56284 (walking left). At both of these locations, there is a list of graphic layout data addresses to be rendered sequentially to give the illusion of motion. Each of these lists contains eight addresses, however the eighth entry in each list is not used because the instructions at the start of the lists (55746 and 56284) states that the lists' lengths are seven. These missing frames of animation can be restored with a couple of POKEs:
POKE 55748,8
POKE 56286,8
The motion of Berk's arms while walking also has a missing frame (see 55765 and 56303). These can also be restored:
POKE 55767,8
POKE 56305,8
When restored, these additional frames make Berk's walk look slightly more awkward; perhaps this is the reason they were excluded from the lists.
Unused skeleton script
Level 4's skeleton has an unused block of script data at 41240. This script data instructs the skeleton to take a step forward, pause for a random (1-10) number of cycles then step back again.
Unused room index
Level 2's accessible rooms are numbered 1, 2, 3, 4, 6 and 7. There is no room with an index of 5 in the horizontal or vertical connectivity blocks, however there is in the room dimension data (44456). There is also a ceiling (44097) and a floor (43968) defined for this room.
Unused routine
The routine at 48791 is unused. As it deals primarily with data offset by 4, 5, 6 and 7 bytes from the values in the IX and IY registers, it is reasonable to assume that IX and IY hold the addresses of complex state data for two entities. This is supported by the instructions at 48838 and 48841 which do a check on the value of the data eight bytes on from the address in IX (the class field in complex state data); this check looks for a value of 31 which is Berk's class value.
It is possible that this routine was intended for use with the clawed foot on level 3, with IY representing the foot and IX representing the entity being picked up by the foot. Given the check at 48838-48841 it seems that originally the clawed foot may have been capable of picking up more than just Berk. Perhaps the coloured creatures puzzle was originally intended to be complicated by the clawed foot rearranging the creatures as well as attacking Berk. If this was the case, it may be that this was deemed too problematic to implement, and so the idea of having the creatures spontaneously switch positions was developed instead.
Unused sounds
In the table of sound parameters at 59634, there are three unused sounds (03, 10 and 11).
Redundant instructions / code, part 10
Script routine 31 (at 48976) is not used. Furthermore, the code within is identical in function to the code at 48958-48973.