Re: Documentation on minixfs and ext2fs

[ekl%beastie@sdf.lonestar.org]

>From uucp Sun Jan 14 16:46 CST 1996
>From terminator.rs.itd.umich.edu!mint-request Sun Jan 14 07:58:57 1996 remote from SDF.LONESTAR.ORG
Received: by SDF.LONESTAR.ORG (Smail3.1.29.1 #1)
	id m0tbS1J-0000TwC; Sun, 14 Jan 96 07:58 CST
Received: from terminator.rs.itd.umich.edu by metronet.com with SMTP id AA14249
  (5.67a/IDA1.5hp for <ekl@sdf.lonestar.org>); Sun, 14 Jan 1996 07:41:11 -0600
Received: by terminator.rs.itd.umich.edu (8.7.3/2.3)
	id IAA08206; Sun, 14 Jan 1996 08:37:59 -0500 (EST)
Received: from mctavish.demon.co.uk by terminator.rs.itd.umich.edu (8.7.3/2.3)
	with SMTP id IAA08203; Sun, 14 Jan 1996 08:37:47 -0500 (EST)
Received: by mctavish.demon.co.uk (Smail3.1.29.1 #8)
	id m0tb9UU-0002lFC; Sat, 13 Jan 96 17:11 GMT
Message-Id: <m0tb9UU-0002lFC@mctavish.demon.co.uk>
From: steve@mctavish.demon.co.uk (Steve Woodford)
Subject: Re: Documentation on minixfs and ext2fs
To: ekl%beastie@sdf.lonestar.org
Date: Sat, 13 Jan 1996 17:11:40 +0000 (GMT)
Cc: mint@atari.archive.umich.edu
In-Reply-To: <m0taa6P-0000RwC@SDF.LONESTAR.ORG> from "ekl%beastie@sdf.lonestar.org" at Jan 11, 96 10:24:00 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Status: R


Evan wrote:

> Well, I realize that.  Its a MUCH better method to write a real
> driver, however, I don't know the details of the ACSI port well
> enough to attempt it (or the details of controlling a LinkII or
> something from the ACSI port).  I think everyone was just kinda
> sitting back and waiting for someone to write the driver.  I think,

Unfortunately, I don't use my Atari any more otherwise I might volunteer
to write it. (No point since I use the MVME147/MiNT now).

However, I did write an ACSI based scsi library a while back which should
be on a.a.u.e in the Programming directory (non-mint). If I recall, it's
called libscsi1.[tgz/zoo] or something like that. It contains low-level
ACSI code in it, plus a higher level SCSI command interface. Now, if
someone wants to volunteer... ;-)

The only fly in the ointment is that it's not interrupt driven, though it
could be easilly converted. The problem is that the floppy drive uses the
same DMA interrupt... :-(  Your solution (below) would not need to be
DMA interrupt driven.

> that a more drastic change internally is more in order.  Instead
> of letting the BIOS block, we should take the BIOS back after the
> next tick, pre-empt it, semaphore lock it, and then get on with
> other tasks.  This would mean pre-empting the BIOS, and would
> mean pre-empting a supervisor process.  

Hmmm, two semaphores would be needed, one on RWABS and one on MinixFs.
I recall that the ROM BIOS RWABS (trap #13) isn't used on MiNT since the
kernel has it's own version which vectors through the hdv_xxx routines.

The actual drivers (eg. ICD) use the 200Hz tick to implement a timeout
on the busy-wait for DMA completion, and also the busy-wait between
SCSI command bytes. The command byte timeout is very short so we would
have to be *extremely* careful not to pre-empt RWABS too soon otherwise
the driver would continually timeout. The main completion timeout is
fairly long (a few seconds at least), so isn't quite so susceptible to
being pre-empted. Someone's going to have to be pretty brave to mess
with RWABS on a live system!! B-)

> Well, who wants to write to write the new Rwabs() wrapper?

Not me, that's for sure!!

Cheers, Steve