int 13h and greater

IIRC you dork the cylinders/heads/sectors counts. I remember using things like Spinrite to set that up.

Cheers

Phil Hobbs

Phil the difficulty is with the disks that have more sectors than Ibm's code allowed for with the 256/63/1024 counts. Then there was, apparantly a 256/16/65500 (roughly) count. Then Pheonix established an extension with a 64 bit sector count, the "logical" accounting, but, as I mentiioned, there is no evidence of that being in use. If you, or anyone else, comes across a clue pointing to current methods do let me know.

Hul

Phil Hobbs wrote:

Just google something like "int 13h large disk drives" All kinds of info comes up.

I don't know whether or not it extends that far but in the distant past DOSREF provided the most complete reverse engineered list of BIOS calls.

That version is far too old for GB disks but it may help the OP find something appropriate by asking in the right place.

If I Recall Correctly, there is little hope to educate someone that can't even copy/paste correctly.

Pro tip: post to public forums only when sober.

Cheers

Phil Hobbs

..and then:

The seemly best reference i saw was: The BIOS IDE Harddisk Limitations - web.inter.nl.net [Search domain web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm] web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm Just as with the 504 MB barrier, you need one of these solutions to break the 8 GB barrier if you do not have the Int 13h extensions: A BIOS upgrade Add-in card with an Int 13h extension BIOS (this takes over the Int 13h interface only) Software like Disk Manager or EZ-Drive.

Bios calls are protected mode. Only used by the boot loader, then The windows disk drivers handle the rest.

Cheers

Isn't BIOS interrupts only used for starting the initial bootstrap code. When some OS code is up and running, those codes will access disks of whatever size. After the initial bootstrap, the extremely slow BIOS is no longer used.

Use a small (< 8GB) disk for booting and most fundamental parts of the OS and use huge disk(s) for application data.

I don't see anything in Ralf Brown's classic list.

There's always the IDE port itself. Have fun.

And from there, obviously, you need to know where the registers and spaces are, and how to use them. In other words, writing vendor-specific drivers. Good luck. You may be better off finding the respective Windows driver and reverse-engineering it, or building an interface to run it as such. Or finding the respective Linux driver, and implement the interface (freely published) and adapt it to DOS interfaces.

Incidentally, you didn't note what kinds of disks you're trying to access. You also didn't specify what age of computers. IBM/Lenovo, HP and Dell are all current brands, and their latest products run modern OSs that access "large" disks just fine, so your problem seems to have a trivial solution... :-)

Tim

Tim the hp laptop I have doesnt have the "extension" Phoenix wrote, but the bios is dated 2013. By the way, Brown lists that extension. Called, if I remember correctly, IBM/MS extension. 64 bit int. for sectoe #. That extension dates to 98,99,2000. Writing a driver for the ide disks is doable but i'd like to use the USB via 13h. Given a usable 13h extension, I could do a little editing on a disk editor I have and that would solve a fair chunk of whats neccessary. Ide may be there and maybe not. The trivial solution you mention is the objective. But, from whats seen so far, it may be hindered by the manufacture's "my applications" interests.

Hul

Tim Williams wrote:

Can you not just boot into $OS, mount the drive, with all the usual device drivers, and inspect it that way? Boot a Knoppix CD and poke at /dev/hda?

My 2010s laptop running WinXP accesses its 500GB SATA drive just fine.

If your laptop can't do that, it's not worth anything anyway. Except perhaps as a vintage relic, but then, it's not nearly old enough to have any value, either.

I suppose I'll have a hard time convincing anyone on /Usenet/ that they should be pragmatic.

Tim

Isn't a T bigger than a G? What is your problem?

Tim - writing a program on windows whatever is a hassel. Especially if its a disk editor using the bios. Microsoft frowns on such programs.

Hul

Tim Williams wrote:

So what are you trying to write? Some stand-alone bare metal program or what?

Several things Joe. First a disk editor on msdos (close to "bare metal") that need to access > 8gb. Second a bios, or bios style, driver for an operating system (Minix).

Hul

Joe Chisolm wrote:

So you'll spurn an OS that supports your operations grudgingly, and rather choose an OS that doesn't support the device at all..?

A bootable *nix image, on CD-R or thumb drive, seems like the way to go. Learning Linux commands seems like a small price to pay.

Tim

Wow - Minx - that's a name I have not heard in many years. Last time I did anything with Minx was maybe '89 or '90 time frame. I see it's still hanging in there but the hardware requirements have sure grown in the last 30 years.

Pull the source code for FreeDOS. I think it will handle drives up to 128GB. See how they are doing it. In a simple dos environment you can talk directly to the controller I did a lot of work modifying the driver for a 9-track tape drive (anyone remember the old IBEX ISA tape controller with the pertec interface?) You dont have to do command queing or sector sorting or any of that stuff. Hell, just spin wait for command completion.

If you are trying to write some hacking tool that will work across a bunch of different mother boards using just INT 13H you will have limited success.