Sorry it’s taken me so long to come back to this subject.  I had a lot of good feedback from part 1 and I’d originally mentioned talking more about true color video modes and outline fonts, but since then I’ve had a lot more ideas popup and I wasn’t sure which way to go until now.

In early 1987, I became the “Chief Software Engineer” for a small company named Neotron Engineering.  Small in this case meaning that I was the third employee.  I was in the final stages of completing my GEM font editor program (Fontz!) and had seen an ad in one of the Atari-related magazines for a new word processor called WordUp that Neotron was releasing soon.

WordUp looked like it might be the first product to fulfill the promise of GEM’s ability to create multi-page documents that mixed graphics and text with different typefaces and styles.  At that point, it was a year and a half since the Atari ST series had come out and only a handful of programs had touched on those promised capabilities.  In retrospect, one can see that the reasons for that promise not being fulfilled weren’t completely as they seemed at the time, but back then the main thing everybody pointed their finger at was GDOS.


When Atari first announced the Atari ST, the promise of GEM included the idea that you could use a GUI-based word processor that would allow you to format your document with a variety of different typefaces and styles, include graphics together with text, etc.  In fact, the main hype about the machine in those early days was that it promised the power of the just-released Apple Macintosh at a lower price.  However, when the machine shipped in July 1985, the GEM VDI graphics engine was missing a key component necessary to make that possible: GDOS.

GDOS stands for Graphics Device Operating System but to be honest it’s really a lot less complicated than it sounds.  GDOS did basically three things.

  • Read a configuration file (ASSIGN.SYS) at system boot time which specified the names of loadable device drivers and the names of the font files that went along with them.
  • Upon demand, install a loadable device driver into memory and patch it into the GEM VDI dispatcher.
  • Upon demand, load the bitmapped fonts that were specified for a given driver into memory.

That’s all it did.  It really should have been part of the regular GEM VDI that was (eventually) put into ROM, but it didn’t make it into the original release.  Even when I worked at Atari I’d get different answers depending on who and when I asked… was it bugs (early versions had a lot of memory leaks), or was it a lack of licensed bitmapped fonts, or what?

I’m sure part of the problem was the logistics of fitting everything into the system.  The early Atari ST models shipped without a hard drive of any sort, and had the operating system loaded from disk instead of in ROM.  That meant a standard 520ST had somewhat less than 300kb of RAM available after booting, before any application was loaded.

That still seemed like a lot of memory to those of us freshly upgraded from 8-bit computers where 64kb was the typical maximum.  But a printer driver would take up a minimum of about 70kb before loading any fonts.  Even a minimal set of bitmapped fonts for a printer device could run another 100kb or more, leaving minimal room for the application itself.

Keep in mind that this was in the old days before virtual memory was a standard feature on computers.  The Atari development system did include a linker that theoretically allowed for overlays – program segments which shared the same memory blocks and which were loaded upon demand as needed, but the feature was never really more than briefly alluded to in the documention.  I remember thinking it seemed like the required runtime support was missing.

At some point the decision was made that GDOS would be provided as a separately loaded program that you would place in your boot disk’s AUTO folder (containing programs to be run at boot time).  This would allow it to be included with programs that needed the features it provided, while not consuming memory or other system resources otherwise.

The first program that shipped with GDOS was Easy-Draw, from Migraph Software.  At least I think it was the first one.  It was a vector graphics drawing program which allowed the user to create drawings from combinations of the various graphics primitives supported by GEM VDI.  (This did NOT include bezier-curves or splines until many years later.)

The way Easy-Draw got around the memory issue was to use one program for creating the drawings and another for printing them.  When you wanted to print something, it would save your drawing as a GEM Metafile.  This was basically a file consisting of a list of GEM VDI commands that, when executed in sequence, would reproduce the drawing.  The only thing the program needed to do was scale the coordinates in the metafile to the resolution of the output device.  Once the metafile was created, then the Easy-Draw program would unload the screen fonts, freeing memory, and then terminate.  As the final step of the process, it would ask GEM to run the OUTPUT program.

OUTPUT was actually a part of the original GEM setup from Digital Research, where the memory situation on 640K-limited PCs wasn’t much different than that on the Atari.  As such, it was included in the GDOS distribution from Atari.  GEM even had specific API calls for launching the OUTPUT program.

When you exited from OUTPUT, it would ask GEM to run the program that had started it, in this case Easy-Draw, so that it looked like you were more or less going from the “design” module to the “output” module as seamlessly as might be possible under the circumstances.  In those early days it meant a fair amount of swapping floppy disks around, but ultimately it worked.

Easy-Draw shipped with GDOS disks containing the printer drivers and bitmapped fonts that Atari provided.  There was a printer driver for the Epson FX series dot-matrix impact printer, another for the Star Micronics printers, and three sets of bitmapped fonts, two for different screen modes, and one more shared by both printer drivers.

The three typefaces included were Typewriter – basically a Courier fixed-character-width font, Swiss– a sans-serif font similar to Helvetica or Arial, and Dutch – a serif font like Times Roman.  Typewriter was included in 1 size (per device) and the others in 5 or 6 sizes ranging from 9 point to 36 point.  Those fonts were high-quality as long as they were output at the right size, but didn’t provide much variety.

Enter Fontz!

In mid 1987 I purchased an Apple Macintosh II computer.  This was the first model with expansion slots and no built-in monitor.  I had been using the Magic Sac emulator on the Atari ST since the previous summer, but I found that when I started programming with the Lightspeed C (later Think C) package, the debugger didn’t work so well under emulation.  Not really surprising since the emulator had to hook into low-level stuff to make things work on the Atari, and the debugger had to hook into much of the same stuff to do its thing.  Anyway, I really wanted to learn how to program for the Mac platform, and I also wanted to experiment with high-res color graphics.

To be honest, in large part another reason I got the Mac was because of the unfulfilled promise of the Atari ST.  However, the Mac didn’t quite take over as my main machine and I continued to work regularily with the Atari.  The Mac was heavily supported by many large software publishers, so I saw the Atari platform as a better place for a single developer just starting out to make his mark.

At some point, I wrote a little utility program that would read bitmapped fonts from the Atari 8-bit computer and create a GEM-format bitmapped font from it.  Then I started playing around with converting other bitmapped font formats.  I had font collections on the Mac with dozens of bitmapped fonts in a variety of sizes, so I dug down into the Inside Macintosh book (the programmer’s bible for the Mac in those days) and before long I had figured out how to extract the data and create a GEM font.

Eventually I pulled these various individual conversion utilities together and a friend suggested it would be nice to be able to edit the actual bitmaps.  Before too long, I’d created the Fontz! bitmap font editor, which could import a variety of different bitmap formats, scale fonts to different sizes for different devices, and more.  It had what amounted to a paint program built-in for manipulating the character bitmaps.

This brings us back to the beginning of the story… I was getting a lot of interest from various publishers about Fontz! when I saw the advertisement for Wordup.  After meeting with Neotron, they offered to buy the rights to publish the program and a position as a software engineer.

GDOS Printer Drivers

After I started at Neotron Engineering (later renamed to Neocept), my first task was to finish off Fontz! so we could ship it, and then I started working on various features for WordUp. Once we finally shipped, we included the same basic GDOS package as anybody else.  The main difference was that we didn’t use the OUTPUT program for printing, but rather printed directly from the main program.  This used more memory, so we specifed that the minimum memory requirement for WordUp was 1mb instead of the usual 512kb.  This was early 1988, and at that point there were all sorts of memory upgrades available for 512k machines, and newer machines like the 1040ST and Mega ST had more memory in the first place. The program actually worked on a 512kb machine, but you often needed to use a limited number of fonts to make everything fit, so we decided just to say that 1mb was required.

One of the biggest problems we had in with the initial release was that there were a lot of new printers coming on the market every time you turned around, and many of them required a different printer driver than either of the ones Atari provided.  So we were constantly getting requests from users for drivers.

For whatever reason, Atari was really slow to come out with new drivers, so initially we had no way to respond to those requests, but eventually we were able to convince Leonard Tramiel, VP of SW Development at Atari, to release the GDOS Driver Kit to us.  I’m not sure if we were the first developer to get this from Atari, but I don’t think there was ever more than 1 or 2 other developers who ever released a driver.  I think part of the reason was that some of what we ultimately did with it went way beyond what Leonard was expecting us to do.

The GDOS Driver Kit was basically the source code and linkable library for the existing printer drivers.  The linkable library was, for all intents and purposes, a version of GEM VDI which rendered into a bitmap buffer.  This would be combined with a chunk of code that you customized for each printer that did nothing more than output a buffer using whatever custom codes that the printer required.   There was printer-specific code provided for the Epson-FX series 9-pin dot matrix impact printers, and for the Epson LQ series 24-pin dot matrix impact printers.  I’m thinking there may have also been a third example for Atari’s own SMM804 9-pin dot matrix printer, but without digging up those old floppies I’m just not sure if that was there originally, or if it came later.

In order to minimize memory usage, the driver would allocate a buffer that was only a fraction of the size needed for the overall page, represented as a horizontal strip across the overall raster area.  This strip would extend across the entire width of the raster, but might only be 8 lines tall even if the overall printer raster was 3000 lines.  The driver would rasterize all of the GEM VDI primitives making up the page and clip the output to the current strip.  Then the printer-specific code you created would output to the printer using whatever custom codes were needed.  Then it would move down to the next strip and repeat the process.  This would happen over and over until it reached the bottom of the page.

This may sound inefficient in some respects, since the primitives might be rendered dozens or even hundreds of times in the process.  However, keep in mind that sending data to a printer over a standard parallel port was not a very speedy process back then.  Compared to the amount of time required to actually send the data to the printer, not to mention the time it took most impact dot matrix printers to actually print that data, the rendering time was usually not a major factor.

Breaking the raster down into strips allowed the printer driver to use much less memory than would otherwise be required if it rendered the entire page at once.   The minimum resolution of the printer drivers we were using was 120 x 144 dpi, or 960 x 1260 dots for a letter-sized page.  For regular monochrome output that would have required about 180kb of RAM to create the entire raster at once.  Remember what I said earlier about how much RAM was available and you see why minimizing RAM usage was important.

Back in those days, you might have 5 different manufacturers creating printers that had basically the same exact capabilities, but for whatever reason, used different escape codes for the same function.  More likely, you had 80% compatibility from one device to the next, but one or two codes here and there would be different.  The first few printer drivers I created were fairly easy to do, as they involving nothing more than changing the printer escape codes that were used.  This was, I think, all that Leonard Tramiel at Atari really expected we were going to do, even though no restrictions were ever placed upon us.

However, before long we started looking at printers that required more work.  The Epson JX-80 was a color version of their popular FX-80 printer.  Another popular inexpensive color printer was the thermal wax transfer Okimate from Okidata.  The first inkjet printer the HP Deskjet, had just hit the market.  The original HP LaserJet was quite popular among the higher-end users.

When I first started working on the drivers that were more complex, or which at least needed changes beyond what escape codes were output, I needed to figure out a way to debug them when things didn’t work right.  This was not straightforward, because of the way printer drivers were loaded into the system and executed.  Eventually I added code to the printer driver that did the equivalent of standing up and shouting “here I am!” when the system loaded it into memory.  This allowed me to tell the debugger where it was in memory, load debugging symbols, etc.  Along the way, I learned a ton of important facts and trivia about GEM VDI and the way it worked internally.

Optimizing The Output

Remember a moment ago when I said that sending the data to the printer was a significant bottleneck?  Well, the basic printer driver code supplied by Atari was set up to output complete strips of data to the printer no matter what the strip actually contained.  That meant we output the same amount of data if the strip had lots of information or if it was empty.  That’s not very efficient.  We noticed that some printers had the ability to skip over empty space and start printing graphics data in the middle of the line instead of just starting at the beginning, so we started working on optimized drivers that would take advantage of that.  This could speed up the time it took to print a page tremendously.  I think we did one test where the unoptimized driver would take about 6 minutes to output a page, but the optimized version took like 30 seconds.  That’s a 1200% improvement, and it was not even the theoretical maximum improvement.  Of course, most pages people printed fell somewhere in the middle.

Somewhere along the line, Migraph software had come out with a GDOS driver for the HP LaserJet laser printer.  This also worked with the HP DeskJet printer, which was a very popular printer with Atari users as it produced near-laser quality at a much lower price.  However, it was slow, mostly because of the amount of time it took to send over the 1mb+ of data that it took for each page, so Migraph supplied two versions, one for fast output at 150 dpi and another for high-quality 300 dpi.

Our WordUp word processor worked with the Migraph driver,  but we weren’t happy with the speed so we decided to do our own driver.  Our original optimization technique that I described earlier did not apply to the DeskJet, but we discovered that it supported the concept of sending Run-Length Encoded (RLE) graphics data. This would allow you to send just a few bytes of data whenever there was a long string of repeating values, as would be the case whenever there was an area that was all black, or all white, or which repeated some pattern over and over.

My boss hadn’t really gotten involved in the printer drivers too much up to that point, but he got interested in this and worked on the encoding algorithm for the data while I did the rest of it, and ultimately we created a driver that was 200-300% faster on average than the Migraph DeskJet driver out there.  This was released along with a full set of fonts as the TurboJet printer driver package.

G+Plus From Codehead Software

As I said earlier, in the early days, GDOS had a reputation for being buggy and slowing down your system.  As far as I could tell, the “buggy” part was mainly a reference to memory leaks that could occur as drivers and fonts were loaded and unloaded.   It was something where you might easily never see any problem.  But as far as slowing your system down goes, this was a bit more commonplace and easy to measure.  It wasn’t a huge difference, but it was there.  The cause was simply that there was extra code being executed each time a GEM VDI call was made, and that code wasn’t really especially optimized.

Codehead Software was a company that specialized in publishing utility software for the Atari ST.  One of their early products was G+Plus which was advertised as a GDOS replacement.  They claimed to have used optimized assembly language to eliminate most of the system slowdown. They also had other improvements to the way regular GDOS worked, like the ability to change the list of installed fonts for a device without rebooting your system.

I first got involved with G+Plus because the very early version had some compatibility issues with our WordUp program.  It initially wasn’t clear if it was a bug with G+Plus, or something WordUp was doing, and so I ended up working with Codehead’s Charles Johnson to figure out what was going on and fix it.  I don’t remember exactly what the problem was now, but it didn’t take us long to figure out.

That all happened before we had gotten the GDOS Driver kit and I had acquired the knowledge about the internal workings of GEM VDI that came from working with it.  Later, as I learned more about how GDOS and GEM VDI worked internally from the printer driver stuff, a variety of questions occurred to me regarding how G+Plus did certain things.  Eventually, I ran into Charles again at a regional Atari User Group show and asked him those questions.  To my surprise, he was largely unable to answer them.  In fact, he didn’t seem to know some of the very basic low-level details about how GEM VDI worked internally.

I couldn’t understand how someone could write a new version of GDOS without such knowledge.  I came to the conclusion that Codehead hadn’t actually written their own version of GDOS from scratch, but rather that they had taken the original version from Atari and disassembled it.  That was easily done, and the program file was only about 8-9 kb.  Once they had a disassembled version, it would be possible to hand-tune the original code generated by Atari’s C compiler to eliminate the various inefficiencies that contributed to the system slowdown. Along the way, they also figured out how to do a couple of things like alter the bitmapped fonts configuration on the fly.

While I was initially disappointed to concluded they hadn’t written their own version from scratch, I later came to appreciate the fact that they managed to introduce as many new features as they did, while maintaining compatibility.  It was quite impressive.

The Atari Gets Vector Fonts

As 1990 drew to a close, the big news was the impending arrival of FSMGDOS.  “FSM” stood for “Font Scaling Module” and basically that meant outline fonts. Outline, or vector-based, fonts were nothing new.  Several desktop publishing applications for the Atari computers used their own proprietary flavor of outline fonts, including Calamus and Pagestream.  However, there was as yet no system-wide solution.

FSMGDOS was a new version of GDOS that took the regular features of GDOS and added in the ability to generate character bitmaps as-needed from scaleable outline fonts.   It also added some new GEM VDI drawing primitives for bezier curve and splines.  All while maintaining backwards compatibility (mostly) with the original GDOS and programs that used it.

The biggest compatibility problem with FSMGDOS was the fact that existing applications using GDOS with bitmapped fonts would typically determine which specific sizes were available and limit the user options accordingly.  But with FSMGDOS, this didn’t work quite right, since any size requested would resolve back to “available”.  However, this was a relatively minor problem overall.

At Neocept we got an early version of FSMGDOS and started making changes to accomodate it, but Neocept was not doing well and essentially dissolved before that job was really finished.

A couple of months later, I moved to the SF Bay Area to take a position at Atari as the developer support engineer for the ST platform.  When I arrived at Atari, FSMGDOS was just about ready to go in many ways, but one of the big problems was the fact that it used a proprietary type of outline font that was not in common usage.  The availability of a variety of typefaces was a big question mark.  The big player with outline fonts was Adobe’s Postscript Type 1, which had been around for several years and which was supported on Windows and Mac via their ubiquitous Adobe Type Manager software. True Type was just making its debut but had backing from both Apple and Microsoft.

We tested the waters briefly by allowing the original version of FSMGDOS to ship with a new version of WordFlair from Goldleaf Publishing, but at the same time, we started looking into an alternate font scaling library from Bitstream.  Since Bitstream was (and continues to be) one of the world’s foremost type foundries, all the lingering questions about font availability faded away.  The big question came down to performance, as the Speedo format required a bit more math processing to render, and floating-point support was software-based on all Atari machines except for the new TT030, which could take an optional floating point chip.

If I remember correctly, the rendering speed differences turned out to be less of an issue than originally anticipated, and combined with improved bitmap caching routines, the Bitstream Speedo scaler and fonts ultimately won out.  Thus was born “SpeedoGDOS”, the “Speedo” version of “GDOS”.

In Conclusion

Part 3 of this series is forming in the back of my brain even now… stay tuned!