flashjazzcat Posted February 20, 2009 Share Posted February 20, 2009 (edited) cc65 includes heap memory allocation functions already. They are sort of "expensive", like the formatted output (printf type functions) though. Mine are pretty "cheap"! They're written in compact assembler and they use a simple linked list, IIRC. You have to remember that Atari CC65 offered nothing like this in the default library. When I get the chance to get into things properly, I'll probably end up merging the best of my SpartaDOS library with the stuff that's already provided. I'm looking forward to getting to grips with the new CC65 once my word processor is finished. can we have ape directory change support where it hits the directory twice to get ape to switch the directory. where you can set that double request mode for just that drive. Can you explain in a bit more detail? I'll be happy to add any features I can. Edited February 20, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 20, 2009 Share Posted February 20, 2009 I'll be happy to add any features I can. I have not been able to copy as Source :H3:*.* . Only been able to copy atr's (i.e.) D2:*.* D3:*.* . This is with the Atari800win 4.0 emulator. Program crashes error code 170 and returns to DUP useing MyDos 4.534. Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted February 20, 2009 Share Posted February 20, 2009 I'll be happy to add any features I can. I have not been able to copy as Source :H3:*.* . Only been able to copy atr's (i.e.) D2:*.* D3:*.* . This is with the Atari800win 4.0 emulator. Program crashes error code 170 and returns to DUP useing MyDos 4.534. Does MyDOS normally work with the H: device? Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 20, 2009 Share Posted February 20, 2009 (edited) Does MyDOS normally work with the H: device? Yes it does and also a turbobasic copyfolder program works fairly good albiet a lot slower. I haven't tried this with A.P.E interface and Mirrored drive yet. Edited February 20, 2009 by rdea6 Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted February 20, 2009 Share Posted February 20, 2009 (edited) I love your program so far but I had some problems. - I tried copying a single subdirectory, e.g. D2:ACTION:*.* to D6:. Result: No activity. - tried to copy one folder to another folder, e.g. D2:ACTION:*.* TO D6:ACTION:*.* Results: No activity (whether or not the target folder already exists). No error message. Process completes. - tried copying all files and folders to a disk which already has some folders with the same name as the source folders Result: Copy proceeds until the first destination folder matching one from the source is encountered. Copy aborts and control returns to MyDOS menu. If there was an error message I didn't get to see it. <--- Edit: two lines added - same as above but this time an existing file on the destination matches one from the source Result: files are copied until it is time to overwrite the existing file. I then see 2-3 lines of garbled data and then the words "exists: overwrite". 800XL crashes. I used my 800XL (w/ Wiztronics 256K), SIO2PC, with AtariSIO/Atariserver serving the files. I tried with 3 different OSes. I also duplicated the same test with Atari800 emulator (SDL build). Same or similar results. - Steve Sheppard Edited February 20, 2009 by a8isa1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Share Posted February 21, 2009 (edited) I love your program so far but I had some problems. - I tried copying a single subdirectory, e.g. D2:ACTION:*.* to D6:. Result: No activity. - tried to copy one folder to another folder, e.g. D2:ACTION:*.* TO D6:ACTION:*.* Results: No activity (whether or not the target folder already exists). No error message. Process completes. - tried copying all files and folders to a disk which already has some folders with the same name as the source folders Result: Copy proceeds until the first destination folder matching one from the source is encountered. Copy aborts and control returns to MyDOS menu. If there was an error message I didn't get to see it. <--- Edit: two lines added - same as above but this time an existing file on the destination matches one from the source Result: files are copied until it is time to overwrite the existing file. I then see 2-3 lines of garbled data and then the words "exists: overwrite". 800XL crashes. I used my 800XL (w/ Wiztronics 256K), SIO2PC, with AtariSIO/Atariserver serving the files. I tried with 3 different OSes. I also duplicated the same test with Atari800 emulator (SDL build). Same or similar results. - Steve Sheppard Glad to see some testing and feedback on this. As I said, it wasn't well tested. If people actually want to use it, I'll try and finish it over the weekend. The failure to copy a directory on its own probably means the logic of the program relies (incorrectly) on the presence of a single file in the source directory. Easily fixed. The failure when copying to a disk containing folders of the same name as on the source disk is simple to diagnose: the program doesn't check for this condition yet. When it does, it will offer the option to merge source files into the exisiting directory, or skip the directory altogether (and to automatically perform the same action thereafter if desired). Same as above: there's code in there to check for existing files on the dest drive but it doesn't act on the information yet. Easily fixed. Error reporting code needs major tidying up. Like I say, if there's a demand to have this finished, I'll be glad to do it. I would still like some algorithmic ideas on how to avoid copying the destination directory into itself when source and destination drives are the same. For example: Source: D1:*.* Dest: D1:>BACKUP>*.* Eventually the program will try to copy the contents of "BACKUP" into itself. Clearly it should avoid this folder. This is easy to program around in the example, but what if the source is "D1:<*.*", etc? Answering my own question here, I think both source and destination paths need to be explicit from the root directory. This will involve picking up the working directory, which I can do. As for the H: device, the program should be OK with it. The splitpath routine doesn't really care what comes before the colon in the pathname. I'll have a go with it myself over the weekend. Have just realized something here... Does MyDOS allow colons as path separators (i.e. instead of ">")??? I assume from the above examples that it does. If so, it would explain quite few problems. The program only checks for right wedges as path separators... Edited February 21, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted February 21, 2009 Share Posted February 21, 2009 I love your program so far but I had some problems. - I tried copying a single subdirectory, e.g. D2:ACTION:*.* to D6:. Result: No activity. - tried to copy one folder to another folder, e.g. D2:ACTION:*.* TO D6:ACTION:*.* Results: No activity (whether or not the target folder already exists). No error message. Process completes. - tried copying all files and folders to a disk which already has some folders with the same name as the source folders Result: Copy proceeds until the first destination folder matching one from the source is encountered. Copy aborts and control returns to MyDOS menu. If there was an error message I didn't get to see it. <--- Edit: two lines added - same as above but this time an existing file on the destination matches one from the source Result: files are copied until it is time to overwrite the existing file. I then see 2-3 lines of garbled data and then the words "exists: overwrite". 800XL crashes. I used my 800XL (w/ Wiztronics 256K), SIO2PC, with AtariSIO/Atariserver serving the files. I tried with 3 different OSes. I also duplicated the same test with Atari800 emulator (SDL build). Same or similar results. - Steve Sheppard Glad to see some testing and feedback on this. As I said, it wasn't well tested. If people actually want to use it, I'll try and finish it over the weekend. The failure to copy a directory on its own probably means the logic of the program relies (incorrectly) on the presence of a single file in the source directory. Easily fixed. The failure when copying to a disk containing folders of the same name as on the source disk is simple to diagnose: the program doesn't check for this condition yet. When it does, it will offer the option to merge source files into the exisiting directory, or skip the directory altogether (and to automatically perform the same action thereafter if desired). Same as above: there's code in there to check for existing files on the dest drive but it doesn't act on the information yet. Easily fixed. Error reporting code needs major tidying up. Like I say, if there's a demand to have this finished, I'll be glad to do it. I would still like some algorithmic ideas on how to avoid copying the destination directory into itself when source and destination drives are the same. For example: Source: D1:*.* Dest: D1:>BACKUP>*.* Eventually the program will try to copy the contents of "BACKUP" into itself. Clearly it should avoid this folder. This is easy to program around in the example, but what if the source is "D1:<*.*", etc? Answering my own question here, I think both source and destination paths need to be explicit from the root directory. This will involve picking up the working directory, which I can do. As for the H: device, the program should be OK with it. The splitpath routine doesn't really care what comes before the colon in the pathname. I'll have a go with it myself over the weekend. Have just realized something here... Does MyDOS allow colons as path separators (i.e. instead of ">")??? I assume from the above examples that it does. If so, it would explain quite few problems. The program only checks for right wedges as path separators... I've always used the colons. Never even tested Sparta... style >'s. LOL. I was going to attempt to write this program in Action! but I had barely started before you already completed your core program. - Steve Sheppard Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 21, 2009 Share Posted February 21, 2009 make it a competition, see who can program it the best in their preferred languages! We all win! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Share Posted February 21, 2009 (edited) I've always used the colons. Never even tested Sparta... style >'s. LOL. I was going to attempt to write this program in Action! but I had barely started before you already completed your core program. I used MyDOS for years and never once used the colons! You should write one in Action! anyway. It might be better than mine. make it a competition, see who can program it the best in their preferred languages! We all win! Exactly! That we we end up with loads of great copiers... Edited February 21, 2009 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 21, 2009 Share Posted February 21, 2009 Hello guys MyDos can use: Dn: Dn> n: n> n not sure about Dn (no colon, no arrow). (n is any number between 1 and 9. Don't use 0 as it might work and will probably screw up things. This bug is killed in MyDOS 4.55.) Don't count on > being supported in later versions. The guy who wrote 4.55 beta 3 wants to kill it. In 4.55 beta 3, :: means "go back one (sub)directory". BTW if the filename without extender is 8 characters long, you don't need the period between the first 8 characters and the extender. Same goes for *.*, it can be replaced by **. greetings Mathy (who needs to get his 8 bit system up and running again) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Share Posted February 21, 2009 Hello guys MyDos can use: Dn: Dn> n: n> n not sure about Dn (no colon, no arrow). (n is any number between 1 and 9. Don't use 0 as it might work and will probably screw up things. This bug is killed in MyDOS 4.55.) Don't count on > being supported in later versions. The guy who wrote 4.55 beta 3 wants to kill it. In 4.55 beta 3, :: means "go back one (sub)directory". BTW if the filename without extender is 8 characters long, you don't need the period between the first 8 characters and the extender. Same goes for *.*, it can be replaced by **. greetings Mathy (who needs to get his 8 bit system up and running again) Yikes. Time to hit the MyDOS source code to look for an internal OS splitpath routine. Mine is getting more and more complex. Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 21, 2009 Share Posted February 21, 2009 Don't count on > being supported in later versions. The guy who wrote 4.55 beta 3 wants to kill it. That's utterly stupid. Using ">" etc. is compatible with SpartaDOS, which is rather popular. If MyDOS stops recognizing SpartaDOS pathnames, then to write applications running on both systems it will be needed to include special kludges on recognizing the DOS type and fix all the paths the program uses. This IMHO will kill MyDOS. Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 21, 2009 Share Posted February 21, 2009 Hallo flashjazzcat Time to hit the MyDOS source code to look for an internal OS splitpath routine. You can find the sourcecode to MyDOS (not all versions, but ... ) on my MyDOS page. Internal OS splitpath routine? No idea what you mean. greetings Mathy Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 21, 2009 Share Posted February 21, 2009 Internal OS splitpath routine? No idea what you mean. By "splitpath" (a generic name used in some C I/O libraries), I mean a routine to parse a path name and separate it into drive, path, name and extender. Since MyDOS is very "flexible" with regard to drive number delimiters, and uses (or is about to start using) double-colons to denote parent directories, etc, this adds complexity to any "bespoke" path parsing routine. Mine was designed for SpartaDOS (SDX has its own user-accessible "kernel" parsing routine), but I'm adapting it for MyDOS. If there's already a suitable routine in DOS.SYS, I'll use that instead. Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 22, 2009 Share Posted February 22, 2009 Hello Flashjazzcat I've been in contact with the guy who made MyDOS 4.55 beta 3 for years. (But unfortunately haven't really talked to him since I bought the IMac) He told me he wanted to rewrite the parser because as it is, it's pretty complicated to add any extra functionality. Guess that also means using it in different applications would not be easy. greetings Mathy Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted February 22, 2009 Share Posted February 22, 2009 Mathy would you happen to know which MyDOS version first implemented the '>' delimeter? I just checked my earliest versions, dating from around 1984, and '>' usage does not work. - Steve Shepard Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 22, 2009 Share Posted February 22, 2009 Hello Steve IIRC Bob Puff introduced the use of > under MyDOS. Guess that would eliminate all versions under 4. I'm pretty sure 4.50 supports it, not sure about versions >= 4 and <= 4.50. I don't know which version of MyDOS was Bob's first. greetings Mathy Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 22, 2009 Share Posted February 22, 2009 I've been in contact with the guy who made MyDOS 4.55 beta 3 for years. (But unfortunately haven't really talked to him since I bought the IMac) He told me he wanted to rewrite the parser because as it is, it's pretty complicated to add any extra functionality. Guess that also means using it in different applications would not be easy. I'll just go ahead and write my own. Although it's flexible, at least the methodology behind MyDOS pathnames is pretty clear-cut. It will be up to the user at the end of the day to be aware of which MyDOS version they are running and know whether or not to include right wedges in pathnames when typing them into the copier. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted November 27, 2009 Share Posted November 27, 2009 Bump.. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 27, 2009 Share Posted November 27, 2009 I'll put up the source code when I get a chance: someone else can finish it since I had my head in too many other things to complete the program. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 31, 2011 Share Posted March 31, 2011 To whom did I give the source code for this program? Any progress? Quote Link to comment Share on other sites More sharing options...
spookt Posted April 30, 2011 Share Posted April 30, 2011 To whom did I give the source code for this program? Any progress? Having just come to need a recursive file copy for MyDOS I thought I'd bump this. Did anyone take it on? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 30, 2011 Share Posted April 30, 2011 I was asked to finish this the other week and just haven't had time yet. It's on the to-do list. Quote Link to comment Share on other sites More sharing options...
OmaOhneBH Posted April 14, 2019 Share Posted April 14, 2019 Is there any new solution for recursive copy utility for MyDOS nowadays? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 14, 2019 Share Posted April 14, 2019 Wow... where did those eight years go? I think I lost the source code as well. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.