This is Paul Kimpel with another guest post on Tom's 205 and 220 blog. Version 1.00 is a relatively minor release, consisting of some important bug fixes, a bit of general tuning and tweaking, and a couple of minor new features. This post will describe those changes.
The source code and supporting materials for version 1.00 of the emulator are available from the project repository. The wiki pages have been updated with the corrections and new features for this release. You can download the source from the repository and run it from your own web server. Alternatively, feel free to run it from our hosting site. Please see the Getting Started wiki page for instructions.
In addition to version 1.00, I am announcing the first release of the recovered Burroughs Algebraic Compiler for the 220, also known as BAC-220 or BALGOL. That is briefly discussed at the end of this post.
New Features
The most visible new feature is on the Control Console. For the few past releases, there have been some mysterious numbers in the lower-left corner of the panel that have never been explained. This was a preliminary display of run-time statistics that are maintained internally by the emulator's Processor module. With this release, I have added a new statistic and reworked the display in an attempt to be more meaningful. That portion of the Console panel now looks like this:
 |
| Control Console Run-time Statistics |
- n.nn=D -- Average Delay Deviation Time (milliseconds). The emulator frequently inserts time delays into its operation, either to throttle performance so it will match that of a real 220, or to model the timing of peripheral device I/Os. Generating accurate delays in a browser environment is difficult, so the emulator has a mechanism that accumulates the difference between requested delays and actual delay times, feeding back the deviations to adjust future delays in an attempt to maintain timing accuracy in the average. The "=D" number is the exponential running average deviation for Processor throttling delays. Numbers less that 4ms are typical; numbers consistently greater than 4ms may indicate that emulated time is falling behind real time. The number may go negative for reasons that are too complex to explain here, but see this this discussion for the retro-205 emulator, which uses a similar delay adjustment mechanism.
- nn.nn%S -- Average Processor Slack. This is the exponential running average percentage of real time the emulated 220 Processor is not using the real processor in your workstation. This is another measure of how well emulated time is staying ahead of real time. Values greater than 70% can be considered to be healthy. Values less than 50% can be problematic, as the browser must do things other than execute the emulator's Javascript code, e.g., render updates to the windows and garbage-collect memory.
- n.nn=R -- Average Processor Slice Run Time (milliseconds). To throttle performance, the emulated Processor runs in spurts. It typically runs for a time slice of about 10ms emulated, then compares the emulated time it has accumulated for individual instructions against the browser's real-world clock and inserts a delay to allow real-world time to catch up with emulated time. The time slice may terminate early, usually because an I/O was initiated. The number is the exponential running average real time that these slices are running. The value will varying depending upon the speed of your workstation's processor and the nature of the 220 program you are running, but I usually see values in the range 0.01 - 0.03ms.
- nnn,nnn=I -- Instruction Counter. This number counts up by one for every 220 instruction that is executed. The count is incremented at the beginning the Execute Phase in the Processor.
Related to the revised timing statistics, the mechanism within the Processor that maintains emulated time has been revised to be more accurate, especially during I/O operations. During an I/O, the Processor is idle except to service memory requests from the I/O devices. Thus emulated time continues to accumulate even though the Processor is not executing instructions.
As part of the revisions to the Processor's timing mechanism, the deviation adjustment algorithm mentioned in #1 above has been redesigned for the umpteenth time. This algorithm is implemented in the emulator's global setCallback() function that centrally manages timing delays. That function is common across the retro-220, retro-205 and retro-b5500 emulators, with each project continuing to contribute to its ongoing refinement.
Corrections
If there is one instruction in the 220 that has given me fits, it is Compare Field A/R (CFA/CFR, op code 18). This instruction compares a partial-word field (or optionally the whole word) in the A or R register against a corresponding field of a word in memory, setting the LOW/EQUAL/HIGH comparison toggles depending on whether the field in the register is less than, equal to, or greater than the field in the memory word, respectively.
Comparing values like this is relatively straightforward at the hardware level -- you effectively subtract the values and look to see if the result is zero (meaning equal), and if not, you look at the sign of the result, with negative indicating a low condition. That is the way it was done on the 220, unless the specified field includes the sign digit. In that case, the 220 used a rather bizarre collation, which if you are interested, you can read about in the Operational Characteristics manual on page 2-15, under Remarks.
The people who wrote the BALGOL compiler were very focused on table storage efficiency, and frequently used the sign digit as a one-digit field. They also really knew how CFA/CFR worked, and used it to advantage. I have encountered at least three cases during debugging of the compiler where my knowledge of how that instruction should work proved deficient, resulting in the compilation going off into Never-Never Land. The most recent incident involved the compiler's Overlay module comparing a word with a sign of 7 to a word with a sign of 0, and the emulator producing the wrong answer. That bug is now fixed, but I won't be surprised if this is not the last of my troubles with that instruction.
Other, more minor problems that have been corrected include:
- When reading data from a Cardatron card reader or magnetic tape, it is possible to have the Processor add the contents of the B register to the low-order four digits of selected words before storing them in memory. This was generally done to relocate operand addresses in instruction words as a program was being loaded. The emulator was isolating the operand address incorrectly before applying the value in the B register to it, corrupting the value of the word. The emulator now performs this B-register modification correctly.
- Tom Sawyer recently sent me some Burroughs correspondence that indicated Processor alarm conditions should be cleared when the Reset/Transfer switch is activated. The emulator was not doing this, and that oversight is now corrected in this release.
- The control panel for teletype printers was not correctly displaying the tab stop positions that had been set for the device. It now displays the tab stops properly.
- The speed for teletype printers operating in "Whippet" mode has been reduced from 5000 characters/second to 1000. The paper-advance delay has been reduced from an average of 200ms per line to 75ms.
- On the Console register displays, you toggle the state of the lamps (and the bits they represent) by clicking on them. On a real 220, you would set bits by pressing the small, white, rectangular button below each lamp. The intent was that the buttons would work this way in the emulator as well, but they were not responding to clicks. This has been fixed, and you can now toggle a lamp by clicking on either the lamp or its white button.
- Paper-tape image files for the emulator are ordinary ASCII text files. They represent each 220 word on the tape as a separate line in the file. For numeric words, the line consists of 11 digits. For alphanumeric words -- indicated by a sign digit of 2 -- the word is represented as five alphanumeric characters after the sign digit. This representation has a problem when the word has trailing space characters and those trailing spaces have been trimmed from the line, perhaps by a text editor. The paper tape reader will now supply trailing spaces as necessary if a line with a sign digit of 2 has less than five characters following the sign.
BALGOL – The Burroughs Algebraic Compiler
Recovery and restoration of the BALGOL compiler for the 220 has been one of the main goals of this project from its inception. BALGOL is a dialect of the preliminary International Algorithmic Language, also known as Algol-58, which was a precursor to the better-known Algol-60. Work on transcription of the compiler source code from listings started in the Fall of 2016, actually before work on the emulator itself.
Getting the compiler to run again has involved transcribing over 10,000 lines of assembly coding, writing two cross-assemblers to translate the transcriptions into 220 object code, ferreting out the contents and organization of the magnetic tape on which the compiler was distributed, and inventing out of whole cloth the several small utility card decks that went along with that tape. It has been a lot of work, but in the end very gratifying.
The compiler first started working at the end of 2017. Since then, I have been preparing example programs, testing the compiler against them, and resolving the inevitable errors that have been uncovered -- some of them taking me weeks of part-time effort to resolve. There have been problems with everything -- the transcriptions, the assemblers, the emulator, and not least, my flawed understanding of correct BALGOL syntax.
I am now pleased to announce the availability of BALGOL for general use. The compiler passes all of my tests, including all of the example programs published in Section 11 of its compiler reference manual. Everything necessary to run the compiler in the retro-220 emulator is available from the project repository. Wiki pages are also available describing how to use the compiler and how to build the compiler from scratch. You are welcome to try it out for yourself. Note that the current version of the compiler requires emulator version 1.00 in order to operate properly.
I am preparing a series of blog posts describing the BALGOL dialect, the effort to recover the compiler and make it run, and an overview of its operation. These will be posted over the next weeks, so stay tuned.
No comments:
Post a Comment