retro-B5500 Emulator Release 1.06

Nigel and I are pleased to announce that version 1.06 of the retro-B5500 emulator was released on 3 January 2020. All changes have been posted to the repository for our GitHub project. The hosting site has also been updated with this release.

Enhancements in Release 1.06

This is a primarily a bug-fix release, containing the collection of corrections and enhancements that have accumulated since 1.05 was released in March 2018.

Emulator Power-On

The emulator has since it's early days performed two actions as part of its "power-on" initialization sequence:

1. The SPO types out a brief message showing the emulator version.
2. The operator console displays a "lamp test" that lights all of the console lamps, waits a few seconds, and then extinguishes them.

I finally got tired of the delay these two behaviors caused and have disabled both of them.

Magnetic Tape Enhancements

The tape drive now examines tape-image file extensions in a case-insensitive manner when determining the format of the image.

The way that a drive stored words in memory during a backward read was incorrect. This has been fixed.

The tape drive will now detect "dropouts" -- areas where there is no flux change indicated by the bytes in the tape image. This can happen only with .bcd tape images, and can be made to occur by writing zero (i.e., all bits off) characters in even parity. If a dropout is detected, it will be reported as a parity error in the result descriptor.

Miscellaneous

When emptying a stacker on the card punch, the progress meter and stacker-full annunciator are now properly reset.

During the Processor's exit from Character Mode, the MSFF and SALF flip-flops were being reset and should not have been. In addition, the way the MSCW address was being obtained was unnecessarily complex. These issues have been corrected.

The delay deviation adjustment algorithm in the setCallback() function has been redesigned and simplified. The "alpha" factor that controls the rate of adjustment decay has been reinstated as part of the redesign.

A few of the utility scripts in the tools/ directory have received minor enhancements and some new scripts added. Most of these scripts are for internal testing and debugging, and are intended as templates to be customized for a particular situation.

• Added B5500DiskDump.html. This utility will write the contents of the first 20 sectors of EU 0 to a window.
• Modified B5500DiskPeeker.html to use the standard default name for a disk subsystem data base, "B5500DiskUnit."
• Added B5500DiskSeg0Fixer.html to correct the MCP and Intrinsics pointers in sector 0 of the halt-load disk unit.
• Modified B5500LibMaintDir.html to have a new "ShowRows" parameter to control whether header row-address words are displayed on the output.

A new, bootable card-image file, tools/DUMPTAP-XIII.card, has been added. Halt-loading this deck will dump the contents of B5500 memory to a tape drive. The tape can then be analyzed by the DUMP/ANALYZE utility after the system has been halt/loaded to run the MCP. This was a standard utility released by Burroughs, but I had never compiled it to get the deck.

An easier way to obtain a memory-dump tape is to click the NOT READY lamp on the console, but that is an emulator-specific feature.

Emulator Version 0.19 Released

Nigel and I are pleased to announce that version 0.19 of the retro-B5500 emulator was released on 10 January. 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 source can be downloaded from the GitHub repository [updated 2022-05-07].

This release supports the ability to write to magnetic tape and to persist tape image data created by the emulator.

Background on Magnetic Tape Images

The emulator has had an initial magnetic tape implementation for the past few months. That initial implementation supported only reading tape images, and only from images in the ".bcd" format. This release expands on that initial one by supporting additional tape image formats and the ability to write to a tape image.

Tape images exist in the form of files in your local file system. The initial implementation allowed you to select an image file, which the emulator would load into memory and then parse into blocks in response to read commands from the I/O Unit. The ".bcd" format was originally supported because that was the one used for Sid McHarg's Mark XIII Burroughs release tapes.

Since the retro-B5500 emulator runs in a web browser, we must live with some limitations on the way that the browser is allowed to interact with your local file system. Modern browsers can read just about any file the user can select from a "file picker" form control, but at present there is not a useful way for a browser to write files under program control to the local file system. This restriction exists for very good security reasons -- without it, hackers would be able to play havoc with your local files -- but it makes getting data out of the browser environment difficult.

There are File System and FileWriter APIs that have been proposed as part of the HTML5 standards initiative, but they have two problems. First, only the Google Chrome and Opera browsers presently support them. Second, the files they create are "sand-boxed," i.e., the files exist within a virtual file system that is managed by the browser. Different browsers may format and manage this virtual file system differently. Worse, the files are generally hidden deep within the user profile directory used by the browser, are not named in obvious ways, and are difficult to find and use outside of the browser environment.

The only reasonably practical way we have found to output data from a browser is to format the data as text within a window and allow the user either to save the contents of that window to their local file system, or to copy/paste the contents into another program, such as a text editor, and save it from there. This process is neither automatic, nor very convenient for the user, but it is safe, and it works with all browsers.

Therefore, this new implementation for magnetic tape supports reading multiple tape image formats, but will output tape image data in only one format, ASCII text, as described in more detail below.

Loading Tape Images

Within the emulator, all tape image files are loaded in their entirety into a memory buffer. All tape reads and writes operate on that memory buffer. Depending on the block size used, a 2400-foot reel of 7-track tape could hold between about two and 22 million characters. It would probably be appalling to the original designers of the B5000 and B5500 that we would implement tape devices by sucking all of the data into "core" memory and operating on it exclusively there, but that turns out to be the easiest and most effective way to do it.

To support multiple tape image formats, the process of loading an image into a tape drive has changed slightly from the original implementation. The file picker control on the tape drive window has been replaced by a text box that will display the name of the image file after it is loaded. When you click the LOAD button on the tape drive window, a small dialog window now opens instead of activating the file picker as before. This window contains the file picker, a Format drop-down list to select the image format, a Write Ring check box to indicate whether the image is writable, and a Tape Length drop-down list to select the length of the tape reel:

To load an existing tape image, simply select it using the file picker. The emulator will attempt to infer the image format from the file name extension, as follows:

• ".bcd" implies a ".bcd" tape image.
• ".tap" is reserved for supporting the "tap" (or "taput") format in the future. See http://simh.trailing-edge.com/docs/simh_magtape.pdf for a specification of this format. It is not implemented at present.
• All other extensions presently imply the "ASCII Odd Parity" format described below under Unloading Tape Images.

You can override the inferred tape format by making a selection from the Format drop-down list. Regardless of the format of a tape image you load into the emulator, it converts the image to the ".bcd" format and uses that format internally. The options presently available are:

• (blank tape) -- This will load a blank tape image into the drive. Any file you previously selected with the file picker will be ignored.
• .bcd image -- This will interpret the bytes in the selected file as a ".bcd" image and load it into the drive without conversion.
• ASCII Even Parity -- This will interpret the bytes in the selected file as ASCII characters and convert them to an internal ".bcd" image with even-parity BCL codes.
• ASCII Odd Parity -- This will interpret the bytes in the selected file as ASCII characters and convert them to an internal ".bcd" image with odd-parity B5500 Internal Code (BIC) codes.

Next to the Format list is a check box labeled Write Ring. If this box is checked, the internal tape image will be writable. The tape image on disk will not be affected by writing unless you later save the image over the original file when the tape is unloaded. If you merely want to read the tape, leave this box unchecked.

The last control is another drop-down list labeled Tape Length. It is relevant only when Write Ring is checked and is disabled otherwise. This specifies the length of tape on the virtual "reel" loaded into the drive. It defaults to 2400 feet, but lengths of 1200 and 600 feet are also selectable. The primary purpose of the length is to allow the drive to report it has passed the reflective EOT (end of tape) marker, which will signal the MCP that it is near the near to the end of the tape and that it should switch to a new reel. When Write Ring is not checked, the length of the tape is inferred from the size of the tape image data.

To load a blank tape into the drive, do not select a file using the file picker. Select a format of "(blank tape)," which is the default. The Write Ring box will be checked automatically and the tape length will default to 2400 feet. You may select a different tape length, if you wish. Any image file you previously selected with the file picker will be ignored.

If the Format list has a value other than "(blank tape)," you must select a file before clicking the OK button. When a file is selected using the file picker, the Format value is inferred from the file name extension, the Write Ring box is unchecked, and the Tape Length list is disabled. You may then alter the values of these controls before proceeding. The tape image is not loaded into memory until you click the OK button.

Unloading Tape Images

When a tape image is loaded with the Write Ring box unchecked, the image will be read-only, and writing to it will be inhibited. Later, when you click the UNLOAD button, that image data will simply be discarded by the drive, as it is still in the file from which it was loaded.

When the Write Ring box for an image is checked, the image will be writable, whether it was loaded as a blank tape or from an existing image file. Later, when you click the UNLOAD button, two things can happen:

1. If the tape was not actually written to, the emulator will simply discard the image data, as for the case of a read-only image above.
2. If the tape was written to, the emulator will ask whether you want to save the altered image data.
   • If you cancel out of this dialog, the image data will be discarded.
   • If you reply OK, however, the emulator will then open a new window and format the contents of the tape image as ASCII text. This may take several seconds for a full, 2400-foot reel of tape.
   • After the tape image text is formatted in the window, you may save it or copy/paste the data into another program. If you paste the text into another program, make sure that program will not trim trailing spaces from lines or compress multiple spaces using tab characters.
   • When you are finished with the image data, simply close the window.

 The ASCII tape image format is very simple:

• The six-bit BCL or BIC character codes are translated to ASCII using the emulator's standard convention for the B5500 characters that do not have ASCII equivalents ("~" for left-arrow, "|" for the multiplication sign, "!" for not-equal, "{" for less-than-or-equal, and "}" for greater-than-or-equal).
• Each tape block becomes one line of ASCII text. Lines are delimited by line-feed or carriage-return/line-feed characters, depending on the convention used by your browser.
• An end-of-file (tape mark) is represented by a block containing a single "}" character.
• All other blocks should be at least seven characters long, although the emulator does not enforce this.

Both even- and odd-parity tape image data converts to the same ASCII representation. The parity data is lost during this conversion.

An ASCII tape image may be loaded into a tape drive later as either "ASCII Even Parity" or "ASCII Odd Parity" format. These two formats will apply the appropriate parity to the data when it is converted to the ".bcd" format used by the drive internally.

Because the ASCII tape image format is just text, you can create tape images outside the emulator, either programmatically, or manually using an ordinary text editor.

See the Using the Magnetic Tape Drive wiki for more details on tape drive operation and the format of currently-supported tape image files.

Emulator Version 0.18 Released

Nigel and I are pleased to announce that version 0.18 of the retro-B5500 emulator has been released. 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 source can be downloaded from the GitHub repository [updated 2022-05-07].

This is a bug-fix release. The only significant new feature is the ability to dump the system processor and memory state to a window in the B5500Console and B5500SyllableDebugger interfaces, as described below.

Processor Bugs Fixed

The following corrections were made in B5500Processor:

1. The TRN (Transfer Numerics) syllable was not clearing zone bits in the destination character string as it should have. In addition, it was not always setting the True-False Flip Flop (TFFF, also known as MSFF) properly.
2. The TRW (Transfer Words) syllable was incorrectly throwing an Invalid Address interrupt when the source string ended at an address which did not have a valid next address (e.g., the highest memory address, @77777).
3. A call on cc.fieldIsolate() in the ISO (Field Isolate) syllable had an extraneous parameter. Thanks to Peter Grootswagers for identifying this.

More Corrections for Tape Drive Oscillation

We thought we had all of the issues with tape drives oscillating between rewind and ready states when tape was at BOT resolved in release 0.17, but alas, that proved not to be the case. Part of the problem was that the I/O Unit did not have tape writes implemented yet, but the rewind and interrogate functions are degenerate forms of tape write. As a result, result descriptors for Mod III I/O Units were not being properly constructed in some cases.

We also discovered, under Sid McHarg's advice, that the MCP is capable of detecting Mod III I/O Units automatically, but the problems mentioned above with the way that result descriptors were being constructed prevented that. With these fixes in place, that automatic detection now works properly, and the "SO USE OPTN 2" command described in the blog post for the 0.17 release is no longer necessary.

Dumping the System State

We have not had a good way to look at the complete system state up to now. The SyllableDebugger script provides some means to do this, but it is awkward to use when having to look at many widely-dispersed memory locations, and it's of no use at all when running the standard B5500Console user interface.

With this release, you can now dump the complete system state. In the SyllableDebugger, there is a Dump button near the top of the page. In the B5500Console interface, you can click the MEMORY CHECK indicator. Both methods will open a separate window and format both the processor state and the contents of core memory in that window. You can examine the dump in the window, save the window's contents, or copy/paste the contents into another application (such as a text editor) for further analysis. When you are finished with the dump, simply close its window.

These dumps can be requested any time the emulator is in a powered-on state. You can generate multiple dumps and have multiple dump windows open at a time. The emulator will pause while the dump is taking place and then resume operation. Thus, you can easily take a snapshot of the system state while the MCP is running, and then continue.

Further Work

We are continuing to see occasional flag-bit and invalid-address errors when running the MCP under heavy load. At present, we are working under the assumption that these are due to emulator bugs, and are pursuing them as a priority. The system state-dump feature mentioned above was implemented to facilitate this.

The next major feature scheduled for implementation is writing to tape, along with providing a means to persist tape volume data outside the emulator environment. After that we are considering implementing a more dynamic and user-friendly mechanism for controlling the system configuration, and implementing (finally) the double-precision numeric syllables.

Emulator Version 0.17 Released

Nigel and I are pleased to announce that version 0.17 of the retro-B5500 emulator has been released. 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 source can be downloaded from the GitHub repository [updated 2022-05-07].

This release contains one really big thing and a number of smaller things.

P2 Lives!

The really big thing is that the second processor, P2, is now functional. Getting this to work is especially gratifying to me, as it is an important feature of the B5000/B5500 and I have wanted it to work from the beginning. It has been very frustrating trying to get this going, as there are only a few places in the processor design where it needs to know whether it's P1 or P2, and it should have just worked. It didn't.

I had made several serious runs at this problem over the past six months, but made very little progress until one morning a few weeks ago when I awoke early. Lying in bed, I started thinking about an intermittent problem we have seen with the system under load and how to trap it. In the middle of those thoughts, it suddenly came to me why P2 wasn't working. It wasn't so much something to do with the design of the emulator's Processor object as with the way we interleave the activities for all of the processors, I/O units, peripheral devices, and console display on one Javascript thread. Without going into a whole lot of details, the way that interleaving was being done interfered with the way we need to start and stop P2. Changing less than ten lines of code fixed the problem.

The processors on a B5500 are physically identical, with a manual switch in Central Control determining which one is P1 (the control processor) and which is P2. Unlike the B6500/B6700 that followed it (and most multiple-processor systems today), the processors on the B5500 do not operate symmetrically. P1 is the control processor. Only P1 can run in Control State, service interrupts, and initiate I/Os. Much of the MCP runs only on P1.

P1 can also run in Normal State, which is used for user tasks. P1 enters Normal State during an Initiate P1 (IP1) syllable, which effectively assigns the processor to a user task by automatically loading state from a few words in the task's stack. P1 reverts to Control State when any interrupt occurs, automatically storing the task's state in the stack and PRT in the form required by IP1 for reactivation.

P2, on the other hand, can run only in Normal State, and thus can be used only to run user tasks. The MCP (running in Control State in P1) assigns P2 to a user task by means of the Initiate P2 (IP2) syllable, which functions similarly to the IP1 syllable. P2 runs until it detects one of its internal interrupts or the MCP running in P1 executes a Halt P2 (HP2) syllable. When one of those events occurs, P2 stores its state in the stack and PRT as P1 does and then idles, waiting for the next IP2 to occur. P2 does not sense external interrupts (such as the timer and I/O completions) and is not directly affected by them. They are handled by P1 instead.

P1 never idles until the system is halted -- its equivalent of idling is for the MCP to continuously execute its NOTHINGTODO loop, waiting for some interrupt or change in system status to occur.

The design of the MCP is intended to assign user tasks preferentially to P2 if it is available. If there is more than one user task ready to run and P1 does not have any Control State duties at the  moment, then both processors can simultaneously run user tasks. When running a single program in the mix, we have seen the program bounce between the processors, but if there is enough processor-bound work in the mix, then P2 will stay busy. Every time P2 senses an internal interrupt or needs some MCP service (which it signals by triggering a COM interrupt), P2 stores its registers and idles. If there is another task waiting for a processor, the MCP will generally initiate P2 again right away on it.

Compared with today's sophisticated SMP system designs, the multiple-processor mechanism on the B5500 probably seems a little clunky and inefficient, and in hindsight it was. But then, even multi-tasking was rare and controversial in the early 1960s, and for the B5000/B5500 to support both that and multi-processing was so far out that Burroughs was often accused of faking it when the capability was demonstrated. It did work, though, and was quite effective if you had a sufficiently processor-bound workload and the memory to support that workload. The two main reasons P2 can be underutilized are insufficient memory (generally resulting in MCP overhead and I/O to overlay memory to and from disk) and high levels of requests for MCP services, such as I/O, both of which can handled only by P1.

You can enable second-processor functionality for the emulator in the system configuration panel. See the Configuring the System wiki page for details. [updated 2022-05-07] by a setting in the emulator/B5500SystemConfiguration.js script. Set both PA and PB to true, and set PB1L to indicate which processor is P1. The other will be P2. At present, the second processor is disabled by default in the standard release.

Those of you using a hosted web site are not able to modify that configuration script, so we have implemented a temporary workaround to allow you to enable the second processor:

• Clicking the NOT READY lamp on the Console display will toggle the availability of Processor B in your local copy of the system configuration. When enabled, it will run as P2.
• When P2 is enabled in this way, the version level to the left of the "retro-B5500" logo will be yellow. When P2 is disabled, the logo will be white as usual.
• The availability of P2 is evaluated only when the POWER ON button on the Console is clicked, so it is best to change the status of P2 when the emulator is in a powered-off state. [obsolete since September 2014]
  

When the system is running and P2 is disabled, the P2BF annunciator (P2 Busy flip-flop) on the Console will be constantly lit. This lamp reflects a flip-flop in Central Control that prevents P1 from initiating P2, and generates a P2 Busy interrupt if P1 attempts to do so.

When the system is running and P2 is available, you should see P2BF turn on and off in concert with the B NORMAL lamp (assuming Processor B is configured as P2) as the MCP assigns user tasks to the processor. You may also see the HP2F (Halt Processor 2 flip-flop) annunciator flash occasionally as the MCP stops P2, usually to assign another task to it after the current task's time slice has expired.

You will need a fairly fast system to run both processors simultaneously at full speed. If the P1 Slack indicator on the emulator console is not at least 50% when running one processor, then your system may not be powerful enough. My one-year old, 3GHz, quad-core Dell Optiplex 390 running 64-bit Windows 7 Pro handles this with ease, as does a six-year old Mac Mini with an Intel Core 2 Duo processor running OS X Snow Leopard. An eight-year old Dell Optiplex GX 520 with a 2GHz Pentinum P4 running Windows XP is borderline. All of these tests were done using Firefox 24.0. Dual B5500 processors will still work on less powerful hosts, but the entire emulation will run slower than it otherwise would.

Tape Drive Oscillation at Load Point

Since the initial magnetic tape drive implementation was released in 0.15, a few people have been bedeviled by some odd behavior when a drive is made ready after loading a tape image, or after a tape is rewound by the MCP. There were some problems in the way that the driver was handling the tape image and reporting status to the MCP at load point (also known as Beginning of Tape or BOT). Those were mostly fixed in release 0.16, but a couple of people were still having significant problems. I couldn't reproduce them.

After about two weeks of collective hair-pulling, we finally determined that the problem was not the tape drive module, but an MCP configuration problem. Paul Cumberworth and Tim Sirianni were the ones still having the problem on 0.16, but they were also the ones working on cold-starting the emulator from card decks. In fact, they had that working, and had each cold-started their emulator instances from the Mark XIII cold start deck instead of the ColdLoader web script.

For some reason that we still have not run to ground, that version of the cold-start program does not properly set bit #2 (MOD3IOS) in the MCP option word. The emulator's I/O Control Units were written to behave like Mod-III I/O units, but that setting in the option word was telling the MCP that the I/O units did not have Mod-III capabilities. As a result, the MCP was handling the reading of tape labels entirely differently, and that difference was resulting in an endless cycle of the MCP reading the tape label and then rewinding the tape.

Paul Cumberworth reported this past week that the problem does not occur when cold-starting using the Mark XVI deck.

Fortunately, we found an easy workaround for systems that have been cold-started using the Mark XIII card deck. After the MCP has halt/loaded and you have entered the time of day, simply enter this command on the SPO:

SO USE OPTN 2

That will set bit #2 in the option word, and that setting will persist across halt/loads and emulator/browser restarts. Note that you will not need to do this if you have cold-started using the ColdLoader script. Also note that the SPO TO command does not display the status of bit #2 in its output.

If anyone feels left out and wants to experience the tape oscillation problem for themselves, you can manually reset bit #2 in a similar way and see what was driving Paul and Tim batty:

RO USE OPTN 2

Then load a tape image and make the drive ready. When you are tired of watching the tape drive misbehave (it probably won't take long), just use the first command above to set things right again.

Other Changes in this Release

1. The Character Mode syllables FAD (Field Add) and FSU (Field Subtract) would complement the wrong operand in certain cases. This was due to the initial compare of the operands being done in an alphanumeric mode instead of a numeric mode.
2. The Character Mode syllables TRN (Transfer Numerics), TRZ (Transfer Zones) and TBN (Transfer Blank for Non-numeric) did not work properly if the transfer spanned more than two words of memory. Words other than the first and last in the destination string were not being fetched into the B register.
3. If you have access to the B5500SystemConfiguration.js script, you may now configure up to 16 tape drives on the system.
4. The flip-flop latching mechanism in Central Control that is used by B5500Console for displaying annunciators was completely redone.
5. The routine that cleared interrupts in Central Control was reworked for more efficient operation.
6. New algorithms were implemented to compute average slack and delay in the Processor.schedule() routine.
7. Some Character Mode syllables were optimized by substituting local variables for Processor object "this" properties.
8. The Processor single-precision divide syllables were leaving the stack in an incorrect state after a divide by zero in Control State. This has been corrected.
9. A few further minor tweaks to performance throttling were implemented.
10. References to this.cc in the Processor.run() routine were optimized.
11. A few improvements to the tape drive module were implemented to eliminate oscillation at load point and improve the timing of rewind operations. The bulk of the tape drive oscillation problem was caused by the configuration problem discussed above.

Finally, I want to remind everyone that we now have a web/email forum on Google Groups linked to this project. If you have a question or a problem, this is the first place you should go to look for answers or post a request for help. Membership is open to everyone. To join the group, go to:

http://groups.google.com/group/retro-b5500/

Emulator Version 0.16 Released

Nigel and I are pleased to announce that version 0.16 of the retro-B5500 emulator has been released. 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 source can be downloaded from the GitHub repository [updated 2022-05-07].

This is a bug-fix release. Our community of enthusiasts found some rather serious problems in the new datacom interface, and some minor ones in the new magnetic tape drive interface. The most serious problem was that entering a zero-length message on the datacom terminal when would result in a "DCA ERROR ... READ BOUNCED BACK" error on the SPO, followed by a complete hang of datacom.

These problems have been fixed, and both new interfaces now appear to be working well. We have also made a few corrections and enhancements to the wiki pages.

We have also seen and had other reports of major instability when running the Timesharing MCP (TSMCP) and CANDE -- Invalid Address and Flag Bit faults, which typically result in either a program being DS-ed (aborted) by the MCP, or a complete system hang. Another report earlier today suggests that doing a fresh cold-start may resolve the problem, but this has not yet been confirmed. Obviously, we are concerned about this, and have not ruled out that it may be a problem in the emulator. Investigation is underway, but you may want to wait a bit before getting too excited about running TSMCP and CANDE.

In other news, Paul Cumberworth and Tim Sirianni are currently working on the set of card-load-select decks necessary to cold- and cool-start a B5500. Up to the present, we have had to rely on the ColdLoader script, a custom web page built for the emulator that initializes the IndexedDB disk subsystem, creates initial disk directory structures, and optionally loads files from Sid McHarg's B5500 Mark XIII tape image files. The card-load programs are the official way to do this type of system initialization, but could not be used until the card-load-select mechanism and support for tape drives became available. Once Paul and Tim have these decks working, we will make them available to everyone.

Finally, communication among the members of the retro-B5500 emulator community to date has been accomplished largely through email. As the number of interested parties has grown, this has become burdensome, so this week we created a web/email forum on Google Groups and linked it to this project. Membership is open to everyone. To join the group, go to

http://groups.google.com/group/retro-b5500/

 The primary purpose of this group is to provide a vehicle for discussion, questions, answers, and support for those using the emulator, and for discussion on the Burroughs B5500 system and software in general. We hope you will join us.

Emulator Version 0.15 Released

Nigel and I are pleased to announce that version 0.15 of the retro-B5500 emulator has been released. 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 source can be downloaded from the GitHub repository [updated 2022-05-07].

In the past six months, the emulator has transitioned from a state where we were astonished if it did anything, to one where now we are astonished if it doesn't do everything -- not that it is exactly in a state of perfection, mind you. The 0.15 release, in addition to numerous minor corrections and improvements, supports two significant new features: datacom and tape drives.

Datacom and Terminal Interface

With the emulator operating within a web-browser, understanding how to implement a data communications interface for it has been a bit of a thorny problem for us. To support external terminals, it would have been nice (and perhaps even necessary) for us to use the modern networking capabilities we have all come to rely on. The TCP/IP protocol upon which most network-based technologies are built, however, requires a network connection to have two ends -- a "client," which initiates the connection, and a "server," which listens for new client connections and reacts to them.

The problem is that the emulator would need to act as a server in this arrangement, but web browsers are capable of acting only as clients. There just isn't any way -- that we've been able to find -- for an application running within a web browser to accept incoming network connection requests and act on them. There are some approaches involving a third party that would serve as sort of a client-client "gender changer," but we chose to avoid those as being too complex.

Recognizing that an application running in a browser is very much a personal environment to begin with, we finally decided to abandon the idea of network-based datacom altogether. Our goal at present is for you to be able to access datacom-enabled applications running within the emulator, not to implement the type of multi-terminal, dial-in timesharing network one would have seen at a university or commercial site in the late 1960s. We hope that for most of you, being restricted to a single terminal instance will not prove to be too limiting.

Therefore, this initial implementation of datacom for the B5500 supports a single terminal interface operating within the emulator itself. Internally, we are emulating a B249 Data Transmission Control Unit (DTCU) with a single B487 Data Transmission Terminal Unit (DTTU). The DTTU is configured to have a single teletype-like terminal adapter, with a 112-character buffer, operating on buffer address 01/00. All of that is buried within the emulator and pretty well hidden from view.

What you see when running the emulator is a new window for the terminal itself. This window attempts to emulate something similar to a dial-in Teletype Model 33 KSR station. Along the top of the window is a Connect button to establish a connection to the B5500, and a set of indicators that show the status of the buffer in the B487. These indicators were originally implemented to debug the interface and may be removed at some point in the future.

The terminal works somewhat like the current SPO device, but without the need for input request to get the system's attention for input. You just key in messages and the terminal types out the responses from the system. Here are the basics:

• To initiate a session with the B5500, click the green Connect button. The button will light. The system should respond with its identification within a few seconds. Click this button again to disconnect.
• To enter a message, simply key it into the window. Terminate the message with a left-arrow (represented by the tilde, "~", in this emulator). As a convenience, you may also press the Enter key, which will echo as a tilde.
• To backspace to correct a mistake, enter a less-than ("<"). Enter this character multiple times to backspace the corresponding number of characters in the buffer. As a convenience, you may also press the Backspace key, which will echo as a "<".

 There are more keyboard capabilities, which are described in the wiki, Using the Datacom Terminal.

The B5500 had two separate operating system environments that supported datacom, the Datacom MCP (DCMCP) and the Timesharing MCP (TSMCP). If you followed the standard getting-started instructions, you probably cold-started with the DCMCP.

Both environments require some setup in order to use datacom. For DCMCP, see Appendix D and E in the B5500/B5700 Operation Manual. For TSMCP, see the Timesharing Terminal User Guide, Timeshare System Operation Manual, and Operating the B5500 Timesharing System. All of these documents are available at http://bitsavers.org/pdf/burroughs/.

We would welcome someone preparing a guest post for this blog on how to set up and configure the TSMCP and CANDE environment. If you are interested, post a comment to this blog or contact me through our Google Code project.

Magnetic Tape Drive

I started working on the tape drive interface because I needed to load more files from the Mark XIII system release tape image in order to test the datacom interface. The standalone B5500ColdLoader.html script has been able to load files from the Mark XIII tape images since the beginning, but in order to use that you needed to shut down the emulator, and that was inconvenient. In addition, the ColdLoader's handling of the MCP disk directory structures was not that robust. It could load files only to the first disk unit (EU0), and attempting to replace an existing file often corrupted the directory.

This initial implementation for tape drives is read-only, and works only with the ".bcd" format that is used for the Mark XIII tape image files. We plan to implement support for writing to tape and for other image formats in the near future.

Library/Maintenance is the portion of the MCP that manages disk files and maintains the disk directory. Among its features is the capability to dump disk files to and load disk files from magnetic tape. This was typically used for file backup, archiving, and transferring files among systems.

Files can be loaded from Library/Maintenance volumes such as the SYSTEM, SYMBOL1, and SYMBOL2 tape images using the LOAD and ADD control card commands, e.g.,

?LOAD FROM SYSTEM ESPOL/DISK, COBOL/DISK, DUMP/ANALYZE

A control card command can be continued across multiple card images by terminating the card with a hyphen ("-") wherever a word or other punctuation character might appear. The continuation card(s) that follow must not have an "invalid character" in column 1.

All files having the same first or last identifier in their file name may be loaded by specifying MFID/= or =/FID. All files from a tape can be loaded by specifying =/=. Library/Maintenance will not overwrite certain critical system files, such as the currently running MCP and Intrinsics.

The ADD command works the same as LOAD, except that it loads only files that are not already in the disk directory.

See the wiki, Using the Magnetic Tape Drive, for details on the .bcd image format and operating the tape drive. Also see Section 4, and in particular page 4-15 ff, in the B5500/B5700 Operation Manual for information on the LOAD and ADD control-card commands used to load files from B5500 Library/Maintenance tapes.

Miscellaneous Changes and Enhancements

In addition to the two major features above, this release has the following changes and enhancements:

1. A serious bug was fixed in the B5500SetCallback.js module, in preparing arguments for the call-back function. Among other things, this prevented the SPO from working properly in Google Chrome. Thanks to Hans Pufal for the information that led me to isolate and fix that bug.
2. Device drivers can now be optionally specified in the base web page hosting the emulator (e.g., B5500Console.html, B5500SyllableDebugger.html). Previously, all drivers known to the B5500CentralControl module had to be specified as <script> tags in the base web page, or initialization of CentralControl would fail during "power on." Peripheral devices will now be created only if they are both configured in the B5500SystemConfiguration.js script and have a <script> tag for their driver module specified in the base page. This will make it easier to implement alternate user interfaces for the emulator in the future.
3. I am finally caught up with documentation in the wiki pages. There are new pages for the card reader, card punch, line printer, tape drive, and datacom devices, along with numerous corrections and additions to existing pages. You can access these through the wiki directory on our Google Code project, or from the Help menu on our hosting site.
4. The way the SPO times and outputs characters, especially when echoing keyboard input, has been significantly improved. The SPO window is now slightly narrower, so that it takes less space on your monitor. The most significant change you will see, however, is that the SPO window is no longer given the focus when the MCP sends it a message. I liked that feature a lot, but it became very annoying to have the SPO suddenly get the focus when you were in the middle of entering a message into the datacom terminal window.
5. Some minor changes have been made to tune the performance of the Processor module, directed towards trying to get it to match as closely as possible that of a real B5500. We are still not there yet, but this is the first release where I have seen the emulator run faster than some timings I have for B5500 runs from the 1970s.
6. Additional work has been done towards getting P2, the second processor, to work. A little progress has been made, but P2 still craps out after only a short time running. I would really like to get this to work, but it's not a very high priority at present.
7. Finally, the standalone B5500DiskDirList.html script (in the tools/ directory) has been modified to dump the first ten words of each disk header in raw octal.

Other News

I am pleased to report that Hans Pufal in France and Fausto Saporito in Italy have finished their joint transcription effort for Gary Kildall's B5500 APL interpreter, and are now industriously proofing and debugging their work. With the initial datacom interface working, we hope to have APL alive once again in the near future.

Paul Cumberworth in Australia has been transcribing patches for the Mark XVI source files that were previously transcribed, and building compile decks for both those patches and the ones on the Mark XIII release tapes. We have encountered a couple of small problems with the base Mark XIII release files (e.g., the effect of a SPO MC command does not persist across halt/loads) that are addressed by these patches, and hope to make these decks available soon so that everyone can upgrade to the "latest" (i.e., October 1971) Mark XIII updates.

I am starting to accumulate a number of test and sample programs for the B5500, some from my own files and some sent to me by others. Presumably some of you out there have programs that you are (or would like to be) running in the emulator, and there are plenty of listings on bitsavers.org that could be transcribed for use with the emulator. We need a way to collect all of this in a central place so that it can be shared and maintained for the benefit of everyone who is interested in the B5500.

I have started discussing this with a few participants in the project, but we have not yet come up with a good idea of how this material should be organized, stored, and made available. We are very interested in any ideas that other participants and readers of this blog may have. We are also very interested in any B5500 software or other materials you may have in whatever form or condition it may be in. Please share. You can comment on this subject on the blog or contact Nigel or me through the Google Code project.

Another idea, if people are interested, is to set up a forum where everyone can interact independently, ask questions, share information, and otherwise act as a community. We have this capability available for the project through Google Groups, but just have not turned it on. If there is sufficient interest in having a common forum, I'll set it up. In the interim, you can post comments on this blog. You can also post entries in the issue tracker that is part of our Google Code project. You will need a (no-cost) Google account in order to do so, however.

I want to express again Nigel's and my appreciation for the interest and enthusiasm that many people are showing for this project and for the Burroughs B5500, plus all of the effort that several are putting into making the emulator and the software for it better. Please let us know any ideas or suggestions you may have, and any problems you encounter in trying to use the emulator.