From: Ben Peddell <killer DOT lightspeed AT bigpond DOT com>
Subject: Re: Sector Editor?
Newsgroups: comp.os.msdos.djgpp
References: <b76ti5$fni$1 AT newsg4 DOT svr DOT pol DOT co DOT uk> <3e9773bd DOT 19881347 AT news DOT voyager DOT net> <b78off$2mo$1 AT news7 DOT svr DOT pol DOT co DOT uk>
Lines: 88
User-Agent: KNode/0.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-ID: <XbTla.12699$1s1.207725@newsfeeds.bigpond.com>
Date: Sat, 12 Apr 2003 22:09:58 +1000
NNTP-Posting-Host: 144.139.175.225
X-Trace: newsfeeds.bigpond.com 1050148727 144.139.175.225 (Sat, 12 Apr 2003 21:58:47 EST)
NNTP-Posting-Date: Sat, 12 Apr 2003 21:58:47 EST
Organization: Telstra BigPond Internet Services (http://www.bigpond.com)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Matthew Smith wrote:

> 
> "Chris Giese" <NoEmailAds AT execpc DOT com> wrote in message
> news:3e9773bd DOT 19881347 AT news DOT voyager DOT net...
>> "Matthew Smith" <matt AT the-spammers-have-me-already DOT freeserve DOT co DOT uk>
> wrote:
>>
>> >Failing this, can someone show me how to read and write sectors on
> an
>> >LBA drive using INT 13h extensions?
>>
>> http://my.execpc.com/~geezer/osd/disks/diskio.zip
>>
>> Unzip it, and look at function lba_biosdisk() in file DJGPP.C
>>
> 
> Cheers :) Your code shows I'm basically on the right track.
> 
> One thing I can't be sure about is the buffer address in the packet.
> You treat this as a far pointer while my reading of the RBIL suggests
> this is a flat address. Has your code been tested?
> 
> And a question for the near future; the 64bit address, how is that
> represented?

The RBIL only suggests a flat address for EDD-3.0. Also note that the flat 
address given in the packet is 64-bit. 
Notice that this is a real-mode or 16-bit protected mode call. EDD 3.0 
probably supports 32-bit protected mode (or even 64-bit x86-64) calls. If 
it were a flat address, it would say so, since _all_ other calls in RBIL 
have pointers as real-mode far pointers.
I'd say that the 64-bit address would simply be represented as a long long 
int. If you wanted to use it, then you'd add an 
        unsigned long long buf_ptr;
to the structure, and check for EDD-3.0 when calling the installation check 

    asm (
         "movw $0x4100, %%ax\n\t"
         "movw $0x55AA, %%bx\n\t"
         "movb %1, %%dl\n\t"
         "int $0x13\n\t"
         "jc 1f\n\t"
         "cmpw $0xAA55, %%bx\n\t"
         "jne 1f\n\t"
         "movb %%al, %0\n\t"
         "jmp 2f\n"
         "1:\n\t"
         "movb $0, %0\n\t"
         "2:"
         : "=q" (ext_ver)
         : "q" (driveno)
    );
    if (ext_ver == 0x30){
        use_addr64();
    } else {
        use_rmaddr();
    }         

        

--------d-1342-------------------------------
INT 13 - IBM/MS INT 13 Extensions - EXTENDED READ
        AH = 42h
        DL = drive number
        DS:SI -> disk address packet (see #00272)
Return: CF clear if successful
            AH = 00h
        CF set on error
            AH = error code (see #00234)
            disk address packet's block count field set to number of blocks
              successfully transferred
SeeAlso: AH=02h,AH=41h"INT 13 Ext",AH=43h"INT 13 Ext"

Format of disk address packet:
Offset  Size    Description     (Table 00272)
 00h    BYTE    size of packet (10h or 18h)
 01h    BYTE    reserved (0)
 02h    WORD    number of blocks to transfer (max 007Fh for Phoenix EDD)
 04h    DWORD   -> transfer buffer
 08h    QWORD   starting absolute block number
                (for non-LBA devices, compute as
                  (Cylinder*NumHeads + SelectedHead) * SectorPerTrack +
                  SelectedSector - 1
 10h    QWORD   (EDD-3.0, optional) 64-bit flat address of transfer buffer;
                  used if DWORD at 04h is FFFFh:FFFFh