Re: Just my 2 penny worth..

[Michael Schwingen <rincewind@tubul.dascon.de>]

On Tue, Jun 23, 1998 at 01:09:57PM +0100, Stephen Usher wrote:
> 
> 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.

The TTDMA can do DMA to TT RAM when using the SCSI port. Do you really have
evidence that there are drivers which do not use that capabilities?

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

What control do you need?

There is a clearly defined interface between the disk driver and the rest of
the system.

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

The TTDMA limits the throughput, not the 5380 SCSI chip - so what? You won't
reduce this overhead by putting the driver code in the kernel itself - you
will only introduce new bugs and throw away years of expecience from the
people writing these drivers.  

And you need to supply drivers for all kinds of hardware that is supported
by current drivers - that includes ACSI, TT SCSI, IDE (on Falcon and ST),
IDE with busmastering (on Milan), PCI-SCSI (on Hades and Milan) - plus maybe
ATW and others which I forgot. And you have to supply a SCSIDRV-interface
(including ATAPI-emulation), so that we can use existing applications like
GEMAR, CDRecorder etc.

All this looks like quite a bit of effort for - well, for what?

> which the kernel has full control and can go straight for the hardware,
> hence speeding access up (in theory).

That is a theory which you should support somehow. I don't see how you can
speed it up against the current scheme, which is quite simple and
straight-forward.

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

CBHD is freeware - look for CBHD502.TOS.

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

That is a problem with the driver you used, not with the concept itself.

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

Which should not be a big problem - even if you need kernel support for it:
DOSEMU in i386 clearly demonstrates that this can be done and that it works
quite well - it can even execute the video BIOS ROM and boot up a native DOS
in a virtual machine, including graphics applications.

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

What parts do you want to throw away then?

GEMDOS is almost (totally?) gone with the new (V)FAT code, and the VDI and
AES on top of MiNT can be replaced. All that remains is the hardware
dependant (X)BIOS and other hardware-dependant lowlevel driver stuff. Part
of that (HSMODEM) could be integrated in MiNT, but rewriting bg parts just
to have a new interface is not worth the effort IMHO.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen