Hi again,
NYYRIKKI <[EMAIL PROTECTED]> wrote:
> > If we use HDD, then we probabbly don't need to read/write directly
> > to sectors.
> Wrong. This is necessary for disk checking and defragmentation
> utilities . And with FAT16 we'll have to run defragmentation often!
>
> Yes, but we can't use any allready existing software for that, so
> supporting existing sector read/write (expetially write) is not
> nessessary. I allready have messed up my HDD two times, because
> these routines are supported. Real reason is ofcource proggrams,
> that are made badly, but if those routines wouldn't be supported my
> HDD would have been saved. So, Ok make new sector read/write, but
> keep it away from allready existing routines... please :-)
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.
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.
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.
Besides: why throw away the possibility of using a whole set of
existing programs, when you can find a way to avoid that?
Gerald Stap <[EMAIL PROTECTED]> wrote:
> One of the major problems may be fitting such a huge fat in
> MSX-memory. Let's face it, even if you build a system which has the
> FAT partially in memory, the swapping of the segments to disk will
> make the process very slow. There go those 10ms accesstimes;)
Never was/won't be a problem, because this is not needed/not done.
You only need in memory a working set, the things that you are
processing at the time. Data that's not used, need not stay in
memory, and need not be read in advance.
If memory is available, you could allow data (FAT/directory sectors,
AND/or data sectors) to stay in memory, if memory is tight, you only
keep a minimum working set.
I'm sure it's done that way by most, if not all major operating
systems.
Jon De Schrijder <[EMAIL PROTECTED]> wrote:
> perhaps it we can pass the 32bit sectornumber in the
> shadowregisters. I think this will be the fastest way.
If I'm not mistaken, the alternative registers are destroyed on
interslot-calls (slotswitch-routines do this to be able to work
faster), which might be a problem.
I would prefer an 'external' way of passing those extra bits anyway.
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)
In other words: less limitations
Patriek Lesparre <[EMAIL PROTECTED]> wrote:
> I'm following this DOS3/>32MB/FAT16 discussion very closely, but I
> have to say 32 bit sectornumbers are a little too big. I agree with
> Egor that 24 bit is better. A little calculation:
> 2^32 x 512 bytes/sector = 2199023256000 bytes = 2 TB
> 2^24 x 512 bytes/sector =8589934592 bytes = 8 GB
NONSENSE!
A 24 bit sector number is the very least needed now, and if you have
24 bits to pass, why not make it 32 bit then. Very little extra
trouble for programmers, very easy to define now, but FAAARRR more
difficult to add later on (like all these 16/32 bit limits we have
now).
I agree it's probably not so realistic to go out and process 8 Gig's
or more of data on an MSX, but that's beside the point here: the
point is, if you have a 20 Gig drive/partition, will a new MSX disk
system allow ACCESS to some files on it? I hope so!
Another example: you have CD-ROMs now, and DVD-ROMs are also already
being sold. What size has a DVD got? Some 10 GB.? If you would access
this through 512 byte sectors, 24 bit sector numbers already wouldn't
do, let alone with some newer types of disks.
8 GBytes disks are sold TODAY, so it will be too small TOMORROW. If
you take less than 32 bit sector numbers now, this will be useless by
the time it's implemented.
Personally, I'd rather allow even bigger sector numbers (like 48
bit), just to make future expansions easier, but I guess I won't be
able to talk any of you into that...
But: I figured out another way of indicating bigger sector numbers.
When you're trying to keep things compatible, you have to use the
same parameters, but in such a way, that one or more of these
indicate 'new', using some values that will/were never used in the
old system.
Let's see: sector number 0-FFFFh: all possible
media descriptor: I've never seen anything below F0h, but I'm not SO
sure about this.
Number of sectors: 0-FFh: could be used, but might give problems if
values bigger than ... are passed to older drivers.
My idea: why not indicate a big sector number with the highest bit of
the drive number (passed with A register)?
If passed to an older driver/part of the system, this would be read
as drive number beyond 127 ('ridiculous'), and any action will surely
be refused in this case, with an error code to go with it.
It would only limit the maximum drive number to be passed this way to
0-127 (who cares), and:
-It's 100% compatible, no FFFFh sector number exception
-The 16 bits used previously for the sector number, can be used as
normal, to pass the lower 16 bits of the sector number, instead of
wasting this with a dummy FFFFh value
-You can use some special values (FFh, FEh, FDh etc.) for the drive
number to indicate sub-functions, and use this for instance to
'inquire' about supported features, locations of extra info etc. (you
might use this through other entries rather than DISKIO).
What do you think?
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/)
****
