Something like Unix pwd for sd2iec

17 views
Skip to first unread message

Eric Christopherson

unread,
Jun 22, 2016, 3:55:48 PM6/22/16
to uIEC-...@googlegroups.com
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

unread,
Jun 22, 2016, 5:16:55 PM6/22/16
to uIEC-...@googlegroups.com
--
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

unread,
Jun 23, 2016, 3:47:10 PM6/23/16
to uIEC-...@googlegroups.com
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

unread,
Jun 23, 2016, 4:25:51 PM6/23/16
to uIEC-...@googlegroups.com
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

unread,
Jul 31, 2016, 11:08:40 AM7/31/16
to µIEC Users Discussion Group
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

unread,
Jul 31, 2016, 2:36:45 PM7/31/16
to uIEC-...@googlegroups.com
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

unread,
Jul 31, 2016, 2:55:53 PM7/31/16
to uIEC-...@googlegroups.com
--
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.

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

unread,
Jul 31, 2016, 4:40:37 PM7/31/16
to µIEC Users Discussion Group
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:


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

RETRO Innovations

unread,
Aug 1, 2016, 12:14:33 AM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 1, 2016, 1:54:19 AM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 1, 2016, 3:10:54 AM8/1/16
to uIEC-...@googlegroups.com

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

unread,
Aug 1, 2016, 8:32:21 AM8/1/16
to µIEC Users Discussion Group
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

unread,
Aug 1, 2016, 1:37:48 PM8/1/16
to uIEC-...@googlegroups.com
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.

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

Eric Christopherson

unread,
Aug 1, 2016, 2:39:54 PM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 1, 2016, 2:42:48 PM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 1, 2016, 2:51:04 PM8/1/16
to µIEC Users Discussion Group
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

unread,
Aug 1, 2016, 5:03:11 PM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 1, 2016, 6:33:35 PM8/1/16
to uIEC-...@googlegroups.com
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

unread,
Aug 2, 2016, 1:02:57 PM8/2/16
to uIEC-...@googlegroups.com
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

unread,
Aug 5, 2016, 8:17:47 PM8/5/16
to µIEC Users Discussion Group
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)?


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

RETRO Innovations

unread,
Aug 5, 2016, 11:30:28 PM8/5/16
to uIEC-...@googlegroups.com
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?


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.

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

Ingo Korb

unread,
Aug 6, 2016, 7:06:44 AM8/6/16
to uIEC-...@googlegroups.com
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

unread,
Aug 6, 2016, 8:00:35 AM8/6/16
to µIEC Users Discussion Group
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

unread,
Aug 6, 2016, 8:03:16 AM8/6/16
to µIEC Users Discussion Group, m...@akana.de
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

unread,
Aug 6, 2016, 8:17:04 AM8/6/16
to uIEC-...@googlegroups.com
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

unread,
Aug 6, 2016, 9:38:10 AM8/6/16
to µIEC Users Discussion Group, m...@akana.de
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

unread,
Aug 6, 2016, 5:47:04 PM8/6/16
to µIEC Users Discussion Group
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

unread,
Aug 7, 2016, 2:35:07 AM8/7/16
to uIEC-...@googlegroups.com
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.

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

Glenn Holmer

unread,
Aug 7, 2016, 9:28:30 AM8/7/16
to µIEC Users Discussion Group
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

unread,
Aug 7, 2016, 4:45:31 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 6:27:22 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 9:41:27 PM8/7/16
to µIEC Users Discussion Group
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

unread,
Aug 7, 2016, 10:01:27 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 10:01:57 PM8/7/16
to µIEC Users Discussion Group
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

unread,
Aug 7, 2016, 10:05:51 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 10:13:06 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 10:48:38 PM8/7/16
to uIEC-...@googlegroups.com
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

unread,
Aug 7, 2016, 11:00:08 PM8/7/16