Programming Language Reminiscence



A wordstar-like text editor for Electronics BK-0010 in 1754 bytes

Electronics BK-0010 was a `home' computer manufactured in the USSR from 1985 through 1993. It was a 16-bit microcomputer (an LSI-11 clone) with the PDP-11 instruction set; it had 3MHz clock and 32KB of RAM, half of which was dedicated to video memory. Programs had only 16KB (that is, 16384 bytes) of memory for code and data. The main unit with the integrated keyboard had to be connected to a tape recorder and a TV set, on which it could display 25 lines of 64-character--wide text.

The following article presents a text editor for Electronics BK-0010, written around 1986. The description may sound hopelessly naive. Still, the features of our editor were quite similar to those of the state-of-the art editors K52 and Wordstar. One should keep in mind that these features were implemented in only 1754 bytes of code. With 512 initial bytes used by the firmware and data and 966 bytes of the custom nanoOS, there were 13 KBytes left for the document text. There was enough room for a paper.

The article was originally published in Russian in the Magazine ``Microprocessornye sredstva i sistemy'' (Microprocessor tools and systems), N3, 1989, p. 56. The following is the close translation.

Universal text editor for the "Electronics BK-0010" personal computer

An important application for personal computers is using them as typewriters, for entering, storing and editing of various documents. For doing these tasks on the ``Electronics BK-0010'', in Kazan State University (named after V.I.Ulyanov-Lenin) has been developed a universal text editor. It lets us enter and edit text in full screen: change any character of the displayed page; shift characters on a line to the right to make room for new ones; delete characters; enter, delete and duplicate lines. There were many ways to quickly move the text cursor. One can scroll the text, and display the page with the given line number. If the cursor is at the top of the screen, pressing the UP key scrolls the text down, showing the previous text line if any. Likewise, the text scrolls up when pressing the DOWN key with the cursor on the bottom two screen lines. Any group of text lines (including one line and the whole text) can be marked as a block, and copied to a different place or deleted. It takes only two key presses to mark the current line as the beginning or the end line of the block. The cursor can be quickly positioned on the first or the last line of the marked block. To format text, one can split a text line in two at the cursor, and merge two lines. If the merged line turns out too wide, it is split in such a way that the first line is filled with whole words (not characters!).

The text in memory is a sequence of lines of varying length (up to the maximum of 63 characters); the trailing spaces are not stored. However, the user does not suspect such a tight storage: he may position the cursor at any point of the screen and insert any characters at any place. The user hence has the full impression of editing the fixed-width--line text -- just like a regular printed text. This feature distinguishes our editor from other well-known screen editors (such as K52). The what-you-see-is-what-you-get mode of our editor significantly improves the convenience of using it.

Besides the editing functions, the program lets us store the document on the magnetic tape, load the previously saved text and append it to the one in memory. The appended text can then be moved using the block copy operation. A universal driver supports printing on any printer with the IRPR [Centronics-like] interface. Printing has been tested on TPU, UVVPC-30-004, TC 7180, D100 (of the DVK System). On last two units one can print both in Cyrillic and Latin alphabets in lower and upper cases.

The editor program is written in position-independent code and takes just a bit over 3 kilobytes of main memory. The rest of the RAM of BK-0010 (13 KByte) can be used for the text.

The BK editor is somewhat like Wordstar (which I have never used, and did not know at the time). There was no on-screen menu though: the whole screen was used for text. The BK editor was also reminiscent of the K52 visual editor that DEC distributed with its OS RT-11 -- which I was familiar with and disliked. The most visible distinction of the BK editor was its WYSIWYG mode: if the newline character cannot be seen, it should not be felt. Therefore, the cursor moves vertically in a straight line, without any odd jumps. The editing feels like the `picture mode' of Emacs. Although the screen lines appear padded with spaces to fixed width, the trailing spaces were not stored. Such WYSIWYG mode was a feature of several editors developed in the USSR for bigger computers but it is hardly known in the West.

The first version of the program was entered into a BK in hexadecimal codes using a custom hexadecimal editor (quite like the HEXL mode in modern Emacs). Referenced below is the second version, which added minor improvements and was re-coded in PDP Macro-11. It was then transmitted to a BK via a custom network.

The code uses tables to quickly dispatch to keystroke handlers. The editor also relies on the putback keystroke buffer: quite a few keystrokes are implemented as `macros'. The previously written nanoOS provided common services via `traps'. For example, trap 14 displays and formats a message, trap 11 controls the magnetic tape, and trap 3 printer. Trap 16 saves registers and trap 17 restores them and returns to the caller of the function.

The BK Editor (sometimes called TRED) was used productively for several years and was widely distributed. It was cloned, so to speak, several times.

The current version is 2.0, around 1987
user-guide.txt [17K]
The complete User's manual written by the users, using the editor itself (in Russian)

edwa.mac [2K]
Editor Source Code (PDP-11 Assembly): Global data definitions

edinit.mac [6K]
Global initialization and the handling of the main menu

edroot.mac [5K]
Text editing root module, with the main loop dispatching to keystroke handlers

edsymb.mac [8K]
Handle simple keystrokes (page/line up, etc)

edgold.mac [11K]
Handle prefix commands with a table-driven 1-symbol-stack automaton

edut1.mac [9K]
Utilities: displaying a block of text, locating a line by its number, status reporting, buffer operations, etc.

lined.mac [8K]
Line editor [2K]
Memory map of the complete executable

BK 0010 in the Old Computer Museum


Language for writing text adventure, er, online courses: glimpse into the computer-assisted education of the 1970s and 1980s

Online courses have become familiar. A typical lesson shows a movie clip or several web pages, followed by the `test': a screen with several multiple-choice questions. The correct answers are then tallied and displayed. Computer-assisted education, however, pre-dates internet by several decades. Back then, it was quickly realized that the courses like the one just described are very boring.

An engaging and productive course should be more interactive. Presentation and questions should be interspersed; an answer should be evaluated on the spot. If the answer is not correct, the student should get another chance or a hint. If the correct answer is still not forthcoming, there should follow alternative lessons to explain the subject more slowly. Questions should be variable and varied, preferably with non-deterministic parts. It goes without saying that the answer should be given in a free form, as an arbitrary number or a string -- rather than as a selection from a list. All in all, an engaging course should look quite like an adventure game.

It was also realized early on that writing the script of a good course, like that of a good game, is a skill, different from programming. It is unreasonable to make course authors write in Fortran or Assembly (as computers were programmed those days). They needed good tools -- a high-level language for writing course scripts. (Game industry has realized that, too). One of such early course script languages was TUTOR, developed at the University of Illinois in late 1960s.

In Soviet Union, there was a dialect/reimplementation of TUTOR for mainframes. I have encountered it when studying and then working at the Kazan State University. Taking a computer course on a mainframe was inconvenient, to say the least: mainframes were not easily accessible -- and, in the Soviet Union, they often broke down.

Personal computers, once became available, made for a better, or at least much cheaper, platform for computer tutoring. That was the motivation to write an interpreter for a TUTOR dialect on the personal computer BK-0010. The hardware was quite less capable than the mainframe. Still, my implementation had a few advantages over its mainframe counterpart.

In the original TUTOR and its dialects, presentations were created by positioning the cursor on the screen and then writing text. My implementation supported formatted output, with text and drawing. The text template to display could contain slots to be filled with the current values of numeric or string expressions. Text templates may also include screen control codes, for color, inverse video and other screen effects. There was a special operator for line drawing.

The script language was a programming language, with numeric and string computations, and string conversion, editing and matching. The latter was necessary to evaluate student responses, which were assumed to be free-form. The language offered 26 integer and 8 string variables. It also supported branching, looping and subroutines. As a dialect of TUTOR, it had dedicated operators for accepting an answer and branching on match or mismatch with respect to the given template; advancing to the next lesson, backtracking, or switching to another lesson plan. Lessons may be grouped into sets. Course scripts may be edited with the built-in full-screen editor.

The interpreter was written in PDP-11 assembly (MACRO-11). The interpreter took 3Kbytes of memory, the editor 1.5KBytes and the simple OS, 2KBytes. The rest 9.5KBytes of the main memory of BK-0010 could then be used for the course script and materials. When a course is fully written, the editor can be removed and its memory used for the course.

I realize now that the script language was good enough to write text adventure games (actually, semi-textual: it supported drawing). Alas, neither I nor any of my friends knew of `text adventure' at the time.

I have written a couple of sample courses for illustration, and planned to port a few of the existing TUTOR courses developed at the university. It seems only the interpreter code has survived, shown below.

Just the other day (in September 2018) I took an online course on personal information handling, mandated by the university. The course consisted of a video followed a dozen of multiple-choice questions. It is sad to realize that in 1988 -- on the computer with the clock speed of mere 3MHz and the total memory million times smaller than that on my present computer -- I could have scripted and taken a much more engaging course.

The current version is June 1988
R.A. Avner, Paul Tenczar: The TUTOR Manual. University of Illinois. CERL Report X-4, January 1969

paper.txt [10K]
Interpreter for training courses on the "Electronics BK-0010" personal computer (in Russian)
This paper describing the system was published in the proceedings of the XIII Joint Soviet-French Seminar "Designing the computer assisted systems for the higher school on the base of personal computers", Kazan, Oct. 10-14, 1988, p. 122-125

A wordstar-like text editor for Electronics BK-0010 in 1754 bytes
BK-0010 computer and the editor used for the course scripts

The source code of the interpreter (PDP-11 Macro-assembly), as is


Simple PC text-mode window system in Modula-2

This Modula-2 code is part of a larger project, an emulator of a non-traditional vector FPGA-like CPU architecture. Unlike the familiar FPGA, the processing elements (nodes) are connected in a full binary tree rather than in a regular rectangular mesh. The architecture was designed by Dr. Makarov at Kazan State University in 1987-1988. Besides the emulator, the project implemented higher-level operations like multiplication and division of integral and floating-point numbers.

Given below are general-purpose utilities and the user-interface-related code. As to the emulator proper, I do not feel I have the right to say anything more about it or the target CPU architecture. I am not aware of its further development.

I used the Modula-2 system developed by the `Interface Technologies Corporation'. The system included a smart, syntax-sensitive editor. The editor made sure that at all times the program is syntactically correct -- which sometimes was a hindrance.

The current version is about 1987
modula2.tar.gz [12K]
Archive of the commented source code
The modules Kbd and TIO implement low-level terminal i/o via BIOS and DOS interrupts. TIO also supports character escapes and printf-like formatted output. The module Window lets one write text into rectangular areas on the screen, supporting line wrap-around, scrolling, colors, and cursor positioning. The module used BIOS interrupts and directly accessed the videoRAM. On the top of these modules, MWDr implements a line editor and a menu processor. The utility modules include Lexem (string tokenizer) and Set (finite maps).


Simple text editor in PL/I

This PL/I code was written for simple text editing of source code files on an IBM mainframe (clone) that had no interactive editing devices save the operator console. The only way to edit source code disk files was to punch the changes on cards and submit a batch job to apply the changes, with the help of the system utility IEBUPDTE. Even if a user had access to a machine room, he still had to punch the updates on cards and run that batch job. That was quite inconvenient. This trivial utility was written to help such users fix simple errors in their source code files from the operator console. I had used the utility on many occasions -- until our computing center got display terminals.
The current version is Spring 1982
upd.pli [5K]
The self-contained commented PL/I source code.


RTRAN parsing and finding direct products in Algol-68

This old Algol68 code is a part of a database system for the results of statistical mechanical calculations. The computed data could be later retrieved for further processing. This self-contained code converted retrieval requests into the request language of the underlying hierarchical database, expanding the abbreviations for sequences of data sets.

The code illustrates parsing via a Turing-like machine -- so called Glushkov R-Technology. I implemented what I understood from a quick glance through Glushkov's book a few years earlier.

The current version is about 1985
tpbbldrq-ann.a68 [12K]
The self-contained commented Algol68 source code
The beginning of the file has a long description of the code, in plain text. It is not part of the code and should be removed prior to compiling the code.


File integrity checking on IBM S/360 and PDP-11

The archetype of file integrity checking is tripwire, written by Gene Kim and Eugene Spafford at Purdue University in 1992 for the purpose of detecting modifications to system files, as signs of malicious activity. In the initialization mode, tripwire computes hashes (i.e., checksums) of system files and records them in a special file. In the checking mode, the tool recomputes the file hashes and compares them with the those recorded earlier. The mismatch indicates the file has been tampered with, e.g., infected by a virus.

Back in 1988 I have written the identical tool, called CHECKDS, for an IBM System/360 clone (EC-1033). The purpose was not checking for viruses however. I was alarmed by the corruption of a file on my (29 MB) disk pack. I wanted to detect such corruption early so I could correct the file or restore it from the backup. I would run CHECKDS from time to time, checking checksums of important disk files against the previously computed values.

The program CHECKDS was quite atypical System/360 program: it was opening dynamically-named files: the names of the files (called `data sets' in System/360 parlance) to check were read from another file. Normally, all files needed for a program must be reserved in advance of program execution and hence described on JCL DD-cards. In the batch-oriented System/360, the names of all files opened by a program must be statically known. Opening files whose names are computed was very rare, requiring special knowledge and administrative privilege (so-called ``zero memory key'', to modify operating system tables).

The program CHECKDS had another peculiarity: it processed so-called library files (``partitioned data sets'', in the official terminology) as if they were ordinary (i.e., sequential) data sets, which may contain records of zero length. Such records separate library members. Normally reading a record of zero length raises the end-of-data indicator. To ignore zero-size records when reading a partitioned data set, CHECKDS installs a call-back (formally called ``IO appendix'') to be executed upon the completion of IO channel operations. The call-back will check for the zero-length record and reset the error indicator. Installing IO callbacks too required zero memory key.

About a year later, working on a micro-computer, a clone of PDP-11, I had to check for corruption of disk files again. Soviet-built computers were notably unreliable. The disk controller of that particular computer broke down. A friend of mine, a remarkable electrical engineer, identified the failure in the checksum computation circuit, which he managed to disable. The computer could work again but disk data corruption could no longer be detected. I had to compensate for faulty hardware with software.

The current version is about 1988
checkds.asm [15K]
Commented IBM System/360 Assembler code

verify.c [9K]
The commented C code; DEC RT-11/XM operating system