Page 2 of 10

Re: ZXpand-Commander

Posted: Thu Sep 27, 2012 10:32 pm
by sirmorris
That was reported by Yerzmyey also - I found it was a timing bug related to the file count on the card. I have fixed this and uploaded v1.2. Hopefully this will be the last timing related bug :(

Re: ZXpand-Commander

Posted: Thu Sep 27, 2012 11:43 pm
by Andy Rea
oops my bad.... had re-dowloaded v1.1 :oops: NOT 1.2 Sorry.

Andy

Re: ZXpand-Commander

Posted: Mon Oct 01, 2012 2:49 pm
by sirmorris
Version 1.3 now available in the top post! Unless issues are forthcoming I think this may well be the last release for a while.

C

Re: ZXpand-Commander

Posted: Wed Oct 03, 2012 5:02 pm
by sirmorris
Version 1.4 just released!

I've added some faster navigation features. You can use '.' to go up a directory level and shift-5/6 to whizz around the file list.

Enjoy!

Re: ZXpand-Commander

Posted: Wed Oct 03, 2012 6:45 pm
by 1024MAK
sirmorris wrote:Version 1.3 now available in the top post! Unless issues are forthcoming I think this may well be the last release for a while.
Then two days later...
sirmorris wrote:Version 1.4 just released!
First: Thanks!

Second, do I change the definition of "for a while" to "about two days" :mrgreen: :lol:

Keep up the good work :D :mrgreen:

Mark

Re: ZXpand-Commander

Posted: Wed Oct 03, 2012 8:48 pm
by yerzmyey
OK, I got ashamed by SirMorris' speed, so finally tested the 1.4 version.

Renaming worx perfectly.
Deleting - too (no errors this time, HA!).
PAGE UP / PAGE DOWN - perfect.

The "." sign on the screen doesn't work as a "go up a directory level", still have to press ".." to go one-up.
I guess the "." was supposed to go instantly to the main path of a disk?

A weird thing: when I copied name.p file into another window - I changed its name into "name" (without *.p).
Then I tried to copy it back.
The commander crashed, destroying the lower line and showing
?K (when "K" is cursor).

Reset is required (because it leaves into BASIC).

Also it does the same when in both windows are the same files (with the same name at least).

And one more thing - both of them mixed:
when in one window is "name" and in another is "name.p", then COPY will crash the commander too. Interesting.

Do my words have any sense? ;)

Re: ZXpand-Commander

Posted: Wed Oct 03, 2012 10:36 pm
by sirmorris
@Mark - Hehe well I had a few minutes to fettle... ;)

@Yerz - When you save a file without an extension the interface will add '.p' as a default. When you try to copy or rename a file and the target exists then you'll get an error and drop out of the commander. This is actually as designed. It doesn't seem right though. Hmm. I'll probably just display the error, the only other option is to either silently overwrite or disable the default extension generation. The 1st is easy, the latter would require some hackery...

C

Re: ZXpand-Commander

Posted: Wed Oct 03, 2012 10:48 pm
by yerzmyey
Yes yes, some error message sounds good.
"File already exists" or something like that, and then simply return to the main-screen (both windows) without copying.
Sounds good.

Re: ZXpand-Commander

Posted: Thu Oct 04, 2012 1:37 pm
by sirmorris
I will implement error display where possible but the load/save routines (used by the COPY function) have their own error handling which uses the BASIC interpreter and therefore I can't catch the errors it generates.

The problem is only with files that don't have an extension. If you open one of these then the PIC firmware assumes you mean a P file and appends the extension for you. Your test case above then becomes:

1. copy a file X/ABC.P to new folder Y
(load X/ABC.P to memory, save as Y/ABC.P)
2. rename Y/ABC.P to Y/ABC
3. copy Y/ABC to X/ABC
(load Y/ABC to memory, ...) <- FAILS because ZXpand will try to load Y/ABC.P which of course does not exist.

There are a few things I could do, such as temporarily disabling auto extension generation, or changing the overlay ROM to return errors rather than pass them to the BASIC error handler, or even re-implement the ROM's load/save code inside commander, but these all sound quite heavy-duty for such an edge-case.

In short - unless there is an outcry then this will probably just have to be left as-is. The solutions are a little heavy in relation to the problem.

It has resulted in a dark damp fog surrounding me though - leaving software with a known bug is upsetting :cry:

Thinking about it though - the filename strings passed around by commander are all prefixed with a forward slash, something which is unlikely to happen in common use. I could detect this in the zxpand firmware and disable extension generation - but would this cause issues elsewhere I wonder?

Thoughts?

C

Re: ZXpand-Commander

Posted: Thu Oct 04, 2012 2:13 pm
by yerzmyey
if this is so difficult then I would leave it as it is now. Plus some info in TXT file or what.
Because if You start tinkering with it so much, then we all will probably end up with a necessity of writing *.p extension all the time, even from basic, while a regular loading.
So.
Let's forget it. :)
I think.