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

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

Browse source
This commit is contained in:
Jeff Parsons 2017-06-14 16:02:03 -07:00 • committed by Jeff Parsons
commit f8eeed79bf
6 changed files with 95 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
apps/pcx86/1983/adventmath/ADVENTMATH-CRASH.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 177 KiB

2
apps/pcx86/1983/adventmath/ADVENTMATH100.json
View file

File diff suppressed because one or more lines are too long

72
apps/pcx86/1983/adventmath/README.md
View file

@ -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 contents of their ZIP archive contains:
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 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".
However, if you dig around a bit more on the Internet Archive, you discover that
It's unfortunate that the archive did not contain a complete dump of the original "Adventures in Math" diskette.
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
directory containing just those files:
All those files have been deleted as well, leaving 8 files dated "Aug 11 1983". Next, I used the PCjs
[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)

2
apps/pcx86/1983/adventmath/manifest.xml
View file

@ -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>

2
disks/pcx86/README.md
View file

@ -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/)

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

@ -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
* safe, I skip 180Kb and 320Kb as well, since 360Kb was the most commonly used format after DOS 2.0 introduced it).
* supposed to have BPBs?) The simple work-around is to avoid creating 160Kb diskette images used by PC-DOS 1.0.
* 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).
*/