Pcjs.v1 Versions Save

This release enables PCjs machines to virtually connect to each other's serial ports.

Specifically, any virtual PCx86 COM port can be connected to any other virtual PCx86 COM port, or to a virtual VT100 serial port.

The latest blog post includes a demonstration of the latter. Two VT100 terminals can be connected as well.

Work is largely finished (for now) on the latest PCjs machine simulation: the original DEC VT100 Terminal.

Most (nearly all) VT100 emulators are really just ANSI Escape Code emulators, whereas we are emulating the original VT100 firmware, along with elements of the original hardware architecture. Features you probably won't find in other emulators include:

• Font from the original VT100 font ROM
• Double-wide and double-high characters
• 80/132 column support
• Smooth scrolling (once you've enabled it on the SET-UP B screen)

There's no AVO support yet, so 132-column mode is limited to 14 lines instead of the usual 24. AVO support will probably be the next major feature we implement.

You must change the terminal from ONLINE to LOCAL mode to type anything on its screen (or you can press the TEST RECEIVER button). Alternatively, you can play with the Dual VT100 Terminal Demo, which demonstrates two virtually connected terminals; anything you type into one should appear on the other.

Over time, you can expect to see more PCjs machine demos appearing on the site that make use of one or more VT100 terminals alongside other machines, highlighting their ability to drive serial terminals in multi-user and/or multi-display environments.

Stay tuned!

This release (v1.23.2) was created simply to fix a problem with one of the Debugger commands in the PCx86 emulator; specifically, the Load ("L") command. When I changed one of the Disk Controller interfaces, I neglected to update the Debugger, so the Load command had been completely broken for a while.

What is the Load command, you ask? It's similar to the "L" command in the DOS DEBUG utility, which loads sector(s) from a disk into memory. For example, L 0:7C00 0 0 1 loads the contents of drive 0, sector 0 (for a total of 1 sector) into memory at address 0000:7C00 -- which is exactly what the ROM BIOS does when attempting to load and execute the boot sector from a disk in drive A.

After issuing that command, you could in theory set the CS register to 0 and the IP register to 7C00 and start executing the boot sector with the "G" command. However, unless you've let the ROM BIOS run first, the interrupt vector table (IVT) and ROM BIOS data areas will not be properly initialized, so your attempt to manually load and execute the boot sector will likely crash and burn.

PCjs now refers to the project (the repository and website), while PCx86 refers to the IBM PC-based emulator. Previously, both were called PCjs.

PCx86 is now just one of several PCjs emulators:

• C1Pjs
• PC8080
• PCx86

Ultimately, C1Pjs will become PC6502, and Challenger 1P machines will become a PC6502 machine type. And everything doesn't need to end with "js". It's 2016 now, and that naming convention seems a bit overdone.

As part of this change, all the "pc" folders within /disks, /devices, and /docs have become "pcx86" folders, to make it clearer that they're associated with the PCx86 emulator. I've added redirects for all the old "pc" URLs, but inevitably I'll probably discover the need for more redirects.

This was the week of The Sharpening.

A while back, I updated most of the machines to use higher-resolution "screens". For example, a typical EGA video configuration now specifies a screenWidth of 1280 and screenHeight of 700, dimensions which are exactly twice the standard EGA resolution.

That change had no effect on the machine's operation, but it did improve the machine's appearance, because most people are using much higher resolution monitors today, so by using a higher-resolution "screen" (canvas), less interpolation is happening when a machine's screen image is scaled up to fill your browser window.

The amount of scaling also depends on whether the machine allows itself to be stretched to fill the browser window. For example, this machine (used by the EGA Machine Array Demo) is limited to an overall width of 680 pixels, no matter how large you make your browser window:

<machine id="ibm5160" class="pc" border="1" width="680px" float="left" background="#FAEBD7">

but most machines don't specify a (maximum) overall width, so their screen canvas is allowed to stretch far beyond the initial screenWidth and screenHeight, thanks to some additional CSS settings.

Larger screens mean less interpolation, which is a good thing if you want the screens to look less "fuzzy." However, interpolation also happens at a deeper level, because internally, PCjs uses two canvases to move pixels from the machine's frame buffer to your browser: the screen canvas, which I've already discussed, and another canvas called the buffer canvas, where changes to the machine's frame buffer are, um, buffered.

The buffer canvas has the same dimensions as the machine's frame buffer, whereas the screen canvas has generally higher dimensions (as explained above), which your browser may then be stretching to even higher dimensions, depending on your monitor resolution and browser size.

The differential between the buffer canvas and screen canvas is where additional interpolation (fuzziness) creeps in. That is where The Sharpening now occurs.

All the browsers I've tested so far (Chrome, Firefox, and Safari) support a Canvas Context property named imageSmoothingEnabled, which eliminates much of the fuzziness that would occur when copying pixels from the lower-resolution buffer canvas to the higher-resolution screen canvas.

So I've added a new Video property named smoothing that can be set to "true" or "false", and I've set it to "false" for most machines in the project. If smoothing is not set, your browser continues to use its default interpolation method.

For some people, this might be a matter of taste, because less fuzziness necessarily means more pixelation (ie, you can see individual pixels more clearly), which becomes more noticeable when switching a machine Full Screen. So I've also added a URL smoothing parameter you can use to override a machine's default setting; eg:

http://www.pcjs.org/devices/pc8080/machine/invaders/?smoothing=true

PC8080, a new CPU emulator/machine simulator, has now officially been added to the PCjs/JavaScript Machines roster. There's not a lot to see at the moment, other than the fact that our first PC8080 Test Machine passes the fairly stringent 8080 Exerciser tests.

PC8080 springs to life as v1.21.7, along with PCjs and C1Pjs, only because I don't feel like maintaining separate version numbers for every component in the project.

As for PCjs, there always seem to be a few tweaks:

• The list of disks available to a machine are now sorted by name (unless the FDC component's new "sortBy" attribute specifies "path" or "none" instead of "name");
• Control Panels that include a live register display should work properly now (this was a recent regression);
• The DAA/DAS instructions have been updated to correct some apparent omissions in the original implementation, discovered while working on PC8080. But I'll be honest with you: they have not been tested across the gamut of CPUs (8088, 80186, 80286, and 80386) that PCjs emulates. That needs to be done one of these days.

That's all for now!

This release "fills out" the Disk Library portion of the project with more (and updated) README files, making the project slightly easier to browse.

Also, a new disk image has been added: the "Enhanced DEBUG 1.32" diskette, which is discussed here.

There are "virtually" no changes to the emulators, except to restrict the new aspect URL parameter to reasonable values (ie, 0.3 <= aspect <= 3.33).

This release provides more consistent aspect ratios for all the display configurations used by all PCjs predefined machines. The MDA and CGA configurations now use a 1.6 aspect ratio, EGA configs use 1.83, and VGA configs use 1.33. These values are not based on extensive scientific research of early PC monitor and video card characteristics -- I leave that exercise for another day and/or another developer more motivated than me -- but rather on a combination of each card's maximum resolution and what "looks good."

Aspect ratio is display width divided by display height, but the choice of aspect ratio is complicated by the fact that none of the early IBM video card/monitor combinations (with the exception of the VGA) displayed square pixels, and (with the exception of the MDA) they could display text and graphics at a variety of resolutions. Moreover, it's difficult if not impossible for a web app to determine your current monitor's aspect ratio.

So, for those users who either 1) don't like the aspect ratios that PCjs has chosen, or 2) just want to squeeze or stretch a machine's screen a bit more, there is now an experimental aspect parameter you can append to the URL of any page containing one or more PCjs machines.

For example:

http://www.pcjs.org/disks/pc/dos/ibm/1.00/?aspect=2.0

will modify the height of the machine's screen to conform to the requested aspect ratio of 2.0. The screen should still be responsive to any browser resizing while still retaining that aspect ratio.

In addition, CGA 40-column video modes are now scaled to fill the screen, provided scale="true" is set in the machine's <video> configuration element.

Finally, I also made some tweaks to the website, as GitHub Pages renders it. Pages now display breadcrumbs, in the form of a DOS directory string, to give you a better sense of where you are within the site. Unfortunately, not all folders contain a README (yet), so some intermediate folders may take you to the generic "Page Not Found" page, but I'll get everything tidied up someday.

I've also replaced the google-analytics.html file in the master branch with an empty file, so that if other folks clone the repository and fire up a local copy of the Jekyll web server, their requests won't be pinging Google.

There are probably other files like that (i.e., files, or contents of files, that should only exist in the gh-pages branch), and I've tried to start addressing this by creating a .gitattributes file:

_includes/google-analytics.html merge=ours

and updating my git config:

git config --global merge.ours.driver true

but it remains to be seen if future merges of master into gh-pages will actually preserve files like google-analytics.html. It certainly didn't on my first attempt, but there's some speculation that "fast-forward" merges don't go through the merge driver process. Obviously, this is something I'll have to keep an eye on.

---

Oh, one more thing: I added a "Save HD" button to selected machines, as an experimental means of saving a machine's hard disk, presumably after you've made changes that you want to keep. There's currently no way for you to upload an entire hard disk image to a machine, so the main use for this feature is to mount the hard disk image (.IMG file) on your local operating system.

I've tested the "Save HD" feature in Firefox, and it works well. Chrome, not so well (the download fails with a less-than-useful "Network Error" message). However, I'm using Chrome Canary, so perhaps older, more stable releases work better.

This release is another hodge-podge set of changes:

• Refactored DIP switch management
• Fixed video page flipping (including cursor display)
• Added 43-line and 50-line support to VGA
• FIxed floppy-only 5170 machines when using newer ROMs

DIP switch mappings now use model-specific tables to map functionality to switches, and all switch operations now go through a well-defined set of methods, instead of using hard-coded switch bit-masks. This should make any future support for additional IBM PC clones a "bit" cleaner.

Page-flipping worked before, but when a change was made to "latch" the new page address only during vertical retrace intervals (so that certain animation tests would work properly), that change made it possible for some flips to be ignored until another event triggered a screen update. In addition, the text-mode cursor was not being redrawn for non-zero pages.

I also added a few MDA and CGA machine configurations for the IBM PC AT (previously, I had only EGA and VGA configurations). This proved to be another useful test of the new DIP switch logic, because the AT did away with most DIP switches, except for a single "Display Switch" on the motherboard to indicate whether the primary monitor was a Color or Monochrome display.

And, since I also happened to create those new PC AT configurations as "Floppy-only" machines, that revealed an unexpected problem with 2 of the 3 PC AT ROMs, resulting in a "601-Diskette Error." Adding a port handler for an undocumented FDC "Diagnostic Register" (port 0x3F1) resolved the problem.

This release adds limited (but growing) support for more IBM-compatible machines, such as:

• AT&T Personal Computer 6300
• Columbia Data Products MPC 1600
• Zenith Data Systems Z-150

The MPC 1600 is noteworthy because it was the first genuinely IBM-compatible machine, predating the COMPAQ Portable. But being first to a party is no guarantee of success, which COMPAQ went on to enjoy for many years, while Columbia Data Products fizzled into oblivion after only a few years.

The complete list of supported machines is at http://www.pcjs.org/devices/pc/machine/.

This release also incorporates enhancements to the savePC() and getResource() interfaces, courtesy of pull requests #31 and #32.