"THERE IS NOTHING IN THIS ROOM" message never shown
In the routine at
29330 that processes Magic Knight's "PICK UP OBJECT" command, the section of code starting at
29339 is intended to count the
number of objects present in Magic Knight's current room. This count of objects is accumulated in the
C register, and after the total (copied into
A) is compared with zero at
29358, a conditional jump occurs to
55192 to display the "THERE IS NOTHING IN THIS ROOM" message window should the
total be zero. Unfortunately this does not work as intended because the
C register is not initialised to zero at the beginning of the count.
The instruction at
29342 (
LD BC,3200) actually initialises
C to 128, so the count can never equal zero. Additionally, this same
instruction should initialise
B (the number of objects to check to determine whether they are in Magic Knight's current room) to 37 as there are 37
objects in the game; instead
B is initialised to 12. So as it stands, this routine only counts the number of objects among the first 12 that are in
Magic Knight's current room, and adds this total to 128. Therefore it is clearly impossible for the count to hold any value outside the range 128 - 140
(i.e. it is never zero), so the "THERE IS NOTHING IN THIS ROOM" message is never shown. Instead, the "THERE IS NOTHING NEAR ENOUGH" message is shown:
The offending instruction should actually be LD BC,9472.
To fix, and ensure that
B and
C are initialised to 37 and 0 respectively:
POKE
29343,0
POKE
29344,37
This bug is also present in Spellbound
Too many objects are checked
Another bug, related to the one above, involves the routine at
29330. The instruction at
29374 loads
B with 50, in preparation for a loop
iterating over all objects' positions, however there are only 37 objects in the game. As a result of this bug, the code that checks the positions of
objects runs over the end of the objects' current positions table at
25286 and into the current planetary data table at
25397. Due to the nature of
the data stored from
25397 onwards, it seems that a conflict (i.e. a false match with an "object") is unlikely, so in most circumstances this bug will
not manifest any symptoms.
Examine USS Pisces
The instruction at
30199 is intended to check whether or not Magic Knight is aboard the USS Pisces when attempting to examine the starship. If Magic
Knight is not aboard the ship, a message window should be displayed ("YOU CANNOT EXAMINE THE USS PISCES IF YOU ARE NOT ABOARD THE MAIN SECTION OF THE
SHIP"). In order to check whether or not Magic Knight is aboard the USS Pisces, his current room's index is compared against the number 12 which is the
index of the McTablet Food room on Starbase 1. However, if Magic Knight is in the room to the left of this (The Transporter Room, Starbase 1, index 11)
then the check is passed even though he is not aboard the starship. The instruction here should instead check Magic Knight's current room index against
11, i.e. it should be
CP 11, not
CP 12.
Extra flag set
The routine at
31312 processes the command to cast a lightning bolt. When Magic Knight casts a lightning bolt at the Control Column, the instruction
at
31374 (
OR 3) is intended to set the tyme-machine-charged flag, however as well as doing this it also sets the barriers-removed flag. The
tyme-machine-charged flag is stored in bit 1 of the byte at
23403, so the instruction should be
OR 2.
Incorrect window type
When Magic Knight has his accident with the glue, photograph and blank ID card, an information window is displayed explaining that happened. However
this window is not really an information window - it's a menu window! The instruction at
34463 calls the routine for drawing menu windows and as a
result the hand cursor is also drawn. This isn't really noticeable though, since immediately after drawing the window and hand cursor, the text is
printed, overwriting the hand cursor graphic.
Starfield rendering
The instruction at
36301 is
LD C,A, however it appears the correct instruction should be
LD A,C as we are checking (in
A) that the
x-component of a star's direction is non-zero when its y-component has already been checked as zero. As it is, the value in
A is not modified from
instruction at
36294 where it is set to the y-component. In the existing code, the value of
A is set at
36294, then at
36299 a conditional
jump occurs if the value in
A is not 70. If the jump does not occur, then the (same) value in
A is loaded into
C, then another conditional
jump occurs only if the (unchanged) value in
A is equal to 128 (which is can't be, because this instruction is only reached if
A is 70!)
To fix, change the instruction at
36301 from
LD C,A to
LD A,C:
POKE
36301,121
This bug is also present in Spellbound
Inconsistent floor colour
Room number 04 ("CARGO HOLD", USS PISCES) has its floor drawn with attribute 86 (yellow INK, red PAPER, BRIGHT) whereas all other rooms on the USS
PISCES have their floors drawn with attribute 94 (yellow INK, magenta PAPER, BRIGHT).
Pass through airlock wall
Magic Knight can pass through the wall separating the Airlock from the Life Boat / Control Column.
To fix, increase the x-coordinate at which Magic Knight can be moved into a new room to the right:
POKE
28286,235