So, stop me if you’ve heard it before.
You’re browsing eBay when you find a strange item.
You take a closer look at the photos, and you find yourself having more questions than not.
The mystery gnaws on your brain, and you realize that the only way you're going to answer those
newfound questions is if you click that mystical “But It Now” button.
*deep sigh*
That’s the short version of how far too much things have ended up in my collection.
It’s also why I ended up with this weird piece of strangeness: The IBM Personal Computer
Graphical File System.
The name alone made me curious, but what really caught my eye was this little panel on the
back, saying that what you needed was one of a small list of compilers.
It was at that point, I realized what I was holding is a big-box software development
library from 1984.
For those not familiar with software development, libraries are bundles of code that provide
pre-built functionality.
For example, a popular library in the current day is the Simple DirectMedia Layer, or SDL
library, which has been used to help develop numerous games over the years.
Given the name “Graphical File System”, I had initially assumed that it had something
to do with browsing files.
Frankly though after reading the box’s descriptions, I was at a loss.
The little blurb on the front of the box was especially useless in this regard:
“[It is] an ANSI-Metafile standard for storage and transfer of professional quality graphics
on a file-oriented storage system.
The Graphical File System provides highly portable graphics information, and easy-to-use
icon interface to enhance programming productivity.”
To put it bluntly, that was a perfectly good waste of an explanation.
Grammatical issues aside, I legitimately have no idea what this does aside from the fact
that it has something to do with graphics and files.
As it turns out , I would end up falling down a deep rabbit hole trying to solve this mystery.
As usual, this is your host NCommander, and today, we’re going to unbox something strange
from 1984!
With said, take it away past me!
Let's crack the shrikwrap, it, uh already kinda going so ...
It's the first time this has been opened since 1984.
Inside, we have a binder, the hefty install manual, and the five 5.25 in disks.
Let's see if these are readable ...
With the unboxing complete, it was time to break out the SuperCard Pro.
Interestingly, only three of the disks were labeled as part of the Graphical File System.
The other two were labeled Professional Graphics Series Device Drivers.
As the disks were being dumped, I spent the time flipping through the rather hefty manual
trying to figure out just what I had unboxed.
Now, I’ve worked with tech for a long time, and the large slab of documentation was rather
remarkable for one reason.
Throughout the hundreds of pages in this binder, I couldn’t find a single simple description
of what the Graphical File System actually is.
Infact, I’ve read tax code documents clearer than this!
Instead, the vast majority of the manual talks about the larger Professional Graphics Series,
and something called “Metafiles”.
From what I could piece together from the manual and from the Internet, Metafiles were
part of a larger specification known as the Graphical Kernel System, meant to standardize
how computer graphics were done as a whole.
Historically, computer graphics were implemented through proprietary systems with little to
no standardization.
For example, Apple had created QuickDraw for their early GUI efforts on both the Lisa and
the Macintosh.
Meanwhile, Microsoft had standardized on their own GDI interface for Windows 1.0 and later
The same problem also extended to printing, and specifically how graphics could be sent
to a printer.
Just like display and rendering, graphical printing was dominated by multiple proprietary
solutions, most prevalently by Adobe’s PostScript.
The folks behind the Graphical Kernel System specification had decided to solve this problem
through a system of abstraction, and which they called the Virtual Device Interface,
or VDI.
VDI defines a series of commands that define how graphics should be displayed.
These commands could be rendered on a monitor, or they could be sent to a printer.
The best way to imagine this is to think of how you might draw this capital N. You might
use a list of commands like the one on screen.
If we step through each command step by step, you can see how a computer might draw it.
For instance, we may draw two rectangles, and then the diagonal lines to connect them.
Afterwards, we just need to fill in the connected areas, and boom, a giant N.
Of course, being able to send drawing commands is one part of a larger challenge.
For the purposes of interoperability, and compatibility, it’s extremely important
to have a defined format for loading and saving a set of these drawing commands.
That is where the Virtual Device Metafile format comes into play.
Metafiles provides a portable exchange of graphics information to and from a disk.
From what I can tell, the Metafile format was at least partially adopted in industry.
For example, the popular for the era drawing program, Harvard Graphics, is able to both
import and export to and from the Metafile format.
With this newly found information, would it be safe to assume that that the Graphical
File System is a way to create and work with metafiles and embed them into a program?
Well, if we want to know for sure, we’re going to need to set up a development environment.
After dumping the last disk, I used hxc to check the validity of my dumps.
To my relief, all five disks were in good condition with valid bitstreams and no copy
protection.
All I had to do at that point is convert them to raw images.
Afterwards, we can get our first look at the files contained within.
The first three disks which were marked Graphical File SYstem had what you might expect for
a software library.
There was a collection of test applications, library files, and sample sources in C, Fortran,
and BASIC.
Meanwhile, the two driver disks have VDI drivers for a variety of IBM graphics adapters, printers,
and more.
From the manual, these are meant to be loaded from CONFIG.SYS to provide the virtual device
interface as a system service.
Surprisingly, there’s support for quite a bit more than I expected: Beside EGA cards,
there are various drivers for monochrome displays as well as special support for the PCjr’s
16-color mode.
This was something of a surprise because the box itself said that only IBM's original Color
Graphics Adapter and the very high end Professional Graphics Controller were supported.
Still, I’m not complaining since EGA cards are easy to emulate.
With the disks ready to go, I fired up a new virtual machine with an EGA card and installed
PC-DOS 3.3, and then copied the files over.
Since I expected to do some programming, I also installed Borland Brief as a good text
editor.
After fiddling with CONFIG.SYS and AUTOEXEC.BAT, I think we’re good to go.
At this point, I can run the GRID test application which shows that everything is working properly.
Infact, this is a good opportunity to demonstrate the device independence of VDI.
By changing the emulated graphics cards, we can see how the GRID rendering changes.
In each case, the image displays to the best of its ability despite the differences in
both hardware and capability.
It’s also at this point you might notice that the EGA versions of GRID don’t look
quite right.
Notably, the image’s resolution looks off.
I’m not certain if this is a problem with GRID, the VDI driver, or perhaps PCem’s
EGA emulation.
I don’t have a physical EGA card to test with, so I can’t say for certain what’s
going on.
Rather notably, I did get a system hang with the monochrome EGA driver.
If you’ve got a physical EGA card and want to try this, get in touch so we can definitively
rule this out.
Beyond that, I’m going to continue with PCem’s emulated card for now, but I might
come back to this subject if new information comes to light.
With VDI mostly working, we can now load what the manual calls the “Interactive Interface”.
After displaying it’s splash screen, we have what appears to be a drawing program
of some sort, but looks are deceptive.
First off, there’s no mouse support, so moving the cursor is done by pressing the
arrow keys.
Second, there isn’t any actual drawing b be done here.
There’s a set of buttons on the right, but the main purpose of this program is to render
stored Metafiles.
We can do this by placing a rectangle representing a given file on screen, then entering its
filename and the picture ID number.
Multiple images can be placed down and even overlapped.
That’s really all there is to say about the so-called Interactive Interface.
Using Harvard Graphics, I exported a few example metafiles, so we can see all the fancy drawings.
While it’s a neat demonstration, I couldn’t help feel a little bit underwhelmed.
As far as I can tell, the only thing you can accomplish here is to send rendered metafiles
to a supported printer or plotter.
At this point, I assumed all the meat and potatoes were hidden in the programming library
itself.
Of the three supported programming languages, I was most comfortable in C, so I went to
install Lattice C, and oh boy, I didn’t expect the world of pain I was able to launch into.
Lattice C is rather notable because it was the origin for one of the most influential
products of this era: Microsoft’s own C compiler.
Infact, early Microsoft C compilers were just Lattice C with the serial numbers filed off.
That being said, I quickly realized that actually using Lattice C though was infact an experience,
and not what I call a good one.
To start off with, the archived documentation seems to be incomplete.
There’s absolutely no word on how to install Lattice C.
After considerable trial and error, I found that installation is in fact handled by a
batch file that has absolutely no error checking.
If that makes you think I might have blown up my file system, not once, but multiple
times, you’d be *absolutely* right.
The trick, for reference, is to run “A:MAKELC” while in the root directory of the C drive.
If done correctly, this creates the directory structure properly, and then installs the
files without doing something idiotic.
It’s at this point that I ran into even more problems, primary because it seems DOS
3.3 is too new for Lattice C.
The first problem I ran into is that Lattice C doesn’t ship with a linker.
It instead expects the system to have one.
Early versions of DOS up until 3.2 actually shipped with LINK.EXE as part of DOS which
is at least understandable.
Rather conveniently, the Graphical File System also contains an updated LINK executable on
the driver disks.
The fun doesn’t end here.
Lattice C gives very terse and confusing error messages, and I went around in circles trying
to figure out why I couldn’t get Hello World to compile.
Eventually, I did realize that there are special batch files that have the correct options
and switches to get things working.
After that, I did manage to compile Hello World, but that wasn’t the end to my suffering.
It all kinda goes downhill from here.
The next step would be building the sample code that shipped with the Graphical File
System.
Helpfully, the GFS manual does list the commands necessary to do this.
The only problem though is the commands in the manual didn’t work.
It's at this point that I realized that the Graphical File System was written with Lattice
C 2.0, and I was using 2.1.
Still, I would think that this should be close enough, right?
Well, the answer is yes, but it took a LOT of fiddling to derive the correct settings.
Even when I got things to build, I can’t say for sure if it is working properly.
For one, I had to make some changes to the code because the program was running through
a timing loop too fast.
Secondly, the example code doesn’t seem to render properly.
This could be related to the EGA issues we had earlier, but the showmetc example renders
differently than the GRID example.
Looking at the two side by side, the image appears squished, and the font is different.
Things get more confusing if I try a CGA card.
Under CGA, the image is squished to the left side of the screen, and the color palette
has gone completely bonkers.
However, as unlikely as it seems, both of these behaviors may both be expected.
There’s a specific function call in the documentation to set rendering coordinates
which is not used in the example code.
Furthermore, the appendix for the CGA graphics also has a section talking about setting the
palette, although there’s no apparent function to actually do so.
I have to assume the GRID test application does things that the example code does not.
For the sake of comparison, I did actually compile the Fortran version of the example
code, and it shows the same behavior as the C version.
Still, glitches aside, I did get this all working mostly, so maybe now is a good time
to show some awesome demos showing Metafiles?
Well, that was the plan, but it was at this point I began to realize that something was
missing.
If I turn to the index of functions provided by the Graphical File System, there’s a
total of 15 functions which all relate to displaying metafiles.
There’s nothing here relating to creating or manipulating graphics.
Heck, aside from a special VDI driver that can print to a file, there isn’t even a
way to create a metafile.
In fact, the vast majority of the manual beyond this point is just a technical reference for
the binary metafile format!
For example, there’s no way that I could create something like the Interactive Interpreter.
I’ll remind everyone that the box itself said that the Graphical File System “provides
highly portable graphics information, and easy-to-use icon interface to enhance programming
productivity"
While I can technically display graphics from a “highly portable” format, there is no
way I could make an icon interface with this since I couldn’t implement something like
a mouse cursor.
I spent a lot of time researching this in an attempt to understand what I was missing.
Eventually, I did manage to put all the pieces of this puzzle in context, but to do so, I
need to go back to the “Professional Graphics Series” the manual menthoned.
IBM had fairly large plans for making the PC a low cost system for doing computer-aided-design
or CAD work.
The pinnacle of this was the “Professional Graphics Controller”, a monster of an ISA
card with an integrated 8088 processor designed to provide accelerated graphics rendering.
Released in 1984, the PGC provided a 640x480 display with 256 colors in an era where 4-color
CGA graphics were still common.
From what I can tell from the surviving PGC documentation, it essentially operated directly
on VDI drawing commands on a 1:1 basis.
It seems IBM’s Professional Graphics Series was entirely intended to support the Professional
Graphics Controller, and it may put things in context if I read off the list of known
software that was under this label.
In short, there was IBM PC Graphical Kernel System, the Plotting System Library, Graphics
Terminal Emulator, and finally, the Graphical File System.
If you’re confused, well, that’s really understandable since as it turns out, IBM
had made their own implementation of the Graphics Kernel System standard, and then sold it under
the same name.
As you might imagine, this made searching for information a real joy.
On top of that, it's the Kernel System that has nearly all the drawing and interface functionality,
what I have is actually an add-on library for the IBM GKS.
While the Graphical File System is technically usable in and of itself, it’s obvious that
it's one bit of a larger whole.
More simply put, I have an programming library add-on for another programming library ultimately
intended for use with an obscure piece of IBM hardware.
I’m legitimately surprised that this ever got sold in a box.
The Professional Graphics Controller was not what I’d call a mass market item, and I
only knew of its existence due to a fluke.
If you watch vintage tech videos, there’s a good chance you’ve seen LGR’s video
on unboxing and setting up his IBM PC AT.
At one point, he flips through the manual, and this, right here folks, is how I learned
that the Professional Graphics Controller exists!
You really can’t make this up!
With that little story aside, I will say that it's not very surprising that the Professional
Graphics Controller is so obscure even in vintage tech circles.
From what I can find, there was very little software that supported it and I got
the feeling that neither the Controller nor the Professional Graphic Series as a whole
were not what we could call successes for IBM.
Still, success or not, both the Controller and the Professional Graphics Series are neat
pieces of IBM history to say for sure.
Maybe someday I’ll be able to demo the controller, but for now, we’ll have to settle with EGA
graphics.
It’s at this point I’m pretty sure you’re all expecting me to go install the Graphics
Kernel System so I could use my obscure add-on to do something fancy, and normally, you’d
be completely right.
The one problem is that the Graphics Kernel System hadn’t been dumped by the time I
started work on this video.
I am going to draw emphasis to the word hadn’t here.
Originally, the script for this video contained an entire section talking about how things
like this never get preserved, but it appears that fate intervened!
In late November, a copy of all three volumes of the Graphical Kernel System surfaced at
the Computer Reset Warehouse.
When I saw this, I was able to get in contact with the finder, and make sure it got preserved!
This alone is a major win in regards to software preservation, and I’m grateful to those
who made that possible.
Anyway, with that, it’s time to close, but before I do so, I need to ask for a bit of
help from you all.
While I currently have all the equipment to save and preserve disk images, I’m somewhat
less well equipped to deal with manuals.
In the case of the Graphical File System, and other similar products, the manuals are
just as important as the disk dumps, and they’re good to have regardless . I don’t have a
flatbed scanner, and even if I did the GKS manual was over 400 pages long.
In the end, I ended up using this Neat Receipts portable scanner to scan each page one by
one but it was very slow and tedious.
It did work, but wasn’t what I could call ideal, and the colors ended a little washed
out.
I have quite a few manuals that need to be scanned, so if you can help, please get in
touch.
I’m especially interested in hearing from people who may be in the New York City/Northern
New Jersey area.
With that being said, I do hope you enjoyed this video, and as usual, you can follow my
adventures in real time on social media.
As always, this is your host NCommander, signing out, and hoping you all have a wonderful day.