>If so, a FAT16 driver should not in any way depend on a certain type
>of hardware/ROM, only change things that are the same with any disk
>interface. Or any DOS2-using interface, if you like.
Yes, the standard way for accessing physical sectors is through routine
#4010 of diskROM. But the standard input parameters specification for this
routine allows only the use of 16 bit sector numbers. So, for accessing 24
bits sector numbers a controller specific routine is needed. Besides I need
to set the "disk change" flag under certain circumstances, and (AFAIK)
there is not standard diskROM routine for this.
BTW, routine #4010 of MegaSCSI was modified for accessing 24 bit (actually
23) sector numbers, so actually I use this routine in my driver. But I
don't know if other interfaces have also this modification, so I separated
this part from the main code. The modification is as follows:
Standard #4010 routine definition:
Input: C = Media ID
MegaSCSI #4010 routine definition:
Input: C = Media ID if bit 7 = 1
C = Starting sector number (bits 22-16) if bit 7 = 0
All other input parameters are identical in both cases.
>A FAT16 driver changes the FILE system, and thus should work with any
>type of disk that supports that file system, in this case: any disk
>hardware that could support FAT16 formatted disks, not just
>MegaSCSI.
For this reason the controller dependant routines are separated from the
main code, so anyone knowing how other interfaces work (designers?
manufacturers?) can change it; sorry, I have only MegaSCSI and information
for MegaSCSI, so I can program only for MegaSCSI. BTW it is just three
routines: physical sector access, disk change flag setting, and checking if
a slot contains the controller.
>If it only works with MegaSCSI, then it's really a MegaSCSI
>modification, not some kind of 'driver'. If so, I think you'd better
>re-do it.
No. It is NOT a MegaSCSI modification, because I don't change anything of
MegaSCSI SRAM. My driver resides in a RAM segment. Besides when a FAT12
drive is accessed, my driver does nothing, and normal DOS code is executed:
no modification at all then.
>> - Jump to #0005 in TPA segment of page 3, via inter-segment call
By the way I commited mistake when typing this... it is "page 0" of course!
>a) Start & end your routines as much as possible the same way as is
>done in the original routines (do some disassembling & code copying,
>only squeezing your own version of the interesting parts in between),
MSXDOS.SYS uses a lot of memory addresses which depends on the TPA end
address, so I can't make a "fixed" code emulating this. My driver takes
control via hook #F252, when DOS code and data segement are already set,
and stack is already placed in page 3, so I must not use these variable
addresses.
>b) If possible, simply return/jump back to the original end of a
>routine?
What? Sorry I don't understand what you mean. Anyway I think you are maybe
speaking about "ignore" option, not "abort"...
BTW my driver will never show "ignore" option. Sometimes DOS shows it,
sometimes doesn't, and since I don't know how to decide if ignore should be
allowed or not, I'll never allow. If someone knows, please... I also don't
know how sector buffers works, as well as "fork a child process" (what the
hell is this???) X-)
Hasta incluso!
-----------------------------------------------------------------------------
Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user
http://www.geocities.com/SiliconValley/Bay/9797/msx.htm
[EMAIL PROTECTED] ICQ#: 18281450
Please don't send me messages with HTML code
"New Pentium 3400000000. Obsolete in 2 months. Guaranteed!"
----------------------------------------------------------------------------
-
****
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/)
****
