This is Paul Kimpel with another guest post on Tom's 205 and 220 blog. Version 1.01 consists of bug fixes, internal enhancements, and a few new features that are externally visible. This post will describe those changes.
The thing that everyone who uses the retro-205 emulator needs to know about this release is that the way you "power off" and shut down the emulator has changed. Previously, a single click of the red OFF button on the Supervisory Panel would terminate the emulator and close all of its windows, leaving only the original browser window with the home page open on your screen.
Now, the OFF button requires a double-click to shut down the emulator. If you hover over the button with your cursor, a tool-tip will pop up to remind you. This behavior has been adopted from the retro-220 emulator, where the power-off and system-clear buttons are close together. I was frequently clicking power-off when I intended to click the clear button, so added the double-click as a safety measure. It seems reasonable to make this behavior consistent between the two emulators.
Memory Dump Generation
The emulator now supports a memory-dump capability. On the Supervisory Panel, below the D register, is a section labeled TEST SYSTEM. The controls in this section have been non-functional in the emulator, as they affected the 205 electronics at a level below which the emulator operates.
|Supervisory Panel TEST SYSTEM section|
Now, clicking the SINGLE PULSE button in the upper-right corner of this section will cause the emulator to open a sub-window and format the current processor state and memory contents to that window. You can generate this dump at any time, even while the emulator is running a program. It will show an instantaneous snapshot of the system state at that point in time.
|SINGLE-PULSE Button Memory Dump|
From this window, you can copy, save, or print the dump using the standard facilities in your browser for doing so. You can click the button multiple times to generate multiple dumps, each in its own window. When you are finished with a dump, simply close its window.
Apple Safari Pop-up Restrictions
This next item could be qualified as a bug fix, but it's really a new feature. The emulator had been operating quite will in the three major modern workstation browsers -- Google Chrome, Mozilla Firefox, and Apple Safari. I recently updated my MacBook Air to macOS 10.13 (High Sierra), and with that update came Safari 11.0.
Trying to run the retro-220 emulator in Safari after this update resulted in the emulator crashing after opening its first pop-up window. I quickly discovered that the retro-b5500 and retro-205 emulators suffered the same problem. I had Safari configured to allow pop-ups, so what gives?
Some research revealed that this new version of Safari places additional restrictions on pop-up windows. Specifically, it would always allow the first pop-up, but if subsequent pop-ups were opened before some amount of time had passed, Safari would inhibit the pop-up. Reports varied on the amount of time that had to elapse between opens, ranging upward from 500ms.
Now, each object calls a common "open pop-up" function in the D205Util.js module, passing parameters necessary to open and configure the window. In addition, each object passes a reference to its "onload" event handler that should be called once the browser opens the window and loads its initial content. These parameters are bundled into a data structure, and that structure is inserted into a queue of pop-up open requests. If the queue was previously empty, the open function calls another function to dequeue and process the first (and in this case, only) entry in the queue. If the queue was not previously empty, then processing of the queue is known to be on-going, and the open function simply exits.
Once the dequeue function obtains a successful window-open result, it attaches the original caller's onload event handler to the window. After the browser finishes loading the window, it will call this handler, which will complete the initialization of the console or peripheral device object. Finally, and unless the queue is now empty, the dequeue function reschedules itself using the current timeout period to process the next entry in the queue.
This new mechanism works extremely well. It automatically adjusts the delay between opens based on the individual browser's behavior. The initial timeout value is 500ms and increments by 250ms on each iteration of a failed open. My tests indicate that Safari 11.0 starts making nice when the timeout reaches 1000ms. Chrome and Firefox both cruise through pop-up opens, because their open attempts do not fail, thus nothing ever gets queued, so the opens proceed without any delay.
The following problems have been corrected in the emulator:
- Floating-point addition/subtraction was producing the wrong result if the mantissa of either operand was zero. Thanks to Tom Sawyer for finding and reporting this problem.
- During floating-point divide, the quotient mantissa was not being normalized properly.
- If a magnetic tape operation was initiated against a not-ready unit, the Processor's internal performance throttling mechanism could become corrupted, causing the emulator to run erratically.
- The Designated Unit lamps on Cardatron devices were not always being illuminated properly.
- Changes to the Format Select control on Cardatron input devices (card readers), an emulator feature that allows the band-select column on cards to be overridden, were not being detected properly. This usually rendered that control non-functional.
- Format-Lockout for Cardatron input devices was not working when there was a simulated 8-punch in the band selection column of the card. See the Cardatron wiki page for details on how simulated 8-punch coding is implemented in this emulator.
- Skip-to-channel carriage control on Cardatron printer devices did not always work properly, depending on the carriage control being applied on the next write to the device.
- Several 205 devices display output from the system in windows or frames, and allow you to save or print the data using standard browser controls. The common document used for these windows and frames contained extraneous white-space, which resulted in blank lines before and after the actual output. This extraneous white-space has been eliminated.
The following summarizes the most important of these internal enhancements for version 1.01:
- A common operation in web programming is to manipulate the list of CSS class names in a DOM element's className property. Traditionally this has been done using simple regular expressions, but the modern DOM treats the className property as a classList object, which has intrinsic methods to add, remove, and test for the presence of specific class names. These classList methods are now used in the emulator.
- Data transfers between memory and card devices are controlled by format band programming in the Cardatron. Because of this, the Cardatron controls how much data is transferred. Thus it must signal the Processor when the transfer is complete so that the Processor can terminate that I/O instruction and continue execution. The way this signal was being passed to the Processor during card-read operations was not particularly reliable, and has been improved.
- The setCallback() function used to manage asynchronous functions in the emulator seems to be forever undergoing refinement. Some additional tuning changes were made in this release.