Hi,
Time to talk about some of the general stuff, after this sector
number discussion. How to build this new disk system roughly?
Let me summarise some desires:
-It should be able to use new devices easily, or it should be
modified easily to support these
-It should be able to have its behaviour adjusted in some ways by the
user
-It should support all current devices, and most current existing
programs
That makes a general setup quite clear:
It should implement most of the available DOS calls and 'standard'
system variables in a compatible way, in other words: implement most
of these, where needed to keep things working.
It should be set up in some modular way, so that for any change
(FAT16 -> FAT32, or some other file system), addition of new devices
(PCMCIA cards, DVD players, etc. etc.) you wouldn't have to rewrite
the entire system, but only certain parts.
Most access to files/devices through DOS has to do with files. Direct
I/O is only needed for a few applications which do lower level stuff
like defragmentation, sector editing, disk checking etc. Many of
these will have to be updated/rewritten to support new file systems
anyway, so the only thing needed here, is to allow these programs to
do their normal work for devices supported in the older system. So
that, for example, a CHDSK writtten for DOS2 can also work with the
new system, when it is run on a FAT12 device.
For most programs, a higher level interface works fine, that only
deals with drives and files in manner, where programs don't need to
know how exactly it works physically. Here, you only need to know how
to access these in a general way, and how to determine some
characteristics of these, like random access or serial accessible, a
read-only medium or writeable, fixed or removable, this sort of
thing.
In my view, most of the implementation of the DOS function calls
should be implemented on this level, so that any single function can
be used for all devices, which can be 'described' in these terms.
You could do this by defining an internal 'file system interface',
which allows access to whatever device, described in these terms
(random access/serial, random access/write/read only, removable y/n
etc.). A new device would then be easily added by writing a 'driver'
that would implement this INTERNAL file system interface, without the
need for rewriting any of the higher level software.
ANY program implementing only this higher level interface would then
automaticly directly work with this new device. And why not?
Ofcourse, the system needs to be able to translate this into lower
level stuff like file systems, partioning schemes etc. So, to keep
this in a modular way, you might implement for instance a FAT12/FAT16
'driver', for controlling the most common hardware like floppy and
harddisks, which would (in essence) do nothing more than implement
this internal 'file system interface' on the one side, and use
sector-I/O routines on the other side.
This part of the system (which might turn out to be a big part) would
NOT need to know ANYTHING about how the disk-I/O is done. So, this
part should not mess with the low-level control of particular
devices, it should only use general sector-I/O, and possibly some
additional information also used for the file system, like whether a
medium is removable or not.
For instance such a FAT 'driver' part would only have any meaning for
random access devices, which use sector-I/O. Devices which wouldn't
allow access this way (like a network drive, routed through a serial
or other connection, or a CD-ROM, which, if I'm right, simply doesn't
have a FAT), would either be implemented on this higher 'file system
interface' level, or accessed through another 'sub-driver'.
These 'sub-drivers' would then either perform any I/O themselves (in
whatever way they 'like'), or, for devices where it could be
described in terms of sector-I/O, through a lowest-level interface,
which would implement only that part.
This would have the same advantage:
If ANY new device could be used in a similar way by such a
'sub-driver' (like a FAT file system), all that would be needed, is
an implementation of this lowest level sector-I/O interface, and if
that would be done, everything possible with other sector-I/O devices
would immediately work with this new device as well.
I hear you all thinking: drivers, interfaces, would this mean a
joining in with the mess you have on MS-DOS/Wintel (Windows/Intel)
systems, with config.sys, memory drivers, separate driver files to be
installed for every single device you can think of?
Ofcourse not. One of the things I like about the MSX system, is its
high level of 'plug and play'. My proposal therefore:
Such a new file system would simply support all current devices for
which the 'control method' is known, directly. For those devices
supporting sector-I/O, it would either call whatever routines are
available and/or defined for particular SCSI/hardisk/floppy-disk
interfaces where possible, or,
if the details for a certain type of interface are unknown, it would
simply support this anyhow, by 'falling back' to a more
general/standard access method, like sector-I/O routines defined in
the old system.
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.
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.
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.
What would be needed for all this?
2 things:
-A definiton of some of these internal interfaces, like a definition
of such a file system 'driver'
-The sorting out of a lot of technical details, like file systems,
partitioning schemes, system variables/DOS calls to support and what
exact calling methods to use etc.
In this way, the design of a new system, would for the largest part
simply come down to sorting out these details. If all is known about
what it should do, and how it should do it, actually programming it
will finally be peanuts in comparison.
Most programmers among you will have to agree, that a lot of
programming time is actually spent on figuring out how exactly the
program should work. If you know EXACTLY how a program should work
(for instance, if you have an example source code written for another
system), the actual programming becomes more something like a
conversion.
Designing a new system this way, has another BIG advantage: ANYONE
can join in with this figuring out/thinking process, and in that way,
actually do some of the programming, without having to be a
programmer.
Then, if you would figure out something together, and run into a
problem later on that would require re-doing some of the earlier
work, that earlier work will not have included any actual coding, and
the work to be re-done would simply be an agreement on an alternative
method, defined in 'pseudo-code'.
All this could speed up the creation of this new system enormously.
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.
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
****
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/)
****
