Panic!

HUNTER is designed, built and quality tested for robustness in every sense including robustness of program execution.

HUNTER’s microprocessor system has wide design tolerances (much more than conventional computers) to guarantee absolutely reliable execution of millions upon millions of machine-code instructions every hour. Its physical construction protects it against mechanical disturbance, while the conventional computer’s Achilles heel - external electrical interference - is virtually eliminated.

Because of these factors, HUNTER is most unlikely ever to mis-execute a user’s program or behave in a way that is not thoroughly predictable, given sufficient insight.

Crashes

However there are some specific situations that can cause HUNTER to mis-execute its internal programming, or “Crash”.

The commonest causes are:

• Illegal System Calls

  System calls from Basic are not ‘trapped’ (this would restrict user programming) and can cause mis-execution if not valid.

• Invalid user machine code

  User assembly-level programs or subroutines can easily cause mis-execution by containing, for instance, invalid jump instructions.

• Physical degradation

  Ingress of water, corrosion of internal parts, damage to components through excessive shock or persistent high level vibration can reduce electronic tolerances.

• Operation outside specified temperature range

  HUNTER is specified for operation in the range 0 to 55°C. Operation above 55°C reduces tolerances, while below 0°C battery capacity becomes severely restricted. Sub-zero temperatures also slow LCD screen response time substantially. HUNTER is unlikely to mis-execute program simply because of low temperatures, however, in the range 0°C to -20°C.

Symptoms

“Crashes” are identified by these symptoms:

• Keyboard Lock-out

  HUNTER’S keyboard is entirely “soft” to allow user re-definition of key functions, including the power key. If HUNTER’S internal program is caused to ‘Crash’, power control may be lost, HUNTER will not switch off.

• Clock wipe-out

  Following a mis-execution episode, HUNTER’S calendar clock registers may be corrupted.

• Program Corruption

  The most serious consequence of mis-execution is when the micro processor runs ‘wild’, writing data randomly to all parts of memory and, occasionally, corrupting user programs. This failure is generally catastrophic, and is unlikely to go undetected. The most likely consequence is that any attempt to ‘RUN’ the corrupted program will result in keyboard lock-out (see above). Attempts to ‘LIST’ corrupted programs may also result in lock-out.

• I/O Corruption

  I/O selections may be affected by mis-executions in a random fashion. In some cases spurious options may appear in the parameter selection screens after a ‘Crash’. In this event, hold down one of the cursor control keys until recognisable options appear.

Recovery

• Program Corruption

  If a mis-execution has occurred, any user program stored in RAM memory must be viewed with suspicion. The safest solution assuming that the use of keyboard is still available, is to type ‘NEW’, followed by reloading of the program.

  Remember that even ‘LIST’ may result in keyboard lockout although holding the power key down will generally restore control eventually.

  Most types of corruption (corrupted lines, spurious line numbers) are unrecoverable in Basic and can only be eliminated by NEW.

• Keyboard Lock-out

  If keyboard lock-out (failure to power down) occurs, it is necessary to power down HUNTER by removing the battery cap.

  HUNTER should power-up again normally. If desired, try running the user program, but be ready to clear any lock-out that occurs using the above methods. If lock-out persists, type ‘NEW’ after restoring operation.

• System Lock-out

  In very rare cases, HUNTER may fail to restart correctly after a mis-execution episode. This is possible in a program that uses auto-start, see Auto Power Feature, and contains an invalid system call.

  Any program corruption resulting could leave the auto-start flag set, but cause a lock-out when power-up is attempted.

  The solution is to apply the ‘ESC’ sequence immediately after power-up, in order to reset the auto-start flag.

• File corruption

  Because files are not stored in Hunter’s workspace (R0) area, mis-execution episodes are much less likely to cause corruption of this part of memory. In any case, the checksum facility will indicate if damage has ocurred. Current experience suggests that storing a ‘back up’ file in a different memory page virtually guarantees data integrity against the worst possible disasters.

  A checksum error can result in a “no file” message being displayed in response to an attempt to use the file, even if the directory entry is present. In this event, the only recourse is to re-load the file.