PCjs Machines 1.0 (archived)
PC8080 and PDPjs already included a set of timer services to make it easier for those machines to simulate hardware features like serial port baud rate, so it seemed like a good time to port those services to PCx86 as well. I haven't updated the PCx86 ChipSet or SerialPort components yet, but the new services are already being used to:
The key services are:
Using the timer index from a previous addTimer() call, setTimer() sets that timer to fire after the specified number of milliseconds. This is preferred over JavaScript's setTimeout(), because all our timers are effectively paused when the CPU is paused (eg, when the Debugger halts execution). Moreover, setTimeout() handlers only run after runCPU() yields, which is far too granular for some components (eg, when the SerialPort tries to simulate interrupts at 9600 baud).
Also included in this release:
To see the new scripting support in action, take a look at the demo machine for TopView 1.01. The README.md defines several scripts at the top of the page:
machineScripts:
startKbd: |
wait Keyboard DOS;
type Keyboard "$date\r$time\rB:\rTV\r";
startMouse: |
wait Keyboard DOS;
type Keyboard "$date\r$time\r";
wait Keyboard;
sleep 1000;
select FDC listDrives "A:";
select FDC listDisks "MS Mouse 5.00 (System)";
loadDisk FDC;
wait FDC;
type Keyboard "MOUSE\r";
sleep 5000;
type Keyboard "B:\rTV\r";
The machine is currently currently configured to use the "startKbd" script:
machines:
- id: ibm5160
type: pcx86
config: /devices/pcx86/machine/5160/cga/640kb/machine.xml
autoMount:
A:
path: /disks/pcx86/dos/ibm/2.00/PCDOS200-DISK1.json
B:
path: /disks/pcx86/apps/ibm/topview/1.01/TOPVIEW101-PROGRAM.json
autoScript: startKbd
This release of PCjs implements FLICKERING.
Yes, the beloved flicker of the original IBM Color Graphics Adapter, or CGA. And I’m not talking about the barely perceptible flicker produced by the CGA monitor’s 60Hz refresh rate. That flicker was tolerable. In fact, many people who didn’t need either color or graphics would opt for IBM’s Monochrome Display Adapter, or MDA, because the green phosphor of IBM’s monochrome monitor had such high persistence that the 60Hz refresh rate was virtually imperceptible.
No, the capital-letter FLICKER that I’m talking about was a side-effect of what IBM’s ROM BIOS did every time the CGA’s screen had to be scrolled: completely turn off the video signal OFF, rearrange the contents of video memory, and then turn the video signal back ON. IBM adopted this approach because otherwise you would see an even worse effect: random video interference or “snow”.
This all came about because the CGA’s memory wasn’t “dual-ported”: if the CPU accessed the CGA’s memory at the same that the display hardware was accessing it (to refresh the screen 60 times per second), the CPU would win and the display hardware would lose, resulting in garbage appearing on the screen for a brief instant.
PC software could avoid that conflict by waiting until the CGA hardware was in a retrace period: either the brief horizontal retrace period that occurs as the CRT repositions the electron beam from the right side of the screen back to the left side, or the slightly longer vertical retrace period that involves moving the beam from the bottom to the top.
However, IBM decided that, since neither of those retrace periods were long enough to perform a full-screen scroll, the easiest solution was to simply turn the screen off for the duration. The result, which many of us suffered with for years, was FLICKER.
One of those interesting solutions was a program from 1986 called FlickerFree, the purpose and value of which would be almost completely lost on someone today if they had never seen or used an original IBM PC with a CGA.
In fact, FlickerFree proved to be a useful PCjs test case, because it relied on a quirk of CGA hardware that I hadn’t originally implemented: frame buffer wrap-around. FlickerFree resolved the flickering-scroll problem by treating the CGA’s 16Kb of video memory as a giant ring buffer: instead of moving the contents of video memory “upward”, like IBM’s ROM BIOS did, FlickerFree would simply shift the video memory start address “downward”. After all, one 25x80 screen of character data required only 4000 bytes, and the CGA had 16,384 bytes of memory.
At first glance, that approach would seem to merely delay the inevitable, because when the start address nears the end of the buffer, the entire buffer still has to be scrolled. But, as it turned out, the CGA’s CRT controller starts reading from the top of video memory after it reaches the bottom. So all software has to do is write new lines at the top of the video memory again. If IBM had thought of that trick 5 years earlier, back in 1981, think of all the years of shared flicker-grief that could have been avoided!
Today, in honor of all that flickering, I’m pleased to announce that PCx86 now offers FLICKERING on all IBM PC Color Graphics configurations. If you feel the need to override it, you can add flicker=0 to the URL of your favorite machine; e.g.:
In fact, you can set the flicker property to any value from 0 to 1; the default is 0.5. This value is applied to the opacity property of the PCx86 <canvas> element, allowing you to mimic whatever degree of “phosphorescent persistence” you prefer.
You can thank me later.
PCx86 machines can now use their screens to display startup and progress messages while the machine is in "initialization" mode. Once the machine has been fully initialized and all its resources have been completely downloaded, control of the screen returns to the Video component.
This does not affect PCx86 machines with a separate text area as part of a Control Panel interface; the separate text area continues to be used for all startup and progress messages.
Other machines modules (eg, PC8080, PDPjs, etc) will probably be updated with similar support in the near future.
Obviously, I don't do enough regression testing. I need to have a talk with all my clones.
The Computer interface getMachineParm() is great for obtaining machine properties from multiple sources (eg, the XML file, the web page, or the URL), but in the case of the state property, any state file setting was only supposed to override the machine's resume setting if state was set expressly via URL, not when it was set as the normal part of a machine's configuration. I've fixed that now, so you can once again stop and resume a DONKEY.BAS game to your heart's content.
While we're on the subject of "resume": I finally tracked down and fixed an annoying resume bug in the original MDA and CGA configurations. If any of those configurations set the resume property AND you reset the machine, the cursor's "blink state" state might not be properly initialized, so you would no longer see a cursor. Another video regression involved the failure of MDA/CGA machines to display their screen immediately after a restore; this was due to some EGA/VGA changes that were probably made a year or more ago, now fixed.
Also, if you're impatient, like I sometimes am, and you switched away from a page before any machines on that page finished loading, you could get spurious errors. Well, maybe spurious is the wrong word: the errors were legitimate, but they were basically all "don't care." And these errors could occur both on the "shutdown" of the machine as well as the "startup", if the machine's resume property was set.
I've tried to eliminate most of those "don't care" notices by 1) adding an "unloading" flag that indicates when a machine is unloading and suppressing notices when that flag is set; 2) suppressing notices whenever the resume property is AUTO (1); and 3) suppressing notices whenever an XmlHttpRequest failed due to an unknown error (usually an indication that the error is simply the result of the user cancelling the page load, not because of any problem with the server).
To properly set the "unloading" flag on iOS devices, I also had to change my 'exit' page handler to rely on the browser's "pagehide" event rather than the traditional "unload" or "beforeunload" events. In fact, the PCjs resume feature wasn't working on iOS devices AT ALL until I made this change. This used to work, but as Apple Documentation explains, "unload" has been deprecated in favor of "pagehide". Now, of course, deprecated doesn't mean unsupported (yet), but perhaps that documentation is out-of-date and Apple finally decided to pull some plug.
In other news, autoType support has been improved: autoType strings no longer need to use double-backslashes to encode \r, \n, \t, or \x sequences, and some new replacement variables ($date and $time) can now be used to auto-type your way through the traditional DOS date and time prompts.
There have also been a few site-related changes, like the addition of a default background color for all machines, and changing most machine XML files on the site to specify "default". Since most of a machine's appearance is its "screen", this mainly affects a machine's border and control panel region (if any).
As this PCjs blog post explains, and as the Adventures in Math page documents, another PC application has been archived, along with a few PCx86 tweaks to make demonstrations of original distribution software a little easier to construct.
In particular, "autoType" is now a supported machine property that can be used to inject a series of keyboard commands into a machine once it is "ready". Various signals will be used to determine a machine's readiness, but the initial signal is a DOS buffered input call (INT 0x21, AH=0x0A).
In honor of MACRO-10's 50th anniversary (sort of), PDPjs now includes a built-in MACRO-10 "Mini-Assembler." Details are in the blog.
This release introduces another PCjs emulator: PDPjs for the PDP-10.
Although I'd like to say that the PDP-10 emulator builds on my recent experience writing a PDP-11 emulator, the architectures are actually quite different. Although the PDP-10 (1968) was released only a couple of years before the PDP-11 (1970), the PDP-10 is really just an extension of the PDP-6's 36-bit architecture, which was designed in 1963 and released in 1964.
And a number of conventions we've come to expect today weren't conventions in the early 1960's. For example, DEC numbers the bits of their 36-bit words from left-to-right, with bit 0 being the most significant bit and bit 35 the least significant. Another oddity: 36-bit multiplication produces 72-bit results, but they contain only 70 bits of magnitude with 2 matching sign bits -- a format that was presumably more convenient for the hardware designers.
I'm sure I'll discover more oddities over time, because the PDP-10 emulator is far from complete. At this point, the only instructions it supports are "Half Word" move instructions, along with all their many variations. The built-in debugger is where I've invested most of my efforts so far, which includes a fully functional disassembler and assembler.
More details can be found in the PCjs Blog.
PDPjs now supports the RX11 controller in combination with RX01 disk drives (named DX0 and DX1), providing read/write/boot support for 250Kb RX01 diskettes.
The RX11 is a somewhat unusual disk controller: unlike the RK11 and RL11 disk controllers, all I/O must be programmed; there is no DMA support. It also does something odd on initialization: it automatically reads the FIRST sector of the SECOND track (Track 1, Sector 1) of any diskette in drive DX0.
This makes RX11 bootstrap code very simple, because it doesn't have to issue a READ command. All it has to do issue an EMPTY command to "empty" the contents of the controller's sector buffer into memory and execute it. However, I'm concerned that the RX11 documentation doesn't enumerate all the conditions that trigger this initialization process.
For example, if you turn your PDP-11 on, enter the RX11 bootstrap code, and then insert a diskette into drive DX0, does the controller re-initialize itself? Since the RX11 has a special "Initialize" bit in its Command and Status register, it would seem trivial for the bootstrap code to re-initialize the controller, but DEC's RX11 bootstrap doesn't do that.
That question is moot for PDPjs, because whenever the DriveController component finishes loading a diskette, it notifies the RX11 component, and if the drive is DX0, it re-initializes the controller, triggering the automatic read of Track 1, Sector 1.
In other news, the Paper Tape Controller (PC11) can now be used to read external files into a machine. For example, in RT-11, the command "COPY PC: FILE.DAT" will copy the entire contents of any file currently loaded in the Paper Tape Reader. Eventually, support will also be added for the Paper Tape Punch device, so that you can also "COPY FILE.DAT PC:" and then save the resulting data as an external file on your host computer. Until then, the PC11 component is technically just a PR11 (Paper Tape Reader).
This release marks the complete adoption of ES6 classes in all PCjs emulators. Details are in this blog post.
PDP-11 machines (or pages containing PDP-11 machines) can now be marked with a resume property that will (like PCx86 machines) use your browser's local storage to save and restore the machine's state.
For example, if you start this PDP-11/70, load a different disk in the RK0 drive, such as the "RT-11" disk, boot it, make changes to the disk, run programs like ADVENT, and so on, all those changes should be restored when you visit the page later. The PC8080 machine running the VT100 Terminal simulation also supports save/restore, so the contents of the display connected to the PDP-11/70 should be saved and restored, too.
It's entirely possible there are still a few bits of machine state that are not fully preserved yet, but if it's not perfect, it's certainly close.