You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
Is there a ad-on to PBDOS to read a hard drives sector directly on a IDE drive in LBA mode.
In this mode you do not address the hard drive by Head, Cyd, sector but by absolute sector.
I'm not quite sure what LBA mode is. Reading disk sectors by
feeding the absolute sector number requires int25. This is okay
except it won't work on IDE and (I think) SCSI drives. That
interrupt will work on the old MFM and RLL drives.
The only interrupt that I found that will work on IDE drives is
int13. However, you have to break the absolute sector number
down into Track, Head and Sector.
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
LBA is Long Block Addressing. If I remember correctly, it is used for hard drives larger than about 850 MB. (At the very least, I had to use it for a 1.2 GB hard drive I installed several years ago.)
As to how to read the absolute sectors, I have no clue.
Alan
------------------
Alan C. Earnshaw
Information Management Systems, Inc. http://www.infoms.com
I have an int13 routine that will read and write absolute
sectors on IDE drives. It is limited to 1024 cylinders, 63
sectors per track and 64 heads. Give me your e-mail address
and I will send it to you as a ZIP'd source file. It was
written in PB2.1f but you should be able to update/translate
it if you need to.
It should be noted that writing absolute sectors is incredibly
!!!! DANGERIOUS !!!!. It writes sectors without regard for
partition structure, operating system on the drive or anything
else.
!!!! MAKE SURE YOU HAVE A CURRENT BACKUP !!!!!
If you want my source file, send your e-mail to me at [email protected]
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
Originally posted by Mel Bishop: I'm not quite sure what LBA mode is. Reading disk sectors by
feeding the absolute sector number requires int25. This is okay
except it won't work on IDE and (I think) SCSI drives. That
interrupt will work on the old MFM and RLL drives.
The only interrupt that I found that will work on IDE drives is
int13. However, you have to break the absolute sector number
down into Track, Head and Sector.
An LBA is a Logical Block Address. The first sector on a disk,
ie, the one at CHS 0,0,1, is LBA 0, and the LBAs are just counted
forward from there in numerical sequence. LBA addressing is done
via int 13 using the LBA extensions (see Ralf's at int 13, ah=42).
INt 25/26 will work on all HDD types up through MS-DOS 7.0. With
DOS 7.1 25/26 are replaced by int 21, Function 73. The reason
you can't get int 25/26 to work via a CALL INTERRUPT is that
since DOS 5 (I think) those interrupts return with the caller's
flags still on the stack, which causes a lockup, since CALL
INTERRUPT does not accomdate that. You have to implement those
ints with in line ASM or etc.
For another poster on this thread: LBA was introduced to handle
drives >8GB.
Original poster: the LBA extensions are documented in Ralf
Brown's Interrupt list. For a code example you can disassemble
the MBR boot loader from a WIN95 OSR2 or WIN98 system.
A good thing to do when experimenting with int 13 is to do it
from a Windows DOS box. Reads will work, writes won't. So you
are less likely to accidently mess up your file system.
Actually I thought LBA was to support partitions/drives over 2gb.
Over 8gb it doesnt matter if you have LBA enabled or not, if your
BIOS doesnt support it (8gb+) then you only option is to use
something like seagates "Disc wizard" which sets its own drive
parameters.
As for using int13... use the BIOS interrupts, someone has
mentioned them before.
Originally posted by Neil Hosgood: Actually I thought LBA was to support partitions/drives over 2gb.
Over 8gb it doesnt matter if you have LBA enabled or not, if your
BIOS doesnt support it (8gb+) then you only option is to use
something like seagates "Disc wizard" which sets its own drive
parameters.
As for using int13... use the BIOS interrupts, someone has
mentioned them before.
Its 8 GB.
You can address up to 8GB in CHS mode. Past that your BIOS must
support the interrupt 13 LBA extensions.
This is a confusing subject. LBA comes into play in two ways:
If your BIOS supports an LBA translation mode (ie, you have
an LBA option in BIOS HDD auto detection), that means that the
BIOS supports LBA at the controller interface. If the BIOS
supports the int 13 LBA extensions, then LBA is supported at the
application interface. Support of the LBA extensions is required
for a BIOS to handle drives > 8 GB.
All of this greatly complicates the process of reading/writing
a hard disk via the BIOS. The fact is that there no good reason
for an application to do that, except for data recovery and
antivirus tools.
Mr. Green stated that int13 writes will not work in a Windows
DOS box. I beg to differ in that it DOES work. (At least using
CHS on non-LBA drives). I use it all time in a program I wrote
to switch between primary boot partitions.
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
Originally posted by Mel Bishop: Mr. Green stated that int13 writes will not work in a Windows
DOS box. I beg to differ in that it DOES work. (At least using
CHS on non-LBA drives). I use it all time in a program I wrote
to switch between primary boot partitions.
You must know something that I don't, then.
Could you specify the exact version of Windows you are doing
this on and post an example of code that does it.
I just tried it on 95/OSR2, copied out my MBR and
tried to write it to CHS 0,0,2. Didn't work .
The following functions are from the actual program that I wrote
to switch between primary boot partitions on my drive. The drive
is a seagate 2GB. The program itself has never failed to work
under any circumstances.
My current system is: An IBM value point L4F 486/66 running an
early version of Windows/95 (don't know the exact version). The
boot program was written in PB v2.1f under DOS 6.2 and has been
in service for about 4 years now.
Was just wondering if you maybe have an anti-virus program
rattling around in the background that you maybe forgot about or
it could be that I just got "lucky".
function read.hard$(d, t, h, s, n) ' Read a hard drive sector
d$ = string$(n * 512,65) ' d = drive number (0-3)
Reg 1, (2 * 256) + n ' t = track
Reg 2, strptr(d$) ' h = head
Reg 3, ((t and &hff) * 256) + s ' s = sector
Reg 3, Reg(3) or (t and &h300) \ &h4 ' n = number to read
Reg 4, (h * 256) + (d or &h80) '
Reg 9, strseg(d$) '
Call Interrupt &h13 '
read.hard$ = d$ '
end function '
'
function write.hard(d, t, h, s, n, d$) ' Write a hard drive sector
Reg 1, (3 * 256) + n ' d = drive (0-3)
Reg 2, strptr(d$) ' t = track number
Reg 3, ((t and &hff) * 256) + s ' h = head number
Reg 3, Reg(3) or (t and &h300) \ &h4 ' s = sector number
Reg 4, (h * 256) + (d or &h80) ' n = nbr sects to write
Reg 9, strseg(d$) ' d$ = data to write
Call Interrupt &h13 '
end function '
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
That's a straight-forward int 13 write. Doesn't work on my
system. BTW, I don't have anything running (other than Windows
itself that would block an int 13 write.
And you are running your boot manager from inside a Windows DOS
box?
I bounced the e-mail thing off Lance. He said we should keep it
in the fourm for the benefit of others who browse but don't post.
I finally found my version of windows (4.00.950 r-3). I don't
know of any reason, however, that windows would support something
in one version and not in another.
I run my boot manager from anywhere I can get to it. "Start>run",
from a pure DOS prompt or a window (it just don't matter).
The one thing that I can think of is windows has a tendency of
being rather autocratic in its want for system resources. It MAY
be that your system and/or hard drive's BIOS is being taken over
by windows. Why it wouldn't on mine?????
One thing you can do (shudder) is if you have a spare IDE drive,
send it to me. I will partition it off and send it back to you.
That way, if it works on your system under DOS, install windows
and see what shakes loose from there. The program is taylored
for each individual drive and I don't have a "do-it-all" sub
for FDISK (yet).
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
I'm not 100% clear on how Win95 mediates BIOS int calls, but
its obviously filtering writes and returning an error code 3
(write protected) on every system I have looked at (quite a few).
(and no, I don't have the BIOS virus protection turned on .
Those are all OSR2 or 98. I don't recall if I have ever done
any coding on the old retail version of W95. A version difference
could be the answer, or differences between your system and the
ones I have access to.
At any rate, it seems that doing int13 writes from a Win DOS box
is something you can't count on, one way or the other.
Thanks for the offer re: partioning a drive, but I don't think
we'd learn anything from it.
Mel, one stray thought occurred to me... is your Win95 system using "MSDOS compatibility mode" drivers to manage disk I/O? Check it out in Control Panel|System|Performance... it could be that the MSDOS drivers are permitting your Int 13 calls.
You may be on to something here Lance. The windows I have
installed is an upgrade version from windows 3.1. I checked out
the system like you suggested. Though I didn't find anything
specifically related to "MSDOS Compatability Mode", I did find
under "Troubleshooting" that there are 6 "Disable" options. All
are unchecked. The "System Properties" show the File System to
be 32-bit as well as Virtual Memory = 32-bit. It just may be
that the "upgrade" from windows 3.1 left DOS drivers on the
hard drive that allows for int13 writes.
------------------
There are no atheists in a fox hole or the morning of a math test.
If my flag offends you, I'll help you pack.
Here is something I found a while back when I was playing around
with direct hard disk access. Follow the link and look for the
header "IBM/MS INT 13 Extensions" there you will find extended
bios calls to handle large drives. Another usefull idea would be
to download a version of slackware linux and look at the source.
Linux has the source to directly address the hard disk hardware
through port manipulation + DMA. http://www.ctyme.com/intr/cat-008.htm
Originally posted by Lance Edmonds: Mel, one stray thought occurred to me... is your Win95 system
using "MSDOS compatibility mode" drivers to manage disk I/O?
Check it out in Control Panel|System|Performance... it could be
that the MSDOS drivers are permitting your Int 13 calls.
I've tested for that. Didn't make any difference on the system
I was using. I noticed that Win95 (OSR2) moved the int 13 entry
point in compatability mode just as it does with 32 bit driver.
With Mel's system, I would guess that disk I/O is for some
reason going through the original BIOS handler. This is checkable
with int 2Fh, ah = 13h, but be real careful using that call.
Just to add to the confusion in this topic consider the following:
INT13h access to drives is allowed in windows 95, 98, in
protected mode. you can read and write sectors. in windows me you can
only read sectors, windows me prohibits int13h access for writing.
you get a read-only return for the int13h action.
in real mode everything is possible.
there is a library that allows the user access to sectors in LBA
mode, but it does not support int13h extensions (drives larger than
8GB). the library can be found at www.basicguru.com (this in respons
to the original post). if you can't find it, mail me, i'll send it
to you (i forgot the name but i've got it here somewhere).
i've probably said some things that have been said already, so be it.
hope this helps.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment