X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: SCSI drives (was: Fun with USB) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 30 Jun 2005 10:27:02 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: SCSI drives (was: Fun with USB) Thread-index: AcV8rqQ3VjGxbqxOS+KL/8x/MY0zowAVp8tw From: "da Silva, Joe" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j5U0RDxK003067 Reply-To: opendos AT delorie DOT com Hi Gary, et al. Well, I've no idea what an "NT BIOS" is supposed to be, sounds like some marketing BS to me. I know NT 3.5x is a very primitive O/S, so I wouldn't be surprised if this in itself was limited to 8G, it may well rely on the BIOS for its disk access too (speculating here). I'm sure I've seen one or two tools that can check if you have an Extended Int 13h BIOS, though I can't recall which or where at the present. AFAIK, you need this Extended Int 13h API for any LBA-capable DOS to break the 8G limit. I think Ontrack and the like have BIOS extension MBR's that can provide this capability if your ROM BIOS doesn't have it, although I'm not sure if that only applies to IDE/ATA drives. I suspect what you have is a SCSI card with its own BIOS ROM, right? Well, AFAIK, the above is the situation for DOS, however for NT 4+, Linux, and the like, the BIOS is only used to start the O/S, so the boot stuff may still need to be limited to the first 8G. After loading, these O/S use their own capabilities to access the hardware directly, so the BIOS capabilities, including any 8G limit, become irrelevant. The tricky bit is ensuring the boot stuff is accessible via the BIOS to "start the ball rolling". So, I'd try to determine if your SCSI BIOS or driver supports the Extended Int 13h API, otherwise you have no chance of supporting >8G with DOS. That said, all signs ("inability to break the 8Gb limit with FDISK R2.31 and DR-DOS 8.0 or a WinMe DOS and FDISK") point to a BIOS that doesn't support the Extended Int 13h API. This stuff about "Extended BIOS Translation ..." sounds like the CHS bit-shuffling trick that allowed DOS to break the 512M barrier, not the Extended API, which provides the extra bits needed for addressing up to 128G or some such. Well, that's about all the light I can shed on this, based on my possibly flawed understanding of it. If you want to pursue >8G capability with a suitable DOS, look for a BIOS upgrade for your SCSI card or upgraded driver (as appropriate) or perhaps Ontrack's (or similar) DDO stuff also works with SCSI drives, in which case your drive manufacturer may have an OEM version of their Disk Manager package for you to download. Joe. > -----Original Message----- > From: Gary Welles [mailto:gary AT wellesway DOT com] > Sent: Wednesday, 29 June 2005 11:26 PM > To: OpenDos > Subject: Re: SCSI drives (was: Fun with USB) > > > Joe da Silva wrote: > > > Firstly, you need SCSI drivers or BIOS that provide > > an Extended Int 13h API. > > This may not be the case. The machine was once described as > having an "NT BIOS". However it's setup disks are for NT > 3.5x, DOS/Win3.1, OS/2 v2.x or Warp, Netware v3.12/v4.x, > UnixWare 2.x, SCO UNIX 3.2/4.2 or OpenServer 3.0. > > Which could explain my inability to break the 8Gb limit with > FDISK R2.31 and DR-DOS 8.0 or a WinMe DOS and FDISK. > > Perhaps of interest a SCSI BIOS default is: > > Extended BIOS Translation for DOS Drives > 1 GByte > > and FDISK R2.31 offers: > > /CHS or /LBA Force MBR to use either CHS or LBA INT 13 Extensions. > > In any event DOS partitions greater than 2Gb are of limited > use, and now with Joe's "Firstly" information I expect I'll > skip ROM-DOS and try SCO OpenServer. > > -- Gary Welles > >