Lessons from installing MP/M II for the RCBus standard.

Lately I've been exploring the build of MP/M II for the RCBus developed by Tadeusz Pycio; available at github: https://github.com/tpycio/MPMII-RCBus

I've produced two, somewhat fumbling, videos of my explorations of the system and I've learned a lot along the way, including what I'm doing wrong. There is a lot left to learn, but I'd like to document what I've discovered so far in text.

MP/M II is Different

I knew this going in, but I'm shocked at how different. Assumptions I make about how MP/M II work have been completely driven by my experiences with CP/M 2, and this is a mistake. As I still am quite new to the world of CP/M 2 and RomWBW's ZPM3 (my preferred "production" platform at present,) the assumptions I make about CP/M, in general, are still somewhat amateurish, to begin with; but there's more to it than that.

Fortunately, publishing content to the community allows the community to contribute. In a recent video list, I show users of compatible Z180, RCBus builds how to install and use MP/M II:

In the second of these videos I teach how to set up an alternate user, and I also show where to find the MP/M II manual. I had not, however, spent much time with that manual at time of filming. A commenter @tapy-yt, who made videos with this build of MP/M II years before I got mine running, pointed out configuration issues and correct use of the SET command in a now pinned comment.

Further experiments and a deep dive into Reading the Friendly Manual later, I've learned that the intended method for administrating the system is quite capable of solving problems I simply brute forced in these videos. I've also learned how to build the Kernel (more) correctly for my intended use case. Specifically, in the case of handling large numbers of files at a time in a single process (mostly to enable archive creation using NULU.)

The Commands

In the manual all of the MP/M II commands are documented in great detail. In our code repository, we see these in the Distrib directory. These commands all end in the .PRL extension.

Commands we're familiar with have options that we may not be familiar with, specific to interacting with MP/M II features. The command pointed out by user @tapy-yt is SET.PRL, and it solves the following problems for us:

• Sharing commands between users, by setting them as SYS (system) commands.
  • Setting command as SYS commands also solves "Pathing" allowing users to call the command from anywhere on the system.
• Preventing non-administrative users from running sensitive commands by password protecting them.

It also provides a range of time stamping features that I plan to explore in the future.

In my videos, I brute force these solutions by creating physical copies of the same files between multiple users. I demonstrate creating both an administrative and non-administrative user in this way. This is unnecessary.

The Correct Way

I'm not thinking enough like a computer here. How do we distinguish admin and non admin users? Well, passwords, usually. Since SET can password protect the use of any specific command, you can expect that only authorized admins can run that command, no matter which user number they are assigned to at the moment.

This is very modern and really, necessary, for multi-user systems when you think about it. Because the MP/M II interface is so similar to CP/M II, I looked past all the Linux knowledge I've built over the years. In many ways, MP/M II is more like a unix, under the hood, than anything that came before it on the Z80 platform.

This is an interesting discovery for me. Largely, it feels obvious in hindsight, making me feel somewhat foolish; but mostly it allows me to bridge a gap between the oldest and newest operating system designs that I've explored.

Future videos will dive deep into how to operate the MP/M II system as intended. I will probably do a streamlined rebuild/deployment of a fresh system and then demonstrate the SET, DIR, and SDIR commands, at the least.

Sharing Tools

This may be addressed in the user documentation, which I am continuing to read through, but I'm unsure on the best approach for sharing certain tools. For example, if you want all users to have access to the z-machine interpreter, VEZZA.COM, for use in playing text adventures, you can simply make it a SYS command with SET.

But you can't, or at least shouldn't, share your gamefiles this way. If we password protect the USER command, but we want non-admin users to be able to access all the gamefiles, where do we install the game files?

In this scenario we can't assume that user #0 is always admin and user #1 is always non-admin, as I did in my videos. We can't even assume we only have two users; it may not be difficult to add more terminals to this system. Users could, potentially, be assigned a console as they are available, and administrative access is protected through the knowledge of a password by authorized users.

Well, this means that's it's likely safe to allow non-admins the ability to change users! As long as you are password protecting tools that allow administrative changes to be made, it does not matter what user they are!

This does mean you have to be diligent about ensuring your administrative tools are correctly configured, with a good password. We can't forget to configure this for build tools, though. An assembler or compiler toolchain can allow any user on the system to write new, administrative tools; bypassing your security.

In a more modern OS we might have facilities to prevent the execution of such code, but MP/M II is already doing more with the resources it has than I ever expected from it, so it's reasonably to expect administrators to handle their permissions with well thought through installations.

Conclusion

I love this system. I'm blown away by the maturity and elegance of its design and operation, and I plan to spend a lot more time with it. Following the historical design choices of these 8-bit operating systems has been quite revealing in understanding even the latest systems.

The code may change, the capabilities of processing technology may expand, but at the bottom of the stack are electrical lines, machine instructions, and lithographic structures. The abstractions that allow us to interact with that circuitry maintain, in their bones, the proven concepts designed in the very earliest days of computing and, in this case, home computing.

Thanks for reading!