Changed the "Adventures in Math (1983)" demo to boot PC-DOS 1.0 -- which in turn required a 160Kb disk image for the game

apps/pcx86/1983/adventmath/README.md

@@ -5,8 +5,10 @@ permalink: /apps/pcx86/1983/adventmath/
 machines:
   - type: pcx86
     id: ibm5150
-    config: /devices/pcx86/machine/5150/cga/256kb/machine.xml
+    config: /devices/pcx86/machine/5150/cga/64kb/machine.xml
     autoMount:
+      A:
+        path: /disks/pcx86/dos/ibm/1.00/PCDOS100.json
       B:
         path: /apps/pcx86/1983/adventmath/ADVENTMATH100.json
 ---
@@ -16,8 +18,8 @@ Adventures in Math (1983)
 
 {% include machine.html id="ibm5150" %}
 
-This game is available from the [Internet Archive](https://archive.org/details/msdos_Adventures_in_Math_1983).
+The files for this game were obtained from the [Internet Archive](https://archive.org/details/msdos_Adventures_in_Math_1983).
-The contents of their ZIP archive contains:
+The contents of their ZIP archive contained:
 
 	-rwxr-xr-x@ 1 Jeff  staff  18688 Dec 24  1996 Adventur.bas
 	-rwxr-xr-x@ 1 Jeff  staff      0 Dec 24  1996 Adventures in Math (1983).ba1
@@ -33,8 +35,11 @@ The contents of their ZIP archive contains:
 	-rwxr-xr-x@ 1 Jeff  staff     13 Dec 24  1996 Sn
 	-rwxr-xr-x@ 1 Jeff  staff    369 Dec 24  1996 Topten
 
-What's a little disturbing about the above archive is that all the files are dated "Dec 24 1996".
+It's unfortunate that the archive did not contain a complete dump of the original "Adventures in Math" diskette.
-However, if you dig around a bit more on the Internet Archive, you discover that
+It's especially disturbing that all the files in the archive are dated "Dec 24 1996", calling into question which,
+if any, of these files are authentic.
+
+After digging around a bit more on the Internet Archive, I discovered that
 [A Large Collection of DOS Collections](https://archive.org/details/large_dos_collection_2013_08) contains:
 
 - DOS Collection v0.7/DVD1/Adventures In Math (1983)(Ibm).zip
@@ -72,9 +77,10 @@ And in the second ZIP file:
 	-rw-r--r--@ 1 Jeff  staff    369 Sep 17  1999 Topten
 	-rw-r--r--@ 1 Jeff  staff    170 Jan 22  2011 file_id.diz
 
-I decided to start with the contents of the second ZIP file.
+I decided to start with the contents of the second ZIP file, since the timestamps of the most of the files
+appeared to be legitimate.
 
-One strange file common to *all* these archives is **MONOCODE.000**.  Dumping that file reveals:
+One strange file common to *all* these archives is **MONOCODE.000**.  Dumping that file revealed:
 
 	00000c60  20 4d 4f 4e 4f 50 4f 4c  59 20 69 73 20 61 20 72  | MONOPOLY is a r|
 	00000c70  65 67 69 73 74 65 72 65  64 20 74 72 61 64 65 6d  |egistered tradem|
@@ -93,7 +99,8 @@ Another unexpected file is **BASICA.EXE** (54277 bytes) from 1999.  It seems unl
 IBM's PC-DOS shipped with **BASICA.COM**, and OEM versions of DOS shipped with either **GWBASIC.EXE** or **BASIC.EXE**.
 
 The closest matching binary I'd seen up to this point was **BASICA.EXE** from [COMPAQ DOS 1.12](/disks/pcx86/dos/compaq/1.12/)
-(54304 bytes).  And sure enough, examining the strings contained inside this **BASICA.EXE** revealed that it is a close relative:
+(54304 bytes).  And sure enough, examining the strings contained inside this **BASICA.EXE** revealed that it was a close
+relative:
 
 	The COMPAQ Personal Computer BASIC
 	Version 1.13
@@ -101,7 +108,8 @@ The closest matching binary I'd seen up to this point was **BASICA.EXE** from [C
 
 It's safe to say that IBM would not have distributed a COMPAQ binary; if IBM had distributed any BASIC binary at all,
 it would have been their own **BASICA.COM**.  Of course, the problem with IBM's **BASICA.COM** is that it also requires
-an IBM PC with ROM BASIC installed, which is why someone copied the COMPAQ version of BASIC (it has no ROM dependencies).
+an IBM PC with ROM BASIC installed, which is why some people would have preferred the COMPAQ version: it has no ROM
+dependencies.
 
 Anyway, I've deleted **BASICA.EXE**.  The proper thing to do -- and what any purchaser of this game would have to do --
 is boot a machine with an appropriate version of DOS and use the BASIC binary included with DOS to run this game.
@@ -138,7 +146,47 @@ and **TOPTEN**:
 	Z[z],55677,LARGE,07-24-81
 	[z],55197,LARGE,07-23-81
 
-All those files have been deleted as well, leaving 8 files dated "Aug 11 1983".  Next, I created a disk image from the
+All those files have been deleted as well, leaving 8 files dated "Aug 11 1983".  Next, I used the PCjs
-directory containing just those files:
+[DiskDump](/modules/diskdump/) utility to create a disk image from a directory ("archive/disk") containing just
+those files:
  
-	diskdump --dir=archive --format=json --output=ADVENTMATH100.json --manifest
+	diskdump --dir=archive/disk --format=json --output=ADVENTMATH100.json --manifest
+
+The resulting 160Kb disk image contains:
+
+	 Volume in drive A is PCJS    ORG
+	 Directory of  A:\
+
+	ADVENTUR BAS    18688   8-11-83  12:00p
+	CASTLE   BAS    11904   8-11-83  12:00p
+	EXIT     BAS     6400   8-11-83  12:00p
+	HELP     BAS     4992   8-11-83  12:00p
+	MAZE1            1418   8-11-83  12:00p
+	MAZE2            2179   8-11-83  12:00p
+	MAZE3            3892   8-11-83  12:00p
+	SN                 13   8-11-83  12:00p
+	        8 File(s)    108544 bytes free
+
+And this disk has now been added to the PCjs [IBM PC Disk Library](/disks/pcx86/) as "Adventures in Math (1983)".
+
+I originally selected an [IBM PC (Model 5150, 64Kb) with Color Display](/devices/pcx86/machine/5150/cga/64kb/),
+which boots PC-DOS 2.00 by default.  However, in the course of starting the game, it would crash:
+
+![ADVENTMATH-CRASH](ADVENTMATH-CRASH.png)
+
+It appeared to run fine with 256Kb of RAM, but these were IBM's "System requirements" for the game:
+ 
+> IBM Color Display, or a television
+
+> 64Kb of memory for PC and PC XT, 128KB for PC*jr*
+
+> One diskette drive
+
+so I reconfigured the machine to boot PC-DOS 1.00, which required less RAM than PC-DOS 2.00, and that appeared to be
+sufficient.  Note that the game was released in October 1983, well after the March 1983 release of PC-DOS 2.00, so
+either it wasn't tested with PC-DOS 2.00 on a 64Kb machine, or the error is a PCjs anomaly. 
+
+References
+----------
+
+[MobyGames](http://www.mobygames.com/game/dos/adventures-in-math)

apps/pcx86/1983/adventmath/manifest.xml

@@ -9,7 +9,7 @@
 	<publisher>IBM</publisher>
 	<releaseDate>1983</releaseDate>
 	<machine href="/devices/pcx86/machine/5150/cga/64kb/machine.xml" state=""/>
-	<disk id="disk01" chs="40:2:9" dir="archive" href="/apps/pcx86/1983/adventmath/ADVENTMATH100.json" md5="190e4fe6e282426456dd7a87a2dd9968" md5json="23281f38b2090eb74c8fd4b492a60a00">
+	<disk id="disk01" chs="40:1:8" dir="archive/disk" href="/apps/pcx86/1983/adventmath/ADVENTMATH100.json" md5="034498ce8f504f33301d2e052f6aeb7e" md5json="9bf439a40013d38be5d88774854eed27">
 		<name>Adventures in Math (1983)</name>
 		<file size="18688" time="1983-08-11 12:00:12" attr="0x20" md5="79d17f58ca8232b7173b80dd05b13b70">ADVENTUR.BAS</file>
 		<file size="11904" time="1983-08-11 12:00:14" attr="0x20" md5="fb1ec8042448618b7bdf3ce996b1daa8">CASTLE.BAS</file>

disks/pcx86/README.md

@@ -5,7 +5,7 @@ permalink: /disks/pcx86/
 ---
 
 IBM PC Disk Library
----
+-------------------
 
 This [Disk Library](/disks/pcx86/library.xml) lists all the [Disk Manifests](#disk-manifests) in the
 [PCjs Project](/docs/about/) and makes those disks available to any [IBM PC Machine](/devices/pcx86/machine/)

modules/diskdump/lib/diskdump.js

@@ -407,7 +407,7 @@ DiskDump.sUsage = "Usage: " + DiskDump.sAPIURL + "?" + DumpAPI.QUERY.PATH + "={u
  * PCJS_LABEL is our default label, used whenever a more suitable label (eg, the disk image's folder name)
  * is not available or not supplied, and PCJS_OEM is inserted into any DiskDump-generated diskette images.
  */
-DiskDump.PCJS_LABEL = "PCJSDISK";
+DiskDump.PCJS_LABEL = "PCJS.ORG";
 DiskDump.PCJS_OEM   = "PCJS.ORG";
 
 /**
@@ -431,26 +431,10 @@ DiskDump.aDefaultBPBs = [
     0x01, 0x00,                 // 0x1A: number of heads (1)
     0x00, 0x00, 0x00, 0x00      // 0x1C: number of hidden sectors (always 0 for non-partitioned media)
   ],
-  [                             // define BPB for 180Kb diskette
-    0xEB, 0xFE, 0x90,           // 0x00: JMP instruction, following by 8-byte OEM signature
-    0x50, 0x43, 0x4A, 0x53, 0x2E, 0x4F, 0x52, 0x47,     // PCJS_OEM
- // 0x49, 0x42, 0x4D, 0x20, 0x20, 0x31, 0x2E, 0x30,     // "IBM  1.0" (this is a fake OEM signature)
-    0x00, 0x02,                 // 0x0B: bytes per sector (0x200 or 512)
-    0x01,                       // 0x0D: sectors per cluster (1)
-    0x01, 0x00,                 // 0x0E: reserved sectors; ie, # sectors preceding the first FAT--usually just the boot sector (1)
-    0x02,                       // 0x10: FAT copies (2)
-    0x40, 0x00,                 // 0x11: root directory entries (0x40 or 64)  0x40 * 0x20 = 0x800 (1 sector is 0x200 bytes, total of 4 sectors)
-    0x68, 0x01,                 // 0x13: number of sectors (0x168 or 360)
-    0xFC,                       // 0x15: media type (eg, 0xFF: 320Kb, 0xFE: 160Kb, 0xFD: 360Kb, 0xFC: 180Kb)
-    0x02, 0x00,                 // 0x16: sectors per FAT (2)
-    0x09, 0x00,                 // 0x18: sectors per track (9)
-    0x01, 0x00,                 // 0x1A: number of heads (1)
-    0x00, 0x00, 0x00, 0x00      // 0x1C: number of hidden sectors (always 0 for non-partitioned media)
-  ],
   [                             // define BPB for 320Kb diskette
     0xEB, 0xFE, 0x90,           // 0x00: JMP instruction, following by 8-byte OEM signature
     0x50, 0x43, 0x4A, 0x53, 0x2E, 0x4F, 0x52, 0x47,     // PCJS_OEM
- // 0x49, 0x42, 0x4D, 0x20, 0x20, 0x32, 0x2E, 0x30,     // "IBM  2.0" (this is a real OEM signature)
+    // 0x49, 0x42, 0x4D, 0x20, 0x20, 0x31, 0x2E, 0x30,     // "IBM  1.0" (this is a real OEM signature)
     0x00, 0x02,                 // 0x0B: bytes per sector (0x200 or 512)
     0x02,                       // 0x0D: sectors per cluster (2)
     0x01, 0x00,                 // 0x0E: reserved sectors; ie, # sectors preceding the first FAT--usually just the boot sector (1)
@@ -463,6 +447,22 @@ DiskDump.aDefaultBPBs = [
     0x02, 0x00,                 // 0x1A: number of heads (2)
     0x00, 0x00, 0x00, 0x00      // 0x1C: number of hidden sectors (always 0 for non-partitioned media)
   ],
+  [                             // define BPB for 180Kb diskette
+    0xEB, 0xFE, 0x90,           // 0x00: JMP instruction, following by 8-byte OEM signature
+    0x50, 0x43, 0x4A, 0x53, 0x2E, 0x4F, 0x52, 0x47,     // PCJS_OEM
+ // 0x49, 0x42, 0x4D, 0x20, 0x20, 0x32, 0x2E, 0x30,     // "IBM  2.0" (this is a fake OEM signature)
+    0x00, 0x02,                 // 0x0B: bytes per sector (0x200 or 512)
+    0x01,                       // 0x0D: sectors per cluster (1)
+    0x01, 0x00,                 // 0x0E: reserved sectors; ie, # sectors preceding the first FAT--usually just the boot sector (1)
+    0x02,                       // 0x10: FAT copies (2)
+    0x40, 0x00,                 // 0x11: root directory entries (0x40 or 64)  0x40 * 0x20 = 0x800 (1 sector is 0x200 bytes, total of 4 sectors)
+    0x68, 0x01,                 // 0x13: number of sectors (0x168 or 360)
+    0xFC,                       // 0x15: media type (eg, 0xFF: 320Kb, 0xFE: 160Kb, 0xFD: 360Kb, 0xFC: 180Kb)
+    0x02, 0x00,                 // 0x16: sectors per FAT (2)
+    0x09, 0x00,                 // 0x18: sectors per track (9)
+    0x01, 0x00,                 // 0x1A: number of heads (1)
+    0x00, 0x00, 0x00, 0x00      // 0x1C: number of hidden sectors (always 0 for non-partitioned media)
+  ],
   [                             // define BPB for 360Kb diskette
     0xEB, 0xFE, 0x90,           // 0x00: JMP instruction, following by 8-byte OEM signature
     0x50, 0x43, 0x4A, 0x53, 0x2E, 0x4F, 0x52, 0x47,     // PCJS_OEM
@@ -1903,7 +1903,7 @@ DiskDump.prototype.buildVolLabel = function(sDir)
             }
         }
     }
-    if (!sVolume) {
+    if (!sVolume || sVolume.toLowerCase() == "archive" || sVolume.toLowerCase() == "disk") {
         sVolume = DiskDump.PCJS_LABEL;
     }
     if (sVolume && sVolume.length <= 11) {
@@ -2375,13 +2375,22 @@ DiskDump.prototype.buildImageFromFiles = function(aFiles, done)
      * Find or build a BPB with enough capacity, and at the same time, calculate all the other values we'll need,
      * including total number of data sectors (cDataSectors).
      *
-     * TODO: For now, the code that chooses a default BPB is starting with #3 instead of #0, because Windows 95
+     * TODO: For now, the code that chooses a default BPB starts with entry #3 instead of #0, because Windows 95
      * (at least when running under VMware) fails to read the contents of such disks correctly.  Whether that's my
      * fault or Windows 95's fault is still TBD (although it's probably mine -- perhaps 160Kb diskettes aren't
-     * supposed to have BPBs?)  The simple work-around is to avoid creating 160Kb diskette images (and, to play it
+     * supposed to have BPBs?)  The simple work-around is to avoid creating 160Kb diskette images used by PC-DOS 1.0.
-     * safe, I skip 180Kb and 320Kb as well, since 360Kb was the most commonly used format after DOS 2.0 introduced it).
+     * To play it safe, I also skip the 320Kb format (added for PC-DOS 1.1).  360Kb was the most commonly used format
+     * after PC-DOS 2.0 introduced it.  PC-DOS 2.0 also introduced 180Kb (a single-sided version of the 360Kb
+     * double-sided format), but it's less commonly used.
+     *
+     * UPDATE: I've undone the above change, because when creating a disk image for an old application like:
+     *
+     *      /apps/pcx86/1983/adventmath ["Adventures in Math" (1983)]
+     *
+     * it's important to create a disk image that will work with PC-DOS 1.0, which didn't understand 180Kb and 360Kb
+     * disk images.
      */
-    for (var iBPB = 3; iBPB < DiskDump.aDefaultBPBs.length; iBPB++) {
+    for (var iBPB = 0; iBPB < DiskDump.aDefaultBPBs.length; iBPB++) {
         /*
          * Use slice() to copy the default BPB, as a precaution (to avoid any changes to the default).
          */