Enter email address here to subscribe to B5500 blog posts...

Sunday, November 20, 2016

Emulator Release 1.04

Nigel and I are pleased to announce that version 1.04 of the retro-B5500 emulator was released on 4 September 2016. All changes have been posted to the repository for our GitHub project. The hosting site has also been updated with this release, and for those of you running your own web server, a zip file of the release can be downloaded from Google Drive.

This is a minor release containing a number of enhancements and corrections for issues we have discovered since version 1.03 was released a little over a year ago.


Enhancements in Release 1.04


This release of the emulator supports the following enhancements.

New Single-Precision Add/Subtract Implementation


The B5500 uses a unified numeric format, which means that it does not have the typical distinction between integer and floating-point numbers that most computer architectures do. Integers are simply values that have been normalized so that their exponent is zero. For exaple, octal 0000000000000001 (the integer representation of 1) and 1141000000000000 (the normalized floating-point representation of 1.0, i.e., octal 1000000000000 × 8-12) are the same value as far as the B5500 numeric operators are concerned.

There is a document informally referred to as "The Flows," which contains a schematic representation of the logic equations for each operator syllable. Alas, we did not have access to this document when initially developing the emulator, and had to rely on its companion, the Processor Training Manual, which is a good, but not-quite-complete narrative guide to The Flows. As a result, the first implementation of single-precision arithmetic was something of a best-guess effort, and as reported previously in this blog, some of my early numeric benchmarks were producing results that had at best one significant digit of agreement with results from a real B5500.

After much frustrating research, that problem turned out to be improper rounding in single-precision Add and Subtract, which are implemented as the same instruction with some small differences in the treatment of signs. I finally fixed the problem empirically by generating results from 64 "interesting" numeric values and comparing the octal results to those from a modern Unisys MCP system, which uses the same numeric word format. That revealed many cases where rounding was being done improperly -- mostly during scaling of the smaller operand to make exponents equal. Fixing those cases allowed the benchmarks to agree with the results from a real B5500.

By the time I got around to implementing the double-precision arithmetic operators about a year later, The Flows had become available on bitsavers.org, and I followed them closely in implementing the double-precision operators. That gave me the idea that at some point I should go back and redo single-precision Add/Subtract with more rigorous attention to implementing them the way The Flows said they worked.

Earlier this year, I had a lengthly and very interesting exchange of correspondence with Reinhard Meyer in Germany, who was contemplating design of a B5500 emulator of his own and perhaps eventually producing an FPGA implementation of the machine. That exchange finally galvanized me to go back and re-implement single-precision Add/Subtract according to The Flows.

Rigorously following The Flows turned out to be considerably more of a challenge than I had originally anticipated. Digital logic tends to work in parallel, with many states changing at each clock pulse. Most of that translates fairly easily to the sequentially-executed code of a traditional programming language, but some of it does not, and you continuously need to be on guard that states set during one clock cycle do not become effective until the start of the next one.

The most frustrating problem that arose during this effort was one where subtracting two numbers of equal value generated a result that was not completely zero. The mantissa would be zero, but the sign or exponent would not. There is explicit logic in The Flows to test for this condition in the J05L block under the secondary control of Q04F/ (see index 1.01.1 page 2 of 2 in the document) and exit the operator early if the sign or exponent do not need to be cleared to zero. That test is based on the logic term W03L, which is defined as "A[39->37] = B[39->37]", meaning the high-order octade of the A-register mantissa (bits 39 through 37) equals the high-order octade of the B-register mantissa. The corresponding narrative in the Processor Training Manual (page 3.17-11) states, "If the 13th octade of the A and B registers do not equal each other (W03L/) it is not possible for the resultant sum of the complement addition to equal all zeros and the operator is terminated."

I implemented the code exactly that way. It didn't work. After staring at that portion of the logic for days, it finally occurred to me that neither the definition of W03L nor the statement in the Training Manual made sense -- it's entirely possible for the two high-order octades to be unequal and still sum to zero -- 7+1 (ignoring the carry), for example. That made me begin to wonder whether "equal" and "not equal" meant what I thought they did. To answer that question, I had to look at the document upon which The Flows are based, the Processor Equation Book, where on page 422.00, I found the term W03L/ to be defined as:

A39F*B39F + A39F/*B39F/ + A38F*B38F + A38F/*B38F/ + A37F*B37F + A37F/*B37F/

This is somewhat simplified from the notation in the Equation Book, which appears to refer to physical circuit elements. For the uninitiated, "*" means logical-AND, "+" means logical-OR, and "/" used as a suffix means logical-NOT. Operator precedence is NOT-AND-OR, highest to lowest. The numbers refer to bits in the registers, with 48 being high-order and 01 being low-order. A suffix of "F" means flip-flop.

That equation clearly does not determine inequality of the high-order A and B octades -- it determines the logical equivalence of the three pairs of bits in the octades and ORs those equivalences together. Logical equivalence is the complement of exclusive-OR. In other words, W03L/ is true if any of the three pairs of bits match. Equivalently, W03L is true if none of the three pairs of bits match. After making that change in the code, results with zero mantissas finally generated words of all zeroes.

After all the hard work to re-implement single-precision Add/Subtract from The Flows, it produced very little improvement over the results of the previous, empirically-corrected implementation. There were a few differences in the way that results are normalized, and a rounding difference if one of the values is octal 0161000000000000 and the other value is one of 0004444444444444, 0005555555555555, 0006666666666666, or 0007777777777777. On that basis, the effort invested in the new implementation was not worth the very slight improvement in results. On the other hand, it was a very interesting experience, and I learned a lot about digital logic and how the B5500 worked at the electronic level.

There is one other significant difference -- the new implementation runs noticeably slower, in terms of emulated clock time, than the prior one. For one heavily numeric benchmark that runs about ten minutes, the new implementation increases the emulated run time by 48 seconds -- a little over 8%.

Card Reader Enhancement


The implementation of the B129 card reader in the emulator allows you to load one or more text files into the reader as if they are card decks. Each line in a text file is treated as an 80-column card image. Thus, in order to read cards, you first must have a text file on your local system to hold the necessary card images.

This has proven to be a little inconvenient. If you have a file of source code you wish to compile, for example, you either need to modify that file and add the necessary B5500 control cards, or create a copy of the file and add the control cards to that.

Starting with this release, the user interface for the card reader now supports the ability to enter card images directly into the reader from your keyboard without creating a text file first. Card images entered this way can be interspersed with card images from text files. This allows you, among other things, to "wrap" existing files with control cards, compiler $-option cards, or anything else you need but don't have (or don't want) in a text file on disk.


The card reader's panel has a new button in the upper right-hand corner labeled KEY IN DECK. This button is disabled unless the reader is in a not-ready state. Clicking the button opens a sub-window that allows you to enter card images directly into the reader's buffer:


While the key-in window is open, the reader's START button is disabled.

The bulk of this window is occupied by a standard text area. You can enter text into this area from your keyboard or copy/paste text from another source. You can edit the text using the normal controls of your operating system. Clicking the Insert button at the bottom of the window appends the contents of the text area to the card reader's buffer and closes the window. Clicking the Cancel button simply closes the window without affecting the reader's buffer. Once text is inserted into the buffer, it cannot be modified or deleted, just as with inserting a text file into the buffer.

There are three white buttons along the bottom of the window with commonly-used control card images. Clicking one of these simply inserts the respective card image into the text area at the current cursor position. From there it can be appended to the reader's buffer by clicking the Insert button.

Miscellaneous Improvements


1. The size of the terminal adapter buffer in B5500DatacomUnit has been reduced from 112 to 56 characters to accommodate the requirements of the R/C interactive editor. Users of the Timesharing MCP (TSMCP) and CANDE will need to update their SYSTEM/DISK file with the new buffer size, e.g.,
?RUN SYSDISK/MAKER
?FILE LINE = LINE BACKUP DISK
?DATA CARD
LINE,0,0,56,0,0,7,0,
LINE,1,0,56,0,0,0,0,
STA,0,0,0,0,"0","0",0,0,
?END
2. We have discovered that the emulator now works with Apple Macintosh OS X using Safari versions 8 and above. Nothing has changed in the emulator to support this -- the issue was waiting for Safari to implement the IndexedDB API used by the emulated disk subsystem.

We continue to be unable to get the emulator to run in either Microsoft Windows Explorer or Edge. If anyone has tried the emulator in Opera or any other GUI browser, please let us know how that works. 

3. Despite a statement in the project wiki that the emulator must be loaded over HTTP from a web server, it appears to run just fine when loaded directly from your local file system, e.g., using a URL like this:
file:///C:/Projects/B5500/WIP-S1/webUI/B5500Console.html
The wiki has been corrected.

4. The alternate B5500SyllableDebugger user interface for the emulator has been enhanced with an Execute Single button. This executes the instruction currently in the T register, but differs from the Step button in that it does not advance the C and L instruction counter registers. This makes Execute Single a better choice than Step for testing and debugging a specific operator.

5. The default height of the SPO and line printer windows has been reduced to about a third of the screen height.

6. The tools/B5500DeleteStorageDB.html script can be used to remove the IndexedDB database for an emulated disk subsystem. Previously, this script could only remove the default data base, named B5500DiskUnit. The script now takes a "?db=" query string parameter with the name of the data base to remove.

7. The Algol Glyphs option for the card punch (CPA) has been set to false by default. Some text editors were corrupting the Unicode characters produced in Cold- and Cool-start decks when this option was set to true, making the decks useless for loading under CARD LOAD SELECT.

8. The exponential moving average computations for Delay Delta and Processor Slack in the Processor object have been adjusted slightly.

Corrections


1. Rounding in Integer Store operators has been corrected to produce a word of all zeroes if the mantissa is zero. Previously, non-zero sign and exponent fields could have been present when mantissa was scaled to zero.

2. BCL translation for alpha-mode (even parity) tape files has been corrected. Previously, the translation was being done twice -- once by the I/O Control Unit and once again by the tape drive. It is now handled entirely within the tape drive.

3. Both EOF and parity error are now reported by the tape units for any attempt to read beyond the end of a tape image.

4. The way that "green-bar" formatting was being done on the line printer was causing a blank line to be inserted every third line when copying text directly from the "paper" area of the printer's window. A different method is now used that does not result in extraneous lines in the copied text.

5. When the emulator was powered on, the browser windows for the individual peripheral devices were being created twice. This behavior was intentional, but dated from very early in the emulator's development when crashes and aborts were a frequent occurrence. The act of opening a window, closing it, and then reopening it served to close any windows left open by a crashed emulator instance. We are long past the need for that now, so the screwy open/close behavior has been removed. As part of this effort, de-registration of event handlers for the various windows has been implemented.

6. After almost five years, we are still finding errors in the transcription of the Mark XVI Algol compiler listing. Most of the errors that have come to light in the past few years have been in comments, but a few months ago we found a serious error in line 06073850 -- a plus sign had been transcribed as a minus. I doubt we are ever going to get all of the errors out of this transcription -- or of any other large transcription like this.


The B5500 Source Code Archive


We are starting to amass a significant amount of source code for the B5500. Most of this has been recovered by transcribing it from listings. Up to this point, we have been including the transcriptions we've done or received from others in the emulator project's repository. Rich Cornwell in North Carolina (US) and Jim Fehlinger in New Jersey (US) have been especially prolific in turning scanned listings into text files.

There are now multiple B5500 emulators, however, either in existence or under development. In addition to Sid McHarg's C++ emulator and this project, Rich Cornwell completed an emulator earlier this year that runs in the SimH framework, and Mark Lloyd in the UK continues to work on his Lazarus/Pascal version.

With multiple emulator projects and multiple sources of recovered source code, it has becoming less and less appropriate for that code to be embedded in a specific project. I have been thinking about this for a while, and a few months ago decided to set up a separate project on GitHub to serve as a common repository for all B5500 emulators:
https://github.com/retro-software/B5500-software
Rather than set this up under someone's personal account, I've created a GitHub "organization" to be the owner. This will make it easier to share and ultimately transfer responsibility for the archive, and also to create additional repositories in the future to maintain recovered source code for other systems. Initially, Nigel and I are the administrators of this organization and the B5500 archive, but hopefully that can be expanded in the future.

To seed this new repository, I have exported the source code transcriptions, and their history, from the retro-b5500 project and made that the initial contribution to the B5500-software project. In the process, I rearranged the directory structure into something that hopefully will be more maintainable over time. The source code in the retro-b5500 project will probably be deleted at some point down the road.

In a future blog post, I will propose some standards and procedures for maintaining the archive, but will be happy to receive comments and recommendations on this from others. I will also be happy to receive new contributions and will consider pull requests for updates. Each transcription should be accompanied by some text that describes it provenance and who did the transcription. See the README.txt files in the repository for examples of what I'd like to have in this regard.

I would like for all of the transcriptions to be faithful to their original sources, so please include sequence numbers if they are present in the original, and please do not correct spelling in comments, or even bugs in the code. Any original errors can be corrected in separate projects or branches from the transcriptions of the originals.

Monday, August 24, 2015

Emulator Release 1.03 and Browser Disk Space Usage

Nigel and I are pleased to announce that version 1.03 of the retro-B5500 emulator was released on 22 August 2015. All changes have been posted to the repository for our GitHub project. The hosting site has also been updated with this release, and for those of you running your own web server, a zip file of the release can be downloaded from Google Drive.

This is a minor release containing corrections for a few issues we have discovered since version 1.02 was released in June. The most significant correction addresses excessive disk storage usage for emulated B5500 disk units.


Excessive Browser Disk Usage Fixed


The emulator uses an HTML5 API known as IndexedDB to provide persistent storage for B5500 disk devices. IndexedDB is a non-relational (NoSQL) database mechanism. It stores Javascript objects, indexed either by an external key value, or by possibly multiple data items internal to the object being stored. Instead of tables, IndexedDB has "object stores," which serve much the same purpose.

The emulator creates a small IndexedDB database named "retro-B5500-Config" to store system configuration data. It creates one additional IndexedDB database for each emulated disk system created by the configuration interface. Each of these subsystem databases contains a "CONFIG" store for its internal configuration, plus an "EUn" store for each disk Electronics Unit in the subsystem. Within an EU store, each disk sector is represented as an object, indexed by its zero-relative sector number. An SU is modeled simply as the range of sector numbers it represents.

The Problem


One of the puzzling (and quite disappointing) things several of us have noticed about the emulator is the very large amount of physical disk space it uses to store B5500 disk sector data. The amount of physical disk space required for the IndexedDB database is typically at least 30 times the size of the data being stored.

Each browser manages IndexedDB data internally in its own proprietary way, and nether of the two browsers that are known to support the emulator, Mozilla Firefox and Google Chrome, make it easy to see from the outside what's there or how it's stored. Firefox implements IndexedDB on top of SQLite. It is easy to see the EU structures in the SQLite database, but the objects themselves are very opaque, probably because they are compressed. Chrome implements IndexedDB using LevelDB, an open-source database manager developed by Google and based on its BigTable technology. Its internal structures are opaque from the outside, also due to compression.

In the past few months, several of us who have larger disk subsystems have been having increasing problems with Firefox accessing those subsystems. The first symptoms were that B5500 operations would simply grind to a halt in the middle of running ordinary work. The MCP was still active, but one of the Disk File Control Units (DFCU, i.e., DKA or DKB) would be hung, along with one of the I/O Units. A halt/load would bring the system back up, but often the system would lock up again fairly quickly. If you had multiple disk subsystems, deleting one of them would usually bring the system back to normal operation. This behavior was seen only with Firefox, not with Chrome.

After a couple of weekends of very frustrating investigation, I finally discovered that (a) Firefox was aborting a disk I/O due to a "Quota Exceeded" error, and (b) aborts are not reported to the IndexedDB onerror event, but rather to its onabort event, and the emulator was not catching the onabort event. The aborted I/O resulted in that I/O never being reported as complete, so the IO Unit stayed busy, and the MCP considered the I/O to still be in progress. Additional I/Os for that DCHA or EU queued up behind the aborted I/O, and eventually everything in the system went idle waiting for I/Os to complete. Not detecting the onabort event in the disk driver was a design error on my part.

The quota error reports that the emulator's "source" (web site) is using more local disk storage than it is allowed. I have not been able to find out exactly what that storage limit is in Firefox, plus, either the limit or the way it is enforced has been changing over the last few Firefox releases. Based on what a few of us have observed, the limit appears to be somewhere in the range of 500MB to 1GB of disk usage. With a 30X inflation factor, that relates to 30-60MB of B5500 data, which means that just loading the SYSTEM, SYMBOL1, and SYMBOL2 tape images would put you in range of the limit.

Knowing we were hitting a quota error and approximately where that error is triggered was useful, but it did not help in knowing what to do about it. My working assumption was that the method we were using to represent sector data was responsible for the 30X inflation factor, and was starting to think about different representations in order to reduce that factor.

The situation came to a head about two weeks ago when Firefox 40.0 was released. It refused to open most of my disk subsystems. I couldn't even halt/load the MCP in order to dump the files to tape. Fortunately, I had held off upgrading to FF 40 on my main development system until I found out about this problem, so was able to dump its disk subsystem while still on FF 39.

At this point something obviously had to be done about the way the emulator was storing disk sectors, so last weekend I started to build a testbed to evaluate different ways of representing sector data. As reported in more detail in this post on the forum, I used the old B5500ColdLoader script as a basis for my testbed, and decided to start by creating a disk subsystem using the current sector representation to obtain a baseline disk space usage.

To generate that baseline, I simply loaded the entire SYSTEM tape image, which is 12.4MB in size. When I checked the size of the resulting IndexedDB database to determine its inflation factor, I found -- surprise, surprise -- it wasn't inflated at all! In fact, it was only 10MB -- 80% the size of the raw data.

That result made me start looking very carefully at the way the ColdLoader and the emulator's disk driver stored data to IndexedDB. I had thought they were the same, but found there was one of those differences that you wouldn't believe could cause a problem until the evidence pushes the realization in your face.

The short story is that each IO Unit has an internal 16KB buffer it uses to convert between the 6-bit character codes in B5500 memory and the 8-bit ASCII codes used by the device drivers. The buffer is an HTML5 Uint8Array, which is a form of TypedArray object. The IO Unit passes this buffer during calls to the drivers, along with a length that indicates how much of the buffer is valid.

Since each disk sector is modeled as a separate object in IndexedDB, each sector must be stored to IndexedDB separately. Therefore, the disk driver must extract each sector of a multi-sector write from the IO Unit buffer and store it with a separate IndexedDB put() call. It implemented that extract using the subarray() method of Uint8Array:
eu.put(buffer.subarray(bx, bx+240), segAddr);
Alas, the resulting object that gets passed to put() is not a 240-byte Uint8Array, but rather an object that consists of the underlying array plus the starting and ending index values, as if it were something like this:
{data: buffer, start: bx, end: bx+240}
Thus, what got stored in the EU object store for that sector was not 240 bytes as I had assumed, but a copy of the entire 16KB IO Unit buffer, plus the two index values. No wonder we were seeing at least a 30X inflation factor in the data stored.

Firefox obviously does some compression on this object, but the degree of compression depends largely on what is in the IO Unit buffer. That buffer initially contains all zero bytes, and is simply overwritten by the data for each I/O. Thus, while the end of the buffer could be expected still to contain zeroes, the extent to which the front of the buffer had been overwritten by non-zero data, and therefore how much it could be compressed, would depend on the length of previous I/Os.

While storing these inflated sector objects had thus far only caused a problem in Firefox, they had the same effect in Chrome, and the sizes of Chrome's LevelDB databases were comparable to that of Firefox's SQLite databases. Chrome computes its quota threshold differently, however, based on the workstation's total available disk space. Apparently no one running the emulator has yet hit the Chrome quota limit.

The Solution


The solution to this problem is quite simple -- stop dragging that 16KB buffer around and storing it as part of every sector object. I did that by declaring a 240-byte Uint8Array object local to the disk driver, extracting sector data from the IO Unit buffer into that local object, and doing the IndexedDB put() on that local object, thus:
var sectorBuf = new Uint8Array(240);

...
while (segAddr <= endAddr) {
    for (x=0; x<240; ++x) {
        sectorBuf[x] = buffer[bx++];
    }
    eu.put(sectorBuf, segAddr);
    ++segAddr;
}
where bx is the current offset into the IO Unit buffer, segAddr is the current disk sector address, endAddr is the ending sector address for the I/O, and x is just a local index variable.

This approach introduces a little extra overhead to copy the bytes of each sector from the IO Unit buffer to the local buffer, but that overhead should be more than offset by the elimination of the 16KB IO Unit buffer in the stored object, the need to compress that buffer, and the extra I/O overhead to read and write an inflated sector object.

The nice thing about this solution is that it can be used with existing disk subsystems. Sector objects already present in the subsystem will be big and fat, but will still work. When a sector is written, it will stored in the new, more space-efficient format. Rewriting a sector will release some space to the underlying database's available pool, but it will not reduce the total amount of disk space used by the subsystem database. To do that, some sort of compaction process needs to take place, such as the vacuum command for SQLite. LevelDB will apparently compact its databases gradually over time automatically.

Experience to date with this solution indicates that my initial testbed experience is holding up. By completely dumping a disk subsystem to tape images, deleting and recreating it (to get an empty subsystem database), and reloading the dump, I am seeing reductions in disk space usage of 30-60X. In Firefox, the physical size of the reloaded databases continues to be about 80% of the size of the tape images used to load the databases. To cite one concrete example, the disk subsystem I use for most of my emulator development and testing went from 1.9GB down to 48MB, a reduction of almost 40X.  The dump tapes used to reload the subsystem totaled 58.7MB.

Even though this solution was easy to implement, works with existing disk subsystems, and adequately resolves the problems we have been having with recent versions of Firefox, I have not entirely given up on the idea of a new representation for sector data. There is a lot of overhead in the IO Unit involved in translating between 6- and 8-bit characters, packing and unpacking words, etc., and it may be that another approach will yield both better space and better processing efficiency.

Implementation


Since the fix for IndexedDB disk space usage in 1.03 is compatible with existing disk subsystems, there is nothing you need to do in preparation for moving to this release. If you are already having trouble with Firefox quotas, or have large disk subsystems and want to avoid having problems in the future, then you should consider dumping and reloading your disk subsystems. This section describes how to do that.

If you have already upgraded to Firefox 40 and cannot access your disk subsystems at all, then dumping the data is going to be problematic. See the next section for some ideas on things you can try and some background on where IndexedDB data is stored.

Assuming you can halt/load from your disk subsystem, however, then here are the steps to shrink the amount of disk space that subsystem is using.
  1. Dump the B5500 disk data: 
    1. Mount a blank tape in one of your tape drives. Make sure it is write-enabled (it will be by default) and the drive is in REMOTE status. 
    2. On the SPO, enter the following command: "?DUMP TO MYDUMP =/=; END". You may substitute any other tape name for MYDUMP, up to seven characters long.
    3. After the drive rewinds, click LOCAL and UNLOAD on the drive, then indicate you want to save the tape image.
    4. You can either save the page directly in Firefox (make sure you save it as type Text, not HTML), or copy/paste the text of the image to a text editor and save it from there. Make sure your editor is set not to trim trailing spaces from lines in the file or to replace spaces with tabs.
    5. If Library/Maintenance is not finished, mount another blank tape and repeat steps 3 and 4 above as necessary.
  2. Start the emulator, but do not power it on.
  3. Delete and recreate the disk subsystem:
    1. Enter the System Configuration tool by clicking the B5500 logo on the Operator Console panel.
    2. Select the appropriate system configuration, then click the EDIT button next to the Storage name for that configuration.
    3. In the Disk Storage Configuration window that opens, click the yellow DELETE button. Click through the "are you sure you want to do this" prompts. The Disk Storage Configuration window should close.
    4. Back on the System Configuration window, click the NEW button next to the Storage name field. The name of the subsystem just deleted will probably still display in the pull-down list. Enter the name of the disk subsystem you just deleted in the pop-up dialog that displays.
    5. Configure the new disk subsystem as desired in the resulting Disk Storage Configuration window. Click SAVE on that window when finished, then click SAVE on the System Configuration window.
  4. Cold-start the new disk subsystem. See the instructions for doing this in the Getting Started wiki page. You can either use the standard SYSTEM tape image to do this, or the first tape of the dump you just created. In that latter case, you will need to modify the cold-start deck to use the tape name of the dump.
  5. Once the system has halt/loaded, enter on the SPO, "?LOAD FROM MYDUMP =/=; END". Library/Maintenance will refuse to overwrite a few system files, such as the running MCP. Do not forget to CI the Intrinsics file once it has been reloaded.
This may read like a lot of work, but it usually goes quickly. You should repeat this process for each of your disk subsystems.

Recovering from Quota Exceeded Problems


If Firefox considers your disk storage already to have exceeded the quota limit, then you may not be able to run the emulator in order to dump the data. There are a couple of things you can try, however.
  • If you have multiple disk subsystems, try moving all but one of them out of the folder where Firefox maintains IndexedDB databases. That may reduce the disk space usage below the quota threshold, and allow you to halt/load from the remaining disk subsystem and dump it to tape. You may then be able to swap in the remaining disk subsystems one at a time and dump them as well.
  • If some disk subsystems are too large for the first suggestion to work, you can try downgrading temporarily to an earlier version of Firefox, and see if you can halt/load and dump the subsystem using that version. You can download older Firefox releases from https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/.
On Windows 7, Firefox stores its IndexedDB data in the following location:
\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile ID>\storage\default\<source>\idb\
where <user> is your Windows user name, <profile ID> is the profile name Firefox assigns (e.g., 0qus6gtz.default), and source is the host name of the web site from which you have loaded the emulator, e.g.,
http+++localhost
http+++www.phkimpel.us
Within the idb\ folder, each IndexedDB database is represented by a directory and an SQLite file. The names of these files are derived from the disk subsystem name as follows:

  • The first part of the name is a 10-digit number, probably derived from a numeric hash of the name.
  • The second part of the name is the disk subsystem name, but with the letters rearranged. This part consists of the characters from the first half of the name, with the remaining characters inserted between them in reverse order. For example, B5500DiskUnit is converted to 1182897429Bt5i5n0U0kDsi.
  • The directory name has the extension ".files" and the SQLite file has the extension ".sqlite".
If the database is presently open and being updated, there may be additional SQLite files with the same name but different extensions. 

I have found that you can move the file and directory for a database into and out of the idb\ folder, and Firefox will adapt to that, but it is best to do this when Firefox is completely shut down.

For Ubuntu Linux, the IndexedDB data is stored in this path under your home directory. Most Linux distributions will probably be similar:
~/.mozilla/firefox/<profile ID>/storage/default/<source>/idb/
For Apple Macintosh OS X, the IndexedDB data is stored in this path under your home directory:
~/Library/Application Support/Firefox/Profiles/<profile ID>/storage/default/<source>/idb/
Prior to Firefox 38, IndexedDB data was stored in the .../storage/persistent/ folder instead of .../storage/default/ for all host systems, and the directory for the database did not have the ".files" extension.


Other Corrections in Release 1.03


In addition to the disk space usage fix described above, this release has the following:

  1. Added onabort traps in B5500DiskUnit to catch QuotaExceeded errors. These are reported to the MCP as unit not-ready conditions, which will cause an error message to be printed on the SPO.
  2. Modified the delay-deviation adjustment mechanism in B5500SetCallback to avoid oscillating between positive and negative cumulative deviations. This should improve the responsiveness of the emulator's internal timing and multi-threading.
  3. Corrected tape reel angular motion in B5500MagTapeDrive, especially during reverse tape movement.
  4. Fixed a bug with reporting memory parity error during tape I/O (should that error ever occur, which at present it won't, as the emulator does not generate memory parity errors).
  5. Reset the Algol Glyphs option for card punch CPA in the default system configuration template. Newly-created configurations will no longer have this option set by default.
  6. Fixed tools/B5500LibMaintDecoder to examine an entire .bcd tape image file instead of just the first 64KB.
  7. Added USE SAVEPBT to the default cold-start options in tools/COLDSTART-XIII.card. This will cause printer-backup tapes to be marked as saved when they are released and not printed automatically.
  8. Eliminated the extraneous "schema update successful" alert when altering a disk subsystem configuration. This means there is one less dialog box you must click through when changing that configuration.
  9. Commited minor corrections supplied by Richard Fehlinger to source/B65ESPOL/SOURCE.alg_m.

Monday, June 22, 2015

Emulator Release 1.02 and the Move to GitHub

Nigel and I are pleased to announce that version 1.02 of the retro-B5500 emulator was released on 21 June 2015. All changes have been posted to the repository for our GitHub project. The hosting site has also been updated with this release, and for those of you running your own web server, a zip file of the release can be downloaded from Google Drive.

This is a minor release containing corrections for several issues we have discovered since version 1.01 was released. In addition, this release contains the documentation and web site changes made necessary by the move to GitHub.


Project Now Hosted on GitHub


As some may already know, Google announced in early 2015 that it would be discontinuing its Google Code project hosting service. All projects will become read-only in August, and the service will be shut down completely in early 2016.

Google Code served us extremely well, but obviously we had to find a new home for the project. After looking at a few alternatives, Nigel and I settled on GitHub, easily the largest and most popular code project hosting service available today. Public projects like this one can be hosted for free, which was an important consideration for us. Plus, the site does not pester visitors with advertisements. Google provided a service to migrate Google Code projects to GitHub, and we took advantage of that to move the emulator's repository, issues, and wiki pages to their new home.

The new URL for the project site is https://github.com/pkimpel/retro-b5500/.

The former Google Code site for the project now redirects to the GitHub URL above. All further emulator development will be posted to the new GitHub site.

Note that this move affects only the open-source project site. This blog, the hosting site, and the forum are unaffected and remain at their former URLs. References to the project site in previous blogs will be updated to refer to the new site.

One big change in this move concerns the repository. On Google Code, we used Subversion to maintain an archive of the code base. On GitHub, the only option is Git, the distributed version control system developed by Linus Torvalds for the Linux kernel project. I liked Subversion a lot, and there are things about Git that I don't care for, but it is certainly adequate for our purposes.

Interestingly, GitHub provides a Subversion interface to its Git repositories, so it is possible to use Subversion client tools (such as the standard svn command-line client and TortoiseSVN, the Windows Explorer plug-in) to check out GitHub repositories and make commits to them. I'm continuing to use Tortoise with GitHub, but the branching and merging model of Git is significantly different from that of Subversion, so eventually I may have to abandon Subversion and become a git head myself. I have tried a few Git GUI clients, and thus far the one I like the best is Atlassian's SourceTree, which is free, but requires you to register with Atlassian first.

For those of you interested in obtaining a copy of the source code, viewing the commit history, or forking the emulator, GitHub offers some improved capabilities over Subversion:

  • You can download a zip file of the latest version of the source code by clicking the Download ZIP button on the project's home page at the GitHub link above.
  • You can clone the project using a Git command similar to the following:
    git clone https://github.com/pkimpel/retro-b5500 retro-b5500
  • You can use a Subversion client to check out a copy of the code as well, e.g.,
    svn checkout https://github.com/pkimpel/retro-b5500/trunk retro-b5500
  • As a distributed version control system, Git has some powerful forking and merging features that allow you to create a separate copy of the repository, make commits to it, and then pass the result of those commits to other distributed copies of the repository. We have no plans at present to open up the emulator to other committers, but the forking capabilities of Git may be the solution we have been seeking for the community to store and maintain a library of B5500 source code and other software we are gradually recovering. Whether that library should be a part of this project or a separate one is an open question, and one on which we would appreciate hearing feedback, preferably in the forum.
You will notice that the wiki pages have a considerably different look on GitHub than they did on Google Code. The markup notation used to compose the pages, known as "markdown," is also different from the one used by Google Code. The text and images are all there, though, and the links on the hosting site have been updated to point into the new wiki on GitHub.

The GitHub project has an issue tracker, similar to the one we used in Google Code. You are welcome to post issues (suspected bugs, new feature requests, documentation errors, etc.) to the project, but in order to do so you must have a GitHub account. Anonymous issue submission is not supported. Registration for an account is free, and can be initiated from the GitHub home page. You do not need any special permissions -- any GitHub account can submit issues to this project.

Please do not submit items of general discussion or questions on installation, configuration, or use of the emulator as issues. Those should be posted on the forum instead.


Changes in Release 1.02


This release incorporates the following fixes and enhancements over 1.01:

1. Memory Dump Tape Image


Since version 0.18 the emulator has supported a built-in dump of processor state and memory. You obtain this dump by clicking the red MEMORY CHECK lamp on the console panel. The emulator opens a temporary window and formats the processor and memory state into the window as plain text. You can view this data in the window or copy/save it for later analysis. The dump is just a snapshot and does not affect operation of the system. It can be generated at any time, and as often as you wish, even while the MCP is running.

This is a nice capability, but the resulting memory dump is just raw octal, and it is not easy to analyze. The B5500 MCP had a memory dump mechanism that was invoked using the DP MT SPO command, which would pause normal operations, copy the contents of memory to a magnetic tape and resume normal operations. You could then run the DUMP/ANALYZE program to read the tape and produce a formatted dump with a lot of the MCP information broken out in a much more readable manner.

In order for this dump mechanism to work, of course, the MCP must be up and running. To support a similar dump mechanism independently of the MCP, the emulator now supports an in-built tape dump. If you click the white NOT READY lamp on the console panel, the emulator will open a temporary window and format the contents of memory into this window, much as it does when clicking the MEMORY CHECK lamp. The difference is that the data is output as a tape image in the format used by the DUMP/ANALYZE program. Simply copy/save this tape image to a file on your local system, the same way you would for a tape image that is created when you unload a tape drive, and run the analyzer program against that tape, For example, from the SPO:

    ?RUN DUMP/ANALYZE; FILE MDUMP=MEMORY/DUMP001; END

Note that DUMP/ANALYZE is for the Datacom MCP. If running under the Timesharing MCP, you must use TSDUMP/ANALYZE. Also, it appears that the dump analysis utilities may have been quite new in Mark XIII, because there are complete source file replacements for both of them on the Mark XIII SYSTEM tape under PATCH/DUMPANL and PATCH/TSDUMP. You may wish to compile and use those newer versions instead of the compiled versions on the SYSTEM tape.

2. Capturing Printer and Punch Output


The emulator's implementation of the B5500 line printer works under the idea that to save the printed output, you would save the line printer text area or copy/paste its contents into another program for saving. In early releases this worked quite well, but starting with 1.00, the line printer implemented optional "green-bar" shading of the output. That shading works by grouping every three lines into a <pre> element and applying the shading to every other element. Disabling the shading simply removes the green color style from the elements -- the grouping into <pre> elements occurs regardless.

Alas, when copying or saving the contents of the printer's text area, some browsers (particularly Firefox) insert a blank line between each of the <pre> elements when rendering them as plain text. This makes the saved or copied text appear as if every third line is double-spaced.

To eliminate this problem, the line printer now supports a new way of capturing the contents of its text area, copied from the approach used with the SPO and datacom terminal. If you double-click anywhere in the printed text, the emulator will open a temporary window, render the entire contents of the text area into that window as plain text (without the extra blank lines), and clear the entire contents of the text area. You can then copy/save the contents of that temporary window as you would any other. When you are finished with the temporary window, simply close it. One advantage of this new mechanism is that you can do it at any time, even while the printer is in a ready state and printing.

The old method of clearing the print area by making the printer not ready and triple-clicking the FORM FEED button still works. There was a bug in the implementation of this method that was introduced in release 1.00, however. It has been fixed in this release.

This mechanism of double-clicking in the output text and opening a temporary window to receive the contents of the text area has also been implemented for both stackers on the card punch.

3. SPO Double-Click Problem


Double-clicking the INPUT REQUEST button on the SPO appeared to enable the SPO for input, but no characters were accepted from the keyboard. The problem could be resolved by clicking END OF MESSAGE and starting over.

What was actually happening was that the first click sent the keyboard-request interrupt to the system and the MCP responded by issuing a read to the SPO device. That usually happened fast enough that by the time the second click registered on the button, the read had already been issued and the input text box in the SPO paper area had been enabled and given the focus. The second click simply moved the focus to the INPUT REQUEST button, which of course ignored any keystrokes sent to it. The problem could also be resolved by clicking in the input box to give it back the focus.

The SPO driver now detects when the INPUT REQUEST button is clicked while the SPO is in the middle of a read operation. In such an event it returns the focus to the input box.

Also, the ability of the SPO to wrap output messages longer than 72 characters to a new line was lost in release 1.00. That ability has been reinstated in this release.

4. Miscellaneous Changes

  1. The disk driver will now report a not-ready error if a read or write transaction is aborted by the IndexedDB API in the browser. See the next section on disk quota problems in Firefox for more information.
  2. The disk driver now reports in the result descriptor for a Read Interrogate operation whether the addressed EU has Model IB (also known as "bulk" or "slow") Storage Units attached to it.
  3. The handling of Ctrl-B (break), Ctrl-D (disconnect request), Ctrl-E (WRU), Ctrl-L (clear input buffer), and Ctrl-Q (alternate end-of-message) keystrokes by the datacom terminal was not working. These keystrokes now generate the appropriate status indicators sent to the I/O Units.
  4. Sensing of the Beginning-of-Tape (BOT) marker for a magnetic tape by a Write Interrogate operation was being reported in the result descriptor in a way the MCP did not like. This was causing problems in purging blank tapes. Write Interrogate no longer reports BOT status, which seems to satisfy the MCP.
  5. The X register in the Processor was not being set properly at the end of some arithmetic operators. The X register is cleared at the end of each operator in Word Mode, so this did not affect operation under the normal user interface, but it did cause problems in the B5500SyllableDebugger interface. The guilty operators have been corrected.
  6. The B5500SetCallback.js module, which controls the synchronous interleaving and timing of all emulator activities, has a mechanism that adjusts future timing behavior based on the deviation between the execution delays it requests and those it actually receives. Tuning this mechanism has been an on-going process, and further tuning adjustments were made in this release.
  7. The ESU card in the standard cold-start card deck (tools/COLDSTART-XIII.card) has been changed to indicate the system has two disk EUs instead of three. When cold-starting a disk subsystem, you should always change this card to reflect the actual number of EUs configured for the disk subsystem.
  8. Preliminary decks for cool-starting and loading an MCP from tape to disk have been created in the tools/ folder as COOLSTART-XIII.card and MCPTAPEDISK-XIII.card, respectively.
  9. The B5500ColdLoad.html cold-start script (which is now deprecated) could not open the IndexedDB database for the disk subsystem in Google Chrome. This was caused by a differing interpretation between Firefox and Chrome of the second parameter to the IDB open() method, and has been fixed.
  10. Most of the disk subsystem utility scripts in the tools/ folder (B5500DiskDirList.html, etc.) would work only with the default disk subsystem, named B5500DiskUnit. These scripts now support a "db" query string parameter that specifies the name of the disk subsystem. For example, you can now invoke these scripts with a URL of the form: ".../tools/B5500DiskDirList.html?db=MyNewDisk".


Firefox Disk Quota Woes


Beginning with release 1.00, the emulator supports multiple disk subsystems. Using the configuration interface (entered by clicking the B5500 logo on the console panel while the emulator is in a powered-off state), you can easily create and switch among disk subsystems to, for example, move between datacom and timesharing MCPs or operate multiple versions of the MCP.

Several users have found multiple disk subsystems to be a nice thing to have, but its use has recently brought a problem to light when running under Firefox.

I have encountered the problem most often after setting up a second or third disk subsystem and during the process of loading system or symbol files to the new subsystem. Suddenly the tape load stops and the console shows the DKA lamp and one of the IOUn lamps lit. The rest of the system quickly ceases operating as well, except that the TIMR lamp for the interval timer interrupt continues to blink. A halt/load will often bring the system back up, but attempts to continue loading files from tape, or doing anything that uses more disk space, quickly results in the system locking up again.

It took a while to track down the cause of this. It was clear fairly early on that an IndexedDB write transaction never reported completion. Without that completion event, the emulated B5500 I/O never finished, so the Disk File Control Unit (DKA) and the I/O Control Unit (IOUn) remained in a busy state. Additional disk I/Os in the system quickly queued behind the write that never completed, and being denied further disk access, the MCP and its tasks quickly came to a standstill.

After several frustrating attempts to trace the I/O causing this problem, I finally discovered what was happening, which in turn revealed a rather serious bug in the emulator's disk driver. The IndexedDB API in Firefox was reporting a Quota Exceeded exception and aborting the write transaction. Unfortunately, the API reports this condition through the transaction's onabort event handler, not its onerror handler, and even more unfortunately, I had not implemented an onabort handler for either disk reads or writes, so the quota error went undetected by the emulator.

On abort event handlers have been implemented in release 1.02. They simply terminate the I/O operation, reporting the EU as not ready. That does not get around the quota problem, but it does cause a message reporting the not-ready condition to be printed on the SPO, so at least you will now know that there is a problem with the disk subsystem. The system as a whole will still stop operating. No further data can be inserted into any of the disk subsystems.

I have not been able to find any documentation on disk quotas for Firefox, and in fact the MDN web site clearly states there isn't one. The best I have been able to determine after a good deal of searching is that Firefox currently has a fixed 2GB upper limit on the amount of off-line storage that can be used by applications from the same source (i.e., same website). That limit appears to be hard-coded in Firefox and cannot be changed in the browser configuration. The only solution to the quota limit I have found is to delete one of the disk subsystems so that total off-line storage will fall below the quota limit.

Google Chrome also has quota limits for off-line storage used by web sites, but its limits are based on the amount of free disk space available on the workstation.

2GB is a lot of disk space, and should be sufficient to support many large B5500 disk subsystems, but I've also found that with the Uint8Array structure currently used to represent data in a disk sector, Firefox is storing that data in an extremely inefficient fashion. The overhead appears to be on the order of 30 times the size of the raw data being stored. I have a disk subsystem that contains perhaps 50-60 million (B5500) characters. Each six-bit B5500 character is stored as an eight-bit byte. The SQLite database used by Firefox for that IndexedDB instance currently occupies 1.8GB on disk. That means I'm already close to the 2GB limit, and a second disk subsystem does not need to get very large to exceed it.

The real problem here is the bloated storage overhead. My guess is that instead of storing a Uint8Array(240) disk sector image as simply a string of 240 bytes, Firefox is storing it as hash table containing 240 index:value pairs.

I am hopeful that we can find another data representation that will not carry so much storage overhead. This will require some research. If we are successful in reducing the storage overhead, however, that will invalidate all disk subsystems currently out there, and we will need a plan and some tooling to covert the existing subsystems to whatever new format we come up with.

For now, the best advice I can offer to those experiencing this problem is to try to keep your disk subsystems fairly small, or not to create multiple of them. Note that the quota limit is per website, so if you can split your emulator environments across multiple web sites, each will have a separate quota limit. Also note that a website is determined by the host portion of a URL, so for example, http://www.phkimpel.us/B5500/ and http://phkimpel.us/B5500/ are considered to be separate web sites by browsers, even though both URLs go to exactly the same place.

As always, if you have questions or need help with emulator issues, please raise them on the forum, so everyone can participate and share in the knowledge.

Monday, February 9, 2015

Emulator Version 1.01 Released

Nigel and I are pleased to announce that version 1.01 of the retro-B5500 emulator was released on 8 February 2015. All changes have been posted to the Subversion repository for our Google Code project GitHub project. The hosting site has also been updated with this release, and for those of you running your own web server, a zip file of the release can be downloaded from Google Drive.

This is a minor release containing corrections for a few issues we have discovered in the four months since version 1.00 was released. In addition, we have changed the way the operator Control Panel is displayed and implemented a different home page for the emulator's web application.


New Control Panel


In previous versions of the emulator, you started by loading the B5500Console.html page into your browser window or tab. This page displayed the operator Control Panel from which you power on the emulator, load the MCP, and monitor the status of the running system:


The problem with this approach was that the Control Panel occupied only a small portion at the top of the page, leaving the remainder of the page unused. In order to bring the Control Panel into view, the entire home page had to come to the top of the screen, when tended to obscure the other windows opened by the emulator, particularly the window for the SPO.

In this release, we have split the Control Panel from the home page. It now displays in its own window, which is sized just large enough to show the entire panel. This smaller window is much easier to position and use without obscuring the other windows on the screen.

That change left the B5500Console.html home page completely empty, so in order to make some use of that space, we have implemented a proper home page for the emulator site:


This is the page that will now greet you when you load the emulator's B5500Console.html URL. The two blue buttons below the image on the page allow you to open the Control Panel and optionally power up the emulator.
  • Clicking the Start & Power On button will open the Control Panel and power up the emulator, as if you had clicked the panel's POWER ON button. This is the option you will probably use most frequently.
  • Clicking the Start - Powered Off button will simply open the Control Panel. This option is useful if you want to start by modifying the emulator configuration, which can only be done in a powered-off state.
Both buttons will be disabled when either of them is clicked, and will remain disabled until the Control Panel window is closed. Attempting to close the Control Panel while the emulator is powered on will result in the display of a warning dialog. If you choose to confirm the warning and close the panel's window, the system will be halted and the emulator implicitly powered off.

Note that in some browsers, particularly Firefox, closing the window for the new home page, minimizing it, or switching to a different tab in the same window may cause the emulator to run slowly. The reason is that Firefox tends to impose a minimum timeout delay of one second on hidden windows, whereas the emulator typically generates timeout delays in the low tens of milliseconds. The difference between the requested and imposed delays results in very slow performance.


Other Changes


The following enhancements and corrections have been implemented in this release:
  1. The scroll-back buffer for the SPO and Datacom devices has been increased from 1500 to 5000 lines.
  2. Switching on and off the green-bar styling for the Line Printer device did not work in Chrome due to the way the styling was being applied. This has been fixed.
  3. A number of improvements have been made to the emulator's setCallback() mechanism, which is used to regulate performance and time-slice among the processors and I/O devices. These changes were imported from the Datatron 205 project, discussed below.
  4. Some optimizations to the bit-field isolate/insert routines have been made. These were also imported from the Datatron 205 project.
  5. A letter "B" has been added to the tape reel image used by the Magnetic Tape device. This makes the image less rotationally symmetric, and less likely to beat with the refresh rate of the screen.
  6. The wiki pages have been updated for the Control Panel and home page changes in this release.

Related News


With the B5500 emulator in a stable state, I have started a new project to emulate the ElectroData/Burroughs Datatron 205 computer system. This was a vacuum-tube, drum-memory computer designed in the early 1950s. It competed against the IBM 650 and Bendix G-15. It was fairly popular in its day -- several hundred were built -- and it continued to be used into the mid/late 1960s.

The primary goal of this project is to build a web browser-based emulator that will run 205 software at its actual speed -- which is very slow by even B5500 standards. A secondary goal is to reconstruct the Algol-58 compiler written for the system by Donald Knuth in 1960 and to get that working. An assembly-language listing of the compiler survives in the papers Knuth has donated to the Computer History Museum.

Tom Sawyer of Minnesota (US) has done considerable research on the 205 and on ElectroData, which was purchased by Burroughs in 1956 and became the foundation of its commercial computer business. He has an interesting web site and a blog devoted to the 205 and its history. I contacted Tom when starting this project in the Fall of 2014; he has been enormously helpful in my work on an emulator and has shared with me a number of technical resources that are difficult to find. Tom has also written an emulator for the 205, and reconstructed a different version of the Algol-58 compiler, which he discusses in a recent blog post.

At present, my emulator is functional, but supports only paper-tape and Flexowriter (teletype) I/O. I am currently working on the Cardatron, a buffering and reformatting device that interfaced the 205 to IBM punched-card tabulating equipment. A couple of weeks ago, I posted an article on Tom's blog describing the current version of the emulator and how to use it.

As with the B5500 emulator, my 205 emulator is an open-source project hosted on Google Code. If you are interested, the emulator can be run directly from my hosting site.

Monday, September 29, 2014

One Point Oh

Nigel and I are pleased to announce that version 1.00 of the retro-B5500 emulator was released on 29 September 2014. All changes have been posted to the Subversion repository for our Google Code project GitHub project. The hosting site has also been updated with this release, and for those of you running your own web server, a zip file of the release can be downloaded from Google Drive.

This release is a significant milestone in the development of the emulator. We have bumped the release level from 0.20 to 1.00 as we feel the emulator is now functionally complete. It is not finished, of course, and probably never will be. There are features of the B5500 that we still do not support (e.g., drums and paper tape devices), areas where significant improvements can be made (e.g., multiple datacom stations), and some areas that may not be practical to support in a browser-based emulator (e.g., File Protect Memory, shared disk systems, and additional datacom line-adapter types). Those issues can be pursued as our time and the desire of the user community permit.

This is also a very large release, with many new features and changes to existing ones. This blog post will attempt to introduce and summarize these changes, but there have been extensive updates to the wiki pages as well. The wiki now also has a table of contents, which can be displayed as a sidebar on the left of the wiki pages. We recommend that before using this new release, you peruse the following wiki pages in particular:

New System Configuration Mechanism


The most significant feature of this release is a completely new, and much more flexible configuration mechanism for the emulator.

Overview


In earlier releases, the system configuration was defined by a static Javascript file, emulator/B5500SystemConfiguration.js. If you were running your own web server, you could modify this file to alter the system configuration -- the processors, memory modules, I/O control units, and peripheral devices the emulator would use. If you were using the emulator from a web server hosted by someone else, however, you were stuck with whatever configuration was coded in the Javascript file on that server.

An additional restriction in earlier releases was that the configuration of the disk subsystem was fixed by the B5500ColdLoader.html script and could not be changed. The standard script created a disk subsystem with two Electronics Units (EUs) having a total of 400,000 sectors, or 96 million 6-bit characters of storage.

The new mechanism stores the system configuration in a small IndexedDB database within your browser. There is a new user interface (UI) that allows you to select the system components you want to make up a configuration. Since this data is stored locally on your workstation, each user can control their own configuration, even when the emulator files are hosted on an external web server. The Javascript file still exists, but its role is now to define the structure of the system configuration data. It is no longer used by the running emulator.

You can now also define multiple configurations and easily switch among them. Each configuration has a name that identifies it within the IndexedDB database. There is no practical limit to the number of configurations you can create. Switching between configurations is as easy as opening the configuration UI and selecting the desired name from a pull-down list.

In addition, the new configuration mechanism supports multiple disk subsystems. Each disk subsystem is implemented as a separate IndexedDB database within the browser. There are a number of uses for multiple disk subsystems. One is to support separate systems for the Datacom and Timesharing MCPs. Another is to maintain different levels of the MCP and easily switch among them.

You can specify the number of EUs in a disk subsystem and the number of Storage Units (SUs) independently for each EU. You can also modify the configuration of a subsystem at a later time to add more EUs or add more SUs to existing EUs. A disk subsystem can have up to 20 EUs (the B5500 maximum), although only the first ten EUs are addressable when the system configuration includes a Disk File Exchange (DFX) component.

The emulator now supports both the original Model-I SUs (40,000 sectors, 20ms average access time) and Model-IB SUs (80,000 sectors, 40ms average access time). The latter model was known as "bulk" or "slow" disk. All SUs for an EU must be the same model, but separate EUs can have different SU models.

You assign a name to each disk subsystem when you create it. That name also becomes the name of the subsystem's IndexedDB database. You use this name to assign the subsystem to a system configuration. A given system configuration can have only one disk subsystem associated with it at a time, but the subsystem associated with a system configuration can be changed at any time.

Using the New Configuration Interface


The emulator permits configuration changes to be made only when it is in a powered-off state. To access the configuration UI, simply click the "B5500" logo (below the Burroughs logo) on the right side of the Operator Console window. A System Configuration sub-window will open:


To change the set of components in a configuration, simply tick or un-tick the appropriate check boxes on the dialog and click the SAVE button. To switch to a different configuration, select it from the Configuration name list and click SAVE. To create a new system configuration, click the NEW button. The dialog will prompt you for the name of the new configuration and then fill the dialog with a default configuration, which you can modify as desired. Each time you click the SAVE button, the displayed configuration becomes the "current" configuration for the emulator. That will be the one used the next time the emulator is powered-on.

To delete a configuration, select its name from the pull-down list and click the DELETE button. The dialog will prompt you for confirmation of the delete, but once acknowledged, the deletion is permanent and cannot be undone.

Note that some elements on this dialog represent features that are not presently supported by the emulator. Their controls are disabled on the dialog.

You assign a disk subsystem to a system configuration by selecting the subsystem name from the Storage name pull-down list on the dialog. Saving the configuration associates that subsystem with that configuration. You can create or modify a disk subsystem by clicking the NEW or EDIT buttons next to the list of storage names. Doing so will open the Disk Storage Configuration dialog in a new sub-window:



If you click the NEW button, the system configuration dialog will prompt you for the name of the new disk subsystem before opening the storage configuration dialog. To add EUs to the subsystem, simply tick their check boxes and select the number and model of SUs the EU should have. Click the SAVE button on this dialog to update the configuration, apply any necessary schema changes to the IndexedDB database, and associate this subsystem with the underlying system configuration.

Once you click SAVE, any storage you have added to the subsystem becomes a permanent part of the subsystem and cannot be removed later. The check boxes for the selected EUs will be disabled so that they cannot be un-ticked. You may not decrease the number of SUs, nor change Model-IB SUs to Model-I SUs, as either of those changes would reduce the amount of storage in the subsystem.

The reason for the restriction on removing storage from a subsystem is that the B5500 MCP considers all disk on the system to be a monolithic resource. Disk files are organized as a set of separately-allocated areas (extents), which may be spread across multiple EUs of the subsystem. Removing storage from the subsystem could cause some areas of files to disappear, so the emulator does not allow this.

To delete a disk subsystem, open it in the Storage Configuration dialog and click the DELETE button. The dialog will prompt you for confirmation, but once acknowledged, the IndexedDB database for the subsystem will be deleted from your workstation. This deletion cannot be undone.

Disk subsystems from earlier emulator releases can be used without change in 1.00 and later releases. These legacy subsystems have the name B5500DiskUnit. The legacy subsystems can continue to be used with earlier releases of the emulator if their configuration is not changed. Once you change the configuration of a disk subsystem, however, it can no longer be used by releases prior to 1.00. There two reasons for this:
  • Adding EUs to a disk subsystem requires a change to the IndexedDB database schema. This change increases the IndexedDB version property for the database. Releases prior to 1.00 required the database to be at version 1 and will not open a database having a higher version.
  • Each IndexedDB database for a disk subsystem contains a configuration table that describes the EUs in the subsystem. The format of that configuration table has changed for release 1.00 in a way that is incompatible with earlier releases. This also means that disk subsystems created by release 1.00 and later cannot be used with earlier emulator releases, even it their IndexedDB version is 1.

Updating from Earlier Releases


When you first power-on the 1.00 emulator in a browser with which the emulator was previously used, the emulator will create a default system configuration named "Default", having a set of components that is somewhat reduced from the default configuration in earlier releases. In particular, it has only one Disk File Control Unit (DKA) and one magnetic tape drive. The configuration will include any existing legacy B5500DiskUnit subsystem. You may wish to adjust this default configuration before proceeding further.

When you first power-on the 1.00 emulator in a browser where the emulator has not been previously used, the emulator will create both the default system configuration described above and a default disk subsystem named B5500DiskUnit. That configuration will have half the storage of previous default configurations -- one EU with 200,000 sectors, or 48 million characters.

Please see the Configuring the System wiki page for more details on the new configuration mechanism and how to use it.


New Cold Start Process


With the implementation of the new system configuration mechanism in this release, use of the B5500ColdLoader.html script is now deprecated. That script served to create the IndexedDB disk subsystem, initialize the disk directory structures, establish the bootstrap mechanism, and load the MCP and other system files from ".bcd" tape images. It dates from a very early point in the emulator development, long before card reader and magnetic tape peripheral devices were implemented.

We now recommend that disk subsystems be created using the new system configuration mechanism, and that they be initialized the old-fashioned way -- with a Cold Start card deck.

We have actually been able to Cold Start the system from a card deck for almost a year, ever since the initial tape drive implementation was made available in release 0.15 last November. We owe thanks to Tim Sirianni and Paul Cumberworth for pioneering the research in how to do this, using the ESPOL compiler to generate the necessary card-load decks from relevant symbol files, and assembling the decks with an appropriate set of parameter cards.

I have taken Tim's latest version of his deck, reworked the parameter cards somewhat, and created a default Cold Start deck you can load directly, or use as a base for customization. This deck is in the tools/ directory of the emulator files, and can also be downloaded from our hosting site at http://www.phkimpel.us/B5500/tools/COLDSTART-XIII.card.

The Cold Start deck consists of two "card-load-select" programs, the COLD Loader and Tape-to-Disk Loader, along with their respective control cards. At the end of the deck is a short MCP Library/Maintenance job that will load a minimal set of system files from the Mark-XIII SYSTEM tape image to disk.

To use the Cold Start deck, follow these steps:
  1. First download a copy of the deck to your local file system.
  2. If you wish, you can modify the parameter cards to suit your preferences, but be careful not to disturb the card images for the card-load programs themselves. Many of the settings on the parameter cards can be modified using SPO commands after the MCP is up and running, so you may want to leave the deck as is, at least initially.
  3. Load the emulator into your browser. Make sure you have the correct system configuration and disk subsystem selected. A Cold Start wipes out any existing disk directory on the disk subsystem, effectively destroying all B5500 files in the subsystem.
  4. Power-on the emulator.
  5. Load the Cold Start deck into card reader CRA and press the START button on the reader.
  6. Load the SYSTEM tape image into a tape drive (any available drive will do) and click the drive's REMOTE button to make it ready.
  7. On the Operator Console, click the yellow CARD LOAD SELECT button so that it illuminates.
  8. Click the LOAD button on the Console. The reader will load the one-card binary bootstrap on the front of the deck, which will then load the COLD Loader program into memory and start executing it. The COLD Loader will initialize the disk subsystem and create an empty disk directory. It will also process the parameter cards and store their values on disk. The program will then print "DIRECTRY BUILT" [sic] on the SPO and halt. The process should take about 30 seconds.
  9. Leave the CARD LOAD SELECT button illuminated. Click the HALT button, then click LOAD again. The reader will load another one-card binary bootstrap, which will in turn load the Tape-to-Disk Loader program and start executing it. You should see the tape spin as the loader searches for the MCP file and loads it to disk. After a successful load, the program will print "MCP FILE LOADED" on the SPO. It will then automatically boot the MCP just loaded.
  10. The standard parameter cards for the COLD Loader will set an MCP option that requires you to set the time of day after a halt/load. You should first set the date with the SPO DR command. Then once you set the time with a TR command, the MCP will read the cards for the Library/Maintenance job and load those files to disk.
  11. One of the files that job loads is the System Intrinsics, INT/DISK. Since the system was just Cold Started, you must specify the name of the Intrinsics file to the MCP using the SPO command "CI INT/DISK". The MCP will preserve that setting across future halt/loads.
  12. At this point the system is fully initialized and ready for use. You may wish to load additional files from the SYSTEM tape, or wait and load more files later as the need arises. It would be a good idea to click the CARD LOAD SELECT button at this time to turn it off.

The B5500ColdLoader.html script can still be used to initialize a disk subsystem for use with release 1.00, but it can only work with the disk subsystem named B5500DiskUnit in its legacy configuration. This script will be removed in a future release, so we strongly recommend that you stop using that script and switch to the new process described above.

Please see the Getting Started wiki page for more details on how to initialize the emulator environment using the new configuration mechanism and Cold Start card deck. That page also has links to the B5500 reference manuals that describe the card-load-select programs and their parameter cards.


Off-line Emulator Operation and the "Application Cache"


The emulator, like most non-trivial web applications, cannot be loaded into a browser from your local file system. Instead, it must be loaded over HTTP from a web server. Once loaded, however, the emulator runs completely within the browser, and the web server is not needed again until the next time you load or reload the emulator.

The continually-evolving HTML5 standards have established a browser feature known as the "Application Cache." This is a bit of a misnomer, as it is not so much a cache as it is a way to install a web application within a browser for off-line use. Once the application is installed, it can be run in the browser without access to the web server from which it is hosted, and even without the browser having access to a network connection at all. Both Google Chrome and Mozilla Firefox support this capability.

Not all web applications can take advantage of off-line operation, especially if they require access to Internet resources while they are running. It is perfectly suited to the emulator, however, since the emulator requires no network or Internet access once it is loaded into the browser. Thus, it is now possible to use a version of the emulator that is hosted on an external web server in situations where you have no access to that server. You load the emulator into the browser using the same URL you would if operating on-line, but the browser will load the emulator files from its local Application Cache rather than from the web server.

Installation and use of the emulator from the Application Cache is unconditional and completely automatic. The first time you load the emulator using release 1.00 or later, the browser will load the emulator files into its local storage. You will see messages displayed in the top-left of the Operator Console window as the application is installed and the complete set of emulator files is downloaded.

Once the emulator is installed within your browser in this way, it will continue to be served from the local Application Cache, even when your browser has network access and can reach the web server from which the emulator was originally hosted. Instead of loading the emulator files from the server when on-line, the browser will instead check the server to see if a newer version of the emulator is available. This check takes place asynchronously, in the background, and neither inhibits nor delays use of the emulator while it is taking place. You will see some messages display in the top-left of the Console while this check takes place.

If a newer version of the emulator is available on the server, the browser will download it, again asynchronously in the background. The new version will be installed automatically in the Application Cache, but the browser will continue to use the prior version until the next time the emulator is reloaded in the browser. At that point the new version of the emulator will be used by the browser and the prior version will no longer be available. This behavior is not unlike the way that most web browsers themselves are updated automatically from the Internet and made available the next time you restart them on your workstation.

Please see the Using the Operator Console wiki page for more details on off-line operation of the emulator and the messages that are displayed during the application installation and update process.


Peripheral I/O Device Changes


This release contains numerous changes and enhancements to the I/O devices and their user interfaces. The following discussion summarizes the differences from prior releases, but please see the respective wiki page on each device for details.

Line Printer


The line printer driver has been completely rewritten. The original driver was a quick-and-dirty implementation, literally thrown together as a debugging exercise. It worked well enough that we have continued to use it, but it had no operating controls and was missing several important features.

The new driver supports a user interface with controls similar to those of the B329 printer. There are now buttons to make the printer ready and not ready, and to manually perform single-space and form-feed operations. To keep printed output from flooding the memory of the browser, the printer has long limited the capacity of its "paper" area to 150,000 lines -- about the equivalent of a box of the pin-feed forms used with the real printers. The new driver now supports an end-of-paper indicator and a more realistic way of clearing the "paper" from the printer when its capacity is reached.

The B5500 used five special Algol characters that do not have ASCII equivalents -- left-arrow, multiplication, not-equal, less-than-or-equal, and greater-than-or-equal. As described in the wiki pages, we have assigned ASCII substitutes for these (e.g., left-arrow as "~"), but several people have expressed a desire to see the actual Algol glyphs, especially in printer output.

The Unicode standard has glyphs for all five special Algol characters, and many fonts available for workstation operating systems include these glyphs. The new line printer driver will now generate these Unicode glyphs, but an option on the printer UI allows you to turn this off and still obtain printed output with the ASCII substitute characters. The default setting for that option can be specified in the system configuration.

Card Reader


The card reader will now unconditionally accept the five Unicode code points for the special Algol characters in "deck" files that are loaded into it. Files may contain a mixture of both Unicode and the ASCII substitutions for the Algol characters. The reader will now also accept the underscore ("_") as an ASCII substitute for the left-arrow.

Card Punch


Similar to the new line-printer driver, the card punch will now optionally output the five special Algol characters using Unicode glyphs. The default setting for that option is also in the system configuration.

The card punch UI now has annunciators on the right side of its panel that will illuminate when one of the output stackers reaches its capacity of 850 cards.

SPO


The SPO interface has been redesigned to accept keyboard input using a standard HTML text box. Formerly, keystrokes were simply captured by the driver when the SPO window or its paper area had the focus. This works fine when you have a real keyboard, but not at all on mobile devices such as tablets that simulate a keyboard on their touch surface. Most of these devices only display the simulated keyboard in a browser when the focus is in a text box or other control that accepts text input. Since the original SPO did not use a text control, there was no way to get the keyboard to appear.

In the new implementation, the SPO driver will enable a border-less, yellow-shaded text box at the bottom of the paper area whenever an I/O Control Unit issues a read operation to the SPO. The MCP initiates a SPO read in response to you clicking the INPUT REQUEST button on the SPO window, or pressing the ESC key when the SPO window has the focus. This text box is disabled and made invisible when you end input to the SPO.

This new approach has solved several obscure, but long-standing problems with input to the SPO. It also has the advantage that you now see a cursor when keying text on the SPO, and you can use standard GUI editing and copy/paste operations during SPO input. It seems to work fine on the tablets we have tested. There are still numerous issues with running the emulator on a mobile device, however (e.g., the I/O devices open as tabs instead of windows), but we have seen significant improvement during the past few months in the ability of mobile devices to support the emulator, particularly with Google Chrome on Android devices.

As a part of the changes to implement the new text input mechanism, the paper area of the SPO is no longer implemented as an HTML <iframe> element. You can still select and copy portions of the SPO output with your pointing device, but as a consequence of this change, it is no longer possible to save or print the contents of the paper area directly from your browser. To help compensate for this, double-clicking anywhere in the paper area will cause a new window to be opened and the current contents of the paper area copied into it. You can then save or print the SPO output from this separate window. Simply close the window when you are finished with it.

The amount of scroll-back retained by the SPO remains at 1500 lines. Older lines are discarded once this limit is reached.

Additional enhancements to the SPO include:
  • Support for the Unicode Algol Glyphs on output has been implemented in a manner similar to that for the line printer and card punch. Unicode code points on input are not currently supported, however.
  • The underscore ("_") is now accepted as a substitute for "~" on input. Keying either of these characters acts as if the END OF MESSAGE button had been clicked.
  • When you resize the SPO window, the paper area will resize in concert. This is especially useful when running the emulator on a workstation with a relatively small screen. Below a certain minimum size, however, the paper area will no longer resize and the contents of the window will be clipped. The really interesting thing to me about this feature is that it was implemented entirely through CSS style sheet changes. No Javascript was harmed in the process.

Magnetic Tape


The tape loader window that is activated by clicking the LOAD button for a tape drive is now opened on top of the drive window. Previously it was opened in the center of the workstation screen, which could make it confusing to which drive the loader window applied.

Timing for the animation of the tape reel image on the drive window is now done at a more granular level. This should improve the quality of the animation and reduce the degree of visual beating between the simulated rotation of the reel and the screen refresh rate.

Disk


Disk devices do not have a user interface, but there have been a few significant improvements internally.
  • The driver has been updated to work with the new system configuration and disk subsystem mechanism. It now attaches to the IndexedDB database for the disk subsystem specified by the current system configuration and adapts to the configuration of that subsystem. 
  • The driver now supports Model-IB (slow) disks in addition to the original Model-I disks, including the difference in average access time.
  • The driver now supports both configurations with a Disk File Exchange (DFX) and those without a DFX. Without a DFX, the B5500 supports up to 20 EUs, with EU0-9 addressed by DKA and EU10-19 addressed by DKB. With the DFX enabled, the system can support only EU0-9, but both disk controls can address any disk.
  • The emulator will now refuse to do a disk load if DKA is not selected in the system configuration. This mimics the way the B5500 hardware worked.

Datacom


The way that keyboard input for the datacom terminal was handled has been extensively reworked for better compatibility with Google Chrome. A more tablet-friendly input mechanism, similar to that described above for the SPO, is under consideration, but it is much more difficult to implement for a datacom terminal, as the input mode is initiated by the user pressing any key, not by the I/O Control Unit.

General Improvements


In earlier releases, the NOT READY indicators on the I/O device windows were rendered in red. Closer inspection of some color photographs of actual B5500 installations has revealed that this is incorrect -- the lamps were white. All I/O device windows have been updated to reflect this.

Several device windows have progress bars on them to indicate things such as input or output capacity. These were being rendered with HTML <progress> elements, but this usage is an incorrect application of that type of element. These have been converted to <meter> elements, which are visually very similar.

As with the resizing feature for the SPO, most other device drivers now resize their widow contents when their windows are resized.

Other Changes and Enhancements

 

Flag Bit Errors


For some time we have had a problem with programs aborting due to Flag Bit interrupts. These typically occur during periods of intense system activity, which suggests the problem may be related to Presence Bit interrupts. It has been a difficult problem to track down.

More or less by accident, I discovered a bug in the Processor object, where the stack was not being properly adjusted during the indexing of a descriptor. The value of the A register was being used without assuring first that the AROF validity flip-flop was set. As part of that, I also reworked portions of the OPDC and DESC operators in the area that detects Flag Bit errors.

Improper stack adjustment could lead to Flag Bit errors. These changes appear to have reduced the incidence of Flag Bit errors when the system is very busy, but they still occur occasionally. The most recent cases I've examined appear to happen during procedure exit, where the processor is checking the Flag Bit [0:1] on the Return Control Word. This is the only known bug in the Processor at present, and remains an outstanding issue (#23 in the project's issue list).

Downloadable Web Fonts


Normally, web browsers render the contents of their windows using fonts that are installed locally on the workstation. Browsers have for some time supported downloadable fonts, however, so we have taken advantage of that feature in this release. The intent is to standardize the fonts used by the emulator, and to eliminate any dependency on fonts installed locally on the workstation.

We have chosen the open-source DejaVu Sans and DejaVu Sans Mono fonts for use with the emulator. The Mono font was specifically chosen because it supports the Unicode glyphs for the special Algol characters, and because it has a numeric "0" glyph that is clearly distinguished from the letter "O".

This release includes files for these two fonts in both Web Font (.woff) and TrueType (.ttf) formats. The font files are quite large, but due to their local storage by the Application Cache feature discussed above, and the fact that they never change, you should be burdened by their download only once.

Operator Console Improvements


Prior to this release the NOT READY lamp on the Console was not implemented. When the emulator is powered-on, this lamp will now be illuminated if certain minimum configuration requirements are not met, e.g., no Processor is enabled in the configuration, the selection for P1 (the control processor) is not valid, or memory module 0 is not enabled. This is not exactly how that lamp behaved on the B5500, but the current implementation follows its purpose in spirit.

In previous releases, clicking the NOT READY lamp would toggle Processor B into or out of the running configuration. That was always intended as a temporary feature, and it has been removed in this release. The presence of PB can now be controlled through the new system configuration mechanism.

The Console will now perform a brief lamp test when the POWER ON button is clicked. Please report any burned out lamps on the forum.

The names of the current system configuration and disk subsystem are now displayed in the top-right of the Console window when the Console is in "non-purist" mode. Clicking the Burroughs logo toggles the Console between the historically-accurate "purist" mode and the default "non-purist" mode, which shows additional legends and annunciators for system status.

Miscellaneous Changes


Many of the scripts and style sheets have been significantly cleaned up and refactored. The user interface now has a more standardized appearance, and this will be easier to maintain going forward.

Images and fonts have been moved into a new webUI/resources/ directory to separate them from the HTML, CSS and Javascript files in webUI/. A number of files in the webUI/tool/, tools/, tests/, and source/ directories have been moved to more logical locations within the project's Subversion repository.

All HTML <meta> Content-Type character sets have been changed from ISO-8859-1 to UTF-8 so that the Unicode glyphs could be supported. A problem with FireFox requiring the character set to be specified within the first 1024 characters of an HTML file has been corrected.

Looking Forward


We have a few ideas for further enhancements in the emulator, but none of them is particularly urgent. Of course, it is likely that we will uncover more bugs that will need to be corrected, but except for the problem with occasional Flag Bit errors, the emulator at present seems to be quite robust and reliable.

The focus on future work is likely to be acquisition and restoration of more software for the B5500. We already have quite a bit that exists in the form of scanned listings. Those need to be transcribed, proofed, and debugged in order to make them useful. That is a very labor-intensive and frustrating process, but Jim Fehlinger has made amazing progress in the past several months with an OCR-based technique that has improved the throughput and reliability of the transcription process substantially, although it is still quite labor-intensive.

Development of the emulator itself has been a closely-held project, but restoration of software is something in which anyone (and everyone) can easily participate. Nigel and I have been pleasantly surprised by the amount of interest this project has garnered, especially given that we have not done all that much to advertise it. We hope that people will continue to be interested in and volunteer to work towards the restoration of software for this very interesting system.

The 50th anniversary of first customer shipment of the B5500 will occur in February 2015. There needs to be a party.