Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!agodwin
From: agodwin@acorn.co.uk (Adrian Godwin)
Newsgroups: comp.os.minix
Subject: Re: Does Minix eat floppy disk drives?
Keywords: bootblok, floppy
Message-ID: <4595@acorn.co.uk>
Date: 7 Jan 91 17:47:07 GMT
References: <1806@sun13.scri.fsu.edu> <1991Jan4.230711.25240@dsuvax.uucp>
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 69

In article <1991Jan4.230711.25240@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes:
>In <1806@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes:
>
>>I wrote in an earlier message (paraphrased):
>>>  ...for the third time, I have lost a 1.2MB floppy disk drive
>>>  on my Minix system.  On the other hand, I have never lost one
>>>  on my MS-DOS system.
>>>
>>>  so...I think...MINIX EATS FLOPPY DISK DRIVES.
>
>>                                      Even though logic tells me
>>that Minix can't possibly eat disk drives, hearing those grinding
>>noises while it is figuring out what sort of drive it is always
>>gives me the creeps.
>
>I don't know if I would say that MINIX doesn't eat disk drives.
>....
>
>BTW, I'm going to clean up my bootblok.s that shouldn't be so hard on
>disk drives and post it tonight.  It will include support for 1.44M
>boot disks and fix a bad thing regarding 720K boot disks.
>

Thanks for these hints, folks ...  I was impressed how easily my 1.5.10
system came up on a 1.44M AT, and surprised when the 360K disc I built
wouldn't work on an AT. 

However, a quick look at the bootblok (and the 'config' scheme someone
posted) raises some queries :

When the 720K disc is tested, it uses disc parameters from a fixed place 
in the PS/2 ROM. This is probably a bad idea on another machine! - it's
also probably the reason why the disc fails to boot on my friend`s AT -
it may well get parameters that result in a successful read of track zero,
but fails thereafter. The 720K parameters ought to be in the boot sector
with the others - why aren't they ? Lack of space ?
Perhaps this is the 'bad thing' Guy refers to.

The worries about seeking to track 64 to find out how many tracks the drive
has are reasonable - but I don't see how that will hurt a 1.2M drive, which
has 80 tracks anyway. It might damage a 360K drive, of course - but that 
wasn't the problem. That's assuming that the drive isn't being double-stepped,
which of course it shouldn't be in 720K mode ... unless the junk parameters
at that hard-coded address say so!

But why worry about 720K parameters anyway ? Most kernels are much smaller than
360k, so they'll stop long before 40 tracks. So why not just set up for 360K
and read that ? I don't believe it will notice the difference! The step rate 
will be slow for the 3.5 inch drive, but I*M always get that wrong, anyway !
In any case, it will only matter for the recal - not sequential track reading.

While I'm on the subject of bootbloks, any readers still using floppy root
discs might be interested in my method of avoiding the disc swap at boot-up.
I added a 'start' parameter to the data at the end of the bootblok to indicate 
where the kernel is to be loaded from. Since the root filesystem is also 
typically small, the boot track can be placed on the root disc, and the
kernel code placed above the filesystem by a suitably-modified 'build'. 

I also replaced fsck (on a 1.3 system) with a fastboot loader that read the root 
filesystem into memory with cylinder-sized reads, but that isn't essential. 
If you do it, you have to modify FS to find the prebooted ramdisk and the memory 
sizing function to operate nondestructively. I haven't put these mods into my 1.5.10
system yet.


-adrian
-- 
--------------------------------------------------------------------------
Adrian Godwin                                        (agodwin@acorn.co.uk)