[syslinux] Read disk not working in 3.35+

[Ram Yalamanchili]

bump? can someone please confirm if 0x19h works for them with intcall 0x22?

thanks,
Ram

On 2/12/07, Ram Yalamanchili <ramyinc at gmail.com> wrote:
> Hey,
>
> Looks like read disk function which was launched in 3.35 isnt working.
> Did anyone test this on any hardware? I'm using it thru the com32
> interface to read contents of the active partition of a USB boot key
> (syslinux).
>
> I did a sample test like:
>
> void scanAndPrint()
> {
>    com32sys_t regs_in;
>    char *sectorBuf = __com32.cs_bounce;
>    int i;
>    memset(sectorBuf, 0x0, 512); // XXX MARK 1
>
>    for (i=0; i< 10; i++) {
>       int j;
>
>       memset(&regs_in, 0, sizeof regs_in);
>       regs_in.eax.l = 0x0019;
>       regs_in.edx.l = i; // sector number
>       regs_in.ecx.l = 1; // sector count
>       regs_in.es = SEG(sectorBuf);
>       regs_in.ebx.w[0] = OFFS(sectorBuf);
>       __intcall(0x22, &regs_in, NULL);
>
>       printf("%d: ", i);
>       for (j =0; j < 512; j++) {
>          if (sectorBuf[j] != 0)
>          printf("%x", sectorBuf[j]);
>       }
>       printf(" .\n");
>    }
> }
>
>
> This should print something if non-null data is encountered, but i see
> just a "." for the first 10 sectors. xxd thru linux on the USB key
> which I'm booting from shows its has data (duh!).
>
> The address i see for cs_bounce is 0x4000:0000
> If I memset this address range to soemthing like 0x36, the final
> result prints 0x36. So looks like the buffer isn't touched at all
> after the call is issued.
>
> thanks.
>
> --
> Ram
>