>So if we will make some fat16-formattingprogram, we will have to format in
>MS-DOS 4 way.
It is the best idea I think. "MS-DOS 4 way" means extra information in the
boot sector:
#20-#23: Number of sectors if it don't fits in 16 bits (else, this number
is placed in #13 as in older versions)
#24: Number of physical unit for HD (#80 is first)
#25: Reserved (normally 0)
#26: #29
#27-#2A: Serial number
#2B-#35: Disk name or NO NAME
#36: FAT12 or FAT16 string
The problem is that MSX-DOS puts a booting program starting in #20, so
disks formatted in this way can't be used for boot.
>> +0: #80 = Active partition
>> #00 = Not active partition
>To be more exactly:
> #80 = boot from this partition at starup
> #00 = don't boot from this partition at startup
>(so only one of the four entries can have #80)
I did not know it. Thanxs!
>> +4: Partition type. Intiristing types for us are:
>> #0: Unused
>#00 =partition disabled
...it is not the same?
>> Head and cylinder can be ignored, in fact MegaSCSI puts it to 0 when doing
>> ESE-ASPI format.
>I don't think this is a good idea; this chs-data should be filled in so
>you can connect this hd to a pc. Like you said: it is used by pcbios.
But only by old versions I think. ZIP disks formatted with ESE-ASPI format
has these fields to 0, and my PC recognices and assigns a drive letter for
all the partitions (just executing ZIP permanent driver).
>It should be possible in future to use a single program for playing
>audiocd's on all types of interfaces, setting read-only, ... The way to go
>is to define some new rombiosentries (for example for sending
>commandpackets to SCSI or ATAPI devices, enabling/disabling readonlymode,
>...)
Then DPB format must be extended. If kernel is modified in order to assign
more work area in RAM for DPBs, then no problem.
Note also that current DPB assigns one byte for the number of entries in
the root directory. ZIP disks use 512! This is another reason for extend DPB.
>It is also useful for a new DOSkernel(or your patch): when it gets the DPB
>of a drive and the devicetype is a CDROM, it can read cdromsectors
>through diskio and interpret them as a cdromdirectory; no msxcdex is
>needed anymore.
This is not a bad idea.
>BTW what is the state of the DISKIO 32(24)bit entry??
If we are going to modify ROM kernel, let's implement 32 bits.
>What about the sectornumber itself?
>*complete number is fetched from memory, pointed by DE
Good idea.
>*lowword in DE, highword from a fixed location in page3 (>#f380)
Not good idea I think...
>Advantages of the DE-pointer: I can't find any.
>Advantages of the fixed address: faster
I don't like the idea of modifying MSX work area...
>Question: does someone know if the output of the function is specified?? I
>know of Carry and A-register for indicating errors. But I've read
>somewhere also B-register for indicating the 'amount of read sectors'???
>Is this true? (I don't think so)
This is true in #4010 ROM entry. In DOS functions... I don't know.
-----------------------------------------------------------------------------
Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user
http://www.geocities.com/SiliconValley/Bay/9797/msx.htm
[EMAIL PROTECTED] ICQ#: 18281450
"In Windows 98, 3.000 found failures of W95 have been corrected..."
Translation: 3.000.000 not found failures continue without being corrected...
----------------------------------------------------------------------------
-
****
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/)
****
