Jump to content
IGNORED

Side3 W/U1MB and FATFS.SYS


videofx

Recommended Posts

I have a 1200XL with U1MB installed and a Side 3. My SD card has 2 partitions.

 

Partition 1- External 32MB (formatted as FAT16)

Partition 2 - DOS Partition 32MB

 

I load the FATFS.SYS to get access to the 32MB FAT16 partition.

 

The issue is this: Once I load the FATFS.SYS driver and do a DIR, it takes 35 seconds before I get the directory listing.

 

Of course once I get past the first DIR, all Directory listings are at normal speed.

 

Anyone else have this issue?

 

Thanks!

Link to comment
Share on other sites

oddly that's normal to some degree as it scans all of the drive including blank spaces and trips up a bit on directories, it shouldn't but it does. I have have hit the break key a few time and then changed directories/drives and such an it worked right away without issue. I tried communicating the problem but there was some sort of spoken/typed language issue that prevented explaining the problem. The only response was that it could be normal, but shouldn't be this bad.

Link to comment
Share on other sites

18 minutes ago, _The Doctor__ said:

oddly that's normal to some degree as it scans all of the drive including blank spaces and trips up a bit on directories, it shouldn't but it does. I have have hit the break key a few time and then changed directories/drives and such an it worked right away without issue. I tried communicating the problem but there was some sort of spoken/typed language issue that prevented explaining the problem. The only response was that it could be normal, but shouldn't be this bad.

Thanks! I figured it was normal.

Link to comment
Share on other sites

4 hours ago, videofx said:

The issue is this: Once I load the FATFS.SYS driver and do a DIR, it takes 35 seconds before I get the directory listing.

 

Of course once I get past the first DIR, all Directory listings are at normal speed.

 

Anyone else have this issue?

It is normal, this is how it behaves. Th driver needs to load up all the info about the disk ant it takes some time to do it. But just once. the next DIR is immediate. Untill you reboot the machine, of course.

Link to comment
Share on other sites

As an additional the initial directory read, as others have said, is normal I believe with fat16 because it doesn't keep track of free space so has to read it once initially at the start.

 

Also just as a passing comment but just out of interest is your side3 updated with the latest January 2023 fjc side 3 firmware? 

 

I only mention it because if you have a much older fjc firmware the Fatfms/dedicated new Dos that Flashjazzcat created which can r/w directly to fat16/32 partitions in both in the loader itself as well as in the cms is very good. (Obviously r/w not available in non Fat DOS's just read (with the fatfs.sys loaded) ). 

 

More info here:

https://atari8.co.uk/firmware/side3/

 

This video is at the bottom of that link's page. If you start 24mins in fjc talks about the initial delay reading a directory with fat16 formatted partitions in order for the Dos to initially read the free space because again fat16 doesn't keep track of the number of free clusters on the volume (unlike fat32 does) :

 

https://youtu.be/LJgnJ10SVzU

 

Link to comment
Share on other sites

32 minutes ago, Beeblebrox said:

As an additional the initial directory read, as others have said, is normal I believe with fat16 because it doesn't keep track of free space so has to read it once initially at the start.

That's what also @flashjazzcat said some time ago. And it's kind of... stupid since the driver is read-only so it shouldn't care about the free space. The only reason to know it is to display this info when DIR is issued. But anyway - pointless.

Link to comment
Share on other sites

1 hour ago, Peri Noid said:

The only reason to know it is to display this info when DIR is issued. But anyway - pointless.

The other reason is to get users become used to it, as this behaviour in inherent to FAT16. So that there would be no bad surprise when/if the driver becomes read/write.

  • Like 2
Link to comment
Share on other sites

2 hours ago, Peri Noid said:

The only reason to know it is to display this info when DIR is issued.

DIR is commonly the very first command the user issues on the volume. But in any case: Konrad can correct me if I'm wrong, but I thought that it was only the internal 'getdfree' or similar function (used by DIR, CHKDSK, etc) which obtained the free cluster count, and if you happen to type the name of an executable immediately after mounting the FAT16 volume, said executable will launch without delay.

 

Regarding my FATFMS DOS: it experiences the exact same hurdle as FATFS.SYS when establishing the free space on a FAT16 volume for the first time in a session, but because the FMS is designed exclusively for FAT and the (currently mandatory) mass storage device is capable of 70-80KB/s reads, even a FAT 128K in size (the largest possible) can be traversed in some 2-3 seconds when the system is establishing the free cluster count. Not ideal, but tolerable. Cluster allocaton, meanwhile, generally takes a fraction of a second unless the volume is densely packed.

Edited by flashjazzcat
  • Like 2
Link to comment
Share on other sites

33 minutes ago, flashjazzcat said:

even a FAT 128K in size (the largest possible) can be traversed in some 2-3 seconds

I agree that the FAT scan in FATFS should not take this long, it is definitely and suspiciously too slow (about 5 KB/s). I will take a look at that today, thanks for reminding me.

 

50 minutes ago, Peri Noid said:

Which seems to never happen

Many other things happen and the time passes by. While posting today about the SDX seek function, I was surprised to see that it was fixed nearly 17 years ago, I would swear that it was about 10 years ago maximum.

 

32 minutes ago, flashjazzcat said:

I offered to help complete the driver in any way I could last year, but never receieved a response to the offer.

Yes, sorry, I was preoccupied with many other things. Anyway, FATFS is a plugin to SPARTA.SYS (just as ATARIDOS.SYS, it is not an independent driver) and developing it needs thorough knowledge of SPARTA.SYS internals.

 

I am slowly describing all that for the Programming Manual, but for now I am inside the kernel drivers, and about the SPARTA.SYS file system driver interface there is not a word yet.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

19 minutes ago, drac030 said:

Anyway, FATFS is a plugin to SPARTA.SYS (just as ATARIDOS.SYS, it is not an independent driver) and developing it needs thorough knowledge of SPARTA.SYS internals.

 

I am slowly describing all that for the Programming Manual, but for now I am inside the kernel drivers, and about the SPARTA.SYS file system driver interface there is not a word yet.

Looking forward to all this. I am sure the end result will be well worth the wait!

  • Like 4
Link to comment
Share on other sites

34 minutes ago, videofx said:

Wow, I never thought we would get so many responses!

 

Thanks everyone.  I will also have to check the version of firmware on my Side3 and see if I have FJC's latest :)

:) worth upgrading the firmware. When you do have it (if not already) check out the manual and videos on that page I linked to. Get the most out of the new fatfms. The functionality in the loader is great as you'll see. 

  • Like 1
Link to comment
Share on other sites

10 hours ago, flashjazzcat said:

Can you reveal the primary culprit?

Scanning FAT via a general routine "get me the FAT entry for this cluster number". It still must be done this way for FAT12, but fortunately, a 12-bit FAT may never be bigger than 6k and rarely exceeds 1k, so this should not be a problem.

 

9 hours ago, videofx said:

Anything I can test?

Attached. Although please remember that it was rather superficially tested. And FAT12 was not. FAT16 seems to work, though.

fatfs.sys

  • Like 2
Link to comment
Share on other sites

1 hour ago, drac030 said:

Scanning FAT via a general routine "get me the FAT entry for this cluster number". It still must be done this way for FAT12, but fortunately, a 12-bit FAT may never be bigger than 6k and rarely exceeds 1k, so this should not be a problem.

Ah - this makes sense. Dropping FAT12 support (for now, having got it working) in my FAT DOS certainly facilitated efficient scanning of the FAT16/32 allocation tables using generic functions with no abstraction.

 

Thanks for uploading the modified driver; I'll test it presently too.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...