Hi all,
Maarten ter Huurne <[EMAIL PROTECTED]> typed on his keyboard:
> >I proposed earlier to use for both BIOS-routine 0144h and
> >diskROM-entry 4010h the following change, to allow the use of bigger
> >sector numbers:
>
> But you still haven't convinced me (and some others) why 4010 should
> be updated instead of creating a new routine at a new address.
The issue here comes down to:
Why have programmers learn the use of a new call, make every single
piece of software that PERHAPS might still have some use, useless 'by
definition', and go through the trouble of definining new entries,
when there's no real need for it?
My view on this is simple: define new methods/entries etc., when
there is a CLEAR ADVANTAGE to be had from this. If no such clear
advantage exists, use existing entries/methods if possible, this will
simply minimize the overall impact, and make acceptance easier.
For those of you who are worried about older programs messing up HD
partitions, I could think of 2 solutions:
a) Doesn't your harddisk-interface allow you to simply disable a
partition? If yes, do so, and you've got no problem here. If no, I
suggest you get that fixed first.
b) I have never liked it, that having a HD interface, in most cases
meant that floppy drive letters A & B moved to F & G or whatever, and
changed again when removing or adding partitions. Instead, I would
much more prefer the PC method here, to give floppy drives fixed
letters A & B (who's got floppy drive C or D anyway?), and start
harddisk partitions with C, D, etc.
Doing so would fix many of these old program's problems as well.
> It's not easy for the programmers of the HD BIOS. To fetch the
> sector number, the memory it is in must be selected. But by the time
> the HD BIOS looks up the sector number, a lot of slot switches have
> occured. Reading the correct values would take an inter-slot-read,
> which is slow.
If called by a user program, all user memory will be selected when
the driver ROM is called, except in page 1.
If the BIOS routine is called, the system can copy the value to a
save location in page 3 or elsewhere in case it was in page 1, or
leave it alone otherwise.
Calling driver entry 4010h directly from an application program
would be illegal (as it is now, strictly speaking), with the
parameters in any other than page 1, no problem anyway.
If called by the system, such a sector number would be somewhere else
than in page 1 anyway.
So in all cases, this will be directly available for the driver, no
inter-slot access required. An example:
If register DE contains this pointer:
PUSH DE
POP IX
then: (IX)=sector number bit 0-7,
(IX+1)=sector number bit 8-15, etc.
no direct limit on the sector number's size here either.
> >For the BIOS/diskROM entries, it would pose a problem to define new
> >entries; where to place such a new entry?
>
> #4034 and beyond, plenty of space left.
Available, but would require the data/software there to be moved
elsewhere, and every routine calling/using the data on this address
to be adjusted. That's the real problem with this, simply a lot of
work, that might be avoided.
> >If called with A=2 (get info on FAT16 support):
> >returns:
> > A=0: no FAT16 support
> > A<>0: FAT16 supported
> >Any extra info to be determined later, if necessary
>
> More useful would be a call that tells you which filesystem is used
> on a particular drive. Imagine a system with both a FAT12 and a
> FAT16 partition active. Knowing that FAT16 is supported is not
> enough, you have to know on which drives. To make this more general:
> you want to ask which filesystem is used on a certain drive.
That's another matter: what filesystem is used on a particular drive,
is depending on the medium/disk in that drive, not on the system that
handles it.
My proposal for this new function call only concerns the system's
ability to handle it, that is, the presence of new
functions/variables that allow access to it, possible new data
structures used etc. In other words, this new function would simply
indicate wheter the system is AWARE of these big sector numbers,
FAT16 etc., and if the functions/data structures to deal with it are
in place, not whether it's actually used or not.
> >Only thing left then, would be finding a way for the system, to
> >determine if a driver supports 32-bit sector number I/O, or not. I
> >suggest using one of the existing diskROM-entries (preferably one of
> >those besides 4010h), with some special input value, to determine
> >this.
>
> I suggest using a "magic number" identification. A short number or
> string that is specific for 32-bit sector number compatible device
> driver ROMs. Just like "OPLL" is used for FM-PAC.
A good idea.
You might use the fact that all existing drivers that I know off,
have most of the entries filled with a JP instruction. You could take
the destination address of this jump, subtract a few bytes, and look
for such a signature there. You could even use the DSKIO-entry itself
for this, no impact on performance, and very little extra bytes to be
added, very easy to implement.
I think a 2 or 3-byte signature would do, maybe followed (damn no!
preceeded!) by a 'feature flag byte', version number or such.
Checking it would work as follows then:
Get byte at address #4010
=C3h (jump?)
If not, no 32 bit sector number support by this driver
If yes, take address of the jump
Lower this address by 2 or 3
Signature at this address?
If no, no 32 bit sector number support by this driver
If yes, 32 bit sector numbers supported, extra info might be
found at this address -1, -2 etc.
Why use a new DOS function for indicating the presence of these new
features?
I think the main advantage of using a DOS call is 2-fold:
-Easy for programmers, call it just like any other DOS function
-Reliable; if you use Extended Bios-hook for it, you might get
incorrect results if some program modified this hook in a not-so-neat
manner, if you use a couple of flag bytes at fixed memory
locations, these might be corrupted by not-so-neat working
programs. DOS functions generally don't suffer from that.
It need not take up any page-3 memory space, and calls could work
fast (not that it matters for this purpose).
By the way, re-routing calls to DOS entries at both F37Dh and 0005h
is not really that difficult.
Entry F37Dh can be re-routed without any problem AFAIK, the same goes
for DOS-entry 0005h. There are some conditions to watch here, like
the fact that the address of this 0005h-jump also indicates the free
DOS memory. There might be some other system variables using this/
used to set this as well.
One way or the other, this can be done, I did it myself sometime. I
don't know exactly how anymore, but this really is not that
difficult.
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/)
****
