TeleVideo Systems MmmOST Operating System
MmmOST, or "Multi-user, multi-tasking, multi-processor Operating System Technology" was a network operating system that TeleVideo developed and released along with their CP/M based computers starting in 1981. The system was based around a central server running CP/M 2.2 and the MmmOST software, and connected to multiple client TeleVideo computer systems.
This differed from MP/M which was offered from Digital Research, because MP/M functioned as a multi-user operating system on one computer with multiple serial dumb terminals, allowing for time-sharing of a single CPU. MmmOST ran applications software on single-user computers, one for each person, and did resource sharing to allow multiple people access to the same data, while not constraining CPU and memory resources to a single computer.
TeleVideo TS-816 Service Processor
Hardware features
MmmOST ran on either a TS-806 or TS-816 (aka "System II" and "System III"), which supported up to 6 or 16 users. These systems were called "Service Processors". The 806 included 64KB of RAM, a 5.25" floppy drive for system maintenance and back-ups, a 10MB or 20MB ST-506 interface 5.25" full-height hard drive (with expansion to a 2nd external drive), and 6 ports to connect clients, or "User stations" to. The TS-816 included 128KB of RAM, a tape drive replacing the 806's floppy drive, a 20 or 40MB ST-1000 interface 8" hard drive with an optional external expansion drive, and 8 or 16 User station ports. Both systems included serial and parallel ports for shared printers and a console terminal.
The system connected the server to the clients in a "star" network configuration, similar to how twisted-pair ethernet is connected to a network switch. Each user station was connected back to the service processor over a 15-pin 100-ohm shielded twisted pair cable of up to 300 ft. For shorter (up to 10 ft) runs, ribbon cables were usable as well. The connection between the two used SDLC over an RS-422 link at 800K baud, which could transfer data at up to 80-100K Bytes/sec. To make cabling simpler, the TX/RX pins were flipped between the service processor's and user stations' connectors, allowing for simple straight-through cables.
Example system layout from TS-816/40 manual
Software features
MmmOST provided a few basic features to clients - clients could boot off of the RS-422 connection back to the host (MmmOST required this to keep track of the state of each client and ensure that the client OS was properly configured for the system), and the server provided printer sharing/queueing and disk/file sharing to the clients.
Booting
Booting was integrated into the EPROM on the user stations, such that flipping one jumper (jumper 5 on all of the Z-80 based systems) would switch between booting off of a local disk or downloading the boot loader and OS from the RS-422 link. Every time that a program would exit on CP/M on the user station - or when the system was reset - it would re-download the OS from the service processor. The service processor would reset its internal state, releasing any resources that the user had exclusive access to.
Printer sharing
The system maintained print spools for each user station and controlled access to printers. Users could request exclusive access to printers, or queue up print jobs without having to wait for access to the printer to continue. This kept different users print jobs from mixing (such as when one person wanted to print payroll checks, and another print out a sales report, the sales report wouldn't get printed on the expensive check stock).
User stations all allowed either a serial or parallel printer to be attached locally as well so that local printers or modems could be used instead of the shared printer.
Disk and File sharing
MmmOST shared hard disk space on the server out to individual user stations. Between this and the remote booting, the clients could be operated without any local storage at all. Two systems, the TS-800A and TS-800R (based off of the TS-802 and TS-803), were full computers that shipped without any local storage options at all, and could only be run connected to a service processor.
On other systems where local storage was available (such as the TS-801, 802(H), 803(H), TPC-I, 1603, etc), the local floppy and/or hard drives were still available to the user, with names starting at N - typically M/N for the two floppy drives, and O/P for hard drives. Note that CP/M 2.2 limited drive sizes to 8MB (2^16 x 128-byte records), so larger drives had to be partitioned into no bigger than 8MB chunks.
On the server, there were typically at least two hard drive partitions available to clients. One, which showed up as "A" on clients, was a "private" drive, which functioned similarly to a home directory or user profile. Private drives were allocated one per user station, and additional password-protected drives could be "logged onto" using the MmmOST LOGON.COM program. At the client, these appeared as a standard block-oriented disk to CP/M. MmmOST would maintain separate directories and manage allocation space on the real disk to separate out users' files. The data was stored in a mostly CP/M compatible way, so that doing a "dir" on the service processor drive that stored private directories without running MmmOST would show every users' files.
One side note, these private drives were not the same as CP/M 2 and MP/M "users". Changing the user number (from 0-15) separated out files on the same private drive. Under MmmOST, user numbers provided a way to separate out different files, since CP/M 2 doesn't support named directories of files.
The other main type of drive is a "public" drive. This was shared between all of the clients. The clients could directly access the blocks on the drive, but in general CP/M would handle file accesses by passing the call (with the appropriate FCB) up to the service processor, and get back the result with the new/updated FCB. This is the type of file handling that MmmOST used for special files, such as MULTI.SYS, which allowed the user stations to make special requests to the service processor.
Public drives also supported record-level locking of data, so that applications could be written which allowed multiple users to access the same database. This would be useful for something like a client database where it would allow different people to work on the data in the database, without overwriting each others' updates and corrupting the database.
Public-Only drives are shared like Public drives, but do not support locking or access control to files. They can be used for read-only access to programs or data, or for anything which will only be accessed by one user at a time, such as the floppy disk on the TS-806 service processor.
Public-Only drives are shared like Public drives, but do not support locking or access control to files. They can be used for read-only access to programs or data, or for anything which will only be accessed by one user at a time, such as the floppy disk on the TS-806 service processor.
MULTI.SYS
Multi.sys was a "virtual" file that MmmOST kept on the shared drive, which allows for the user stations to make requests of MmmOST. There were a few different sections of the file, which allowed access to the service processor time (to synchronize it with user stations), file locking requests, and inter-user communications.
Time access was the simplest, reading a certain record of the file returned the current time on the service processor.
Record locking allowed a program running on a user station to request access to a file. It could request either exclusive whole-file read/write access, exclusive access to particular records, or just test for locks on the file.
Inter-user communication is a simple form of IPC, which allows messages to be passed between software running on different user stations. The default mode is a "mailbox", which allows each user station access to a short 128-byte mailbox, which any user station can use to send a message to another user station. The mailbox is overwritten, with no history or queueing, every time a new message arrives for that user station.
As an alternative to the mailbox, named FIFO queues can be selected instead. There are default FIFOs for each user station and can be additional named FIFOs, which multiple user stations can share.
Other commands
There are other commands which are distributed with MmmOST that talk to the service processor directly, instead of using a file like MULTI.SYS. These include LOGON (change which private drive is currently in use), DSTAT (to get information from the user processor about resources), PRNT/SELQUEUE (to control shared printing and queues), and a few others.
More info
My next blog post will go into more detail that I've reverse engineered while building a modern replacement for MmmOST.
The TeleVideo MmmOST 2.1 programmers manual has more details on the system, programming to use MmmOST features, and how to change MmmOST parameters. A copy is available on Google Drive here.
No comments:
Post a Comment