qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Mike Nordell" <tamlin@algonet.se>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: Qemu floppy emulation problems - partially solved
Date: Thu, 7 Oct 2004 15:37:05 +0200	[thread overview]
Message-ID: <000701c4ac72$c3d482f0$0401a8c0@putte2k> (raw)

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

             reply	other threads:[~2004-10-07 13:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07 13:37 Mike Nordell [this message]
2004-10-07 17:13 ` [Qemu-devel] Re: Qemu floppy emulation problems - partially solved Derek Fawcus
  -- strict thread matches above, loose matches on Subject: below --
2004-10-08  9:39 Mike Nordell
2004-08-18 15:35 Mike Nordell
2004-08-31 16:55 ` Derek Fawcus
2004-10-03 21:49   ` Fabrice Bellard
2004-10-04 22:00     ` Derek Fawcus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000701c4ac72$c3d482f0$0401a8c0@putte2k' \
    --to=tamlin@algonet.se \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).