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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
