• Please review our updated Terms and Rules here

PL/M compiler

tomjennings

tomjennings

Experienced Member
Joined
Jun 30, 2022
Messages
234
Location
Los Angeles CA
There's what appears to be a PL/M compiler in one of the folders in the MP/M source distribution floating around. There are what appear to be executable binaries, that I suspect are ISIS executables.... there is a ISX.COM, which when run, with or without arguments (PLM80, LINK, LOCATE, etc, the potential executables) prints ISIS-II INTERFACE VERS 1.4 then hangs, on MP/M. On CP/M 2.2, it prints no message, and Behaves Badly*. I've done little beyond this. I can find little about this stuff; has anyone got it to compile anything?

* BADLY: run, it does nothing; press RETURN and returns a command line prompt, but all keyboard input in all consoles is dead; processes are still running and load is low.
 
I have looked for a native-CP/M PL/M compiler (I recall using one back in the day), but I think the only way I've been able to compile CP/M source is using the ISIS PL/M compiler, run inside the "thames" ISIS emulator. I've got some Linux makefiles that use "thames" to build some of the CP/M source, if you want to see some examples. As I recall, it took some effort to get all the necessary components downloaded and setup. And there were some files missing from the CP/M source that I had to re-create.
 
Back in 2014 when the cp/m 1.3 source code was discovered I managed to get a two stage PLM compiler built from Fortran sources with gfortran which would compile
those PLM sources from a DOS environment but not cp/m. There is a v2 and v4 of the Fortran compiler sources. I still have my work folder if anyone is interested.

Larry G
 
durgadas311 said:
I have looked for a native-CP/M PL/M compiler (I recall using one back in the day), but I think the only way I've been able to compile CP/M source is using the ISIS PL/M compiler, run inside the "thames" ISIS emulator.
Click to expand...

I may have to do some tracing or disassembly of ISX.COM; it suuuure looks like an OS wedge, that "ISIS-II INTERFACE VERS 1.4" line is intriguing. And there are binaries with appropriate names with no extention.

As far as I can tell the .SUBs in the mpm source folders were often run on ISIS, what with the :f1: drive names, and " to " wordy syntax. But not all. And I'd be surprised if DR did development on other than MP/M at that point. But all I can do is guess.
retrogear said:
Back in 2014 when the cp/m 1.3 source code was discovered I managed to get a two stage PLM compiler built from Fortran sources with gfortran which would compile
those PLM sources from a DOS environment but not cp/m. There is a v2 and v4 of the Fortran compiler sources. I still have my work folder if anyone is interested.
Click to expand...

That's really interesting. It's a bummer so much of this stuff was lost, PL/M seems like the perfect 8080/z80 compiler it it's way. But I've got too many projects as it is, at this time I won't be pursuing compiling a compiler, too much work for too little return.

My first job if I had a PL/M compiler that would run on MP/M would be to fix the !@#!!!@ Y2K display/entry problem on SDIR and the rest! And display dates as 31-DEC-2026.
 
I think the DRI source code build "scripts" were run on something like a PDP-11 or VAX, and it appears they ran some sort of emulator(s) there. I assumed the original "SUB" files are not for CP/M SUBMIT, but for whatever OS they were running (a lot of names common in CP/M were taken from the PDP-11/VAX world). You'll see some commands prefixed with "vax", or other indications of what the commands were meant to be interpreted by. In some, you see lines with only "isx" or "cpm" to switch back and forth. I never did bother to try and figure out exactly what sort of system they were running, but just assumed it was not the CP/M environment we know. Rather, I used these scripts to understand the build steps.
 
Thorbjørn Ravn Andersen said:
I am pretty sure that Udo Munk did all the hard work already. It _looks like_ that the ISIS PL/M cross compiler in a workable state and documentation is present at http://cpmarchives.classiccmp.org/cpm/mirrors/www.unix4fun.org/z80pack/index.html, but you may have to hunt around a bit and build the tools.
Click to expand...
That's where I found the stuff I have so far. He's done a massive amount of work there!

He has a unix version running. I want to run it under MP/M or CP/M.
 
Ahh... this is apparently the ISX.COM program. So DR hacked CP/M to support this ISIS emulator!

github.com

GitHub - hperaza/P112-isx: Disassembly and P112 port of Digital Research's ISIS-II emulator for CP/M

Disassembly and P112 port of Digital Research's ISIS-II emulator for CP/M - hperaza/P112-isx
github.com github.com

This doc, linked to by the URL above, explains the BIOS and BDOS hacks. It is unlikely I will be pursuing this, *but I could* and it is tempting.

P112 Support Page

p112.sourceforge.net p112.sourceforge.net

...aaaand there is .ASMs for the ISIS-emulator-compatible BIOS and BDOS. Hmm...
 
Last edited:
My initial look at ISX.COM (at least the copy I find) shows it to be hard-coded for a particular memory layout. It starts copying parts of itself into 0F700H and 0F800H, which I'm pretty sure won't work on most CP/M systems. I'm not yet seeing how this will work on any system except the specific one it was written for (probably CP/M on an MDS-800).
 
tomjennings said:
That's where I found the stuff I have so far. He's done a massive amount of work there!

He has a unix version running. I want to run it under MP/M or CP/M.
Click to expand...
It looks like the PL/M compiler is written in Fortran, so you need a Fortran compiler for CP/M which accepts this particular Fortran dialect and then you need to make it work (perhaps continuing the work in https://forum.vcfed.org/index.php?threads/pl-m-compiler.1257428/post-1501824) . This page may be helpful: http://z80.eu/for-compiler.html

If all you want is to edit and compile a few sources, the Unix approach may be faster. If the journey is the important bit here, I would start with getting the fortran toolchain up and running.
 
One issue with ISX.COM is that it needs to put a fake MDS-800 ROM at 0F800H and most 64K CP/M systems are already using that memory and won't tolerate it being trashed. I think that if you make a 62K CP/M image and boot from that, it would work (provided your platform does not use that memory - I suspect a Kaypro won't work ever). I'm going to try this out on my CP/M emulator, after adding the option to drop down the top CP/M address.
 
durgadas311 said:
One issue with ISX.COM is that it needs to put a fake MDS-800 ROM at 0F800H and most 64K CP/M systems are already using that memory and won't tolerate it being trashed. I think that if you make a 62K CP/M image and boot from that, it would work (provided your platform does not use that memory - I suspect a Kaypro won't work ever). I'm going to try this out on my CP/M emulator, after adding the option to drop down the top CP/M address.
Click to expand...

Oh yeah. Since my first post I've gone through what I had at the time, and more found since. I went through ISX.COM with DDT and it's all "round number" addresses and jumps ("JMP 3000H" etc). Total kludge. I've read through what's there on how it works: it was a crock through and through. A customized BIOS, that hole at f800, customized BDOS (to calc exact filesize), etc. ISX.COM fills in MDS-800 ROM jump table probably into itself or the CPM BIOS. I could do that hack on my fZ80 fairly easily. Not sure I want to. fZ80 is about cleaning up MP/Ms rough edges byt applying modern knowledge to old tools.

I realize that in 1980 (plus minus) serious dev work was done on larger machines. My desire to run PL/M on CP/M is "not reasonable" and certainly not how DR did it. The kludgey complexity of this probably means I won't pursue it much further at this time.

But in those piles of files are Y2K-repaired TOD.PRL and SCHED.PRL and they work! Oh, if only Hector had done SDIR.PRL...

EDIT: The source to ISX.COM is ISX.ASM, and in the ISX14.ZIP. Hector found a lot of interesting stuff!
 
Last edited:
horo said:
I combined the CP/M3 source code and build tools for system, utilities and applications in my repo – ready to use on Linux.
Click to expand...

Great! With the goal of generating a Y2K-fixed SDIR.PRL, I may install a unix cross compiler. I'd hoped to have a resident PL/M for other work, but that's increasingly a silly idea.
 
tomjennings said:
Oh yeah. Since my first post I've gone through what I had at the time, and more found since. I went through ISX.COM with DDT and it's all "round number" addresses and jumps ("JMP 3000H" etc). Total kludge. I've read through what's there on how it works: it was a crock through and through. A customized BIOS, that hole at f800, customized BDOS (to calc exact filesize), etc. ISX.COM fills in MDS-800 ROM jump table probably into itself or the CPM BIOS. I could do that hack on my fZ80 fairly easily. Not sure I want to. fZ80 is about cleaning up MP/Ms rough edges byt applying modern knowledge to old tools.
...
Click to expand...
The fake MDS-800 ROM is necessary because those interfaces are "public" and may be used by any ISIS-II program. I don't know if any of the compiler/linker stuff uses them, but they could. And since the address is hard-coded at F800 you're kind of out of luck on any non-MDS-800 (64K) system. The rest of the code is not so terrible, doing what it does (emulate ISIS-II), but it was written in PL/M and so looking at a disassembly you are seeing the artifacts of the compiler. It looks awful unless you take that into account. Still, it's not a general-purpose utility (for any CP/M platform) and was just "good enough" for what DRI needed. I'm still not sure whether these SUB files were run on CP/M or something else. ISX.COM does take over the "$$$.SUB" file and act like the CCP for that, so those SUB files might have actually worked under CP/M (on an MDS-800). I thought I had seen more evidence in SUB files of being run on something like a VAX, but have not done an exhaustive search for examples.

I've gone to doing my builds on Linux for a lot of reasons. But I still use DRI tools (in a CP/M emulator) - especially for things like GENSYS, GENCOM, GENCPM. There's also a problem with REL files created by native Linux tools like zmac, where they use some special linker codes that DRI tools don't recognize (i.e. you can't use zmac and then DRI LINK.COM). I needed DRI LINK.COM in order to create PRL, SPR, BRS, RSP files and so couldn't use zmac (had to use RMAC.COM). It just made more sense to use all DRI tools in the compile chain. I did make some changes to ld80 (used with zmac) to create PRL, SPR, RSP, BRS files, but haven't gone back and changed my builds. And for PL/M, I use "thames" and the original ISIS-II tools.
 
Discovered something else interesting about ISX.COM, although that's probably a dead horse by now. It contains a complete copy of the BDOS (can't tell which version, guessing 1.4), built to run in low memory and access the BIOS via the JMP at 0000h (BIOS address at 0001h). I think the reason for this is to save that extra memory for ISIS-II programs, which operate in the area above 3000h. My guess is that this extra memory is important, at least on smaller systems. This creates a problem for my CP/M emulator since that uses native files and relies on BDOS calls, not BIOS (disk I/O) calls. But, this gives a clearer picture of the design.
 
I think I've gleaned from the mess of docs that the ISIS TPA begins at 4000h, hence all the low-ram nonsense.

Oh, the hacked BDOS is contained in ISX.COM?! Hmmm I could very easily make my machine free up f800h up. The BIOS edits are simple enough. If there was some compelling reason I could do this. My tendency is to not. And who knows what troubles there would be even if it worked.

Yeah I found those .SUBs interesting too. They do look like mixed ISIS and CP/M. Perverse. And relying on the weird ISIS file-not-found-try-lower-drive stuff, yeah no thanks!

Reminds me that it is no longer 1980, and that is good.
 
The ISIS-II base address for programs starts at 3000h, higher depending on number of buffers you want. I didn't dive into the details, but looks like you can place your program almost anywhere in the range above 3000h, limited by your top of memory. The ISIS-II executable contains the base address and start (entry) point, so it is more sophisticated than a CP/M .COM file. The ROM is usually mapped at F800 but depending on how much RAM is installed you may not have that much. ISIS-II "owns" RAM between 0000h and 3000h. So, the layout of ISX.COM reflects that.
 
You must log in or register to reply here.
Back
Top