At 07:59 AM 11/12/98 +0000, you wrote:
>There might be another reason for that: some badly written programs
>assume drive A or B -> floppy drive, 360 or 720 K. With HD interface,
>A: might be 1st HD partition -> program treats HD partition as if it
>were a floppy disk.
What kind of programs are these? Will these programs ever be able to work
well on a harddisk?
>Anyway, compatibility is usefull: a CHKDSK program might not know
>about FAT16, but it can still be used for FAT12 partitions, AS LONG
>as the disk-I/O routines are supported in a compatible way.
But what if you accidentally run that CHKDSK on a FAT16 partition?
>A sector-editor might not be able to handle >64K sectors, but it
>might still be the best tool available for viewing/editing the lower
>64K sectors, AS LONG as the disk-I/O routines are supported in a
>compatible way.
What good is a sector editor that can only access the lower 32MB of a (for
example) 500MB partition? We simply need a new sector editor for DOS3. I
think the team that will write DOS3 will make a sector editor anyway,
because it is very useful for debugging.
>Besides: why throw away the possibility of using a whole set of
>existing programs, when you can find a way to avoid that?
I think that what Nyyrikki was saying, is that it's better to have 0%
compatibility than 50% compatibility: you don't want programs written for
floppies writing sectors to HD. If you allow that, old or badly written
programs may mess up your HD partitions.
You can never get 100% compatiblity on sector level, because you are
abandoning the FAT12 system.
My suggestion for implementing #4010 is making a routine that always
returns "disk offline". Result: old sector-based programs won't crash, but
they won't mess up your HD either.
>If you say now: register IX (for example), that's just a 16 bit
>number. If you choose to pass this some other way, you can:
>-use a 'default' for the extra bits
>-allow programs or parts of the system to work within a 16-bit sector
>number 'window' (so that every call works with sectors xxxxyyyy,
>where xxxx is set once, and yyyy passed with every subsequent call)
Just like the V9938 where the upper address bits are in register 14?
>Number of sectors: 0-FFh: could be used, but might give problems if
>values bigger than ... are passed to older drivers.
256 sectors is 128K of data. Since the Z80 address space is only 64K, this
limit is not a problem.
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/)
****
