About the FAT16 discussion, I mainly agree the word of Alwin Henseler, that
is: let's forget to disassemble DOS 2 kernel and let's make new system
software for controlling it.
But, I think that making a whole new operating system is exagerated. It
will take too many time and efforts, I think. The best solution is to make
an external driver, loaded in a separate RAM segment, as I explained in a
message some days ago. This driver should act when a funtion call referred
to a FAT16 disk acces is made, and leave DOS to act normally otherwise.
Again, see MSXCDEX for MegaSCSI.
Problem is, for avoid conflicts with DOS 2 operations, we need some
internal information that we (or at least me) don't have. For example:
let's suppose that our driver must open a file placed in a FAT16 disk. Ok,
then a file handle number must be assigned to it. But, what number we
choose? How can we know that this number is not already in use by DOS? We
need to know which file handle number are already in use. DOS must store a
list somewhere. Well, where? And with which format? If someone has this
information, he is keeping it very "top secret"!!
The same applies for sector buffers, FIB and FCB exact formats and many
other things. Having a map of page 3 and data segment variables, and a
description of all data structures used by DOS should be enough then for
making a FAT16 driver.
If someone knows if ESE staff is capable of even killing for something
specifical, please say. These guys adapted DOS kernel to MegaSCSI, and made
a perfect CD driver!! So, for sure they have the information we need. But
they don't reply e-mail.
>Technicaly, adding FAT16 to both DOS1 or DOS2 kernels is not hard.
>You have to modify 3 routines:
>
>- FAT element getting
>- FAT element putting - add 16 bit FAT processing to them
>- Cluster Chain processing - must understand both FFx and FFFx special
>values for respectively FAT12 and FAT 16.
And FAT<->sector number translation. But this is easy.
>Oh yes, and you must of course add FAT16 file system detection routine
Easy: 4085 or fewer amount of clusters implies FAT12. 4086 or higher
implies FAT16.
>Greater than 32 Mb partitions are a different story.
>Modification of kernel for them is not very dificult - you have to
>modify
>only multiplication routine in cluster-to-sector translation module.
>But we don't have any worked-out standards of how to pass this sector
>number to disk I/O routine!
Well, you look it easy, but you know where are placed the FAT calculation
routines in DOS2 kernel? Physical disk access can be easily solved with a
drivers system as I said in other message.
>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 :-)
It is a good idea. In fact, Microsoft engineers (?) had the same idea ten
years ago. Yes: MS-DOS 4 (first MS-DOS version with >32Mb partitions
support) uses the same funtion call of previous versions for accessing
sectors. But when sector higher than 65534 must be accessed, sector -1 is
specified in the sector field, and other registers are used for specify the
32 bit first sector number and amount of sectors.
>Yes, I think that for 32Mb partitions, the cluster size is equal to the
>sector size. So, these calculations routines should be completely
>rewritten.
NO!!! 1 cluster = 1 sector only on very small partitions (RAM disk for
example). In 32 Mb partition, cluster size is 16 sectors.
-----------------------------------------------------------------------------
Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user
http://www.geocities.com/SiliconValley/Bay/9797/msx.htm
[EMAIL PROTECTED] ICQ#: 18281450
"In Windows 98, 3.000 found failures of W95 have been corrected..."
Translation: 3.000.000 not found failures continue without being corrected...
----------------------------------------------------------------------------
-
****
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/)
****
