At 05:15 PM 11/26/98 +0000, you wrote:
>> 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,
By changing parameters of an existing call, like you suggested, programmers
have to learn the changes as well. This is unavoidable.
>make every single
>piece of software that PERHAPS might still have some use, useless 'by
>definition',
I can't think of any software, written for 16 bit sector numbers, that will
function well on a partition requiring 32 bit sector numbers.
>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.
Advantages:
- HD BIOS implementation doesn't have to check whether old (16-bit) or new
(32-bit) calling convention is used.
- Complete freedom in specifying parameters.
>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.
If you know you are going to run a program that can mess up your >32MB
partitions, this works (although clumsy). But the most harmful accidents
are the ones you don't expect.
>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 fixes problems with programs messing up HDs because they think it are
floppies. It doesn't fix problems with 16-bit sector number programs
messing up 32-bit sector number partitions.
But there was a different suggestion that will work well to protect
partitions: direct sector I/O must be enabled explicitly by the user. For
example, by specifying a certain environment variable.
>> 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 you are programming under DOS, your code and data is located in page 0,
1, 2 and maybe even 3. How can you be sure that your sector number isn't
stored in page 1? You can assign an address explicitly (using EQU), but
that is not a flexible way of programming.
>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.
But where is "a safe location in page 3"? If you can find one, you might as
well let the user store the sector number there.
>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.
Loading sectors to page 1 is perfectly possible in DOS1 and DOS2, as far as
I know.
>> >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.
Yes, it is true that patching DOS2 will be more difficult.
>> >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.
What I mean is, that the average program doesn't care whether FAT16 is
supported, it only matters whether it is or isn't used on a certain drive.
I think only FDISK and FORMAT need to know whether FAT16 is supported.
Your remark about "depending on the medium/disk in that drive" is a good
one, I forgot about removable media. For example ZIP disks, it would be
useful to partition them with a single partition.
Bye,
Maarten
****
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/)
****
