Maximum depth of a file Path

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, [ProToS], lp, moondog/.tSCc., Moderator Team

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Maximum depth of a file Path

Postby DrCoolZic » Mon Dec 07, 2009 10:52 am

I have run into a problem of path's depth:

I was testting under TOS 1.6 and I received the following message:
SNAPIT00.bmp.jpg

I therefore made the following test:
I started from root of disk and made a folder with name 1. Inside this folder c:\1 I have created folder 2 ...
I was able to go as far as 8 levels but when i reached this level I could not create level 9:
SNAPIT03.bmp.jpg


Therefore it looks like maximum depth is 8 under TOS 1.62 Can someone confirm.

To test further I have done test under TOS 2.06 and there I did not found limit (I stoped at level 18!).
I went back to TOS 1.62 and tried to access this tree.
I was able to go down all the way down the tree? I was also able to to copy a file at level 10 and execute it !?
But when I tried to copy the folder I again got the message shown above.

So it looks like on pre-TOS 2.x we have the folowing situation:
    cannot create folder above level 8
    can access folder and files at any level (if exist before)
    cannot copy folder above level 8

I did research in Atari compendium and did not found much information there. Only that you should use a 128bytes buffer for directory routine when accessing HD and 200 bytes when accessing CD-ROM ????

Actualy problem does not seems to be related to buffer lenght but rather to tree depth (in my example all folders are only 1 character long).

Does anybody has more information on this subject ?
For info I actually found this problem when trying to copy a tree in C program :?
You do not have the required permissions to view the files attached to this post.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Mon Dec 07, 2009 2:11 pm

DrCoolZic wrote:I have run into a problem of path's depth:

Therefore it looks like maximum depth is 8 under TOS 1.62 Can someone confirm.

To test further I have done test under TOS 2.06 and there I did not found limit (I stoped at level 18!).
I went back to TOS 1.62 and tried to access this tree.
I was able to go down all the way down the tree? I was also able to to copy a file at level 10 and execute it !?
But when I tried to copy the folder I again got the message shown above.

I was surprised. I only know of a 128 byte limit for the total path length and no limit for directory depth. My test with TOS 1.02, 1.04, 1.06 and 2.06 din't show a limit of 8 for folder depth. It might be a 1.62 issue.

I tested under STeem on the a drive. I might do a test on a real 1.0 machine later.

DrCoolZic wrote:So it looks like on pre-TOS 2.x we have the folowing situation:
    cannot create folder above level 8
    can access folder and files at any level (if exist before)
    cannot copy folder above level 8

I don't agree. Look it is tos 1.62 specific.

Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Mon Dec 07, 2009 3:25 pm

I was also very surprized but ...

Test performed on real Atari ST TOS USA 1.04 GEM 0.20 AES 1.40
SNAPIT00.jpg
SNAPIT01.jpg
SNAPIT02.jpg


Test performed on real Atari ST TOS FRANCE 1.62 GEM 0.20 AES 1.40
SNAPIT03.jpg
SNAPIT04.jpg



Also tested on steem same result :?
How did you tested ? Followed my procedure ?
You do not have the required permissions to view the files attached to this post.

User avatar
Desty
Atari God
Atari God
Posts: 1959
Joined: Thu Apr 01, 2004 2:36 pm
Location: 53 21N 6 18W
Contact:

Re: Maximum depth of a file Path

Postby Desty » Mon Dec 07, 2009 8:10 pm

Thought this was well known - I ran into this issue on my old STFM with TOS 1.02 (UK). Actually I was experimenting to see if there was any such limit, using a ramdisk to quickly create deeper and deeper folders, and soon found one.

I seem to recall this being related to the limit on command-line argument buffer size (like 256 bytes or something?) - i.e. you can't pass a pathname as an argument to a program if the pathname is bigger than the maximum argv[] size, so instead of increasing the space for cmdline arguments they limited the path depth.
tá'n poc ar buile!

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Tue Dec 08, 2009 10:46 am

DrCoolZic wrote:I was also very surprized but ...

Also tested on steem same result :?
How did you tested ? Followed my procedure ?

I now tested on drive C, started with 0...9 then folder A to U. Then I copied them to drive A and ran into the 40 folder problem on TOS 1.04. With KAOS TOS there was no problem. The thing is that I created the folders under Teradesk 1.40 then everything works fine. Under plain TOS I can access the folders but I cannot create a new one nor create a file there, even not with KAOS TOS.

Because everything works fine with Teradesk I assume the folder depth isn't a problem on GEMDOS level. With Pure C I could create a file in directory D (level 14), but Universal Item selector V3.3 wouldn't let create me a new folder on this level. The File selector from Pure C itself could create a folder at the same level.

The TOS 1.04 desktop can access and show the file I created with Pure C in directory D.
folders.png


Hans Wessels
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Tue Dec 08, 2009 1:20 pm

Nyh wrote:I now tested on drive C, started with 0...9 then folder A to U. Then I copied them to drive A and ran into the 40 folder problem on TOS 1.04.

Hi Hans,
I thought that the folder problem was only on 1.0 1.02 but was suppose to be fixed with 1.04 ?
See
http://cd.textfiles.com/crawlycrypt2/pr ... s_rom_._11
http://www.atarimagazines.com/startv4n3/smalltools.html in section VI. Does Your Data Appear Damaged?
http://www.atari.st/content.php?type=t&file=toslist

With KAOS TOS there was no problem. The thing is that I created the folders under Teradesk 1.40 then everything works fine. Under plain TOS I can access the folders but I cannot create a new one nor create a file there, even not with KAOS TOS.

What is KAOS TOS? Can you use it on a real Atari ?

Because everything works fine with Teradesk I assume the folder depth isn't a problem on GEMDOS level. With Pure C I could create a file in directory D (level 14), but Universal Item selector V3.3 wouldn't let create me a new folder on this level. The File selector from Pure C itself could create a folder at the same level.
The TOS 1.04 desktop can access and show the file I created with Pure C in directory D.

Yes it seems that with Pure C it works with more than 8 levels. In my program I was copying a tree with more than 8 levels created on PC. And it is only when playing withthe result from the desktop that I found the limitation.

However I really need to verify the limitation you mention about 40 folders with 1.04. I thought this was one of the major fix of the rainbow TOS :(

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Tue Dec 08, 2009 3:29 pm

DrCoolZic wrote:
Nyh wrote:I now tested on drive C, started with 0...9 then folder A to U. Then I copied them to drive A and ran into the 40 folder problem on TOS 1.04.

Hi Hans,
I thought that the folder problem was only on 1.0 1.02 but was suppose to be fixed with 1.04 ?

The 40 folder limit is still in TOS 1.04. Before TOS 1.04 the OS ran out of buffer space as soon as you accessed 40 different folders because the space is not recycled. In TOS 1.04 the folder space is recycled but in the example I have 33 open folders. When you copy them to drive A the OS runs out of folderspace after 7 new folders.

KAOS TOS will survive a bit longer but you can even run out of folderspace with KAOS (use addmem.prg to get more folder space).

DrCoolZic wrote:What is KAOS TOS? Can you use it on a real Atari ?

KAOS to is TOS 1.04 with a lot of bug fixes and improvements by Andreas Kromke (of MagiC fame). See http://www.atari-forum.com/wiki/index.php/History_of_Atari_TOS. You can use it on a real Atari. My development machine used KAOS for years. I installed KAOS instead of 1.04 and I was very happy with it, especially with the push pack button on the GEM windows, making the top window into the lowest window. You can see the Icon next to the maximize icon.

Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Tue Dec 08, 2009 5:26 pm

Nyh wrote:The 40 folder limit is still in TOS 1.04. Before TOS 1.04 the OS ran out of buffer space as soon as you accessed 40 different folders because the space is not recycled. In TOS 1.04 the folder space is recycled but in the example I have 33 open folders. When you copy them to drive A the OS runs out of folderspace after 7 new folders.

I am not sure what you mean by open? I did two test on my 1.04 system:

First I have made a copy of a folder that contains 106 directories just drag and drop on partition D
SNAPIT00.jpg

The copy when well without problem. To relate to the original problem description, if the level is above 8 it would not let me do it.

The second test I have made is to use my hard disk/driver test program written in C (It basically copy a tree and then run several passes of verification). The program was able to copy the complete tree, with 100+ folders, without a problem.

Therefore when do we hit the 40-folders bug?

KAOS to is TOS 1.04 with a lot of bug fixes and improvements by Andreas Kromke (of MagiC fame). See http://www.atari-forum.com/wiki/index.php/History_of_Atari_TOS. You can use it on a real Atari. My development machine used KAOS for years. I installed KAOS instead of 1.04 and I was very happy with it, especially with the push pack button on the GEM windows, making the top window into the lowest window. You can see the Icon next to the maximize icon.
I have made some search and I found that you already published an english version 142 of KAOS ROM (I also found a german v143 that seems to have more features but it is in German! any 143 in English?).
I was able to run the image with steem.
On a real atari, apart from burning ROM, how do you use it? I have heard about a program called seltos that is suppose to load tos image. Is this what you use?

Thanks - Jean
You do not have the required permissions to view the files attached to this post.

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12495
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Maximum depth of a file Path

Postby wongck » Wed Dec 09, 2009 1:29 am

DrCoolZic wrote:I am not sure what you mean by open? I did two test on my 1.04 system:

First I have made a copy of a folder that contains 106 directories just drag and drop on partition D
The copy when well without problem. To relate to the original problem description, if the level is above 8 it would not let me do it.

The second test I have made is to use my hard disk/driver test program written in C (It basically copy a tree and then run several passes of verification). The program was able to copy the complete tree, with 100+ folders, without a problem.

Therefore when do we hit the 40-folders bug?



Any extra folders buffers configured in your HDDriver?
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Wed Dec 09, 2009 9:41 am

DrCoolZic wrote:The second test I have made is to use my hard disk/driver test program written in C (It basically copy a tree and then run several passes of verification). The program was able to copy the complete tree, with 100+ folders, without a problem.

Therefore when do we hit the 40-folders bug?

On the old TOS your test would have hit the 40 folder bug. On TOS 1.04 and onward you have to open 40 folders at the same time. Normally this happens seldom. But is does happen quickly when you create a folder structure with a depth of 33 as I did. When you are at level 33 you have 33 open folders which leaves 7 spare folders. As soon as you try top copy the deep tree folders are opened at the destination side to and you quickly pass the 40 folder limit.
40foldercrash.png


DrCoolZic wrote:I have made some search and I found that you already published an english version 142 of KAOS ROM (I also found a german v143 that seems to have more features but it is in German! any 143 in English?).
I was able to run the image with steem.
On a real atari, apart from burning ROM, how do you use it? I have heard about a program called seltos that is suppose to load tos image. Is this what you use?
[/quote]
I have got KAOS TOS and TOS 1.0 in a 6x512 Mbit Eprom, switchable. You can simply burn KAOS TOS in Eprom and use it like normal TOS. The program Seltos is to load TOS versions in RAM. I have never used something like that. It might work with KAOS but I am not sure about that. Steem is an excellent way to test TOS versions.

Hans Wessels
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Wed Dec 09, 2009 12:20 pm

wongck wrote:Any extra folders buffers configured in your HDDriver?

Good point! I did not even new that HDD was adding extra folders! 100 in my case?
I will redo test without these extra folders

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Wed Dec 09, 2009 12:27 pm

Nyh wrote:
DrCoolZic wrote:The second test I have made is to use my hard disk/driver test program written in C (It basically copy a tree and then run several passes of verification). The program was able to copy the complete tree, with 100+ folders, without a problem.
Therefore when do we hit the 40-folders bug?

On the old TOS your test would have hit the 40 folder bug. On TOS 1.04 and onward you have to open 40 folders at the same time. Normally this happens seldom. But is does happen quickly when you create a folder structure with a depth of 33 as I did. When you are at level 33 you have 33 open folders which leaves 7 spare folders. As soon as you try top copy the deep tree folders are opened at the destination side to and you quickly pass the 40 folder limit.
So if I undertand correctly open means, in your example, that you have traversed 33 levels to get to the displayed current folder.
This should be possible even on TOS <= 1.62 but copy operation would not be possible anyway due to 8 level depth limit.

EDIT:
Do you know if this notion of "open" apply when you are running from a C application. For example let say that I am accessing from C files at level 33 does this imply 33 "open folders".
Do and When are the folder "closed". If I move one level up is the # of open folder 32?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Wed Dec 09, 2009 2:50 pm

DrCoolZic wrote:Do you know if this notion of "open" apply when you are running from a C application. For example let say that I am accessing from C files at level 33 does this imply 33 "open folders".
Do and When are the folder "closed". If I move one level up is the # of open folder 32?

I think this article http://www.sarnau.info/atari:tos_1.4_release_notes#discussion_of_os_pool explains all.

Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Wed Dec 09, 2009 2:51 pm

I made some test based on above information.
In the HDD General Setting I have changed the additional Folders from 100 to 0
DSC06584.JPG

I have created a 50 level deep tree on PC
I have traversed the tree and at level 34 (not 40) I got the following screen
DSC06582.JPG

With 4 nices bombs !
Reset button at back of Atari did not even restarted the computer. I had to power off/on

I used my copy tree program. And at about level 33 I got the "out of internal memory ...." message but the program continued to work and was able to indeed copy the 50 levels of directories and to verify them correctly !?!

Folder100.PRG corrected the problem (both from desktop and from program)
And of course seting "additional folders" back to 100 in HDD also solved the problem.

* Therefore looks like 40-folders problem was not fixed by 1.04 and looking at http://www.atari.st/content.php?type=t&file=toslist seems like 2.x and 3.x TOS still need this fix ???

* For the tree depth it seems like from the desktop level is limited to 8 for pre 2.x TOS but shows no practical limit from program. I am therefore wandering from where the problem comes. Not from GEMDOS/XBIOS/BIOS as it would not work from C. May be just some code in the desktop ?
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Wed Dec 09, 2009 3:34 pm

Nyh wrote:
DrCoolZic wrote:Do you know if this notion of "open" apply when you are running from a C application. For example let say that I am accessing from C files at level 33 does this imply 33 "open folders".
Do and When are the folder "closed". If I move one level up is the # of open folder 32?

I think this article http://www.sarnau.info/atari:tos_1.4_release_notes#discussion_of_os_pool explains all.

Hans Wessels

Excellent site. Excellent information
Thanks very much Hans

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Thu Dec 10, 2009 10:00 am

Not directly related but Hans would you know an easy call to Atari timer from C ?
I would need this to measure transfer time. I am currently using the system call time() function but it is only 1 sec precision.
I would rather use one of the Atari timer (timer A). I have some code for accessing the MFP but it is not very easy as you have to handle overflow and requires to go to super() mode...
I searched the function call available from Pure C lib and did not found any ?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Thu Dec 10, 2009 1:13 pm

DrCoolZic wrote:Not directly related but Hans would you know an easy call to Atari timer from C ?
I would need this to measure transfer time. I am currently using the system call time() function but it is only 1 sec precision.
I would rather use one of the Atari timer (timer A). I have some code for accessing the MFP but it is not very easy as you have to handle overflow and requires to go to super() mode...
I searched the function call available from Pure C lib and did not found any ?

I usually use this for timing:

Code: Select all

#include <time.h>

      clock_t t;
      t=clock();
      decode_m7(dst, src);
      t=clock()-t;
      printf("ARJ m7   : time = %li.%02li s\n", t/(CLK_TCK), (100*(t-(t/(CLK_TCK))*(CLK_TCK)))/(CLK_TCK));

clock() is in the ANSI C standard lib and on Atari it uses the 200 Hz system clock. If you need a higher accuracy as 200 Hz you have to write a timer routine in assembly.

Hans Wessels

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12495
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Maximum depth of a file Path

Postby wongck » Thu Dec 10, 2009 1:59 pm

DrCoolZic wrote: Therefore looks like 40-folders problem was not fixed by 1.04 and looking at http://www.atari.st/content.php?type=t&file=toslist seems like 2.x and 3.x TOS still need this fix ???

Yes, I remember that it is mentioned up to tos 3.x need this fix.
One well-known Atari guy (can't remember the name) called this a configurable feature because you can speed up the disk access if you add more buffers. :mrgreen:
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Thu Dec 10, 2009 3:45 pm

Nyh wrote:I usually use this for timing:

Code: Select all

#include <time.h>

      clock_t t;
      t=clock();
      decode_m7(dst, src);
      t=clock()-t;
      printf("ARJ m7   : time = %li.%02li s\n", t/(CLK_TCK), (100*(t-(t/(CLK_TCK))*(CLK_TCK)))/(CLK_TCK));

clock() is in the ANSI C standard lib and on Atari it uses the 200 Hz system clock. If you need a higher accuracy as 200 Hz you have to write a timer routine in assembly.

This is very handy and much more accurate than time(). I will use it for overall prog execution. However in some places in need better accuracy.

I have just finished the routines to access timer A and it works fine (and of cource all is coded in C :wink: - I do not like 68K asm :( )
I choose a prescale of 200 wich gives a period of about 81µs and an overflow every 20 ms. As I get back to the timer in less than 20 ms I can test for overflow and proceed accordingly, but it would probably be better to setup an interupt handler on overflow, but I do not know (yet) how to write that in C. :)

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Thu Dec 10, 2009 4:47 pm

DrCoolZic wrote:I choose a prescale of 200 wich gives a period of about 81µs and an overflow every 20 ms. As I get back to the timer in less than 20 ms I can test for overflow and proceed accordingly, but it would probably be better to setup an interupt handler on overflow, but I do not know (yet) how to write that in C. :)

It is possible to do that in Pure C but this is dark magic. You can only use code that doesn't change registers.

Code: Select all

#include <stdio.h>
#include <tos.h>

void rte(void) 0x4E73;

volatile long int counter=0;

void handler(void)
{
  counter++;
  *(char*)0xfffa0fL=0xDF; /* clear interrupt mask */
  rte();
}

int main(void)
{
  Jdisint(13); /* disable timer A */
  Xbtimer(0, 1, 128, handler); /* install and enable timer A handler */
  for(;;)
  {
    printf("%li\n",counter);
  }
  return 0;
}


Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Thu Dec 10, 2009 11:16 pm

Nyh wrote:
DrCoolZic wrote:I choose a prescale of 200 wich gives a period of about 81µs and an overflow every 20 ms. As I get back to the timer in less than 20 ms I can test for overflow and proceed accordingly, but it would probably be better to setup an interupt handler on overflow, but I do not know (yet) how to write that in C. :)

It is possible to do that in Pure C but this is dark magic. You can only use code that doesn't change registers.

Code: Select all

#include <stdio.h>
#include <tos.h>

void rte(void) 0x4E73;

volatile long int counter=0;

void handler(void)
{
  counter++;
  *(char*)0xfffa0fL=0xDF; /* clear interrupt mask */
  rte();
}

int main(void)
{
  Jdisint(13); /* disable timer A */
  Xbtimer(0, 1, 128, handler); /* install and enable timer A handler */
  for(;;)
  {
    printf("%li\n",counter);
  }
  return 0;
}


Hans Wessels

Yes this is really dark magic! and extremely elegant solution compared to the code I wrote manipulating the timer registers, going in/out of sv mode ... !!!!

Lets see if I can make sense out of this:

void rte(void) 0x4E73;
I remember that you already mentioned this capability of Pure C to drop "Assembly opcode" inside C code. I have been looking everywhere in the Pure C help files but could not find any information on this ?
How did you found about this feature? What is the syntax? If I remember correctly you also gave examples passing an argument. Something like func(long value) 0x???? In that case the code dropped would be ???? folowed by value ? Is it limited to Only one argument or more ? What type of argument char, short, long ... ? This looke extremely powerful and I am interested by information even if it is not really portable.

So with a name like rte I guessed that the 0x4E73 is instruction for return from exception (probably another name for interrupt in 68k terminology - sorry I am more an x86 guy :wink: )
By the way I have dowloaded lots of documents on motorola (user's guide, ... ) but none of them have a simple table that list by hex value the associated opcode? So I can easely find that $4e73 is an RTE operation ??? Any pointer to such document ?

The rest of the code is relatively clear :? but I have few questions:
First: in the handler you access register directly and use RTE. All this needs to be done in SV mode, so my guess is that the handler declare in Xbtimer is called in SV mode (humm this sound pretty obvious) :wink:
Second: You used Jdisint() ? This is suppose to disable interrupt ? I was rather expecting Jenabint() function to be called ? so that timer can generate interrupt ?
I noted the usage of volatile, so that if counter is used in some other places in the code it does not get "optimized".


Now another question related on the subject of limitations while accessing files and folders.
I was running some tests to copy a large tree from one partition to another using a new hd driver in dev. from ppera and the program stoped on an invalid file name to read. It happen that this tree has been generated on a PC with some files using long file name. The files shows in Atari with shorter name and usage of "~" char (I think this is part of the DOS 8.3 name mapping). According to ppera this is the cause of the problem (problem in Fsfirst() and Fsnext()) and indeed on on a tree without "long names" everything works fine. However I run the exact same test without any problem using HDD 8.2 !?!
So here is my question: does anybody knows if HDDriver does something to correct this problem ???

Another interesting way to see this problem is by asking "file information" on a large tree with "long names": it returns a correct number of files and folders but an invalid size (even using all sorts of invalid character in the size field!).

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Maximum depth of a file Path

Postby Nyh » Fri Dec 11, 2009 1:03 am

DrCoolZic wrote:The rest of the code is relatively clear :? but I have few questions:

The questions are answered in a new thread: Interrupthandler in C http://www.atari-forum.com/viewtopic.php?f=70&t=18212. I think this is interesting for more people then those who are following this thread.

Hans Wessels

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Maximum depth of a file Path

Postby DrCoolZic » Mon Jan 04, 2010 6:31 pm

Information on max depth plus other limitations has been added in new release of my doc at
viewtopic.php?f=15&t=18027&p=158692#p158692


Social Media

     

Return to “Professionals”

Who is online

Users browsing this forum: No registered users and 6 guests