[S] ext. (nicer?) .COMs of the Standard CP/M-Commands for RunCPM

[guidol]

Hi there,

as there is now an compile-option for RunCPM to deactivate all internal commands I'm searching for .COM replacements to fill this gap with some nicer or more beautiful or designed versions of the standard internal CP/M-CCP-standard-commands

But ATTENTION - we cant use a CCP-Replacement like XCCP or EPEX, because the RunCPM CCP isnt like a real CCP and cant be replaced and this function isnt emulated (external CCPs then do freeze at startup)

The following standard commands are included in the "internal CCP" of RunCPM:
DIR , ERA , TYPE , SAVE , REN and USER

Additional some RunCPM own extra command included in the "internal CCP":
CLS , DEL (alias of ERA) , EXIT , PAGE , VOL and ? (Help)

WIth nicer or designed commands/output I mean something like - the maybe good known SD.COM - as replacement for DIR

For ERA , REN it would be nice to get an (more) informative feedback
(like - if you know it - the difference on DOS when using 4DOS (COMMAND.COM replacement) against the normal MS-DOS.
4DOS under DOS tells which file was deleted (or how much files) or gives more feedback on rename.

Also for USER only a textual feedback would be nice.
In RunCPM you can change the User-Area with "USER 1" to change from A0: to A1: - but you also could give only "A1:" to go from A0: to A1:

For CLS is no feedback needed and I also have a small ASM-Programm or a version compiled in Turbo Pascal

For DEL we could use a copy of ERA.COM (while we cant create a Alias)

EXIT is only used in non Microcontroller-version to go back to DOS/Windows/Linux prompt

PAGE sets the Page-Size for TYPE

VOL and ? are only some informational commands for RunCPM
VOL lists the contents of a Info-File where the User can store a Volume-Info (like types of Programms in this volume)
and ? gives a short overview of the internal commands.

It would be nice when you could recommend some external .COM-replacements to get back the full function when deactivating the internal CCP-commands...

Many thans for reading and your interest in advance

 

[shirsch]

I lost interest in RunCPM after discovering how unfriendly the system was to well-known CP/M enhancements. If/when it becomes enough CP/M-like to support NZCOM and ZSDOS I'll take another look.

 

[cjs]

If/when it becomes enough CP/M-like to support NZCOM and ZSDOS I'll take another look.

It does support ZCPR3 and a few other CCPs (though these need to be set at compile time). Have you tried adding NZCOM to this list? What were the issues you ran into?

 

[guidol]

I lost interest in RunCPM after discovering how unfriendly the system was to well-known CP/M enhancements. If/when it becomes enough CP/M-like to support NZCOM and ZSDOS I'll take another look.

I know its doesnt support NZCOM , but I like the Speed and has been its ported to many platforms (including Microcontroller like RPi Pico, ESP32 and STM32 and Arduino Due) and does use a real filesystem and not disk-images

 

[shirsch]

It does support ZCPR3 and a few other CCPs (though these need to be set at compile time). Have you tried adding NZCOM to this list? What were the issues you ran into?

NZCOM is a replacement for CCP and BDOS. RunCPM has too many differences from CP/M in system segment size and addresses. I contacted the author about this a few years ago and was told "..that's just the way it is". This sort of compatibility, which I consider essential for a CP/M work-alike was just not deemed to be important.

The issue that @guidol links above contains a statement by the author that seems to imply it's a hardware problem. That's not at all true. NZCOM could care less about the hardware, but it does expect that CCP will be 2k long, BDOS 3.5k and the BIOS jump table to begin on an even page boundary. I forget which of those were the primary issues, but suffice to say it doesn't work.

 

[cjs]

NZCOM is a replacement for CCP and BDOS. RunCPM has too many differences from CP/M in system segment size and addresses....
The issue...seems to imply it's a hardware problem. That's not at all true. NZCOM could care less about the hardware, but it does expect that CCP will be 2k long, BDOS 3.5k and the BIOS jump table to begin on an even page boundary. I forget which of those were the primary issues, but suffice to say it doesn't work.

Actually, looking at the issue linked above, and understanding (slightly) better what NZCOM does, I don't think that the problem is what you think it is.

I believe that RunCPM is not running CP/M (the original BDOS), but is instead supplying the BDOS and BIOS APIs to give access to files on the native filesystem. To do this it must work in a dramatically different way from the original BDOS, which operates, in the end, on disk sectors, supplying its own filesystem different from the native one. This simply can't be compatible because you need to use one filesystem or the other; the two are not compatible.

This sort of compatibility, which I consider essential for a CP/M work-alike was just not deemed to be important.

I reckon that it wasn't that it "was just not deemed to be important," but it was simply deemed to be less important than using the native filesystem. This has disadvantages, as you've pointed out, but it also has advantages. For example, I can edit with a host editor (e.g., Vim) a file available to RunCPM and RunCPM will immediately see the changes, so I can e.g. edit FOO.ASM using a host editor and then assemble it under RunCPM without having first to copy it to a CP/M filesystem in a disk image and then mount that image before RunCPM can use it.

Basically, your attitude that using the CP/M BDOS (and thus filesystem) is essential for an emulator means that emulators can never read from and write to files on the host filesystem. To say that no CP/M emulator should ever do this is objectively wrong. (It's perfectly reasonable, however, to say that the purposes for which you need an emulator should do that. But I'd bet there are actually plenty of cases that would be useful even to you where using native filesystem files would be more important than being able to run NZCOM and similar things.)

 

[JohnElliott]

Basically, your attitude that using the CP/M BDOS (and thus filesystem) is essential for an emulator means that emulators can never read from and write to files on the host filesystem.

rcpmfs says hello

 

[cjs]

rcpmfs says hello

Ah, yes, there is that. Are any emulators actually using it?

I'd definitely be interested in hearing about the reliability of it. Even before you get to how it works with files being modified from the host side while CP/M is running, there's this statement from the documentation:

To my knowledge, rcpmfs has only been tested under the dsktrans pattern of usage (which writes the directory and then the file space), and with fairly simple operations in a CP/M emulator. It is not known how well it holds up under heavy use as a live CP/M filesystem.​

And even if it's working perfectly fine, it seems likely that all it takes to trash one or more files is forgetting just once to hit ^C after making a change on the host side (or making host side changes while the CP/M emulator is making changes).

Note that this is nothing to do with the quality of the code; as with the discussion of RunCPM above, the issue is just that CP/M does not support multi-threaded access to its filesystems. There's no way around this except to implement a different set of file access code that supplies the CP/M API to client programs.

 

[JohnElliott]

Ah, yes, there is that. Are any emulators actually using it?

JOYCE does, and I've even had bug reports on it from users so it has at least some level of functionality.

 

[cjs]

JOYCE does, and I've even had bug reports on it from users so it has at least some level of functionality.

I thought I'd have a quick look at it to see if I could replicate the problems I'd expect to see, but it turns out Joyce isn't too user friendly to new users, at least when running on Unix. I can start Joyce, but no luck figuring out what a "start of day disk" is, where I might get one (even after about ten minutes of web searching), nor do the prompts I get from the stable version appear to match what's in the documentation, exactly. After installing the dev version I got better prompts, but nothing really seemed to work. Maybe it wasn't even emulating one of the 8-bit machines, who knows. (There seemed no way to ask for a PCW 8256.)

(Other bugs, in case you care: the download archive can't be extracted without renaming it or giving special options to Gnu tar, because you've put a .gz extension on a file that's not gz compressed, at least for the download I got. And the configure script asks for libxml-dev to be installed, when what it actually wants, according to both the documentation and real life, is libxml2-dev.)

At any rate, I never claimed that rcpmfs was totally broken, just that it's probably broken for certain common uses of a shared filesystem. I would expect it to work just fine if you don't try any simultaneous access, and always make sure you warm-start the CP/M system after any change made from the Unix side.

(And if that works for some people, great! I'm not saying that it's wrong for an emulator not to support what RunCPM does; I'm just saying that some people need what RunCPM does, and I don't think it's technically possible to make something that does that and uses the CP/M BDOS.)

 

[JohnElliott]

JOYCE is written for people familiar with the PCW, so a 'start of day disk' is the term the PCW manual uses for a boot disk. For copyright reasons I can't bundle one with the emulator, which has always been a pain for users.

The download archive is a gzipped tarfile and if I download it with wget what I get is a gzipped tarfile. As far as I can make out, some browsers transparently decompress the file but leave the .gz extension on there.

 

[cjs]

The download archive is a gzipped tarfile and if I download it with wget what I get is a gzipped tarfile. As far as I can make out, some browsers transparently decompress the file but leave the .gz extension on there.

I looked into this a bit further, and the problem is that your web server is violating HTTP standards by claiming to have compressed (again) the .tar.gz file with gzip, probably due to a misconfiguration. I've sent you all the details in a PM.

 

[Svenska]

Basically, your attitude that using the CP/M BDOS (and thus filesystem) is essential for an emulator means that emulators can never read from and write to files on the host filesystem.

I've started (but not finished yet) an emulator with integrated CP/NET server.
That's another approach to get host file system access with an original BDOS.

 

[cjs]

I've started (but not finished yet) an emulator with integrated CP/NET server.
That's another approach to get host file system access with an original BDOS.

Except it doesn't actually, because the CP/NET requestor (client) intercepts BDOS calls and passes only local disk etc. accesses on to the original BDOS. Anything on a network mounted drive will not use the original BDOS at all, which means you won't get whatever facilities were made added by whatever modified the original BDOS.

 

[Svenska]

Some CP/M applications are badly implemented and incompatible with anything except the BDOS-implemented native CP/M file system. To my knowledge, they won't work with RunCPM (and won't work with CP/NET remote drives), but they do work with local drives even on CP/NET-enabled systems.

A networked CP/M system drives provides full BDOS semantics and compatibility (on local drives), easy access (on remote drives) and is compatible with BDOS replacements. From my point of view, that's worth considering, even if it is not the one true perfect answer.