Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added more info about DOS 2.0 BPBs

Browse source
This commit is contained in:
Jeff Parsons 2017-06-01 16:42:46 -07:00 • committed by Jeff Parsons
commit 20f8bdf141
2 changed files with 21 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

15
modules/diskdump/lib/diskdump.js
View file

@ -541,14 +541,15 @@ DiskDump.aDefaultBPBs = [
0x08, 0x00, // 0x16: sectors per FAT (8) 0x08, 0x00, // 0x16: sectors per FAT (8)
// //
// Wikipedia (http://en.wikipedia.org/wiki/File_Allocation_Table#BIOS_Parameter_Block) implies everything past // Wikipedia (http://en.wikipedia.org/wiki/File_Allocation_Table#BIOS_Parameter_Block) implies everything past
// this point was introduced post-DOS 2.0. I think that's wrong, because I just formatted a diskette with PC-DOS 2.0 // this point was introduced post-DOS 2.0. However, DOS 2.0 merely said they were optional, and in fact, DOS 2.0
// and it properly initialized the next 3 fields as well. TODO: Investigate PC-DOS 2.0 BPB behavior. // FORMAT always initializes the next 3 words. A 4th word, LARGE_SECS, was added in DOS 3.20 at offset 0x1E,
// and then in DOS 3.31, both HIDDEN_SECS and LARGE_SECS were widened from words to dwords.
// //
0x11, 0x00, // 0x18: sectors per track (17) 0x11, 0x00, // 0x18: sectors per track (17)
0x04, 0x00, // 0x1A: number of heads (4) 0x04, 0x00, // 0x1A: number of heads (4)
// //
// PC-DOS 2.0 actually stored 0x01, 0x00, 0x80, 0x00 here, so you can't always assume that anything past offset // PC-DOS 2.0 actually stored 0x01, 0x00, 0x80, 0x00 here, so you can't rely on more than the first word.
// 0x1E is part of the BPB. TODO: Investigate PC-DOS 2.0 BPB behavior. // TODO: Investigate PC-DOS 2.0 BPB behavior (ie, what did the 0x80 mean)?
// //
0x01, 0x00, 0x00, 0x00 // 0x1C: number of hidden sectors (always 0 for non-partitioned media) 0x01, 0x00, 0x00, 0x00 // 0x1C: number of hidden sectors (always 0 for non-partitioned media)
] ]
@ -2652,10 +2653,10 @@ DiskDump.prototype.convertToJSON = function()
if (iBPB >= 0) { if (iBPB >= 0) {
if (fBPBExists) { if (fBPBExists) {
/* /*
* In deference to the PC-DOS 2.0 anomaly noted above (see "Investigate PC-DOS 2.0 BPB behavior" above), * In deference to the PC-DOS 2.0 BPB behavior discussed above, we stop our BPB verification
* we limit the following byte verification to the offset of LARGE_SECS, less two bytes. * after the first word of HIDDEN_SECS.
*/ */
for (i = DiskAPI.BPB.SECTOR_BYTES; i < DiskAPI.BPB.LARGE_SECS - 2; i++) { for (i = DiskAPI.BPB.SECTOR_BYTES; i < DiskAPI.BPB.HIDDEN_SECS + 2; i++) {
var bDefault = DiskDump.aDefaultBPBs[iBPB][i]; var bDefault = DiskDump.aDefaultBPBs[iBPB][i];
var bActual = this.bufDisk.readUInt8(offBootSector + i); var bActual = this.bufDisk.readUInt8(offBootSector + i);
if (bDefault != bActual) { if (bDefault != bActual) {

18
modules/shared/lib/diskapi.js
View file

@ -89,8 +89,9 @@ DiskAPI.DISK_FORMATS = {
1474560: [80,2,18,,0xF0], // media type 0xF0: 80 cylinders, 2 heads (double-sided), 18 sectors/track, (2880 total sectors x 512 bytes/sector == 1474560) 1474560: [80,2,18,,0xF0], // media type 0xF0: 80 cylinders, 2 heads (double-sided), 18 sectors/track, (2880 total sectors x 512 bytes/sector == 1474560)
2949120: [80,2,36,,0xF0], // media type 0xF0: 80 cylinders, 2 heads (double-sided), 36 sectors/track, (5760 total sectors x 512 bytes/sector == 2949120) 2949120: [80,2,36,,0xF0], // media type 0xF0: 80 cylinders, 2 heads (double-sided), 36 sectors/track, (5760 total sectors x 512 bytes/sector == 2949120)
/* /*
* The following are some common partition sizes, which we explicitly map to CHS values, since the MBR and/or BPB * The following are some common partition sizes, which we explicitly map to CHS values, since MBR/BPB values
* can mislead us when attempting to calculate total cylinders. * can mislead us when attempting to determine the exact disk geometry. TODO: Investigate. Is it possible that
* usable space on early hard disks was reduced to reserve the last cylinder for diagnostics, head parking, etc?
*/ */
10618368:[306,4,17], // PC XT 10Mb hard drive (type 3) 10618368:[306,4,17], // PC XT 10Mb hard drive (type 3)
21368320:[615,4,17], // PC AT 20Mb hard drive (type 2) 21368320:[615,4,17], // PC AT 20Mb hard drive (type 2)
@ -152,7 +153,14 @@ DiskAPI.BOOT = {
}; };
/* /*
* BIOS Parameter Block (BPB) offsets in DOS-compatible boot sectors (DOS 2.0 and up) * BIOS Parameter Block (BPB) offsets in DOS-compatible boot sectors (DOS 2.x and up)
*
* NOTE: DOS 2.x OEM documentation says that the words starting at offset 0x018 (TRACK_SECS, TOTAL_HEADS, and HIDDEN_SECS)
* are optional, but even the DOS 2.0 FORMAT utility initializes all three of those words. There may be some OEM media out
* there with BPBs that are only valid up to offset 0x018, but I've not run across any media like that.
*
* DOS 3.20 added LARGE_SECS, but unfortunately, it was added as a 2-byte value at offset 0x01E. DOS 3.31 decided
* to make both HIDDEN_SECS and LARGE_SECS 4-byte values, which meant that LARGE_SECS had to move from 0x01E to 0x020.
*/ */
DiskAPI.BPB = { DiskAPI.BPB = {
SECTOR_BYTES: 0x00B, // 2 bytes: bytes per sector (eg, 0x200 or 512) SECTOR_BYTES: 0x00B, // 2 bytes: bytes per sector (eg, 0x200 or 512)
@ -165,8 +173,8 @@ DiskAPI.BPB = {
FAT_SECS: 0x016, // 2 bytes: sectors per FAT (eg, 1) FAT_SECS: 0x016, // 2 bytes: sectors per FAT (eg, 1)
TRACK_SECS: 0x018, // 2 bytes: sectors per track (eg, 8) TRACK_SECS: 0x018, // 2 bytes: sectors per track (eg, 8)
TOTAL_HEADS: 0x01A, // 2 bytes: number of heads (eg, 1) TOTAL_HEADS: 0x01A, // 2 bytes: number of heads (eg, 1)
HIDDEN_SECS: 0x01C, // 4 bytes: number of hidden sectors (always 0 for non-partitioned media) HIDDEN_SECS: 0x01C, // 2 bytes (DOS 2.x) or 4 bytes (DOS 3.31 and up): number of hidden sectors (always 0 for non-partitioned media)
LARGE_SECS: 0x020 // 4 bytes: number of sectors if TOTAL_SECS is zero (TODO: Verify the true extent of DOS 2.0 BPBs; they may have stopped with HIDDEN_SECS, which is what DiskDump assumes) LARGE_SECS: 0x020 // 4 bytes (DOS 3.31 and up): number of sectors if TOTAL_SECS is zero
}; };
/* /*