PE> Amibios says that they are:

PE> 826 16 63
PE> 1050 16 63
PE> 4969 16 63
PE> 4969 16 63

RS> Presumably you meant that thats what the bios says in the autoidentify,

PE> That is correct.

RS> in the normal mode, without LBA enabled.

PE> It makes no difference whether I use normal mode or not, it
PE> always comes up with the same parameters in the auto-identify.

Yes, but presumably not in the screen you see when booting, while the
bios itself is putting the text on the screen very early on, after the
video bios has done that itself. Ditto with the screen inside the cmos
setup, AFTER you have done the autoidentify, say when you are looking at
the most general list of the drive params and stuff like the floppy drives.

It should THEN be showing the CHS that say DOS sees at the
lowest level on the drive params, coz DOS doesnt understand
anything about LBA and so the CHS is faked up to keep it happy.

PE> My program says that they are:

PE> 825 16 64
PE> 524 32 64
PE> 873 16 64
PE> 873 16 64

RS> The difference of one in the cylinder count with the first drive is
RS> complicated. There is a reserved maintenance cylinder as far as DOS
RS> is concerned. So you do usually find that the manufacturers label
RS> data on the drive itself is one more than the bios finds with an
RS> autoidentify. Tho some of the manufacturers have started to make
RS> those numbers match because of the confusion that can cause.

PE> Hey, I paid good money for that 1 cylinder.

Yeah, like about 10c.

PE> I am glad I'm not the manufacturer having to decide whether
PE> to set the parameters assuming first or non-first drive.

That doesnt vary with whether its first or not. It applys to both your
non Sirrocco drives once you allow for the halving of the track number
and doubling of the head number from the autoidentify values to get the
track number below 1024.

RS> The 63/64 with the sectors is just because DOS numbers those from 0, not 1.

RS> Just to fuck things up completely, the head number from 1, not 0. Bizarre.

PE> You didn't actually state here that it IS 63/64, just that there
PE> is an issue regarding 63/64.  I already know there is an issue.

God knows what this is about, totally opaque comment.

RS> The Sirrocco data is certainly rather odd. OTOH
RS> presumably FDISK does see the full capacity of the drive,
RS> so it cant actually be seeing those numbers you list.

PE> Good point.  You are right, fdisk does see the lot.  It just
PE> won't let me select >504 meg for my installable partitions.

Yeah, FDISK wont normally be using INT 13 on an IDE drive.

RS> Come to think of it, I dunno what the OS/2 FDISK does specifically
RS> about that stuff, whether it notices that LBA is enabled and just
RS> uses the maximum block number and ignores that CHS data completely.

PE> "uses the maximum block number" is outside my
understanding of fdisk.

Again, a rather opaque comment. LBA just specifys the drive by the maximum
block number, the drive can be interrogated and asked 'what is the maximum
block number'. Once the drive is operating in LBA mode, nothing of the CHS
detail is visible outside the drive itself, it is responsible to working
out which particular cylinder/head/sector a particular block occupys.

RS> And you dont say just how you ran that program,
RS> it doesnt prove too much if you ran it inside OS/2,

PE> I ran it in a DOS box under OS/2.

Very undesirable. Particularly when its producing
obviously dud values. Largely because you have an entire
layer of OS2 faking that stuff up for the DOS app.

RS> as far as what the bios itself reports. You really need
RS> to run it with plain booted DOS atleast, say from a floppy.

PE> Did that.  Got very interesting results indeed!

RS> Just what INT 13 reports is complicated by a wide variety of issues.

PE> Note that 4969 % 1024 = 873.

RS> God knows what you mean here.

PE> C syntax is "%" means remainder.  4969 divided
PE> by 1024 gives 4, with a remainder of 873.

OK, I thought thats what you meant when I first read it, then managed
to use the values of 4696 in the spreadsheet by accident and concluded
that it wasnt the remainder at all. Brain fart on my part.

PE> The remainder is what is being reported to me by the
PE> OS/2 bios. Coincidence?  Unlikely.  Bug?  Very likely.

Yeah, likely there is some significance in that.

PE> I therefor conclude that there is a bug in Amibios that
PE> is causing LBA to not remap the drive correctly.

RS> Thats a pretty rash conclusion at this stage.

PE> Hey, how was I supposed to know that OS/2 was intercepting the BIOS!
PE> If I'd known that, I would have said "OS/2 or Amibios".

Well, even just the fact that there have been no reports of problems
with the Amibios and LBA with say plain dos would suggest that its
unlikely that the bios is just fucked in some gross way.

PE> Note that LBA on the 540 meg drive is
PE> working fine, as the figures above show.

RS> Well, there certainly is some problem with the Siroccos, but just
RS> where that problem lies is another matter entirely at this stage.

PE> OS/2!

Not very surprising given the APAR on >2GB drives.

PE> BTW, can you tell me whether there are 63 or 64
PE> sectors per track. I added 1 to get the # heads right,
PE> but not sure if I should do the same with sectors.

RS> See above.

PE> You could have just given me a straight answer to the question.

I did.

(Continued to next message)
@EOT:

---