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.

Version

The current version is 2.0, around 1987.

References

user-guide.txt [17K]
The complete User's manual written by the users in the editor (in Russian)

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.

Version

The current version is about 1987.

References

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.

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.

Version

The current version is about 1985.

References

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.