Hi!
On Thu, 12 Nov 1998, Alwin Henseler wrote:
> ...
>
> Ofcourse, the system needs to be able to translate this into lower
> level stuff like file systems, partioning schemes
don't know exactly what you mean by 'the system'; anyway, the partitioning
schemes should be handled by the devicedriver in the rom of an
interfacecartridge and are not visible to the DOS3-system.
partitioned harddisks, etc. should only be visible to DOS3 as several
'local' disks connected to the interface.
partitioning of devices should be performed by software delivered with the
interface or by 'universal' FDISK programs with internal driversoftware
for most common interfaces.
> ...
> For instance, if there is documentation on how to directly access
> SCSI devices using bigger sector numbers, it could do that by calling
> the specific SCSI BIOS routines defined for that interface, and
> sorting out the partitioning scheme for itself.
> If a harddisk-interface can't be determined for sure as a particular
> type, the more general disk-I/O routines in the interface would be
> used instead, leaving the separation in partitions up to the software
> in that harddisk interface.
I don't like the idea of having 'interface-particular-driversoftware' into
the DOS kernel (which will make it very large, different compilations for
different users, ...)
Better would be to define a number of 'device classes' and some some new fixed
entrypoints in diskroms that every scsi/ide/... should support.
For example an entry to query about the 'device class' of a 'local drive'
connected to the interface. And another 'general' entry to pass data,
dependent on the device class.
I think of the following classes:
SCSI: the general entry can be used to send specific command packets (play
audio, ...)
IDE: general entry can be used for sending special ATA-commands (unlock
device, ...)
ATAPI: the general entry can be used to send specific command packets
(play audio, read CD sector,...)
in future more classes can be added if new devices with a specific
protocol appear.
In this way all kinds of scsi-interfaces, ide-interfaces, ... are grouped
toghether, so that the DOS3 kernel has only to implement some 'subdrivers'
like you called it (for each device class one), for converting data
read/written through the general entry to a usable format.
In that way we don't need to put particular-interface-specific I/O in the
DOS3 kernel.
Of course this is only useful for devices that support functions that
can't be used by using for instance DISKIO.
Also note the fact that the entries may eventually not be used by DOS3.
For example DOS3 only deals with files. For example the ATAPI entry can be
used for reading files from CD, but can also be used by independent
CD-Audioplayers. The IDE entry will probably not be used very often by
DOS3 because all sectorreading/writing can be done by DISKIO. But these
are details.
>
> The separation between all these access methods would exist only on
> the level of the internal file system/sub-driver interface, and each
> of these 'drivers' would only exist as a piece of source code, used
> for assembling each version of the final system.
> If some new device would pop up, a piece of source code could be
> written implementing one of these file system/sub-driver interfaces,
> and then assembled together with the rest of the code for the current
> system. Et voila, a new version, supporting that new device.
ok. but only subdrivers for 'device classes'.
>
> Users would only know a number of different versions of system files,
> like a paticular version of (?) 'msxdos3.sys', and the only
> 'installation' required, would be the selection of a version,
> in which the hardware they have is supported.
> Any user configuration could be done through some settings file,
> where, in the absence of it, carefully selected defaults are used.
don't like this
> ...
>
> Frankly, by this time, I have become convinced we're not just
> brainstorming here, but having an entirely new disk system for the
> MSX is a VERY REAL possibility.
>
it is indeed.
but don't go too fast. It has to be done in a GOOD way; otherwise we'll
end up in microsoftland...
So it is really necessary to have a lot of brainstorming here 8-)
Greetz,
jon
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
