Overview
The software of the ZX80 comprises the BASIC interpreter, the Editor and whatever it is that does the rest of the work (Operating System seems too grand a title).
What's here?
Program entry
For two reasons, the keying in of programs is an absolute joy! First you don't have to type in many of the BASIC instruction codes, one key is sufficient; second you cannot enter anything that is syntactically incorrect. Some BASIC instructions have to be entered the long way (these are listed above the keyboard) but 29 of the instructions may be entered with a single key stroke, while only 8 need to be keyed in full.
As with many micros most of the instruction codes are stored in a single byte. Normal Z80 machine code can be entered using the POKE statement and executed with the USR instructi on. This should keep the buffs happy after they have tired of BASIC. Syntac checking is superb - it's impossible to go wrong. Every character is checked on entry and, it the interpretor thinks that you are going to make a mistake, it signals with a reverse S (for Syntax) a t the point it thinks you have gone wrong. If, later in the same line you correct the error, then the marker disappears. What a grown up facility for such a small machine! Incidentally, the program lines are displayed very clearly with line numbers, instructions, operators and what have you being nicely spaced out.
Code storage
Inside the machine, the lines of code are held as compactly as possible with most of the commands and operators occupying one byte each. The spaces are removed and there are very few extra bytes needed - for instance the new line code is one byte, although I did notice the "=" operator needed one extra for some reason. I'm sure there are others, but I'm equally sure they are very few and far between. An example of the storage requirement is as follows:
10 FOR A=16424 TO 17424 18 Bytes
20 PRINT PEEK(A); 12 Bytes
30 NEXT A 5 Bytes
40 STOP 4 Bytes
So you see, the storage for that program (displaying the 1K memory) is 39 bytes long - an average of 10 bytes per instruction. I'll leave you to work out what sort of program you can get in 1K. Perhaps I should mention that the screen buffer uses part of the 1K, as does the stack and system control area. The stack is held at the top of memory and "grows" down; I put 327 entries on it before it stopped accepting them.
The program and variables "grow" up the into the screen buffer thus reducing the amount of data on display. Eventually it's possible for the porgram or variables to grow so large that there's nothing left on display. It was while experimenting with this interesting feature that I crashed the system. It seems the software couln't cope with someone entering a string 868 bytes long! After about 424 bytes of input the screen removed another character every time I keyed in a new one - it was most odd to watch.
Another way of crashing the system, in fact the only other way I could find, is to hit the EDIT key while in the middle of an INPUT loop. This returns the current program line with a syntax error which is impossible to clear. For those who are feeling unhappy about all this talk of crashing systems, don't worry, it's not as bad as it sounds. In the first place you have to enter forty characters after the screen has gone blank, and in the second place you can only hit EDIT when you are holding the SHIFT key down.
|