UCSD Pascal

I was going to post this in another thread but it's way off topic, so I'm starting a new one here.
Anywho.... what I'm mostly going to talk about here is what should have happened with UCSD Pascal.

The other thread mention Forth and UCSD Pascal arising at a similar time with a similar idea for a virtual machine.
Both were designed around 1968-69 and the Wiki shows them being released in 1970.
They arose at the same time because someone else designed something similar for another language a couple years earlier.
I think the got the idea from a BASIC produced at the University of Illinois by the same guys that designed the PLATO system, but I'm not 100% sure of that.

UCSD Pascal took the virtual machine a step further than Forth or their predecessor with the portable OS and environment.

I've worked on a P Machine for a different CPU. and if I sat down to seriously work on it for a few days, it would probably be up and running within in a week.
It was a pretty great idea at the time. Most of the work is the P-Machine itself, and then the low level I/O. After that it's just configuring the system which is easy.

There are several things UCSD should have done they didn't, and I think at least one would apply to Forth as well.

1. It should have been made open source... though the concept didn't really exist as we know it at the time. Things were commercial or public domain.

2. They should have included an extensible command shell. Any number of development tools could have extended the system. When combined with #1, support would have exploded.

3. The editor/environment should have been configurable to use different compilers. Apple's Fortran certainly proved the usefulness of the concept.

4. It should have been designed so it could run on top of any native file system that could support longer file names and subdirectories. Basically a level of abstraction in the OS design so it could get away from the proprietary file system where possible.

5. The P-Machine should have been register based and more RISC like to make the P Machine smaller, optimization easier, and translation to native code easier. That way of thinking was several years off though.

I'm not sure if register allocation was even used until the 80s, and I saw compilers as late as the 90s without even peephole optimization.

Native code translation from P Code certainly existed by the late 70s. There was an 8080 translator published in BYTE magazine around 1978... after Tiny Pascal?
The ability to run P-Code modules through a native code translator would have made a huge difference at runtime on speed critical code.
A just in time compiler is what some would call it.

6. The P Machine needs better support for paged or extended memory. This is sort of supported in later versions, but I couldn't find source code and it needs to work hand in hand with the translator. Automatic support for more than 64K along with native code generation makes 8 bits much more competitive with 16 bit machines.

7. The virtual machine (talking the OS/API level here) should have moved away from a strictly terminal interface
I'm not talking about a GUI here, just extend the environment with features similar to Extended BASICs... and then add a few more.
It should have supported some way to detect native hi-res graphics mode. What resolution and pixel depth.
Then it should have APIs for a bunch of related things.
Line, circle, flood fill, DRAW (complex shapes based on strings) and simple blit copies.
Drawing text on the graphics screen like a terminal.
Play sounds, play simple music, play sound samples, and produce speech.
Support for some sort of system timer.
Include a set of Pascal routines to do some of that so it's easy to get up and running, but then they could be ported to native assembly for maximum speed on each machine.

Basically, a lot of the things the PLATO educational system had, but targeted at microcomputers of the early 80s.
All of the technology to do that was available at the time.

Certainly not all systems would have sound, and maybe require a minimum resolution in 2 colors, but it makes portable games, educational software, etc... .not only possible, but easy. Some of it could have been up and running in 1980. Apple Pascal certainly proves that with it's support for some graphics.
Something like Print shop could be ported from one system to another mostly by adding printer drivers.

I've worked a little on pieces of this. It's partially why I wrote the code for printing text on a graphics screen.
It's also why I've been supporting most 6847 based machines, the Atari, the Plus/4 & C64, and I've even done a little work for 9918 based machines (the last three aren't 100% complete). It supports a minimum system it might run on.
Drawing lines, circles, etc... are easy once you have native pixel drawing code.
Sound is awkward beyond simple notes. Sound samples, speech and any sound effects are pretty much native code for each machine.
A new virtual machine like I described, requires a new interpreter, compiler, assembler, peephole optimizer, linker, runtime translator for each CPU, a set of native functions to support native translated code, native sound related libraries... it's a massive undertaking and I've just scratched the surface.

I thought maybe add the graphics, graphics text, sound, and music to the existing system.
Use the graphics text for the editor (full upper and lower case no matter what system it's on).
Then maybe the OS changes so it can sit on top of a native OS.
Maybe sampled sound and speech.
Command shell?

Possibly a peephole optimizer for the existing P Code. I don't even know if stack based code can be optimized that way though.
If it looks promising, then maybe all the new VM stuff. It would be transparent to the Pascal source code.
It might be more important just to get new p machines for each CPU free of copyright issues.

I used UCSD Pascal extensively on Apple Pascal, and later on the SAGE machines, and yeah, your concerns pretty much mirrored mine when I was using it. The overall problem for me with UCSD Pascal was the performance, which never received the optimization it really needed.

But the language itself was very good, fairly complete, and so many people were able to make useful things in it.

(all things said, I _am_ glad that UNIX and C ultimately took over in the academic circles)

Actually, I think peephole optimization would work well for a few things.
Where procedure calls can follow one another using return values from the previous function, it could group pushes to the stack together instead of messing with the stack more.
The P Machine is designed to push all values before returning to the main interpreter loop, and grouping them together eliminates interpreter calls.
But that would depend on the order parameters are expected by procedures.
Some intermediate calls could also be dumped.
Parsing will probably be a pain though.

The UCSD archive that was released includes full source of V1.3 (license files have a different version) including ADA and BASIC compilers, as well as PDP 11 and Z80 interpreters.
No Fortran, Modula 2, 6502, 6800, 6809, or 9900 source has been located yet.
I'm trying to sort through source code from several other disks to see what the latest versions are of everything.
There may be source for a later version and possible some code related to multitasking, but some of it isn't as advertised.
Other disks seem to have V1.5(?) with the intel 8088 interpreter.

There is source available for M Pascal for the Kim 1, but I'm not sure if's usable towards building a new UCSD P Machine.
Another disk image might contain some UCSD 6502 source, if I can find a tool to extract it. Building a tool may be required.
There is a disassebly of Apple Pascal but it needs work.
The FLEX archive seems to have disappeared so any hope of getting 6800 or 6809 versions seems to have gone down the drain for the moment.
Some disks supposedly include the Modula 2 compiler, probably just the binary, but it should run on a compatible P Machine.
Apple Fortran binaries *may* run on a P Machine on a different CPU but I'm not sure if Apple included some sort of protection.
Based on the disassembly of Apple Pascal, I can tell you that switching to the 65816 would speed everything up noticeably due to 16 bit support.

I've been wanting to make a version of the Apple ][ Pascal runtime that uses the ProDOS kernel and filesystem.

By all means, go for it. I certainly won't stand in your way.
Just be aware that this isn't just something you can easily patch.
The built in dos on UCSD is pretty lightweight as far as memory goes.
ProDOS is sure to require more RAM and the need to use addresses Apple Pascal normally does.

The IIgs may be first platform I support due to ProDOS having support for everything.
The 65816 could also work around the memory issues.
For machines with ROM based operating systems where the OS could be paged in and out, it might be easier, but again, using the 65816 would solve a lot of potential issues.
The 65816 should also run the P-Code 20% faster than the same MHz 6502.
The P-Machine is 16 bit which isn't exactly the 6502's best feature.
Plus, I could use the IIgs's 320x200 graphics, the more advanced sound, etc....

By all means, go for it. I certainly won't stand in your way.
Just be aware that this isn't just something you can easily patch.
The built in dos on UCSD is pretty lightweight as far as memory goes.
ProDOS is sure to require more RAM and the need to use addresses Apple Pascal normally does.

I do remember reading of 48K runtimes (Wizardry, maybe?), and for at least some stuff I'd want to port *cough* An Introduction *cough* I'm fine requiring 128K.

Keep in mind this is just what I know so far for an Apple version.
.
A 6502 version is certainly doable. It would definitely require 128K due to the memory conflicts.
The Apple Pascal P-Machine resides at $D000, as does most of ProDOS.

They can only reside at the same address on different memory pages.
This means you'd have to alter the loader, but I think that's a given no matter what.
$C000-$CFFF is hardware I/O on the Apple, so that's reserved..
Up to that point it's not too big of a deal.
But ProDOS also uses $B000-$BFFF, part of the direct page, and part of low auxiliary RAM.
The P-Code interpreter could work around the direct page use, that's no big deal.

The amount of available RAM could be reduced to account for $B000-$BFFF, or that could be paged in and out as DOS calls are needed.

Paging would complicate things a bit, but it's certainly doable.
The auxiliary RAM use for the dispatcher is okay, but you might need to write a new ProDOS dispatcher.
I think the docs said it was a maximum of 3 256 byte pages.
I haven't even looked at what will be required for the interrupt handler.
I can't help but think both systems will want to deal with interrupts themselves, and what happens if an interrupt takes place that must be handled by the other system?.

You'll have to create stub routines to interface the P-Machine to the ProDOS dispatcher calls.

Then you have to worry about differences in DOS structures.
Any of the P-Machine utilities you may still need will have to be rewritten to support the native file system.

The alternative is to place a virtual drive on top of a standard disk volume and just make some transfer utilities to go between the virtual drive and the regular file system.
That is probably the easiest approach. Basically what an emulator would do.
It's certainly not ideal, but a lot of things may break otherwise.

OTOH, if you switch to the 65816, the P-Machine can run under the DOS in whatever free memory is available in the first 64K.
The P-Machine can allocate a full 64K block of RAM for program space, you can have 64K or more dedicated to data, you can probably have as much stack space as you want, video RAM is totally separate, you can have your own direct page for the P-Machine separate from the one used by DOS, and you can use the rest of RAM above 64K for a disk cache.
Plus it would be smaller and faster due to 16 bit support.
You don't have to worry about paging, just point index registers at the code or data memory as needed.
I suppose you could leave one index register always pointing at the data since you will only modify code memory when the OS loads a program.
The other could always serve as the program counter unless needed by specific instructions.
You still have the same file system issues, but again, you could create a virtual drive and utilities.

Either way, I think it would be wise to go with a virtual drive on top of the native file system, at least initially.

After searching through a lot of disk images and archives, it seems the compilers besides Pascal only seem to work on older versions of the VM.
I've only found Fortran for the Apple Pascal version, so I'm not sure if it will work on other systems.
Modula 2 may only include the binary, but I haven't extracted the files yet to be sure.
The BASIC compiler includes source but it would have to be adapted to a newer VM and none of this code has any amount of useful comments.
Trying to update any of these probably isn't worth the trouble.

So far I've only located P-Code interpreters for the 8080, Z80, 6502, PDP-11, 8088, and 68000, though I haven't looked at all the code yet.
The 6800 and 6809 versions seem to be missing. I'm not surprised about the 6809, since I think it was offered by a different company, but the 6800 version should be knocking about somewhere.
Several of the retargetable P-Code interpreters only support older versions of the VM, and I'm not sure how much work it would take to update them to support the newer instruction set.

The portable environment is the most useful part of the system, and the file system only supports 77 files, at least on the older versions.
Switching it to work on a native OS is not a simple task either.

And to top it all off, not everything is dated, so I'm not sure what is the latest version of some of the files.

If everything were well organized, documented, and kept up to date, this would be a complex project.
This is a salvage operation at best, and I'm not even sure what is salvageable.