Nestor Soriano <[EMAIL PROTECTED]> wrote:
>> SET the disk change flag? Why do you need to do that?
>
> The behavior of my driver when a function call is made is the
> following:
>
> - Check if the disk has been changed via CALL #4013.
> - If not, read an internal table which contains the type of the
> drive. If FAT16, process function call. Else (FAT12) do not
> process and let DOS to do it. - If yes, read boot sector in
> order to determine the type of drive. If FAT16, build new DPB
> and process function call. Else, let DOS to do it. Update the
> drive type table in both cases.
>
> Well, suppose that disk was changed and it is FAT12 type. My
> driver must do nothing and let DOS to execute funtion call. But
> what will do DOS at first? To check if the disk was changed. But
> my driver did it already!! So DOS will obtain a "disk not
> changed" status, even if the disk was changed, and will not
> update the drive's work area. This is very dangerous...
>
> How to solve it: if the disk was changed and it is FAT12, set
> again the disk change flag, so next call to #4013 (check disk
> change), performed by DOS, will return "disk was changed"
> status. I know how to do it but only on MegaSCSI.
You could figure out how to set this disk change flag for other
interfaces, but it's disk hardware-specific, so better leave it
alone...
Possible solutions for the above:
-Avoid making a "disk changed?" call. If you do need it: maybe you
can use the result of a "disk changed?" call made by DOS earlier?
-Maybe you can use another interception point for your routine, at a
point where DOS already determined this disk change status?
-DOS does this call again, after your code? Maybe you can use a
different exit point from your code, skipping this next DOS call, and
pass on the result of the "disk changed?" call you made?
-Or: intercept somehow this next "disk changed?" call made by DOS
(difficult, tricky)
> >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.
MegaSCSI modification = adding something, that only works with
megaSCSI, not other interfaces.
What it does with the megaSCSI itself, or where that added code
stays: I don't care!
> >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"...
Dos HAS code for handling "Abort", right? You can do the same, but
instead, you could also jump back to that DOS code handling "abort"
(and don't care what happens from there). That was the idea.
> I also don't know how sector buffers works, as well as "fork a child process"
> (what the hell is this???) X-)
See MSX-DOS 2 function call documentation, functions 60 & 61h.
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/)
****
