by whartung | 2025-04-16 23:15:40+00:00
From the Terak Museum[0] from the Terak thread[1] there was this anecdote

> What does the Terak have to do with the Macintosh and MacPaint? The Macintosh's operating system was bootstrapped on an Apple Lisa computer. The Lisa's OS was written on the Lisa using a port of the UCSD Pascal compiler and P-System. The Lisa's port of the P-System was prepared on an Apple II, which had its own version of the P-System that was developed by Bill Atkinson, the Apple programmer who later wrote MacPaint. Atkinson ported the P-System to the Apple II while visiting UCSD, who helped Apple with the port using a Terak. Some people think he got the idea for MacPaint from the paint programs he saw in use on the graphics-intensive, square-pixel Terak. Thanks in part to Gary Capell (gary@cs.su.oz.au) for parts of this story.

Its a great anecdote. And it also makes one think "They wanted to use Pascal so badly, they were willing to use UCSD Pascal for it."

UCSD Pascal was a wonder and a pioneer. Unfortunately, it was in the early era of microcomputers. When microcomputers were, frankly, horrible. File this anecdote under "its amazing we managed to get any software written at all" back then.

In the P-System, you had the core VM, and everything else was compiled into that P-code. The shell, the compiler, the file utilities, everything. Again, it's a marvel. It's (almost) self hosted (did it come with an assembler? I don't recall). But if you had a VM running, everything else was self hosted. The compiler compiled itself, being written in UCSD Pascal. Marvel yes, speedy, not so much. It certainly qualified as "better than nothing".

It had a lousy file system. Files had to be continuous, which makes it difficult to write to more than one file at a time. Compressing the disk structure was a routine process. The editor was also very interesting. Also, text files naturally compressed whitespace -- important with Pascal source code where whitespace is probably 20-30% of the space on disk.

However, on the other hand, the runtime was quite sophisticated. P-Code was position independent, so it could read, run, and flush code at will. The code was segmented into chunks, "overlays" being the norm. But as user of the code, it was mostly invisible to you (you know, the way RPC is invisible). If you look at the original Macintosh memory and resource manager, and how it stored applications in segments, you can see the lineage straight from what UCSD was doing back in 1977. And, of course, UCSD Pascal had that novel feature of being an actual, usable Pascal for, well, demonstrable system level programming, and also large system design through the use of Units and such. Novel at the time.

The real shame of the UCSD eco-system, specifically today, was when USCD licensed it to SofTech (something like that), who came out with P-System IV (P-III was a unique port to, I think, a Sage 68K machine). The ship had sailed for "but it's not DOS" types of systems that SofTech was trying to squeeze UCSD back into. But it had some cool features, notably it supported co-routines.

But, while P-System 1.5 and P-System II are all flying free around the interwebs, P-IV is not.

It IS well documented, but whoever owns SofTech today, hasn't released the legacy stuff to world.

Also, as a shout out to the Blog author. Do a search for, I think, the game SunDog. This was written in P-System IV, and they have a P-machine in C (or C++) that you can look at.

The part of the P-Machine I haven't quite grokked, is the way it handles stack frames. Because Pascal allows nested functions (and scopes), it had primitives to access "variable 3, 4 stacks frames up" kind of thing, so its a bit of a maze (plus the first class support for the segments in the runtime as well). I was looking at trying to port it to the 65816. The P-System would naturally work well with a 128K 65816 using their data bank model. You could have the runtime in its own 64K bank, the P-Code in its own, and then 64K of data ram in a 3rd. I thought that would be a neat '816 project.

[0] https://www.threedee.com/jcm/terak/index.html [1] https://news.ycombinator.com/item?id=43708726