Re: Just my 2 penny worth..

[Stephen Usher <Stephen.Usher@earth.ox.ac.uk>]

>> The main reason I suggested it was that if you're going to have a full
>> virtual memory environment these programs won't be able to work.. and also
>
>So why do they work with Outside?

Simple.. Outside only emulates TTram. From what I understand, all the
current crop of hard disk driver programs all use STram exclusively. This
would not work if you wanted to fully protect every program and the system
from application crashes.

>> it's so difficult trying to get the XFS's to work with all of them. Add to
>
>Yeah. But that's a problem in *some* of the existing drivers, not in the
>concept. Even AHDI-3.00-compliance should be good enough to get
>everything
>working, as it gives you the ability to access any sector on the disk.
>XHDI "just" adds a lot of comfort.

The problem is that these programs are basically a TSR the system has no
control over.

>> that, the current crop just can't drive the hardware at full speed. (The
>> TT's SCSI hardware is not slow, contrary to popular opinion. It's basically
>> the same as used in the Sun 3 computers but with added DMA, which can make
>> it quicker. It's the drivers which don't take full advantage of it.)
>
>Sorry. The DMA in the TT limits transfers to around 1.9 MB/sec, and all
>the drivers I know reach this limit when the disk is fast enough.
>
>Please prove that you are right, then I'll believe you.

I can't prove or disprove it other than saying that Sun 3/80's can do it
faster with the same SCSI controller and very similar hardware to the TT030.

>> Also.. have you every tried getting some drivers to boot if you have
>> non-standard filesystems on some of your partitions? I have.. AHDI 5.x locks
>> the system after bombing, sometimes hard hanging it. Some versions of the
>> ICD utilities work, others don't.
>
>a) Use the most recent AHDI.
>b) Don't blame others for bugs in the ICD driver.

I'm not.. I'm just saying that a lot of problems would be solved if the hard
disk driver was brought in-house and hence becomes a known quantity. One in
which the kernel has full control and can go straight for the hardware,
hence speeding access up (in theory).

>c) What about HDDRIVER, HuSHI and CBHD?

I have no access to these, so I can't comment.

>> If MiNT is going to support a wide range of filesystems it's going to have
>> to take these pieces of software out of the loop and get disk access under
>> its control. It also allows the kernel to schedule processes properly so
>> that those waiting for I/O don't sit in the run queue, allowing others to
>> get on with other things.
>
>You are repeating this, but it just is not true. You just need drivers
>that are implemented properly. To add background DMA, you need to define
>the kernel interface (just like what MagiC does) and that's it.

It's more of a problem with the drivers and/or TOS getting confused with the
filesystems before MiNT starts.. this can cause either TOS or the driver to
crash. Just try using a Linux ext2fs partition with a driver which doesn't
allow you to turn partitions off from TOS's point of view.. from what I can
remember, TOS 3.05 gives 4 or 5 bombs. :-)

>> Also, if you want to be able to give as many of the advantages as possible
>> to the 68000 crowd playing with emulators under Linux (which have to do a
>> total emulation in software, and hence run like treacle) is not an option.
>
>No, you don't need to emulate the CPU.

Someone's obviously found a way to catch illegal instructions and to emulate
code in Supervisor mode then.

>> I'm trying to be inclusive here.. allowing the ST users to get as much out
>> of it as possible and also giving the TT & Falcon owners the full use of
>> their machine's abilities, and hopefully not slowing things down for either
>> group, maybe even speeding things up.
>
>Sorry, I think you're really overdoing it :-)

Maybe.. but TOS + MiNT is an even more unholy kludge than Windows 3.1 over
MSDOS.. it works (just, mostly) but it is klunky and could be a whole lot
better if it were redesigned from the ground up throwing away the 15 year
old baggage but keeping backward compatibility with old programs.

Steve

-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (01865) 282110 (UK) or +44 1865 282110 (International).