An I/O Library for M-DOS/PC-DOS written for PL/M-86 using PL/M-86

[Mike Gillmore]

I have created a run-time library for PL/M-86 using PL/M-86.  The first version was created in early 1986.  It allowed me to port applications from the Intel ISIS-III environment to DOS.

Revision 2 was written starting in 2012.  It was a re-creation of the a run-time library for the 32-bit Windows console, and of course, with full support for the DOS environments.

This work is free of charge.  If you would like it, I will zip all of it together, and send it to you.

You are doing a great service to the history of a lot of the early history of micro-processor computing.

Here is the introduction to the project, written for the API document.

Foreword

The ACME Menu application was first written in 1986, then went dormant a couple of years later with the release and subsequent use of Microsoft Windows 3.1. In the DOS days, everything was done at the command line, with LOTS of repetitive typing. If you were not a typist (I'm not, really) it was tedious indeed.

Move forward to 2019. I retired from software engineering, though the timing was not of my own choosing. I wanted to improve the applications that I had written all those years ago, so I found a DOS look-alike that would run on Windows, and got to work.

My first challenge was to find references that were still available in book form. With the help of a couple of world-wide web sites, I was able to recover two of my favorites: The Peter Norton Programmer's Guide to the IBM PC & PS/2 by Peter Norton and Advanced MS-DOS by Ray Duncan.

Next on the list was finding a copy of the long since abandoned PL/M-86 compiler. Thanks to the Vetus Software site, another problem solved. Now came the real work. I remembered that there was no operating system API available, so I had to write my own. The earlier version was mostly implemented in x86 assembler, with some of the higher level functions in PL/M-86. The problem was that it meant LOTS of work any time the memory model was changed.

Not wanting to go down that path again, I took advantage of my experience to make the task of writing applications easier. The first step down the new path was to allow the application's entry point (from the programmer’s perspective) to be a function called "main" which accepted three parameters and returned an integer, just like those applications written in C, C++ and many other languages.

Since DOS applications have some specific requirements at the start, and since much of the necessary information was available only in the context of the starting instruction, the first lines were written in assembler, but passed to PL/M as soon as reasonable. In that first assembly language module, I made the first improvement to the developer's API, I initialized the static heap to zero. This allowed the programmer to make assumptions about the initial value of variables defined on the heap. Detection of initialization was now possible.

Also absent from those early versions of the (Intel) UDI-like environment was the ability to dynamically allocate memory. Since I wanted the ability to allocate memory dynamically in my applications, I chose that task next. That took all of 8 lines of assembly (with 17 lines of comments so that I would not forget WHY I did it).

Next came the real work of the startup code. For that, I moved to PL/M. It is here that I parsed the command line, and initialized an array of pointers to character strings for the command line parameters, commonly referred to as argv in the C language programming references. That is perhaps the single largest improvement in the API from the developer's perspective. No more calls to DQ$GET$ARGUMENT for each of the application's arguments. These arguments could be referenced in any order desired, and could be read many times, not just once.

Now that the initial code was in place, application development could begin. However, those first few simple applications took a LONG time to develop. While PL/M was a great language for embedded microprocessor applications, there was no library of useful utilities to manage I/O, strings, memory or anything else of that nature. This led to the next necessary feature of the environment: executing calls to DOS and the BIOS from PL/M-86, and not resorting to assembler every time.

The early C libraries for DOS had a function called int86() which allowed the programmer to set values in registers, and execute the appropriate interrupt. This is perhaps the greatest challenge yet: CPU registers must be initialized before the interrupt, and then captured and returned to the caller without context loss.

With that next critical piece in place, the creation of the I/O portion of the library was substantially easier. I could rely on the system call functionality provided by int86() to make the job easier. What followed (quite quickly actually) was the low level I/O in files and the user interface.

Of course, there is no reason to have file I/O if you are not going to use it, so I re-created one of my first serious applications for DOS: fprint. Indeed, there was a rudimentary version of that even before I discovered DOS and the IBM-PC. But this version was going to be faster, cleaner, and more likely to be used.

The next big challenge was to make the parsing of the command line easier and more consistent. I did not want to require that the parameters to be specified in a particular order. I also did not want to have command line parsing code repeated in every application.

My experience taught me that a common parser was more valuable than some might expect. As a model, I grabbed the simple API model from the Python library, and implemented it. That let me specify parameters in any order I wished. That was a huge improvement. I could now specify what arguments and modifiers were acceptable, and provided both a short version and a longer version to be specified. If the user wanted to know the acceptable command syntax, that could be provided using the same information provided to the command parser. Two wins with one API.

Lastly, there are two more things that I always wanted to do in my own API, printf() and its other related functions fprintf() and sprintf() which allow for the easy formatting of information, and strftime() which allows me to format the date/time string as I wish. The date/time report formatter was relatively easy since there is a fixed number of command arguments.

printf()/sprintf()/fprintf() would be a bigger challenge because the PL/M language syntax does not allow direct function calls with a variable number of parameters. I could make an indirect call (through a pointer) with no problem, but how could I find the first argument in the function list CONSISTENTLY? If called through a pointer, the function addressed by the pointer can NOT have any arguments, or the calling sequence is different. I found a method that works, but only when not called from a reentrant function.

(update: printf()/sprintf()/fprintf() may reliably now be reliably called from reentrant functions)

[William Beech]

Mike,

We would be glad to receive your work to add to the archive.  Are you willing to release it into the public domain?

Thanks!

Bill

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/0e128c3e-1c55-48f4-8522-49fb432206ffn%40googlegroups.com.

[Herbert Johnson]

This is interesting because it explores the MS-DOS environment for
PL/M-86. a lot of Intel work in discussion here, has not been in MS-DOS.
There have been ports of Intel ISIS tools to C source and thus to run in
modern environments that some C compiler supports. One still needs a
robust library per OS and compiler, to get something useful, seems to
me. 32-bit early Windows is a more complicated environment, harder to
make libraries, busier C compilers, etc.

I'm not quite sure, how 32-bit MS-DOS works with various Windows OS's.
the earlier Windows simply supported an MS-DOS shell - the "32-bit
console"? Later Windows gave up (most of) that environment: that's
beyond my skills set. I still produce 32-bit C Windows compiled programs
that run at the command line level - they perform tasks that aren't
graphical, aren't click-n-drag, etc. Most will compile with 16 bit
MS-DOS compilers.

I have no problem with tools that work in older Windows environments,
there's plenty of devices and projects one can do in vintage computing.
Windows 95 is now 30 years old (go figure) and some vintage interest is
emerging there. And there's always the gaming crowd, that is drawn to
any gaming platform - any - and Win 95/98 has its share of games and
video card technology (or emulation). I don't anticipate there will be
graphics from running PL/M-86 / early Windows, but maybe there will be
basic window management. MS-DOS explored text and graphical screens
(Turbo C / Pascal for instance).

So this is welcome work to me. Thanks to Mike Gillmore. Making vintage
work available to all, seems to me to be the point, that's how you
refine it and get it into use, debugged, etc.

It would be good to find some PL/M-86 application codes from the era.
That's most likely to be industrial; not a lot of that has bubbled up
over the years that I'm aware of.

Regards Herb

On 5/5/2025 12:21 AM, William Beech wrote:
> Mike,
>
> We would be glad to receive your work to add to the archive.  Are you
> willing to release it into the public domain?
>
> Thanks!
>
> Bill
>
> On 5/4/2025 4:32 PM, Mike Gillmore wrote:
>> I have created a run-time library for PL/M-86 using PL/M-86. The first
>> version was created in early 1986.  It allowed me to port applications
>> from the Intel ISIS-III environment to DOS.
>>
>> Revision 2 was written starting in 2012.  It was a re-creation of the
>> a run-time library for the 32-bit Windows console, and of course, with
>> full support for the DOS environments.
>>

>> _*This work is free of charge*_.  If you would like it, I will zip all

>> of it together, and send it to you.
>>
>> You are doing a great service to the history of a lot of the early
>> history of micro-processor computing.
>>
>> Here is the introduction to the project, written for the API document.

--
Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[Mike Gillmore]

https://drive.google.com/file/d/1kWSyoylFsfcNIZdAfhDj88q0Aywu7jlf/view?usp=sharing

This is a link to the zip file in my Google drive.

---

Mike Gillmore

Marion, IA

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/9a57b88d-1202-40bd-b5f4-f4fe91cfb31b%40retrotechnology.com.

[mark.p...@btinternet.com]

Mike

Downloaded many thanks

Mark

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/CA%2BJgass6N3ML%3DangbJb3d-xDTj4D1aNwi0LTcqwPqz1L7E_p8g%40mail.gmail.com.

[mark.p...@btinternet.com]

Mike

The code is now in my Intel repository on the web at  https://mark-ogden.uk/files/intel/msdos/DOS%20IO%20Lib/

I have added a readme.txt to acknowledge that you wrote the code and also a  pdf version of the DOSLibrary documentation with bookmarks to help navigation.

 

Mark

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/000901dbbde0%242223d820%24666b8860%24%40btinternet.com.

[Mike Gillmore]

Here is the link to the tools that I used ...

https://drive.google.com/file/d/1xMByl2gfHxTR6A5RFwB1qsgaasedQiW-/view?usp=drive_link

> Mike

[William Beech]

Mike,

I have also downloaded the file.  Thanks.

Will await your final cleanup!

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/CA%2BJgass6N3ML%3DangbJb3d-xDTj4D1aNwi0LTcqwPqz1L7E_p8g%40mail.gmail.com.

[William Beech]

Mark and Group,

You are fast!  That was nice integration.

Now the question:  Do we want to venture into the MSDOS and PCDOS world here?  If so, I have reworked all the BIOS ROMs source code for the PC, PC XT, PC XT 286, and PC AT to build on win11 with the latest MASM and LINK, and produce byte-for-byte images of said ROMs.

I have also done this for PCDOS 0.90, 1.00, 1.10, 2.00 working on, and 2.11 for the BOOT, IBMBIO, and IBMDOS.  Will work on the CUSPs next.  I Have also got MSDOS 1.25, 2.00, and 4.00 from the Microsoft Release to build the same way.  I need to do some clean up, but we have a lot of that history available.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/001a01dbbde2%240f1e3ca0%242d5ab5e0%24%40btinternet.com.

[Mike Gillmore]

There are 3 directories of interest:
 
Lib - the source and a Makefile which allows you to build the I/O library
Apps - the source and a Makefile to create a binary file viewer, an ASCII file viewer, and a "menu" re-created from the old days of DOS 3.10
TestApps - the source and a Makefile to create the apps I used to do  testing of my library

DOSDocuments contains a .docx which explains the I/O API and describes the Apps that I created

[mark.p...@btinternet.com]

Bill

From a purely personal perspective I would suggest we keep to Intel hardware, OS and unique tools e.g. PL/M86 along with source code written using these tools. If we extended to MSDOS/PCDOS or CP/M I fear the group would start to lose focus.

 

There are many other fora and repositories that cover MSDOS/PCDOS and CP/M. They also have many more active members who would appreciate your work.

 

I would also note that if you are considering early MSDOS/PCDOS then versions before MSDOS 3.x existed for several non standard implementations, as companies created personal computers without copying IBM.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/2b60175f-38f3-473a-a193-f359b3e71791%40nj7p.info.

[Herbert Johnson]

I'm just responding as these considerations of Bill Beech and Mark Ogden
are written. My knowledge is incomplete so those who know more, can poke
at my reasoning and premises. and "if I had more time, I'd write a
shorter letter", I have things to do today.

It seems to me, the overlap between MS-DOS and ISIS, commodity PC
hardware and Intel Multibus, are the INtel PL/M-86 tools designed to run
on MS-DOS (and I guess 32-bit command line Windows) commodity systems.
Intel presumably provided PL/M-86 for MS-DOS tools, as a bridge between
those two hardware and software platforms. "A bridge" means for
instance, doing PL/M development on a PeeCee, then porting some/all
results to target Multibus systems. Or maybe vice versa, I can imagine a
Multibus system that has to talk in some fashion to MS-DOS systems.

(I'm neglecting CP/M in this analysis. CP/M isn't that hard to cover,
and it's been covered, as far as I can tell.)

Given that description, I'd be curious to know the boundaries between
running PL/M-86 on MS-DOS, producing applications, as Mike has done: and
how those applications migrate over to the Intel Multibus systems we
here run under various INtel OS's. Or perhaps, development of embedded
applications without an OS on the target system (the application is the OS).

Also: What Mike seems to have done, is to come up with a more robust
PL/M-86 platform for MS-DOS 32-bit applications development. I presume
that's what his libraries are about. They beg the question: why didn't
Intel provide those?

NOw, to my general impressions about this group. It's focused on
development tools and OS's, not applications, upon various Intel
Multibus hardware and Intel supplied OS's; with an exception into Xenix
which amounts to archiving whole implementations.

I haven't seen much traffic or archiving of *applications*. They will be
harder to find, possibly proprietary - although Intel codes and sources
are/were proprietary in their time. My point being: application code for
Intel Multibus systems is a little scarce.

That said, various individuals work on various things for their own
reasons. We see that Bill Beech is well into the (IBM branded?) PC-DOS
(early stuff) and MS-DOS (to 4.0) world. It's his call but it seems
reasonable for him to wrap PL/M-86 under MS-DOS into his coverage. The
question he raises, is to ask if anyone else is interested. My guess is
Mark Gillmore will be, maybe. Depends if Bill can work up to 32-bit
MS-DOS and Mark can work down to 16-bit MS-DOS - I think I've put that
question correctly.

(Converse question for Bill Beech: Did Intel or someone (or you) support
MS-DOS on Intel 80X86 Multibus hardware? I've not looked for it, I don't
recall now but it may have happened at the time. It more likely occurred
in the early MS-DOS days, before graphics dominated personal computing.
I don't expect Windows 3.1 or 95 on Intel Multibus. But Windows up to
2.0 found itself on Zenith Z-100's (8088 with a S-100 bus), and
certainly early MS-DOS ran on 8086/88 Compupro systems. Windows 3.X
needed 80386 memory management.)

Also: I've not seen much interest (here, elsewhere) in applied Intel
Multibus systems. They ran all kinds of things. It's unwieldy today to
run an Intel Multibus system application - people don't have
photocopiers in their basement with Intel Multibus cards, or machine
tools, or some chemical mill, or ATM machine ... you get the idea. It's
the same thing with S-100 systems, CP/M systems, STDbus systems: people
mess with all those as architectures, but not so much on the
applications side. Just the original branded hardware and branded OS's
(notwithstanding TurboDOS and some odd hardware bits).

But development tools for applications are fair game, they don't suffer
application-hardware limitations like I mentioned. So, "sauce for the
goose ...", a PL/M-86 compiler under MS-DOS must be like a PL/M-86
computer under an ISIS (286? 386?) OS.

So: Mark Gillmore brings an entry into the Venn diagram of 80386 (maybe
earlier) class hardware, some overlap between Microsoft and Intel
software, and IBM and INtel hardware, with PL/M-86 for MS-DOS. I've
suggested some of that overlap. Bill Beech does too as he (and now I)
described. So what to make of those opportunities?

Well, factually, everyone does their own thing while sharing results.
Sharing creates synergies, not to mention an audience (usually an
audience is a good thing). And, an audience brings more interest,
interest brings more stuff (people find software and hardware, discuss
results, etc.) That's how collective activities prosper. So: some amount
of diversity should be welcome.

But Mark Ogden points out the notion of "focus", that is collective
focus. Enforcement of that is setting boundaries within the Google Group
discussions. I'm suggesting some areas, the "Venn diagrams", where each
of us can decide where our individual interests lie. But a collective
identity, that is the general topic of the list, is Intel development
systems. Yet Intel developed a set of MS-DOS tools for their PL/N-86
.... seems like a candidate ...

As to the reasonable note Mark Odgen points out:

> There are many other fora and repositories that cover MSDOS/PCDOS and CP/M. They also have many more active members who would appreciate your work.

Well, that was a commodity computing world, but it's an old world. A lot
of that community is aging out. As they go, they often take their
archives and Web sites with them. Still, given their large numbers, and
the numbers of new people coming on, it's plausible to *think* they
don't need our help.

By contrast, Intel Multibus "hobby" support got pretty thin, back there
a few decade ago. It's a little better now. But those working this turf,
are busy enough, and our numbers here are small.

It's fair to decide where one's interest are more needed, and of course
where one brings more to the table. Our colleagues in this group, are
very, very skilled from the era. That won't repeat itself when we (you
guys, I'm small fish) go away as we eventually will. so, doing what we
did before, but not far beyond that, is a plausible consideration.

But let me suggest a contribution *we* can make to the MS-DOS world,
from our collective skills sets and resources. and it's a response to
Mark Ogden's assumption.

I doubt most MS-DOS interested persons today, ever heard of PL/M-86.
It's impact in the MS-DOS world was very modest. CP/M had more impact of
course, it ran stuff before MS-DOS was replicated from CP/M. But
interest in CP/M-86 and successor DRI OS's did not prove out: MS-DOS
dominated, then Windows, in the commodity PC world.

[I've worked the world of Digital Research product preservation. It was
a tough go for some decades. Now it's easier for reasons I wont'
elaborate. But those same reasons have helped our Intel Multibus cause too.]

[Also, as an aside: The IBM OS/2 contingent, probably shares more
circumstances with "us" than the MS-DOS people. They too are recovering
and sustaining a quickly-abandoned OS, and with PS/2 PCs an abandoned
architecture. No Venn diagram of overlap with our interests. But maybe
some common causes?]

So my asides on DRI and OS/2, amount to examples where IBM PC
architectural interests outside of MS-DOS don't get a lot of support
compared to the bulk of the IBM PC vintage world.

So it seems to me, there's some room in the Intel development system
universe, for Intel's *other* development tools in the MS-DOS world,
with PL/M-86. The MS-DOS gamers, the rebuilders of 80686 and later
systems, the IBM PC collectors - they are not doing applications
development. They are running OS's and applications and that's their
thing. I'm skeptical they will show interest in an abandoned high-level
language that supports no applications they've ever heard of. Whereas,
the collective interest here in Intel products of a certain era, covers
an Intel development tool like PL/M-86 for MS-DOS: and would welcome
some new extension of that tool for further MS-DOS application support.

-----------------------------------------

Those are the sort of arguments I see on the matter. I've likely made
assumptions outside my knowledge but I think I've got the ideas and the
general landscape laid out OK. It's a long lecture but I covered a lot.
I welcome correction and discussion. I hope I encouraged some further
considerations.

regards Herb

On 5/6/2025 6:16 AM, mark.pm.ogden via intel-devsys wrote:
> Bill
>
> From a purely personal perspective I would suggest we keep to Intel
> hardware, OS and unique tools e.g. PL/M86 along with source code written
> using these tools. If we extended to MSDOS/PCDOS or CP/M I fear the
> group would start to lose focus.
>
> There are many other fora and repositories that cover MSDOS/PCDOS and
> CP/M. They also have many more active members who would appreciate your
> work.
>
> I would also note that if you are considering early MSDOS/PCDOS then
> versions before MSDOS 3.x existed for several non standard
> implementations, as companies created personal computers without copying
> IBM.
>
> Mark
>

> *From:* *William Beech
> *Sent:* 05 May 2025 20:20
> *To:* intel-...@googlegroups.com
> *Subject:* Re: intel-devsys An I/O Library for M-DOS/PC-DOS written for

> PL/M-86 using PL/M-86
>
> Mark and Group,
>
> You are fast!  That was nice integration.
>
> Now the question:  Do we want to venture into the MSDOS and PCDOS world
> here?  If so, I have reworked all the BIOS ROMs source code for the PC,
> PC XT, PC XT 286, and PC AT to build on win11 with the latest MASM and
> LINK, and produce byte-for-byte images of said ROMs.
>
> I have also done this for PCDOS 0.90, 1.00, 1.10, 2.00 working on, and
> 2.11 for the BOOT, IBMBIO, and IBMDOS.  Will work on the CUSPs next.  I
> Have also got MSDOS 1.25, 2.00, and 4.00 from the Microsoft Release to
> build the same way.  I need to do some clean up, but we have a lot of
> that history available.
>
> Bill

[Jon Hales]

A brief response to Herb's asking whether Intel offered MS-DOS for a Multibus system.

Yes, for the System 310 - which uses Multibus 1 cards. I have seen an advert which supports the assertion (but no trace of the software). I'm busy and don't have a copy to at this moment.

I'm not aware of MS-DOS for Series II, III or IV MDS systems (and their year(s) of manufacture suggest the answer in that case would be No)..

Regards

Jon

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/2e0c7984-e34a-4852-813c-0e4bfc80373a%40retrotechnology.com.

[William Beech]

Mark,

Good points.  I will look for other avenues to post this material.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/00d401dbbe6f%24ed4dae60%24c7e90b20%24%40btinternet.com.

[William Beech]

Herb,

I have to agree with Mark on focus.  I suspect I can find other groups
that are more in to the CPM, MSDOS, and PCDOS stuff.  Any ideas?  Send
me a personal email.

There was overlap as Intel moved from the MDS IV to PC-based tools. I am
not sure if they progressed their ICE devices to be supported on a PC. 
But certainly the tools and languages are present as PC executables.  I
believe the networking on the Intel MDS IV was an early version of SMB,
just as the early networking on the PC.  We used Zenith 248's (PC AT
Class) with PCLINK 2 ethernet cards on ThickNet to talk to the Intel
310's and 320's with iSBC-550 Ethernet cards with OpenNet.  It was VERY
smooth networking.

Yes, the MSDOS, PCDOS, and CPM are all covered elsewhere.  I need to
Google it!

It gets back to the chicken and egg problem.  We see it in all our old
systems.  I have kludge system XXX that has a boot ROM and Monitor that
can load software modules in Intel Hex.  I have software and disk images
off the internet on my PC.  How do I get them onto XXX so I can run
them.  We have had several answers here for ways to do that.  I have had
the best luck with Intel or Motorola Hex formats for moving software to
XXX with a Monitor with Hex load and save capability.  You can also move
Kermit or XModem to XXX and use the corresponding tool on the PC.  Much
more difficult to produce physical disks on the PC for XXX's FDC.  App
as the OS is another solution.  But the chicken and egg problem has
haunted us all since the beginning!

Archiving is at the heart of what we have done here.  We have rooted out
a large volume of hardware and software of the Intel Intellec and MDS
machines.  Who would have thunk 20 years ago we could find so much of
this stuff?

My initial effort was to be able to create CPM and MS/PCDOS applications
and disk images without finding all the OLD software to build it.  Why
not use the final versions of MASM and LINK on a Win11 PC to compile the
source code?  It was not that hard.

We have the Intellec, MDS, and Xenix software for the Intel product
line.  We have seen it work on the actual hardware and on simulators. 
We have the languages and office tools they used.

Intel had an OEM port of MSDOS for the Intel 310 and 320.  I never used
it, but I know it was there.  It is one item I am still looking for. 
But we could take one of the OEM kits and create MSDOS for the 310 and
320.  It could be run on an MDS III or IV using an 80XX8 board.  That
would be a larger challenge.

I believe there are still multibus systems running some commercial train
stuff.  And I had multibus boards that ran a commercial flight
simulator.  There was CNC stuff.  I know there is something keeping the
current multibus vendors/repairers in business.

I will stop here. Herb makes some good points.  But there is one other
thing.  What happens to all our work when we are gone?

Bill

[Mike Gillmore]

Just a couple of comments.  First, Intel developed PL/M-86 as a compiler for embedded microprocessor work generally.  In my case, the library came about because we were using the PC as out development platforms, targetting an embedded microprocessor product.  While Intel had an in-circuit emulator (I2ICE), we used that for hardware/software integration.

Since every developer had a PC, we decided to use the PC for module testing.  Revision 1 (really more like Revision 0.5) of the I/O library was created to help.  I wrote most of it,  then gave it to the company for whom I worked.  It was quite simple, just a simple read and write API.  (This was early in 1986)

In 2015 (or thereabouts), I finally had some time to develop a PL/M-86 API the way I always wanted to do.  The result of that decision is what I have given to you.

Use it in good health.

> Mike Gillmore

[Herbert Johnson]

Bill brings up some points about communications and file transfers
between generations of systems that don't share a common mass-storage
technology. Solutions have been discussed before. I appreciate calling
this "chicken and the egg" problems, my term is "20th vs 21st century"
problems in file systems.

Bill is informative to me, when he mentions Ethernet and networking as a
means to connect cross-platforms in the era of transition away from
Multibus. If there's more examples, I'm interested.

For example: I have a rack-mount box than runs/ran some OS, I think
MS-DOS?. It has both a PC ISA bus *and* a Multibus card cage. I have not
thought much about it, but it represents that transition. I'll take time
another day to describe it, see if it still runs.

There was a lot of industrial ISA PC-class equipment in the 1990's, I
did not think a lot about it at the time, "water to fish" is what I call
it. Now of course to modern eyes, it makes no sense, there's no
recognition beyond "oh yeah, some old PC-AT bus stuff".

So we have to do all the recognition, so people can determine what
ancient thing they found, so they can find a home for it. Thus our Web
pages.

Regards Herb

[Herbert Johnson]

On 5/6/2025 9:55 PM, Mike Gillmore wrote:
> Just a couple of comments.  First, Intel developed PL/M-86 as a compiler
> for embedded microprocessor work generally.  In my case, the library

> came about because we were using the PC as our development platforms,

> targetting an embedded microprocessor product.  While Intel had an
> in-circuit emulator (I2ICE), we used that for hardware/software integration.
>
> Since every developer had a PC, we decided to use the PC for module
> testing.  Revision 1 (really more like Revision 0.5) of the I/O library
> was created to help.  I wrote most of it,  then gave it to the company
> for whom I worked.  It was quite simple, just a simple read and write
> API.  (This was early in 1986)
>
> In 2015 (or thereabouts), I finally had some time to develop a PL/M-86
> API the way I always wanted to do.  The result of that decision is what
> I have given to you.
>

> Use it in good health. - Mike Gillmore

Well, Intel of course provided Multibus products in the 1980's as a end
hardware solution for some industrial and product applications; and
INtel microprocessor chip families for customized microprocessor
controllers for other smaller/cheaper applications. Certainly Intel
Multibus was a development platform early on.

PL/M-86 executables, like any other high-level language, also need an
I/O library and sometimes a file system and sometimes an OS which
combines all of those. (CP/M-80 became the 8-bit version of that
progression for PL/M-80.) The 1980's was a transition from "let's use
Intel systems for development" to "let's use IBM PC systems for
development" to "let's use PC's for applications". Even Intel started
making PC motherboard designs, which were adapted for commodity PC
computing.

But - correct me if I'm wrong - it appears that Intel did not develop a
robust PL/M-86 API (I/O library plus FAT-file library) for MS-DOS
applications. It was sufficient to compile PL/M-86 under MS-DOS, with
customer-produced libraries and API's that were NOT tested (to their
hardware) on MS-DOS PCs, but tested on the target application hardware
(which were not PCs at Mike's shop at the time). But Mike apparently saw
that PL/M-86 *could* be a *MS-DOS application language*, or at least
better test embedded software, if it had a more complete MS-DOS / IBM-PC
library.

Or - Mike's company didn't spring for the cost of Intel's available
support for MS-DOS applications. Or - Intel didn't go that route until a
later time, or never, or at least after Mike wasn't doing that work at
that company anymore. So I'm asking Mike about Intel's PL/M-86 product
line at points in time, and what Mike (or his employer) had in mind at
the time.

I don't want to sidetrack the discussion, with Digital Research's
PL/M-86 products. But Mike, did you or your shop consider any software
tools from DRI? Or were DRI products simply considered incompatible with
your Intel and IBM-PC sets of tools?

regards Herb

[mark.p...@btinternet.com]

Herb

A number of the Intel DOS tools were written to run under iRMX UDI framework. They were then wrapped into DOS files using UDI2DOS. A consequence of this is that file names had to meet the iRMX convention of upper case letters and digits. In use it also means that if you are using an emulation environment long path names or with spaces cause a problem. Even the 8.3 name mapping done in later versions of DOS don’t work as the usually use ~ in the mapped name and this isn’t a letter or digit. 

Mark

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Herbert Johnson <hjoh...@retrotechnology.com>
Sent: Wednesday, May 7, 2025 6:16:16 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>; Mike Gillmore <mike.g...@gmail.com>
Subject: Re: intel-devsys An I/O Library for M-DOS/PC-DOS written for PL/M-86 using PL/M-86

 

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/f91ccfc8-a42a-48ab-b457-858747d0855a%40retrotechnology.com.

[mark.p...@btinternet.com]

Herb

Forgot to note Digital Research had a PL/I compiler which targeted a different market sector from the embedded systems PL/M targeted. 

Mark

Regards

Mark Ogden

---

From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: Wednesday, May 7, 2025 7:48:21 PM

[Herbert Johnson]

On 5/7/2025 2:53 PM,

> Herb
> Forgot to note Digital Research had a PL/I compiler which targeted a
> different market sector from the embedded systems PL/M targeted.
> Mark
>
> Regards
> Mark Ogden

> ------------------------------------------------------------------------
> *From:* Herbert Johnson <hjoh...@retrotechnology.com>

>
> I don't want to sidetrack the discussion, with Digital Research's
> PL/M-86 products. But Mike, did you or your shop consider any software
> tools from DRI? Or were DRI products simply considered incompatible with
> your Intel and IBM-PC sets of tools?

Mark is right. PL/I was an IBM mainframe/IBM minicomputer product. DRI
introduced a PL/I compiler into CP/M-80 and maybe CP/M-86. A few other
microcomputer and maybe minicomputer companies had some kind of PL/I
derivative products. I don't know much about DRI's PL/I or other PL/I's,
so my site doesn't cover PL/I. (I have one mention of it, in an
interview of Gary Kildall. But bitsavers and other archives have DRI
PL/I product content.)

PL/M was created by Gary Kildall for Intel. Kildall created Digital
Research Inc (DRI) to distribute CP/M, written in INtel's PL/M. Intel
produced a number of PL/M products for their Intel microprocessors. And
others including DRI used the PL/M scheme and produced PL/M related
microprocessor products - *except*, DRI did *not* produce a PL/M for the
8080 or 8086.

DRI moved into the IBM PC / MS-DOS world with C and assembler for their
MS-DOS-compatible OS's (and of course with CP/M-86 which was not MS-DOS
compatible). DRI's MS-DOS-friendly OS's could apparently operate other
MS-DOS compatible compilers and development tools. But I don't think DRI
produced a PL/I for the MS-DOS world.

My error, then, to suggest DRI would have PL/M compatible alternatives
to Intel's PL/M 808X or MS-DOS compilers. Intel carried that ball, not
Digital Research.

This is an odd thing, to discover in 2025 that there's ground I've not
covered in the 808X world of Intel, DRI, and early MS-DOS. A bit of
noodling today finds this informative Web page list of Intel documents
to 1988:

http://www.bitsavers.org/pdf/intel/_catalog/210621-029_intelLitCatJul88.txt

Sure enough, PL/M from Intel was provided for the 8080, 8086, 80286; and
for ISIS, MS-DOS, iRMX-86, Xenix 286. Also as cross compilers for the
8051 and 8096. I've seen on eBay recently, Intel PL/M - MS-DOS documents
for sale.

I cover PL/M history on this page:

https://www.retrotechnology.com/dri/dri_plm.html

I'll likely add Mike's PL/M and MS-DOS work on this Web page:

https://www.retrotechnology.com/restore/isis.html#archive

because his PL/M work was refined in the 21st century, as was/is other
Intel-related work on that particular Web page.

- Herb

[William Beech]

Mark,

I know.  I own the PL/I compiler.  I got it hoping I could use it to work on operation systems.  But I found C so much better for that task during my early 80's sweep of languages.

Bill

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/VI1PR05MB4413212CD5EC6EB57770AF39FC88A%40VI1PR05MB4413.eurprd05.prod.outlook.com.

[William Beech]

PL/M was initially developed for the 8008, I believe, in 1974?

Bill

[mark.p...@btinternet.com]

Bill
There is a PL/I-86 that runs on DOS. A copy can be found at https://winworldpc.com/product/digital-research-pl-i-compiler/1x
Mark

-----Original Message-----
From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech

Sent: 08 May 2025 00:46
To: intel-...@googlegroups.com
Subject: Re: intel-devsys An I/O Library for M-DOS/PC-DOS written for PL/M-86 using PL/M-86

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/54f06afb-5c86-4c56-8106-1daf39edea12%40nj7p.info.

[Herbert Johnson]

I spent some time, Web searching on PL/I and DRI today. So there's a
number of archives of PL/I from Digital Research for CP/M 80, MS-DOS
V1.1. Possibly there's an archive PL/I for CP/M-86. Also PL/I was
supported on a variety of mainframes and minicomputers, those
impementations are also archived. And I know in the era, there were yet
other PL-slash-something compilers and interpreters for microprocessors.

But I think it won't be fruitful (at least for me) to work PL/I history
and products, in order to learn more or do more with PL/M from Intel and
DRI, for use with Intel 8080's and 8086's and later Intel processors;
including use on Intel equipment. That's the focus that started this
series of posts.

That's my nominal conclusion for today, but I'd welcome any confirmation
or argument from someone with more period knowledge. Maybe Mark can
speak to any PL/I interest he or his employers had at the time?

Regards Herb

On 5/8/2025 9:41 AM, mark ogden

> Bill
> There is a PL/I-86 that runs on DOS. A copy can be found at https://winworldpc.com/product/digital-research-pl-i-compiler/1x
> Mark

>> On 5/7/2025 2:53 PM,
>>> Herb
>>> Forgot to note Digital Research had a PL/I compiler which targeted a
>>> different market sector from the embedded systems PL/M targeted.
>>> Mark
>>>
>>> Regards
>>> Mark Ogden

[William Beech]

Mark,

Thanks.  Got it.  I only had the CP/m version.

Bill

[William Beech]

Herb,

PL/I subset G was implemented on many systems.  Full PL/I was on
mainframes in the day.  PL/M is a different beast and not at all related
to PL/I.  Good call not to go down the rabbit hole!

Bill