Index | wersja polska |

- 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 errors in function arguments within parentheses. Example: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($+$)

**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. - The multiplication and division can produce small numbers out of specified limits, in range
1E-4097..9.999999999E-4097 (biased exponent=0x0000) or -1E-4097..-9.999999999E-4097 (biased exponent=0x8000), without reporting underflow.
Examples:

A=1E-4096/2 B=-1E-4096*0.1

The system isn't prepared to cope with such numbers. For example, the variable A (also A+A or A-A) is printed as 5, but most arithmetical operations treat it as 0. - 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 answerPerform 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