Updated page on COMPAQ DOS 1.11

This commit is contained in:
Jeff Parsons 2017-06-26 07:33:03 -07:00 committed by Jeff Parsons
commit 8d5c618b78
2 changed files with 34 additions and 34 deletions

View file

@ -70,7 +70,7 @@ A directory listing of the 320Kb diskette is provided [below](#directory-of-comp
28 file(s) 256320 bytes 28 file(s) 256320 bytes
53248 bytes free 53248 bytes free
The boot sector of the COMPAQ MS-DOS 1.11 disk image (COMPAQ-DOS111.img) contained the following bytes: The boot sector of the COMPAQ MS-DOS 1.11 disk image contains the following bytes:
00000000 fa bc e7 01 b8 c0 07 8e d0 fb 8e d8 8e c0 33 c0 |..............3.| 00000000 fa bc e7 01 b8 c0 07 8e d0 fb 8e d8 8e c0 33 c0 |..............3.|
00000010 cd 13 b8 01 02 bb 00 02 b9 04 00 33 d2 e8 8b 00 |...........3....| 00000010 cd 13 b8 01 02 bb 00 02 b9 04 00 33 d2 e8 8b 00 |...........3....|
@ -105,29 +105,30 @@ The boot sector of the COMPAQ MS-DOS 1.11 disk image (COMPAQ-DOS111.img) contain
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Consequently, the disk could not be mounted by a modern operating system (e.g., macOS), because it lacked a proper Consequently, the disk cannot be mounted by a modern operating system (e.g., macOS), because it lacks a proper
BPB at offset 0x000B. BPB at offset 0x000B.
Using the *--forceBPB* option of the [DiskDump](/modules/diskdump/) utility, I was able to create a mountable disk One solution is to use the *--forceBPB* option of the [DiskDump](/modules/diskdump/) utility, which creates a
image with the following boot sector modifications: mountable disk image with the following boot sector modifications:
00000000 eb fe 90 50 43 4a 53 2e 4f 52 47 00 02 02 01 00 |...PCJS.ORG.....| 00000000 eb fe 90 50 43 4a 53 2e 4f 52 47 00 02 02 01 00 |...PCJS.ORG.....|
00000010 02 70 00 80 02 ff 01 00 08 00 02 00 00 00 00 00 |.p..............| 00000010 02 70 00 80 02 ff 01 00 08 00 02 00 00 00 00 00 |.p..............|
00000020 00 00 00 00 00 8a 07 3c 24 74 0c 53 b4 0e bb 07 |.......<$t.S....| 00000020 00 00 00 00 00 8a 07 3c 24 74 0c 53 b4 0e bb 07 |.......<$t.S....|
These modifications included: The following byte ranges are modified:
- 0x0000-0x0002: 2-byte Intel JMP instruction followed by 1-byte Intel NOP - 0x0000-0x0002: 2-byte Intel x86 JMP instruction followed by 1-byte x86 NOP
- 0x0003-0x000A: 8-byte OEM signature string (we use the fake "PCJS.ORG" OEM signature) - 0x0003-0x000A: 8-byte OEM signature string (we use the fake "PCJS.ORG" OEM signature)
- 0x000B-0x001D: 19-byte BPB describing a 320Kb diskette image with 8 sectors/track and 2 heads - 0x000B-0x001D: 19-byte BPB describing a 320Kb diskette image with 8 sectors/track and 2 heads
Ordinarily, only the 19-byte BPB would be required, but it turned out that macOS wouldn't mount the image file Ordinarily, only the 19-byte BPB would be required, but it turns out that macOS won't mount the disk image
*unless* the boot sector also began with an Intel JMP instruction. All known PC-DOS boot sectors begin with a JMP unless the boot sector *also* begins with an Intel x86 JMP instruction. So the *--forceBPB* option updates all
instruction, so these early OEM disk images were rather unusual. 30 bytes at the beginning of the boot sector, making the disk image mountable, but also rendering it unbootable --
which is OK if all you want to do is mount the image and copy files from it.
Anyway, I changed the *--forceBPB* option to update all 30 bytes at the beginning of the boot sector, making the disk Here's a sample command sequence. Note that *two* DiskDump commands are required, because BPB modification
image mountable, but also rendering it unbootable. But that was OK, because all I wanted to do with the image was mount only happens when converting an IMG file to a JSON file; the second command converts the JSON file back into
it and copy its files. The sequence of commands were: a separate IMG file, preserving the original.
diskdump --disk=COMPAQ-DOS111.img --format=json --output=COMPAQ-DOS111-BPB.json diskdump --disk=COMPAQ-DOS111.img --format=json --output=COMPAQ-DOS111-BPB.json
warning: BPB has been updated warning: BPB has been updated
@ -139,4 +140,12 @@ it and copy its files. The sequence of commands were:
mkdir COMPAQ-DOS111 mkdir COMPAQ-DOS111
cp -pr /Volumes/Untitled/ COMPAQ-DOS111 cp -pr /Volumes/Untitled/ COMPAQ-DOS111
Another curiosity regarding this disk are the BASIC files. **BASIC.COM** and **BASICA.COM** are nothing more than
tiny programs to load **BASICA.EXE**, a stand-alone version of BASIC that doesn't require any BASIC ROMs. And
**BASICA.EXE** reports a version number that differs from the DOS version:
The COMPAQ Personal Computer BASIC
Version 1.13
(C) Copyright COMPAQ Computer Corp. 1983
[Return to [COMPAQ MS-DOS Disks](/disks/pcx86/dos/compaq/)] [Return to [COMPAQ MS-DOS Disks](/disks/pcx86/dos/compaq/)]

View file

@ -2955,28 +2955,7 @@ class Video extends Component {
* At this point, xThird and yThird should both be one of 0, 1 or 2, indicating which horizontal and * At this point, xThird and yThird should both be one of 0, 1 or 2, indicating which horizontal and
* vertical third of the virtual screen the touch event occurred. * vertical third of the virtual screen the touch event occurred.
*/ */
if (/* xThird == 1 && */ yThird != 1) { this.kbd.addActiveKey(Video.KEYGRID[yThird][xThird], true);
if (!yThird) {
this.kbd.addActiveKey(Keyboard.CLICKCODES.UP, true);
} else {
this.kbd.addActiveKey(Keyboard.CLICKCODES.DOWN, true);
}
} else if (/* yThird == 1 && */ xThird != 1) {
if (!xThird) {
this.kbd.addActiveKey(Keyboard.CLICKCODES.LEFT, true);
} else {
this.kbd.addActiveKey(Keyboard.CLICKCODES.RIGHT, true);
}
}
else {
/*
* Why simulate a SPACE if the tap is in the middle third of the screen? Well, apparently I
* didn't explain earlier that the WHOLE reason I originally added KEYGRID support (before it was
* even called KEYGRID support) was to make the 1985 game "Rogue" (pcjs.org/apps/pcx86/1985/rogue)
* more fun to play on an iPad, because arrows and spaces are the most commonly used keys.
*/
this.kbd.addActiveKey(Keyboard.SIMCODE.SPACE, true);
}
} }
} else { } else {
@ -7345,6 +7324,18 @@ Video.TOUCH = {
MOUSE: 2 MOUSE: 2
}; };
/*
* Why simulate a SPACE if the tap is in the middle third (center) of the screen? Well, apparently
* I didn't explain earlier that the WHOLE reason I originally added KEYGRID support (before it was
* even called KEYGRID support) was to make the 1985 game "Rogue" (pcjs.org/apps/pcx86/1985/rogue)
* more fun to play on an iPad, and space is a commonly required key.
*/
Video.KEYGRID = [
[Keyboard.SIMCODE.HOME, Keyboard.SIMCODE.UP, Keyboard.SIMCODE.PGUP],
[Keyboard.SIMCODE.LEFT, Keyboard.SIMCODE.SPACE, Keyboard.SIMCODE.RIGHT],
[Keyboard.SIMCODE.END, Keyboard.SIMCODE.DOWN, Keyboard.SIMCODE.PGDN],
];
/* /*
* Port input/output notification tables * Port input/output notification tables
* *