• Please review our updated Terms and Rules here

Best way to implement directories while maintaining CP/M 2.2 compatibility.

I’ve used micro shell for cp/m where you can customize the prompt then together with a dir utility that allows you to assign names for users thus you would say user 2 and it would correspond to games and the prompt would say A:games>
In practice you would say dir games or dir word and that would just change users.

To see a dir listing would be dir ? And it would list out the alias assigned.

Thing is it’s very slow using all that it looks nice but you just revert back to normal cpm prompt and user 0 to 15
Once you get used to where you put things actual directories become pointless it’s only for a new person
Not used to user command
 
They're treated as two different files. The first byte is masked to provide a user number and that is used in the search. In particular, see the discussion here:
github.com

BDOS function 17: Search for First Name Match with '?' in drive byte errors out · Issue #88 · MockbaTheBorg/RunCPM

I'm having a problem with RunCPM's implementation of BDOS function 17 (Search for First Name Match). Unless I'm not reading the code correctly (which is entirely possible), it doesn't seem to allow...
github.com github.com

The bonus is that if a "?" is used in BDOS call 17, you get all files that match the search criterion, regardless of user number, type, or deleted status.

What's not to love?
 
Eudimorphodon said:
Ignorant question: when does “generic” CP/M software ever make “direct” disk accesses?
Click to expand...
Regular software only cares about files, not about disks. Although some many programs will use their file system (FCB) knowledge to do weird stuff. I've looked into CP/NET before, and those applications would break on a network drive.

Eudimorphodon said:
I’m looking at ye old big list of BDOS calls and I don’t see anything akin to INT13h direct sector access, everything that touches the disk goes through an FCB. So far as I’m aware any programs that run under CP/M that touch the disk at a lower level than that (like for, say, reading alien formats) are platform specific.
Click to expand...
Yes, although you can treat the BIOS interface as an extension to the BDOS interface - it is available to applications and very standardized. In the early days of DOS, that wasn't the case (until the IBM PC dominated and defined the interface).

durgadas311 said:
It was quite common for programs that needed direct disk access to make BIOS calls. Even Digital Research's reference implementation of SYSGEN does that.
Click to expand...
SYSGEN is very much not a generic CP/M application. It stores data outside of the file system and assumes that the system boots from the reserved tracks in the first place (there is no such requirement). One version of SYSGEN is also extremely unlikely to function on a different machine.

cj7hawk said:
I'm just looking to program up some code to add directories to my CP/M implementation and was wondering of the best considered methods, and ideas from the past.
Click to expand...
The only interface between applications and files is the FCB. Applications do not understand directories, so you have to designate a "current directory" and base your FCBs of them. The file system itself cannot handle subdirectories, so you are basically implementing your own. Whether that is concatenation of multiple CP/M filesystems or a hierarchical system like FAT doesn't matter - as long as you get the FCB handling right.

Depending on whether you want system-level tools like STAT to work accurately, you have to abide by different limits within the structure, or you just fake those and live with the consequences (e.g. never report more than 50% free in the allocation bitmap). Some applications will do weird stuff with the FCBs, and these will break. There is nothing you can do about that.

If modifying the BDOS is out of the question, you can still use a TSR approach (like CP/NET) to overlay the BDOS functions. For example, you can store directory metadata in a special file, have a magic directory for always-available utilities (such as "CD.COM", "MKDIR.COM" and "RMDIR.COM"). This is also how early LFN support was implemented in DOS.

Such an approach would also allow you to support multiple file systems without sacrificing compatibility. For example, a CP/M file system as A: (no directory support) for misbehaving applications and a regular FAT file system as B: (with full directory support).
 
Svenska said:
SYSGEN is very much not a generic CP/M application. It stores data outside of the file system and assumes that the system boots from the reserved tracks in the first place (there is no such requirement). One version of SYSGEN is also extremely unlikely to function on a different machine.
Click to expand...
Indeed. One of my systems has ROMs that mandate that boot tracks be in Intel hex format. The OEM version of MOVCPM knows nothing about BIOS and doesn't perform relocation on it--just the BDOS. Even functions that would seem to be standard fare aren't, such as disk copy.
 
Chuck(G) said:
Indeed. One of my systems has ROMs that mandate that boot tracks be in Intel hex format. The OEM version of MOVCPM knows nothing about BIOS and doesn't perform relocation on it--just the BDOS. Even functions that would seem to be standard fare aren't, such as disk copy.
Click to expand...
SYSGEN itself is just the program that reads/writes the system track. It is not particularly dependent on a platform. MOVCPM normally contains the CCP, BDOS, and vendor's BIOS, and possibly the bootstrap sectors.
 
durgadas311 said:
SYSGEN itself is just the program that reads/writes the system track. It is not particularly dependent on a platform. MOVCPM normally contains the CCP, BDOS, and vendor's BIOS, and possibly the bootstrap sectors.
Click to expand...
My point was that SYSGEN is not a standard DRI-provided utility. And putting an Intel HEX-format bootloader in MOVCPM might be--interesting. DRI left a lot of "we leave this to the vendor" stuff in the OEM release, providing only examples of what one might do.
 
Chuck(G) said:
My point was that SYSGEN is not a standard DRI-provided utility. And putting an Intel HEX-format bootloader in MOVCPM might be--interesting. DRI left a lot of "we leave this to the vendor" stuff in the OEM release, providing only examples of what one might do.
Click to expand...
My point being that SYSGEN is a good example of accessing the disk via the BIOS in a platform-agnostic manner. And since the 8" SD SS distro disk contains SYSGEN.ASM from DRI, it certainly is provided by DRI.
 
It works only if the host system works that way. There's no particular requirement that the boot tracks are accessible by the BIOS routines. The BIOS is required to provide cold-boot and warm-boot routines; there's no ironclad rule how those would work. Suppose, for example, in the interests of economy, the boot tracks were compressed?

In fact, leaving the boot tracks inaccessible to the normal BIOS routines would certainly score a point for security. I can think of other reasons to do this--for example, use a larger sector size for faster loading.
 
Last edited:
Svenska said:
If modifying the BDOS is out of the question, you can still use a TSR approach (like CP/NET) to overlay the BDOS functions. For example, you can store directory metadata in a special file, have a magic directory for always-available utilities (such as "CD.COM", "MKDIR.COM" and "RMDIR.COM"). This is also how early LFN support was implemented in DOS.

Such an approach would also allow you to support multiple file systems without sacrificing compatibility. For example, a CP/M file system as A: (no directory support) for misbehaving applications and a regular FAT file system as B: (with full directory support).
Click to expand...

That much I already have. I wrote my own BDOS and CCP and BIOS from scratch, but I also have routines that allow the DRI BDOS and CCP to be hot-swapped in as an option, so I want things to continue working if that happens. All that should be lost is the commands under the CCP and any future BDOS extensions that I add. The whole architecture allows OS replacement on the fly, or OS switching even, though at the cost of system memory.

My L: drive is a 64K ROM space that contains the bootstrap ( 128 bytes ) and the BIOS and BDOS, which it copies to memory, then boots the CCP via the BIOS reset, which loads the CCP like a regular binary file before handing over control. The CCP looks for executables on the logged drive, then defaults to looking on L: for the file to execute, so adding commands to L: to handle directory structures still maintains compatability if someone switches in the DRI CCP, since they can manually run the L: commands from the command line.

The BDOS during boot time also executes the driver bios routines by looking for specific executables on A:, C:, J:, K:, N:, O: and P:

N: is for Non-Volatile memory, so system updates can be located on N: and boot into a different OS or perform other functions as a standard component of boot time. I reserve the top 8 drives for other purposes. I: is reserved for network drive mounts over IP.

Only drives A: to H: are going to be storage - A: and B: will be a floppy, and C: and D: will be a hard drive. That gives me four drives I can do other things with such as directories if I choose not to keep A: and C: as they are when first accessed under CP/M.

That provides plenty of options. I'm just trying to work out what has been done in the past and how it worked. Also, there's probably quite a few different ideas I would miss if I was just thinking it through myself, so all ideas are appreciated - :)
 
Chuck(G) said:
It works only if the host system works that way. There's no particular requirement that the boot tracks are accessible by the BIOS routines. The BIOS is required to provide cold-boot and warm-boot routines; there's no ironclad rule how those would work. Suppose, for example, in the interests of economy, the boot tracks were compressed?

In fact, leaving the boot tracks inaccessible to the normal BIOS routines would certainly score a point for security. I can think of other reasons to do this--for example, use a larger sector size for faster loading.
Click to expand...
I'm not even going to consider security... That's a can of worms I don't want to open.

This system will support user booted OS elements, including ROMs, that execute before system utilities, all from ROM. If security is required, someone can use one of the two userspace ROM sockets to ensure they only boot their trusted OS. Same with adding Dongles. Two should be enough for most typical user cases, especially since it's not like anyone will care how I build a computer with a millionth of the power they can buy from the local Walmart for a few hundred dollars.

And even from a software perspective, the user can install their own OS and just use the Loki OS to boot it straight from either NVM or C:

Though I guess an interesting thought then is boot order. It's something I don't support. So it would be quite possible to corrupt the NVM and stop the system from running... I guess I need a "safe mode" in the end at a minimum that bypasses the boot order and just boots the basic LokiOS files as though the user drives are all ignored.
 
The other aspect is that not much of the BIOS need be in read/write memory. Just a few cells related to things like IOBYTE, disk ALV, etc. The rest of the code can be in ROM and reside at a fixed address. There are some oddball applications that "plug" the bios jump vector temporarily, however. I'm not even certain that the relationship between the BIOS jump vector and BDOS is a fixed immutable thing, although that's certainly the usual trend.
 
Depending on how much compatability you want, then as long as you find some method to catch BDOS calls and can load programs in at 0100, I think you can almost make the rest up. But software certainly does do whatever it wants. That is both a strength and weakness of CP/M.
 
You must log in or register to reply here.
Back
Top