Re: [cc65] C64 POSIX dirent stuff actually working?

Hello Uz,

* On Mon, Aug 06, 2012 at 09:34:58PM +0200 Ullrich von Bassewitz wrote:
> 
> On Mon, Aug 06, 2012 at 09:14:09PM +0200, Spiro Trikaliotis wrote:
> > r5804? Well, LOAD "$:*,R",8 does not work as you expect, indeed...
> 
> It does, but "$0,R" does not.

I agree with André: This is just an implementation detail of the 1541,
not something you should rely on.

It makes even sense: With "$:*,R", there IS a filename specified ("*").
Thus, the parser (which is shared between file handling and directory
handling here, as André remembered correctly) accepts the ",R", as it is
something you can specify when opening files.

Not so with "$,R" or "$0,R": In this case, there is no file
specification available (no colon). Thus, the directory commands parses
the command itself and expects the end of the command. However, there is
no, because ",R" was appended.

The ",R" is nowhere documented for the $ command. Thus, in order to be
on the safe side (think about other drives like 1581, CMD), you should
ommit the ",R" for "$". So, IMHO, r5804 is right (in the sense of using
only documented behaviour), and r5805 is wrong.

 
> Does anybody have an "official" guide to what the CBM drives accept? Doing all
> this stuff with try&error is a bit tiring.

More official than the handbook and the ROM code? No.

The 1541/1571 ROM does the following:

When opening a file, $d7b4 handled it.

It checks  the secondary address and jumps to $d7f3 if it is not zero
(not reading). That's wierd. [1]

Then it checks if the file name starts with "*". If not, it jumps to
$d7f3. This is the case if we open the directory, thus, I will proceed
there.

Now, $d7f3 checks if the file name starts with "$". It does, thus, we
proceed at $f7f7, checking the secondary address for 0. If it is not 0
(= reading), it proceeds with processing and avoids the directory
handling.

If it is reading, $f7fc jumps to $da55 which does the actual directory
processing.

Then, it jumps to $da55 which does the real dir-processing.

Here, we check the length of the command:
- Is it 1 (only "$" was given), then we proceed at $da6d.
- Is it 2 ("$x" was given), then we proceed at $da65.
- Is it longer, then we proceed at $da86.

At $da65 (processing of "$x"), it is tested if the second byte is a drive
number ("0" or "1"). If it is not, then we proceed at $da86, thus, we do
the same as for file names that are longer than 2.

Now, we are at $da6d. Thus, we are here ifeither the file name was 1
byte long, or if it was 2 byte long and the second byte was a drive
number.

Now, the code does something interesting: It writes "**" at the
beginning of the command string (yes, TWO asterisk), does some
housekeeping to let the parser start at the beginning of the command
string (instead of where it is already in processing), and jumps to $da90.

$da90 is part of the processing of the longer command strings ($da86 as
mentioned in the "case" above).

So, to make a long story short:

If you would send "$" or "$0" only, then the command would be replaced
by "*" or "**", leading to the dir command finding a string.

The problem with "$,R" is that the command is not recognised as being
send without a filename (because the string is too long). Thus, the
parser expects a filename which is not there. Thus, it cannot find any
file with the speecified name: It returns an empty directory.

An additional artefact when looking at $da86-$da90: The colon is not
really needed. Thus, you can also specify LOAD "$abc*", and it work like
LOAD "$:abc*". However, this will NOT work if the first character is a
"0" or an "1". In this case, you would have to use LOAD "$00*" to do the
equivalent of "LOAD "$0:0*" - weird syntax, isn't it?

Now, why is the ",R" accepted in the first place? For finding the file
to show, the dir command uses the same routine that is used when
searching a file to load ($daa4->$c49d->$c5ab), and the routine to PARSe
the file is also the same ($c398). Thus, preventing the ",R" in the
first place would reuquire additional logic. That's the reason why we
have this undefined (in the sense of "not contractual") behaviour.


> > BTW, I generated new debian packages of r5804. Thus, I am up-to-date
> > again.
> 
> Not really. r5805 is 45 minutes old :-)

Well, at least at the time I wrote that, I thought I was up-todate. ;)

Regards,
Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.