Gareth Magennis wrote:

"D Yuniskis" wrote in message
...
Meat Plow wrote:
On Thu, 04 Nov 2010 10:03:10 -0700, D Yuniskis wrote:

Larger disks use LBA addressing

So do smaller disks, LOL!

Only *some* smaller disks. Older (the OP was talking about "old
systems" -- I guess I take that *literally*) drives expected
the CHS values to conform to the *physical* geometry of the
drive (i.e., before ZDR, etc.). Older INT13 limits trapped
you at ~500MB (I have a selection of ~300MB drives on hand for
just such machines).

Early IDE implementations required the INIT message to provide
the *actual* physical geometry implementation to the drive's
controller. Getting this wrong resulted in a scrambled disk.
(I was "lucky"? enough to be a victim of one of the first IDE
machines ~1986 vintage when the rest of the world was still ST506).

As processing power IN THE DRIVE became affordable, it was possible
for the drive to map arbitrary "virtual" geometries into their
own physical geometry. This allowed you to use any "drive type"
that your BIOS would support -- so long as you never exceeded the
physical capacity of the device. I've modified the ROMs in my
Compaq Portable III and Portable 386 to create bogus drive types
to allow 300M drives to be used in these boxes (this is tricky as
you have to do so without invalidating the ROMs checksum, etc.)
instead of the ~100MB limit imposed by the original drive type
selection.

"Type 47" eventually became synonymous with "user defined geometry"
as BIOS's began to allow these extra parameters to be stored in
"CMOS" (once the 50 byte limitation of the original MC146818 was
ignored). This allowed you to fabricate an arbitrary geometry
for your drive without concern for the "claimed" physical geometry
(since ZDR has made this meaningless) as long as your geometry
fit "within" the drive's capacity.

Nowadays, the drive's capacity is queried (won't work with antique
drives!) and automagically accommodated.

Of course, that's at the lowest level in the drive interface "stack".
You still have to deal with partitions, slices and the individual
requirements of the file systems hosted *on* that drive -- any of
which can also constrain the usable space.

Many OS's still have throwbacks to physical device geometries for
hysterical raisins. E.g., you can't boot a Solaris systems (pre 10?)
if the startup code isn't within the first 2G of the boot partition;
the same is true of many MS OS's (DOS 3.3, IIRC, had a 32M! limit).

Any of these things can be responsible for upsetting the OP's
device. I stand by my initial comment: format the drive on a
PC and then install it in the device. If you are tech savvy,
*wipe* the drive first; then let the device *try* to format it;
then examine the MBR and partition table to see if everything
is *almost* right (it could be that the "problem" lies in writing
the partition table sanely); then, resort to the PC approach

(I've used this sort of tactic to upsize drives in NAS boxes, etc.
beyond "factory supported limits")

LBA is a particularly simple linear addressing scheme; blocks are located
by an integer index, with the first block being LBA 0, the second LBA 1,
and so on.

IDE standard included 22-bit LBA as an option, which was further extended
to 28-bit with the release of ATA-1 (1994) and to 48-bit with the release
of ATA-6 (2003). Most hard drives released after 1996 implement Logical
block addressing.

http://en.wikipedia.org/wiki/Logical_block_addressing


Interesting stuff guys. Thanks.

In this case there is no OS on the disk at all, the 2480 does not boot from
it.
I have successfully upgraded the 2480's OS via MIDI onto its onboard Flash,
with no valid hard drive installed. The drive is purely storage.


It depends on the BIOS of the computer. That sets the upper limit.


Does this make things any easier?
Is cloning the new drive from the working (noisy) one a viable proposition?

Cheers,

Gareth.




--
Politicians should only get paid if the budget is balanced, and there is
enough left over to pay them.