PrintStar's Blog
Ramblings of a Fortran Nut
July 1, 2009 by Jeff

RetroChallenge Begins!

RetroChallenge quietly began today, and my challenge got off to slow but productive start. As my RetroChallenge entry says, I’ll be tackling some programming using GEM, an alternative windowing system originally developed by Digital Research. GEM enjoyed moderate success in the PC world in various incarnations, but is probably most famous for being the operating system (along with GEMDOS) on the Atari ST line of computers. A great rundown on how Atari came to choose and port GEM to their rapidly developed hardware is available from DadHacker, an Atari developer at the time. While PC and Atari GEM are theoretically compatible, there are a few show-stopping differences in porting software to each.

The most obvious issue is the CPU differences. The Motorola 68k series found in Atari machines is big endian, while Intel and compatible chips in PCs are little endian. While not an obviously large difference, it does make the use of macros in C a necessity for porting software. However, the macros themselves are problematic as compilers diverged from each other on the two systems. Little, tiny differences, which I’ll outline in later posts, appear in different compiler suites. Furthermore, header files are not named similarly or present at all on one or the other. The other nastiness related to system architecture is the inherent ugliness of far pointers and the like on Intel systems. The Atari does suffer somewhat from a two-stage memory system (ST and TT RAM addressed using 16 and 32 bits respectively), but the Atari’s 14MB of addressable ST RAM is accessible without any trickery, unlike Intel architectures, which require EMS/XMS/whatever else you can imagine. Yuck.

The other major difference is the differences in GEM itself. It appears that Atari licensed the GEM source code and then never spoke to DRI again. PC GEM was basically dead by 1990 as Microsoft Windows was clearly becoming the winner of the GUI wars on the PC. DRI more-or-less abandoned GEM as a standalone environment, relegating it to a shell in DR-DOS called ViewMAX. Furthermore, Apple sued the pants off DRI for GEM and its functionality, severely crippling its usefulness on the PC.

Atari GEM, on the other hand, continues to be developed (although the pace has slowed considerably). GEM is partially derived from GSX, the Graphical System Extension, and retains the modularity of the older system. In fact components of GEM can be swapped out with ease, replaced with significantly better software. Atari itself released its last version of TOS, which is stands for “The Operating System” and is comprised of GEM, GEMDOS, the BIOS, and the XBIOS, in 1993 with the release of the Falcon030. However, TOS itself continued to be developed, released again in the late 1990s with the Milan computer, a 68040 or 68060 Atari clone.

Various additions and alternative components have been released both commercially and as open-source software. For example, my Atari runs FreeMiNT, which replaces much of the GEMDOS and provides the ability to use preemptive multitasking and modern file systems. On top of FreeMiNT I run a replacement open-source Video Device Interface (VDI), commercial Graphic Device Operating System (GDOS), a commercial Application Environment Services (AES), and a commercial desktop. The gist of this description is that Atari GEM is considerably more advanced than PC GEM.

As an example, lets take a look at two screenshots. This first image is a capture from ShaneLand OpenGEM, the current state-of-the-art PC-GEM implementation:

Note that the screenshot shows monochrome icons and a relatively Win 3.1-like feel. The system pallete is 16 colors at 640×480. Contrasting OpenGEM is a screenshot from my current Atari TT030:

The screenshot above was taken at a resolution of 1024×768 in 16-bit color. The icons are all 256 colors, and the window decorations are decidedly mroe attractive.

Tomorrow I’ll try to start postin about the wonders of GEM programming once I understand a little bit more about it. From my initial glances, GEM seems a lot like Win32 C programming, relying on messages processed in event loops. I plan to attempt my first “application” tomorrow.

  •   •   •   •   •

Leave a Reply