Hi,
The problem of writing a new disk system might be not such a huge
problem as it might seem, and this is why:
With the transition from DOS1 -> DOS2 there's been plenty of time to
find out what programs used less known DOS1 features (documented or
not). When you would make a list of some system variables, and go
over this, most of you will agree that with a bit of cooperation,
it's either possible to tell what it's for, what it does, and whether
it's needed for compatibility somehow, or (if no-one knows anything
about it) it's so unknown, that you can count programs that use it on
the fingers of one hand.
Then, if you compare different disk implementations (different DOS1
diskROMs/interfaces) and you compare DOS1 and DOS2 use of system
variables, it easily becomes clear what things can move or be done
differently, and what things might better stay in place.
Under DOS2 some things defined for DOS1 stayed in place, and a lot of
things were done differently. Many, if not all applications have
learned to 'live' with that (I have to think real hard to come up
with one program, that I just can't get to work under DOS2). I'd say,
that makes it clear, that everything which was done differently under
DOS2, apparantly doesn't need to be done in a particular way to keep
programs working. For instance directory/FAT sector buffers: some
DOS1 versions keep less in the BASIC memory than other versions, DOS2
puts most of this in the mapper -> apparantly it's okay to move MOST
of this wherever you like, and you could surely think up a new way
for this in a new system, without too much trouble.
With DOS1, many of the internals where not defined or
documented properly (like error-handling), with DOS2 this is
different. There are a few documents which make it 100% clear for
instance how the mapper support routines work, or how some parts of
memory are arranged.
Outside of this, many things are done so complicated, or there's no
documentation of it anywere, that the number of programs that use it,
is automaticly very limited.
One example: apparantly there is a way to reserve some memory space
in one of the 2 memory mapper blocks DOS2 uses for itself.
Apparantly, there are one or 2 programs whose programmers knew how to
do this (some DOS2 caching program for instance, I believe).
How many of you know how to do this? I don't, for starters.
Don't bother to point it out here, my point is this: if nobody knows
how it works, you can change it in a new system.
If no programmer knows it, it won't be used anywere, and no programs
will fall over it if it's changed in a new system.
Having done quite some debugging and hard thinking myself in the
past, I think most of what should stay, is pretty well defined by
DOS2 reference documentation, together with some system variables
which didn't change from DOS1. Would it be so hard, to fill in some
of the blanks together? I don't think so.
Why not simply DEFINE a new disk system together, and start writing
some of the parts already, in 'pseudo-code'?
Let me take one. I think it was Egor who wrote:
>I have an idea about this and I'm testing it now. It seems to work
>well and is pretty compatible with the "old way". It works as
>follows: - when sector number is less than 0xFFFF, we just work the
>old way. If sector number is 0xFFFF, we forget it and use 32-bit
>sector number, which is stored somewhere in the BIOS work area. The
>only thing to be determined and standartized is the location address
>:-)
I like this. It's not such a compatibility-killer as defining a new
routine for it. And why not let older programs mess a bit with the
first 32 MB. of a bigger partition. Isn't it the responsability of
the user to decide what programs to run on his system, and which to
stay away from, or what to do with these programs?
A tiny detail here: what happens when a program actually wants to
access this one sector FFFFh (16 bit!) ? (no problem if a block of
sectors winds up here, the definition of '16 bit' was clear in that
case).
A program says: read sector FFFFh (just 1) -> disk-I/O routine reads:
32-bit sector number -> higher bits of sector number not filled in
-> wrong sector number taken
Possible solution:
-Make this a special case (sectornumber FFFFh & 1 sector). If more
sectors, it would wrap around in 16 bits, and I doubt if that would
be allowed in any case, so no problem, if a program does that, it
must mean a bigger sector number (eehh, how big anyhow?). If
sectornumber = FFFFh & only 1 sector, treat it 'the old way'. Would
that work?
Or:
Set a 'default' for the higher bits in the (input) sector number, and
set this to 0 AFTER each call to disk-I/O routine (and once, upon
initialisation). If a program doesn't change these, any calls to
disk-I/O will then automaticly be in the first 32 Meg, if it wants to
access anything beyond that, it has to set this BEFORE every call to
disk-I/O.
This has a big advantage: you could define quite large sector
numbers. If programs use only smaller disks, they only have to keep
track of the number of bits they actually use, the higher bits are
automaticly set to 0 by the system between disk-I/O calls.
For sectornumbers: I don't like adding small pieces, if you change
something because it became too small, make it a whole lot bigger
right away, don't mess with a few bits extra.
Frankly, I find the maximum number of drives not really a problem, I
have no more than 5 drives in my PC as well:
A: floppy drive
B: virtual second floppy drive (what's it do anyway, I never use it)
C: 1 Gig. HDD
D: another HDD
E: CD-ROM
I wouldn't like messing with 20 drives on a MSX, to allow direct
access to bigger sizes. So the problem is not this number of drives,
but the maximum size per drive.
FAT16 support would be nice, but it's really useless without access
to bigger drives, so shall we figure that out first?
I have one question here: can anyone make it clear what exactly those
special values for cluster numbers (FFx for FAT12, and ??? for FAT16)
are, and what they mean?
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx (MSX Tech Doc page)
** Solve all your smaller problems first, then your bigger problems
will turn out to be not so big after all ***
****
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/)
****
