Something like Unix pwd for sd2iec

[Eric Christopherson]

Is there something like Unix's pwd in sd2iec devices -- in other words, a DOS command that returns the current partition and directory on the device? If so, does it also work if you're currently in a D64 image?

--

        Eric Christopherson

[RETRO Innovations]

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/CADyB93A2D1%2BAsBT0ZUT8P4qEZvE%2B6HFNDNkaoXNNdJFtOBe2YA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

a 'PWD' like function is not readily available, but it can be created in a few ways:

The 'OS' can hold onto this information, which is easiest.

Or, you can walk the "parent dir" chain to obtain the CWD. 

I'm not sure about Ingo's perspective, but I thought about adding the function, and resisted pursuing it because it will consume significant memory resources (remember, sd2iec has 2-4kB of RAM for all operations), and it could be hard to implement:

Although I have never tested it, the rename directory (r-h or rename header) command can accept absolute paths.  Thus, any PWD text would have to be modified everytime the directory naming was altered.  Not that the 'OS' solution above shares the same issue, but there is more space to deal with it.

I think, given the frequency of use, the 'walk the tree' approach is easiest.

Jim

-- 
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

[Eric Christopherson]

OK. I just discovered each partition has an associated current directory, sort of how drive letters in DOS/Windows do; so I thought the information was available in the uIEC. Is it just that the uIEC has a sort of opaque pointer to the current directory, but it doesn't know the actual path to it?

Also, what happens to files that are open in the Commodore when directory or partition is changed? Do they get closed?

[RETRO Innovations]

On June 23, 2016 at 3:46 PM Eric Christopherson <echrist...@gmail.com> wrote:

OK. I just discovered each partition has an associated current directory, sort of how drive letters in DOS/Windows do; so I thought the information was available in the uIEC. Is it just that the uIEC has a sort of opaque pointer to the current directory, but it doesn't know the actual path to it?

In CMD directories, the directory is laid out similar to a normal 1541 directory, with a "header" name and such.  You guessed it.  sdi2iec holds a pointer to the current directory, and then when you ask for a directory listing, it just finds out the name and the contents at that time.  It has no previous knowledge of the name, except a reference to the current dir

Also, what happens to files that are open in the Commodore when directory or partition is changed? Do they get closed?

changing a directory, just changes the pointer used for relative opens.  So, any open file should continue to work fine.

jim

[Glenn Holmer]

On Thursday, June 23, 2016 at 3:25:51 PM UTC-5, Jim Brain wrote:

In CMD directories, the directory is laid out similar to a normal 1541 directory, with a "header" name and such.  You guessed it.  sdi2iec holds a pointer to the current directory, and then when you ask for a directory listing, it just finds out the name and the contents at that time.  It has no previous knowledge of the name, except a reference to the current dir

What are the mechanics of this? Where is the pointer and what is it a pointer to? How do I get at it? (dir header? G-P command?) I implemented pwd pretty easily as a C64 program for CMD native partitions, but how would I do it on a uIEC? Do I have to navigate the FAT filesystem using DR commands?

[Ingo Korb]

Glenn Holmer <glenn....@gmail.com> writes:

> Where is the pointer and what is it a pointer to?

In a data structure in the microcontroller's RAM

> How do I get at it?

You don't, it is an implementation detail that is deliberately not exposed.

-ik

[RETRO Innovations]

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/b1e5ec22-f82e-4b3f-93ca-e2c015d03aed%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

I think the better approach would be to mimic what worked on the CMD drives.  Can you explain in steps what you did to make PWD work on the CMD drives?  I can then look at adding that into the codebase.  I would not think it would be tough, unless you are using a lot of reserved CMD stuff.

I can't lay claim to much (if any) of sd2iec's codebase, but my name is in there somewhere, and I think it's for the help I provided on CMD directory and partition support.  I'd love to add a bit more support in.

[Glenn Holmer]

On Sunday, July 31, 2016 at 1:55:53 PM UTC-5, Jim Brain wrote:

On 7/31/2016 10:08 AM, Glenn Holmer wrote:

On Thursday, June 23, 2016 at 3:25:51 PM UTC-5, Jim Brain wrote:

In CMD directories, the directory is laid out similar to a normal 1541 directory, with a "header" name and such.  You guessed it.  sdi2iec holds a pointer to the current directory, and then when you ask for a directory listing, it just finds out the name and the contents at that time.  It has no previous knowledge of the name, except a reference to the current dir

What are the mechanics of this? Where is the pointer and what is it a pointer to? How do I get at it? (dir header? G-P command?) I implemented pwd pretty easily as a C64 program for CMD native partitions, but how would I do it on a uIEC? Do I have to navigate the FAT filesystem using DR commands?

I think the better approach would be to mimic what worked on the CMD drives.  Can you explain in steps what you did to make PWD work on the CMD drives?  I can then look at adding that into the codebase.  I would not think it would be tough, unless you are using a lot of reserved CMD stuff.

I can't lay claim to much (if any) of sd2iec's codebase, but my name is in there somewhere, and I think it's for the help I provided on CMD directory and partition support.  I'd love to add a bit more support in.

1) Get directory header by opening "$" as a file with non-zero secondary address. Read 254 bytes (initial track and sector pointer is not returned). 

2) Offset 32/33 is track and sector pointer to parent directory header (see CMD HD manual, Appendix C "Partition and File Formats", subtracting 2).

3) If 0/0, we are at the root. If first time through, return "//"; else add another '/' at the beginning and return full path.

4) Otherwise copy disk name field to end of path buffer: read backward from offset 17 (19 if full sector) until no more shifted spaces, then copy backward through offset 2 (4 if full sector). Add '/' at start of path and set index into path for next copy. 

5) Read track and sector from pointer. Now we have a full sector, so new parent directory track/sector offset is 34/35. Go to step 3.

I implemented this in PROMAL, which is much easier to read than the above:

http://www.lyonlabs.org/temp/

The good stuff is in pwd_main.s and diskutils.s (subroutines).

[RETRO Innovations]

Hmmm

Pulling back a raw track and sector in the FAT subsystem is going to be a challenge, as the filesystem is only emulated at the highest level... 

There's also the problem of reading a raw T&S in a FAT subsystem.

If I get time, I'll see if CMD allows reading "<:$" to get the parent dir header.  That type of walk would be more portable and easier to implement.

Jim

[Eric Christopherson]

On Sun, Jul 31, 2016, RETRO Innovations wrote:
> If I get time, I'll see if CMD allows reading "<:$" to get the parent dir
> header. That type of walk would be more portable and easier to implement.

Where did you get "<:$" from? Does <: exist already in CMD DOS?

--
Eric Christopherson

[RETRO Innovations]

ON a sd2iec and CMD drives, the top left key on the c64/vic/sx/128 KB can be used to go back a dir.

<-

[Glenn Holmer]

On Sunday, July 31, 2016 at 11:14:33 PM UTC-5, Jim Brain wrote:

Pulling back a raw track and sector in the FAT subsystem is going to be a challenge, as the filesystem is only emulated at the highest level...  

There's also the problem of reading a raw T&S in a FAT subsystem.

If I get time, I'll see if CMD allows reading "<:$" to get the parent dir header.  That type of walk would be more portable and easier to implement.

I wouldn't advise entering that combination of characters, as JiffyDOS will interpret it as "save a file named $". You'll have to use wild-card magic to delete it.

OPEN2,12,2,"_:$" (where '_' is the back-arrow) in a BASIC program gives FILE NOT FOUND.

I tried quite a few other combinations of directory commands involving a back-arrow and couldn't get any of them to work. Anybody else?

Outside of the save command, the CMD command reference only mentions the back-arrow key as part of a CD command (and then says "The back arrow cannot be combined with any subdirectory path information.").

[RETRO Innovations]

Hmmm, well, I was hoping for a simple option...  Looks like more thought is needed.

I suspect:

repeat
    dir
    cd<-
until X
print
cd "pwd"

works (not sure what X condition is at present, but should be doable), but it's ugly and it'll unmount an image if you are in an image...

It's a shame <-:$ doesn't do what I expected.

Still thinking.  The good news is that anything (within reason) is possible.  I am just leery of using T&S manipulations, especially in light of the fact that such a setup will lie when when a DNP image (as the root dir of the DNP image will have T&S = 0,0, but it's not root.

I think it is important to get it right, as doing so sets a precedent that allows CBM drive access to accommodate ever larger storage facilities.  The emulation capability that sd2iec provides has become itself a precedent for newer solutions, in my opinion.


Jim

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/8fa798cc-668d-40f1-9f09-21db4f71e6b5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Christopherson]

On Mon, Aug 01, 2016, RETRO Innovations wrote:
> On 8/1/2016 12:54 AM, Eric Christopherson wrote:
> >On Sun, Jul 31, 2016, RETRO Innovations wrote:
> >>If I get time, I'll see if CMD allows reading "<:$" to get the parent dir
> >>header. That type of walk would be more portable and easier to implement.
> >Where did you get "<:$" from? Does <: exist already in CMD DOS?
> >
>
> ON a sd2iec and CMD drives, the top left key on the c64/vic/sx/128 KB can be
> used to go back a dir.
>
>
> <-

Oh, OK. I read that as a less-than sign.

--
Eric Christopherson

[Eric Christopherson]

On Mon, Aug 01, 2016, Glenn Holmer wrote:
> On Sunday, July 31, 2016 at 11:14:33 PM UTC-5, Jim Brain wrote:
> >
> > Pulling back a raw track and sector in the FAT subsystem is going to be a
> > challenge, as the filesystem is only emulated at the highest level...
> >
> > There's also the problem of reading a raw T&S in a FAT subsystem.
> >
> > If I get time, I'll see if CMD allows reading "<:$" to get the parent dir
> > header. That type of walk would be more portable and easier to implement.
> >
>
> I wouldn't advise entering that combination of characters, as JiffyDOS will
> interpret it as "save a file named $". You'll have to use wild-card magic
> to delete it.

I would assume JiffyDOS would only behave that way if that was entered
as an actual command in the BASIC/screen editor mode. JiffyDOS isn't
going to treat left arrow as the save command outside of that context
(e.g. when it's being used as a filename).

> OPEN2,12,2,"_:$" (where '_' is the back-arrow) in a BASIC program gives
> FILE NOT FOUND.
> I tried quite a few other combinations of directory commands involving a
> back-arrow and couldn't get any of them to work. Anybody else?
> Outside of the save command, the CMD command reference only mentions the
> back-arrow key as part of a CD command (and then says "The back arrow
> cannot be combined with any subdirectory path information.").

--
Eric Christopherson

[Glenn Holmer]

On Monday, August 1, 2016 at 12:37:48 PM UTC-5, Jim Brain wrote:

Hmmm, well, I was hoping for a simple option...  Looks like more thought is needed.

I suspect:

repeat
    dir
    cd<-
until X
print
cd "pwd"

works (not sure what X condition is at present, but should be doable), but it's ugly and it'll unmount an image if you are in an image...

[shrug] If it works, it works.  I'll try it later today. BTW, you can tell if you're in an image on the uIEC by using the G-P command; a D64 reports partition type 2 (1541 emulation), &c.

[Ingo Korb]

RETRO Innovations <go4r...@go4retro.com> writes:

> Pulling back a raw track and sector in the FAT subsystem is going to be
> a challenge, as the filesystem is only emulated at the highest level...
>
> There's also the problem of reading a raw T&S in a FAT subsystem.

A similar backwards-walking approach could be used for FAT though - scan
the parent directory for an entry that has the same cluster number of
the current directory, record the name, repeat one level higher until
the current directory is the root.

Of yourse you would need to reverse the individual components to convert
that to a "real" directory string, but that could be handled by filling
a buffer from the end.

A more serious problem is that the maximum length of a path on a FAT
file system can exceed any buffer size you can reasonably account for on
a microcontroller.

Finally, there is the question of handling subdirectories within image
files, i.e. DNP. A similar scan algorithm can easily determine the path
within the disk image, but this leaves out the path to the disk image
itself on the FAT filesystem "outside". I think not returning the path
of the image in this case would be the better option though, because it
keeps the "identity function" of getpwd, cd//, cd<previous_pwd> intact.

-ik

[Eric Christopherson]

On Mon, Aug 01, 2016, Ingo Korb wrote:
> Finally, there is the question of handling subdirectories within image
> files, i.e. DNP.

So images with their own directory hierarchies are supported? How does
the device know when CD<- means "go up within the image" and "go out of
the image"?

> A similar scan algorithm can easily determine the path
> within the disk image, but this leaves out the path to the disk image
> itself on the FAT filesystem "outside". I think not returning the path
> of the image in this case would be the better option though, because it
> keeps the "identity function" of getpwd, cd//, cd<previous_pwd> intact.

I'm not sure I understand what you're saying here. I would read
"identity function" to mean that function which results in no change in
state (especially, in this context, the current directory pointer).
Obviously getpwd wouldn't change it, but cd// would; and I'm not sure if
by previous_pwd you actually mean "previous" as in "most recent one
before the current one" or if you mean the parent of the current one.
And I'm not sure if you mean there's a special syntax for that or not.

--
Eric Christopherson

[Ingo Korb]

Eric Christopherson <echrist...@gmail.com> writes:

> So images with their own directory hierarchies are supported?

Yes

> How does the device know when CD<- means "go up within the image" and
> "go out of the image"?

CD<- leaves the image exactly when you are in the root directory of the
image. Nobody has yet mentioned any troubles with determining if this is
the case.

>> keeps the "identity function" of getpwd, cd//, cd<previous_pwd> intact.
>
> I'm not sure I understand what you're saying here. I would read
> "identity function" to mean that function which results in no change in
> state (especially, in this context, the current directory pointer).
> Obviously getpwd wouldn't change it, but cd// would; and I'm not sure if
> by previous_pwd you actually mean "previous" as in "most recent one
> before the current one" or if you mean the parent of the current one.
> And I'm not sure if you mean there's a special syntax for that or not.

I mean exactly this sequence that I mentioned in abbreviated form:

old_pwd = getpwd()
cd//
cd old_pwd

Assuming that getpwd does not fail (e.g. due to a too-long path) and
there are no disk/filesystem errors, my "reasonable expectation" of this
sequence would be that you are in the same directory that you started
in.

-ik

[Glenn Holmer]

On Monday, August 1, 2016 at 12:37:48 PM UTC-5, Jim Brain wrote:

I suspect:

repeat
    dir
    cd<-
until X
print
cd "pwd"

works (not sure what X condition is at present, but should be doable), but it's ugly and it'll unmount an image if you are in an image...

Yeah, that works:

while true

    get dir header

    cd<-

    if err=62 (file not found)

        if first time through

            path="//"

            return (don't have to CD at the end)

        else

            add a '/' to the beginning of the path

            break

    else

        add current dir to beginning of path from dir header

[end while]

CD to path to return to it

Interestingly, you can't use the same method on a CMD HD and an sd2iec/uIEC because:

a) CMD HD has parent dir pointers and sd2iec/uIEC doesn't

b) sd2iec/uIEC returns 62 (file not found) if you issue cd<- at the root but CMD HD doesn't (!)

As for images, I don't think it's worth trying to do pwd for them. On a CMD HD, you're at the root by definition if you're in an emulation partition, and on an sd2iec/uIEC, I don't think there's a way to get the filename of a mounted disk image anyway (is there)?

http://www.lyonlabs.org/promal-pwd-sd.png

http://www.lyonlabs.org/promal-pwd-cmd.png

I'll be showing the code (in PROMAL) at VCFMW next month.

[RETRO Innovations]

If I understand correctly, You can't use the CMD DOS method on sd2iec due to a,

b) sd2iec/uIEC returns 62 (file not found) if you issue cd<- at the root but CMD HD doesn't (!)

And, you can't do my method on CMD DOS because of b...

As for images, I don't think it's worth trying to do pwd for them. On a CMD HD, you're at the root by definition if you're in an emulation partition, and on an sd2iec/uIEC, I don't think there's a way to get the filename of a mounted disk image anyway (is there)?

Well, I would assume that if you have the image mounted, your CMD HD version of code should work...  Did you try?

http://www.lyonlabs.org/promal-pwd-sd.png

http://www.lyonlabs.org/promal-pwd-cmd.png

I'll be showing the code (in PROMAL) at VCFMW next month.

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/9beaebc7-59b2-4b0d-b653-665ce560597c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ingo Korb]

Glenn Holmer <glenn....@gmail.com> writes:

> Interestingly, you can't use the same method on a CMD HD and an sd2iec/uIEC
> because:
> a) CMD HD has parent dir pointers and sd2iec/uIEC doesn't

How do you access the parent dir pointers on a CMD HD?

-ik

[Glenn Holmer]

On Friday, August 5, 2016 at 10:30:28 PM UTC-5, Jim Brain wrote:

Well, I would assume that if you have the image mounted, your CMD HD version of code should work...  Did you try?

I don't understand what you're saying here. 

[Glenn Holmer]

On Saturday, August 6, 2016 at 6:06:44 AM UTC-5, Ingo Korb wrote:

How do you access the parent dir pointers on a CMD HD?  

It's in an earlier post from me on this thread. See CMD HD manual, Appendix C "Partition and File Formats".

[Ingo Korb]

Ah, so there actually is no official way to access them and you instead
resort to parsing the low-level disk layout yourself. You can do that
with a FAT disk too if you want to, sd2iec has commands to directly read
and write sectors on the SD card.

-ik

[Glenn Holmer]

On Saturday, August 6, 2016 at 7:17:04 AM UTC-5, Ingo Korb wrote:

Glenn Holmer <glenn....@gmail.com> writes:

> On Saturday, August 6, 2016 at 6:06:44 AM UTC-5, Ingo Korb wrote:
>>
>> How do you access the parent dir pointers on a CMD HD?  
>>
> It's in an earlier post from me on this thread. See CMD HD manual, Appendix
> C "Partition and File Formats".

Ah, so there actually is no official way to access them and you instead
resort to parsing the low-level disk layout yourself.

Not sure what you mean by "no official way"; it's documented in the CMD HD manual, just like the directory structure of a 1541 is documented in the 1541 manual.

 

You can do that
with a FAT disk too if you want to, sd2iec has commands to directly read
and write sectors on the SD card.

 

Well, I asked about that early in this thread:

What are the mechanics of this? Where is the pointer and what is it a pointer to? How do I get at it? (dir header? G-P command?) ... Do I have to navigate the FAT filesystem using DR commands?

In any case, I think we're beating a dead horse here. I've got something that works, and adding code to read a FAT filesystem in a utility meant to run on a C64 seems like overkill (although it would certainly be interesting, e.g. Big Blue Reader and WCOPY obviously can).

[Greg King]

On Friday, August 5, 2016 at 11:30:28 PM UTC-4, Jim Brain wrote:

On 8/5/2016 7:17 PM, Glenn Holmer wrote:

As for images, I don't think it's worth trying to do pwd for them. On a CMD HD, you're at the root by definition if you're in an emulation partition; and, in sd2iec, I don't think there's a way to get the filename of a mounted disk image, anyway (is there)?

Well, I would assume that if you have the image mounted, your CMD HD version of code should work.  Did you try?

Glen was talking about the name that is used to mount the image; that is, the name that's stored on the FAT file-system.

Where CBM-compatible file-systems are concerned, a subdirectory's file-name and its header-name are independent objects.  There is no guarantee that they will match each other.

[RETRO Innovations]

On 8/6/2016 4:47 PM, Greg King wrote:

On Friday, August 5, 2016 at 11:30:28 PM UTC-4, Jim Brain wrote:

On 8/5/2016 7:17 PM, Glenn Holmer wrote:

As for images, I don't think it's worth trying to do pwd for them. On a CMD HD, you're at the root by definition if you're in an emulation partition; and, in sd2iec, I don't think there's a way to get the filename of a mounted disk image, anyway (is there)?

Well, I would assume that if you have the image mounted, your CMD HD version of code should work.  Did you try?

Glen was talking about the name that is used to mount the image; that is, the name that's stored on the FAT file-system.

Ah, I did not understand.  Still, I'd like to see if his original CMD code will work if he's in an image.

It does seem like a thing that should be supported. 

Where CBM-compatible file-systems are concerned, a subdirectory's file-name and its header-name are independent objects.  There is no guarantee that they will match each other.

Correct, and no more true than in an image.  the image name has no bearing on the dir header name in the image.

Jim

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/ab1169d1-94f0-451a-9994-175f375dc96b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Glenn Holmer]

On Sunday, August 7, 2016 at 1:35:07 AM UTC-5, Jim Brain wrote:

Ah, I did not understand.  Still, I'd like to see if his original CMD code will work if he's in an image.

I still don't understand what you're saying. The "CMD method" involves reading the parent directory track/sector pointer from the current directory header. Where is that pointer in a D64 image? or a DNP image, for that matter?

[RETRO Innovations]

I guess I'll dig into the code, but when you are in an image, I thought the code returns the directory data just like it would in a real unit.  So, if you were in:

/jim/dir/to/dnp/image/glenn.dnp

and inside the image, you were in:

/path/to/file/within/dnp/c64.prg

If you were in the "within" directory, you should be able to use your code to pull the dir, walk the T&S to get back to "path", which would contain a T&S of 0,0, which means your code would stop and think it was at the root.

If that does not work, I think a first step would be to make it work (in the firmware, not in your code).  It will cause no harm to do so. It won't solve the issue per se, but it will get us closer and offer more compatibility.

Jim

[Glenn Holmer]

On Sun, Aug 7, 2016 at 3:45 PM, RETRO Innovations <go4r...@go4retro.com> wrote:

So, if you were in:

/jim/dir/to/dnp/image/glenn.dnp

and inside the image, you were in:

/path/to/file/within/dnp/c64.prg

If you were in the "within" directory, you should be able to use your code to pull the dir, walk the T&S to get back to "path", which would contain a T&S of 0,0, which means your code would stop and think it was at the root.

Oh, you're talking about within a DNP image.

There's ​still a fly in the ointment: you have to look at what type of device you're on to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside e.g. a D64/D81 image by checking the partition type returned from the G-P command, which is reported as a 1541/1581 emulation partition (à la CMD). But a DNP image reports itself as a native partition, just as a root FAT partition does, so there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g. "CMD native emulation"), with a new numeric entry in the table.

Commenting out the device type check and running the pwd program within //SUBDIR1/SUBDIR2 inside a DNP image on a uIEC shows the path correctly, as you'd expect.

[Greg King]

On Sunday, August 7, 2016 at 6:27:22 PM UTC-4, Glenn Holmer wrote:

There's ​still a fly in the ointment:  You have to look at what type of device you're on, to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside, e.g., a D64/D81 image by checking the partition type returned from the "G-P" command, which is reported as a 1541/1581 emulation partition (à la CMD). But, a DNP image reports itself as a native partition, just as a root FAT partition does; so, there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g., "CMD native emulation"), with a new numeric entry in the table.

Commenting out the device type check and running the pwd program within //SUBDIR1/SUBDIR2 inside a DNP image on a uIEC shows the path correctly, as you'd expect.

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.  Unfortunately, sd2iec has a bug in it:  It uses the same format code for FAT that is used for the 1541 format!  I ask Ingo (or Jim) to change FAT's format code from "a" to something like "f".  (Also, the version number in the directory header should be either "0" or "1".)  (I can't remember if I've mentioned it before -- it's been on my mind for many years.)

In any case, DNP's format is "h".  So, there already is no confusion there.

[RETRO Innovations]

On 8/7/2016 5:27 PM, Glenn Holmer wrote:

On Sun, Aug 7, 2016 at 3:45 PM, RETRO Innovations <go4r...@go4retro.com> wrote:

So, if you were in:

/jim/dir/to/dnp/image/glenn.dnp

and inside the image, you were in:

/path/to/file/within/dnp/c64.prg

If you were in the "within" directory, you should be able to use your code to pull the dir, walk the T&S to get back to "path", which would contain a T&S of 0,0, which means your code would stop and think it was at the root.

Oh, you're talking about within a DNP image.

There's ​still a fly in the ointment: you have to look at what type of device you're on to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside e.g. a D64/D81 image by checking the partition type returned from the G-P command, which is reported as a 1541/1581 emulation partition (à la CMD). But a DNP image reports itself as a native partition, just as a root FAT partition does, so there's nothing to tell you to use the "CMD method".

I think the FAT partition should maybe report itself differently... NAT is CMD NATIVE, so perhaps there are other options.  Maybe another variant of G-P that provides additional information?

The only way this would work is if a DNP image reported itself as a different partition type (e.g. "CMD native emulation"), with a new numeric entry in the table.

I'm not opposed to it.

Commenting out the device type check and running the pwd program within //SUBDIR1/SUBDIR2 inside a DNP image on a uIEC shows the path correctly, as you'd expect.

Cool.  Well, that's a good thing.

Jim

[Greg King]

Oops, I should have said, "the BASIC-format directory listing" when I wrote about the version number.

Also, I will take this opportunity to say that this thread shows another reason why sd2iec should keep the "$"-as-SEQ-file feature.

[RETRO Innovations]

Hmm, if you have, I missed it.

I'm leery of using f for FAT, because if you had a different FS for the container, F might not be best. 

In any case, DNP's format is "h".  So, there already is no confusion there.

I think C = Container might be best...  That would work regardless of FS type (FLASH, EEPROM, etc.)

Glenn, let's plan to do some hacking at VCF-MW.  I always have more time for these types of things at the show, and I think there is a way to make this happen... 

Jim

[RETRO Innovations]

On 8/7/2016 9:01 PM, Greg King wrote:

Also, I will take this opportunity to say that this thread shows another reason why sd2iec should keep the "$"-as-SEQ-file feature.

Did we lose it?

[Glenn Holmer]

On Sun, Aug 7, 2016 at 9:01 PM, Greg King <greg....@verizon.net> wrote:

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.

​Not reliable; clever programs (like demo disks) might overwrite it. Besides, if it's been wrong for years and it's fixed, it will take years for the fix to propagate.

--

Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

[RETRO Innovations]

On 8/7/2016 9:48 PM, Glenn Holmer wrote:

On Sun, Aug 7, 2016 at 9:01 PM, Greg King <greg....@verizon.net> wrote:

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.

​Not reliable; clever programs (like demo disks) might overwrite it. Besides, if it's been wrong for years and it's fixed, it will take years for the fix to propagate.

Is there a way to get the same value from the PRG open? 

Also, I would not worry about the latter case.  The upgrade is trivial, and your app alone could be the reason people upgrade.

Jim

--

Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/CAK4PH5Auk-y4ujvHJ25pPEe2pLyT5hAWB%3Dgbds92kpFyYcxCEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Greg King]

On Sunday, August 7, 2016 at 10:05:51 PM UTC-4, Jim Brain wrote:

On 8/7/2016 8:41 PM, Greg King wrote:

On Sunday, August 7, 2016 at 6:27:22 PM UTC-4, Glenn Holmer wrote:

There's ​still a fly in the ointment:  You have to look at what type of device you're on, to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside, e.g., a D64/D81 image by checking the partition type returned from the "G-P" command, which is reported as a 1541/1581 emulation partition (à la CMD). But, a DNP image reports itself as a native partition, just as a root FAT partition does; so, there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g., "CMD native emulation"), with a new numeric entry in the table.

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.  Unfortunately, sd2iec has a bug in it:  It uses the same format code for FAT that is used for the 1541 format!  I ask Ingo (or Jim) to change FAT's format code from "a" to something like "f".  (Also, the version number in the directory header should be either "0" or "1".)  (I can't remember if I've mentioned it before -- it's been on my mind for many years.)

Hmm, if you have, I missed it.

I'm leery of using "f" for FAT, because if you had a different FS for the container, "F" might not be best.

That's the point.  If we have a different container file-system, then reading the directory should see some other format code.  Each "unique" FS should have its own unique format code that identifies it.

In any case, DNP's format code is "h".  So, there already is no confusion there.

I think C= Container might be best.  That would work regardless of FS type (FLASH, EEPROM, etc.).

 

Those are media types, not file-system types.

[Greg King]

No.  But, Ingo had wondered if anybody actually used that feature.  He had thought about removing it from sd2iec (to make room in the ROM for new features).

[Greg King]

On Sunday, August 7, 2016 at 11:00:08 PM UTC-4, Jim Brain wrote:

On 8/7/2016 9:48 PM, Glenn Holmer wrote:

On Sun, Aug 7, 2016 at 9:01 PM, Greg King <greg....@verizon.net> wrote:

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.

​Not reliable; clever programs (like demo disks) might overwrite it. Besides, if it's been wrong for years and it's fixed, it will take years for the fix to propagate.

Is there a way to get the same value from the PRG open?

Yes and no.  CBM-compatible directory headers have two copies of that code.  The very first byte in the header is the official one.  The second one is near the header name -- it's a decoration for the PRG-format listing.

But, Glenn is correct.  I had forgotten that people sometimes change them.  A disk can be "write-protected" by making the official byte lie about the format.  And, coders often change the other one when they want to make the directory listing show a "picture".

[RETRO Innovations]

On 8/7/2016 10:52 PM, Greg King wrote:

On Sunday, August 7, 2016 at 10:05:51 PM UTC-4, Jim Brain wrote:

On 8/7/2016 8:41 PM, Greg King wrote:

On Sunday, August 7, 2016 at 6:27:22 PM UTC-4, Glenn Holmer wrote:

There's ​still a fly in the ointment:  You have to look at what type of device you're on, to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside, e.g., a D64/D81 image by checking the partition type returned from the "G-P" command, which is reported as a 1541/1581 emulation partition (à la CMD). But, a DNP image reports itself as a native partition, just as a root FAT partition does; so, there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g., "CMD native emulation"), with a new numeric entry in the table.

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.  Unfortunately, sd2iec has a bug in it:  It uses the same format code for FAT that is used for the 1541 format!  I ask Ingo (or Jim) to change FAT's format code from "a" to something like "f".  (Also, the version number in the directory header should be either "0" or "1".)  (I can't remember if I've mentioned it before -- it's been on my mind for many years.)

Hmm, if you have, I missed it.

I'm leery of using "f" for FAT, because if you had a different FS for the container, "F" might not be best.

That's the point.  If we have a different container file-system, then reading the directory should see some other format code.  Each "unique" FS should have its own unique format code that identifies it.

I disagree.  The FAT FS is very agnostic as it is:

• >16MB partition size
• support for all normal CBM file types (PRG, SEQ,REL)
  
• no file size limit

So, I think it should suffice as a general purpose container.  Writing different code for type=F (FAT), type= E (EEPROM) and type = L? (FLASH) is triple the work, and I don't think that's the direction we should go.  Create a virtual "perfect" FS and make FAT mold to it.

Jim

[Greg King]

On Sunday, August 7, 2016 at 6:27:22 PM UTC-4, Glenn Holmer wrote:

There's ​still a fly in the ointment: you have to look at what type of device you're on, to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside, e.g., a D64/D81 image by checking the partition type returned from the G-P command, which is reported as a 1541/1581 emulation partition (à la CMD). But, a DNP image reports itself as a native partition, just as a root FAT partition does; so, there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g., "CMD native emulation"), with a new numeric entry in the table.

Shouldn't that be the other way around?  sd2iec is the newer DOS; therefore, its partition type should have the new number in the table.

[Greg King]

On Monday, August 8, 2016 at 12:30:47 AM UTC-4, Jim Brain wrote:

On 8/7/2016 10:52 PM, Greg King wrote:

On Sunday, August 7, 2016 at 10:05:51 PM UTC-4, Jim Brain wrote:

On 8/7/2016 8:41 PM, Greg King wrote:

On Sunday, August 7, 2016 at 6:27:22 PM UTC-4, Glenn Holmer wrote:

There's ​still a fly in the ointment:  You have to look at what type of device you're on, to decide whether to use the "CMD method" or the "CD<- method". If you're on an sd2iec/uIEC, you then have to know that you're inside a DNP image to trigger the switch to the "CMD method". You can tell if you're inside, e.g., a D64/D81 image by checking the partition type returned from the "G-P" command, which is reported as a 1541/1581 emulation partition (à la CMD). But, a DNP image reports itself as a native partition, just as a root FAT partition does; so, there's nothing to tell you to use the "CMD method". The only way this would work is if a DNP image reported itself as a different partition type (e.g., "CMD native emulation"), with a new numeric entry in the table.

You don't need to use the "G-P" command; the format code should be able to tell a program what it needs to know.  Unfortunately, sd2iec has a bug in it:  It uses the same format code for FAT that is used for the 1541 format!  I ask Ingo (or Jim) to change FAT's format code from "a" to something like "f".  (Also, the version number in the directory header should be either "0" or "1".)  (I can't remember if I've mentioned it before -- it's been on my mind for many years.)

Hmm, if you have, I missed it.

I'm leery of using "f" for FAT, because if you had a different FS for the container, "F" might not be best.

That's the point.  If we have a different container file-system, then reading the directory should see some other format code.  Each "unique" FS should have its own unique format code that identifies it.

I disagree.  The FAT FS is very agnostic, as it is:

• >16MB partition size
• support for all normal CBM file types (PRG, SEQ, REL)
  

• no file-size limit

So, I think it should suffice as a general-purpose container.  Writing different code for type=F (FAT), type= E (EEPROM) and type = L? (FLASH) is triple the work, and I don't think that's the direction we should go.  Create a virtual "perfect" FS; and, make FAT mold to it.

But, CBM and CMD File-systems aren't agnostic!  They do have size limits!  That is why the FAT, EEPROM, and FLASH (or, your virtual FS) needs a format code that isn't the same as the codes of CBM and CMD FSes!  sd2iec's FSes need their own format code for the same reason that each of the CBM/CMD formats has its own code.

CBM/CMD and sd2iec's FSes are different; programs shouldn't be tricked into thinking that they are similar.  Suppose a program wants to read a directory, and remember the names, so that it can show a scrolling menu.  We don't want that program to think that a FAT FS's maximum directory length is 144 names!  Programs that do low-level things need to know specific details about the formats where they will be working.  The format code can tell them which details to consult.

One of sd2iec's great selling points is its backward-compatibility.  New programs might know about CMD and sd2iec; they might know about the "G-P" DOS command.  But, old programs don't know.  They will use the old method of looking at format codes.  sd2iec should support that 100% -- and, it should be accurate.  It shouldn't pretend that its advanced FSes are an old-fashioned CBM FS.  All programs should be able to tell when they are in a mounted image file, and when they are outside of image files (assuming that they need to know it) -- even if those programs are so old that they don't know that image files exist (when outside, they should see a format code that they don't recognize).

It might not matter whether sd2iec's advanced FSes have different format codes from each other, or share the same code.  What is important is that they don't have any code that was chosen by CBM or CMD (or Kajtar Zsolt, he chose "i" for IDE64).

[Glenn Holmer]

​I'm not against changing the partition type for a "native" FAT partition (although the change would be intrusive), but the partition type reported from within a DNP image should definitely not be "CMD native". It fits the pattern:

D64 reports itself as 1541 emulation partition​

D71 reports itself as 1571 emulation partition​

D81 reports itself as 1581 emulation partition​

​DNP should report itself as an emulation partition as well, since it is *not* a CMD native partition. This would avoid having to run device-type detection, then checking the partition type, then deciding that if I'm on an SD device and got a result of "CMD native", it's not really CMD native after all (and you only need to know this on an SD device, so you can use the "CMD method" instead of the "CD<- method" to get the working directory).

​I'm not sure anyone's asked this question: does anyone actually use DNP images on an sd2iec/uIEC? I don't see the point, when you have excellent subdirectory support in the native FAT partition. It's been my impression that DNP images are used mainly with VICE.

[silv...@wfmh.org.pl]

> On 2016-08-06, at 15:38, Glenn Holmer <glenn....@gmail.com> wrote:
>
> On Saturday, August 6, 2016 at 7:17:04 AM UTC-5, Ingo Korb wrote:
> Glenn Holmer <glenn....@gmail.com> writes:
>
> > On Saturday, August 6, 2016 at 6:06:44 AM UTC-5, Ingo Korb wrote:
> >>
> >> How do you access the parent dir pointers on a CMD HD?
> >>
> > It's in an earlier post from me on this thread. See CMD HD manual, Appendix
> > C "Partition and File Formats".
>
> Ah, so there actually is no official way to access them and you instead
> resort to parsing the low-level disk layout yourself.
>
> Not sure what you mean by "no official way"; it's documented in the CMD HD manual, just like the directory structure of a 1541 is documented in the 1541 manual.

An official way is the one documented by the vendor. One can do many things by referring to low level, filesystem structures. You can for example read directory this way. This doesn't make it an official way of reading directory. For reading directory there is another, official method provided and documented. One that - BTW - works across the whole range of underlying filesystems, formats and devices and doesn't depend on any particular one.

--
SD!

[RETRO Innovations]

On August 8, 2016 at 4:23 AM Greg King <greg....@verizon.net> wrote:

On Monday, August 8, 2016 at 12:30:47 AM UTC-4, Jim Brain wrote:

On 8/7/2016 10:52 PM, Greg King wrote:

That's the point.  If we have a different container file-system, then reading the directory should see some other format code.  Each "unique" FS should have its own unique format code that identifies it.

I disagree.  The FAT FS is very agnostic, as it is:

• >16MB partition size
• support for all normal CBM file types (PRG, SEQ, REL)
  
• no file-size limit

So, I think it should suffice as a general-purpose container.  Writing different code for type=F (FAT), type= E (EEPROM) and type = L? (FLASH) is triple the work, and I don't think that's the direction we should go.  Create a virtual "perfect" FS; and, make FAT mold to it.

But, CBM and CMD File-systems aren't agnostic!  They do have size limits!  That is why the FAT, EEPROM, and FLASH (or, your virtual FS) needs a format code that isn't the same as the codes of CBM and CMD FSes!  sd2iec's FSes need their own format code for the same reason that each of the CBM/CMD formats has its own code.

I agree.  All I am saying is that I don't want to create new codes for all the various formats from this point forward.  I want to create one new format that all of the media types will implement.

It might not matter whether sd2iec's advanced FSes have different format codes from each other, or share the same code.  What is important is that they don't have any code that was chosen by CBM or CMD (or Kajtar Zsolt, he chose "i" for IDE64).

I don't think I was suggesting otherwise.  I am just asking that we choose 1 for the container FS (FAT, EEPROM, FLASH, etc.) and specify that this format supports

• Infinite size
• Ability to load all standard CBM file types
• File protection support
• Time and Date stamping
• 16 byte filenames
• I am sure there are others, but the list is already extensive.

However, this virtual format does not support:

• T&S access
• Underlying access to raw file system (B-R, B-W and friends)

Jim

[RETRO Innovations]

On August 8, 2016 at 9:07 AM Glenn Holmer <glenn....@gmail.com> wrote:

​I'm not against changing the partition type for a "native" FAT partition (although the change would be intrusive), but the partition type reported from within a DNP image should definitely not be "CMD native". It fits the pattern:

D64 reports itself as 1541 emulation partition​

D71 reports itself as 1571 emulation partition​

D81 reports itself as 1581 emulation partition​

​DNP should report itself as an emulation partition as well, since it is *not* a CMD native partition.

Can't we just say that NAT is a CMD Native emulation partition?

This would avoid having to run device-type detection, then checking the partition type, then deciding that if I'm on an SD device and got a result of "CMD native", it's not really CMD native after all (and you only need to know this on an SD device, so you can use the "CMD method" instead of the "CD<- method" to get the working directory).

Or, maybe we just need to improve compatibility.

I'm not sure anyone's asked this question: does anyone actually use DNP images on an sd2iec/uIEC? I don't see the point, when you have excellent subdirectory support in the native FAT partition. It's been my impression that DNP images are used mainly with VICE.

DNP images serve a great purpose in that they offer a T&S capable FS for apps that need true random access.  We can't really offer that in the root FS.

Jim

[David Witmer]

I use the DNP partitions for Wheels as a bootable partition. I also use DNP partitions to back up my CMD hard drive partitions in an equal sized partition.

[Eric Christopherson]

On Mon, Aug 8, 2016 at 10:11 AM, RETRO Innovations <go4r...@go4retro.com> wrote:

I don't think I was suggesting otherwise.  I am just asking that we choose 1 for the container FS (FAT, EEPROM, FLASH, etc.) and specify that this format supports

• Infinite size
• Ability to load all standard CBM file types
• File protection support
• Time and Date stamping
• 16 byte filenames
• I am sure there are others, but the list is already extensive.

Would it be possible to have >16-byte filenames? I'm thinking of how VICE seems to present arbitrary-long filenames to the emulated machine when it's using a host directory as virtual disk. I would think there would be some hard and fast size limits in the Kernal, BASIC, or DOS that would prevent this, but somehow they seemed to manage it. (But then individual programs might balk at attempts to enter more than 16 characters).

Speaking of that, but slightly OT, I've been wondering: what is the maximum line length of a JiffyDOS wedge command (e.g. the % character plus the whole pathname)? Is it less than the maximum screen editor/BASIC logical line? And also, what's the maximum filename length (or command string, in the case of routines like OPEN15,8,15,"foo...") in the Kernal?

--

        Eric Christopherson

[Ingo Korb]

Eric Christopherson <echrist...@gmail.com> writes:

> Would it be possible to have >16-byte filenames?

Currently not, the limit is quite deepy ingrained into the code of
sd2iec. Extending it would increase the size of quite a few critical
data structures, while the code would still need to be able to run on
microcontrollers with just 8K of RAM.

Additionally, something would need to be done about duplicates when the
file names are truncated to 16 characters in raw directories ($ with
secondary != 0). The name field in those cannot be made longer without
breaking existing programs that parse it.

-ik

[Greg King]

On Monday, August 8, 2016 at 11:11:57 AM UTC-4, Jim Brain wrote:

On August 8, 2016 at 4:23 AM Greg King wrote:

It might not matter whether sd2iec's advanced FSes have different format codes from each other, or share the same code.  What is important is that they don't have any code that was chosen by CBM or CMD (or Kajtar Zsolt, he chose "i" for IDE64).

I don't think I was suggesting otherwise.  I am just asking that we choose 1 for the container FS (FAT, EEPROM, FLASH, etc.); and, specify that this format supports:

• Infinite size
• Ability to load all standard CBM file-types

• File protection support
• Time and Date stamping

• 16-byte filenames
• I am sure there are others; but, the list is already extensive.

However, this virtual format does not support:

• T&S access
• Underlying access to raw file system (B-R, B-W, and friends)
  

That makes sense to me.

[Eric Christopherson]

Interesting. I didn't know about raw directories (or I had forgotten).
What's this thing about loading "$" as a SEQ file?

--
Eric Christopherson

[gregor...@gmail.com]

I am super new to this group. And I've been away from the C= world for several years, but I've been back for 7 or 8 months.

I'm working on an OS, for my personal reasons, because I like OSes, and I want a base of code from which I can build apps that interest me. In the process I'm implementing/porting code for all kinds of purposes. I've most recently been pestering all the guys in c64friends IRC about serial bus drive detection. And expanding it to support IDE64, and SD2IEC. And whatever else is out there.

I only recently even discovered that SD2IEC can even mount disk images! I was very happy to make that discovery. 

I'm now of course interested in how to implement PWD. And Glenn's promal code is the closest I've come to a fully thought out solution. But, it occurs to me that manually figuring out the PWD on the fly is not as important inside an OS as I originally suspected. The initial starting directory is important to know, but if it's inside a known system folder, it can just be defined and read from a config file. After that, as the user uses the OS to navigate the file system, the OS merely needs to keep track of where the user has gone as he goes there.

The main trick is updating the path of currently tracked files when the user changes a directory name. My thoughts are that I will have structures that hold the device number, partition number, path and filename for every file the user cares to have access to. Before saving over a file previously read from, in say a text editor, the OS will use the partition info to change the default partition first. Then use the path info to change the default path. Then do an open with the filename from that relative location.

If a directory gets renamed by the user, though, while the OS is holding onto various structures that have a path that contains the directory being renamed, they would have to be updated at that time. Not too hard though for the OS's file system handling code to do.

The beauty is that it just eliminates all need to brute traverse a path in reverse to figure out where you are.

Greg.

On Friday, August 5, 2016 at 8:17:47 PM UTC-4, Glenn Holmer wrote:

On Monday, August 1, 2016 at 12:37:48 PM UTC-5, Jim Brain wrote:

I suspect:

repeat
    dir
    cd<-
until X
print
cd "pwd"

works (not sure what X condition is at present, but should be doable), but it's ugly and it'll unmount an image if you are in an image...

Yeah, that works:

while true

    get dir header

    cd<-

    if err=62 (file not found)

        if first time through

            path="//"

            return (don't have to CD at the end)

        else

            add a '/' to the beginning of the path

            break

    else

        add current dir to beginning of path from dir header

[end while]

CD to path to return to it

Interestingly, you can't use the same method on a CMD HD and an sd2iec/uIEC because:

a) CMD HD has parent dir pointers and sd2iec/uIEC doesn't

b) sd2iec/uIEC returns 62 (file not found) if you issue cd<- at the root but CMD HD doesn't (!)

As for images, I don't think it's worth trying to do pwd for them. On a CMD HD, you're at the root by definition if you're in an emulation partition, and on an sd2iec/uIEC, I don't think there's a way to get the filename of a mounted disk image anyway (is there)?

http://www.lyonlabs.org/promal-pwd-sd.png

http://www.lyonlabs.org/promal-pwd-cmd.png

I'll be showing the code (in PROMAL) at VCFMW next month.