Link updates

This commit is contained in:
Jeff Parsons 2016-05-23 14:14:42 -07:00
commit d29ef36ea1
30 changed files with 84 additions and 66 deletions

View file

@ -11,7 +11,7 @@ are simple XML files that describe a piece of software (an application, an opera
link to a PCjs machine configuration capable of running the software, along with a "ready-to-run" machine state file.
Conversely, a PCjs machine XML file can refer back to the manifest, to obtain a list of disk images.
Here are some [demos](/apps/pc/) of "ready-to-run" apps on [PCjs](/docs/about/pcjs/).
Here are some [Demos](/apps/pc/) of "ready-to-run" apps on [PCjs](/docs/about/).
There have been lots of server-side changes recently, including API improvements that make it easy (well, *easier*)
to dynamically create diskette images from a list of files, or even an entire folder (including all subfolders),

View file

@ -55,8 +55,8 @@ There's still no support for [LOADALL](/pubs/pc/reference/intel/80286/loadall/)
call gates or task gates, nor for conforming code segments or expand-down data segments. 80286-specific cycle
counts haven't been incorporated yet, either. The list of remaining 80286 features is long.
And there's plenty of hardware support left to do: I haven't looked at the AT hard disk controller yet (which
I believe is significantly different from the XT hard disk controller), and the keyboard *barely* works; the 8042
And there's plenty of hardware support left to do: I haven't looked at the AT hard drive controller yet (which
I believe is significantly different from the XT hard drive controller), and the keyboard *barely* works; the 8042
Keyboard Controller and AT keyboard had a number of features that older PC/XT keyboards did not (like LEDs and
programmable repeat rate).

View file

@ -121,7 +121,7 @@ if (DEBUG) this.log('load("' + sFileURL + '")');
```
There are a number of other important shared constants in [/modules/shared/lib/defines.js](/modules/shared/lib/defines.js)
and PCjs-specific constants in [/modules/pcjs/lib/defines.js](/modules/pcjs/lib/defines.js); refer
and PCjs-specific constants in [/modules/pcx86/lib/defines.js](/modules/pcx86/lib/defines.js); refer
to those files for more information.
### Braces and Parentheses

View file

@ -17,7 +17,7 @@ can boot and run in real-mode now, but there's still a lot of protected-mode wor
this year is to boot OS/2 1.0.
There are also a lot of rough edges left to polish. Holes in EGA emulation remain to be filled (support for dynamically
loaded fonts is one of the bigger ones). And the PC AT Keyboard, along with the 8042 and Hard Disk controllers, are all
loaded fonts is one of the bigger ones). And the PC AT Keyboard, along with the 8042 and Hard Drive controllers, are all
just limping along at the moment.
Longer term, I'm looking forward to building some new tools, including an "IBM PC Configurator" that will take some

View file

@ -10,19 +10,19 @@ The [8Mhz IBM PC AT](/devices/pcx86/machine/5170/ega/1152kb/rev3/debugger/) mach
[PCjs v1.15.5](https://github.com/jeffpar/pcjs/releases/tag/v1.15.5), which includes the following fixes:
+ The BIOS expects 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](/modules/pcjs/lib/chipset.js));
of the refresh bit in port 0x61 to bit 6 of the CPU cycle count (see *in8042RWReg()* in [chipset.js](/modules/pcx86/lib/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](/modules/pcjs/lib/chipset.js)).
when the keyboard's "clock" line is toggled (see *set8042CmdData()* in [chipset.js](/modules/pcx86/lib/chipset.js)).
+ The Floppy Disk Controller needed to add support for the "READ ID" command, in order for the BIOS
+ The Floppy Drive 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
+ The BIOS Diskette Reset function does something odd after resetting the Floppy Drive 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
@ -32,7 +32,7 @@ with a BIOS that's almost 30 years old.
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](/modules/pcjs/lib/hdc.js), but I was surprised
It was an easy fix to *outATCDrvHd()* in [hdc.js](/modules/pcx86/lib/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.

View file

@ -7,7 +7,7 @@ permalink: /blog/2014/10/23/
---
[PCjs v1.15.6](https://github.com/jeffpar/pcjs/releases/tag/v1.15.6) 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](/disks/pcx86/dos/ibm/7.00/)
Floppy Drive Controller (FDC) issues and one CPU emulation bug that prevented [PC-DOS 7.00](/disks/pcx86/dos/ibm/7.00/)
from working properly.
There are also some Debugger improvements; for example, if you turn on "fdc" and "int" messages in the

View file

@ -14,7 +14,7 @@ machines:
PCx86 can now boot the [COMPAQ DeskPro 386/16 ROM BIOS](/devices/pcx86/rom/compaq/deskpro386/).
There's still a problem with the hard disk controller, which I haven't looked into yet,
There's still a problem with the Hard Drive Controller, which I haven't looked into yet,
but booting from a floppy works.
While working through issues with this ROM BIOS, I created some lightly-annotated

View file

@ -10,7 +10,7 @@ scripts: # the following list of scripts should mirror what /modules/diskdump/li
- /modules/shared/lib/diskapi.js
- /modules/shared/lib/dumpapi.js
- /modules/shared/lib/component.js
- /modules/pcjs/lib/x86.js
- /modules/pcx86/lib/x86.js
- /modules/diskdump/lib/diskdump.js
---

View file

@ -9,7 +9,7 @@ redirect_from:
IBM PC Application Archive
---
Below are selected [PCjs](/docs/about/pcjs/) demos of classic IBM PC applications:
Below are selected [PCx86](/docs/about/pcx86/) demos of classic IBM PC applications:
* [VisiCalc (1981)](1981/visicalc/)
* [Executive Suite (1982)](1982/esuite/)

View file

@ -18,4 +18,4 @@ All PCjs machines are built from the following collections of devices:
* [8086-based Devices](pcx86/) (e.g., [IBM PC, including 80286 and 80386-based compatibles](pcx86/machine/))
These devices are user-installable components that you would typically find in a real personal computer,
such as keyboards, disk controllers with one or more disk drives, video cards, etc.
such as keyboards, disk drive controllers with one or more drives, video cards, etc.

View file

@ -9,12 +9,14 @@ Challenger 1P Device Configurations
All our [Challenger 1P Machines](machine/) are built from a collection of devices, including:
* [Control Panel](panel/)
* CPU (6502)
* Debugger
* Floppy Drive Controller
* Keyboard
* RAM
* [ROMs](rom/)
* Keyboards
* [Video Resources](video/)
* Floppy Drive Controllers
* [Control Panels](panel/)
* [ROM](rom/)
* Serial Port
* [Video](video/)
The project also includes an assortment of Challenger 1P [Applications](/apps/c1p/) and [Disk Images](/disks/c1p/).

View file

@ -7,6 +7,9 @@ permalink: /devices/c1p/panel/
Challenger 1P Control Panels
---
A Control Panel is a collection of machine controls (e.g., buttons, register values, etc) bound to the *CPU* and
*Debugger* components and usually defined in a separate XML file.
The following C1P Control Panels are available:
- [default.xml](default.xml)

View file

@ -12,28 +12,32 @@ IBM PC Device Configurations
All our [IBM PC Machines](machine/) are built from a collection of devices, including:
* CPU (e.g., 8088, 80286, 80386)
* RAM
* [ROMs](rom/)
* ChipSets (e.g., 8259, 8253, 8237)
* [Keyboards](keyboard/)
* [Video Adapters](video/)
* Floppy Drive Controllers
* Hard Drive Controllers
* [Control Panels](panel/)
* [ChipSet](chipset/)
* [Control Panel](panel/)
* [CPU](/docs/pcx86/cpu/)
* [Debugger](/docs/pcx86/debugger/)
* [Floppy Drive Controller](/docs/pcx86/fdc/)
* [Hard Drive Controller](/docs/pcx86/hdc/)
* [Keyboard](keyboard/)
* [Mouse](/docs/pcx86/mouse/)
* [RAM](/docs/pcx86/ram/)
* [ROM](rom/)
* [Parallel Port](/docs/pcx86/parallel/)
* [Serial Port](/docs/pcx86/serial/)
* [Video](video/)
Each of those devices can be configured in multiple ways, and some support external UI controls.
For example, the IBM PC Keyboard component supports different keyboard models (eg, 83-key, 84-key, 101-key),
and each of those models can also be configured to have dedicated buttons for selected key combinations,
or even entire keyboard layouts.
For example, the IBM PC *[Keyboard](/docs/pcx86/keyboard/)* component supports different keyboard models
(eg, 83-key, 84-key, 101-key), and each of those models can also be configured to have dedicated buttons for
selected key combinations, or even entire keyboard layouts.
Complete machine configurations are constructed from those devices. A Machine Configuration is a single XML file
that lists all the device components to be used. A Machine XML file can choose to configure every device itself,
or it can include pre-configured device XML files, such as those provided above or elsewhere.
Here's an example of [IBM 5150](/devices/pcx86/machine/5150/mda/64kb/)
[XML](/devices/pcx86/machine/5150/mda/64kb/machine.xml):
Here's an [IBM 5150](/devices/pcx86/machine/5150/mda/64kb/) [XML](/devices/pcx86/machine/5150/mda/64kb/machine.xml)
example:
```xml
<machine id="ibm5150" class="pcx86" border="1" pos="center" background="#FAEBD7">
@ -54,6 +58,7 @@ Here's an example of [IBM 5150](/devices/pcx86/machine/5150/mda/64kb/)
```
In this example, all the devices are fully configured within the machine XML file, except for the
[Video](/docs/pcx86/video/) [XML](/devices/pcx86/video/ibm/mda/ibm-mda.xml),
[Floppy Disk Controller (FDC)](/docs/pcx86/fdc/) [XML](/disks/pcx86/compiled/samples.xml), and
[Keyboard](/docs/pcx86/keyboard/) [XML](/devices/pcx86/keyboard/us83-buttons-arrows.xml).
*[Video](/docs/pcx86/video/)* ([XML](/devices/pcx86/video/ibm/mda/ibm-mda.xml)),
*[Floppy Drive Controller](/docs/pcx86/fdc/)* ([XML](/disks/pcx86/compiled/samples.xml)), and
*[Keyboard](/docs/pcx86/keyboard/)* ([XML](/devices/pcx86/keyboard/us83-buttons-arrows.xml)) components,
which refer to separate XML configuration files.

View file

@ -7,9 +7,15 @@ permalink: /devices/pcx86/chipset/
IBM PC ChipSet Configurations
---
The following ChipSet configurations are available:
The following predefined *[ChipSet](/docs/pcx86/chipset/)* XML configurations are currently available:
- [IBM Model 5150 w/CGA](5150-cga-max.xml)
- [AT&amp;T Personal Computer 6300](att6300-cga-max.xml)
- [Columbia Data Products MPC 1600](mpc1600-cga-max.xml)
- [Zenith Z-150](z150-cga-max.xml)
However, most machines use their own *[ChipSet](/docs/pcx86/chipset/)* model, DIP switch settings, etc; e.g.:
```xml
<chipset id="chipset" model="5160" sw1="01001001"/>
```

View file

@ -11,8 +11,8 @@ IBM PC Keyboard Devices
### Keyboard Configuration Files
The easiest way for a machine to include a *[Keyboard](/docs/pcx86/keyboard/)* component in its XML configuration file
is to reference one of the project's keyboard configuration files, using the *ref* attribute; eg:
The easiest way for a machine to add a *[Keyboard](/docs/pcx86/keyboard/)* component to its XML configuration file
is to use one of the project's predefined configuration files, with the *ref* attribute; e.g.:
```xml
<keyboard ref="/devices/pcx86/keyboard/us83-buttons-minimal.xml"/>

View file

@ -10,13 +10,13 @@ redirect_from:
IBM PC Machine Configurations
---
PCx86 supports these early [IBM PC Machines](#ibm-pc-machines):
PCjs supports these early [IBM PC Machines](#ibm-pc-machines):
* [IBM PC](/devices/pcx86/machine/5150/) (Model 5150)
* [IBM PC XT](/devices/pcx86/machine/5160/) (Model 5160)
* [IBM PC AT](/devices/pcx86/machine/5170/) (Model 5170)
PCx86 also supports IBM PC-compatibles, such as:
PCjs also supports IBM PC-compatibles, such as:
* [AT&amp;T](/devices/pcx86/machine/att/) ([AT&amp;T 6300](/devices/pcx86/machine/att/6300/))
* [Columbia Data Products](/devices/pcx86/machine/cdp/) ([MPC 1600](/devices/pcx86/machine/cdp/mpc1600/cga/640kb/))

View file

@ -9,13 +9,15 @@ redirect_from:
IBM PC Control Panels
---
[Control Panels](/docs/pcx86/panel/) are XML files that define layouts for Debugger-related controls.
A *[Control Panel](/docs/pcx86/panel/)* is a collection of machine controls (e.g., buttons, register values, etc)
bound to the *[CPU](/docs/pcx86/cpu/)* and *[Debugger](/docs/pcx86/debugger/)* components and usually defined in a
separate XML file.
The following IBM PC control panel configuration files are currently available:
The following predefined IBM PC *[Control Panel](/docs/pcx86/panel/)* XML configuration are currently available:
- [default.xml](default.xml) (a simple layout for 8086/8088-based machines)
- [wide.xml](wide.xml) (a wide version of default.xml)
- [wide386.xml](wide386.xml) (a wide version of default.xml for 80386-based machines)
The visual controls described by these layouts are provided by the [Computer](/docs/pcx86/computer/),
[CPU](/docs/pcx86/cpu/), [Keyboard](/docs/pcx86/keyboard/), and [Debugger](/docs/pcx86/debugger/) components.
The visual controls described by these layouts are provided by the *[Computer](/docs/pcx86/computer/)*,
*[CPU](/docs/pcx86/cpu/)*, *[Keyboard](/docs/pcx86/keyboard/)*, and *[Debugger](/docs/pcx86/debugger/)* components.

View file

@ -73,6 +73,6 @@ The project also contains BIOS ROMs, along with more detailed information, for t
### Other ROMs
The project contains other ROMs, including IBM [EGA](/devices/pcx86/video/ibm/ega/#ibm-ega-rom) and
[VGA](/devices/pcx86/video/ibm/vga/#ibm-vga-rom) ROMs, the Xebec Hard Disk Controller ROM used in
[VGA](/devices/pcx86/video/ibm/vga/#ibm-vga-rom) ROMs, the Xebec Hard Drive Controller ROM used in
the PC XT, etc, but those ROMs seemed more appropriately filed in their respective component folders;
eg, [IBM PC Video Devices](/devices/pcx86/video/).

View file

@ -17,7 +17,7 @@ Our COMPAQ [EGA ROM BIOS](000412-001B/compaq-ega.json) comes from
### Font Information
As noted in [Video.onROMLoad()](/modules/pcjs/lib/video.js), the Video component needs to know where the card's
As noted in [Video.onROMLoad()](/modules/pcx86/lib/video.js), the Video component needs to know where the card's
font data is located:
For EGA cards, in the absence of any parameters, we assume that we're receiving the original

View file

@ -11,7 +11,7 @@ IBM PC Video Configurations
Sample XML configurations are available for the following IBM PC Video Adapters:
* Monochrome Display Adapter (MDA)
* [Monochrome Display Adapter (MDA)](mda/)
* [Color Graphics Adapter (CGA)](cga/)
* [Enhanced Graphics Adapter (EGA)](ega/)
* [Video Graphics Array (VGA)](vga/)

View file

@ -48,7 +48,7 @@ The following IBM CGA configuration files are currently available:
There is only one known CGA Character ROM ([ibm-cga.json](ibm-cga.json)), and it is identical to the MDA Character ROM,
because the ROM contains both the 8x14 MDA and 8x8 CGA fonts.
As documented in [Video.doneLoad()](/modules/pcjs/lib/video.js):
As documented in [Video.doneLoad()](/modules/pcx86/lib/video.js):
[T]here are TWO CGA fonts in the ROM: a thin 5x7 "single dot" font located at offset 0x1000, and a thick 7x7
"double dot" font at offset 0x1800. The latter is the default font, unless overridden by a jumper setting on

View file

@ -64,7 +64,7 @@ The PCjs server's Dump API can be used as well:
### IBM EGA Font Information
As noted in [Video.onROMLoad()](/modules/pcjs/lib/video.js), the Video component needs to know where the card's
As noted in [Video.onROMLoad()](/modules/pcx86/lib/video.js), the Video component needs to know where the card's
font data is located:
For EGA cards, in the absence of any parameters, we assume that we're receiving the original

View file

@ -44,7 +44,7 @@ The following IBM MDA configuration files are currently available:
There is only one known MDA Character ROM ([ibm-mda.json](ibm-mda.json)), and it is identical to the CGA Character ROM,
because the ROM contains both the 8x14 MDA and 8x8 CGA fonts.
As documented in [Video.doneLoad()](/modules/pcjs/lib/video.js):
As documented in [Video.doneLoad()](/modules/pcx86/lib/video.js):
[T]here are TWO CGA fonts in the ROM: a thin 5x7 "single dot" font located at offset 0x1000, and a thick 7x7
"double dot" font at offset 0x1800. The latter is the default font, unless overridden by a jumper setting on

View file

@ -72,7 +72,7 @@ folder, along with a **manifest.xml** file containing metadata about the softwar
disks. This is generally referred to as a [Software Manifest](/apps/), but in the context of the Disk Library,
it's simply known as a Disk Manifest.
A Disk Manifest can then be added to a *[Floppy Disk Controller (FDC)](/docs/pcx86/fdc/)* configuration file,
A Disk Manifest can then be added to a *[Floppy Drive Controller (FDC)](/docs/pcx86/fdc/)* configuration file,
making all its disks available to any machine loading that particular configuration file.
A simple FDC configuration file, such as [samples.xml](samples.xml), *could* contain individual &lt;disk&gt;

View file

@ -28,7 +28,7 @@ pre-loaded), what kind of video adapter (MDA, CGA, EGA or VGA), serial ports, mo
[Documentation](/docs/pcx86/) for details.
+ Excellent IBM hardware compatibility ensures all the original IBM BIOS ROMs operate properly, and that the
machines run at their original speed. Even obsolete hardware, such as the original PC XT hard disk controller,
machines run at their original speed. Even obsolete hardware, such as the original PC XT hard drive controller,
is supported.
+ The CPU component is easily configured to emulate an 8088, 80186, 80286, or 80386. A target speed can also

View file

@ -29,7 +29,7 @@ of XSL and CSS support files (included in the ZIP file below).
A PCx86 machine XML file defines all a machine's components, including:
* [Chipset](chipset/)
* [ChipSet](chipset/)
* [Computer](computer/)
* [Control Panel](panel/)
* [CPU](cpu/)
@ -42,7 +42,7 @@ A PCx86 machine XML file defines all a machine's components, including:
* [ROM](rom/)
* [Parallel Port](parallel/)
* [Serial Port](serial/)
* [Video Adapter](video/)
* [Video](video/)
Here's a simple machine XML file that includes an 8088 CPU and 16Kb of RAM:
@ -88,7 +88,7 @@ Note that as soon as the machine is ready and the CPU starts running, the "Run"
</machine>
```
Next, we can add a Floppy Disk Controller (FDC) component. And since we want to be able to "load" and "unload" floppy
Next, we can add a Floppy Drive Controller (FDC) component. And since we want to be able to "load" and "unload" floppy
disks at will, we'll include some UI controls.
```xml

View file

@ -40,7 +40,7 @@ Bindings
For use with a control of type *list*. The list will be populated automatically with a series of &lt;option&gt;
elements based on the number of floppy drives, as determined by the SW1 settings obtained from the
[ChipSet](/docs/pcx86/chipset/) component.
*[ChipSet](/docs/pcx86/chipset/)* component.
* *listDisks*

View file

@ -16,8 +16,8 @@ Format
Purpose
---
Creates an instance of the Control Panel component, which simply acts as a container for controls that the
machine wants to bind to the [Computer](/docs/pcx86/computer/), [CPU](/docs/pcx86/cpu/), [Keyboard](/docs/pcx86/keyboard/)
and/or [Debugger](/docs/pcx86/debugger/) components.
machine wants to bind to the *[Computer](/docs/pcx86/computer/)*, *[CPU](/docs/pcx86/cpu/)*,
*[Keyboard](/docs/pcx86/keyboard/)* and/or *[Debugger](/docs/pcx86/debugger/)* components.
Attributes
---
@ -25,8 +25,8 @@ None.
Bindings
---
Refer to available bindings in the [Computer](/docs/pcx86/computer/), [CPU](/docs/pcx86/cpu/), [Keyboard](/docs/pcx86/keyboard/)
and [Debugger](/docs/pcx86/debugger/) components.
Refer to available bindings in the *[Computer](/docs/pcx86/computer/)*, *[CPU](/docs/pcx86/cpu/)*,
*[Keyboard](/docs/pcx86/keyboard/)* and *[Debugger](/docs/pcx86/debugger/)* components.
Example
---

View file

@ -26,7 +26,7 @@ Attributes
* *size* (optional; default is 0x00000)
The amount of RAM, in bytes. If the size is omitted (or 0), the [ChipSet](/docs/pcx86/chipset/) component
The amount of RAM, in bytes. If the size is omitted (or 0), the *[ChipSet](/docs/pcx86/chipset/)* component
is queried for the amount of RAM indicated by SW1/SW2.
* *test* (optional; default is true)

View file

@ -15,7 +15,7 @@ PCx86, the PCjs IBM PC emulation module, is the engine powering all our [IBM PC
This module divides PC functionality into variety of logical and visual components.
In general, each JavaScript file is responsible for a single component or set of related components (eg,
[chipset.js](lib/chipset.js)). Most components represent familiar PC devices, such as video cards, disk
[chipset.js](lib/chipset.js)). Most components represent familiar PC devices, such as video cards, disk drive
controllers, etc.
*Component* is an overloaded term, since **Component** is also the name of the shared base class in
@ -110,8 +110,8 @@ A BackTrack index is encoded as a 32-bit value with three parts:
This represents a total of 31 bits, with bit 31 reserved.
For example, look at one of the last things a ROM does during boot: loading a disk sector into RAM. It will be up to the
disk controller (or DMA controller, if used) to create a BackTrack object representing the sector that was read,
For example, look at one of the last things a ROM does during boot: loading a disk sector into RAM. It will be up to
the drive controller (or DMA controller, if used) to create a BackTrack object representing the sector that was read,
adding that object to the global BackTrack object array, and then associating the corresponding BackTrack index with
the first byte of RAM where the sector was loaded. Subsequent bytes of RAM containing the rest of the sector will refer
to the same BackTrack object, using BackTrack indexes containing offsets 1-511.