f



CBM-Command Version 1.6 - All Users Should Upgrade!

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
0
plbyrd75 (110)
7/28/2010 2:28:35 AM
comp.sys.cbm 14322 articles. 0 followers. dunric (341) is leader. Post Follow

5 Replies
444 Views

Similar Articles

[PageSpeed] 26

On Jul 27, 10:28=A0pm, Payton Byrd <plb...@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. =A0Please 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
0
Jerry
7/30/2010 7:42:06 PM
On Jul 30, 2:42=A0pm, Jerry Kurtz <jerryku...@gmail.com> wrote:
> On Jul 27, 10:28=A0pm, Payton Byrd <plb...@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. =A0Please discard any version older than 7/26/201=
0
> > (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. =A0I 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. =A0I 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? =A0Not 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? =A0I 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. =A0I 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.

0
Payton
7/30/2010 8:35:54 PM
Payton Byrd <plbyrd@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!


0
iAN
7/30/2010 9:03:25 PM
On Jul 30, 4:03=A0pm, "iAN CooG" <GETianRIDc...@OFemailME.it.invalid>
wrote:
> Payton Byrd <plb...@gmail.com> wrote:
> > Yes, I cache 30 records at a time, 19 (17 on the VIC) of which are
> > displayed at any time. =A0There'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.
0
Payton
8/2/2010 1:18:36 AM
On Jul 27, 10:28=A0pm, Payton Byrd <plb...@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. =A0Please discard any version older than 7/26/2010
> (Version 1.6) and update to Version 1.6!
>
> http://cbmcommand.codeplex.com

Here is my setup.  C64, 1541 as drive 8 (or 9 depending on my switch),
uIEC CF as 10 and CMD HD as 12

If I load cmbcommand from any drive, it always tries to read the
directory of drive 8 to start with.  I rarely have a disk in drive 8
so you know what happens then.  My thinking is that it should default
to the boot drive when it starts up.

I do also agree with the other posts about scrolling/selecting files
is way too slow.  Please realize that on a HD we could have several
hundred files.

Other than that, its a great program and works well.
0
JB
8/2/2010 1:15:45 PM
Reply: