... Hehe, confusing, those calculations?

Hokay. We have 32MB.
That's 32768kB.

...erm...

WHOOOW!! My bad It's 65536 sectors yes... Sorry for the inconvenience

Clusters stand aside from it, that's merely how FAT12 has been designed. Anyway, when you have a partition of EXACTLY 32MB (that is, 65536 sectors ), so 32768kB. So, an easy calculation (1st grade math class ) proves us that a sector has a size of 1/2kByte, that is 512 bytes. For some reason, the standard cluster size of a 32MB partition is 16kB. When you decrease the sector size of that partition from #10000 to #FF7A (that's #86, so, 134 sectors, not 32, another miscalculation by me :S), the clustersize becomes 8kB. Dunno exactly why, but that's how it seems.

By the way, the sector size of a partition being #10000 means the range is #0000 - #FFFF. The range of a #FF7A sectors sized partition is #0000 - #FF79. In normal kBytes, that's 65402/2=32701kByte, so that's about 99,7% of 32MB. So actually you exchange 0,3% of 32MB for a HUGE lot of extra space for smaller programs. At least the overall level of slack space will be decreased

Interesting stuff, idd. And I believe indeed fdisk 'knows' this feature and uses #ff7a sectors when creating a 32mb fat12 drive, right? So the clustersize is 8kb.

Ow OFCOURSE!!! (Damn, I'm finally getting somewhere )

So WHY is it called FAT12? Because it can define an absolute position on disk in 12 bits, so ranging from 0 to 4095. The definition of a cluster is as follows: it's the smallest size of a disk which can be used to put files on. So, we have 32768kBs on our partition, which are 65536 sectors.

So there are 65536 sectors on a 32MB partition, divided by 4096 clusters. That makes our math easy again: 65536/4096=16, so the cluster size of a 32768kB partition is 16/2=8kB. So now I'm still wondering why certain FDISKs make the cluster size of an exactly 32MB filled up partition 16kB... Because we could do the same trick with only 8kB...

[edit]YAY! By means of this post, I've got another title [/edit]

Erhm, indeed. 65536 sectors and 4096 positions. That makes 16 sectors per cluster. That's 8kbyte per cluster, because one sector is 512 bytes, so 16 sectors is indeed 8 kbyte. I agree with D-Tail Why do certain FDISKs make the clustersize 16kb? Do they, actually?

Well... That was at least the argument, I believe. I recall it was stated in some manual, why a 32MB partition should be a little smaller than a real 32MB partition, thus decreasing the cluster size. Right now I will examine the FDISK310.TXT file

Well... The manual just states the following:

[(c) Jon de Schrijder]

|size in sectors|FATtype|MediaID|rootDIRentries|sectors/cluster|
|---------------+-------+-------+--------------+---------------+
|  32733-65404  | FAT12 |  F0   |     256      |      16       |
| 65405-262610  | FAT16 |  F0   |     512      |       4       |

I've got a slight idea why FAT12 isn't defined beyond 65404 sectors. Well... Assuming we deal only with FAT12.
I think it has something to do with the sectors used by the BOOT, FAT, ROOT, etcetera. These things could consume 132 sectors altogether, thus the actual partition space combined with the 'administrative things (ROOT, FAT, etc)' would be 65536 sectors exactly. So when you're about to make an exactly 32MB sized partition, it will mean you use 32MB for data. Just a few kBs will be added because of the administrative part of the partition.

imho: Fat12 has a fixed set of clusters. This will cause the behaviour what I was talking about. Somehow Fat16 can alter the number of cluster, where it is fixed in Fat12.

Hi guys, please don't get angry, but I have another question:

Would it be hard to rework SunRise fdisk.com, Okei's fat16.com and hacked 2.41 command2.com to support FAT32?

If the work was dote for FAT16, I don't think it's impossible, but then again, at this moment of time I'm far from being subject matter expect in this domain.

Why would you want to use FAT32? With FAT16, you can already use up to 2GB on one partition. I myself have 400MB in use of my 4.3GB HDD. So I think FAT32 would be a little too far out of the way, really. Maybe it'd be better to improve the FAT16 driver program, so it would actually support more than only those BDOS calls.

I'm not getting angry , I just don't think FAT32 is really necessary on MSX.

By the way: ever tried to copy an EVA movie from a CD to your HDD? It seems that the copying would never finish, even with a 8MB movie...

I'm using a MSX Turbo R FS-A1ST with a Sunrise ATA-IDE/RS232c combo AND a loose Sunrise ATA-IDE. With HDSPEED it seems I've got a transfer rate of about 300kB/second, even using Alex Wulms' R800-Drive! This little tool will ensure the R800 will be turned on during disk access concerning specified drives. I heard a Novaxis SCSI could already do 450kB/s on a MSX2! Now I'm wondering, why is that IDE that slow?! :S

Quote:

. I heard a Novaxis SCSI could already do 450kB/s on a MSX2! Now I'm wondering, why is that IDE that slow?! :S

This is not true. I made a hack of the novaxis rom and get about 348KB/s on a 7.16Mhz msx2+. But indeed the ide is slow on the turbo r. I'veen seen speed upto 600KB/s on a turbo r with novaxis scsi.

One thing is for sure, the Turbo R runs code from a cartigde much slower then code run in internall ram. The hack I made for the novaxis rom actually slows it down on turbo r. I changed a inir to a lot of ini's. If the ide interface code uses something like this it then it sure explains why it is so slow.

Couldn't Jon modify its BIOS then, so it would transfer faster? I mean, 300kB on my Turbo R is half of the 600 of the Novaxis!

I don't think I have seen more than 450kB/s on my Novaxis on TurboR. That's an 1.59.64 BIOS, untouched by msd....

There is a thread on improving the IDE BIOS right here. Unfortunately, it doesn't look like Jon feels like improving the IDE BIOS (or Compass 2.0) these days... :/

Perhaps it's a good idea to disassemble the IDE BIOS (or to get it open-source first hand from Jon) to see what can be improved? I've got 512kB FLASH RAM in it, room enough for improvement/extra features. I'd love to see some decent MegaSCSI-like FDD emulation

Let's assume MSD is right and let's focus first on 348 kB , what should be at least possible .
I would appreciate it if I try again to contact Jon in cooperation with us since we deliver the bios ,snout.
you know as much as I that we discussed all in the topic.
And also the best discussed item if you ask me !
Even we asked jon several times to give us the source, but he never did !