public inbox for linux-8086@vger.kernel.org
 help / color / mirror / Atom feed
From: "Riley Williams" <Riley@Williams.Name>
To: Richard Wallman <r_wallman@yahoo.co.uk>
Cc: Linux 8086 <linux-8086@vger.kernel.org>
Subject: RE: Amstrad ppc640
Date: Thu, 26 Jun 2003 07:47:25 +0100	[thread overview]
Message-ID: <BKEGKPICNAKILKJKMHCAKEFNEHAA.Riley@Williams.Name> (raw)
In-Reply-To: <E19VN6a-0001hA-00@murkygoth.co.uk>

Hi Richard.

 > Just been playing around with ELKS on my TI TravelMate 2000,
 > and I got the same problems with init and sh.
 >
 > When I compile the kernel to get drive info from INT13, it
 > seems to get the number of sectors on a floppy wrong - it
 > seems to think there's 19 sectors. Hence, loading init fails
 > miserably.

That indicates that your computer doesn't support INT 13 for
determining the parameters of a floppy disk. Such is common for
XT class computers as the INT 13 facility wasn't introduced
until the PC/AT came in. Since there is no means for the ELKS
kernel to determine whether INT 13 support is included, this is
something that |MUST be correctly configured when compiling the
ELKS kernel.

 > Re-compile turning "Use INT13" off, it correctly identifies
 > 18 sectors.

With INT 13 support disabled, the ELKS kernel simply tries to
read sectors on track 0 starting with the highest numbered one,
and counting down until it reads one successfully. It assumes
that the sector number read is the number of sectors that disc
is formatted with for all tracks, so will get copy-protected
floppies wrong and all other floppies correct.

 > I don't know if that's an issue with my laptop, or with the
 > code - it might be interesting if people conduct the same
 > experiment (kernels with and without using INT13) and post
 > the results.

As stated above, it's an issue with the fact that your laptop
is a PC/XT clone, and thus does not include facilities that
were not implemented on the genuine PC/XT. It's thus something
that is pretty much expected on that class of machine.

Incidentally, because of the above, the safe option is to
disable use of INT 13 and let it probe each floppy in turn.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.491 / Virus Database: 290 - Release Date: 18-Jun-2003


  parent reply	other threads:[~2003-06-26  6:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-26  3:07 Amstrad ppc640 Richard Wallman
2003-06-26  3:52 ` Dan Olson
2003-06-26  6:47 ` Riley Williams [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-06-18 19:19 Joost Vermeulen
2003-06-18 19:43 ` Riley Williams
2003-06-18 20:26   ` Joost Vermeulen
     [not found]     ` <BKEGKPICNAKILKJKMHCACEBJEGAA.Riley@Williams.Name>
2003-06-19 21:08       ` Joost Vermeulen
2002-04-26 14:05 Joost Vermeulen
2002-04-26 19:42 ` Riley Williams

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=BKEGKPICNAKILKJKMHCAKEFNEHAA.Riley@Williams.Name \
    --to=riley@williams.name \
    --cc=linux-8086@vger.kernel.org \
    --cc=r_wallman@yahoo.co.uk \
    /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