Newsgroups: comp.os.minix
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!news.mathworks.com!europa.chnt.gtegsc.com!news.sprintlink.net!noc.netcom.net!netcom.com!raduga
From: raduga@netcom.com
Subject: Re: bios vs ps HD drivers
Message-ID: <radugaDBAC4M.C6u@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <radugaDB6HyH.761@netcom.com> <DB8Iny.9DJ.0.-s@cs.vu.nl>
Date: Thu, 6 Jul 1995 08:12:22 GMT
Lines: 85
Sender: raduga@netcom12.netcom.com

Kees J. Bot (kjb@cs.vu.nl) wrote:
: raduga@netcom.com writes:

: >okay!


: I probably wrecked the I/O code.

If you disable it altogether, its hard to tell 
if its really wrecked or not. :)  

: I disabled writing just in case I wrecked the I/O code.  :-)

does "disabled" code count as "wrecked" code for this excercise?

: I rearranged both the PS and ESDI drivers without being able to test
: them.  Luckily someone lend me a PS/2 to play with, so I could fix 1.7
: and the ESDI driver up.  I learned alot about the interrupt controller.

The ESDI driver does not recognise my drive.  I'm assuming this is
expected behavior. Do you know which PS/2 systems use the ESDI
and which use the PS type drives?

: The PS driver is still untested, because I couldn't find someone with
: that kind of drive.  Until now.  :-)

WOW. does this mean that i'm the only minix user of a ps-type PS/2 system
left in existence?  
(note, i've been fending off requests and polite suggestions from 
 family members and concerned friends, that i junk this machine 
 solely based on its age.  I dont find that argument compelling. :)

SERIOUSLY though, is there any way I can help you test the driver
more thoroughly? (you could maybe share bits of test code, 
or tell me how to get diagnostics that would give you the info
you need to fix it :) 

: The BIOS driver has the advantage that it is more reliable, because it
: uses the code of the manufacturer.  On old interleaved drives it is just
: as fast as a Minix driver.  I have been thinking about sending the XT
: driver to /dev/null for these reasons.  Any reason why I should not?

I assume when you say that its a REAL mode as oposed to a PROTECTED
mode driver, that it will only function in the former.
Can it be adapted to use in PROTECTED mode, or is it just too 
much kludge and work, to even bother?

lastly, when trying to make my system bootable from the HD,
i find installboot -d nearly always dies with "not enough 
space on /dev/foo for 'boot'" even when its a brand-new
partition with an empty new-made fs on it.
after trying *several* times wiht utter frustration,
i think im gonna give the auto-installation package a shot.
Is there a way to do an auto-install with the TINYROOT
and USR disks? looks like im gonna hae to use the real mode
kernel, at least until i can get a working PS driver :(

when booting from TINYROOT and mounting /dev/hd2 
with a full /usr and /src install, (manually)
i run out of memory midway through the compile.
it suggested I chmem some of the compiler utils
(no luck) with the added frustration that 
after an aborted make I had to remake from the beginning.
Yes, i gave it -F on the cflags, no help.

is there any place I can send formal bug reports?
(or what looks like a real bug, to my untrained eyes)
as opposed to vauge questions 
(is this, uh, like, uh, right, or am i uh doing something wrong?)

re: PS driver, and etc.

Or do all the Minix developers read c.os.minix anyway
and repeat posting would be a waste of breath :)


thanks for your support and time


   --------------------------------------------------------------------
  | Marc B. Silver	| "I shall begin my report as if I were telling|
  | (408)469-4939	|  a story, for I was taught as a child on my  |
  | mcs@gnu.ai.mit.edu	|  homeworld, that truth is a matter of the    |
  | raduga@netcom.com   |  imagination." U.K. LeGuin	  	       |	
   --------------------------------------------------------------------
