Hi,
Gee, I'm getting started here! (see my response right before
this one).
To be able to use more and/or bigger drives on MSX, there's
essentially 2 things needed:
-System software (like DOS2, disk/CD-ROM drivers and such) that will
allow access to these
-Applications, that allow USE of these (don't forget about this one!)
For any single application, it's not really too hard: if you want to
make a copy-program a la BK, MultiMente or such, then what's
preventing you from just making one, that supports CD-ROM, Gigabyte
HDD's with FAT16 or FAT32 partitions?
You could use standard DOS2 functions for what's supported by DOS2,
and use your own routines for using those CD-ROM & other goodies.
If you want to copy files back and forth between FAT12 and FAT16
partitions, you could use DOS2 routines for accessing the FAT12
partitions (up to 32 MB), and write your own software for accessing
those other drives. If they're not supported by DOS(1 or 2), it won't
access these drives, it won't access these partitions, and you're
free to do that yourself.
What would you need: an understanding of the disk formats used,
like FAT 16, CD-ROM format(s), etc. And some documentation on the
BIOS routines present in the hardware you'd want to support. This
might turn out difficult already, but I'm sure you can find out what
lowlevel sector/device access routines there are in several of those
IDE/SCSI interfaces, and how to use these. So what's holding you
back?
In essence, this comes down to writing, for some part, a disk
operating system. As I said, in essence, you can simply do this, I
wouldn't see any ESSENTIAL problems here.
But, that would surely be a lot of work. And if you do all that,
wouldn't it be easier to incorporate this into those SCSI/IDE
interfaces, to be used by other programs or utilities, like using any
other drive (like loading CD-ROM files from Basic, using something
like BLOAD "K:\DEMO\UTILS\MSX\DOS304\EXAMPLES\SEETHIS.BIN".
(would be nice if you could do it that way).
The problem here really comes down to this: you could just define
some extra system software. Like those lowlevel sector read/write
routines in SCSI/IDE routines; either they already support other
media on this low level already, or it wouldn't be too big a problem
to add support for these ON THIS LEVEL.
But: can you use these as well using any ordinary program (like that
BLOAD from Basic, or any other DOS program)? There's the main
problem.
On the other hand, there's no problem in extending some of that
existing system software either: define some new DOS calls (plenty
of function numbers left!), add some new bits to a bit pattern
returned by a function call, or increase a maximum drive number
somewhere. The main problem here is the same as above: is existing
software gonna use that, or will it remain invisible for those?
In essence, a problem of compatibility: make it compatible with
existing 'standards', and it will mean having to build in
restrictions, so that you won't quite get what you want (like max. 32
MB. partitions on far bigger drives).
Define some new (either semi-compatible or entirely new) stuff, and
many existing software won't 'see' it, won't be able to use it, and
only a very few new programs might support it. In this way, you
wouldn't quite get what you had hoped for either.
I watched some of the discussion earlier here, and I think the most
important thing missing here, is some overview here:
Someone suggested implementing some extra bits on a 'login vector'
returned by a DOS function call. Yes, this login vector IS defined as
16 bit (I know this for a fact), but: are programs gonna take it as
such? If you would make some extra drives this way, and return a more
than 8 drives present answer on a function call, I would say the
real interesting thing is not wheter it's possible, but far more
interesting is, wheter it's any use to do that.
Maybe there are just one or two programs that actually process those
extra bits, where others will just take 8, making an implementation
of these extra bits useless for those programs.
So what I suggest is this:
Instead of diving into all these details too much, why not do some
research, together (on this mailing-list for instance), to determine
all the options for implementing a next-generation disk operating
system for MSX?
For instance: current systems know a 32 MB. partition limit. Instead
of looking right away for how to extend this, why not look first at
how this limit comes about?
I know, it's a 16-bit sector number used in DOS system software,
combined with a 512 byte sector size. What I mean here: how are these
routines used by programs? IF you would modify these routines to
support more than a 16-bit sector number, how would it affect
existing programs? If you would support for instance 32-bit sector
numbers here, how to handle programs that don't support it? If you
would define a 'new' function call for this, what would the practical
use of this be?
When you take file operations: if I'm not mistaken, file offsets are
defined as a 32-bit value in existing DOS function calls. I'd say,
supporting access to normal files, but up to a 4 GB filesize (2^32)
would be a great step forward. If you would implement a 'file
operating system' that will fully support such files sizes using
existing function calls, how will this affect existing programs?
Would this work okay, or would there be all sorts of problems,
created for instance by programs using mixed sector-I/O and file-I/O?
Instead of looking for solutions for some of these details, why not
do some proper research on the general issues here?
What might be REALLY usefull here is this: an overview of the exact
use that several popular or 'essential' EXISTING software makes of
the existing DOS functions. If you know that a particular SET of
programs only uses a particular set of DOS functions (like memory
locations xxx, and function calls yyy/zz), then you also know that
you can continue to use these programs with 'DOS3', if it would
SOMEHOW implement THAT set of function calls & memory locations.
Instead of wasting time to figure out HOW you could do that, you
could first figure out, WHAT would be needed to implement a 'DOS3'.
What functions would HAVE to be implemented, with what things should
it remain compatible, in order to make it any use?
So, on the other hand, support/implementation of what things could be
dropped, without having every existing program stop to operate?
Why this whole story? Well, simple: why bother making a disassembly
of a DOS2 kernel? You know what happens, when you delete a file on
harddisk, don't you? Some special marker is put into the directory
entry that goes with it, that says: 'deleted file', and the FAT
entries (clusters) that were occupied by that file, are converted
from pointing to next parts of that file, back to 'free'.
You know how a FAT12 disk is organised, you know how to read/write
those sectors using low/level I/O routines. So why bother to figure
out, how exactly this is done by DOS2?
All you REALLY need to know, is how to put such a new DOS together in
such a way, that many existing programs can use it. What memory
locations are 'fixed', and which are free to shift to other places,
or not to use at all in this new disk operating system. So all you
REALLY need to know, is how existing programs use the current
systems. How do they determine what's present (DOS1/DOS2)? What
function calls are used? What memory locations are used? What
assumptions are made?
Instead of debugging your entire software collection, I suggest that
all of you, who would like to participate, find out for THEIR OWN
PRODUCTS, or maybe for one or two of their favourite programs, HOW
these things use the disk system: what system locations are used,
what calls are made, what assumptions were made? Check out some
source codes of some of your own stuff, and make a quick list of ANY
system locations used in relation to disk/file-I/O, and ANYthing that
would have to be in such a new disk system, to make your product
work. If you lost the source, get out your debugger! You still know
roughly how your program works, others don't!
Then, drop your results on this mailing-list, or some volunteer that
collects these results, and after a while, you would get a database,
showing how different programs use the disk system. With that, you
could see in one quick look, what the effect would be, when a certain
modification to the disk system would be made. If you would implement
some higher drive numbers somewhere, with this database you could see
in one look, what programs would support those extra drives, and what
programs wouldn't.
And THEN, it would be far easier, to work on any extensions or
modifications of a disk system. You would know up front, what would
be necessary to make programs xxx (choose any set of favourites)
work, and what would be free to change in a new system.
To conclude: my suggestion here, is to focus any efforts here on the
INTERFACE between existing software, and existing disk system
software. What are the essientials here?
Let's forget about the rest of how these programs work, and let's
forget about how all the details are implemented by disk systems (I
mean, those details that are 'internal'). In other words, let's
figure out, how this INTERFACE works, what is 'external'
('fixed'/'standard') and what is 'internal' (free to change as you
wish) ?
Can we do this?
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/)
****
