Re: Just my 2 penny worth..

[Julian Reschke-FJR010 <Julian_Reschke-FJR010@email.mot.com>]

Stephen.Usher@earth.ox.ac.uk%INTERNET wrote:
> 
> >> 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.

I must admit that I don't understand. ST RAM can't be virtual by
definition. And if somebody does an Rwabs to TT RAM, it's up to the
virtual
memory handler to remap the call, and this is what Outside does.

> >> 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.

What kind of control would you need?

> >> 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.

Yes, we all know that the NCR can do more. But both TT-DMA and
Falcon-DMA
can't.

 
> >> 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).

I don't have anything against writing a new harddisk driver which can
do all these wonderful things -- I just don't happen to see anyone who
is prepared to do all the dirty work.

But even then there is little reason to break the existing and well
defined interface, unless you can supply one.

> >c) What about HDDRIVER, HuSHI and CBHD?
> 
> I have no access to these, so I can't comment.

CBHD is freeware, HDDRIVER has a free demo version.

> >> 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. :-)

Well. Yeah. Great. That's a bug in the harddisk driver you are using.
Use a better one. But there's no reason to change the harddisk driver
interface just because you happen to use one which doesn't work
properly.

> 
> >> 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.

I completely agree to get rid of TOS wherever possible, but some defined
interfaces like the BIOS interface to mass storage are working
completely
fine, so why throw them away?

What do you do with people who have proprietary hardware which *needs*
these drivers? CD ROMs on cartridge ports? ZIP drives on cartridge
ports? SCSI hardware connected to a PC card in the Milan?

Do you want to rewrite all this code? Good luck.

Regards, jr