CBM-Command Version 1.6 - All Users Should Upgrade!
in [Commodore]
|
From: Payton Byrd on 27 Jul 2010 22:28 There is a major bug in the way that CBM-Command handles batches of file that are selected using the select all hotkey that can cause directory corruption. Please discard any version older than 7/26/2010 (Version 1.6) and update to Version 1.6! http://cbmcommand.codeplex.com
From: Jerry Kurtz on 30 Jul 2010 15:42 On Jul 27, 10:28 pm, Payton Byrd <plb...(a)gmail.com> wrote: > There is a major bug in the way that CBM-Command handles batches of > file that are selected using the select all hotkey that can cause > directory corruption. Please discard any version older than 7/26/2010 > (Version 1.6) and update to Version 1.6! > > http://cbmcommand.codeplex.com Hello Payton, I finally got around to trying this on real hardware so that I could transfer some files from my CMD-HD to the uIEC. I really like the concept, but I have to say, scrolling down through the files in the directory is very slow. I know I've mentioned this before, but I believe it has to do with the way you are re-drawing the file list and the resulting flashing. I know you stated that you were doing it that way for code-portability between systems, but I really think that to make this thing really sing, you may need to investigate another approach. Do you cache ahead any of the file entries, or only read them as needed? Not that I'm a Vic 20 or C128 hater, but I think specific versions for specific platforms, in this case, make sense. Did you say you were writing this in C or is this pure assembly? Also, can this tool remove a directory during deletes, or traverse a directory when copying? I couldn't seem to get it to delete a directory. Anyway, I managed to complete what I needed, and the progress meter and such during the copy was a nice touch. I can appreciate the efforts you've put into this tool. Jerry
From: Payton Byrd on 30 Jul 2010 16:35 On Jul 30, 2:42 pm, Jerry Kurtz <jerryku...(a)gmail.com> wrote: > On Jul 27, 10:28 pm, Payton Byrd <plb...(a)gmail.com> wrote: > > > There is a major bug in the way that CBM-Command handles batches of > > file that are selected using the select all hotkey that can cause > > directory corruption. Please discard any version older than 7/26/2010 > > (Version 1.6) and update to Version 1.6! > > >http://cbmcommand.codeplex.com > > Hello Payton, > > I finally got around to trying this on real hardware so that I could > transfer some files from my CMD-HD to the uIEC. This is a good combination of drives. You are fortunate. > > I really like the concept, but I have to say, scrolling down through > the files in the directory is very slow. I know I've mentioned this > before, but I believe it has to do with the way you are re-drawing the > file list and the resulting flashing. I know you stated that you were > doing it that way for code-portability between systems, but I really > think that to make this thing really sing, you may need to investigate > another approach. I'm sorry, but there's no other way to redraw the screen without poking to the screen memory and I'm not going down that road. I know scrolling is a pain, which is why I added Page Up (plus key) and Page Down (minus key) and moving to the top (Up arrow) and to the bottom (SHIFT-Up arrow). > > Do you cache ahead any of the file entries, or only read them as > needed? Not that I'm a Vic 20 or C128 hater, but I think specific > versions for specific platforms, in this case, make sense. Yes, I cache 30 records at a time, 19 (17 on the VIC) of which are displayed at any time. There's not enough RAM to cache any more than this because you have to remember that with two panels that's 60 records in RAM at once, each having an overhead of over 20 bytes, it takes over 1K just to cache the sliding windows for the two panels. > > Did you say you were writing this in C or is this pure assembly? It's written in C with a couple of very small assembly routines to make saving and retrieving screens faster. > > Also, can this tool remove a directory during deletes, or traverse a > directory when copying? I couldn't seem to get it to delete a > directory. This is up to the drive in question. If you select a directory and hit F8 to delete it, it simply sends a S0:DIRNAME to the drive and it's up to the drive to decide whether or not to delete the directory. > > Anyway, I managed to complete what I needed, and the progress meter > and such during the copy was a nice touch. I can appreciate the > efforts you've put into this tool. Thanks, it's been a pleasure working on CBM-Command and I'm always glad to hear when it's been useful for somebody.
From: iAN CooG on 30 Jul 2010 17:03 Payton Byrd <plbyrd(a)gmail.com> wrote: > Yes, I cache 30 records at a time, 19 (17 on the VIC) of which are > displayed at any time. There's not enough RAM to cache any more than > this because you have to remember that with two panels that's 60 > records in RAM at once, each having an overhead of over 20 bytes, it > takes over 1K just to cache the sliding windows for the two panels. this is an issue on vic 20 or also on c64? how many RAM do you use? -- -=[]=--- iAN CooG/HVSC & C64Intros ---=[]=- My software never has bugs. It just develops random features!
From: Payton Byrd on 1 Aug 2010 21:18
On Jul 30, 4:03 pm, "iAN CooG" <GETianRIDc...(a)OFemailME.it.invalid> wrote: > Payton Byrd <plb...(a)gmail.com> wrote: > > Yes, I cache 30 records at a time, 19 (17 on the VIC) of which are > > displayed at any time. There's not enough RAM to cache any more than > > this because you have to remember that with two panels that's 60 > > records in RAM at once, each having an overhead of over 20 bytes, it > > takes over 1K just to cache the sliding windows for the two panels. > > this is an issue on vic 20 or also on c64? how many RAM do you use? You have to remember, this is running in the cc65 runtime, there's several pre-defined segments of ram, and after they are all initialized the heap isn't all that big. To ensure that memory always exists for the 60 sliding window entries the memory is not dynamically allocated, so the linker automatically blocks off the ram for this. I could tinker to find a bigger sliding window size at the risk of blowing up something else, such as the heap, which is used for dynamically allocated structures such as the selected files array. This problem exists for all the platforms, not any one in particular. |