Elektronika MK-85 - undocumented features, quirks, bugs

Command WHO displays information about the author of the firmware.
The exclamation point allows to enter comments into the program. All characters after the exclamation point up to the end of the line are ignored. Lines containing only a comment (i.e. starting with an exclamation point) aren't allowed. Example:
```
  10 A=1!This is a comment
```
Command SET accepts the SET N syntax, which cancels the precision setting for printed numbers.
The error message ERR! reports interpreter internal errors. Examples:
```
  SIN (0/0)
  TAN (1>0)
```
Command DEFM followed by a comma and variable name assigns maximal number of additional variables to the specified variable. Valid only in programs, not in direct mode. Example:
```
  10 DEFM ,A
  20 PRINT "Max=";A
```
Both a sole variable name and a variable with assigned value are allowed for some commands accepting a variable as an argument. For example, the following bizarre program doesn't cause any errors:
```
  10 PRINT A=123;B$="ABC"
  20 INPUT C=5,D$="DEF"
  30 SET K=2
  40 DEFM ,M=3
  50 I=3
  60 FOR I TO 5
  70 NEXT I=10
  80 GOTO X=10
```
The MK-85 doesn't mind comparing a string with a number. It choses between the string/number comparison routine testing only the expression on the right side of the relational operator. For example, it happily executes the following program:
```
  10 A=1: $="ABC"
  20 IF A=$ THEN 30
  30 IF $>5 THEN 40
  40 END
```
The string concatenation routine doesn't anticipate a concatenated string as a second argument. For example, following expression is calculated wrong:
```
  "12"+("34"+"56")
```
The same memory area is allocated for the buffer for concatenated strings and the stack for evaluated expressions. This stack can be overwritten by the string, leading to various, unrelated error messages, as in the following malicious example:
```
  $="123456789012345"
  LEN($+$)
```
Function VAL of a string longer than 37 characters can overwrite the data stack or the expression evaluator stack. For example, the following expression causes an ERR2 error message:
```
  2*VAL"123456789012345678901234567890123456789012345"
```

INPUT doesn't check if a value written to a numerical variable is actually a number. Typing a string after the INPUT prompt trashes the variable contents. Try to enter some string (in quotes) or a string variable (for example $) in response to INPUT in following program:
```
  10 VAC
  20 INPUT A
  30 PRINT A$
```
INPUT fails to write an empty string to a string variable. The problem is caused by missing test of the length of the input string before copying it to the variable. Example:
```
  10 INPUT $
```
When the INPUT prompt appears, try to type [SPC], arrow-left, [DEL] and [EXE]. The system will crash and the RAM contents will be lost.
This bug was submitted by Sergei Gaidukov on 22.11.2005 09:45 to the iXBT Hardware BBS forum.
Due to incomplete type checking, the command INPUT accepts a number for a string variable as an argument. Typed input string is stored at the address formed of first four digits of the mantissa.
In the example below the variable $ will be overwritten by the string typed in response to the INPUT prompt:
```
  10 $="0123456789"
  20 INPUT 8150
  30 PRINT $
```
Yet another INPUT bug submitted by Denis Gorbunov to the guestbook of the mk85.narod.ru web site in an entry dated 09.01.2003 00:20.
Type this short line to the program area P0, then RUN it:
```
  1 INPUT A$:HH
```
When the INPUT prompt appears, press [AC] then [EXE] - the system will hang. Other characters than HH may cause different failures, for example system restart or memory contents corruption. The author came to a correct conclusion that the processor starts to execute the BASIC program as machine code!
Instruction LETC cannot be used within a subroutine, because it overwrites the first byte of the GOSUB stack. For example, this program causes an error when trying to RETURN:
```
  10 GOSUB 30
  20 END
  30 LETC "2222222"
  40 RETURN
```
This bug was discovered by Aleksei Akatov.
Arithmetic operations can produce small numbers out of allowed limits, in range 1E-4097..9.999999999E-4097 or -1E-4097..-9.999999999E-4097 (biased exponent=0), without reporting an underflow. Examples:
```
  1E-4096 / 2
  -1E-4096 * 0.1
  1E-4095 - 0.99E-4095
```
Finding the tangent (or any other function derived from the tangent, i.e. SIN, COS) of a number with an exponent of 4094 takes quite some time. For such large arguments the result is obviously meaningless. Examples:
```
  TAN 1E4094
  SIN -9E4094
```
Trigonometric functions with angles lower than ±1E-127 radians return invalid results or restart the system. Example:
```
  TAN 1E-130
```
Near-integer numbers are excessively rounded, similarly as in the Casio calculators, i.e. the results of all numeric calculations are corrected following way:
- if the last four mantissa digits are in range 0001..0009 then they are replaced with 0000
- if the last four mantissa digits are in range 9950..9999 then the number is rounded up until its last four digits are 0000
Examples:
The calculator displays only 10 digits, but the numbers are internally stored with a precision of 12 digits. How to extract those extra two digits:
- store in the variable A the result of the expression 7+34E-11
- the contents of the variable A is displayed as 7, thus the last two mantissa digits are not shown
- calculating the expression A-7 reveals the hidden digits showing 3.4E-10 as the answer

Perform the same test for the value of an expression 7+4E-11 stored in the variable A. This time calculating A-7 returns 0 instead of expected 4E-11.

Two more tests:
- for A=7+9934E-11 the expression A-7 evaluates as expected to 9.934E-8
- however, for A=7+9956E-11 the expression A-7 is surprisingly evaluated to 1E-7