Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!olivea!apple!agate!ucbvax!POLAR.BOWDOIN.EDU!tsarna
From: tsarna@POLAR.BOWDOIN.EDU (Tyler Sarna)
Newsgroups: comp.os.minix
Subject: AmigaMINIX developments?
Message-ID: <9101060416.AA04545@polar.bowdoin.edu>
Date: 6 Jan 91 04:16:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 79

[again, I can't seem to get myself subscribed to the info-minix
mailing list. I've tried twice. Please e-mail me, or better yet,
get me subscribed!]

> From: uunet!easy!lron@uunet.UU.NET (Dwight Hubbard) (Dwight Hubbard)

> Well, if you do find the patch could you mail it to me as I don't have
> FTP access. :-(

Ok, it's on it's way to you.

> My boot disk has had no real problems.  My biggest problem is I can't
> figure out how to up the size of the Ram disk (I'm having nightmares of
> trying to compile the Minix kernal with 2 floppy drives and a 160K ram
> disk)

Yes. to change the size of the ram disk, you're supposed to use
"/etc/setup_root", but this file doesn't exist! Could some ST user
please mail me theirs?

I'm probably opening up a huge can of worms, but....

I've decided to try to write a AmigaMINIX hard disk driver. This driver
will be for the GVP Series II controller, but can serve as a model for
other Amiga drivers. I'm playing around with some of the basic code
under AmigaDOS now, using the SCSIdirect interface to make "read" and
"write" functions. Since SCSIdirect is an AmigaDOS ".device" level
standard, it have to be rewritten with actual low-level code. I'll call
GVP on monday and try to get this info from them. If they, for some
reason, fail to give me any info, would a Amiga/68k assembler guru be
willing to help me decypher dissasembled listings of GVP's device
driver?

Anyone out there with AmigaMINIX and a Series II that could beta-test
for me?

Also, when (if?) I get this driver up and running, I will next work on
680x0 compatibility. Does anyone have any ideas as to where the
problem(s) lie? The methods for making 680x0-incompatible code are, as
far as I know:

a) using "unused" 68000 instructions that are used on the 0x0. This
sounds like it might be one of the problems (does AmigaMINIX perhaps use
one of these codes or FPU traps to implement systems calls?)

b) timed instruction loops. Seems unlikely, but it might be used in
keyboard or floppy routines. Anyone have MINIX running on a faster
68000? If so, that proves that this is not the problem.

c) hosing the 0x0 VBR (vector base register) or other 0x0-only
registers, or not saving extra 680x0 registers (if they need to be
saved?)

d) using the high 8 bits of pointers as "free" data storage. The 68000
doesn't use these 8 bits, but the 0x0 do. Does MINIX use these bits?

e) self-modifying code. writing over code in causes discrepencies
between the instruction cache and what's in memory. The CPU may try to
execute wierd combinations of new and old code. This doesn't sound like
a problem in AmigaMINIX.

Any of the 68000 MINIX authors want to 'fess up to what they did wrong
in their ports? ;-)

Finally, some of the responses to my previous post indicated that since
I could use the minix.img.bu and was told so that everything is OK.
Everyting is *NOT* OK. It's like being sold a new car. All of the cars
come from the factory with punctured left-front tires. Instead of fixing
the tires, they affix a sticker to the windshield which says, "Your
front left tire is punctured. When you receive your vehicle, please
replace the tire with the spare in the trunk". Would YOU trust a car
manufacturer like that? I wouldn't...

At any rate, thanks for your replies. Take care,

------///------------------------------------------------------------
     /// Tyler "Ty" Sarna            E-Mail: tsarna@polar.bowdoin.edu 
 \\\///  "...and save up to 100% on brands you've never heard of!!!!"
--\XX/---------------------------------------------------------------