About all this 32Mb limit...
The current reason for the limit is because we only have 16 bits to specify
the sector number. As each sector is 512 bytes at the moment, the maximum
partition size we can access is 65526 * 512 = 32 Mbyte
I don't think you want to start thinking of a 16 bit FAT or something like it.
You could want to change the sector size, but I don't think this will work.
Sector buffers of 512 bytes wouldn't be enough anymore, so the internal MSX
disk basic structures would have to change.
Better would be to change the sector number from a 16 bit integer to a 32 bit
integer. It would probably take the following :
- Add an extra entry to the disk interface. For most SCSI interfaces and IDE
interface there already is one.
- Change some routines to calculate sector numbers. Since 16 bit sector number
are the only option in the MSX standard, these routines probably won't
return
a 32 bit value. So you would have to add extra math routines that are
somewhat bigger.
It might be better to rewrite all FAT-12 routines to FAT-16 routines.
But then you have to write routines that check what FAT routines have to
be used.
In my oppinion it would be even better to define a new kind of driver
system...
Change MSX-DOS so that the BDOS entry's don't use the MSX standard, but patch
it to use a common driver and remove all the sector based routines.
This driver could have the following entries :
Init
Open
Close
Read
Write
SearchFirst
SearchNext
Flush
GetFreeBytes
GetInfo
some more???
Then you could write drivers for different devices :
CD-ROM SCSI/IDE - ISO 9660
DISK MSX/SCSI - FAT12/FAT16
Harddisk SCSI/IDE - FAT12/FAT16/????
TAPE SCSI - ????
network ???? - ????
The user and application programmer shoeldn't have to know with what system
he is working. Long filenames could be used if implemented in the driver.
A real disadvantage is that the driver programmers would have to write all
the low level file routines. (not the low lever sector routines, they have
to use the routines in the SCSI/IDE/??? interface).
(I have experimented more than a year ago with FAT-16 in TP 3.3, but never
finished it.)
This looks very simple, but really, it isn't.
You have to define a standard to make it really work.
It could work like this :
An application executes the BDOS function _FOPEN with a pointer to
"D:AFILE.DAT".
_FOPEN will get the drive letter from the filename and searches for the
according driver. Let's say it finds it at slot 2-2 in page 5 at address
#4100.
Then it will call this entry with the OPEN function.
This will be the open function of the specific device that is assigned to
drive letter "D:"
I don't know if this is clear enough. Otherwise I will think of something
when I have some time.
BDOS
_OPEN
_CLOSE
_READ
_WRITE
_etc...
|
\|/
Driver info table
A: B: C: D:
structure 1 1 0 2 0=FAT-12,1=FAT-16,2=ISO9660,etc.
device 1 1 0 2 0=Disk,1=Harddisk,2=CDROM,3=tape,etc.
io 1 2 0 1 0=MSX-disk, 1=SCSI, 2=IDE,etc.
drv_sub 1 2 1 1 Driver sub number, for more devices/driver
drv_slot 2-1 2-1 2-1 2-1 Driver slot
drv_page #f3 f3 f3 e4 Driver mapper page
drv_basead #4100 #4100 #4200 #40f0 Driver base address
It's just an idea...
Might be that the creators of MSXCDEX know how to patch the BDOS functions, as
they probably have done that. It would be even greater if they already have
made this kind of software for non-CD-ROM devices.
Then you decide wheather or not to use the above idea of independant
drivers for each disc structure.
Greetings from Erik Maas
--------------------------------------------------
H.P.A.M. Maas
Woudseweg 5a
5275 JH Den Dungen
Tel. 073-5942926
Email : [EMAIL PROTECTED]
--------------------------------------------------
****
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/)
****
