[Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Mike Nordell]

Johannes Martin wrote:

> a little while ago we had some discussion about floppy emulation not
> working in qemu once an OS has been installed. Our assumption was that
> floppy access worked through int13 bios emulation but not really down at
> the hardware level.

Both have problems (errors). Fabrice was (AFAIK) notified by me over one
month ago.

1. diskette_param_table in rombios.c from Bochs is too short. It neeed two
more bytes, else e.g. NT believes the floppy only got 31 cylinders (the code
following the table begins with "push ds", 0x1e, and that just happens to be
"maximum track" NT expects). Append:
db 79
db 0

This is obvious if looking at the registry value
HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\x\DiskController\y\Flo
ppyDiskPeripheral\0\Configuration Data.

(x, y was 5 and 0 respectively on a real machine, but you might experience
local fluctuations)

Compare the last two bytes from a real system (working) with a non-working
QEMU-installed system.

2. fdc.c has got some problems:
2.1 fdctrl_stop_transfer:
- fdctrl->fifo[0] = status0 | (cur_drv->head << 1) | fdctrl->cur_drv;
+ fdctrl->fifo[0] = status0 | (cur_drv->head << 2) | fdctrl->cur_drv;

2.2 fdctrl_write_data for case 0x08 /* SENSE_INTERRUPT_STATUS*/:
- fdctrl->fifo[0] =
    fdctrl->int_status | (cur_drv->head << 2) | fdctrl->cur_drv;
+ fdctrl->fifo[0] = 0x20 /* seek complete */ | (cur_drv->head << 2) |
fdctrl->cur_drv;

To be 100% clear about 2.2, it is AFAIK _not_ to return the main status
register like it was/is.

2.3 Just for good measure, let's tell the OS we got a two-sided drive. For
case SENSE_DRIVE_STATUS transfer, just before "fdctrl_set_fifo(fdctrl, 1,
0);" I put:
+ fdctrl->fifo[0] |= 0x08; // two-sided drive

2.4 And finally while treating READ_ID:
+ cur_drv->head = (fdctrl->fifo[1] >> 2) & 1;


As I haven't got the tools to rebuild the rombios, I can't verify that fix.
The other hardware-emulation fixes are AFAIK 100% correct.


/Mike

Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Derek Fawcus]

On Wed, Aug 18, 2004 at 05:35:19PM +0200, Mike Nordell wrote:
> Johannes Martin wrote:
> 
> 1. diskette_param_table in rombios.c from Bochs is too short. It neeed two
> more bytes, else e.g. NT believes the floppy only got 31 cylinders (the code
> following the table begins with "push ds", 0x1e, and that just happens to be
> "maximum track" NT expects). Append:
> db 79
> db 0
> 
> This is obvious if looking at the registry value
> HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\x\DiskController\y\Flo
> ppyDiskPeripheral\0\Configuration Data.
> 
> (x, y was 5 and 0 respectively on a real machine, but you might experience
> local fluctuations)
> 
> Compare the last two bytes from a real system (working) with a non-working
> QEMU-installed system.

Well that would seem to be an error in the NT code,  or we're triggering
something in the NT code which makes it seem to think there should be
a larger table.

The original table was only 11 bytes (as in the Bochs BIOS),  you can
look at the interrupt list to see.  It seems there is an enhancement
that adds an additional 3 bytes.

However from the layout of the BIOS,  it looks as if there is no room
to expand the table in place,  one'll have to have the param table pointer
(int 1e) point somewhere else.

Anyway,  I hacked something up if you want to try...

The diff is at http://www.employees.org/~dfawcus/rombios.c-diff,  and the
rom image is at http://www.employees.org/~dfawcus/bios.bin

I've not tried your other diffs yet.

DF

Format of diskette parameter table:
Offset  Size    Description     (Table 01264)
 00h    BYTE    first specify byte
                bits 7-4: step rate (Fh=2ms,Eh=4ms,Dh=6ms,etc.)
                bits 3-0: head unload time (0Fh = 240 ms)
 01h    BYTE    second specify byte
                bits 7-1: head load time (01h = 4 ms)
                bit    0: non-DMA mode (always 0)
                Note:   The DOS boot sector sets the head load time to 15ms,
                          however, one should retry the operation on failure
 02h    BYTE    delay until motor turned off (in clock ticks)
 03h    BYTE    bytes per sector (00h = 128, 01h = 256, 02h = 512, 03h = 1024)
 04h    BYTE    sectors per track (maximum if different for different tracks)
 05h    BYTE    length of gap between sectors (2Ah for 5.25", 1Bh for 3.5")
 06h    BYTE    data length (ignored if bytes-per-sector field nonzero)
 07h    BYTE    gap length when formatting (50h for 5.25", 6Ch for 3.5")
 08h    BYTE    format filler byte (default F6h)
 09h    BYTE    head settle time in milliseconds
 0Ah    BYTE    motor start time in 1/8 seconds
---IBM SurePath BIOS---
 0Bh    BYTE    maximum track number
 0Ch    BYTE    data transfer rate
 0Dh    BYTE    drive type in CMOS

Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Fabrice Bellard]

Applied a modified version. Tell me if it works.

Fabrice.

Derek Fawcus wrote:
> On Wed, Aug 18, 2004 at 05:35:19PM +0200, Mike Nordell wrote:
> 
>>Johannes Martin wrote:
>>
>>1. diskette_param_table in rombios.c from Bochs is too short. It neeed two
>>more bytes, else e.g. NT believes the floppy only got 31 cylinders (the code
>>following the table begins with "push ds", 0x1e, and that just happens to be
>>"maximum track" NT expects). Append:
>>db 79
>>db 0
>>
>>This is obvious if looking at the registry value
>>HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\x\DiskController\y\Flo
>>ppyDiskPeripheral\0\Configuration Data.
>>
>>(x, y was 5 and 0 respectively on a real machine, but you might experience
>>local fluctuations)
>>
>>Compare the last two bytes from a real system (working) with a non-working
>>QEMU-installed system.
> 
> 
> Well that would seem to be an error in the NT code,  or we're triggering
> something in the NT code which makes it seem to think there should be
> a larger table.
> 
> The original table was only 11 bytes (as in the Bochs BIOS),  you can
> look at the interrupt list to see.  It seems there is an enhancement
> that adds an additional 3 bytes.
> 
> However from the layout of the BIOS,  it looks as if there is no room
> to expand the table in place,  one'll have to have the param table pointer
> (int 1e) point somewhere else.
> 
> Anyway,  I hacked something up if you want to try...
> 
> The diff is at http://www.employees.org/~dfawcus/rombios.c-diff,  and the
> rom image is at http://www.employees.org/~dfawcus/bios.bin
> 
> I've not tried your other diffs yet.
> 
> DF
> 
> Format of diskette parameter table:
> Offset  Size    Description     (Table 01264)
>  00h    BYTE    first specify byte
>                 bits 7-4: step rate (Fh=2ms,Eh=4ms,Dh=6ms,etc.)
>                 bits 3-0: head unload time (0Fh = 240 ms)
>  01h    BYTE    second specify byte
>                 bits 7-1: head load time (01h = 4 ms)
>                 bit    0: non-DMA mode (always 0)
>                 Note:   The DOS boot sector sets the head load time to 15ms,
>                           however, one should retry the operation on failure
>  02h    BYTE    delay until motor turned off (in clock ticks)
>  03h    BYTE    bytes per sector (00h = 128, 01h = 256, 02h = 512, 03h = 1024)
>  04h    BYTE    sectors per track (maximum if different for different tracks)
>  05h    BYTE    length of gap between sectors (2Ah for 5.25", 1Bh for 3.5")
>  06h    BYTE    data length (ignored if bytes-per-sector field nonzero)
>  07h    BYTE    gap length when formatting (50h for 5.25", 6Ch for 3.5")
>  08h    BYTE    format filler byte (default F6h)
>  09h    BYTE    head settle time in milliseconds
>  0Ah    BYTE    motor start time in 1/8 seconds
> ---IBM SurePath BIOS---
>  0Bh    BYTE    maximum track number
>  0Ch    BYTE    data transfer rate
>  0Dh    BYTE    drive type in CMOS
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Derek Fawcus]

On Sun, Oct 03, 2004 at 11:49:26PM +0200, Fabrice Bellard wrote:
> Applied a modified version. Tell me if it works.

Well I was waiting to here back if the change I proposed had any
positive effects,  since I'm not experiencing the problems it's
supposed to address.

However I've had no feedback,  so it's a bit difficult to tell
if it's of help.

DF

[Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Mike Nordell]

Derek Fawcus wrote:

> So does it make any difference if you use the BIOS image I
> posted,  or does that also fail to help?

With CVS BIOS as of now, it seems to work both on the hardware and software
side. 80 cylinders reported, access works. Unless anything else turns up, I
think this can be considered closed.

--
/Mike

Re: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Derek Fawcus]

On Thu, Oct 07, 2004 at 03:37:05PM +0200, Mike Nordell wrote:
> 
> Now for the software problem, I'm sorry to say your patch didn't help. With
> your patch (as applied and compiled in the bios binary image in CVS), NT
> still believes the floppy only got 31 cylinders.

OK.  But Fabrice changed a few things.

The patch as I did it also altered the use of the table as presented in two
different APIs.  So does it make any difference if you use the BIOS image I
posted,  or does that also fail to help?

> Could it be that this information, using a real BIOS, is first copied down
> to the BIOS playground area (0040:xxxx), appends the extra knowledge (i.e.
> maxtrack = 79) and then it points the 1e interrupt vector to this new place?

Certainly.  But then we'd expect the change as Fabrice merged it to work.

DF

[Qemu-devel] Re: Qemu floppy emulation problems - partially solved

[Mike Nordell]

Derek Fawcus wrote:

> Well I was waiting to here back if the change I proposed had
> any positive effects,  since I'm not experiencing the problems
> it's supposed to address.
>
> However I've had no feedback,  so it's a bit difficult to tell
> if it's of help.

Sorry for the delay.

Let me first bring some good news: As of 15 hours ago, I fixed the final bug
of the hardware emulation part of the floppy that prevented it working
for/with NT5+ (Windows 2000 and later) guests. It's not in CVS as of this
writing, but I suspect it'll be shortly.

Now for the software problem, I'm sorry to say your patch didn't help. With
your patch (as applied and compiled in the bios binary image in CVS), NT
still believes the floppy only got 31 cylinders.

I have verified that direct modification of a BIOS image, appending the
max.cyl. and a zero to the originally placed diskette_param_table does make
NT work as expected re. floppy, in that it recognizes it as having 80
cylinders instead of the 31 cylinders it otherwise believes due to the
binary representation of the following "push ds". Obviously that overwrites
the leading two bytes of the int 17h handler, so while it makes NT floppy
handling work it breaks DOS - I couldn't even boot a DOS image with such a
modified BIOS image. Not good.

As the source code for NT isn't available, there is no way of really knowing
how, and where from NT grabs this data. I haven't (yet) checked with a real
BIOS to see if it too obeys the hard-coded offset efd2 for int 17h (which
here is the limiting factor for the diskette_param_table), but if it does NT
obviously must assemble this information from some other place since it
works on real h/w.

Could it be that this information, using a real BIOS, is first copied down
to the BIOS playground area (0040:xxxx), appends the extra knowledge (i.e.
maxtrack = 79) and then it points the 1e interrupt vector to this new place?

I think what's needed is an authorative answer from someone that really
knows either how a real BIOS behaves or how NT does this discovery in
detail, or close examination and/or empirical evidence from a real BIOS.

/Mike