hpr-knowledge-base/hpr_transcripts/hpr4506.txt

Episode: 4506
Title: HPR4506: The UCSD P-System Operating System
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4506/hpr4506.mp3
Transcribed: 2025-11-22 15:11:15

---

This is Hacker Public Radio Episode 45006 from Monday 10th of November 2025.
Today's show is entitled The Uxed-P System Operating System.
It is hosted by Whiskey Jack and is about 21 minutes long.
It carries a clean flag.
The summary is, this episode is about the Uxed-P System Operating System.
Uxed-P System is an operating system from the late 1970s which carried on into the 1980s.
It ran on a variety of different micro and mini computers.
The notable thing about it is that it ran programs on a portable virtual machine rather
than directly on the native hardware.
This podcast overview will give a very brief overview of the operating system, its features,
and its history.
This episode is for people who are interested in some of the more obscure history of the
early micro computer era.
Don't expect to find something here that you could put to use in a practical way.
Pascal and UCSD.
Pascal is a programming language that was developed by Nicholas Vert somewhere around 1970.
Many of you will be familiar with the name even if you have never used it.
It, along with C, were some of the most important programming languages of that era.
In the late 1970s, people working at the University of California San Diego created a combined
operating system, compiler, and development environment which would run on the various
micro computers and PDP 11 mini computers that they had in their computer labs.
This allowed them to offer a common teaching environment on a variety of hardware.
The design of the UCSD system very much reflects those origins as they are oriented towards
providing features that someone writing a program would find useful.
Commercialization.
Eventually, UCSD decided to commercialize the software by licensing or selling it to
a company who would then market it.
The first company was Softech Microsystem, who sold it for a number of years as well
as sublicensing it to others.
It then passed through the hands of a number of current companies before finally disappearing
in the late 1990s.
UCSD P-System versions.
The version numbering system used for P-System has a significance that goes beyond just
new features.
The first part of the version number is in Roman numerals.
There were four major versions, i, i, i, i, i, and i v. Note that I am pronouncing it
as letters rather than as numbers.
This apparently was the convention.
The first part is based on the virtual machine op codes and a different major version indicates
that a new and incompatible op code set was used.
The second part of the version number is in Arabic numerals and reflects release numbers.
This a full version number may be something like i, v, dot, zero, i, v, dot, one, etc.
I won't cover the history of the different versions here in the interests of keeping
this podcast short.
Hosted versions.
Later on in the life of the P-System, versions were released which ran as guest operating systems
on top of another operating system such as MS-DOS.
Disallowed people to use it while not dedicating a computer to it.
The version that I will describe here is one such system which was sold by P-Can software
as the power system and ran on MS-DOS.
P-Can was one of the successor companies which the P-System ownership passed through during
its life.
Basic concepts.
The base of a P-System is a P-Code interpreter.
This is a small interpreter written in native assembly language and which runs the P-Code.
On the MS-DOS hosted version this is a 4 kilobyte file called p-System.com.
Porting the P-System OS to a different set of hardware mainly involved just rewriting
this part of the system.
The operating system itself, utilities, user interface, file system and everything else
were written in Pascal and compiled to P-Code.
On the MS-DOS hosted version this is contained in a roughly 800 kilobyte file called p-System.com
That is, with ending with a VOL suffix.
Another file contains a documentation.
On the MS-DOS hosted version this is contained in roughly a 128 kilobyte file called doc.val.
File system.
The P-System file system is based around what are called volumes.
A volume could be thought of as like a disk.
Then a volume would simply be an entire floppy disk.
A hard drive could be split up into multiple volumes.
There could be sub-volumes inside of volumes but there was no hierarchical directories
such as found in a Unix system.
The latter being a concept which MS-DOS also eventually copied.
Dispaced was allocated in blocks of 512 bytes.
A maximum of 77 files was allowed in a volume.
Other drives were accommodated by allowing sub-volumes inside of volumes.
I don't think that sub-sub-volumes were allowed, although I haven't tested this.
Since most people were using P-System on microcomputers with only floppy disks, this wasn't
a real issue.
File names could be up to 15 characters long.
There were conventions for file name extensions.
This included one such as .T-E-X-T for text files, .B-A-C-K for backups of text files,
and .CODE for executable code files.
The file system was case insensitive.
The P-System did not allow Unix file naming patterns, so characters such as slash and
backslash could be legal parts of a file name.
The colon character, however, was a reserved character used to separate the volume name from
the actual file name.
Virtual memory and multitasking.
The P-System has a primitive form of virtual memory and multitasking.
Code exists in separate segments.
Segments are loaded into the code pool dynamically when needed, and unused ones are removed
when the code pool becomes full.
This compares to manually loading and unloading code overlays, which was a common method
in those days.
The P-System also has a form of multitasking called Cooperative Multitasking.
This allows for multiple threads of execution on a single CPU, but required each thread
to explicitly give up control of CPU to allow the OS to run out of the thread.
This is in contrast to preemptive multitasking, where the operating system takes over control
of the CPU from a thread, whether it wants to give it up or not.
The method of multitasking was present in some other micro computer operating systems
in those days, but the most commonly used ones, CPM and MS-DOS, did not have this.
In 8-bit versions of P-System, the code pool and stack heap, that is the data memory,
had to share whatever memory there was, typically 64K.
In 16-bit versions, that is, hosted versions running on MS-DOS, the code pool had a separate
128 kilobyte memory space from the 64K stack and heap.
The 16-bit version was a bit of a budge, as P-System was fundamentally an OS designed
for 8-bit systems, and so couldn't use all the available memory on a PC compatible
or 68000 system.
Remaining memory on those systems was typically allocated as a RAM disk, which at least allowed
for fast access to temporary files to make up for the lack of usable data memory.
This was a major deficiency of the P-System, and fixing it properly would probably have
required coming out with a 32-bit version.
However, by the time 32-bit PCs became common, more advanced operating systems were also
available, and the P-System was already fading away.
Architecture independence with P-Code
The P-System presented a consistent, portable system from the programmer's perspective, allowing
programs to be easily ported from one machine architecture to another.
This was quite extraordinary in those days, especially for something that ran on an 8-bit
CPU.
In many ways, this could be thought of as a predecessor to Java, and that code was compiled
down to P-Code that ran on a virtual machine.
There was no jit compiler to automatically create native code, but the programmer could
designate parts of the program using the Pire Directives, Dollar N Plus, Dollar N Minus,
to direct which parts of the program were to be compiled to native code, and which parts
were to be left as P-Code.
Native code was not necessarily faster than P-Code, as operating system calls had a higher
overhead from native code.
The programmer needed to use his discretion in deciding where native code made sense if
it did at all.
P-Code interpretation was very efficient, and in many cases, I couldn't see any noticeable
improvement from a user perspective with native code.
Western Digital designed a CPU called the micro-wension specifically to run the P-System.
The native machine code of the micro-wension was P-Code, version III, that is three,
of the P-System was a micro-wension specific version.
The micro-wension was sold commercially in limited numbers.
Programming languages.
The main programming language used on the P-System was Pascal.
Most of the operating system in standard applications were written in Pascal.
This was unusual for this era, when a lot of software of this type was written in assembly
language, or at least it was for the micro-computers.
Other programming languages were available though, including Fortran, Basic, and Module
2.
The fading away of the P-System Ennestimize.
The UCSDP system was one of three operating systems offered by IBM when they introduced
their IBM PC, the others being PC DOS and CPM.
However, P-System was several times more expensive than the alternatives, and if you were
available third-party applications.
The introduction of the IBM PC as a de facto hardware standard removed a lot of the advantages
of a portable system that had existed in the days of the plethora of 8-bit computers.
The P-System had only ever had a small market share to begin with.
The owners switched to focusing on embedded systems.
By the end of the 1990s, however, it was more or less dead.
It cut down version of the P-System with just the P-Code interpreter and compiler, and
without the rest of the OS had been used on some 8-bit systems, notably the Apple 2 where
it was known as Apple Pascal.
However, other versions of Pascal, particularly Turbo Pascal, came to dominate in the IBM
PC market instead.
A quick tour of the P-System running it on modern hardware.
I will now give a quick tour of the P-System touching only lightly on a few aspects of it.
I have a copy of an MS-DOS-hosted version that I bought in the 1980s.
I bought this to learn about the OS as I was writing application software for a large
piece of lab equipment that ran a native version of P-System to control the hardware.
The version I have is IV.2.2 R 1.0.
The first order of business is how to get it to run on a modern PC, which is running Linux.
I solve this by installing DOSBoxX, which is an emulator which simulates a variety of
older hardware and provides an equivalent to MS-DOS built-in.
I had tried getting it to run under QEMU and free DOS, but I had problems with numerous
bugs so I gave up.
This is an exercise in running P-System, not in debugging QEMU and free DOS issues.
I put the P-System files in a directory called PSYS or PCS for short.
Then in the parent directory, I open terminal and typed DOSBoxX.
When DOSBoxX started, I typed Mount, C, PSYS in the MS-DOS terminal.
This mounted the Linux directory PSYS as MS-DOS drive C. When I typed DIR in the DOS terminal,
the files were visible.
I then typed P-System to run P-System.com and the P-System started up.
User Interface
When the P-System starts up, you are greeted by a splash screen which shows the OS name,
version, system date, copyright notice, and the main menu.
Something that may surprise you is that there is no command line for the P-System.
The user interface is all menu driven.
The menu runs in a single line across the top of the screen.
These are not drop-down menus.
Instead, items are each activated by typing a single key which represents the first character
of the item name.
When there are too many items to fit across the top of a single screen, you use the question
mark key to select the next set of items, repeating as many times as necessary.
All standard programs use the same menu system, providing a consistent unified user experience.
This system works equally well on serial terminals as it does on PCs with graphics cards.
The OS level menu
Here are the options of the OS level menu.
Edit.
This runs a standard editor known as the Advanced System Editor, or ASC for short pronounced
ACE.
Run.
It compiles and runs a program.
File.
It starts the file manager.
Comp.
Runs the compiler.
Link.
Runs the linker.
Execute, which starts with an X.
Runs a compiled program.
SM.
Runs the assembler.
Debug.
Runs the debugger.
Halt.
Shuts down the OS.
There is a confirmation menu for this operation so you won't do it accidentally.
Initialize.
Reboots the OS.
User restart.
This does nothing in the MS-DOS-hosted version.
Monitor.
Records and plays back keystrokes.
This allows for simple scripting.
Set.
Opens the menu, allowing you to view and set various system defaults.
ACE Editor.
The Advanced System Editor is part of the P system.
I won't try to cover all the features here as that would take too long.
It has two distinct modes, a command mode and an editing mode.
In the command mode, it has a menu system like the OS itself, where typing a single character
causes the editing command to execute.
In editing mode, you can edit an individual line of text.
One unusual feature is that to enter a line of text, you need to accept it, which is done
by pressing Control-C.
On keyboards, where the control key is in the middle row on the left-hand side of the
keyboard, this is actually very quick and easy.
Once you get used to the editor, you can move a vote and edit files very quickly.
Filer.
The Filer is the file manager.
This has a number of different menu commands for listing directories, creating, copying,
deleting files, and other file operations.
This also lets you mount and dismount volumes.
You must mount a volume before you can use it.
However, you can only mount a limited number of volumes at the same time.
Thus, you need to decide which volumes to mount for what it is you wish to do.
As most microcomputers in those days only had two floppy drives, this was not actually
a major issue, as these volumes would correspond to individual floppy disks anyways.
In the P-System file system, the volume name is called the file prefix.
You can set any volume to be the default prefix.
The equal sign would act as a wildcard character when specifying which files to list.
The file system was very simple, and volumes could be come fragmented when changing, deleting
or adding files.
As a result, you would need to regularly defragment volumes, an operation known as Crunch, where
that it starts with a K, rather than a C.
A Crunch operation would move files up to the beginning of the volume to close up any
unused blocks in between files, and leaving the unused blocks at the end of the volume.
Execute
To run a program, you press the X key on the main menu to select the Execute command.
You'll be asked for the name of the program you wish to run.
Type in the name of the file, including the volume name if it is not the current volume.
Separate the volume name and the file name with a colon character.
Executable files end with a .code suffix.
You do not need to type in the .code file extension as this is assumed, but it will still
accept it if you do.
DOS FILOR
The MSDOS hosted version of P-System includes a program called the DOS FILOR.
This is not part of the standard system, and so is not integrated into the system menu.
You have to execute it through the Execute menu.
It offers features similar to those of the standard FILOR, but also understands the MSDOS
FILOR system.
Its main purpose is to copy files between the MSDOS FILOR system and the P-System FILOR
system.
It also allows you to create new P-System volumes.
These new volumes appear as separate files in the MSDOS FILOR system.
Conclusion
The UCSDP system is an example of an operating system from the early days of microcomputers
that did not follow the conventions that we are used to today.
It had features that were in many ways ahead of its time.
Here are some examples of this.
It was almost entirely written in a high-level language, Pascal.
It was compiled to P-code or Pascal code that ran on an architecture independent virtual
machine.
Performance critical parts of the P-code could be compiled to native code.
The user interface did not use a command line, indeed there was none, instead it used
a menu driven user interface.
On the other hand, it remained stuck on 8-bit limitations in a 16-bit world.
It was a closed source proprietary product, and when the vendor lost interest, the product
died.
It is an interesting bit of history, but I can't really recommend that anyone should expect
to do anything useful with it today.
I still have a copy that I bought when it was a current product, but it has been many
years since I even looked at it and only resuscitated it for the sake of making an HPR episode.
At Endham Performance benchmarks Some people may be curious as to
how fast a program running in the P-system virtual machine running on top of the DOS
Box X emulator running on Linux on a modern PC compared to the microcomputers of that
era.
To test that, I ran one of the common benchmarks of that era, the Siv of Eras Totsanese
prime number program.
This as a name implies, calculates a series of prime numbers.
DOS Box X offers a variety of tuning factors.
I set the CPU speed to the fastest option, which claims to emulate the speed of an 866
Beggerhertz Pentium 3.
When I time the benchmark using a stopwatch, I measure roughly one second of execution
time.
The source code for the benchmarks lists the performance of that benchmark on a variety
of other computers.
Here's a few examples.
On Apple 2, ran it at 390 seconds.
For the IBM PC, it was 203 seconds.
The North Star i.5 with a 4 Beggerhertz Z80, it was 183 seconds.
The LSI 1123, a version of the deck PDP 11, ran it between 92 and 128 seconds depending
on the machine options.
The Western Digital Microwension, ran it in 59 seconds.
There is a note that the Philcare operation is very slow on Microwension.
For the Sage 2 with an 8 Beggerhertz 68000, it was 157 seconds.
I'll note the Sage 2 was designed specifically for running P-System.
As you can see, modern PCs are much, much faster than the micro computers of that era.
This concludes this episode on the UCSDP system.
You have been listening to Hacker Public Radio, at Hacker Public Radio does work.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording a podcast, you click on our contribute link to find out
how easy it really is.
Hosting for HBR has been kindly provided by an honesthost.com, the internet archive
and our syncs.net.
On the Sadois stages, today's show is released under Creative Commons, Attribution, 4.0
International License.