Commander X16

This basic premise can be applied to any multi process development effort... like a suite of applications that edit and compile code. Then when the code is compiled, you just run it from the same shell.

Daedalus wrote: ↑Sat Jul 22, 2023 11:50 pm I noted that in BASIC, the DOS calls just shortened the path to 16 characters. Well, that happens here, too.

As far as I can find, the ROM keeps a 256-byte buffer to read filename strings and command channel strings into, and the emulator keeps an 80-byte buffer.

If there's any truncation that takes place, it must be either in BASIC or the Kernal, because the actual DOS code doesn't do it as far as I can tell, but I haven't looked at absolutely everything just yet

Another detail that you can't see here is that there are only 2 "file types" reported, DIR and PRG.

I can confirm that Commander-DOS assumes every file is a program file. That might change in the future, but it's what it does right now.

The path truncation must be in the code that creates (or emulates.) the CD return data. Note that each directory contains 10 blocks. I expect that those blocks contain each hop of the path all the way from the file name back to root. One hop per block. But I probably won't know that for certain until I more fully unwind the system. So the data's all there, at the very least in a private 255 byte string somewhere.

In the grand scheme of things, so long as the data is "actually there" is what matters. There is only a dinky 80 columns by a max of 60 rows to display it in (I use 80 by 30, as I prefer an 8 by 16 font to better resolve upper and lower case characters.) So really... how much of a ginormous path would you even be able to show?

I might've misunderstood you originally; I see now that the CWD gets truncated to 16 characters when printing it out with "$", but if you ever need it, "$=C" will list out the names of each subdirectory you're in. I was thinking you meant that the commands themselves, or the filenames themselves got truncated in, e.g., the OPEN commands, because I've heard others mention that around here too.

Here's the stuff I've tried just now: Really long paths work, both the documented and undocumented forms of specifying paths work (except the CD command, which is forced to be "CD:" in the emulator), and doing the "$" listing is where I noticed the 16-character truncation in the CWD, but also what "$=C" gives, which can be a way to reconstruct the CWD if needed.

EDIT: And I tested just now, if a subdirectory's name is super super long, "$=C" will still print the whole name.

Right! The data's there, it's just stretched out among the blocks in the directory list for $=C

What I may do is open the $=C list, then if the data is more than 32 characters total, (Requiring the subdirectories to be concatenated.) show the data from the tail in, rather than the root out.

I want the displayed path to not block out the sun, as it were. There needs to be room on the line for the user to enter their command.

Edited to add: What I was doing earlier was opening $=C, then only looking at the first entry... ASSUMING that it was the entire path. When I realized earlier today that it was truncated to 16 chars, I tested it (Shown in one of the screen shots on page 5) proving that the data was there, just truncated for the display. Your screenshot proves that the data is indeed spread out in the 10 blocks of the file itself. But... what happens if there are more than 10 hops? Meh. It's a computer with a 64K addressing limit. There have to be limits. 10 seems generous.

Ok. Using the "Working with DOS" docs, I was able to figure out changing to a directory(CD), making a directory(MD), deleting a directory(RD), deleting a file(S), and rename a file(R)

But I cannot figure out how to copy a file from one place to another.

The docs say to use: C[path_a]:target_name=[path_b]:source_name[,...] but all I ever get is SYNTAX ERROR. I made a "cmd" command so that I can type whatever crazy stuff I can think of and inject it directly the command channel so I can try bizarre variants of the possible syntax.

I tried it on the BASIC screen using DOS too. I can't get anything to work.

It looks like copying isn't implemented in the emulator's hostfs just yet. I had to look at the emulator's source code to figure that out.

At this rate, you might have better luck mounting an SD card image in the emulator, since that bypasses the whole hostfs system and goes through the ROM instead.

Ah. That would do it.

I have considered using the whole "sdcard image" route many times. I can make as sdcard image and stuff it with files easily enough, but I like having the files actually be in the computer's file system directly, not as a simulation of a file system trapped in a file. I.E. I don't want to have to keep mounting and unmounting the "sdcard" file to move stuff to it.

I'll just leave this feature unimplemented.

So. I thought about it, and realized my apparent aversion to using the sdcard image switch was probably not founded in reality. My biggest problem was that I have a bad habit of putting the project's development files right there where the host fs is... It seemed like a good idea at the time.

So I split it between "dev" and "runtime", with only the files that need to be in runtime being copied over when a compile is made. Then runtime has the mounted fs that's in the sdcard image. All I need to do to init it is run a script once after I turn my computer on (I don't leave my computers on 24 / 7.) When I shut it off, it's automatically unmounted. Between then, when I compile, the make file loads in the required files to the runtime directories in the mounted fs. I like it. It's fast and easy.

The good part is this really gives me as close to the "full hardware experience" as I can get without actual hardware, and it really is different. There are a lot of differences because of the emulator's treatment of files, but there is also the lack of "Instant on and in the right directory already." That really changes the user experience.

I also downloaded the emulator and rom source files and compiled them, now I can modify the rom code if I think it will help me and test the changes. So all good stuff... I just needed to step out of my comfort zone.

When I run the Emulator under linux I just use -fsroot to point where I've got the actual sdcard mounted.

That was I have the same setup on the Emulator and the Hardware.