Nestor Soriano <[EMAIL PROTECTED]> wrote:
> Yep, tired of searching technical info, and since nobody does anything (eh
> Pazos! Esto no va por ti; yo ya me entiendo) I started my FAT16 driver.
> Unlike Pazos&Okei one, it is not a patch for diskROM, but a completely
> self-made driver which will be placed into a RAM segment.
>
> I'm making it for MegaSCSI, but the controller dependant routines (just
> three routines) are clearly separated from the rest of the code, so anybody
> can modify it for any other controller.
I am really sorry to have to write this, but:
Doesn't a FAT16 driver modify the disk system, and not the disk-I/O
itself? For clarity: with 'disk system' I mean here: the non-hardware
dependant software, that for instance resides in an ordinary
DOS2-cartridge. With 'disk-I/O' I mean: the low-level,
hardware-dependant part of diskROMs.
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.
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.
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.
> I almost finished the "basic engine" but I have problems with the error
> handling part, so I ask for help. Here is the problem:
>
> [HI-TECH MODE ON] X-)
>
> Imagine that a function call is being executed. Page 2 contins the DOS data
> segment. Page 0 should contain the DOS code segment...
...
(...more tech speak...)
...
> - Restore TPA segments in pages 1 and 2
> - Load C=#62 (program terminate) and B=Error code
> - Jump to #0005 in TPA segment of page 3, via inter-segment call
>
> It works and COMMAND.COM takes control, but next execution of a program
> causes the computer to hang.
>
> [HI-TECH MODE OFF]
>
> SOS... help... maidai... dios mio, esto es un infierno... X-) I just need
> to solve this problem for having a "releasable" version of the driver (I
> hope!!). Also, any suggestion & beta-testing offers will be welcome of course!
On error handling:
Why not -
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),
or
b) If possible, simply return/jump back to the original end of a
routine?
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/)
****
