From 20f8bdf141158b28ccd656a4f8b4f8451b8382a1 Mon Sep 17 00:00:00 2001 From: Jeff Parsons Date: Thu, 1 Jun 2017 16:42:46 -0700 Subject: [PATCH] Added more info about DOS 2.0 BPBs --- modules/diskdump/lib/diskdump.js | 15 ++++++++------- modules/shared/lib/diskapi.js | 18 +++++++++++++----- 2 files changed, 21 insertions(+), 12 deletions(-) diff --git a/modules/diskdump/lib/diskdump.js b/modules/diskdump/lib/diskdump.js index b631bc246..714c5d7ed 100644 --- a/modules/diskdump/lib/diskdump.js +++ b/modules/diskdump/lib/diskdump.js @@ -541,14 +541,15 @@ DiskDump.aDefaultBPBs = [ 0x08, 0x00, // 0x16: sectors per FAT (8) // // 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 - // and it properly initialized the next 3 fields as well. TODO: Investigate PC-DOS 2.0 BPB behavior. + // this point was introduced post-DOS 2.0. However, DOS 2.0 merely said they were optional, and in fact, DOS 2.0 + // 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) 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 - // 0x1E is part of the BPB. TODO: Investigate PC-DOS 2.0 BPB behavior. + // PC-DOS 2.0 actually stored 0x01, 0x00, 0x80, 0x00 here, so you can't rely on more than the first word. + // 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) ] @@ -2652,10 +2653,10 @@ DiskDump.prototype.convertToJSON = function() if (iBPB >= 0) { if (fBPBExists) { /* - * In deference to the PC-DOS 2.0 anomaly noted above (see "Investigate PC-DOS 2.0 BPB behavior" above), - * we limit the following byte verification to the offset of LARGE_SECS, less two bytes. + * In deference to the PC-DOS 2.0 BPB behavior discussed above, we stop our BPB verification + * 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 bActual = this.bufDisk.readUInt8(offBootSector + i); if (bDefault != bActual) { diff --git a/modules/shared/lib/diskapi.js b/modules/shared/lib/diskapi.js index f048f7d51..093d81652 100644 --- a/modules/shared/lib/diskapi.js +++ b/modules/shared/lib/diskapi.js @@ -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) 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 - * can mislead us when attempting to calculate total cylinders. + * The following are some common partition sizes, which we explicitly map to CHS values, since MBR/BPB values + * 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) 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 = { 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) TRACK_SECS: 0x018, // 2 bytes: sectors per track (eg, 8) 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) - 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) + 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 (DOS 3.31 and up): number of sectors if TOTAL_SECS is zero }; /*