Reminiscencesof the Stone Age
Reminiscences of the Stone Age-the legacy of a little black box.
By Irving Brand.
The insubstantial volume which, in a moment of untypical curiosity, I casually removed from one of the shelves in my local library wasn't a specially attractive book, but it was a simple and straightforward introduction to the BASIC programming language-and it had me hooked. The revelation that I could, with a few well-thought-out instructions, get a machine to solve all my data processing problems, imbued me with a rarely experienced enthusiasm. Of course I was well aware that such machines existed, but what was so surprising was that I, as a mere layman, could so easily manipulate their every action. It was all so logical.
That was back in about 1980. Little did I know then, of course, that the apparently perfect programs which I subsequently developed on paper would be the seeds of unlimited frustration. Little had I surmised that these gems of creative genius would lead me to hours of syntax checking, reordering, correcting, bug extraction, etc., etc., when the time eventually came to feed the stuff into the innards of a real live machine.
My initiation into this next practical stage of computer addiction came with the acquisition of one of the first affordable computers to appear on the British market. The ZX81 was a neatly designed matte black case, a few centimeters thick and round about half the size of an A4 sheet of paper. On its upper surface it sported a completely flat pressure sensitive keyboard. Except for a couple of cables and a small power supply, that was it.
No monitor, no disk drive, and almost no memory (but more of that later). One of the supplied cables was to be connected to any common or garden UHF television, via the aerial socket, to furnish the display. The other cable, when plugged into a common or garden tape recorder (the commoner the better, as it turned out), provided a means of storing and retrieving programs on tape.
Inside this little black marvel, the manufacturers, Sinclair Research, managed to cram the processing, operating system, memory, and input/output control into a parsimonious set of four integrated circuits. These included a Z80A microprocessor, an 8K ROM chip which held Sinclair's version of BASIC, a single ULA that dealt with all input and output functions, and ....1K of RAM!
On power up the system would go directly into BASIC. The black and white display, which could accommodate 24 rows of 32 characters, was divided into two areas. The bottom two lines were used for typing and editing numbered program lines, which, when finished would jump up into the upper screen area in their appropriate position together with the other program lines. One interesting feature of the system was that lines in the editing area were checked for syntax and would not be allowed into the program unless correctly formed-something of a novelty at that time.
The actual typing was done on the pressure sensitive keyboard. There were no moving keys, simply a membrane with key locations printed on the exposed surface. On applying pressure the metallic backing would make contact with the printed circuit below. Each of the 40 'keys' could have several functions depending on which additional keys were pressed in conjunction with it. Thus a single key might produce a letter, a graphic, a function/operator, or a BASIC keyword. A further novel characteristic of Sinclair BASIC was that each keyword, or command, was assigned to a single key, allowing for single key entry of commands such as PRINT, INPUT, etc.-a saving of several key presses, and no chance of spelling mistakes to boot. This unorthodox approach had its advantages and disadvantages but one got used to it nevertheless, and often became quite attached to it.
It was, to be sure, no small electronic feat to compress so much functionality into such an inexpensive device, and one which could make use of readily available home appliances as peripherals. However, the interest for me derived, not so much from what it could do, but rather from how to get it to perform beyond its apparent limits. It was like some grand logical jig-saw puzzle, and the joy was as much in playing around with the pieces as in (eventually) achieving a satisfactory result.
It is amusing these days to hear computer folk bemoaning the limitations of their hundred and something MHz CPU, their megabytes of RAM, and their gigabytes of hard disk space, and then to think back to less than twenty years ago when I had to contend with a 3.5 MHz processor and a single kilobyte of memory. It was these very restrictions, however, which proved to be an inspiration to many a fledgling computer enthusiast. One had to seek out all manner of devious ploys to circumvent the lack of memory and speed imposed by the system.
Perhaps for me, the memory problem was the more important. Although 1K did not appear as miniscule then as it would today, the question of how to get a decent program into one kilobyte of RAM was still pertinent. One way, of course, was to make the program as short as possible. Leaving out REM lines, restricting variable names to single characters, and reusing subroutines were more obvious approaches, but there were also more subtle techniques involving more detailed knowledge of the workings of the computer software. For example, all numbers entered into program lines were stored in the program part of memory as floating point representations, each requiring five precious bytes, even if they were only intended as integers. However, juggling with BASIC symbols which take up less program space, but which, on running the program, produce the required number, could end up being more economical. Thus, using PI/PI to represent 1 would save two bytes. Further savings could be made by assigning often used numbers to variables, and substituting these in subsequent lines.
In addition to conserving program space, further economies were possible during run time. One rather peculiar example in this regard relates to the ZX81's 'mapping' of the screen memory. In a way which I never fully tried to understand, the moveable area of memory occupied by the display data expands and contracts in some ingenious way as an inbuilt memory saving facility. It does so, though, such that the further towards the right of the screen that characters are displayed, the higher is the memory requirement. So, ensuring that display lines are kept as short as possible, frees more valuable memory for other uses.
Speed, or lack of it, posed its own set of problems. It is interesting to note, by the way, that ZX81 programs ran at two speeds, FAST and SLOW (here printed in upper case, as they are BASIC keywords which can be inserted into programs). SLOW is slow because the same system which interprets the program lines also cleverly refreshes the display, which takes extra time. This is normally of little concern, unless lots of complicated calculations are to be processed. In this case, a switch to FAST mode can speed up the process considerably, but to achieve this the screen display blanks out until a return to SLOW is effected. Going into the faster mode is thus of little use if one wishes to speed up the display, e.g. in a game program. The only solution is to use machine code.
For most amateur programmers writing complete programs in machine code was hardly a viable proposition, however many brave individuals took the trouble to learn enough to write or copy simple routines. In this way, if a program required instances of true speed for graphics or number crunching, it was possible to call short machine code routines at necessary points (this was made possible by means of a BASIC instruction, together with the start address of the routine). It was no easy task to insert the code. A suitable place, usually somewhere in the program storage area, needed to be found. Often this would be in a dummy REM statement which was the first line in the program. However, as the program area moved around in the 'memory map', it was not a straightforward matter to find the starting point of the code, but it was possible by accessing system variables using PEEK and POKE statements.
The first appearance of the ZX81 was round about 1981. In its promotional material, Clive Sinclair (now Sir Clive) made some rather extravagant claims concerning its capabilities, including the assertion that it could run a power station! Considering its specification, and the limitations of tape storage, and, well, just about everything, thank heavens that nobody in charge of any power facilities ever decided to give it a try. But nothing stands still. It wasn't long before amateurs and professionals alike were producing add-ons of every variety, from extra memory (up to 64K), to high resolution graphics devices, to disk drives and sound boards and printers. Some were practicable, others bit the dust, and others were just a little too late, since it didn't take long before better and more powerful machines came onto the market. As far as I am aware, nobody has yet produced an add-on power station.
What seems sure is that the ZX81 was instrumental in bringing computing to the British masses. It was certainly one of Clive Sinclair's most successful products and made him a very rich man (compensating for some of his notorious failed projects). And, it got me thoroughly hooked on computing as a hobby.
I have one complaint in all this, however. The ZX81 has left behind a dubious legacy. I learned such programming abilities as I possess through experimenting with the little black box, its keyless keyboard and its almost non-existent memory. In the days when software either did not exist or was unaffordable to budget users, if you wanted a program you had to write it yourself. In these circumstances I acquired the tricks of memory conservation and economy. Unfortunately, these concerns remained with me through the passage of time, notwithstanding access to improved machines with masses of memory to spare. These ingrained approaches to programming were difficult to eliminate, and I still found myself trying to make routines as multi-functional and reusable as possible. Programming elegance for me consisted in writing a program in as few lines as possible. Forget about readability and clarity. Any little trick to achieve this was a triumph. I think, now, I have pretty much weaned myself off these attitudes. But, just as childhood conditioning is often one of the hardest aspects of behaviour to change, even where we rationally see it as inappropriate, so the acquired habits of the formative early years of my computing development linger in the deep recesses of my psyche.
Dimensions: 167 x 175 x 40 mm.
Integrated circuits: Z80A CPU at 3.25MHz.
1K RAM (expandable to 56K).
8K ROM with Sinclair BASIC.
ULA (Universal Logic Array).
Ports: Bus connector - for peripherals.
UHF modulator output to TV.
9v power supply input.
Keyboard: 40 key pressure sensitive
© Algorithmica Japonica Copyright Notice: Copyright of material rests with the individual author. Articles may be reprinted by other user groups if the author and original publication are credited. Any other reproduction or use of material herein is prohibited without prior written permission from TPC. The mention of names of products without indication of Trademark or Registered Trademark status in no way implies that these products are not so protected by law.
The Newsletter of the Tokyo PC Users Group
Submissions : Editor
Tokyo PC Users Group, Post Office Box 103, Shibuya-Ku, Tokyo 150-8691, JAPAN