Hi all,
To refreshen your memory:
I proposed earlier to use for both BIOS-routine 0144h and
diskROM-entry 4010h the following change, to allow the use of bigger
sector numbers:
if bit 7 of drive number=0, then all parameters as usual,
if bit 7 of drive number=1, then
DE-register = pointer to 32-bit sector number
(instead of containing 16-bit sector number itself)
I would like to add one condition for the implementing routine here:
the memory location passed this way should not be modified, only used
as an input parameter.
All other parameters unchanged.
This would insure 100% compatibility, have a negligable impact on
performance, and easy to use for programmers.
I think it was Jon De Schrijder <[EMAIL PROTECTED]> who
proposed to simply put the lower part of the sector number in
DE-register (as usual) and store the high part directly in some
memory location.
Simple and fast, but with 1 big problem, as with the other methods
proposed: where to store the rest of that sector number?
A memory location to use for that would have to be:
-Fixed; if this location would be a variable itself, you might as
well use my method
-Free to use for this purpose, which means it should not be corrupted
by any other system software that might be executed during the call
(interrupts can be on as well, so software hanging on an
interrupt-hook might call BIOS-routines during the disk-I/O call)
-It should not corrupt any system variables itself
Take your pick!
I see another discussion coming, about the single issue of what
memory location might be used for this purpose. Once a certain
address would have been picked, and a few HDD-interfaces updated
using this, it would be very difficult to move this to another
location after that.
To stop that discussion right here, I would like to point out that
the method I proposed, solves that immediately: an application
programmer can pick what he/she likes, and no problems with changing
an address that was picked earlier. No risk of interfering with
system variables either.
Therefore I feel the way I came up with is still the best, and right
now it's the only full solution for passing bigger sector numbers.
Jon also wrote:
> Does everyone agree on the fact of using 24bit sectornumbers instead
> of 32? I do
I sure as hell DON't !
You'll probably have to update files like MSXDOS2.SYS & COMMAND2.COM,
some utils like CHKDSK, sector-editor etc. will have to be modified
or re-written, updates for the software in HDD-interfaces will have
to be made, and if you take 24 bit sectornumbers now, it will be
useless by the time this is done.
Taking at least 32 bit sector numbers is a tiny issue now, as opposed
to 24 bit sector numbers, but if you take too small numbers now,
it'll give an enormous amount of (unnecessary) headaches later.
Nestor Soriano wrote:
> It is this simple:
> FAT16 -> max. 2 GB. per partition -> 24 bit sector numbers are enough
Well, suppose you have that 24 bit sector number support, and you
have FAT16 support. Then you want stuff like FAT32 support (plenty of
filesystems left!). The system would not support that yet, so what
could you do? Simple! Write your own application using that, and do
the I/O using low-level sector routines.
WRONG! no sector-I/O support for this either.....
I think if you're making system-extensions now, you should in
principle include what exists now, and take into account what you can
see coming.
Well, I see 10 GB. and bigger drives NOW, and far bigger ones coming
(soon). -> 24 bit sector number usefull NOW (not in a year), 32 bit
sector number support usefull SOON (MAYBE in a year from now, maybe
even sooner).
2 things left to be sorted out here:
-DOS function calls for this purpose
-how to determine if the system supports this big sector number
feature?
DOS functions
---------------------
For the BIOS/diskROM entries, it would pose a problem to define new
entries; where to place such a new entry? How to pass the extra info?
For that reason alone, it was a good idea to use the existing
entries, with a small modification to parameters. To be able to call
these using interslot-calls, no use of index registers or Z80
shadow-registers was possible.
But for DOS function calls, this is far EASIER!
I think that indicating a big sector number with bit 7 of the drive
number set, is so much compatible, that there is no real need to
define new DOS function calls for this. Not doing that, will make
sure that it's easy for programmers (same function numbers, same
parameters, just set a bit).
But: you can use Z80 index-registers on DOS calls!
(used for several DOS2 functions, I'm not sure about Z80
shadow-registers though). So, I propose to extend DOS function calls
2Fh & 30h (absolute disk read/write) as follows:
If bit 7 of drive number (in L register) = 0: all parameters as usual
If bit 7 of drive number = 1:
DE = low 16 bit of sector number (was: sector number)
IX = high 16 bit of sector number (was: unused)
Other parameters as usual, output as usual
How to determine the presence of features
------------------------------------------------------------
As a programmer, you're mostly not interested in system version
numbers; you don't really care if it's an MSX-1 or MSX2+, you care
what videochip is in there, and if you can use a mapper or not.
You don't really care if it's DOS1 or DOS2, you care about being able
to use file handles, mapper support routines, or not.
For that reason, I propose that any new disk system should report
itself as version 2.x, as before, and indicate the presence of new
features (FAT16 support, big sector number support, etc.) through a
specialised function call. I think function #71 hex would be free for
this purpose, and I suggest calling this: 'get feature info'.
This would be a general function; for each feature to determine, the
programmer would call it with a 'feature-ID' in the A register, if
necessary with other input in other registers, and the return
parameters would indicate the presence/support of that particular
feature, with the exact return info depending on the particular
feature.
For each feature NOT supported, the return values for both new AND
EXISTING systems IS defined as: A=B=0 (probably zero-flag set as
well). So it already works that way in DOS1 or DOS2, as it exists
now.
I would propose these 2 sub-functions here:
If called with A=1 (get info on 32-bit sector number support):
returns:
A=B=0 -> no 32 bit sector number support
A<>0 -> 32 bit sector number support for BIOS-routine 0144h /
FFA7h hook
B<>0 -> 32 bit sector number support for DOS functions 2F/30h
In other words, A and B would serve as flags, where A would indicate
32-bit sector number support for the BIOS-routine, B would indicate
this for the DOS functions.
I think it's usefull to indicate this separately, this would allow to
implement it seperately. If you implement both, you can set both
flags. If a programmer needs both, he/she can simple OR these flags
together.
If called with A=2 (get info on FAT16 support):
returns:
A=0: no FAT16 support
A<>0: FAT16 supported
Any extra info to be determined later, if necessary
If called with any other value for A then 1 or 2, this function would
return A=B=0 (let's leave A=0 for input alone, shall we? It's sort of
a magic number...)
Only thing left then, would be finding a way for the system, to
determine if a driver supports 32-bit sector number I/O, or not. I
suggest using one of the existing diskROM-entries (preferably one of
those besides 4010h), with some special input value, to determine
this.
If you would use some special ROM memory location, which location to
use then? If you would use a new entry, how to fit this in existing
ROM's? Using a special sub-function for 4010h entry could have an
undesirable impact on performance. I'm sure we can find some special
calling sequence to put into one of the other entries, that will do
fine.
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/)
****
