Jump to content
Sign in to follow this  
SoLo2

Atari 5"1/4 and PC-MSDOS compatible. FAT format.

Recommended Posts

Hello!

 

I did post this to "atari.org"

a while ago. As I had nearly

no answer, but I still think

using a de-facto standard

floppy format is interesting

for the XL scene and users...

 

 

 

I would like to know of

any Atari programmers,

if there exists any

DOS for XL that can

read&write PC MSDOS

compatible 5"1/4 diskettes.

 

Is this possible?

Does the hardware permit

such compatibility?

 

Anyways, it would be

interesting to know if

there is any DOS for

Atari XL that uses a

FAT file system. I think

it would be possible to

program a DOS that uses

nearly equal FAT disk

configuration.

Very nice would be,

to use with emulators

in Windows/Unix, to

mount disk images and

add/delete files.

 

 

Greetings,

SoLo2

 

Visit: bits.atari.org

 

 

Greetings again,

SoLo2

Share this post


Link to post
Share on other sites

The problem with using a FAT type system is that the sector links are kept in the FAT.

Therefore, when doing file read or creating a new file, you need to keep the entire FAT in RAM, otherwise you'll have time wasting seeks all the time.

 

Assuming an ED 1050 disk of 1040 sectors and FAT12, that equates to about 1600 bytes more RAM that the DOS would have to use.

You'd probably also need file buffers equal to the cluster size, so there's another 512 bytes for each file which can be OPEN at a time - for any sort of useable filing system you want that to be at least 3.

ed: actually for 512 byte clusters, that would equate to 1040/4 = 260 clusters. May as well use FAT8 and sacrifice the sectors > 1024 or use them for something else.

Or, reduce cluster size to 256 or 128 - smaller file buffers needed but the FAT size gets bigger again.

 

End result - a DOS that uses almost 3K more than a standard one. But, in some ways FAT would be more efficient than Atari's DOS from a programming point of view, so the actual FMS code might be shorter.

 

But, standard 810 and 1050s don't read DOS disks. Not sure about the XF551 and others. Also, floppies are out of favour anyway - it's pointless spending money on old tech just to have some PC compatability when there are much better solutions like Hard Drives and SD card readers about (and they use FAT anyway, IIRC).

Edited by Rybags

Share this post


Link to post
Share on other sites

I recall that Happy/Hyperdrive and laser 1050 upgrade's had the capability of reading PC disks (as long as you had the software, which xcame with the happy/laser upgrades)

Share this post


Link to post
Share on other sites

The compatibility of the hardware would only be possibly for 180K disks and maybe 360s for later drive mechs.

 

All up, a lot of trouble to go to if you don't already have a "Happy" solution, and not really worth any effory since 5.25 has been dead on the PC for a long time.

 

Not to mention the existence of much better alternatives like APE, SIO2SD and the various IDE interfaces around.

Share this post


Link to post
Share on other sites

A FAT 16 driver is planned for a future release of the SpartaDOS X. Don't know, if this year, though.

Share this post


Link to post
Share on other sites
The problem with using a FAT type system is that the sector links are kept in the FAT.

Therefore, when doing file read or creating a new file, you need to keep the entire FAT in RAM, otherwise you'll have time wasting seeks all the time.

 

Assuming an ED 1050 disk of 1040 sectors and FAT12, that equates to about 1600 bytes more RAM that the DOS would have to use.

You'd probably also need file buffers equal to the cluster size, so there's another 512 bytes for each file which can be OPEN at a time - for any sort of useable filing system you want that to be at least 3.

ed: actually for 512 byte clusters, that would equate to 1040/4 = 260 clusters. May as well use FAT8 and sacrifice the sectors > 1024 or use them for something else.

Or, reduce cluster size to 256 or 128 - smaller file buffers needed but the FAT size gets bigger again.

 

But, standard 810 and 1050s don't read DOS disks. Not sure about the XF551 and others. Also, floppies are out of favour anyway - it's pointless spending money on old tech just to have some PC compatability when there are much better solutions like Hard Drives and SD card readers about (and they use FAT anyway, IIRC).

 

Well, one can argue that Atari DOS 3 was actually an attempt to provide a FAT like filing system - it is very similar to FAT, the sector links are kept in a separate sector (DOS 2 would call that

the VTOC, but for DOS 3 it is the FAT), and four sectors are combined in a block to fit the FAT into one sector, so you get the typical 512 bytes/sector FAT uses.

 

Needless to say, DOS 3 never became very popular. For various reasons, of course, but the sector waste - for the small Atari disks - was one.

 

Greetings,

Thomas

Share this post


Link to post
Share on other sites

Hello!

 

 

Assuming the XL floppy drive uses

1040 sectors of 128Bytes each:

 

 

 

FAT8 has space for 256 clusters

 

FAT8 and 128Bytes/cluster:

1040 clusters... too BIG for FAT8

 

FAT8 and 256Bytes/cluster:

520 clusters... again too BIG for FAT8

 

FAT8 and 512Bytes/cluster:

260 clusters... again bigger than FAT8

but loosing 4 clusters = 2048Bytes....

256 clusters, 4 sectors of 128Bytes each cluster

1Byte/link = 256Bytes = 1/2 cluster for the FAT

may keep 2 copies of the FAT in the same cluster

 

FAT8 and 1024Bytes/cluster (old Linux size):

256*1024Bytes = 256K capacity per floppy

FAT of size 256Bytes again, this time it occupies

1/4 of a cluster and so 4 copies may be kept,

4 copies is very secure, but sadly, they are

stored in the same cluster.

Only 133 clusters in a 1050XL floppy disk.

 

 

 

FAT10 and 128Bytes/cluster:

1040 clusters .... too BIG for FAT10

or else there may be 16 sectors lost:

1024 * 10bits = 10240bits = 1280Bytes = 10 clusters FAT

 

FAT10 and 256Bytes/cluster:

1024 * 10bits = 10240bits = 1280Bytes = 5 clusters FAT

1024clusters * 256Bytes/cluster = 256K per floppy disk

520 clusters in a 1050 XL floppy disk

 

FAT10 and 1024Bytes/cluster:

1024clusters * 1024Bytes/cluster = 1MB per floppy! :)

260 clusters in a 1050 XL floppy disk

 

 

 

FAT11 is the minimum for

1040 clusters or sectors of 128Bytes each

int(log2(1040))=11 bits

not to loose 16sectors :)

 

 

 

 

FAT12 and 128Bytes/cluster:

this FAT has space for upto 4096 links

12bits * 4096links = 6144Bytes = 48 clusters! FAT

for the 1050 floppy only 1040links*12bits = 13 clusters! FAT

 

FAT12 and 256Bytes/cluster:

4096clusters*256Bytes=1 MegaByte max. per disk

24clusters for a 4096links FAT

7clusters for 1040links FAT of a 1050XL drive

 

FAT12 and 1024Bytes/cluster:

4096clusters*1K = 4 MegaBytes max. per disk

 

 

 

 

FAT16 and 128Bytes/cluster:

this FAT has space for upto 65536 links

16bits * 65536links = 131072Bytes = 1024clusters for the FAT!

65536clusters * 128Bytes = 8 MegaBytes max. per disk

1040links * 16bits = 2080Bytes = 17 clusters for FAT

 

FAT16 and 256Bytes/cluster:

65536clusters * 256Bytes = 16MegaBytes max. disk capacity

and 512clusters to store the FAT

1040links * 16bits = 2080Bytes = 9 clusters for the FAT

 

FAT16 and 1024Bytes/cluster:

64Mega Bytes max. disk space

128 clusters to store the FAT

3 clusters FAT for a 1050 XL floppy

 

 

 

 

This was more or less a synthesis of what

Rybags said in the previous post.

 

Of interest are the FAT12 and FAT16 which

are compatible with the MS-DOS world.

 

And for normal floppies the FAT12 and

256Bytes/cluster solution which manages

floppies of upto 1MB. It uses 7 clusters for FAT.

 

For more advanced floppies, like the modern

HHD PC floppies of 1.44MB, FAT12 and

512Bytes/cluster.

 

This last was also the sector size for Atari ST

computers, which were PC MSDOS FAT compatible:

2 sides * 80 tracks * 10 sectors * 512Bytes = 800 K

 

FAT16 wouldn't fit at once in the XL's memory.

This FAT needs 128K of RAM for 64K links ! :)

But if using a reduced cluster number of 1040, then

3K are required for the FAT, when using 128Bytes/cluster.

Or less, if using 1024Bytes/cluster only 260Bytes of

FAT in RAM memory.

FAT16 with full 128K FAT may be read as necessary

from disk or memory cards, because these are very

fast and XL files are very little, and maybe are wholly

contained in 1 or 2 FAT clusters (see Linux "inodes").

 

Of course, a mass storage abstracted from the

used file system, would require only the file name or

URL to load the data. This is more useable; faster,

reliable and consumes less RAM in the little XL! :)

This is the actual approach.

 

I would use the FAT8 with big clusters of

1024Bytes, as realizing how each XL program

may fit perfectly in only 1K, and still there's room

for 133 such little files in a 1050 floppy.

FAT8 fits in one 6502 page. 4 copies fit in 1

1024Bytes cluster, for safety.

 

 

Greetings,

SoLo2

Share this post


Link to post
Share on other sites
But, standard 810 and 1050s don't read DOS disks. Not sure about the XF551 and others. Also, floppies are out of favour anyway - it's pointless spending money on old tech just to have some PC compatability when there are much better solutions like Hard Drives and SD card readers about (and they use FAT anyway, IIRC).

 

I agree its kinda pointless to do that now where many people don't even use their 3.5 disks at 1.44MB. I am actually surprised that when Tramiel took over Atari, he didn't start using the same 3.5in drives that go into PCs and just build an interface instead of the XF551. At that point, they could have built them cheaper than what it was costing to build those costume 1050 and 551 drives. Any serious Atari user probably would use both drives and transfer their stuff to 3.5 higher density disks to save space and the 3.5 disks were more durable.

 

But around 1990, hard drive technology became more feasible and more suited for needs. Too bad Atari never officially upgraded the 8-bit into a 16bit machine with better speed and graphics. Instead Atari dropped the whole thing in the early 1990s.

Share this post


Link to post
Share on other sites

One advantage of FAT over the Atari DOS 2.x filesystem is that when deleting or seeking inside a file, you don't have to read it from the beginning just to know which sectors it uses. Also, sequential reads can go right from the device to RAM, without having to tweak the last bytes of each sector (same deal for writes).

 

Certainly doable with 128KB or more of RAM, and while floppies aren't really appealing, it would be nice to directly read and write FAT-formatted hard drives and CF/SD cards and be rid of the 16MB partition limit. The trouble would be all the ill-behaved programs that do their own disk ops or expect the FMS to fit into a tiny little area of RAM and use all the rest.

Share this post


Link to post
Share on other sites

For sure.

 

Deleting or overwriting a file would need maybe 8 sector reads and a few writes rather than having to scan the entire file.

 

What we really need is a DOS that just works for 64K and better machines, and has 90%+ of it's code sitting under the OS. In that case, having FAT support could be done with much less concern for the extra couple of K RAM for buffering that it might need.

Share this post


Link to post
Share on other sites

Didn't later versions of spartadros and mydos have support for 16meg plus partitions (i recall hearing that spartadros went upto 48meg partitions

Share this post


Link to post
Share on other sites

Hello!

 

 

Then all this discussion is true.

 

FAT for XL is feasible only if

the floppy drive and diskettes

can be written and read raw,

 

The drive doesn't have any

static or hard saved values in

the magnetic medium. Does it?

No "hard" protections, I mean.

 

 

Bye bye,

SoLo2

 

 

p.s. I edited this message a

little bit as I couldn't understand

my own English... :)

Edited by SoLo2

Share this post


Link to post
Share on other sites
What we really need is a DOS that just works for 64K and better machines, and has 90%+ of it's code sitting under the OS. In that case, having FAT support could be done with much less concern for the extra couple of K RAM for buffering that it might need.

 

Sounds like SpartaDOS! Especially SpartaDOS X.

Share this post


Link to post
Share on other sites
What we really need is a DOS that just works for 64K and better machines, and has 90%+ of it's code sitting under the OS. In that case, having FAT support could be done with much less concern for the extra couple of K RAM for buffering that it might need.

 

This is exactly SpartaDOS X, except that SDX is yet better. Namely, on 64K machines it may sit under the OS, but on a 128K+ machines it can keep its code and buffers in the extended RAM. So that your concern about buffers occupying the main RAM doesn't really apply.

 

@carmel_andrews: to 32 MB actually. And the filesystem format has been extended so that it can theoretically go up to 4 GB. But this has not yet been implemented. In MyDOS the 16 MB barrier is unbreakable.

Edited by drac030

Share this post


Link to post
Share on other sites
The compatibility of the hardware would only be possibly for 180K disks and maybe 360s for later drive mechs.

 

All up, a lot of trouble to go to if you don't already have a "Happy" solution, and not really worth any effory since 5.25 has been dead on the PC for a long time.

 

Yes, the Happy MS-DOS software could only do single sided 180K disks. And it wasn't very reliable because of the well known 300/288 RPM issue.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...