To those people familiar with the MS-DOS command prompt, have you ever wondered how similar tasks are accomplished with non-PC compatible systems? Well, I am one of those people and I have wondered, so I have written this blog article to compare common disk operations with the DOS for the IBM PC, the Apple II and the Commodore 64 (and VIC-20) to compare how these tasks might or might not be accomplished on each system.
Showing posts with label DOS. Show all posts
Showing posts with label DOS. Show all posts
Sunday, June 22, 2025
Friday, December 2, 2022
So Many Floppies! - Late DOS/Early Windows Era Installations
The CD-ROM format continually promised to make floppy disks obsolete. First introduced in a usable form in 1986, the CD-ROM's 650MiB capacity was enormous when 1.2MiB 5.25" floppies were largest available removable media at the time and hard drives maxed out at around 50 MiB. While CD-ROMs were standard equipment on current PCs by 1995 and the principal method for software installation by that year, the PCs reliance on floppy disks for operating system installation lasted for much longer than anyone anticipated. How long you ask? Let's find out.
Saturday, September 6, 2014
A: B: and C: (and later D:)
A Brief Overview of the History of Disk Drives and DOS
MS-DOS assigns drive letters to disk drives, whether they are physical drives or virtual drives. All user-level drive access through DOS is via drive letters. This is why to copy a file from drive A: to drive B:, you can type at the command prompt :
copy b:\myfile.txt a:
The PC BIOS itself had no concept of drive letters, all it originally acknowledged were floppy controllers. (The PC and PCjr. BIOSes also had routines to interface with a cassette recorder, but this was not accomplished with specialized hardware and is unique to these systems). The PC Floppy controller could originally support two internal drives and two external drives, but few systems ever used a four drive system.
Due to the flexibility of the PC expansion bus, just about any kind of storage device could be made to work with the computer. A tape drive, for example, may attach to a specialized interface card. Later, it would likely be SCSI compatible and attach via a SCSI interface card. An internal hard drive could use an ST-506 MFM or RLL style controller with the separate command and data ribbons, an IDE interface card or a SCSI interface card. In order to do anything with these devices, either the PC BIOS had to be aware of them, they had to have BIOS extension ROMs on their interface cards, device drivers for the operating system with which they were intended to work or a specialized program that could talk directly to the card via I/O ports or its upper memory range.
In the days of PC-DOS 1.0-3.2, it would have been very unlikely for drive letters to get above C:. This is because most computers used two floppy drives at best and hard drives were not yet ubiquitous. A standard MFM controller could control a pair of drives, but not all systems had four half height 5.25" drive bays. MFM controllers were generally limited to internal hard drives. More importantly, hard drives cost a great deal in the 1980s, often half the price of a computer was due to the purchase of hard drives.
The use of the letters of the alphabet to access drives seemed reasonable at the time. The concept of someone having twenty-six physical drives in a system was still more fantasy than reality. Then DOS 3.3 came along with support for the creation of logical drives within the extended partition. Prior to DOS 4.0, each drive letter could only recognize 32MB of storage. Thus you could have one primary 32MB partition, the boot partition, and an extended partition up to 2GB. Within the extended partition, you could carve out logical drives, each no larger than 32MB. Each drive would get assigned a drive letter. A: and B: being reserved for floppy drives, you could have a maximum amount of usable storage of 768MB in DOS 3.3 (24 x 32MB). Because DOS 4.0 acquired a reputation of being a buggy memory hog, many people stayed with DOS 3.3 until the release of DR-DOS 5.0 in 1990 or MS-DOS 5.0 in 1991.
Even though MS-DOS 3.3 had severe partition limitations, few hard drives of its day came anywhere near 768MB. However, each physical drive had to share the same 24 available drive letters. MS-DOS 5.0 allowed each partition, whether primary or extended, to be up to 2GB. The Int 13h disk BIOS routines only supported 8GB hard drive parameters, and thanks to different ATA IDE limitations, the storage space was even more limited to 504MB until BIOS makers began using workarounds such as LBA and BIOS translation. By the time 2GB hard drives became affordable, Windows 95 was in use.
The CD-ROM drive, despite its read-only capabilities, was to be accessed like a disk drive. While at first it used proprietary interfaces, usually tied to a sound card, eventually it would usually use IDE or SCSI interfaces. While DOS increased its support for hard drive capacities over the years and the PC BIOSes added support for the standard AT-IDE interface starting with the IBM PC AT, full support for CD-ROM drives was never included in the BIOS and DOS never integrated it into its core operating files. Instead, the CD-ROM was accessed through a device driver specific to the drive and interface loaded in CONFIG.SYS and MS-DOS CD-ROM extensions program MSCDEX loaded in AUTOEXEC.BAT. MSCDEX would assign a drive letter to the CD-ROM drive.
Each set of IDE ports can support a master and a slave drive, and the PC can support up to four sets of IDE ports, the primary, secondary, tertiary and quaternary. With IDE you can have eight devices, assuming you have a tower large enough to hold them. One SCSI interface can support seven or fifteen devices (the interface counts as a device), depending on the SCSI version.
Drive Letter Assignment Over the Years
With the IBM PC, which only supported full height drives and typically came with two 5.25" full height double density Tandon TM100-1 (single sided) or -2A (double sided) drives, one drive was Drive A: and the other drive was Drive B: There were only two bays for disk drives and they were only designed to support full-height drives. More adventurous PC owners could find a third-party kit to mount two half-height drives in the full height bay, use a hard card or an external disk drive. The IBM PCjr. only supported one disk drive, and it was Drive A: and B:, DOS being able to redirect commands meant for Drive B: to Drive A:
The IBM PC/XT shared the same number of bays as the PC and originally came with one 5.25" full height Tandon TM100-2A and one 10MB ST-412 MFM full height hard disk drive. You might think that the hard drive would be assigned to Drive B:, but to maintain compatibility with two floppy disk systems, DOS 2.0 assigned it to drive C: With the IBM PC AT, with two external half height bays and one internal half height bay, drives A:, B; and C: were now quite feasible. A typical AT configuration would have one 1.2MB half height drive and one 360KB half height drive (for compatibility with double density disks) and a 20MB internal hard drive. Unlike the PC and XT floppy controller, the AT hard disk and floppy controller did not have a port on the bracket for external floppy drives, so the two floppy drive maximum limit was firmly established with these machines.
Nonetheless, PC and MS-DOS 1.0-3.3 and DR-DOS up to and including 6.0 assigned drive letters to the first four floppy drives, then to other kinds of drives. PC and MS-DOS 4.0 and above, reflecting a greater understanding of how PCs were actually used, assigned A: and B: to floppy drives, then C: and letters thereafter to hard drives, and then it assigned letters to any further floppy drives the user may have in the system.
However, drive lettering after C: was very flexible in DOS, and as most home users only had one hard drive, CD-ROM programs typically ran off Drive D: In fact, there are some games, both for DOS and Windows 3.x and 9x, that refuse to run unless run off Drive D: MSCDEX could reserve Drive D: for the CD-ROM drive, and hard drive partitions could be assigned to use Drive E: or above.
Even today with Windows 8.1, much of this drive lettering arrangement is still followed. Drive letters A: and B: are still reserved for floppy drives, even though a typical user is unlikely to have physical floppy drives in his modern system. Fortunately, floppy drive emulators can use A: and B: without difficulty. Drive C: is always a boot drive. Thereafter, things get very flexible. Dual-boot Windows systems, like Windows XP and Windows 7 can each be Drive C:, depending on which OS is being active. Drive C: can be just about anything except a floppy (too small) or an CD/DVD/Blu-ray (not made for rewriting) drive. It could be a hard disk drive, a solid state drive, a Compact Flash or SD Card or a USB stick. Drive D: and above could be an optical drive, physical or virtual or any of the above. Windows will let you assign whatever drive letter you want. However, there is no Drive AA:, even in Windows 8.1. The twenty-three available drive letters can get fully used today.
The Ideal Vintage Drive Setup
I believe that if you are buying a specific system, like an IBM PC Model 5150, a Compaq Portable or a Tandy 1000 RLX-HD, it is usually preferable to stick with the drives it came with, especially the floppy drives, assuming they work. For systems with few bays, using things like CF cards or DOMs mounted directly onto an XT-IDE header may be required.
For systems of the 1980s, it is typically best to have at least one 360KB drive and one 720KB drive, where possible, and a hard drive. Actually, virtually any 1.44MB drive will work as a 720KB drive, which can be rare. The same cannot be said for 1.2MB drives, and generally they were not used for games during the 1980s. With such a setup, you have your A: B: and C:, and you can play just about anything.
For systems of the 1990s, it is best to have one 1.44MB drive, one 1.2MB drive and one CD-ROM (early to mid-90s) or DVD-ROM (late 90s) drive with a hard drive. With your optical drive as D:, you have one of everything. For the late 1990s, you can get away with the 1.44MB drive, or no floppy drive at all if you have no need for a boot disk. Unfortunately, all floppy drive emulators that I know of require at least Windows 2000.
MS-DOS assigns drive letters to disk drives, whether they are physical drives or virtual drives. All user-level drive access through DOS is via drive letters. This is why to copy a file from drive A: to drive B:, you can type at the command prompt :
copy b:\myfile.txt a:
The PC BIOS itself had no concept of drive letters, all it originally acknowledged were floppy controllers. (The PC and PCjr. BIOSes also had routines to interface with a cassette recorder, but this was not accomplished with specialized hardware and is unique to these systems). The PC Floppy controller could originally support two internal drives and two external drives, but few systems ever used a four drive system.
Due to the flexibility of the PC expansion bus, just about any kind of storage device could be made to work with the computer. A tape drive, for example, may attach to a specialized interface card. Later, it would likely be SCSI compatible and attach via a SCSI interface card. An internal hard drive could use an ST-506 MFM or RLL style controller with the separate command and data ribbons, an IDE interface card or a SCSI interface card. In order to do anything with these devices, either the PC BIOS had to be aware of them, they had to have BIOS extension ROMs on their interface cards, device drivers for the operating system with which they were intended to work or a specialized program that could talk directly to the card via I/O ports or its upper memory range.
In the days of PC-DOS 1.0-3.2, it would have been very unlikely for drive letters to get above C:. This is because most computers used two floppy drives at best and hard drives were not yet ubiquitous. A standard MFM controller could control a pair of drives, but not all systems had four half height 5.25" drive bays. MFM controllers were generally limited to internal hard drives. More importantly, hard drives cost a great deal in the 1980s, often half the price of a computer was due to the purchase of hard drives.
The use of the letters of the alphabet to access drives seemed reasonable at the time. The concept of someone having twenty-six physical drives in a system was still more fantasy than reality. Then DOS 3.3 came along with support for the creation of logical drives within the extended partition. Prior to DOS 4.0, each drive letter could only recognize 32MB of storage. Thus you could have one primary 32MB partition, the boot partition, and an extended partition up to 2GB. Within the extended partition, you could carve out logical drives, each no larger than 32MB. Each drive would get assigned a drive letter. A: and B: being reserved for floppy drives, you could have a maximum amount of usable storage of 768MB in DOS 3.3 (24 x 32MB). Because DOS 4.0 acquired a reputation of being a buggy memory hog, many people stayed with DOS 3.3 until the release of DR-DOS 5.0 in 1990 or MS-DOS 5.0 in 1991.
Even though MS-DOS 3.3 had severe partition limitations, few hard drives of its day came anywhere near 768MB. However, each physical drive had to share the same 24 available drive letters. MS-DOS 5.0 allowed each partition, whether primary or extended, to be up to 2GB. The Int 13h disk BIOS routines only supported 8GB hard drive parameters, and thanks to different ATA IDE limitations, the storage space was even more limited to 504MB until BIOS makers began using workarounds such as LBA and BIOS translation. By the time 2GB hard drives became affordable, Windows 95 was in use.
The CD-ROM drive, despite its read-only capabilities, was to be accessed like a disk drive. While at first it used proprietary interfaces, usually tied to a sound card, eventually it would usually use IDE or SCSI interfaces. While DOS increased its support for hard drive capacities over the years and the PC BIOSes added support for the standard AT-IDE interface starting with the IBM PC AT, full support for CD-ROM drives was never included in the BIOS and DOS never integrated it into its core operating files. Instead, the CD-ROM was accessed through a device driver specific to the drive and interface loaded in CONFIG.SYS and MS-DOS CD-ROM extensions program MSCDEX loaded in AUTOEXEC.BAT. MSCDEX would assign a drive letter to the CD-ROM drive.
Each set of IDE ports can support a master and a slave drive, and the PC can support up to four sets of IDE ports, the primary, secondary, tertiary and quaternary. With IDE you can have eight devices, assuming you have a tower large enough to hold them. One SCSI interface can support seven or fifteen devices (the interface counts as a device), depending on the SCSI version.
Drive Letter Assignment Over the Years
With the IBM PC, which only supported full height drives and typically came with two 5.25" full height double density Tandon TM100-1 (single sided) or -2A (double sided) drives, one drive was Drive A: and the other drive was Drive B: There were only two bays for disk drives and they were only designed to support full-height drives. More adventurous PC owners could find a third-party kit to mount two half-height drives in the full height bay, use a hard card or an external disk drive. The IBM PCjr. only supported one disk drive, and it was Drive A: and B:, DOS being able to redirect commands meant for Drive B: to Drive A:
The IBM PC/XT shared the same number of bays as the PC and originally came with one 5.25" full height Tandon TM100-2A and one 10MB ST-412 MFM full height hard disk drive. You might think that the hard drive would be assigned to Drive B:, but to maintain compatibility with two floppy disk systems, DOS 2.0 assigned it to drive C: With the IBM PC AT, with two external half height bays and one internal half height bay, drives A:, B; and C: were now quite feasible. A typical AT configuration would have one 1.2MB half height drive and one 360KB half height drive (for compatibility with double density disks) and a 20MB internal hard drive. Unlike the PC and XT floppy controller, the AT hard disk and floppy controller did not have a port on the bracket for external floppy drives, so the two floppy drive maximum limit was firmly established with these machines.
Nonetheless, PC and MS-DOS 1.0-3.3 and DR-DOS up to and including 6.0 assigned drive letters to the first four floppy drives, then to other kinds of drives. PC and MS-DOS 4.0 and above, reflecting a greater understanding of how PCs were actually used, assigned A: and B: to floppy drives, then C: and letters thereafter to hard drives, and then it assigned letters to any further floppy drives the user may have in the system.
However, drive lettering after C: was very flexible in DOS, and as most home users only had one hard drive, CD-ROM programs typically ran off Drive D: In fact, there are some games, both for DOS and Windows 3.x and 9x, that refuse to run unless run off Drive D: MSCDEX could reserve Drive D: for the CD-ROM drive, and hard drive partitions could be assigned to use Drive E: or above.
Even today with Windows 8.1, much of this drive lettering arrangement is still followed. Drive letters A: and B: are still reserved for floppy drives, even though a typical user is unlikely to have physical floppy drives in his modern system. Fortunately, floppy drive emulators can use A: and B: without difficulty. Drive C: is always a boot drive. Thereafter, things get very flexible. Dual-boot Windows systems, like Windows XP and Windows 7 can each be Drive C:, depending on which OS is being active. Drive C: can be just about anything except a floppy (too small) or an CD/DVD/Blu-ray (not made for rewriting) drive. It could be a hard disk drive, a solid state drive, a Compact Flash or SD Card or a USB stick. Drive D: and above could be an optical drive, physical or virtual or any of the above. Windows will let you assign whatever drive letter you want. However, there is no Drive AA:, even in Windows 8.1. The twenty-three available drive letters can get fully used today.
The Ideal Vintage Drive Setup
I believe that if you are buying a specific system, like an IBM PC Model 5150, a Compaq Portable or a Tandy 1000 RLX-HD, it is usually preferable to stick with the drives it came with, especially the floppy drives, assuming they work. For systems with few bays, using things like CF cards or DOMs mounted directly onto an XT-IDE header may be required.
For systems of the 1980s, it is typically best to have at least one 360KB drive and one 720KB drive, where possible, and a hard drive. Actually, virtually any 1.44MB drive will work as a 720KB drive, which can be rare. The same cannot be said for 1.2MB drives, and generally they were not used for games during the 1980s. With such a setup, you have your A: B: and C:, and you can play just about anything.
For systems of the 1990s, it is best to have one 1.44MB drive, one 1.2MB drive and one CD-ROM (early to mid-90s) or DVD-ROM (late 90s) drive with a hard drive. With your optical drive as D:, you have one of everything. For the late 1990s, you can get away with the 1.44MB drive, or no floppy drive at all if you have no need for a boot disk. Unfortunately, all floppy drive emulators that I know of require at least Windows 2000.
Friday, September 5, 2014
Flavors of PC Compatible BASIC and Why You Should Care
Cassette BASIC :
In 1981, when IBM released the IBM PC Model 5150, it included BASIC in ROM. In the 5150, it was contained on four 8KB chips, in later machines, it was included within the 32KB chips that included the BIOS. In every IBM PC model it occupies the space from F600:0000 to FDFF:0000.
Cassette BASIC, as its name implies, has commands for saving and loading only to a compact cassette. In order to save to or load a program from a cassette, the user needed to connect a cassette drive to his IBM PC with a special cable. On the back of the IBM PC Model 5150, there was a 5-pin DIN next to the keyboard DIN that this cable would plug into. At the other end of the cable there would be a 3.2mm audio jack for the auxiliary or microphone input (to save/record data from a PC), a 3.2mm audio jack for the earphone output (to load/playback data to the PC), and a 2.5mm jack to control the tape recorder remotely. The PC had a relay circuit on the motherboard that would start and stop the motor so that the user would not have to.
IBM did not offer a cable for the 5150, but Tandy/Radio Shack TRS-80 and Color Computer tape recorders came with the correct cable. Most older tape recorders, including those Radio Shack sold for their non-PC compatibles, had four audio jacks, the EAR, REM, MIC and AUX. Current recorders ditch the AUX input and only have a MIC input. REM is the smaller jack that controls the cassette deck. There was a jumper on the system board to set the appropriate signal strength for a MIC input or an AUX input.
Cassette BASIC comes in three versions, C1.0, C1.1 and C1.2. C1.0 will only be found in the very first IBM PCs, typically those with a 16-64KB system board and a BIOS version dated 04/24/81 or 10/19/81. C1.1 generally should come with all IBM PC Model 5150s with a 64-256KB system board or those systems with a BIOS version dated 10/27/82 (the last). However, the BIOS in the IBM PC is contained in one chip, U33, and can be updated in an 16-64KB system board without updating BASIC.
All later IBM PCs, the XT, Portable, AT, XT/286 and Convertible, contain Cassette BASIC C1.1. The PCjr. (and probably the PC JX) uses Cassette BASIC C1.2 for reasons described below. All PS/2s released during the 1980s and early 90s, and the early IBM PS/1s, also contain Cassette BASIC C1.1 for compatibility reasons. No other PC Compatible system, unless an exact clone of one of these systems, included Cassette BASIC.
Unlike the disk-based versions of BASIC, Cassette BASIC does not require PC or MS-DOS to run. However, because the IBM PC and IBM PCjr. are the only PC-compatible systems known to come with circuitry to drive a cassette recorder, Cassette BASIC can only save or load programs on these two systems.
Disk BASIC, Advanced BASIC and GW-BASIC :
Disk BASIC and Advanced BASIC were included with PC-DOS v1.0 and every version thereafter, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0 and 4.01. They were replaced by QBASIC in PC-DOS 5.0. The version number for Disk BASIC and Advanced BASIC correspond directly to the version of DOS they came with. This you will see D1.1 for the version of Disk BASIC accompanying PC-DOS 1.1 and A3.3 for the version of Advanced BASIC that came with PC-DOS 3.3. Disk BASIC is invoked by executing BASIC.COM in DOS, and Advanced BASIC by BASICA.COM in DOS.
The Disk BASIC-Advanced BASIC split was due to the low amounts of memory that came with early IBM PCs. You could buy an IBM PC with only 16KB of RAM, but with that amount of RAM, you could only run Cassette BASIC. Disk BASIC required 32KB of RAM, and Advanced BASIC 48KB of RAM. Disk BASIC could do everything that Cassette BASIC could do and added support for saving and loading programs to floppy disks and serial port access, keeping track of the date and time and supporting two additional printers. Advanced BASIC does all Disk BASIC does and more, such as support for more graphics and sound statements and event trapping.
PC BASIC does not support multiple memory segments, it runs everything within one 64KB segment. Thus, after PCs began shipping with 128KB of RAM or more, there was no further need to use Disk BASIC. In fact, as of DOS 3.3, BASIC.COM was just a small (1-2K) stub that called BASICA.COM and was only present for compatibility. DOS 1.0-3.2 had a functional BASIC.COM. PC BASIC would keep up with DOS features, like the added support for subdirectories in DOS 2.0 and the IOCTL calls in DOS 3.0.
With non-IBM machines, vendors and OEMs released system-specific versions of MS-DOS. With these operating systems, GW-BASIC was included. GW-BASIC did not require Cassette BASIC. In these systems, sometimes there is a large BASIC.EXE and a small BASICA.COM. BASICA.COM is the stub that executes BASIC.EXE. Sometimes there is also a BASIC.COM stub. In certain systems, the file was BASICA.EXE or GWBASIC.EXE.
Tandy's GW-BASIC for the Tandy 1000 series included the commands found in Cartridge BASIC to control its PCjr-derived advanced graphics and sound capabilities. The AT&T 6300's GW-BASIC included commands for the advanced graphics capabilities of that system, and the Hercules Graphics Card came with a utilities disk with HBASIC, which allowed the use of the 720x348 graphics mode these cards support. A generic GW-BASIC would not support these special features. Microsoft began releasing generic, non-OEM specific versions of MS-DOS starting with MS-DOS 3.2. A generic version of GW-BASIC can be found on them.
IBM also released Compiler BASIC which allowed users to compile their program into object code so it does not require a BASIC interpreter to run the program. Most companies that released games found it simpler to run their code through an interpreter, because every computer with a disk drive and DOS should have had one during the 1980s.
Cartridge BASIC :
The PCjr. included Cassette BASIC C1.2 in its system ROM. Due to the differences between the PC and PCjr., the BASIC code cannot be identical. However, to maintain compatibility with applications written for Cassette BASIC, all the functionality of PC Cassette BASIC is included in PCjr. Cassette BASIC, and nothing more. IBM released an official cassette cable that plugged into a unique male BERG-style port on the PCjr., but it requires a cassette recorder with an AUX input.
IBM released Cartridge BASIC with the PCjr., and the user had to buy it separately. It is a 32KB cartridge that plugs into either cartridge slot of the PCjr. Cartridge BASIC included commands to take advantage of the PCjr. video adapter and sound chip. Cartridge BASIC has only one version, J1.0. Disk BASIC and Advanced BASIC, when run on the PCjr., will show the version as J1.0, regardless of DOS version. Disk BASIC and Advanced BASIC will not run unless Cartridge BASIC is present.
Using Cartridge BASIC in a PCjr. with more than 128KB of RAM imposes special problems. Cartridge BASIC was not designed for more than 128KB, and programs run it may not run correctly or at all. However, the PCjr. will not recognize extra RAM unless a device driver is loaded in DOS. If DOS is loaded, either from a disk or a hard drive without a device driver loaded, then Cartridge BASIC should run normally. You will be limited to the first 128KB of RAM and the poor performance resulting by running BASIC code within it. The popular device driver JRCONFIG 3.1 included an unsupported /q command line switch where it will lie about the amount of memory available to BASIC, but it will warn you that anything contained in a RAM Disk or Print Spooler created by JRCONFIG will be in danger.
QBASIC :
In PC-DOS 5.0 and MS-DOS 5.0, Disk BASIC and Advanced BASIC were no longer included with the operating system. Instead, QBASIC version 1.0 was included. QBASIC was a cut down version of Microsoft QuickBASIC. QBASIC does not require line numbers and supports a mouse cursor, split windows, drop down menus and multiple colors in its text-based user interface. The MS-DOS EDIT.EXE program requires QBASIC.EXE, QBASIC.HLP and EDIT.HLP to work. QBASIC tends to be a poor performer on 8088-based XT-class and low speed 286-based AT-class machines.
I read that the original version of QBASIC in PC-DOS 5.0 still required Cassette BASIC in ROM, but it only used checked to see that it was there before loading QBASIC. This requirement was removed in the QBASIC that came with PC-DOS 5.02. QBASIC version 1.1 was included in MS-DOS 6.0 through Windows ME and NT 4.0.
BASIC Games :
The first game ever written for the IBM PC was Donkey. This simple game was included as the file DONKEY.BAS with several other demonstration programs included on the DOS disks. In fact, half the files included in PC-DOS 1.0 and 1.1 were BASIC demonstration programs. It is included with PC-DOS 1.0-3.2. With DOS 3.3, virtually all the demo programs were eliminated.
QBASIC in MS-DOS 5.0 and PC-DOS 5.0 came with two games, Gorillas and Nibbles. Their files are called GORILLA.BAS and NIBBLES.BAS. Nibbles is a text mode game that uses an 80x25 column mode, but appears as a 80x50 column mode by the use of a half-bar ASCII character (where the top half uses the foreground color and the bottom half uses the background color). It works with any video adapter. Gorillas uses either the 320x200x4 CGA Mode 04 or the 640x350x16 EGA Mode 0F. They are intended to be run on a low-end 386 or a high end 286. Both games would be gone by MS-DOS 6.22 and PC-DOS 6.1
Games Requiring BASIC :
Several games, usually early games, used Cassette/Disk/Advanced BASIC. Some were copy-protected DOS disks that directly accessed Cassette BASIC. They must be run on an IBM system. Nine games commercially released by IBM early in the life of its PC line require Cassette BASIC or Cartridge BASIC. They are
Adventures in Math
Arithmetic Games Set 1*
Arithmetic Games Set 2*
Bumble Games*
Bumble Plot*
Casino Games
Juggles Butterfly*
Monster Math
Strategy Games
* - Copy Protected (The Learning Company games) or probably Copy Protected (Science Research Associates, Inc.) IBM never seemed to copy protect the games it developed internally, but did with any game it released that was licensed from or developed by another company. Any game that is not copy protected, or has been cracked to run on a generic disk should be able to be run with GW-BASIC. Mobygames lists 75 games that require BASIC, and some are sophisticated commercial releases like Battle of the Bulge, some are old classics like Temple of Apshai and others are small single file games that just need a BASIC interpreter. There are many, many freeware games that run on QBASIC, and while Mobygames may not document every Cassette/Disk/Advanced BASIC game ever made, it does not really list any games that use QBASIC other than Gorillas an Nibbles. A good place to start to find QBASIC games is here :
http://www.qbasic.com/games/
http://www.petesqbsite.com/index.php
In 1981, when IBM released the IBM PC Model 5150, it included BASIC in ROM. In the 5150, it was contained on four 8KB chips, in later machines, it was included within the 32KB chips that included the BIOS. In every IBM PC model it occupies the space from F600:0000 to FDFF:0000.
Cassette BASIC, as its name implies, has commands for saving and loading only to a compact cassette. In order to save to or load a program from a cassette, the user needed to connect a cassette drive to his IBM PC with a special cable. On the back of the IBM PC Model 5150, there was a 5-pin DIN next to the keyboard DIN that this cable would plug into. At the other end of the cable there would be a 3.2mm audio jack for the auxiliary or microphone input (to save/record data from a PC), a 3.2mm audio jack for the earphone output (to load/playback data to the PC), and a 2.5mm jack to control the tape recorder remotely. The PC had a relay circuit on the motherboard that would start and stop the motor so that the user would not have to.
IBM did not offer a cable for the 5150, but Tandy/Radio Shack TRS-80 and Color Computer tape recorders came with the correct cable. Most older tape recorders, including those Radio Shack sold for their non-PC compatibles, had four audio jacks, the EAR, REM, MIC and AUX. Current recorders ditch the AUX input and only have a MIC input. REM is the smaller jack that controls the cassette deck. There was a jumper on the system board to set the appropriate signal strength for a MIC input or an AUX input.
Cassette BASIC comes in three versions, C1.0, C1.1 and C1.2. C1.0 will only be found in the very first IBM PCs, typically those with a 16-64KB system board and a BIOS version dated 04/24/81 or 10/19/81. C1.1 generally should come with all IBM PC Model 5150s with a 64-256KB system board or those systems with a BIOS version dated 10/27/82 (the last). However, the BIOS in the IBM PC is contained in one chip, U33, and can be updated in an 16-64KB system board without updating BASIC.
All later IBM PCs, the XT, Portable, AT, XT/286 and Convertible, contain Cassette BASIC C1.1. The PCjr. (and probably the PC JX) uses Cassette BASIC C1.2 for reasons described below. All PS/2s released during the 1980s and early 90s, and the early IBM PS/1s, also contain Cassette BASIC C1.1 for compatibility reasons. No other PC Compatible system, unless an exact clone of one of these systems, included Cassette BASIC.
Unlike the disk-based versions of BASIC, Cassette BASIC does not require PC or MS-DOS to run. However, because the IBM PC and IBM PCjr. are the only PC-compatible systems known to come with circuitry to drive a cassette recorder, Cassette BASIC can only save or load programs on these two systems.
Disk BASIC, Advanced BASIC and GW-BASIC :
Disk BASIC and Advanced BASIC were included with PC-DOS v1.0 and every version thereafter, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0 and 4.01. They were replaced by QBASIC in PC-DOS 5.0. The version number for Disk BASIC and Advanced BASIC correspond directly to the version of DOS they came with. This you will see D1.1 for the version of Disk BASIC accompanying PC-DOS 1.1 and A3.3 for the version of Advanced BASIC that came with PC-DOS 3.3. Disk BASIC is invoked by executing BASIC.COM in DOS, and Advanced BASIC by BASICA.COM in DOS.
The Disk BASIC-Advanced BASIC split was due to the low amounts of memory that came with early IBM PCs. You could buy an IBM PC with only 16KB of RAM, but with that amount of RAM, you could only run Cassette BASIC. Disk BASIC required 32KB of RAM, and Advanced BASIC 48KB of RAM. Disk BASIC could do everything that Cassette BASIC could do and added support for saving and loading programs to floppy disks and serial port access, keeping track of the date and time and supporting two additional printers. Advanced BASIC does all Disk BASIC does and more, such as support for more graphics and sound statements and event trapping.
PC BASIC does not support multiple memory segments, it runs everything within one 64KB segment. Thus, after PCs began shipping with 128KB of RAM or more, there was no further need to use Disk BASIC. In fact, as of DOS 3.3, BASIC.COM was just a small (1-2K) stub that called BASICA.COM and was only present for compatibility. DOS 1.0-3.2 had a functional BASIC.COM. PC BASIC would keep up with DOS features, like the added support for subdirectories in DOS 2.0 and the IOCTL calls in DOS 3.0.
With non-IBM machines, vendors and OEMs released system-specific versions of MS-DOS. With these operating systems, GW-BASIC was included. GW-BASIC did not require Cassette BASIC. In these systems, sometimes there is a large BASIC.EXE and a small BASICA.COM. BASICA.COM is the stub that executes BASIC.EXE. Sometimes there is also a BASIC.COM stub. In certain systems, the file was BASICA.EXE or GWBASIC.EXE.
Tandy's GW-BASIC for the Tandy 1000 series included the commands found in Cartridge BASIC to control its PCjr-derived advanced graphics and sound capabilities. The AT&T 6300's GW-BASIC included commands for the advanced graphics capabilities of that system, and the Hercules Graphics Card came with a utilities disk with HBASIC, which allowed the use of the 720x348 graphics mode these cards support. A generic GW-BASIC would not support these special features. Microsoft began releasing generic, non-OEM specific versions of MS-DOS starting with MS-DOS 3.2. A generic version of GW-BASIC can be found on them.
IBM also released Compiler BASIC which allowed users to compile their program into object code so it does not require a BASIC interpreter to run the program. Most companies that released games found it simpler to run their code through an interpreter, because every computer with a disk drive and DOS should have had one during the 1980s.
Cartridge BASIC :
The PCjr. included Cassette BASIC C1.2 in its system ROM. Due to the differences between the PC and PCjr., the BASIC code cannot be identical. However, to maintain compatibility with applications written for Cassette BASIC, all the functionality of PC Cassette BASIC is included in PCjr. Cassette BASIC, and nothing more. IBM released an official cassette cable that plugged into a unique male BERG-style port on the PCjr., but it requires a cassette recorder with an AUX input.
IBM released Cartridge BASIC with the PCjr., and the user had to buy it separately. It is a 32KB cartridge that plugs into either cartridge slot of the PCjr. Cartridge BASIC included commands to take advantage of the PCjr. video adapter and sound chip. Cartridge BASIC has only one version, J1.0. Disk BASIC and Advanced BASIC, when run on the PCjr., will show the version as J1.0, regardless of DOS version. Disk BASIC and Advanced BASIC will not run unless Cartridge BASIC is present.
Using Cartridge BASIC in a PCjr. with more than 128KB of RAM imposes special problems. Cartridge BASIC was not designed for more than 128KB, and programs run it may not run correctly or at all. However, the PCjr. will not recognize extra RAM unless a device driver is loaded in DOS. If DOS is loaded, either from a disk or a hard drive without a device driver loaded, then Cartridge BASIC should run normally. You will be limited to the first 128KB of RAM and the poor performance resulting by running BASIC code within it. The popular device driver JRCONFIG 3.1 included an unsupported /q command line switch where it will lie about the amount of memory available to BASIC, but it will warn you that anything contained in a RAM Disk or Print Spooler created by JRCONFIG will be in danger.
QBASIC :
In PC-DOS 5.0 and MS-DOS 5.0, Disk BASIC and Advanced BASIC were no longer included with the operating system. Instead, QBASIC version 1.0 was included. QBASIC was a cut down version of Microsoft QuickBASIC. QBASIC does not require line numbers and supports a mouse cursor, split windows, drop down menus and multiple colors in its text-based user interface. The MS-DOS EDIT.EXE program requires QBASIC.EXE, QBASIC.HLP and EDIT.HLP to work. QBASIC tends to be a poor performer on 8088-based XT-class and low speed 286-based AT-class machines.
I read that the original version of QBASIC in PC-DOS 5.0 still required Cassette BASIC in ROM, but it only used checked to see that it was there before loading QBASIC. This requirement was removed in the QBASIC that came with PC-DOS 5.02. QBASIC version 1.1 was included in MS-DOS 6.0 through Windows ME and NT 4.0.
BASIC Games :
The first game ever written for the IBM PC was Donkey. This simple game was included as the file DONKEY.BAS with several other demonstration programs included on the DOS disks. In fact, half the files included in PC-DOS 1.0 and 1.1 were BASIC demonstration programs. It is included with PC-DOS 1.0-3.2. With DOS 3.3, virtually all the demo programs were eliminated.
QBASIC in MS-DOS 5.0 and PC-DOS 5.0 came with two games, Gorillas and Nibbles. Their files are called GORILLA.BAS and NIBBLES.BAS. Nibbles is a text mode game that uses an 80x25 column mode, but appears as a 80x50 column mode by the use of a half-bar ASCII character (where the top half uses the foreground color and the bottom half uses the background color). It works with any video adapter. Gorillas uses either the 320x200x4 CGA Mode 04 or the 640x350x16 EGA Mode 0F. They are intended to be run on a low-end 386 or a high end 286. Both games would be gone by MS-DOS 6.22 and PC-DOS 6.1
Games Requiring BASIC :
Several games, usually early games, used Cassette/Disk/Advanced BASIC. Some were copy-protected DOS disks that directly accessed Cassette BASIC. They must be run on an IBM system. Nine games commercially released by IBM early in the life of its PC line require Cassette BASIC or Cartridge BASIC. They are
Adventures in Math
Arithmetic Games Set 1*
Arithmetic Games Set 2*
Bumble Games*
Bumble Plot*
Casino Games
Juggles Butterfly*
Monster Math
Strategy Games
* - Copy Protected (The Learning Company games) or probably Copy Protected (Science Research Associates, Inc.) IBM never seemed to copy protect the games it developed internally, but did with any game it released that was licensed from or developed by another company. Any game that is not copy protected, or has been cracked to run on a generic disk should be able to be run with GW-BASIC. Mobygames lists 75 games that require BASIC, and some are sophisticated commercial releases like Battle of the Bulge, some are old classics like Temple of Apshai and others are small single file games that just need a BASIC interpreter. There are many, many freeware games that run on QBASIC, and while Mobygames may not document every Cassette/Disk/Advanced BASIC game ever made, it does not really list any games that use QBASIC other than Gorillas an Nibbles. A good place to start to find QBASIC games is here :
http://www.qbasic.com/games/
http://www.petesqbsite.com/index.php
Thursday, January 16, 2014
A Tale of Two Configs
In an MS-DOS system with a 386 or better processor, when it comes to configuring the OS, typically the issue is whether to load or not to load EMM386.EXE. Loading EMM386.EXE puts the machine into Virtual 8086 mode, and using EMM386 to make expanded memory available substantially decreases the amount of upper memory available to load drivers. Fortunately, you need not make expanded memory available unless a program requires it. EMM386 is used to make upper memory available for loading device drivers, and without it, those drivers must be loaded in conventional memory. If those drivers cause the amount of free memory to be lower than the amount a program requires, the program will not load. Use of EMM386.EXE is utterly incompatible certain programs like Ultima VII Parts I & II. On the other hand, many other contemporary games require expanded memory to support sound. Other games don't care either way.
HIMEM.SYS, which provides access to all the memory above 640KB, is essential to load and should always be loaded . EMM386.EXE requires HIMEM.SYS to be loaded first. HIMEM.SYS provides access to the high memory area and allows DOS to load most of itself there, significantly cutting down on the conventional memory DOS would otherwise take up. For programs that require or can use it, it also makes extended memory available.
For MS-DOS 6.22, a typical 486 computer setup with a mouse, CD-ROM drive and a Sound Blaster 16 may have a CONFIG.SYS like this :
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF FRAME=E000
DOS=HIGH,UMB
FILES=40
BUFFERS=30
DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
and a typical AUTOEXEC.BAT file may look like this :
@ECHO OFF
PROMPT $P$G
PATH=C:\;C:\DOS;C:\SB16
SET BLASTER=A220 I7 D1 H5 P330 T6
SET SOUND=C:\SB16
SET MIDI=SYNTH:1 MAP:E
C:\SB16\DIAGNOSE /S
C:\SB16\MIXERSET /P /Q
LH C:\DOS\MSCDEX.EXE /D:MSCD001
LH CTMOUSE.EXE
My 486 uses roughly these lines in its AUTOEXEC.BAT and CONFIG.SYS. Lets describe what each line does, starting with the first line of CONFIG.SYS :
1. DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
HIMEM.SYS is a Device Driver that must be loaded in CONFIG.SYS on startup. The config.sys command to load a device driver is DEVICE=. The full path where a device driver can be found must be included. HIMEM.SYS is primarily used to allow DOS to access the High Memory Area, but it also functions as an eXtended Memory Manager (XMM), giving your programs access to eXtended Memory Specification (XMS) memory. The /TESTMEM:OFF parameter bypasses a memory test that adds to the boot time on DOS 6.x. It is only useful on 286 or above systems.
2. DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF FRAME=E000
EMM386.EXE can be used as a command or as a device driver. It's primary function is to act as an Expanded Memory Manager (EMM), giving your programs access to Expanded Memory Specification (EMS) memory. It also allows the creation of Upper Memory Blocks (UMB) in the Upper Memory Area (UMA). It is only useful on 386 or above systems. This device driver switches DOS from using real mode into Virtual 8086 mode, and some programs and games refuse to run in this mode. By removing the EMM386.EXE line, those programs that complained about EMM386.EXE and Virtual 8086 mode and refuse to load now will load.
HIMEM.SYS, which provides access to all the memory above 640KB, is essential to load and should always be loaded . EMM386.EXE requires HIMEM.SYS to be loaded first. HIMEM.SYS provides access to the high memory area and allows DOS to load most of itself there, significantly cutting down on the conventional memory DOS would otherwise take up. For programs that require or can use it, it also makes extended memory available.
For MS-DOS 6.22, a typical 486 computer setup with a mouse, CD-ROM drive and a Sound Blaster 16 may have a CONFIG.SYS like this :
DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF FRAME=E000
DOS=HIGH,UMB
FILES=40
BUFFERS=30
DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
and a typical AUTOEXEC.BAT file may look like this :
@ECHO OFF
PROMPT $P$G
PATH=C:\;C:\DOS;C:\SB16
SET BLASTER=A220 I7 D1 H5 P330 T6
SET SOUND=C:\SB16
SET MIDI=SYNTH:1 MAP:E
C:\SB16\DIAGNOSE /S
C:\SB16\MIXERSET /P /Q
LH C:\DOS\MSCDEX.EXE /D:MSCD001
LH CTMOUSE.EXE
My 486 uses roughly these lines in its AUTOEXEC.BAT and CONFIG.SYS. Lets describe what each line does, starting with the first line of CONFIG.SYS :
1. DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF
HIMEM.SYS is a Device Driver that must be loaded in CONFIG.SYS on startup. The config.sys command to load a device driver is DEVICE=. The full path where a device driver can be found must be included. HIMEM.SYS is primarily used to allow DOS to access the High Memory Area, but it also functions as an eXtended Memory Manager (XMM), giving your programs access to eXtended Memory Specification (XMS) memory. The /TESTMEM:OFF parameter bypasses a memory test that adds to the boot time on DOS 6.x. It is only useful on 286 or above systems.
2. DEVICE=C:\DOS\EMM386.EXE I=B000-B7FF FRAME=E000
EMM386.EXE can be used as a command or as a device driver. It's primary function is to act as an Expanded Memory Manager (EMM), giving your programs access to Expanded Memory Specification (EMS) memory. It also allows the creation of Upper Memory Blocks (UMB) in the Upper Memory Area (UMA). It is only useful on 386 or above systems. This device driver switches DOS from using real mode into Virtual 8086 mode, and some programs and games refuse to run in this mode. By removing the EMM386.EXE line, those programs that complained about EMM386.EXE and Virtual 8086 mode and refuse to load now will load.
As the command is given, EMM386 will emulate Expanded Memory. If you do not wish to emulate Expanded Memory, then use NOEMS. I=B000-B7FF tells the system to add a 32K Upper Memory Block in the area of video memory reserved for MDA cards. As you are likely using EMM386 with a VGA card, this area should be used. FRAME=E000 sets the EMS page frame to E000-EFFF, which permits UMBs at C000-C7FF and D000-DFFF. If the E000 segment gives you trouble, then you'll have to use the D000 segment. The line as given gives you 96K of UMBs to load your device drivers, which should be more than sufficient even for the relatively bloated CD-ROM and Mouse drivers of the day.
3. DOS=HIGH,UMB
This line instructs DOS to load itself high, saving about 55K of Conventional Memory. It also instructs DOS to create UMBs. By loading drivers within UMBs, you can save Conventional Memory from being used. You must load HIMEM.SYS to use the HIGH parameter and EMM386.SYS to use the UMB parameter.
4. FILES=40
DOS's default maximum number of files being open at one time is 15, but some games require more. 40 is sufficient for just about any program.
5. BUFFERS=30
DOS's default maximum number of disk buffers to allocate is 8, but some games require more. 30 is sufficient for just about any program.
6. DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
DEVICEHIGH tells DOS to load a device driver into an UMB. It does not work with HIMEM.SYS or EMM386.EXE and will not work until both have been loaded.
VIDE-CDD.SYS is a generic IDE CD-ROM device driver that works with pretty much everything and only takes up 5KB of RAM. This device driver acts as an interpreter between DOS calls and the low level hardware. If the CD-ROM drive used a SCSI or proprietary interface, you would load another kind of driver here. You cannot actually use a CD-ROM as a drive until you load MSCDEX.EXE in AUTOEXEC.BAT The /D:MSCD001 is the name given to the CD-ROM and must be used with MSCDEX.EXE.
Alternatives to EMM386.EXE for UMBs
EMM386.EXE generally causes slightly decreased performance compared with an environment when it is not loaded. If you want to create UMBs without it, you will have to try to find a program that will work with your chipset. The program UMBPCI.SYS works with chipsets that provide a properly-functional PCI implementation. Pentium/586 and later systems are the mostly likely systems to work with UMBPCI.SYS. Programs that can work with 386 and 486 computers include HiRAM, URAM, DOSMAX and RDOSUMB. These programs only support specific motherboard chipsets, whereas EMM386.EXE is universally supported on PC compatible motherboard chipsets. I have a 486 SiS 85C471 chipset and URAM supports it, so I use that program. My CONFIG.SYS looks like this :
DEVICE=C:\DRIVERS\URAM.COM R=..........7777777777.... I Q
DEVICE=C:\DRIVERS\UMB.SYS C800-EFFF
DEVICEHIGH=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DOS=HIGH,UMB
FILES=40
DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
My AUTOEXEC.BAT stays the same.
DOS 6.0 and above allows you to select your configuration properties via a boot-up menu system. The Help in DOS 6.0 and above gives examples on how to set up a menu so that one selection will give load EMM386 and a second selection will load URAM.
3. DOS=HIGH,UMB
This line instructs DOS to load itself high, saving about 55K of Conventional Memory. It also instructs DOS to create UMBs. By loading drivers within UMBs, you can save Conventional Memory from being used. You must load HIMEM.SYS to use the HIGH parameter and EMM386.SYS to use the UMB parameter.
4. FILES=40
DOS's default maximum number of files being open at one time is 15, but some games require more. 40 is sufficient for just about any program.
5. BUFFERS=30
DOS's default maximum number of disk buffers to allocate is 8, but some games require more. 30 is sufficient for just about any program.
6. DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
DEVICEHIGH tells DOS to load a device driver into an UMB. It does not work with HIMEM.SYS or EMM386.EXE and will not work until both have been loaded.
VIDE-CDD.SYS is a generic IDE CD-ROM device driver that works with pretty much everything and only takes up 5KB of RAM. This device driver acts as an interpreter between DOS calls and the low level hardware. If the CD-ROM drive used a SCSI or proprietary interface, you would load another kind of driver here. You cannot actually use a CD-ROM as a drive until you load MSCDEX.EXE in AUTOEXEC.BAT The /D:MSCD001 is the name given to the CD-ROM and must be used with MSCDEX.EXE.
Alternatives to EMM386.EXE for UMBs
EMM386.EXE generally causes slightly decreased performance compared with an environment when it is not loaded. If you want to create UMBs without it, you will have to try to find a program that will work with your chipset. The program UMBPCI.SYS works with chipsets that provide a properly-functional PCI implementation. Pentium/586 and later systems are the mostly likely systems to work with UMBPCI.SYS. Programs that can work with 386 and 486 computers include HiRAM, URAM, DOSMAX and RDOSUMB. These programs only support specific motherboard chipsets, whereas EMM386.EXE is universally supported on PC compatible motherboard chipsets. I have a 486 SiS 85C471 chipset and URAM supports it, so I use that program. My CONFIG.SYS looks like this :
DEVICE=C:\DRIVERS\URAM.COM R=..........7777777777.... I Q
DEVICE=C:\DRIVERS\UMB.SYS C800-EFFF
DEVICEHIGH=C:\DOS\HIMEM.SYS /TESTMEM:OFF
DOS=HIGH,UMB
FILES=40
DEVICEHIGH=C:\DRIVERS\VIDE-CDD.SYS /D:MSCD001
My AUTOEXEC.BAT stays the same.
DOS 6.0 and above allows you to select your configuration properties via a boot-up menu system. The Help in DOS 6.0 and above gives examples on how to set up a menu so that one selection will give load EMM386 and a second selection will load URAM.
Tuesday, December 31, 2013
Sound Blaster Drivers - When DOS Games Need Them
The Sound Blaster cards, before the software configurable 16s and the AWE32s, are for the most part are fine if you just install them in a system and note the hardware settings. While they came with installation and program disks, games usually don't care whether those programs are installed or not. All the game wants to know is that the settings are correct. Some require the user to input those values in an install program, others autodetect the values and some just assume that the card uses specific values and fails if those values are not set. Most games are fine with a SET BLASTER variable in your AUTOEXEC.BAT file, such one that looks like this for the Sound Blaster 16 :
SET BLASTER=A220 I5 D1 H5 P330 T6
With the Sound Blaster Pro and Sound Blaster 16 the installation disks provide very useful utilities for setting the mixer. The power-on-default mixer values are somewhat quiet, so the preset mixer values provided by these utilities allow these cards to output at a higher volume.
However, there are games that require some files off the installation disks. The two files that may be needed are SBFMDRV.COM and CT-VOICE.DRV. SBFMDRV.COM is a Resident FM Driver, CT-VOICE.DRV is a Loadable Digitized Sound Driver. Typically, a SET SOUND= variable with the installation path of the Sound Blaster installation or the directory where these files can be found is sufficient. However, games requiring SBFMDRV.COM may require it to be loaded before starting the game. The Adlib Sound Card Disks contain an equilavent file called SOUND.COM.
It is important that the CT-VOICE.DRV is matched with the card or a superior card with which it is intended to work. Thus a CT-VOICE.DRV for a Sound Blaster Pro 1.0 will not likely work with a Sound Blaster 2.0.
Finally, there is at least one game that requires the Resident CMS Driver, CMSDRV.COM to be loaded prior to beginning the game. The original file will work fine with a real Game Blaster but not a Sound Blaster with CMS chips. In that instance, the CMSDRV.COM file from the Sound Blaster 1.0-2.0 Install Disks must be used. Here are the list of games that require these files or come with these files :
SOUND.COM OR SBFMDRV.COM
Don't Go Alone
Hoosier City
Kingdom of Syree III: Black Magic, The
Yendorian Tales: Chapter 2
Words of Jesus
CMSDRV.COM
Miami Vice
CT-VOICE.DRV
Breakin (Shareware)
Innocent Until Caught
Pizza Connection (German original only)
Prehistorik
Stick Fighter 1 & 2
Here is a list of all versions of the drivers mentioned above, and for the Sound Blaster, I indicate which versions came with a particular card's install disks :
Adlib SOUND.COM versions :
1.00 or 1.10
1.20
1.30
1.51 (by far the most common)
Creative Music System CMSDRV.COM versions :
3.10 - CMS/Game Blaster Required
3.20A - Sound Blaster Required
Sound Blaster SBFMDRV.COM versions :
1.11 - Sound Blaster Card Version (SB 1.5)
1.22 - Sound Blaster Card Version (SB MCV)
1.30 - Sound Blaster Pro Stereo Version (SB Pro 1)
1.30B - Sound Blaster 1.5 and 2.0 Version (SB 2.0)
1.32* - SB Pro 2 / SB Pro MCV Version (SB Pro 2)#
1.32* - SB Pro 2 / SB16
1.33 - SB16 / SB Pro 2 / MCV Pro 2 (SB16)
1.34 - SB 1.5 / SB 2.0 / MCV 2.0 (SB 2.0 late)
# - will refuse to load on a Sound Blaster 1.0-2.0.
* - There are two versions of this driver, one dated February of 1992 and one dated October of 1992. The February 1992 driver (7,276 bytes) supports stereo playback, the October 1992 (7,191 bytes) driver does not.
For the .COM files, running the file will reveal the version number. The CT-VOICE.DRV is not self-executing and most versions do not have a version number, at least not in plain-text format, when viewed with a hex editor. Thus file sizes are used to distinguish the versions.
Sound Blaster CT-VOICE.DRV versions :
SB1.0 - 2,377 bytes
SB1.5 - 2,493 bytes
SBPRO1 - 5,014 bytes
SB2.0 - 3,894 bytes
SB2.0 - 31,866 bytes 4.01 (late)
SBPRO2 - 5,108 bytes
SBMCV - 3,894 bytes (one byte difference from the SB 2.0 version)
SB16 - 18,560 bytes
SB16 - 31,842 bytes 4.05 (late)
SET BLASTER=A220 I5 D1 H5 P330 T6
With the Sound Blaster Pro and Sound Blaster 16 the installation disks provide very useful utilities for setting the mixer. The power-on-default mixer values are somewhat quiet, so the preset mixer values provided by these utilities allow these cards to output at a higher volume.
However, there are games that require some files off the installation disks. The two files that may be needed are SBFMDRV.COM and CT-VOICE.DRV. SBFMDRV.COM is a Resident FM Driver, CT-VOICE.DRV is a Loadable Digitized Sound Driver. Typically, a SET SOUND= variable with the installation path of the Sound Blaster installation or the directory where these files can be found is sufficient. However, games requiring SBFMDRV.COM may require it to be loaded before starting the game. The Adlib Sound Card Disks contain an equilavent file called SOUND.COM.
It is important that the CT-VOICE.DRV is matched with the card or a superior card with which it is intended to work. Thus a CT-VOICE.DRV for a Sound Blaster Pro 1.0 will not likely work with a Sound Blaster 2.0.
Finally, there is at least one game that requires the Resident CMS Driver, CMSDRV.COM to be loaded prior to beginning the game. The original file will work fine with a real Game Blaster but not a Sound Blaster with CMS chips. In that instance, the CMSDRV.COM file from the Sound Blaster 1.0-2.0 Install Disks must be used. Here are the list of games that require these files or come with these files :
SOUND.COM OR SBFMDRV.COM
Don't Go Alone
Hoosier City
Kingdom of Syree III: Black Magic, The
PGA Tour Golf
Romance of the Three Kingdoms II
Solar WindsYendorian Tales: Chapter 2
Words of Jesus
CMSDRV.COM
Miami Vice
CT-VOICE.DRV
Breakin (Shareware)
Elfland
Eye of the StormInnocent Until Caught
Pizza Connection (German original only)
Prehistorik
Stick Fighter 1 & 2
Street Fighter II (comes with SBDRIVER.DRV which is a renamed CT-VOICE.DRV for Sound Blaster 2.0)
Titus the Fox?
The Clou
Traffic Department 2192
It is important to note that some games have one of these files statically linked or embedded in their files. Jill of the Jungle is an example of this. JotJ embeds Creative's SBFMDRV.COM in its EXE files, and the 1.0 version of the game will only produce music on a Sound Blaster, not an Adlib card, even if you don't want digitized sounds. JotJ supports a basic Sound Blaster and none of the more advanced features of the SB Pros or 16s. Versions 1.2(b), 1.2(c) and 1.2(d) support a pure Adlib for music, but with the music you will hear only PC speaker sound effects in 1.2(b) and 1.2(c) and no sound effects in 1.2(d). LucasArts embedded CT-VOICE.DRV in the sound driver for Indiana Jones and the Fate of Atlantis, Day of the Tentacle and the CD-ROM version of The Secret of Monkey Island.
Titus the Fox?
The Clou
Traffic Department 2192
It is important to note that some games have one of these files statically linked or embedded in their files. Jill of the Jungle is an example of this. JotJ embeds Creative's SBFMDRV.COM in its EXE files, and the 1.0 version of the game will only produce music on a Sound Blaster, not an Adlib card, even if you don't want digitized sounds. JotJ supports a basic Sound Blaster and none of the more advanced features of the SB Pros or 16s. Versions 1.2(b), 1.2(c) and 1.2(d) support a pure Adlib for music, but with the music you will hear only PC speaker sound effects in 1.2(b) and 1.2(c) and no sound effects in 1.2(d). LucasArts embedded CT-VOICE.DRV in the sound driver for Indiana Jones and the Fate of Atlantis, Day of the Tentacle and the CD-ROM version of The Secret of Monkey Island.
Here is a list of all versions of the drivers mentioned above, and for the Sound Blaster, I indicate which versions came with a particular card's install disks :
Adlib SOUND.COM versions :
1.00 or 1.10
1.20
1.30
1.51 (by far the most common)
Creative Music System CMSDRV.COM versions :
3.10 - CMS/Game Blaster Required
3.20A - Sound Blaster Required
Sound Blaster SBFMDRV.COM versions :
1.11 - Sound Blaster Card Version (SB 1.5)
1.22 - Sound Blaster Card Version (SB MCV)
1.30 - Sound Blaster Pro Stereo Version (SB Pro 1)
1.30B - Sound Blaster 1.5 and 2.0 Version (SB 2.0)
1.32* - SB Pro 2 / SB Pro MCV Version (SB Pro 2)#
1.32* - SB Pro 2 / SB16
1.33 - SB16 / SB Pro 2 / MCV Pro 2 (SB16)
1.34 - SB 1.5 / SB 2.0 / MCV 2.0 (SB 2.0 late)
# - will refuse to load on a Sound Blaster 1.0-2.0.
* - There are two versions of this driver, one dated February of 1992 and one dated October of 1992. The February 1992 driver (7,276 bytes) supports stereo playback, the October 1992 (7,191 bytes) driver does not.
For the .COM files, running the file will reveal the version number. The CT-VOICE.DRV is not self-executing and most versions do not have a version number, at least not in plain-text format, when viewed with a hex editor. Thus file sizes are used to distinguish the versions.
Sound Blaster CT-VOICE.DRV versions :
SB1.0 - 2,377 bytes
SB1.5 - 2,493 bytes
SBPRO1 - 5,014 bytes
SB2.0 - 3,894 bytes
SB2.0 - 31,866 bytes 4.01 (late)
SBPRO2 - 5,108 bytes
SBMCV - 3,894 bytes (one byte difference from the SB 2.0 version)
SB16 - 18,560 bytes
SB16 - 31,842 bytes 4.05 (late)
Monday, November 19, 2012
Important DOS versions for PC Gaming
In the text below, assume that for DOS 4.0 and lower, I am discussing IBM's PC-DOS unless otherwise noted, and for 5.0 and above, MS-DOS.
DOS 1.0 - Introduced with the IBM PC in 1981. This is the first version of Microsoft MS-DOS and it only came the IBM Personal Computer. This version of DOS only supports single sided 5.25" disks with 160K capacities (8 sectors). Any game using a double sided disk or a 180K disk (9 sectors) will not work with this version. Virtually all DOS games come on disks with one or the other, so this version has purely vintage value. Unlike later versions, this one will require you to input a valid date and time value on bootup. No hard drive support. It would effectively be off the market once IBM included double sided disk drives as standard in the PC.
Includes DONKEY.BAS, the first game ever made for the IBM PC and would be included in PC-DOS until 3.2. AUTOEXEC.BAT was included as a batch file that would be run at bootup time. Although a user could run an IBM PC with 16K of RAM, DOS 1.0 required 32KB. Some of the BASIC programs required 48K of RAM to run.
DOS 1.1 - Introduced with the IBM PC with Double Sided Drives in 1982. The most important feature of this incremental upgrade is double sided 5.25" drive support for 320K capacity support. Still only 8 sector support.
Microsoft began to supply OEM manufacturers (Compaq, Tandy, Zenith, etc.) with DOS around this time. The earliest known MS-DOS version is 1.25, and does not come with all the utilities of PC-DOS 1.1. The OEM would then modify it as necessary to support its hardware. Some OEM versions of DOS, like Tandy's, would not run on a non-Tandy system. Others, like Compaq, did not care.
The chief difference between IBM's PC-DOS and the OEM MS-DOS for gaming purposes is that IBM's BASIC.COM (Disk BASIC) and BASICA.COM (Advanced BASIC) programs did not have the core of BASIC contained within. Instead, the core was contained in 32K of ROM in the F segment which was called ROM BASIC or Cassette BASIC. In the OEM MS-DOS, the equilavent BASIC executables contained GW-BASIC, which had the code which would have otherwise been in ROM embedded in the file on the disk.
Thus, if a game requires ROM BASIC, it will not run on a non-IBM system. Several early BASIC games, including IBM's, assume that you are running them on an IBM PC, XT or AT. Virtually any IBM PC or PS/2 machine made during the 1980s will work with games requiring ROM BASIC. While some may be able to be run with a non-IBM machine using an OEM GW-BASIC, this can be tricky due to copy protection schemes and direct accesses to the ROM.
One game manual (Ultima II) suggested that you copy over the DOS system files using the sys command to make the game disk bootable. This could only be done with DOS 1.1, DOS 2.0 and above were too big.
This version allowed DEL as an alias for ERASE and REN for RENAME.
DOS 2.0 - Introduced with the IBM PC XT in 1983. This is the required minimum for most DOS games that come on a 5.25" double density drive. Adds support for 9 sector disks, so single sided formatted disks are 180K and double sided disks 360K. The latter is by far the most common format for 5.25" Double Density DOS game floppy disks.
The next feature would become even more important, support for hard drives. The IBM PC XT shipped with the Seagate ST-412 10MB hard drive. The existing 12-bit File Allocation Table (FAT-12) used on floppy disks could handle drives up to 15MB. Only one DOS partition and two drives were permitted, so DOS 2.x's expandability was limited. IBM used FDISK to partition disks, OEMs used similar programs.
Architecturally, applications written to run on the 1.x versions of DOS used File Control Blocks to keep track of open files. This was too limiting, so DOS 2.0 introduced file handles to handle the same task. Subdirectories were also introduced in DOS 2.0.
Finally, DOS 2.0 offers support for installable device drivers. CONFIG.SYS makes its first appearance to load those drivers at bootup. The first of these was ANSI.SYS. By installing this driver in CONFIG.SYS, the user or a game could obtain more direct control over the text on the screen. The user could change the background color, the text colors, the video mode, etc. Some text-based games require ANSI.SYS to be loaded before they will run.
DOS 2.1 - Introduced with the IBM PCjr. in 1983. It adds support for that system and its enhanced graphics and sound in the BASIC interpreters. The PCjr. cannot run earlier versions of DOS.
IBM was yet to embrace the wider international market, so OEM's included Microsoft's international convention support in the COUNTRY command in CONFIG.SYS in MS-DOS 2.11 to audiences. I think that due in part to this, 2.11 is considered the "safest" lowest version of DOS you can use and expect DOS games that came on 5.25" floppies before 1991 to run.
The first Tandy 1000 computers began with Tandy DOS 2.11.22. Like the IBM PC-DOS 2.1, the BASIC on these disks supports the enhanced graphics and sound of the 1000 series. The EX and HX also use 2.11.24, but the HX's version includes support for 720KB drives and DOS-in-ROM.
DOS 3.0 - Introduced with the IBM PC AT in 1984. This is the first version of DOS which supports high density 5.25 floppy disk drives for 1.2MB per disk. All DOS games that come on 5.25" 1.2MB disks will expect this or higher as the minimum DOS version.
The IBM PC AT came with a 20MB hard disk, and FAT-12 was inadequate. A 16-bit FAT (FAT-16) was supported in this version of DOS. One DOS partition of 32MB per disk was supported per drive, due to the use of 16-bit sector values.
The Real Time Clock in the AT is supported, thus DOS can automatically update the date and time and retrieve it once the system is shut down and restarted, or reset. Non-AT style RTCs require device drivers.
IBM added support for common international keyboard layouts (KEYBXX) and international conventions (COUNTRY) in this version. The ATTRIB command allowed the user to set the file attributes (hidden, system, read only, archive) for any file.
DOS 3.1 - An incremental upgrade to DOS 3.0. The most important feature was this DOS was the first version to support networking. More signficantly for gaming, this is the first version to support Microsoft Networking extensions, which is what MSCDEX uses to allow CD-ROM drives to function in DOS (it looks like a newtork drive to DOS). This is the minimum version on which Windows 3.x will run.
DOS 3.2 - Introduced with the IBM PC Convertible in 1986. Adds support for 3.5 inch double density drive support for 720K disk capacities. All DOS games that come on 3.5" 720K disks will expect this or higher as the minimum DOS version. XCOPY command added to copy directories and the included subdirectories. Many games of the late 1980s use batch files to install themselves to the hard drive, and sooner or later one will assume that the XCOPY command is available and use it.
MS-DOS 3.2 was the first time Microsoft made the OS available to system builders through an OEM package. This meant that an individual putting together their system from parts had a way to acquire the OS without having to buy a pre-built system. By version 3.2, the user could be more-or-less assured that his version of DOS would be as fully featured as IBM's PC-DOS (mainly with the hard drive utilities).
The Tandy 1000 SX and TX come with Tandy DOS 3.20.22, and have a custom partitioning utility to add three extra 32MB partitions. Other OEMs like Compaq provided similar utilities. More modern operating systems tend not to recognize these partitions and a special formatting program is necessary to create them and a special device driver must be loaded in CONFIG.SYS to access them.
DOS 3.3 - Introduced with the IBM PS/2 series. Adds support for 3.5 inch high density drive support for 1.44MB disk capacities and country code pages. Keyboard layouts are now supported with the KEYB command instead of a separate command for each layout.
This version adds support for the extended DOS partition, allowing one primary DOS partition of 32MB (drive C:) an an extended partition of up to 2GB. However, the logical drives within the extended partition can only be 32MB each. Thus the user can have logical disk drives D: to Z: with 32MB capacity each in the extended partition. The total disk space available to the user would be 736MB. This was still extremely large back in 1987 when this version was released.
International support was improved with the addition of country codes in IBM's version. IBM and Microsoft were shipping the same utilities in their respective versions of DOS by this point. This allowed the user to display characters in text-modes that were not available in the character ROM on their video adapter, but requires an EGA or VGA card work.
The remainder of the Tandy 1000s use this DOS, 3.30.22, except for the RLX-B and RSX (5.0). These systems contain the DOS core files in a fast ROM drive, which is disabled when a hard disk is installed.
DOS 3.31 (Compaq MS-DOS only) - Final FAT-16 implementation introduced, 32-bit sector values used. An 8GB disk could be supported with a 2GB drive partition support with one primary and three logical drives in the extended partition. Seems to work fine in non-Compaq systems.
DOS 4.0 - Introduced with 2nd Generation IBM PS/2 in 1988.
In DOS 4.0, the use of partitions greater than 32MB should be accompanied by loading SHARE.EXE beforehand. This is necessary only for really old games that use FCBs, since their use is incompatible with the full FAT-16 implementation. SHARE.EXE will translate the use of FCBs to file handles. DOS 5.0 and later automatically implement SHARE.EXE.
EMM386 first introduced, but in DOS 4.x it is known as EMM386.SYS. EMM386.SYS or EMM386.EXE in a 386 or better machine allows extended memory, that is the memory above the first megabyte in a PC, to be used as expanded memory. On a 8088, 8086 or 80286 machine, expanded memory could only be added by an expensive memory card. Games supporting the Expanded Memory Specification for storing data in expanded memory will work well with EMM386.
EMM386 has another important feature. It allows device drivers to be loaded in Upper Memory. Upper Memory is the area between 640K and 1MB in a PC that is reserved for ROM and RAM on adapter cards. A 386 usually had memory in that area that would be left sitting unused, but areas not otherwise occupied by ROM or RAM could be converted into Upper Memory Blocks into which DOS could load device drivers instead of taking up valuable conventional memory. If Expanded Memory was not required, EMM386 could still provide Upper Memory Blocks.
IBM's PC-DOS 4.0 acquired a bad reputation as a buggy OS. Its memory footprint was rather high, especially when used with systems that did not have a full 640K free. More unforgivable was that it did not work well, if at all, with 3rd-party (non-IBM) EMS boards. MS-DOS 4.0 did. PC-DOS 4.01 also exists that fixed the issue. IBM's EMM386's functionality is provided by XMA2EMS.SYS. Users were also wary of the new partitioning schemes, which was incompatible with their existing disk utilities and tended to stick with DOS 3.3 until 5.0.
The MEM command is introduced to show you how your conventional and upper memory is being used and is extremely helpful to identify how you can improve your system configuration.
DOS 5.0 - Released in 1991 with DR-DOS 5.0 and MS-DOS 5.0. By this time, OEM versions of MS-DOS are not really customized, and MS-DOS 5.0 was the first version of DOS to have a real identity on a store shelf. Unlike earlier versions of MS-DOS, it had an install program. Adds 3.5 inch extra high density drive support for 2.88MB disk capacities. The drives needed for format and read such disks were never popular and games were never released on such disks.
The most important feature MS-DOS 5.0 provides is the HIMEM.SYS driver. This provides access to the High Memory Area (HMA) on 286 and better processors with over 1MB of RAM. DOS can load a large chunk of itself in the 64K HMA area, leaving more conventional memory free. HIMEM.SYS also implements the XMS specification to allow access to as many megabytes of extended memory as the system contains in a 286 or above. Some games can use the access to XMS memory to store data or otherwise require HIMEM to be loaded, so this version of DOS is obviously the lowest those games support.
QBASIC was introduced, which is why so many people have fond memories of Gorillas and Nibbles. The MS-DOS EDIT, which uses the QBASIC interface, is very handy to edit AUTOEXEC.BAT and CONFIG.SYS and read text files.
There are bugs in the FORMAT and FDISK commands, so when these are updated this can be called MS-DOS 5.00a. Commands can show a help menu by using a /? switch.
Four physical hard drives allowed with DOS partitions.
DOS 6.xx - Released in 1993, the biggest feature of this version was support for drive compression. When drives were 20-200MB in size, this was a useful option. Today when drives are huge and cheap, it is not important. Also important was the DELTREE command (deletes directories, subdirectories and all the files within them) and the MOVE command (copy and delete in one command). 6.22 is the last standalone version of DOS Microsoft ever released.
The most useful feature of MS-DOS 6.xx is its support for multiple configurations. This means you can have one configuration with Expanded Memory and Upper Memory with EMM386, and another configuration without it loaded for those games that will not run with it.
Unlike earlier versions of DOS, MSCDEX.EXE came with these versions. Otherwise, MSCDEX would be provided on a floppy disk accompanying the CD-ROM package you bought. MSCDEX came in versions 2.1, 2.2 and 2.95. 2.1 requires PC-DOS 3.1 or MS-DOS 3.1 or 4.0, 2.2 is required for MS-DOS 5 or SETVER must be used. 2.95 was released with Windows 95.
Microsoft eliminated certain utilities like JOIN and SUBST in the main install of 6.xx, which some game installs (weird CD compilations) rely upon. Microsoft later released a Supplemental Utilities disk to put these programs back in (presumably without using SETVER). The Supplemental Utilities disk can still be freely downloaded.
MEMMAKER is also a useful utility to try to maximize conventional memory, and HELP shows a text-based interface with the commands, examples and notes. SCANDISK is useful for determining hard drive errors. IBM released PC-DOS 6.1 and 6.3, leapfrogging Microsft's version numbers.
DOS 7.0 - This is the version of DOS underlying Windows 95. Windows 95 OSR2 introduced the FAT-32 filesystem, and this version of DOS is 7.0a. If you have a copy of Windows 95 OSR2 or above , there is a way to extract the very useful 7.0a and use it as a standalone operating system. The EDIT in these systems use more modern keyboard shortcuts like Ctrl C for copy, Ctrl V for paste and Ctrl X for delete. IBM released a DOS 7.0 and 7.1 (a.k.a. PC-DOS 2000).
DOS 8.0 - A crippled version of DOS which underlies Windows ME. No value.
DOS 1.0 - Introduced with the IBM PC in 1981. This is the first version of Microsoft MS-DOS and it only came the IBM Personal Computer. This version of DOS only supports single sided 5.25" disks with 160K capacities (8 sectors). Any game using a double sided disk or a 180K disk (9 sectors) will not work with this version. Virtually all DOS games come on disks with one or the other, so this version has purely vintage value. Unlike later versions, this one will require you to input a valid date and time value on bootup. No hard drive support. It would effectively be off the market once IBM included double sided disk drives as standard in the PC.
Includes DONKEY.BAS, the first game ever made for the IBM PC and would be included in PC-DOS until 3.2. AUTOEXEC.BAT was included as a batch file that would be run at bootup time. Although a user could run an IBM PC with 16K of RAM, DOS 1.0 required 32KB. Some of the BASIC programs required 48K of RAM to run.
DOS 1.1 - Introduced with the IBM PC with Double Sided Drives in 1982. The most important feature of this incremental upgrade is double sided 5.25" drive support for 320K capacity support. Still only 8 sector support.
Microsoft began to supply OEM manufacturers (Compaq, Tandy, Zenith, etc.) with DOS around this time. The earliest known MS-DOS version is 1.25, and does not come with all the utilities of PC-DOS 1.1. The OEM would then modify it as necessary to support its hardware. Some OEM versions of DOS, like Tandy's, would not run on a non-Tandy system. Others, like Compaq, did not care.
The chief difference between IBM's PC-DOS and the OEM MS-DOS for gaming purposes is that IBM's BASIC.COM (Disk BASIC) and BASICA.COM (Advanced BASIC) programs did not have the core of BASIC contained within. Instead, the core was contained in 32K of ROM in the F segment which was called ROM BASIC or Cassette BASIC. In the OEM MS-DOS, the equilavent BASIC executables contained GW-BASIC, which had the code which would have otherwise been in ROM embedded in the file on the disk.
Thus, if a game requires ROM BASIC, it will not run on a non-IBM system. Several early BASIC games, including IBM's, assume that you are running them on an IBM PC, XT or AT. Virtually any IBM PC or PS/2 machine made during the 1980s will work with games requiring ROM BASIC. While some may be able to be run with a non-IBM machine using an OEM GW-BASIC, this can be tricky due to copy protection schemes and direct accesses to the ROM.
One game manual (Ultima II) suggested that you copy over the DOS system files using the sys command to make the game disk bootable. This could only be done with DOS 1.1, DOS 2.0 and above were too big.
This version allowed DEL as an alias for ERASE and REN for RENAME.
DOS 2.0 - Introduced with the IBM PC XT in 1983. This is the required minimum for most DOS games that come on a 5.25" double density drive. Adds support for 9 sector disks, so single sided formatted disks are 180K and double sided disks 360K. The latter is by far the most common format for 5.25" Double Density DOS game floppy disks.
The next feature would become even more important, support for hard drives. The IBM PC XT shipped with the Seagate ST-412 10MB hard drive. The existing 12-bit File Allocation Table (FAT-12) used on floppy disks could handle drives up to 15MB. Only one DOS partition and two drives were permitted, so DOS 2.x's expandability was limited. IBM used FDISK to partition disks, OEMs used similar programs.
Architecturally, applications written to run on the 1.x versions of DOS used File Control Blocks to keep track of open files. This was too limiting, so DOS 2.0 introduced file handles to handle the same task. Subdirectories were also introduced in DOS 2.0.
Finally, DOS 2.0 offers support for installable device drivers. CONFIG.SYS makes its first appearance to load those drivers at bootup. The first of these was ANSI.SYS. By installing this driver in CONFIG.SYS, the user or a game could obtain more direct control over the text on the screen. The user could change the background color, the text colors, the video mode, etc. Some text-based games require ANSI.SYS to be loaded before they will run.
DOS 2.1 - Introduced with the IBM PCjr. in 1983. It adds support for that system and its enhanced graphics and sound in the BASIC interpreters. The PCjr. cannot run earlier versions of DOS.
IBM was yet to embrace the wider international market, so OEM's included Microsoft's international convention support in the COUNTRY command in CONFIG.SYS in MS-DOS 2.11 to audiences. I think that due in part to this, 2.11 is considered the "safest" lowest version of DOS you can use and expect DOS games that came on 5.25" floppies before 1991 to run.
The first Tandy 1000 computers began with Tandy DOS 2.11.22. Like the IBM PC-DOS 2.1, the BASIC on these disks supports the enhanced graphics and sound of the 1000 series. The EX and HX also use 2.11.24, but the HX's version includes support for 720KB drives and DOS-in-ROM.
DOS 3.0 - Introduced with the IBM PC AT in 1984. This is the first version of DOS which supports high density 5.25 floppy disk drives for 1.2MB per disk. All DOS games that come on 5.25" 1.2MB disks will expect this or higher as the minimum DOS version.
The IBM PC AT came with a 20MB hard disk, and FAT-12 was inadequate. A 16-bit FAT (FAT-16) was supported in this version of DOS. One DOS partition of 32MB per disk was supported per drive, due to the use of 16-bit sector values.
The Real Time Clock in the AT is supported, thus DOS can automatically update the date and time and retrieve it once the system is shut down and restarted, or reset. Non-AT style RTCs require device drivers.
IBM added support for common international keyboard layouts (KEYBXX) and international conventions (COUNTRY) in this version. The ATTRIB command allowed the user to set the file attributes (hidden, system, read only, archive) for any file.
DOS 3.1 - An incremental upgrade to DOS 3.0. The most important feature was this DOS was the first version to support networking. More signficantly for gaming, this is the first version to support Microsoft Networking extensions, which is what MSCDEX uses to allow CD-ROM drives to function in DOS (it looks like a newtork drive to DOS). This is the minimum version on which Windows 3.x will run.
DOS 3.2 - Introduced with the IBM PC Convertible in 1986. Adds support for 3.5 inch double density drive support for 720K disk capacities. All DOS games that come on 3.5" 720K disks will expect this or higher as the minimum DOS version. XCOPY command added to copy directories and the included subdirectories. Many games of the late 1980s use batch files to install themselves to the hard drive, and sooner or later one will assume that the XCOPY command is available and use it.
MS-DOS 3.2 was the first time Microsoft made the OS available to system builders through an OEM package. This meant that an individual putting together their system from parts had a way to acquire the OS without having to buy a pre-built system. By version 3.2, the user could be more-or-less assured that his version of DOS would be as fully featured as IBM's PC-DOS (mainly with the hard drive utilities).
The Tandy 1000 SX and TX come with Tandy DOS 3.20.22, and have a custom partitioning utility to add three extra 32MB partitions. Other OEMs like Compaq provided similar utilities. More modern operating systems tend not to recognize these partitions and a special formatting program is necessary to create them and a special device driver must be loaded in CONFIG.SYS to access them.
DOS 3.3 - Introduced with the IBM PS/2 series. Adds support for 3.5 inch high density drive support for 1.44MB disk capacities and country code pages. Keyboard layouts are now supported with the KEYB command instead of a separate command for each layout.
This version adds support for the extended DOS partition, allowing one primary DOS partition of 32MB (drive C:) an an extended partition of up to 2GB. However, the logical drives within the extended partition can only be 32MB each. Thus the user can have logical disk drives D: to Z: with 32MB capacity each in the extended partition. The total disk space available to the user would be 736MB. This was still extremely large back in 1987 when this version was released.
International support was improved with the addition of country codes in IBM's version. IBM and Microsoft were shipping the same utilities in their respective versions of DOS by this point. This allowed the user to display characters in text-modes that were not available in the character ROM on their video adapter, but requires an EGA or VGA card work.
The remainder of the Tandy 1000s use this DOS, 3.30.22, except for the RLX-B and RSX (5.0). These systems contain the DOS core files in a fast ROM drive, which is disabled when a hard disk is installed.
DOS 3.31 (Compaq MS-DOS only) - Final FAT-16 implementation introduced, 32-bit sector values used. An 8GB disk could be supported with a 2GB drive partition support with one primary and three logical drives in the extended partition. Seems to work fine in non-Compaq systems.
DOS 4.0 - Introduced with 2nd Generation IBM PS/2 in 1988.
In DOS 4.0, the use of partitions greater than 32MB should be accompanied by loading SHARE.EXE beforehand. This is necessary only for really old games that use FCBs, since their use is incompatible with the full FAT-16 implementation. SHARE.EXE will translate the use of FCBs to file handles. DOS 5.0 and later automatically implement SHARE.EXE.
EMM386 first introduced, but in DOS 4.x it is known as EMM386.SYS. EMM386.SYS or EMM386.EXE in a 386 or better machine allows extended memory, that is the memory above the first megabyte in a PC, to be used as expanded memory. On a 8088, 8086 or 80286 machine, expanded memory could only be added by an expensive memory card. Games supporting the Expanded Memory Specification for storing data in expanded memory will work well with EMM386.
EMM386 has another important feature. It allows device drivers to be loaded in Upper Memory. Upper Memory is the area between 640K and 1MB in a PC that is reserved for ROM and RAM on adapter cards. A 386 usually had memory in that area that would be left sitting unused, but areas not otherwise occupied by ROM or RAM could be converted into Upper Memory Blocks into which DOS could load device drivers instead of taking up valuable conventional memory. If Expanded Memory was not required, EMM386 could still provide Upper Memory Blocks.
IBM's PC-DOS 4.0 acquired a bad reputation as a buggy OS. Its memory footprint was rather high, especially when used with systems that did not have a full 640K free. More unforgivable was that it did not work well, if at all, with 3rd-party (non-IBM) EMS boards. MS-DOS 4.0 did. PC-DOS 4.01 also exists that fixed the issue. IBM's EMM386's functionality is provided by XMA2EMS.SYS. Users were also wary of the new partitioning schemes, which was incompatible with their existing disk utilities and tended to stick with DOS 3.3 until 5.0.
The MEM command is introduced to show you how your conventional and upper memory is being used and is extremely helpful to identify how you can improve your system configuration.
DOS 5.0 - Released in 1991 with DR-DOS 5.0 and MS-DOS 5.0. By this time, OEM versions of MS-DOS are not really customized, and MS-DOS 5.0 was the first version of DOS to have a real identity on a store shelf. Unlike earlier versions of MS-DOS, it had an install program. Adds 3.5 inch extra high density drive support for 2.88MB disk capacities. The drives needed for format and read such disks were never popular and games were never released on such disks.
The most important feature MS-DOS 5.0 provides is the HIMEM.SYS driver. This provides access to the High Memory Area (HMA) on 286 and better processors with over 1MB of RAM. DOS can load a large chunk of itself in the 64K HMA area, leaving more conventional memory free. HIMEM.SYS also implements the XMS specification to allow access to as many megabytes of extended memory as the system contains in a 286 or above. Some games can use the access to XMS memory to store data or otherwise require HIMEM to be loaded, so this version of DOS is obviously the lowest those games support.
QBASIC was introduced, which is why so many people have fond memories of Gorillas and Nibbles. The MS-DOS EDIT, which uses the QBASIC interface, is very handy to edit AUTOEXEC.BAT and CONFIG.SYS and read text files.
There are bugs in the FORMAT and FDISK commands, so when these are updated this can be called MS-DOS 5.00a. Commands can show a help menu by using a /? switch.
Four physical hard drives allowed with DOS partitions.
DOS 6.xx - Released in 1993, the biggest feature of this version was support for drive compression. When drives were 20-200MB in size, this was a useful option. Today when drives are huge and cheap, it is not important. Also important was the DELTREE command (deletes directories, subdirectories and all the files within them) and the MOVE command (copy and delete in one command). 6.22 is the last standalone version of DOS Microsoft ever released.
The most useful feature of MS-DOS 6.xx is its support for multiple configurations. This means you can have one configuration with Expanded Memory and Upper Memory with EMM386, and another configuration without it loaded for those games that will not run with it.
Unlike earlier versions of DOS, MSCDEX.EXE came with these versions. Otherwise, MSCDEX would be provided on a floppy disk accompanying the CD-ROM package you bought. MSCDEX came in versions 2.1, 2.2 and 2.95. 2.1 requires PC-DOS 3.1 or MS-DOS 3.1 or 4.0, 2.2 is required for MS-DOS 5 or SETVER must be used. 2.95 was released with Windows 95.
Microsoft eliminated certain utilities like JOIN and SUBST in the main install of 6.xx, which some game installs (weird CD compilations) rely upon. Microsoft later released a Supplemental Utilities disk to put these programs back in (presumably without using SETVER). The Supplemental Utilities disk can still be freely downloaded.
MEMMAKER is also a useful utility to try to maximize conventional memory, and HELP shows a text-based interface with the commands, examples and notes. SCANDISK is useful for determining hard drive errors. IBM released PC-DOS 6.1 and 6.3, leapfrogging Microsft's version numbers.
DOS 7.0 - This is the version of DOS underlying Windows 95. Windows 95 OSR2 introduced the FAT-32 filesystem, and this version of DOS is 7.0a. If you have a copy of Windows 95 OSR2 or above , there is a way to extract the very useful 7.0a and use it as a standalone operating system. The EDIT in these systems use more modern keyboard shortcuts like Ctrl C for copy, Ctrl V for paste and Ctrl X for delete. IBM released a DOS 7.0 and 7.1 (a.k.a. PC-DOS 2000).
DOS 8.0 - A crippled version of DOS which underlies Windows ME. No value.
Sunday, February 28, 2010
Perfecting the IBM Model M Keyboard
The IBM Model M Keyboard is among the best keyboards ever made. However, technologically it has shown its age a bit, and even IBM cut a corner or two to reduce the cost of production. If I had the means, I would make the following improvements:
1. Make a 103-key Keyboard.
Some people like to have Windows keys. Sometimes even I can see their utility. Windows + D makes a good "boss key". Learing how to use the key combinations can make working in Windows more efficient. However, I would prefer a longer spacebar than Windows keys the same size and Ctrl and Alt. The 101-key Model M has empty spaces, the size of a regular key, in between each set of Ctrl and Alt. Why not put Windows key in those spaces? People who hate the Windows key can easily disable it in software. For Macintosh users, perhaps an option could be made for a shorter spacebar and a "Windows" key the same size as the Ctrl and Alt keys. On no account would I want a Menu key cluttering up the row, that key's function can be replicated by Shift F10. However, should one want one, a standard size keycap with the Menu graphic can be included if one was willing to sacrifice a Windows key.
2. Improve the internal assembly
The assembly of the Model M, once the keycaps and keystems are removed, is one plastic layer with holes for the keys, three membrane layers, and a metal back. The greatest dangers to the Model M, regardless of version, are liquids. I spilled some wine into my Unicomp Model M, and despite the drain holes, the conductive membrane was ruined. Later, I spilled a little G2 into my 1987 Model M and the B and M keys would give VB and NM when pressed. In the latter case, I was able to open keyboard up and save the keyboard by wiping up the liquid. The membrane is NOT internally sealed, nor can it be, but the membrane itself is three sheets of translucent plastic that could easily be replaced.
The problem with replacing the membrane is that IBM secured the upper plastic layer to the metal layer by melting the upper plastic layer through holes in the membrane and metal layer (in the assembly) and letting the melted plastic cool into studs on the bottom of the metal plate. There are lots of these plastic nubs throught the back of the keyboard assembly. The issue is that the can break after a hard impact or by wear over time. Once all are broken off, there is no way to resecure the plastic layer to the metal layer. At that point, you had best buy a new keyboard.
The solution is to use screws instead of melted plastic. This way the user can unscrew the keyboard and clean or replace the membrane. I believe this is how the Tandy Enhanced Keyboard operates. (A nut should be used.) Yes, it increases costs, but I believe it is better to extend the life time of the investment.
3. Improve the controller
The Keyboard controller circuit has some issues. First, it only supports AT & PS/2 style connections. Since the AT connection is a thing of the past and the PS/2 connector is a legacy port on modern motherboards, the controller should add USB support. Second, some Model Ms have controllers than can work with the original IBM PC and IBM PC/XT and (with a custom an adapter) the IBM PC Portable (before 2nd BIOS in the latter two cases). Most do not, I do not have any that do. I would love a truly IBM PC Compatible keyboard. The Tandy Enhanced Keyboard works perfectly with an IBM PC 5150 and with any other true IBM PC-compatible computer.
The IBM Model Ms I have ## 1390120 (ledless), 1390131 (silver logo), & 1391401 (grey oval logo) have a 6-pin RJ-45-like port on the rear to attach a cable. IBM generally supplied AT & PS/2 cables, coiled. Why not make a sturdy USB cable? Since only four pins are used, the other two can tell the controller that a USB cable is being attached. While there are AT-PS/2 adapters and PS/2-USB adapters (and vice versa), permanency is prized by some people.
Finally, why not have a wireless dongle attachment? If it attaches to the back, another dongle can attach to the PC. Rechargeable through USB.
4. Add support for N-Key and 6-Key Rollover
The Model M does not support N-key Rollover. In fact, depending on the keys pressed, it cannot register three keys at the same time. Try pressing r y u all at once. Unlimited key rollover is supported through the PS/2 interface, but only 6-key rollover through USB. 6-key is not that terrible, after all the functional limit is 10 keys unless the user is a rare polydactyl with a functioning extra finger. In order to have unlimited N-key rollover, each key on the membrane needs to be isolated with a diode. As this is rather difficult to achieve with a thin plastic membrane, please see my next suggestion.
5. Use Printed Circuit Board Contacts
The IBM Model F keyboards used a Printed Circuit Board with key contacted etched in the board, and the key mechanism used a carbonized switch to conduct electricity between the two halves of the contact. This denoted significantly higher build quality. Also, it gives an easy platform to install the diodes needed for N-key rollover. Get rid of those flimsy plastic membranes which true rubber domes use.
6. Fix the layout shortcomings
The IBM Model M keyboard had a few shortcomings over the older Model Fs. One, the function keys were relegated to the top instead of the side of the keyboard. Savvy keyboard users with the space can use extra function keys, so add a set of function keys on the left side of the keyboard. F11 and F12 would go to the left of the top function key row. This is nothing new, the Northgate Omnikey Ultra and Ultra T featured two sets of function keys in this fashion.
The ~` and Esc key can be exchanged using removable keycaps, so no adjustment need be made there.
Some people prefer that the L. Ctrl should be where the Caps Lock key is on a Model M. All that is required here is to make a Caps Lock keycap and a Ctrl key (since the Model M's Caps Lock has cap and stem fused together). I would also make two models of Ctrl key, one with the lowered area (so people would not strike it by trying to hit the A key) and one without. Also, why not make a Caps Lock key without the lowered area.
L shaped Enter key? I have no particular views toward or against the big L shaped Enter key, which was a staple of the AT Model F keyboard. But since it replaces the | \ key, the usual alternatives are not very good. One option is to put it to the left of the Backspace key, which requires that key to be shortened. I have never liked this option, which is perhaps the AT Model F's biggest shortcoming. The next option is to put it to the right of the Shift key, ala the Northgate Omnikey Ultra and Avant Stellar Prime, which is better but unlike a laptop we are not pressed for space here. The best place to put it is where one of the Windows keys go. I do not feel that sacrificing a Windows key to be that great of a loss.
7. Make the Keyboard Fully Programmable
While the keyboard can be reprogrammed in software, there are times when the keycodes being reported from the keyboard to the system would actually match what the key cap indicates. This is especially true when you have reconfigured your keycaps to match a DVORAK or AZERTY layout. No need to load drivers or special software. Volatile memory on the keyboard contoller should be used to indicate which scancode it outputs for each key, so the programming can be platform independent. A USB cable may need to be used for the programming option.
1. Make a 103-key Keyboard.
Some people like to have Windows keys. Sometimes even I can see their utility. Windows + D makes a good "boss key". Learing how to use the key combinations can make working in Windows more efficient. However, I would prefer a longer spacebar than Windows keys the same size and Ctrl and Alt. The 101-key Model M has empty spaces, the size of a regular key, in between each set of Ctrl and Alt. Why not put Windows key in those spaces? People who hate the Windows key can easily disable it in software. For Macintosh users, perhaps an option could be made for a shorter spacebar and a "Windows" key the same size as the Ctrl and Alt keys. On no account would I want a Menu key cluttering up the row, that key's function can be replicated by Shift F10. However, should one want one, a standard size keycap with the Menu graphic can be included if one was willing to sacrifice a Windows key.
2. Improve the internal assembly
The assembly of the Model M, once the keycaps and keystems are removed, is one plastic layer with holes for the keys, three membrane layers, and a metal back. The greatest dangers to the Model M, regardless of version, are liquids. I spilled some wine into my Unicomp Model M, and despite the drain holes, the conductive membrane was ruined. Later, I spilled a little G2 into my 1987 Model M and the B and M keys would give VB and NM when pressed. In the latter case, I was able to open keyboard up and save the keyboard by wiping up the liquid. The membrane is NOT internally sealed, nor can it be, but the membrane itself is three sheets of translucent plastic that could easily be replaced.
The problem with replacing the membrane is that IBM secured the upper plastic layer to the metal layer by melting the upper plastic layer through holes in the membrane and metal layer (in the assembly) and letting the melted plastic cool into studs on the bottom of the metal plate. There are lots of these plastic nubs throught the back of the keyboard assembly. The issue is that the can break after a hard impact or by wear over time. Once all are broken off, there is no way to resecure the plastic layer to the metal layer. At that point, you had best buy a new keyboard.
The solution is to use screws instead of melted plastic. This way the user can unscrew the keyboard and clean or replace the membrane. I believe this is how the Tandy Enhanced Keyboard operates. (A nut should be used.) Yes, it increases costs, but I believe it is better to extend the life time of the investment.
3. Improve the controller
The Keyboard controller circuit has some issues. First, it only supports AT & PS/2 style connections. Since the AT connection is a thing of the past and the PS/2 connector is a legacy port on modern motherboards, the controller should add USB support. Second, some Model Ms have controllers than can work with the original IBM PC and IBM PC/XT and (with a custom an adapter) the IBM PC Portable (before 2nd BIOS in the latter two cases). Most do not, I do not have any that do. I would love a truly IBM PC Compatible keyboard. The Tandy Enhanced Keyboard works perfectly with an IBM PC 5150 and with any other true IBM PC-compatible computer.
The IBM Model Ms I have ## 1390120 (ledless), 1390131 (silver logo), & 1391401 (grey oval logo) have a 6-pin RJ-45-like port on the rear to attach a cable. IBM generally supplied AT & PS/2 cables, coiled. Why not make a sturdy USB cable? Since only four pins are used, the other two can tell the controller that a USB cable is being attached. While there are AT-PS/2 adapters and PS/2-USB adapters (and vice versa), permanency is prized by some people.
Finally, why not have a wireless dongle attachment? If it attaches to the back, another dongle can attach to the PC. Rechargeable through USB.
4. Add support for N-Key and 6-Key Rollover
The Model M does not support N-key Rollover. In fact, depending on the keys pressed, it cannot register three keys at the same time. Try pressing r y u all at once. Unlimited key rollover is supported through the PS/2 interface, but only 6-key rollover through USB. 6-key is not that terrible, after all the functional limit is 10 keys unless the user is a rare polydactyl with a functioning extra finger. In order to have unlimited N-key rollover, each key on the membrane needs to be isolated with a diode. As this is rather difficult to achieve with a thin plastic membrane, please see my next suggestion.
5. Use Printed Circuit Board Contacts
The IBM Model F keyboards used a Printed Circuit Board with key contacted etched in the board, and the key mechanism used a carbonized switch to conduct electricity between the two halves of the contact. This denoted significantly higher build quality. Also, it gives an easy platform to install the diodes needed for N-key rollover. Get rid of those flimsy plastic membranes which true rubber domes use.
6. Fix the layout shortcomings
The IBM Model M keyboard had a few shortcomings over the older Model Fs. One, the function keys were relegated to the top instead of the side of the keyboard. Savvy keyboard users with the space can use extra function keys, so add a set of function keys on the left side of the keyboard. F11 and F12 would go to the left of the top function key row. This is nothing new, the Northgate Omnikey Ultra and Ultra T featured two sets of function keys in this fashion.
The ~` and Esc key can be exchanged using removable keycaps, so no adjustment need be made there.
Some people prefer that the L. Ctrl should be where the Caps Lock key is on a Model M. All that is required here is to make a Caps Lock keycap and a Ctrl key (since the Model M's Caps Lock has cap and stem fused together). I would also make two models of Ctrl key, one with the lowered area (so people would not strike it by trying to hit the A key) and one without. Also, why not make a Caps Lock key without the lowered area.
L shaped Enter key? I have no particular views toward or against the big L shaped Enter key, which was a staple of the AT Model F keyboard. But since it replaces the | \ key, the usual alternatives are not very good. One option is to put it to the left of the Backspace key, which requires that key to be shortened. I have never liked this option, which is perhaps the AT Model F's biggest shortcoming. The next option is to put it to the right of the Shift key, ala the Northgate Omnikey Ultra and Avant Stellar Prime, which is better but unlike a laptop we are not pressed for space here. The best place to put it is where one of the Windows keys go. I do not feel that sacrificing a Windows key to be that great of a loss.
7. Make the Keyboard Fully Programmable
While the keyboard can be reprogrammed in software, there are times when the keycodes being reported from the keyboard to the system would actually match what the key cap indicates. This is especially true when you have reconfigured your keycaps to match a DVORAK or AZERTY layout. No need to load drivers or special software. Volatile memory on the keyboard contoller should be used to indicate which scancode it outputs for each key, so the programming can be platform independent. A USB cable may need to be used for the programming option.
Subscribe to:
Posts (Atom)