Message-ID: <00c701c044f2$11bc4760$11fea8c0@dell>
From: "Ben A L Jemmett" <ben DOT jemmett AT ukonline DOT co DOT uk>
To: <opendos AT delorie DOT com>
References: <00b801c02814$cc72b3a0$0400000a AT alain-nb> <01d601c04023$ddf751e0$cb881004 AT dbcooper> <005301c04062$9af82420$11fea8c0 AT dell> <001601c041bf$4c924ff0$6f1e0404 AT dbcooper> <000101c041dc$47239a20$11fea8c0 AT dell> <010a01c042dd$202ba230$3d1e0404 AT dbcooper> <017701c04365$41ca2aa0$11fea8c0 AT dell> <00ba01c04442$62576980$eb881004 AT dbcooper>
Subject: Re: DRDOS FDISK
Date: Thu, 2 Nov 2000 17:17:02 -0000
Organization: Jemmett Glover Software Development
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: opendos AT delorie DOT com

> I don't understand why any OEM would forget about using the BPB if it is
> part of DOS. They are sent the MS source code for DOS and build on it. Why
> would they want to go to the trouble to delete that from the source code.
I guess they wanted the space to play with for boot sector code, and let DOS
use the default BIOS-based BPBs.

> > Either that one or the one at offset 0Ah in the BPB - I'll guess that
DOS
> > uses the FAT one in preference to the BPB one.
>
> I don't think so. I am not certain what that is used for, it is an
extended
> signature byte. It may be different in some versions, but it seems like it
> was always a 29 hex. (At least for HDD.)
Well, I've found the following table listing some values for the first entry
in the FAT:
F0    Unidentifiable
F8    Fixed disk
F9    Double-sided, 15 sectors/track
F9    Double-sided, 9 sectors/track (720Kb)
FC    Single-sided, 9 sectors/track
FD    Double-sided, 9 sectors/track (360Kb)
FE    Single-sided, 8 sectors/track
FF    Double-sided, 8 sectors/track

(The two entries for F9 are verbatim).  This coding appears to be the same
used in the BPB. (I just pulled the first sector of a FAT from a Zip disk
and the ID there matches the BPB ID).

I think a fixed disk is F8h - I've checked this both on the actual HDD in
this system and on a random Zip disk (the latter has a BPB as follows:)
16AB:0100                                   00 02 04 01 00
.....
16AB:0110  02 00 02 00 00 F8 BC 00-20 00 40 00 00 00 00 00   ........
.@.....
16AB:0120  00 F0 02 00 00 00 29 42-2F E6 1A 52 41 4C 31 20   ......)B/..RAL1
16AB:0130  20 20 20 20 20 20 46 41-54 31 36 20 20 20               FAT16
(This is a copy and paste from DEBUG, using the commandsL 100 3 0 1 and D
10B L 33)

I think Win98 (FAT32) uses a different BPB format - the media descriptor is
in the right place, but after that I think the values are laid out
differently to encode the 32-bit locations.


> [Copy protection]
> Some even used tracks beyond 39 and DOS would not copy those. AFAIK there
> were never any HD disk copy protection, it was only used on DD disks.
Hmm...  A piece of software I recently disassembled (trying to find out why
it would crash on load on this machine) looks for a special track in the
last cylinder of a disk, and can be installed to a 1.2Mb floppy (the INSTALL
program writes the copy-protected track with a special 'installed' flag).

> This may have changed or may some OEM DOS does it differently, but what
IBM
> DOS DISKCOPY did/does is first it formats the disk then it copies all of
the
> files. It may or may not copy the BR. But as I recall, if I copied a 3.3
> formatted diskette with MSDOS 5.0 installed and used 5.0 DISKCOPY, the BR
> would show the OEM ID as MSDOS5.0.
My Amstrad 3.2 DISKCOPY copies the whole lot as a lump of sectors - the boot
sector and all.  I know, since the 'Starting out with the PC' instructions
include 'copy all four system disks supplied', two of which has a DOS Plus
boot-sector while the others are MS-DOS - the boot sectors are copied
correctly.  It doesn't even adjust the data in case of a bad sector - so if
you copy a good diskette onto one with known bad sectors, the bad sector
marks in the FAT disappear.

Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)