Groundwork for BACKTRACK support

BACKTRACK support is (or rather, will be) a feature of the PCjs Debugger that makes it possible to track the sources of memory contents.

Part of the support for this feature comes from the Disk module, which is now able to read FAT volumes and create sector-to-file mappings. Next, the DMA component (part of the ChipSet module), which is involved in sector transfers from diskettes (and XT hard disks) to memory, creates byte-to-sector mappings. With these pieces in place, the Debugger will be able to "backtrack" the contents of any memory location containing file data to the original file name and position.

BACKTRACK support will include additional backtracking features (more than just file tracking) so stay tuned. For now, it's disabled in all compiled releases, as it currently serves no purpose in the non-DEBUGGER release, and even in the DEBUGGER release, there are no new Debugger commands (yet) to take advantage of it. The support is available only if you download/install/run the uncompiled PCjs code.

As you can imagine, this is a somewhat "expensive" feature, both in terms of increased memory requirements and operational overhead, so it will be a feature you must explicitly enable. On most machines, however, the overhead shouldn't be noticeable, and the simulations should still run fine at normal speed.

Keyboard module improvements

No new real features, just some much-needed code cleanup in the Keyboard module. I'm aware of a few regressions, but they're mostly related to "soft keyboards" (eg, support for upper and lower case). Soft keyboard support is overdue for some attention anyway.

The important thing is that all key handling, whether from actual key events or from the various ways in which keys and key combinations can be simulated, is now funneled through a simple set of methods (eg, addActiveKey(), updateActiveKey(), removeActiveKey()) which in turn call keySimulate() to simulate all the necessary "make" and "break" scan codes.

This fixes a number of obscure bugs (eg, different results depending on whether a CTRL-[character] sequence released the CTRL key first or the [character] key first, and the failure of many keys to repeat properly).

The new code will also make it much easier to implement programmable repeat delay/rate for PC AT keyboards. Currently, repeat delay and repeat rate are hard-coded with the PC XT keyboard defaults of 0.5sec and 0.1sec, respectively.

In the course of debugging the new Keyboard module, I also uncovered some hidden bugs in the 8042 code of the Chipset module. The most severe was that the "break" code for a completed key press was not being delivered until the beginning of the next key press; it's surprising that the PC AT configurations worked at all. The interface between the 8042 code and the Keyboard module has been cleaned up a bit, and that bug should be fixed now.

Improved drawing speed on desktop Safari

As described in this PCjs blog post, Canvas drawing performance in desktop Safari v8.0 suffers significantly if the Canvas is marked "contenteditable" and has focus. Safari is probably doing something silly, like trying to mask an (invisible) cursor that a normal "contenteditable" control might have but which Canvas objects should not have.

Whatever the reason, placing a transparent <textarea> on top of the Canvas for all input operations and removing the "contenteditable" attribute from the Canvas seems to solve the problem. Performance in other browsers (eg, Chrome) seems unaffected.

OS/2 1.0 is now supported

OS/2 1.0 now runs in selected IBM PC AT (80286) configurations.

There are still lingering problems, the most severe being the inability to complete a hard disk installation from OS/2 install diskettes. So for the time being, only selected OS/2 1.0 boot disks can be used. See this blog post for details.

In general, all OS/2 floppy and hard disk I/O seems to be working fine — the first diskette successfully formats the hard disk, copies all its files over, reboots from the hard disk, and then starts copying files from the next installation diskette. But usually on either diskette 2 or diskette 3, the copy process just silently stops and never completes.

UPDATE: The "incomplete installation" problem may just be one symptom of a more general problem, where any machine running OS/2 for a significant period of time becomes unresponsive (or faults). Since the OS/2 installation process is rather lengthy, this is probably just one of many ways to reproduce a particular PCjs bug. Under investigation.

More 80286 protected-mode support

This release includes limited support for 80286 call gates, interrupt gates, trap gates, and task gates.

Support for local disk images

It's now possible to select disk images on your local machine and load them directly into any PCjs machine.

It's important to note that this is not an "upload" operation. There is no server communication involved. When you load a local disk image with the new "Choose File" button, the image is loaded directly in the PCjs application running in your browser.

There were a variety of other fixes in this release, including some keyboard improvements (primarily for PC AT machines, but also some across-the-board improvements, like the ability to differentiate between left and right SHIFT keys), a work-around in the Mouse component for Microsoft serial mice, and a fix to the FDC component to generate the expected "Not ready" error when no diskette is loaded in a drive.

Simplified directory structure

The /configs folder has been folded into the /devices folder (or in some cases, the /apps and /disks folders), in an attempt to simplify the project structure.

The embedMachine() logic has also been improved. It no longer uses synchronous XMLHttpRequest calls, and it provides more feedback during the embed operation, making it easier to diagnose failures. None of this will make your machines load any faster, but all the browsers seem to be racing to deprecate (and eventually disallow) synchronous XMLHttpRequests, so it seemed prudent to tackle this issue sooner rather than later.

A few new features slipped into PCjs as well, including a working 80286 LOADALL instruction; it's been tested in real-mode (RAMDRIVE.SYS in PC-DOS 7.00 appears to work fine), but it has not yet been tested in protected-mode.

Limited support for XDF disk images

This release includes support for XDF disk images (specifically, the XDF disk images that were shipped with PC-DOS 7.00).

However, this support is referred to as "fake" XDF support, because it requires using JSON disk images created by DiskDump without the experimental "--xdf" option, which is an option that attempts to encode XDF sectors as they existed on the original diskettes (ie, with varying lengths and non-standard sector IDs).

"Fake" XDF support works by using conventional 80-track disk images with 23 sectors/track. No standard PC floppy disk format ever used 23 sectors/track, but in this case, by distributing the XDF track data across 23 conventional 512-byte sectors, the PC-DOS 7.00 Setup code that reads XDF disks succeeds. This was probably one of several fall-back options built into the PC-DOS XDF code.

Improved PC-DOS 7.00 Support

This is a fairly minor update that fixes a few Floppy Disk Controller (FDC) issues and one CPU emulation bug that prevented PC-DOS 7.00 from working properly.

There are also some Debugger improvements; for example, if you turn on "fdc" and "int" messages in the Debugger using the "m fdc on" and "m int on" commands, all FDC (INT 0x13) software interrupts will be logged, including descriptions and register values.

PC-DOS 7.00 still can't be setup from its non-standard 1.84Mb XDF distribution disk images, "PC-DOS 7.00 (SETUP Disk 2)" through "PC-DOS 7.00 (SETUP Disk 5)", so your best bet is to boot from the "PC-DOS 7.00 (1.44Mb Disk)".

Note that you must use a fairly new 80286 machine configuration, like this 8Mhz IBM PC AT, in order to use 1.44Mb diskette images; previous models did not support 3.5-inch diskette drives, unless they had been retrofitted with a newer BIOS.

Improved support for PC AT machines

Specifically, machines with the "Rev3" AT BIOS, dated 11/15/85.

• The BIOS expected memory refresh to occur roughly every 16us, which I've resolved by tying the state of the refresh bit in port 0x61 to bit 6 of the CPU cycle count (see in8042RWReg() in chipset.js); the original AT BIOS was satisfied with a refresh bit that merely alternated, whereas the new AT BIOS is much more particular about the rate at which that bit changes, since many hard-coded delay-loops have now been replaced with code that waits for a specific number of refresh cycles.
• The 8042 Keyboard Controller emulation needed a few more tweaks, mainly with respect to what happens when the keyboard's "clock" line is toggled (see set8042CmdData() in chipset.js).
• The Floppy Disk Controller needed to add support for the "READ ID" command, in order for the BIOS "double-stepping" test to work (double-stepping is required on an 80-track drive when attempting to read a 40-track diskette).
• The BIOS Diskette Reset function does something odd after resetting the Floppy Disk Controller: it issues not one but four "SENSE INTERRUPT STATUS" commands to the FDC, and expects each response to return an incrementally larger drive number. I found this a bit mystifying, considering that IBM's own FDC/HDC "combo card" supports a maximum of two diskette drives. But, there's no point arguing with a BIOS that's almost 30 years old.
• The BIOS attempts to detect what its authors must have considered a common problem: a user's failure to run SETUP after installing a second hard drive. So, when the CMOS reports only one hard drive installed, the BIOS probes for a second hard drive anyway, and it does so by simply writing the drive number to the ATC's "DRVHD" register and then immediately reading the "STATUS" register, without issuing any intervening command. It was an easy fix to outATCDrvHd() in hdc.js, but I was surprised to discover that the ATC had this behavior, and now I'm wondering if there are any other I/O operations that must immediately update the "STATUS" register.

This PCjs release also fixes a problem reported by a user: if you disable localStorage support in your browser, previous versions would fault. I knew that every browser that supports PCjs also supports localStorage, but I didn't consider what might happen if a user had decided to turn it off.

The only downside to turning off localStorage is that none of your PCjs machines will be able save/restore their state when you leave/return to the page, so they will always reboot.

Browser's don't always refer to the localStorage feature by its actual name, either. For example, in Chrome, the setting that enables/disables localStorage is hidden under "Advanced Settings" => "Privacy" => "Content Settings" => "Cookies" => "Allow local data to be set (recommended)". Which is somewhat misleading and a little annoying, because localStorage is not a cookie.

PCjs never sets any cookies. Cookies are bits of data that your browser saves and then automatically sends off to the server every time you make a request. localStorage is nothing more than local storage; it is not automatically sent anywhere. Granted, a JavaScript application could abuse it and send it out just like a cookie, but PCjs does not do that; the only exception is when PCjs detects a problem, and even then, you must first agree to submit your machine's state as part of the bug report.