I didn't read the whole lot but I have some comments...
: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!)
Why would the applications have to use specific calls??? Can't you implement
FAT16 in the old function calls??? It shouldn't make a difference when using
functions like open, block read/write etcetera. And if the direct sector
read/write-functions are used on a FAT16-drive, dos can simply return an
error-code. Which will very likely be detected by the program. Or otherwise
you can let Dos abort the program.
: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.
First, give me 5 applications which use this function (bet you can't find
five of them).
Second, look if they use both H and L.
If yes, all is fine on drives A-P and they'll have to use a new
function-call when they want the vectors of drives Q-Z.
Third, look if they presume byte H=0
If yes, they will give trouble when ran on drive I-P, for then H won't be
zero. ***
If not, they can only use drives A-H. If they want to use more drives thay
should use the new function-call or modify the use of the old one.
Well, only in the case of the three *** this will give trouble. So of those
few programs who use this only the programs which presume H=0 will give
trouble. Result: chance of trouble less than 1%.
Conclusion: Just implement FAT16 as good as possible in the old functions,
let the 'dangerous' functions return an error (sector write), and define
some new functions supporting the new possibilities which couldn't be
(fully) implemented in the old function. In example a new Get Login Vector
using DEHL.
And I think debugging Dos2 will be a lot easier than writing a complete new
OS. As you said, it will most likely give trouble (although if you use the
fixed memory locations defined in the Dos2 documentation it shouldn't give
any) and it is a lot, I repeat A LOT of work to write a complete new OS.
~Grauw
****
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/)
****
