Recent Posts

  • Secrets of NeoDesk 4 - by Al Fasoldt What Gribnif's NeoDesk 4 desktop can do for youPublished in two sections:A Guide to NeoDesk 4Tips and Tricks of NeoDesk 4 Section One:A Guide to NeoDesk 4Covering NeoDesk 4 up to release 002 by Al FasoldtTechnology Writer, Syracuse Newspapers and Newhouse News ServiceSystems Editor,Herald-Journal, the Herald American and the Post-StandardProgrammer, Syracuse Newspapers Telesystem online serviceSyracuse, New York Copyright (C) 1995 by Al Fasoldt. All rights reserved. INTRODUCTIONPower, grace and style on an AtariUntil the introduction of Gribnif Software's NeoDesk 4, users of the Atari ST, TT and Falcon were left on the sidelines of the revolution in multitasking desktops for personal computers. NeoDesk 3 ...
    Posted Jul 16, 2019, 4:29 AM by Joshua Kaijankoski
  • Secrets of Geneva - by Al Fasoldt PART 1 Tips, tricks and things that should be obvious but may not be in getting the most of of Gribnif's amazing Geneva, the multitasking environment for Atari ST, TT and Falcon computers. by Al Fasoldt Technology Writer, Syracuse Newspapers and Newhouse News Service Systems Editor, the Herald-Journal, the Herald American and the Post-Standard Syracuse, New York  Copyright (C) 1994 by Al Fasoldt. All rights reserved. Version date: January 24, 1994.  NOTE: This can be reproduced in electronic form without permission of the author only if the entire document remains intact. Printed reproduction requires a prior arrangement. No commercial use of this document, for any purpose, is allowed.  Geneva, the multitasking operating environment from Gribnif Software, is ...
    Posted Jul 16, 2019, 2:29 AM by Joshua Kaijankoski
  • Atari TT030 Revision Guide What follows is a guide based on educated assumptions, logical conclusions, and some hard evidence. As such, the information provided may not be, or may never be entirely accurate due to lack of evidence. All information has been acquired from the internet, mostly from public forums, without explicit permission. Therefore, you might recognize a source as belonging to you and you may then request its removal. At the same time, the results of my public request for users to submit pictures of their motherboards has been disappointing and I hope this article will encourage TT owners to submit pictures as I'm willing to update this guide if new or contradicting evidence comes to light.The Need for a Clear ...
    Posted Dec 6, 2019, 8:52 AM by Joshua Kaijankoski
  • TT VME Graphics - Revisited Just recently I posted the article TT VME Bus Fix - Does it really make it faster? where I compared performance before and after Atari's VME Bus Fix which all REV.H motherboards and up seem to have. As kind of expected, the gains were not significant. I mean we would have noticed this years ago. What is unexpected, however, is the sudden performance boost (on average) than just a few days ago. So what has changed? Am I missing something? If so, let me know.Before I show the results, here's what has changed (I'll list everything even if it is seemingly unrelated):Motherboard recappedRest of the rework done (My TT Gets Some Love)New storage ...
    Posted Jul 27, 2018, 2:51 AM by Joshua Kaijankoski
  • TT Cable Management and Cooling - Extreme Edition I hate cables, especially ribbon cables like SCSI and IDE. Ever since I got Thunder (and Storm) I've been looking for a solution that plugs straight into Thunder. Challenge has been to a) find something small enough b) connector in right orientation c) high enough capacity. Never found anything close enough. Ideally I wanted a Compact Flash solution. Then I ran into TrueIDE that I bought from the lovely folks at Shipment was super fast and they included a nice Amiga postcard with a personal message. Thank you very much if you are reading.TrueIDE checks all criteria apart from size. I wanted this to work. After I tested it with conventional methods with a brand new ...
    Posted Jul 26, 2018, 9:51 AM by Joshua Kaijankoski
  • My TT Gets Some Love I reckoned it would only be fitting that my TT030 receives all the rework procedures I had recently created visual guides for. I'm very happy and relieved to have done it all successfully. I also did a highly experimental "Poly-Mod" that I will outline at the end.Essentially, with these fixes, my early REV.C (C301763-001 REV A) is now a REV.K.I am not responsible for any problems or damage caused by these procedures. Attempt them at your own risk.Rework DoneREV.C Rework OverviewRTC FixVery straightforward. Nothing much to comment here. I haven't received my frequency counter yet so once I do I will adjust it. Frequency counters are very ...
    Posted Jul 23, 2018, 10:14 AM by Joshua Kaijankoski
  • TT VME Bus Fix - Does it really make it faster? So I decided to attempt the VME Bus Fix as per Atari's rework procedure. The fix saves 1 clock cycle per transfer so it just might be faster. Before I did that, I took screenshots of two benchmarks:I have a 2MB Mach 64. Only NVDI 5.03 and Idek's Nova drivers are loaded. Reference is the exact same setup and system sans Mach64. The Mach64 @ 1280x1024x256 colors is pretty much as fast as TT High. That says a lot. The ET4000 is faaar behind. Here is the same setup after the VME Bus Fix. First result is vs the first screenshot above. The rest are with the same TT High reference.So the results are pretty conclusive ...
    Posted Jul 21, 2018, 7:24 AM by Joshua Kaijankoski
  • Atari 520STM Restoration Pictures I thought I'd post pictures of my latest restoration project as I realized I had never done that . Unlike my previous projects, this was a "restored to order" job with some specific requests.This was the starting point. A little dirty but not bad at all.Here is the motherboard before any work has been done. Very clean. It's the last revision of the small STs and only one that supports 2-chip TOS.Right off the bat I noticed that there has been minor rework on the board. It's clear that a bunch of resistors have been changed. They are connected to the RAM chips and the MMU (memory management unit). It seems that someone wanted ...
    Posted Jul 4, 2018, 2:57 AM by Joshua Kaijankoski
  • Mega ST Keyboard Switches They are mechanical and they are Cherry MX Blacks. I know because I finally took one out. No membranes anywhere. This is not a new discovery but something I had to verify myself because of lack of evidence.Some people complain that Mega ST keyboards aren't as good as TT/MSTE membrane keyboards that have tactile feedback. And they would not be wrong if that's what they are after.Mega ST's Cherry MX blacks are linear switches, meaning they have no click or tactile feedback by design. They are also one of the earliest Cherry switches from 1984.The beauty of the Cherry MX switches, and therefore the Mega ST keyboards, is that they are replaceable. If ...
    Posted Jul 3, 2018, 1:31 AM by Joshua Kaijankoski
  • Atari TT030 REV.C Rework Guide This started out as a guide for myself to do the rework down the road. This is for REV.C (PGA CPU) which is the model after the daughterboard REV.A and one before the REV.D-K ("SMT Models"). Took a long time to do. I hope someone finds it useful. Filesize is big, but for a reason.
    Posted Jun 10, 2018, 1:43 PM by Joshua Kaijankoski
Showing posts 1 - 10 of 62. View more »

Secrets of NeoDesk 4 - by Al Fasoldt

posted Jul 16, 2019, 3:53 AM by Joshua Kaijankoski   [ updated Jul 16, 2019, 4:29 AM ]

What Gribnif's NeoDesk 4 desktop can do for you

Published in two sections:

A Guide to NeoDesk 4
Tips and Tricks of NeoDesk 4 

Section One:
A Guide to NeoDesk 4

Covering NeoDesk 4 up to release 002 
by Al Fasoldt

Technology Writer, 
Syracuse Newspapers and Newhouse News Service

Systems Editor,
Herald-Journal, the Herald American and the Post-Standard

Syracuse Newspapers Telesystem online service

Syracuse, New York 

Copyright (C) 1995 by Al Fasoldt. All rights reserved. 


    1. 1.1 Power, grace and style on an Atari
    2. 1.2 GUI things and why they are important
    3. 1.3 What NeoDesk 4 offers that the standard desktop doesn't
    4. 1.4 Up with upgrades
    5. 1.5 So why not just read the NeoDesk user manual, pal? 
    6. 1.6 Um, what user manual? I think the dog ate mine.
    1. 2.1 Memory is made of this
    1. 3.1 INFinite wisdom 
    1. 5.1 Getting rid of FOOBAR3.PRG and THSBGFIL.DOC 
    2. 5.2 Try it - you'll like it
    3. 5.3 Groups that care for MIAs
    1. 6.1 You use parameters every day
    2. 6.2 Give me an N! Give me a P! 
    1. 8.1 Geneva adds the muscle
  10. 10 PART 10: FONT OF PLENTY 
    1. 10.1 What GDOS is and why it's not built into the computer 
    2. 10.2 It's all a matter of proportions 
    3. 10.3 GUI or not, sometimes text is a better choice after all
    4. 10.4 Note this, please
  11. 11 PART 11: SCREEN GEMS 
    1. 11.1 If icon, you can, too
    2. 11.2 We do Windows
  13. 13 PART 13: PICTURE THIS 
    1. 13.1 Placing a picture of the desktop on the desktop 
  14. 14 PART 14: ICON DO IT 
    1. 14.1 Why not just hide those icons away where they belong? 
    2. 14.2 You can't really click on a DA and get it to run, can you?
    3. 14.3 Pick a name 
    1. 15.1 How NeoDesk does it
    2. 15.2 Make me a macro. (ZAP! You're a macro.)
    3. 15.3 Macros that do more than run programs 
    4. 15.4 Special macros, or how to make them call themselves 
  17. 17 PART 17: TRASHY STUFF 
    1. 19.1 Where's my trash can?
    2. 19.2 Just a couple of choices
    3. 19.3 It's up to you


Power, grace and style on an Atari

Until the introduction of Gribnif Software's NeoDesk 4, users of the Atari ST, TT and Falcon were left on the sidelines of the revolution in multitasking desktops for personal computers. NeoDesk 3, the previous version of Gribnif's alternative desktop, already supported multitasking, but only in the most basic way; as long as the computer was running Geneva, Gribnif's multitasking replacement for part of the Atari operating system, NeoDesk 3 was able to launch a new application while a currently running program remained active. But NeoDesk 3's own operations -- copying, deleting and formatting, for example -- did not multitask. And NeoDesk 3 did not have two other features that have made the best desktops on PCs so attractive -- a modern 3D look and feel, and a way of organizing and managing programs by groups.

NeoDesk 4 changes everything, and corrects an imbalance between the premiere desktop environment for the Atari and Microsoft's Windows. But in creating NeoDesk 4, Gribnif did not imitate Windows or fashion an Atari version of the Macintosh interface. NeoDesk 4 is more flexible and more intuitive than either of its popular counterparts. It is even able to perform some functions that Windows 3.1 and the Mac cannot ordinarily do.

And, almost as a tribute to the lean and efficient way Ataris have always operated, NeoDesk 4 occupies only as much memory as you want to yield over to the desktop. You can even run NeoDesk 4 comfortably on a 1-megabyte ST, although it will run more quickly and smoothly on systems with more memory. 

GUI things and why they are important

A graphical user interface is nothing new. We like to point out with considerable pride that the ST arrived on our desks with a built-in graphical user interface long before most users of IBM-compatible personal computers had even heard of icons and windows. But the ST's GUI -- yes, it's pronounced "gooey" and not "Gee You Eye" -- followed the Mac's by a year. The ST's graphical environment was designed by Digital Research as almost a sideline in its efforts to create a GUI for PCs. This PC system, the Graphics Environment Manager, was stripped of much of its power and many of its features before it came to market, after a legal dispute between Digital Research and Microsoft, which was then developing its own graphical system called Windows. Microsoft complained that GEM was too much like Windows, and so Digital Research changed GEM. But the new owners of Atari Computer, casting about for an icon-and-windows interface for the exciting new 520ST, managed to convince Digital Research to leave the Atari version of GEM unsullied, and so the ST came to life with a GUI of its own, vaguely similar to the PC version of GEM. (That version disappeared from the marketplace in an avalanche of Windows.)

A graphical user interface does not have to use icons and windows, but that is how most of them have developed. It is easier to describe such a system as an "object-oriented" interface, because it allows the user to manipulate objects that perform actions -- actions that are, in most cases, analogous to what happens in "real life." Instead of typing commands onto the screen, the user instructs the computer to do any task by selecting an icon and doing something with it -- double-clicking on it or dragging it to another icon, for example. Rather than typing commands such as "XCOPY C:\BIN\FOO *.* /S A:" onto a blank screen, the user of an object-oriented interface merely deals with things -- objects of one kind or another, all represented by icons -- on the computer screen.

The way these icons were placed on the screens of the first experimental object-oriented interfaces in the late 1970s and early 1980s made the screens look a little like the desks in a typical office. They had icons for filing cabinets (disk drives in the computer system), for folders (directories on a disk), for a waste basket (the bit bucket, or the act of erasing a file), for a pile of notes, and for many other things. These early interfaces also had windows that opened up to show more icons or to hold running programs.

The metaphor of the computer-as-desktop is just one way of representing the way we deal with a personal computer. It may not be the best way, but it stuck. With the introduction of the Apple Macintosh in 1984 and the ST and Commodore Amiga a year later, the notion of a desktop on the screen began to gain popularity among users who had always viewed the standard PC command-line interface as crude and inadequate. In the IBM-compatible area, Microsoft's Windows took a halting step in that direction in its first two versions and then went a lot further in Windows 3.1 and in the latest version, Windows 95. IBM, creator of a hybrid interface called OS/2 1.0, also adopted the same sort of desktop in OS/2 2.0, 2.1 and OS/2 Warp and, at the same time, the GeoWorks company invented its own Mac-like interface for PCs -- one that actually surpasses the Macintosh in a dozen ways.

By the mid-1990s, "object-oriented" computer desktop interfaces had become, at last, the standard way of working with a personal computer. 

What NeoDesk 4 offers that the standard desktop doesn't

Until recently, the ST's desktop interface, although easy to use, has been the weakest of all these systems. Although it uses icons and windows, the ST's GEM did not gain many of the full functions expected in an object-oriented interface until the release of version 2.05 of the ST's built-in operating system, known as TOS (for "The Operating System"). This was followed by version 2.06 when Atari added support for 1.44-megabyte floppy drives. A similar TOS-based GEM, which appeared as TOS 3.01 and was incremented to version 3.06, is built into the TT, and a newer TOS, version 4.xx, has been engineered into the latest Atari, the Falcon030.

But the GEM desktop built into the latest versions of TOS, while superior to the original version, lacks all the advanced features of the ranking monarch of alternative desktops, NeoDesk 4. Among the advantages of NeoDesk 4 are these features:
  • Support for the Geneva, the multitasking replacement for the Atari Application Environment Services (AES). NeoDesk 4 was created as the perfect shell (desktop environment) for Geneva.
  • Program and data-file groups. These groups let the user organize aliases (virtual copies that take up little space) of any kind of object, making both program launching and data-file organization exceptionally easy.
  • NeoDesk Program Information files (NPIs). These provide ultimate control over how every program or data file is handled by allowing the user to customize the action of specific programs for particular functions.
  • Background file operations. NeoDesk 4 is able to copy, move and delete files and folders completely in the background, while other desktop tasks are going on. When NeoDesk 4 is run as the desktop under Geneva, it can even perform these operations while any other multitasking applications are running.
  • Background formatting of floppy disks. This does not require Geneva.
  • Desktop windows that contain their own GEM menu bars. This vastly simplifies desktop operations and extends the intuitive nature of GEM is a way that puts Microsoft Windows and the Macintosh desktop to shame.)
  • Display options that include the use of different fonts for separate parts of windows and the ability to employ scalable vector fonts in place of fixed-size bitmapped fonts.
  • Choices of text-only and icon-based display modes for file-and-folder and group windows. Large or small text can be used, in any suitable font, and display modes (text or iconic) can be mixed among different windows.
  • Operation as a desk accessory. NeoDesk 4 can be loaded as a desk accessory instead of a program. It retains all its functions as a DA, and can be closed into the Desk menu just as any other accessory can be.
  • Operation within a fully resizeable GEM window. NeoDesk 4 can be contained within its own window, an especially handy arrangement for systems with large-screen displays.
  • Flexible file-and-folder search operations that can use both simple wildcard specifications and powerful Unix-style Boolean operators.
  • Advanced control over how much memory NeoDesk 4 takes for its own operations. Free memory can be displayed in a windowed dialog box at all times if desired.
  • A choice of desktop background patterns. These can be simple wallpaper (repeating small patterns), tiled images or large black-and-white or color pictures that fill the entire desktop. All major Atari-specific graphics formats are supported, as is the universal format for Microsoft Windows desktop pictures.
  • Full compatibility with all display modes of every Atari made, including ST low resolution, both standard ST resolutions, all four TT resolutions, all resolutions of the Falcon030 and all extended resolutions provided by add-on graphics cards and big-screen devices and software. NeoDesk 4 supports all color-plane settings from monochrome to True Color (16.7 million colors, available on some graphics cards).
  • Animated icons that can be separately tailored to the three primary color modes of Atari computers -- monochrome, 4-color and 16-color screens. There is no limit, apart from available memory, on the number or variety of icons that can be installed in NeoDesk 4, nor is there a limit (apart from desktop real estate) on the number of icons that can be placed on the desktop.
  • A powerful icon editor. It can import icons in many different formats, including the icon formats used by Microsoft Windows.
  • Accessories that act like programs. Desk accessories that are written to communicate with NeoDesk (STeno, STalker, CardFile, EditPlus, MemFile and many others) can be placed on the desktop just as programs can. Dropping a text file to the STeno accessory icon, for example, will open the STeno accessory with the text file ready to read or edit. Dropping another text file onto the same icon while STeno's window is open will update the window with the new file.
  • Built-in keyboard shortcuts for many desktop operations, including hotkeys for launching programs, accessing drives and opening NeoDesk-compatible accessories.
  • A powerful macro facility. Macros can be as simple or as complicated as desired, and can include window resizing and movement.
  • A recoverable trash can.
  • A control panel that provides a screen saver, a corner clock and configurable blitter options, among others.
  • Full control over the GEM environment for all applications running under NeoDesk 4.
  • Limitless installation of "Installed Applications" (programs that automatically run when their data files are opened). Each application can have two different data-file types associated with it by setting up applications from a NeoDesk menu, but any number of others can be added to each application by merely editing NeoDesk's information file. 

Up with upgrades

NeoDesk, developed by Dan Wilga and sold by Gribnif Software, has undergone many revisions. The first modern version was introduced as NeoDesk 3, although the first multitasking version of NeoDesk was released as NeoDesk 3.04. NeoDesk 4 is based on NeoDesk 3, but is a major upgrade in every sense. Gribnif offers users of NeoDesk 3 a special upgrade price when they switch to NeoDesk 4. 

So why not just read the NeoDesk user manual, pal? 

NeoDesk 4 comes with an extensive, well written manual. This is intended only as a supplement to that manual, written from the perspective of an experienced user and NeoDesk beta tester. (A beta tester is someone who tries out software while it is being created). As with all good software, there is no single "correct" way of using NeoDesk 4; instead, each user is likely to find what works best in each unique situation. It is with that understanding that I present this personal perspective. 

Um, what user manual? I think the dog ate mine.

NeoDesk is one of the most prized packages in the world of Atari software. If you are a satisfied user of NeoDesk 4 but have not paid for it, you probably do not have a user manual. Gribnif has a simple solution: If you send the company money, it will send you a manual. Along with the manual will be the legitimate NeoDesk 4 software. What could be more simple and more satisfying in an ethical sense? (If you are an unsatisfied user of NeoDesk 4 but have not paid for the software, you are still morally obligated to purchase it. And you will probably discover that owning any piece of software changes your perspective on how much time you should spend learning how to use it.) 

Author's note:
Because of its length, this document is in two sections. "A Guide to NeoDesk 4," which you are reading now, was published in March of 1995. "Tips and Tricks of NeoDesk 4" will be available in the summer of 1995. For additional background, read "Secrets of Geneva" and "Secrets of NeoDesk 3," available in the ST Roundtable libraries of GEnie and from other services. Some of the material in "Secrets of Neodesk 3" is included in this document, but I have tried to keep "Secrets of NeoDesk 4" as fresh as possible.

This may be freely distributed in any form, but only if it remains intact. You do not have permission to edit this or use it commercially in any way.

If you have comments or questions, and especially if you find errors in this work, you can reach me at these addresses:

Al Fasoldt 
Syracuse Newspapers
Box 4915 Syracuse, NY 13221

GEnie: a.fasoldt 
America Online: AlFasoldt


This is Version 1.0, written in March 1995 at the computer center at Countless Pines, Baldwinsville, New York.


Why half a loaf may not be better than none 
NeoDesk 4 was born to mate with Geneva. Gribnif Software created Geneva, its multitasking environment, when NeoDesk was still at version 3. This version was quickly updated to support Geneva's multitasking -- allowing NeoDesk 3.04 to run multiple applications when Geneva was running -- but it was clear that NeoDesk 3.04 was an aging and inflexible companion for the lean and powerful Geneva. The need for a modern multitasking desktop was fulfilled in NeoDesk 4, which takes advantage of Geneva in dozens of ways.

To put it plainly, running NeoDesk 4 without Geneva is like eating the frosting without the cake. Although NeoDesk 4 is able to multitask its own desktop file-and-disk operations without Geneva, it cannot do them at all while another application is running unless Geneva is present. NeoDesk 4 can, for example, format a floppy disk while it copies files from one folder to another whether or not Geneva is running, but limiting multitasking to that kind of operation turns the NeoDesk desktop into little more than a multitasking file manager and single-tasking program launcher.

Geneva is much more than a multitasking environment, of course. Technically, it is a replacement for the Atari's Application Environment Services, which provides the "look and feel" of the computer's operating system, among other things. Geneva's enhancements include the ability to put any program or desk accessory to sleep (freeing up the display and the processor's resources), a new set of program flags to control how each application is run, the ability to tear off GEM menus so they can be floated on the desktop, flexible control over system fonts and type sizes, assignable hotkeys to bring any running application to the foreground (or to open any desk accessory), complete keyboard manipulation of all menus, an advanced file selector that offers copy and delete functions in addition to unparalleled search operations, a 3D look for all GEM dialog boxes, single-keypress actuation of dialog and alert choices and much more -- all in addition to its built-in multitasking.

This is not to say that NeoDesk 4 cannot be successfully employed without Geneva. On Ataris that do not have even the moderate amount of extra memory (much less than 200 kilobytes) that Geneva requires, or on Ataris that are dedicated to a single task (running a BBS, for example), a Geneva-less NeoDesk may make sense. And everyone who owns Geneva and NeoDesk and uses a boot manager (software that lets you choose which programs and accessories are run at bootup) probably will have one or two configurations in which Geneva is bypassed in order to play older games or run odd software that won't behave on a modern system.

But my message should be made as clearly as possible: If you own NeoDesk 4 and have not yet added Geneva to your Atari, you are missing out on the single most significant advance in Atari computing since the introduction of the ST itself. And you are also likely to be disappointed in many of the sections of this guide to NeoDesk 4, because it generally addresses NeoDesk 4 as the indispensable partner of Geneva. 


Get a load of this 
NeoDesk's main software module is a file named NEODESK.EXE. Ordinarily, the ST, TT and Falcon cannot run executable files ending in "EXE," but Gribnif apparently chose this non-standard filename extension (in the Atari world, at least) to make sure that another, much smaller, module named NEOLOAD.PRG would have to be run first. When NEOLOAD.PRG is run, it launches NEODESK.EXE.

Why did Gribnif adopt this unusual way of launching NeoDesk 4? The answer lies in two other functions of Neoload. In addition to serving as the launcher for the main NeoDesk software, Neoload monitors the status of the Atari's operating system in order to report on system memory registers whenever the OS crashes, and it holds off running NEODESK.EXE until all desk accessories have finished loading.

The system-monitor function of Neoload is not, by itself, unusual. Other system monitors are available, including one that is very similar to the monitoring function of Neoload. The information that it lists on the screen after a crash is primarily useful to a software developer, although Neoload has a secondary function of providing a graceful recovery from minor system crashes. (However, you should always save your work and reboot after any system crash, even one that has been intercepted by NeoDesk 4's system monitor, because memory locations may have been corrupted, and there is no way to restore them otherwise.)

It is the third function that matters most. This function operates only when NEOLOAD.PRG is run from the AUTO folder when the computer boots up, and can be the source of confusion over how NeoDesk 4 works. If you are auto-running NeoDesk 4 without placing a copy of Neoload in the AUTO folder -- in other words, if you merely install NEOLOAD.PRG file in the NEODESK4 folder as the GEM auto-boot application in TOS 1.04 or above -- Neoload may launch NEODESK.EXE too soon, before the computer's desk accessories finish loading. If this happens, NeoDesk 4 or some of the desk accessories can lock up or behave erratically.

To prevent this, you must place a separate copy of NEOLOAD.PRG in the AUTO folder of your boot disk. (It can be placed last or near the end of the list of files in the AUTO folder; the placement doesn't matter much. Just keep in mind that the computer's operating system runs programs in the AUTO folder not in the order they are normally listed in a file-list display, but in the physical order they are listed on the disk. NeoDesk can show you the actual order of files and folders if you choose the "No Sort" option in its file-display menu, and it will let your change the order in that same menu.) Special code in Neoload delays the running of NEODESK.EXE until after all desk accessories have been initialized. The process goes like this: First, the copy of NEOLOAD.PRG in the AUTO folder installs itself in memory; then when the operating system tries to auto-run the other copy of NEOLOAD.PRG (the one in the NEODESK folder), the Neoload that is in memory intercepts the second running of Neoload, and instead runs NEODESK.EXE itself after the accessories have been installed

NEOLOAD.PRG is actually run only once in each session (the time between boot-up and shutdown), no matter how many times you may quit NeoDesk and load it again. You can easily see this for yourself. Try running NeoDesk the regular way (from the AUTO folder using Neoload as described above, or by running NEOLOAD.PRG from the Atari desktop) and then copy the NEODESK.EXE file to a second file named NEODESK.PRG. If you quit NeoDesk, you can double-click on NEODESK.PRG from the GEM desktop and re-run NeoDesk. The copy of NEOLOAD that is still in memory provides a hidden launcher for the program, even when the name has been changed. 

Memory is made of this

NeoDesk 4 can run on small-memory STs if its memory use is constrained through a dialog that allows the user to specify how much RAM NeoDesk should take up. On systems that do not employ a multitasking environment, even more memory can be retained for running programs if NeoDesk is configured to unload its own desktop code each time a program is executed. (This is done from the "File preferences" menu.) On such a system with a fast hard drive, NeoDesk 4 will reload fairly quickly after each program ends, but users with older, slower hard drives and those who have only one or two floppy drives are likely to find this process distressingly slow. In such situations it may be better to leave NeoDesk set to remain in memory except when running large programs. NeoDesk 4's "Install Application" dialog and its NeoDesk Program Information (NPI) files both provide a way of specifying how NeoDesk 4 should behave for each application, and they should be suitably adjusted for programs that need all available memory.

However, configuring NeoDesk 4 to unload its code when executing programs is pointless in a multitasking environment. NeoDesk would unload its code and run the program and then immediately load its code again. (After all, "multitasking" means NeoDesk itself and other applications are running at the same time.) Users of Geneva can maximize available memory by cutting down on the number of desk accessories that are loaded on bootup. Accessories run in this normal fashion always take up memory, whether they are being accessed or not. Because Geneva (and NeoDesk, when running under Geneva) are able to treat desk accessories as freely loadable programs, you can free up considerable RAM by placing the icons for your desk accessories on the desktop or in a group window and running them only when they are needed. 


Let the desktop do the work for you
When Apple introduced the Macintosh 11 years ago, personal computing suddenly became easier. Much of this was a result of the Mac's windows and icons and the simple way that it could be made to copy and move files or even entire subdirectories -- or folders, in a lexicon that soon became popular on other platforms. But more than anything else, the Mac was easy to use because its operating system associated data files with applications. Generally, a Mac user never has to run a program directly; all that's necessary is to double-click on a data file, and the rest is handled by the Mac.

On the Mac, all applications -- computer jargon for programs of any kind -- work this way, and so there is no such thing as an "installed application." Apple works with software developers to assign data types and icons to all new software, so that applications install themselves, so to speak.

The ST, TT and Falcon work the same way, except that applications must be installed by the user. Here, in its basics, is how the process works:

Let's suppose that you are using LHARC.TTP as your standard software for extracting archived files that have the ".LZH" filename extension. One way to use this utility would be to double-click on its icon or filename from the desktop and then fill in the "parameters" box that appears when it runs. (As a "TOS-Takes-Parameters" program, it requires command-line instructions when it is invoked.) A typical set of parameters for LHARC.TTP might be "x FILENAME.LZH" to extract all the files from the archive named FILENAME.LZH.

But LHARC.TTP is specially written to accept just the filename itself as a parameter. You could, of course, run it from the desktop and type in the filename of the archive, but there's a much easier way -- by associating a filename extension when you install each program in the GEM desktop's "Options" menu. (You must save the desktop to make the change permanent, of course.) Then, all you need to do is to double-click on the archive's icon or filename; the archiving utility automatically runs and extracts the files.

Here's another example, which is perhaps just as common. Suppose your favorite word processor is Atari Works. This application generally saves its texts with an ".STW" filename extension. If you want to edit or read an Atari Works document, one way to do it is to open up the folder where Atari Works is located, double-click on the Atari Works icon or filename, and then select the document you want to edit or read from the file selector that appears.

But that's just plain dumb. (I'm not referring to your intelligence, of course, but to the mindless way the computer would be operating in that situation.) The sensible way is to install Atari Works in NeoDesk 4 with ".STW" as its associated filename extension. Then any time you click on a file that has ".STW" as its extension, Atari Works will automatically run and load the text.

(Those of you who use this feature of GEM on a regular basis will have to bear with me for a while, since I'm convinced that only a small fraction of Atari users know about installed applications. I hope I'm wrong!)

This method of associating data files with applications does not work with all programs, but it operates with most of the ones that are written properly. It's important to note that some applications may require specific filename extensions, but others, such as text editors, usually have no restrictions.

To link applications with their data types -- filename extensions, in other words -- within NeoDesk 4, click once on the icon or filename of the application and drop down the "Options" menu. (You'll find an "Options" menu in each desktop window and in the main NeoDesk GEM menu bar.) Choose "Install Application" and type in the filename extension you want to associate with the program. You'll notice that the dialog also lets you set other parameters, and it also allows you to scroll through the full list of currently installed applications if you want to change any of their settings.

NeoDesk 4 lets you specify two data types (filename extensions) for each application. You can add more extensions by editing the NeoDesk information file -- a simple procedure, but one that could cause a disaster if you fail to heed the next two warnings:

  1. Work on a backup copy of the information file, not an original copy.
  2. Edit the file with a text editor or word processor that has word-wrap turned off and that can save its output in standard ASCII form. (An ASCII file is just text, with no word-processing codes.) STeno, EditPlus, Everest, SpiritEd, Edith, and the editors built into Flash, Flash II and Storm all meet this ASCII criterion. If you use a full word processor for this kind of editing, you're asking for trouble unless you make sure word-wrap is off and the text is saved as ASCII. If you're not sure if your word processor can do that, don't even try. (Buy a copy of STeno or EditPlus instead.)

The information file is usually named NEODESKn.INF, with the "n" representing the resolution. A typical information file for ST high resolution would be named NEODESKH.INF. It is easy to decipher. You will see a section that begins with a line that looks like this:

;Applications: type,flags,2 extensions,name,path

If you have not yet installed any applications, the entire section will be blank. Otherwise you will see each application listed in one line. Here is one for Calligrapher:


Calligrapher should not need more than two file extensions associated with it (".CAL" for Calligrapher documents and ".CAT" for Calligrapher templates, which cannot be saved until you rename them). But a program that can make good use of multiple file associations is STeno. What I am about to show you may be unfamiliar, so look it over carefully.

First, note the name of the application -- STENO2.PRG instead of STENO.PRG. On both my systems, I have many variations of STeno -- two STeno desk accessories and three STeno programs. The ones with "2" in their names are set up strictly as programmers' editors, with word wrap turned off and the default window set quite wide. I use these versions of STeno whenever I need to edit a data file. I work at the desktop extensively, and that means I am nearly always dealing with files and folders -- not applications. Why should I have to run a text editor manually when I want to edit a text or ASCII data file? It's much easier to double-click on the file. Entering lines like these in your NeoDesk 4 information file makes that possible:


Look at the extensions for STENO2.PRG. You'll see ".TXT," of course, but you'll also see ".SYS" and others that are usually not considered as texts. But in many cases, they ARE texts -- with ASSIGN.SYS being the most prominent example. Note also that I also list these extensions ending in "X," is in ".SYX" and ".DAX." This allows me to double-click on a data file that is, in effect, turned off (hidden from its application through the renaming process) and still edit it via STeno.

Note that under a multitasking environment, the same copy of a properly written application can be running in multiple instances at the same time. This makes multiple associations even more powerful. 

INFinite wisdom 

Within the NeoDesk information file itself, or (preferably) within NeoDesk's "Set Preferences" menu (under the "Options" drop-down menu), you can add to the list of executable file types or change the ones that are already listed. Normally, the only executable file types are those that end in these extensions: .APP, .PRG, .TOS, .TTP and .GTP, in addition to the special NeoDesk-compliant applications, which have the extensions .NPG and .NTP, and NeoDesk 4's program information files, which end in .NPI.

The extensions have these meanings:

.APP - Application
.PRG - Program

(Applications and programs are usually the same thing. They are standard GEM programs, although they do not need to have GEM windows. Some programmers stick to the rules, and use .APP only to refer to programs that can also run as desk accessories if you change their extension to .ACC.)

.TOS - "The Operating System" program, which does not make use of the GEM desktop built into the operating system, and does not ordinarily provide access to desk accessories.

.TTP - "TOS-Takes-Parameters" program, a TOS program that normally requires command-line input from the keyboard, from another program or from any other source. A common .TTP program is ARC.TTP, and a common parameter for ARC.TTP is an archiving command followed by the path and name of the archive. (Example: ARC.TTP X MYFILE.ARC, which tells ARC.TTP to extract the files in the archive named MYFILE.ARC.)

.GTP - "GEM-Takes-Parameters" application, an .APP or .PRG that behaves like a .TTP file in some ways.

.NPG - "NeoDesk Program," a specially written .APP or .PRG that communicates with NeoDesk. There are only a few .NPG applications.

.NTP - "NeoDesk-Takes-Parameters," an .NPG program that accepts command-line input.

.NPI - "NeoDesk Program Information" file, a set of instructions that NeoDesk passes to a program that is being run. These are described separately in this guide.

If you are using Geneva, you should add other extensions to this list. They are .PRX and .ACX, which represent executable files that are "turned off" so that they cannot be run at bootup. If you are really fastidious, add ".APX" also.

A small digression is in order to help explain this X-rated business. All modern Atari computers ordinarily use two disk locations to determine which executable files are run when the computer boots up. The first is the boot drive's AUTO folder and the second is the boot drive's root (main) directory. All .PRG and .APP files found in the AUTO folder are run at bootup, and the first six .ACC files found in the root directory are initialized.

You may know already that Geneva eliminates the vexing limitation on the number of .ACC files that are loaded at bootup. (There is no practical limit.) And you may know that Geneva is able to run these desk accessories even if they are renamed with an .ACX extension. Likewise, if its configuration is set accordingly, Geneva is able to run programs that have a .PRX or .APX extension. NeoDesk 4 can do the same thing.

But Geneva and NeoDesk will not do this at bootup time. This means you can hide files from the autorun routines by renaming them with an "X" as the last character of the filename extension even if Geneva and NeoDesk 4 have those files listed as executable. They will still be executable, but only after the regular part of the bootup has finished. (.PRX and .ACX files can be run by Geneva from "run" or "runacc" statements in its GEM.CNF file after the regular part of the bootup has finished, but they will be ignored in the AUTO folder or in the desk accessory path otherwise.)

By listing .PRX, .APX and .ACX files as executable under NeoDesk (and Geneva), you provide a way of running these programs at any point after bootup -- even if the .PRX files are in the auto folder. (Yes, you can often run an AUTO-folder program after bootup without a problem.)

NeoDesk has another category of executable files. These are batch files, which technically are executable only in the sense that they are scripts for a batch-file interpreter. CLIs (command-line interpreters) usually include the ability to run batch files, as do such shell programs as Gulam and TomShell. Two types of batch file can be installed in NeoDesk 4: .BAT (a standard batch file) and .BTP ("Batch-Takes-Parameters"), a NeoDesk-specific batch file run by the NeoDesk CLI desk accessory. Installing the extensions .BAT and .BTP in the NeoDesk information file tells NeoDesk to run the CLI or shell of your choice, feeding the batch file to the CLI or shell for immediate execution any time you click on a filename or icon with either of those extensions.

You must first list the path and name of the CLI or shell in the "Paths" submenu under the "Settings" menu. If you do that, NeoDesk 4 offers a keyboard shortcut to run your CLI or shell. This is Control-B. This shortcut will not work if you have not installed the CLI or shell in the "Paths" entry line. 


How GEM ought to be 
The first graphical user interfaces were welcome changes from the character-based command-line systems that were common until the 1990s. But as intuitive as a window is as a bordered space for file and program activity, a window in itself is just a fancy box. Working within that box makes sense up to a point -- that point being the difficulty of accessing menus at another place on the screen just to manipulate the contents of a window.

That's the way Atari's GEM works, and how the Mac's desktop works, too. Under a single-tasking operating system, this limitation is perhaps too minor to worry about, but it becomes quite a liability under a multitasking system such as the Geneva-NeoDesk 4 combination. Each desktop window in such a system is potentially active even if it is not in the foreground, but working in separate windows becomes an exercise in eye-and-hand coordination if the only menus available are in a shared GEM menu bar at the top of the screen.

NeoDesk 4 removes that limitation in its enhanced GEM windows. Each one is a full GEM window, complete with menu bar and menus, instead of a box where file operations take place. You will notice that some menus in NeoDesk 4's windows are duplicated in the main menu bar, but many are not. This frees up the main menu for options and functions that pertain to NeoDesk's general operation. 


Why didn't Microsoft do it this well? 
NeoDesk 4 differs radically from the TOS desktop by incorporating Groups. These are files and folders that can be displayed in special Group windows on the NeoDesk desktop.

What's this all about? What's wrong with file and folder icons? Why use Groups?

In one way, NeoDesk's Groups resemble Program Manager groups in Microsoft Windows. Windows 3.1 and 3.11 (the current consumer versions of Windows as of the first half of 1995) split file-copying operations from program-launching functions through two main applications -- File Manager and Program Manager. Despite the size of Microsoft's software engineering staff and the hundreds of millions of dollars the company spent developing Windows, Microsoft's dual-function treatment of files and programs in Windows is confusing and ineffectual. (A large software industry specializing in replacements for those two Windows applications has made a lot of PC software writers wealthy.)

But what makes the Windows Program Manager attractive to untutored PC users is its grouping function. If you drag a program out of a File Manager window into a Program Manager window, the program file itself stays in its original location while Windows creates an alias for that program -- a launcher icon -- within the Program Manager window. If you have two word processors, you could create a Program Manager group called "Word Processors" and place an icon for each one in that group. This way, no matter where those applications are on disk, you can launch either of them from one location.

That's what NeoDesk 4's Groups allow you to do, too. But NeoDesk's Groups are much more powerful. NeoDesk's Groups contain active aliases, not just program launchers, and, also unlike the groups in Windows, they can contain folders in addition to files. And NeoDesk 4 Groups can be nested hierarchically; Groups can be placed within other Groups at any time. 

Getting rid of FOOBAR3.PRG and THSBGFIL.DOC 

NeoDesk 4 Groups also surmount one of the oldest problems of every DOS and DOS-like computer disk operating system -- the limitation on the length of filenames. PCs and Ataris both labor under that restriction (under MS-DOS for PCs and TOS for Ataris), which limits the main part of a filename to eight characters and the extension -- the part of the name that follows a period -- to three characters. This limitation is removed in all Group windows. Whether the items in the Group window are displayed by icons or by text, the names can be normal words. They can contain capital and lower-case letters, spaces, punctuation marks and even special characters such as trademark or copyright symbols. Furthermore, whenever Groups are listed in regular NeoDesk 4 desktop file-and-folder windows, their names are also displayed in normal language, not as such filenames as MYWORDP.GRP (as they are in Microsoft Windows). 

Try it - you'll like it

NeoDesk 4 Groups are easy to create. Every desktop file window has a "New Group" option in its File menu. Groups can also be created automatically by NeoDesk when it performs a search. Groups must be given a name before they can be saved.

Because the notion of groups is new to Atarians (at least to those who have not used Microsoft Windows on a PC), I'll explain the uses of NeoDesk Groups in some detail. If you have not yet created and used NeoDesk Groups, you may discover a new dimension to everyday computing.

The primary function of a group in NeoDesk 4 is obvious: It puts programs, data files and folders where they can be easily located. Here's the most basic example: If you create a Group for all your graphics applications, all you need to do to run one of them is to open the Graphics group and double-click on the icon or name of the one you want to run. This Group can be made up of programs stored in different locations on your hard drive, and it can also contain folders for various kinds of graphics files (Spectrum 512 pictures, GIF photos and so on) no matter where they are located.

Here's another example, taken from my own setup. All my primary utility programs and configuration files have been placed in a Group called Quick Utils. By opening that Group window, I have easy access to all the utilities and data files. (The data files include the ASSIGN.SYS file that GDOS uses, the GEM.CNF file needed by Geneva and the NEOD1024.INF file used for my standard-display mode in NeoDesk 4, among many other files.) These files are located in scattered folders on various drives, but they are all accessible from one Group window.

The icons (or names, in a text display) in a Group window are active. That is, they do not simply launch a program. They are capable of all the drag-and-drop operations that can be performed by the files to which they refer. The only limitation in the functionality of Group members is that renaming, deleting, copying or moving them does not perform those operations on the original files. (This is intentional, of course; you would not want to endanger the original files in this way.) They are also linked immediately to their original files if you press the Control key and double-click on a Group member. This operation opens a new window on the desktop to the location of the original file or folder, making file functions very simple when you need to rename, delete, copy or move those items. 

Groups that care for MIAs

Yet Groups are even more powerful than these examples show. While it is clear that Group members represent files and folders in another location, it may not be obvious that they can represent items that are NOT locally stored. In other words, you could create Groups for every floppy disk in your collection. You could then open those Group windows and use them either as a way of checking for files without needing to access the floppies or as a way of providing quick access to the contents of any disk you put in the floppy drive. In my setup, I have created Groups for every CD-ROM disk in my collection. When I put a particular disk in the CD-ROM drive, I merely open the Group window corresponding to that CD-ROM and get instant access to the entire contents -- without opening any file-and-folder windows on the CD-ROM itself.

I also use Group windows to catalog my secondary backup disks. (Secondary backups, in my system, are disks holding archived files created with a standard archiver instead of a backup program. These are held offline as insurance against problems with the primary backups, which are created with a backup program.) If one of my backups fails, I have to do nothing more than open a set of Group windows to determine which backup disk (a Floptical) contains the file I need.

Another Group I use was automatically created by NeoDesk 4's search function. I have a lot of GDOS, Degas (Warp 9), Speedo and TrueType fonts in dozens of locations on my main drives. Rather than trying to move them all to a single set of folders on one drive, I had NeoDesk 4 search for files matching the specifications for these fonts. I saved the search results as a Fonts Group. Now any font is just a click away, after opening just a single window.

And another Group holds entries for all my articles about Atari computers. Most are stored in Calligrapher's own file format, but some are ASCII texts and others are saved in the Atari Works format. Yet they are all in the same Group window, and all have descriptive names (not WHAT_DA.CAL or GENSECR.STW and that kind of thing). Because these Group members are aliases for files that NeoDesk already associates with their applications, all I have to do is double-click on any Group entry and it will appear in a second or two inside the application that created it originally.

This is an important function of Groups that many users may not understand. Groups do not have to be made up of programs; they can be put together from any items stored on disk. A common use I make of a Group I call New Docs is the temporary listing of documentation for new programs. Rather than digging out the doc file in a folder half-lost somewhere on one of my drives, I merely drag the document icon to the Group window and access it from there. It is always instantly available that way.

You may want to consider creating a Master Group that holds all your other groups. If you place the icon for the Master Group on the desktop, you will always be able to open any Group window quickly. 


Pass parameters and collect $200
When Atari created TOS, its software engineers designated two very different ways programs could run. They could be mouse-and-window applications -- PRoGrams, which had to have names ending in ".PRG" -- or they could be text-based applications that did not use the mouse and its associated paraphernalia. These are called TOS applications, and they look for all the world like programs that run under the standard PC operating system, MS-DOS. (They are, in fact, quite similar to DOS programs in some ways.)

But Atari did something unknown in the MS-DOS world when it settled on TOS programs as the non-mouse (or non-GEM) applications that would run on the ST. It made two categories -- one for TOS programs that needed parameters and one for the ones that didn't. If this is all gobbledegook to you, stick with me; TOS programs can be very important, and the way they run can be applied in a more general way, too, now that Atari programmers have learned how to unleash the full power of both GEM and non-GEM software.

I remember how disappointed I was the first week I spent with my new 520ST nine years ago when I discovered that least friendly version of all Atari programs, the .TTP monster. Double-clicking on a .TOS program made it run, but double-clicking on a .TTP program made a box appear on the screen asking me to type something. If I'd wanted to type something at a command line, I would have stuck with my Atari 130XE and its wonderfully adaptable operating system, SpartaDOS. Here was a computer with a graphical user interface that suddenly reverted to the old type-in-your-favorite-command system -- that is, if you were able to remember the command you were supposed to type in. If you ran the early version of ARC in those days, you were supposed to type in "-X" or "-E" or just "X" or "E" (I'm glad I've forgotten which it was!) followed by the path and filename to extract a file, like this: -X A:\ARCFILES\THISFILE.ARC.

I hated .TTP programs. Under later versions of TOS, I found that I could drag the icon of a file to the icon of the .TTP program and get at least part of the command line filled in by TOS. But I had to do the rest. Even NeoDesk 3, the first modern version of Gribnif's desktop, wouldn't free me from this horrible backwater world of command lines and parameters; it still acted like TOS did, forcing me to fill out the rest of the command line. (And NeoDesk 4 still acts the same way, unless you do something about it. The problem is not with the desktop but with the rules of TOS; a .TTP file needs parameters. That's what .TTP means, after all -- TOS Takes Parameters -- and so if you double-click on a .TTP file or drop another file onto it, even NeoDesk 4 will poke a dialog box in your face and tell you to fill it out.) In yer face, indeed! This is NOT my idea of a user-friendly system.

It doesn't have to be that way. I'll tell you how you can get around this inconvenience shortly. 

You use parameters every day

But first we need to look at parameters another way. They're not just instructions on a command line you type in. And they don't just go with .TTP programs. Any Atari program can be written to use parameters, and most major pieces of software are, in fact, written that way. We usually don't think of them as using parameters unless we encounter one of those rare .GTP programs -- a GEM program that Takes Parameters. But parameter-passing is common, and it's exactly what takes place any time you drop an icon for a data file onto the icon for a program. (My favorite example is dropping the icon for a ZIP archive onto the icon for STZIP.PRG. The operating system runs STZIP and passes it the parameter of the path and filename of the ZIP file. But another common example is dropping the icon for a text file onto the STeno icon or the icon of any other word processor.)

This is a simple kind of parameter passing. Some specialized programs such as LHARC.TOS (which is generally distributed as LHARC.TTP for no good reason) allow a dozen or more separate parameters to be passed to the program when it runs. Some programs almost beg for parameters in order to run properly. A good example is JonDOS, one of the better command-line interpreters for the Atari, which will misbehave under Geneva unless it is run with "-t" as the parameter. This tells it to act like a TOS program -- no mouse, with all operations occurring within a standard TOS 25-line display -- instead of a GEM program.

(A digression is again in order. LHARC takes parameters, so it is normally distributed as a .TTP program. But this can defeat one of the cleverest features of LHARC, its ability to automatically run and either extract an archive's contents or compress a file or folder without a need for any action by the user. LHARC does this by examining the parameters the operating system passes to it. If the parameters include a filename with the extension ".LZH," LHARC extracts the archive to a folder. If the parameters do not include ".LZH," LHARC creates an archive and compresses the file or folder listed in the parameters. This is all very elegant; drop a folder on the LHARC icon, and it does the rest, creating an archive. Or drop the icon for an LZH file onto the LHARC icon, and it extracts the contents to a folder. But this will NOT happen so elegantly if you insist on using LHARC with its original filename extension, .TTP, because the operating system will stick that dialog box in front of your face and tell you to fill it out, as it must do with .TTP programs.)

To a word processor, a text file can be a parameter. But the same kind of operation can take place with other software, too. You can run Flash, the original high-power telecommunications program for the Atari, by passing it a parameter that consists of the name of one of its DO files. (DO files are scripts that tell Flash what to do.) You can run STalker, a modern Atari telecomm program, with a parameter that consists of the name of a BackTALK script; STalker will run, load the script automatically, and execute the instructions in the script. There are countless other examples.

But how do you do that? Ordinarily, you look at the icon for STalker, and you see only one thing you can do with it to get it to run -- you double-click on it. But you could drag the icon for a BackTALK script onto the STalker icon (or onto its name in a text-only window display, of course) and it would run and execute the instructions in the script. You could do it that way, that is, if you have the script icons and the STalker icon handy; you can't drag something that's not available on the desktop or in a window. 

Give me an N! Give me a P! 

NeoDesk 4 offers an easier way. It's also a more powerful way. It's called the NeoDesk Program Information file. An NPI can do much more than what I have suggested here -- there is probably no limit to the inventiveness you could put an NPI to -- but at its most basic it can readily automate such tasks as passing parameters. When you set up an NPI, you'll see a dialog for entering the parameters. Keep in mind that some programs do not behave as you might expect when they receive parameters, so you'd be wise to experiment. (You can't hurt anything.) Start with something simple, such as passing a script name to a telecomm program, and then graduate to something more complicated. (With LHARC, you could create one NPI that ran LHARC in minimal-memory mode, another that ran it in maximum-memory mode, and so on. If you double-click on LHARC.TOS with no parameters, you'll see a list of possible commands that can be passed to LHARC on startup.)

NPIs can be named by normal-language conventions ("Mini-LHarc," for example) instead of by the 8-and-3 ("MINILHAR.NPI") requirement of normal filenames. Unfortunately, NeoDesk 4 has a bad habit of overriding the name you have chosen and using its own best-guess filename, which uses the old 8-and-3 convention. If this happens, change the name NeoDesk assigns back to a normal phrase. (Note that a file display under NeoDesk 4 shows the name you assigned, not the 8-and-3 filename, but a display using a utility such as MaxiFile or the Geneva item selector will show the TOS filename.)

Because NPIs are program-launching instructions and not executable files per se, they are very small, taking up only one sector, the minimum amount of individual space that can be allotted on a floppy disk or hard disk. This means you can store all your NPIs in one place without a problem. It also means you can place them in Groups easily. But try to resist the temptation of creating a Group just for NPIs. It makes no sense having one icon in a Group run LHARC and another run STalker; rather, place your NPIs into the Groups they naturally fit into, with archivers in one Group and telecomm software in another, or utility software in one Group and applications in another, and so on. 


RAM cram can be a thing of the past
A powerful desktop shell can be a hungry one, too. It could require a lot of memory, depending on how it is set up. In one installation I configured, NeoDesk 4 was running in 15-bit color mode (more than 32,000 colors visible at once) on a Falcon and displaying a large background picture; it had 400 to 450 icons, and booted up with six desktop windows open, each of them full of files and folders. I probably don't have to add that this NeoDesk 4 setup took a lot more memory than the setup I use on my ST, which has no extra icons, boots up with no desktop windows open and has only a simple desktop pattern.

But this is one of the strengths of NeoDesk 4. It can be large and impressive or lean and mean. NeoDesk 4 does this many ways.

First, NeoDesk 4 can be set up like my ST instead of my friend's Falcon. You can choose to leave out extra icons and desktop pictures, and you can keep extra desktop windows closed when you do not need them. (A desktop window that displays 100 or more files consumes extra memory. Add four or five of them at the same time and memory consumption rises quite a bit -- needlessly, in most cases.)

Second, NeoDesk 4 lets the user specify how much memory it should take, in two separate approaches. You can limit NeoDesk to a specific maximum amount of memory or you can tell it to take a minimum at all times. (You can also set no limits, which is the preferred way for those with four or more megabytes of RAM.) This may be confusing, so I'll try to explain.

The first approach, which limits the total amount of memory, keeps NeoDesk 4 from using memory that may be needed for applications that do not behave properly when run under a shell such as NeoDesk. Behavior such as this is also influenced by the version of TOS that NeoDesk 4 is running under. Applications that are well behaved in terms of memory usage normally won't have a problem with NeoDesk 4's preferred setting, which is to let it take all the memory it needs.

The second approach, which specifies a precise amount of memory that NeoDesk 4 should always occupy, may work better than the others if your Atari's RAM tends to become fragmented over a long period of time. (If you reboot often, fragmentation probably can be ignored. But if you regularly run your computer for weeks at a time without rebooting, you may want to begin checking on the amount of fragmentation.) Many of the operations NeoDesk 4 performs require extra memory from the operating system's pool of RAM, and this memory is always released back to the operating system later. But in a multitasking system (and within NeoDesk alone, which always is able to multitask its file and disk operations even without Geneva), the operating system may be supplying memory to more than one process at a time. Because there is no way to know whether these operations will return their blocks of RAM in the same order they obtained them, there is no way to control possible fragmentation of RAM in these situations. (There are ways to defragment RAM in some operating systems, but none that have been implemented on Ataris so far.)

This second approach, setting NeoDesk 4's memory consumption to a specific minimum figure, prevents NeoDesk 4 from asking for extra memory during desktop operations and keeps it from shrinking its memory consumption during idle time, and this is what can help reduce fragmentation. In a typical desktop file-copying operation, NeoDesk 4 will otherwise try to appropriate nearly all available memory, using RAM as a copying buffer.

There are no hard and fast rules for the memory settings. If you choose to limit NeoDesk's memory, try settings that are quite low and see if NeoDesk complains. (If NeoDesk runs out of memory for its own operations, it will alert you to that.) You may notice that file-copying and -moving operations are slower, especially when NeoDesk 4 is dealing with a lot of small files or a few very large files. This could be an acceptable tradeoff, especially in light of NeoDesk 4's ability to do file operations in the background. Since you are able to continue other tasks during these functions, you may not care if they run slowly. 


Getting NeoDesk 4 to work with both hands
Even when Geneva is not running, NeoDesk 4 has an amazing ability to perform background file operations. Files can be copied or moved while you do other operations at the desktop -- creating Groups, setting up NPI files, formatting floppy disks, and so on. If you are copying or moving files from one folder to another and begin another copying or moving operation, NeoDesk 4 will add that operation to its queue and perform it when the first operation is done. (NeoDesk 4 cannot perform more than one file operation at a time, even under Geneva.)

Floppy formatting is a special case. Not only can you do file operations in the background while formatting a floppy; you can format a floppy disk AND do file operations while doing anything else at the desktop. This facile manipulation of the generally uncooperative floppy-disk controller is one of Gribnif's minor triumphs in NeoDesk 4, and I know few Atarians or PC users who are not amazed when they see NeoDesk 4's background formatting in action. 

Geneva adds the muscle

But NeoDesk 4's ability to place such tasks in the background is most useful under Geneva. Background file operations are particularly handy during telecommunications sessions, when you can move downloaded files to separate folders, for example, and they are just as useful at many other times. NeoDesk 4 and its partner, Geneva, will let you create archives with STZIP or the superb LHarc-Shell while formatting floppy disks to place those archives on -- and while doing any other tasks as well. In my own systems, I regularly download files from GEnie using a background telecommunications program while performing file-copying operations and writing in Calligrapher or Atari Works. Because NeoDesk 4 provides a user-adjustable control over the amount of processor time given over to file operations, you can fine-tune the background response of NeoDesk for your own setup. The slowest (leftmost) setting of the background adjustment frees up the CPU for other tasks with minimal intrusion even on an 8MHz ST; on my 48MHz TT, it exacts no apparent toll, even when the TT is formatting a floppy at the same time. (I generally set the adjustment at the second button, which seems to be a good compromise between background speed and foreground operations on both my 16MHz ST and on my TT.) 


Finding a way to locate files singly or in groups
Hard-disk space is cheaper than ever, and that means more and more Atari users have big hard drives. And that, of course, means those disks are getting filled with all sorts of stuff. (The phenomenon of Fibber McGee's Closet -- the drive that is always full no matter how big it is -- is worth looking at another time.) All that space is great, but how do you find those odd files you stuck in a folder deep inside some other folder five months ago? How do you ferret out all those strange-looking "*.C" files and ".PRJ" files that you've accumulated with every download of one of those big German applications? And how do you check your entire file system, every drive, every folder, to make a list of all your GIF graphics?

NeoDesk 4 has the answer. In NeoDesk's Search function, you are offered the power to locate any file or combination of files on every drive in your system. And you can even automatically create a Group out of every file search just by choosing the Group option.

NeoDesk 4's Search function offers the old-fashioned set of wildcards that every other search method has -- using the question mark and the asterisk to represent single characters in filenames (the question mark) or any group of characters (the asterisk). The asterisk, as most users may already know, can even denote the absence of characters.

But NeoDesk 4 goes further. Using advanced wildcards common in Unix but largely unknown in TOS, NeoDesk 4 lets you specify a range of characters that should be included or excluded in the search, so that you could, for example, have NeoDesk 4 find all files that begin with "A" or "B" but not "C" or other letters and that have "DOC" or "TXT" as their filename extensions.

Setting up searches this complicated can take a lot of time and keystrokes, so NeoDesk 4 also lets you save the search criteria. The next time you need to do the same kind of search, you simply load the particular Search file.

The addition of the automatic Group creation makes NeoDesk 4's Search method an ideal way to create Group files quickly. After the Group has been set up, you can edit it to take out extraneous files and to add descriptions. Let's look at an example.

Suppose you have a lot of shareware programs, each in their own folders. Most of them come with short "README" files and longer documentation texts, but they never seem to be where you can find them when you need them. You could, of course, make copies of all of them and put the copies in a central folder, but that would be an immense waste of space. You could also print all of them out, but that would be an even bigger waste; after all, you may not need to have more than a few of them handy as printed documents. But you do need to be able to get at any of them.

A Group file is the perfect answer. Just set up a search for all "READ*.* files and all "DOC" and "TXT" files and save the results in a Group. Put that Group file in a convenient location, and all your documentation files will be available for browsing in seconds.

TIP: Make sure you save that Group with the full pathnames displayed so you can tell the difference between one "README" file and another. You may want to save the group with the text-display option rather than iconic display, because text mode will show the locations of the files instantly. 


Using GDOS bitmapped and Speedo scalable fonts in windows 
NeoDesk 4 offers many ways to dress up your desktop, but the one that can add a finishing touch is its employment of as many as four separate fonts for the displays within windows, in window information bars and on the desktop itself. You do not have to choose these fonts, of course; NeoDesk will use its defaults ordinarily, but you can achieve some stunning effects if you play around with GDOS bitmapped or Speedo scalable fonts for any or all of the four selections. 

What GDOS is and why it's not built into the computer 

Users who are new to GDOS fonts may need a brief explanation of what's needed to get them to work. (If you're an old hand at this, just skip to the next section.) GDOS (the Graphics Device Operating System) is a much-maligned add-on part of the Atari operating system that, in fact, is an amazingly powerful feature in all Ataris. Atari had planned to incorporate GDOS into the ROMs of all STs (hard-coded into the computer's operating system, in other words), but left GDOS out at what was practically the last minute. In place of a ROM-based GDOS, Atari supplied a GDOS program on disk. The first version slowed down the operation of the ST horribly, but an improved GDOS was quickly issued by Atari and by others. (AMCGDOS is one of the most popular improved GDOS programs and is free, but there are others that are better, as we'll see in a moment.)

GDOS is something like a translator for devices attached to the computer -- printers, the display screen, plotters, that sort of thing. It handles most of the work involved in getting, for example, characters of various sizes and types on the screen and on the printed page. (GDOS is MUCH more complicated than this, but I'm trying to keep things simple so we can concentrate on fonts.) Regular GDOS supports fonts that are stored as graphical dot-by-dot images. These generally come in in two basic versions, one for screen characters and one for printed characters, and they are not resizeable. (They actually can be made twice as big, to give an example of apparent resizing, but they are not resizeable in any manner that retains their appearance.) These dot-by-dot-image fonts are called bitmapped fonts because each part of every character is mapped to a grid of dots on the screen or on the page. Bitmapped fonts work very well but have a single, very significant drawback: Since each character is stored as a collection of dots for a single size on the screen or on paper, the only way to get characters of differing sizes is to store separate versions of each character for every size you may want to use. In other words, you'd need a separate font file for 12-point type, 14-point type, 18-point type, and so on. If you really want to have a lot of choices in font sizes, you'll need to store a lot of fonts.

Font technology improves year by year. The most dramatic improvement for all computer systems is the development of scalable fonts, which are stored not as dot-by-dot graphics but as mathematical codes. These codes can be very complicated, but that sort of thing is relatively easy for a computer to deal with.

The good part of scalable-font technology is that characters that are stored as expressions of curves and straight lines can be made any size without changing their basic appearance. (This is technically oversimplified, because the best scalable-font systems actually DO change the way characters are drawn at small sizes to keep them readable, in a process called "hinting." Speedo GDOS and the TrueType system both use hinting.) Because only the mathematical codes are stored and not the bitmaps themselves, a single scalable font file can replace the dozen or more bitmapped font files that would have been needed to make sure all typical sizes are available in that font. And, of greater importance to a desktop publisher, that single scalable font file can be used to make ANY size characters, whereas a bitmapped font file is limited to one size only, preventing the user from altering documents for a more pleasing fit and appearance if the ideal font size is not available.

The bad part of scalable-font technology is that scaling characters on the fly takes time. A 16MHz ST or Falcon and a 32MHz TT will generally work fast enough with scalable fonts, but 8MHz STs may bog down quite a bit. That does not mean scalable fonts can't be used with 8MHz STs; instead, it means users with slower STs should do everything possible to speed things up -- by eliminating desk accessories that are taking up processing time, for example, or by using the fastest available font-scaling systems. NVDI 3 is generally considered one of the most flexible GDOS systems, and is highly recommended, especially since it handles both Speedo and TrueType fonts.

Fonts of both types are drawn under the control of GDOS. In the past, most applications that took advantage of GDOS were word processors and desktop-publishing applications, but this has changed with continual improvements in both GDOS and font technology. Today it's not uncommon to find applications of nearly all kinds supporting a range of fonts. The popular LHarc-Shell is one example of a relatively simple application that allows full control, through GDOS, of the fonts used in its file-display lists.

NeoDesk 4 uses GDOS to provide a choice of fonts and font sizes for these distinct display areas:
  • Captions (descriptions) under the desktop icons.
  • Small-text listings in desktop file-and-folder windows.
  • Large-text listings in desktop file-and-folder windows.
  • Information lines near the top and at the bottom of desktop windows.

You should note that even without GDOS, NeoDesk 4 lets you change the size of the font used for any of these displays. The font will always be one the system fonts. (In some resolutions, you will not have all of the system fonts available.) But with GDOS, you can change both the appearance and the size of the fonts. 

It's all a matter of proportions 

The standard fonts built into all Atari computers have evenly spaced characters, each the same width and the same distance apart, within a single font. This is how a typewriter's font looks, but it is not the way most published documents in books, newspapers and magazines look. They use fonts that have variable-width characters, with the "m," for example, taking up a lot more space than the "i" and "t" characters. These proportional fonts add a finished, professional look to the screen display, and can be used in two of the display areas in NeoDesk 4 -- the caption line under desktop icons and the information line above and below desktop windows. These do not have to be Bitstream Speedo fonts; they can be proportional bitmapped GDOS fonts. You may have to experiment quite a bit to find a proportional font that looks good and is readable as the icon caption font, but you shouldn't have any difficulty assigning a proportional font in the range of 9 to 12 points for the information line.

Proportional fonts cannot be used for the small- and large-text listings in desktop windows. If you select non-system fonts for these displays, try to use fonts that have thick letterings to enhance readability. 

GUI or not, sometimes text is a better choice after all

NeoDesk 4 normally displays files and folders as icons within each desktop window. This is often the most informative type of display because icons can be uniquely shaped and colored for each item they represent. (After all, this is part of what a graphical user interface is all about -- graphics!) But there are times when an icon-based display is not the best method. A text display can show many more items, of course, but the main point is that in a window in which all items are of the same kind of file (a group of GIF pictures, for example), an iconic display will have no graphical advantage, since the icons will all look alike. In that kind of situation, a text display makes more sense.

NeoDesk 4 allows mix-and-match selection of icon and text displays within desktop windows. This can be especially handy for ST Medium Resolution screens, where icon displays take up a lot of room, and can be useful in ST High Resolution mode, too, when many windows are open. NeoDesk 4's Group windows take up only a small amount of space in text mode, permitting a desktop with dozens of applications and other items to be listed in group windows even in ST Medium Resolution. 

Note this, please

NeoDesk 4 also uses modern font technology to good effect in its Desktop Notes, a feature that has long been one of the trademarks of NeoDesk. (This is literally true; "Desktop Notes" is copyrighted by Gribnif.) Whereas previous versions of NeoDesk limited Desktop Notes to a few brief messages in a plain Atari system font, NeoDesk 4 allows lengthy notes in any Bitstream Speedo font, large or small, in addition to any of the system fonts. In order to use Speedo fonts with NeoDesk 4, you'll need Speedo GDOS or NVDI version 3 or newer. (Although the latest versions of Speedo GDOS and NVDI also support other scalable fonts, NeoDesk 4 cannot display Desktop Notes in TrueType or PostScript formats.)

Proportional Speedo fonts look especially good in Desktop Notes. Most Speedo fonts are proportional, so, if you already have a set of Speedo fonts, you no doubt have proportional ones. (Regrettably, the non-proportional font originally distributed with Speedo GDOS, Monospaced 821, is one of the worst examples of monospaced fonts I have ever seen. Bitstream's Courier is much better.)

When you choose a Speedo font for Desktop Notes, you may find that a sans-serif font looks better than a serif font. Serifs are tiny strokes that generally make each letter look more interesting, and usually make the text more readable. But if you use serif fonts at smaller sizes on a typical Atari display, the serifs are too small to be accurately rendered. On the other hand, a serif font such as Bitstream's Charter or Windsor can be very attractive on the screen at larger sizes.

Keep in mind that NeoDesk 4 places its Desktop Notes on an unseen grid based on the height of the font, so if you put a Desktop Note in small type on the bottom of the screen and then use the Desktop Notes dialog to make the type larger, NeoDesk may place it off the bottom of the display. If this happens, set the size back to what it was and erase the note, then change the size and write it where you want it to appear. (If you don't do it this way, you'll never be able to get at the Desktop Notes because they'll stay hidden off-screen!)

If you use Speedo GDOS, which generally takes up considerable memory, you may not want to have a Speedo-font Desktop Note displayed all the time. If your Desktop Notes are used more for display than for quick note-writing -- if, for example, you create Desktop Notes that show a permanent message -- you can use Imagecopy or any other good snapshot utility to create an image of the part of your screen containing the Desktop Notes; this can then be used as a desktop background when your computer is not running Speedo GDOS. 


What you see is what you got
The popularity of the large-screen displays for the ST, TT and Falcon has changed the demands on the desktop. Where once a resolution of 640 X 200 was normal and a resolution of 640 X 400 was considered "high," for many users the standard TT and Falcon resolution of 640 X 480 is now considered normal -- and a display with four times that resolution (1280 X 960, TT High Resolution) is not uncommon. The old standard of a four-color desktop for normal use (the maximum that is possible in ST Medium Resolution of 640 X 200) has been eclipsed by the 16- and 256-color displays of the TT and Falcon, and even so-called True Color displays (showing thousands or even millions of colors) are possible on some Ataris. Clearly, the desktop is a more detailed and more colorful place than ever before.

Yet while NeoDesk 4 is unique in taking advantage of these large-screen displays, it is still capable of running to full advantage on even the oldest display standard for the ST, the 320 X 200 ST Low Resolution screen. All the extended features of NeoDesk 4 -- background pictures in color, animated icons, dialog boxes in their own windows and more -- function in ST Low Resolution mode, too. And because ST Low Resolution supports NeoDesk 4's 16-color icons, owners of the oldest and simplest STs are able to enjoy the rich graphical interface of NeoDesk 4 just as owners of the most expensive Ataris are. 

If icon, you can, too

NeoDesk 4's handling of color-plane settings (color modes) is unusual. Whereas older versions of NeoDesk were not able to deal effectively with colored icons when the desktop was running in monochrome -- the icons usually turned out to be black on black -- NeoDesk 4 has three separate icon configurations. If the computer is running in monochrome (either black-and-white mode or the unusual "duochrome" mode of some Ataris), NeoDesk 4 displays two-color icons; if the computer is running in any color mode that has more than two colors but less than 16, NeoDesk 4 displays four-color icons, and if 16 or more colors are present, NeoDesk 4 uses 16-color icons. These are separate icons, not just icons that look different in different displays. A folder icon, for example, can look entirely different in monochrome than it does in four-color mode, and both of them can be different from the folder icon used in 16-color mode.

What if you have created icons in, say, 16 color mode but not monochrome, and then boot up in monochrome? The older versions of NeoDesk would have turned every color in an icon to black, but NeoDesk 4 dithers color icons to gray patterns if it cannot find corresponding monochrome icons. These are often not satisfactory for everyday use (you will want to create your own versions at some point), but they are much better than blacked-out icons.

NeoDesk 4 handles icons in another smart manner, too. Normally, the same icon may be used to represent any number of items (a Swiss army knife icon for a disk utility, for an undelete program and for a control panel applet, for example), and you may find you are assigning hundreds of icons but using only half that number in unique ones. NeoDesk 4 checks the images in its icon file for duplicates and stores pointers to icons that are the same, saving memory and disk space. 

We do Windows

Unique among Atari desktops, NeoDesk 4 is able to import icons in the Microsoft Windows format. Nothing special needs to be done. You merely run the NeoDesk 4 icon editor. It recognizes both separate Windows icons and multi-icon Windows icon files. You can drag a Windows icon into the NeoDesk 4 "NEOICONS.NIC" file and use it immediately, or you can edit it to add animation and support for monochrome and other color planes.

The NeoDesk 4 icon editor can also import all the Atari-specific icon formats developed by both Atari and third-party companies, can use Windows bitmap ("BMP") graphics for incorporation into icons, can read Atari resource ("RSC") files for use in icons, and, of course, lets you draw your own icons from scratch. Full cut-and-paste facilities within the icon editor make it easy to copy part of one icon to another.

An apparent limitation of NeoDesk 4 -- its inability to run the icon editor as a separate, coexisting task while other operations are taking place -- can easily be circumvented if you have enough RAM and are running NeoDesk 4 under Geneva. Simply run a second instance of NeoDesk 4 and use it to edit your icons. Switching from one running copy of NeoDesk 4 to the other will be less confusing if you set up the second one with a distinctive desktop pattern or you run the second NeoDesk 4 in a window. 


The desktop doesn't have to be the size of your screen
An unusual feature of NeoDesk 4 is its ability to run as a desk accessory. Yes, you heard that right; NeoDesk 4 can hide itself away in the Desk menu of your Atari, ready to pop open just like any other GEM desk accessory. A similarly unusual feature is NeoDesk 4's ability to contain itself in a resizeable GEM window whether run as an accessory or as a program.

When it is run as a desk accessory, NeoDesk 4 retains all the functionality of the standard NeoDesk 4 setup. It still acts as the shell (the central file-and-program controller) for all operations, and still provides desktop macro keys and other specialized features. What it gains when run this way -- as both a desk accessory and as a program in which the desktop-in-a-window feature is activated -- is a second identity. The "desktop" suddenly becomes something new, not simply the background space for all file and program activity but rather a redefinable area on top of the bedrock of the operating system, if you will pardon the metaphor. Resizing the NeoDesk 4 window so that it covers only a small portion of the screen quickly frees up the remaining space for anything else.

What could that "anything else" be? In a multitasking system or a system making effective use of desk accessories, it could be anything -- an image in its own GEM window (using Imagecopy or 1stView, to name just two programs that will do such a thing), the Gribnif World Clock, a scientific calculator, an address book, an archiver running in its own GEM window, a notepad, a telecommunications applet in a window ... or just an expanse of ordinary, featureless space. All of this can be done when NeoDesk 4 is running full-screen, of course, but without the panache; anyone used to the way the Windows and Mac desktops look cannot fail to be amused and amazed at a desktop that can collapse into its own window. There is even something Trekkie about it.

If you decide to run NeoDesk 4 in a window, whether as a desk accessory or a program, you will want to arrange its desktop icons and windows more carefully than you would normally. An ideal setup would display the most important icons and windows when the NeoDesk 4 window is normal size, with ancillary icons and windows coming out of hiding, so to speak, when the NeoDesk 4 window is made full-size. You can arrange the icons and windows for this effect without a lot of difficulty. Such a desktop looks like nothing else on any platform -- perfectly organized, adaptable and easy to use. 


Placing a pretty background on the desktop
The millions of Microsoft Windows users probably rank one feature of Windows near the top in the category of Neat Things Windows Can Do. (We'll skip the Unneat Things Windows Can Do!) It's the desktop background, which can be a pattern or a picture. Windows uses just one kind of graphic file for this background wallpaper, a "BMP" file. (The name stands for "bitmap," but of course lots of other graphics are bitmapped, too.)

If this is such a Neat Thing, how come Windows users can't do what NeoDesk 4 users can do? NeoDesk 4 can use any BMP file for a background picture, too, or any IMG file, or Degas graphic, or Tiny-format picture ... you get the point. Desktop pictures are a breeze for NeoDesk 4. It even dithers (creates patterns in) color graphics so they can be viewed passably in monochrome. If you have a Falcon or an ST or TT with a graphics card, you should be able to use any 16-color Windows BMP file easily, and may be able to use 256-color BMPs also.

If you have a favorite picture in a non-supported format such as GIF or JPEG, you can quickly convert GIF and JPG files (and many others) to a NeoDesk-usable format with either Imagecopy 3.5x or GEM-View 3.x. For display sizes larger than ST High Resolution (640X400), IMG files are better choices than BMPs when you are converting pictures because they are quite a bit smaller. 

Placing a picture of the desktop on the desktop 

One of the easiest screen tricks any NeoDesk user can pull is taking a snapshot of a typical desktop, using any of the many snapshot utilities available (Imagecopy is superb) and then selecting that snapshot as the background picture for NeoDesk. By altering THAT desktop, which of course includes the representation of the other desktop as the background, and then taking a snapshot of it, you can create another background that looks quite unusual. It could have, for example, 14 open windows showing (seven for each desktop) even when you have no windows open on the real desktop. As you can see, there is no limit to the number of times you can do this.

You could also take a snapshot of the original Atari desktop and use that as a NeoDesk background, if you find yourself longing for the bad old days. 


Take a drag 
Little needs to be said about the ability that NeoDesk 4 users have of placing icons on the desktop, since this is now a feature of the latest official Atari desktops also. You simply open up a drive or folder window and drag the icon from the window to the desktop. Close the window or move it out of the way, then arrange the desktop icon any way you want it.

But both NeoDesk users and those who use the new TOS/GEM desktops sometimes fail to realize that this facility extends to ANY icon -- not just to icons that represent applications. In other words, the desktop can display icons representing texts, batch files, telecommunications scripts, audio-sample files and hundreds of other file types. In NeoDesk, even desk accessories written to communicate with the NeoDesk kernel can be installed on the desktop. If you are an experienced user and know all about this already, you may wish to skip this section; the explanation I am about to give is quite basic, but I'm sure it will be useful to many NeoDesk users. 

Why not just hide those icons away where they belong? 

If you use the "Show as Icons" option under the "View" drop-down menu, every file in every root directory and folder on your floppy and hard disks will be shown as an icon. The reasoning behind the use of icons instead of file names is simple: Icons for different functions and for their various data files can be shaped or colored differently, so they can be readily identified. To use just one example, your word processor can be identified as an icon that shows a pen and a piece of paper, and the text files that it creates can be represented as icons that show pages placed in a neat stack.

The important point here is not that icons for applications such as word processors and telecomm programs should look pretty or be informative; that much is taken for granted. What I am pointing out is that data files should be clearly related to their applications by the careful assignment of icons -- using, to cite other examples, icons that show a musical staff for the data files for a sound-sampling application, icons representing a bookshelf full of books for the resource files for system applications, and so on.

That way, a quick glance will tell you what data files go with various applications. This is much more informative than a text listing of files, and it means you are less likely to waste time searching for the right files every time you use your computer.

But that's only the beginning. The next step takes advantage of the drag-and-drop capabilities of NeoDesk 4 (a facility shared by the latest TOS desktops, too). You can do this without the need for any prior setup in NeoDesk 4; in other words, you do not need to create any "installed applications" in the NeoDesk 4 information file to make use of drag-and-drop, since it is built into the operating system itself.

This means you can open a window onto a folder on a floppy or hard drive, click on a data file icon, drag it to an application icon and drop it there, and the application will run and load the data file. If you haven't tried this before, you can practice on any file that has been archived with ARC.TTP. (It will have an ".ARC" file extension.) Drag the icon for that file onto the icon for ARC.TTP and let it go; the ARC program will automatically run, load the archived file and extract its contents.

But why go to the trouble of opening a desktop window to do this? You can do the same thing from the desktop itself if you install these icons on the desktop. By dragging a data icon to an application icon and dropping it there, you accomplish three operations in one move. You run the application, load the data file into the application and instruct the application to perform a default function -- displaying a text file in the case of a word processor, perhaps, or extracting the contents of an archive in the example of ARC.TTP.

Stay with me, because even THIS is not the full story. You can take advantage of NeoDesk 4's installed-application function and its drag-and-drop operation to add flexibility to the way you use your computer, if you install both data and application icons on the desktop. I'll give you an example from my own NeoDesk 4 setup. In fact, it's the setup I'm using to write and edit this text file.

On my NeoDesk desktop, I have placed an icon for this text file and icons for three versions of STeno, the Gribnif text editor. Two of the STenos are desk accessories, and the other is a standard GEM program. The STeno icons are clustered near the text-file icon for NEOSECRT.TXT. Also nearby is an icon for READTEXT.TTP, a text analyzer written by Paul Lefebvre, and an icon for a spell-check program. Within NeoDesk's information file, I have installed 1STVIEW.PRG as the default text viewer. (I cannot praise 1stView enough, since it is able to show multiple texts in separate windows in one double-click, displays all the text attributes such as italic and boldface in 1stWord documents, plays audio samples and shows GEM image files as well. It doesn't make my coffee in the morning, but perhaps the CodeHeads or Damien Jones will come up with THAT utility.)

Double-clicking on the icon for NEOSECRT.TXT displays this article in a 1stView window. Dragging the same icon to one of the STeno icons loads the text into STeno and opens it up in a STeno window, ready to edit. Dragging the icon to the text-analyzer icon gives a quick accounting of the file's word count, sentence length and probable readability, and dragging the icon to the spell-checker icon loads it into the spelling program.

All this is done in a sort of intuitively sensible way. I could perform the same tasks, with the same range of choices, in many different ways -- through FlexMenu, the program linker and launcher from Trace Technologies, or by means of batch files written for a shell program, to give two examples. But the most logical way, once you are accustomed to the idea that icons represent not just files but actions, seems to be the route that NeoDesk 4 takes. 

You can't really click on a DA and get it to run, can you?

Desk accessories are special applications that are always running. They are loaded into the computer's memory when it boots up and remain there, ready to go to work. (Both Geneva and CodeHead's MultiDesk Deluxe provide ways to get around the need to have all desk accessories loaded at boot-up, and are highly recommended.) Desk accessories are accessed through the "Desk" menu at the upper left of the screen.

Desk accessories normally will not run (or drop down if they are already loaded) if you double-click on their icons. Without Geneva (which lets you load a desk accessory at any time), there are two ways to get around this. One is to install MultiDesk Deluxe in NeoDesk as an application that has the associated data type ".ACC"; if this is done, double-clicking on any desk accessory will cause MultiDesk to start up the the desk accessory just as if the DA were a standard program. This has immense advantages, but it has at least one major disadvantage: The DA takes all its bags and baggage with it when you exit the desk accessory, since it was not loaded at boot-up and therefore is not running in the background while you are doing something else. (This is in no way a criticism of MultiDesk Deluxe, which is behaving in an entirely proper fashion.)

It is just that sort of background operation that makes many desk accessories useful. Excellent examples are STeno, the Gribnif text editor, and STalker, its companion telecommunications software. Other examples are CodeHead's own Warp 9 Control Panel and its excellent file utility, MaxiFile. Because a desk accessory loaded at boot-up is always available at the desktop and in any properly written GEM program, it can hold data for you for quick recall -- a calculator DA is a good example -- or it can retain work-in-progress that you can return to at any time, as you can do with a text-editor DA such as STeno or the CodeHead Head_Ed editor. It can even perform an active operation such as a file transfer while you are running another application, in the example of STalker.

With this in mind, you can appreciate the usefulness of a desk accessory that can be treated like a standard application. If you place the icons for any NeoDesk-compliant desk accessories on the desktop, you can employ the drag-and-drop technique with them just as you would a regular program. In fact, you can do that with a significant advantage. Because a NeoDesk-compliant desk accessory is already loaded and running, dropping a data icon on its icon triggers a faster response in the drag-and-drop race. The difference in response time depends on a number of factors, such as whether you are working solely from floppy disks (in which case the NeoDesk DA would load the data file at least 10 times faster than an application running from a floppy) and whether you are using a fast hard disk with a large cache (in which case the speedup would be slight).

STeno and STalker are NeoDesk-compliant desk accessories, as are the DAs that Gribnif supplies with NeoDesk -- a control panel, a printer queue and a recoverable-trash DA. The NeoDesk command-line interpreter DA, sold separately, is also NeoDesk-compliant, and some desk accessories programmed by others, such as EditPlus, also meet this standard.

These special desk accessories have another advantage. They can be listed in NeoDesk's "Accessories" submenu within the "Set Preferences" menu, so that NeoDesk can assign special hotkeys that will call them. These hotkeys are Control-0 through Control-9 (Control-1 is actually first on the list, with Control-0 last). The DA hotkeys work only on the desktop, but they are quite handy.

And there is yet another distinction of these desk accessories. By placing icons for these DAs on the desktop, you are doing, in effect, what users of graphical interfaces for other computers are able to do -- you are iconizing a running program. In Windows, OS/2 and GeoWorks for the PC and such interfaces as Motif for Unix computers, a single click on a gadget of an open window will reduce the window to an icon. In NeoDesk, a single click on the close gadget (the oval button at the upper left) of a STeno, EdHak, BackTALK or STalker DA window (among others) will reduce it to an icon in the same way. If you work with NeoDesk-compliant desk accessories in this fashion, you are adding much of the power of the other graphical interfaces to your ST or TT, while avoiding all the overhead associated with these systems. 

Pick a name 

When you install icons on the desktop, the label below the icon is nothing more than the filename or the folder name attached to the icon by the operating system. It will always be in capital letters, and may not be as descriptive as you would like. You can change these labels to anything else. Click once on any icon and choose the "Install Desktop Icon" submenu under the "Options" drop-down menu; type in any descriptive label, using upper-and-lower-case letters, which look a lot classier than something written in capitals. You can even type in any of the symbols in the ST, TT and Falcon character set -- yes, even "Bob," the famous hidden face in the high-order alphabet! Do this for each icon, then save the desktop configuration. (The Control-X key combination will do this, if you'd like a shortcut.) 


Form and function
Both NeoDesk 4 and the official Atari desktops in TOS versions from 2.05 on up have programmable hotkeys. These keys operate only on the desktop. (In other words, while you can program them to run any application, you cannot program them to perform functions within an application. They are cleared out of memory whenever an application or desk accessory is active as the top window. Hotkeys you create on the desktop will not interfere with hotkeys or function keys that are built into any of your programs.

By "hotkeys" I am referring to both the set of separate keys at the top of the keyboard labeled "F1" through "F10" and the keys on the main keyboard. Both NeoDesk and the later TOS desktops allow you to assign any "Fkey" function key and any keyboard character key to certain actions, but in other ways the two desktops differ. NeoDesk 4's method uses an actual macro program, which records a series of desktop operations for later playback, while Atari's method merely links a single keystroke to a single operation. The NeoDesk method is much more powerful and far more flexible.

The TOS desktops have these limitations:
  1. They allow the assignment of only 20 Fkeys, from F1 to Shift-F10.
  2. They do not let you use Control- or Alt-key combinations with either the Fkey assignments or keyboard hotkeys.
  3. They do not recognize the Esc, Tab, Backspace, Delete, Help or Undo keys as assignable hotkeys.
  4. They will not perform any function associated with a file except to run an executable program.

NeoDesk 4 offers these advantages:
  1. You can choose from a total of 120 possible Fkey combinations alone. That is, any Fkey can use Control, Left Shift, Alternate, Right Shift, Control-Left Shift, Alternate-Left Shift, Left Shift-Right Shift (and so on) as modifier keys.
  2. Any keyboard keys can be used with any of the modifier keys, in any combination, for macros. Thus you could assign a particular action to Control-LShift-Alt-RShift-A, for example.
  3. Any key on the keyboard except the four modifier keys (Control, Alternate and the two shift keys) can be used as a macro hotkey. For example, the Undo key, which ordinarily has no function on the desktop, can be mapped as the "Close Window" key.
  4. Most importantly, a NeoDesk 4 macro can perform any function that can be done from the desktop. It can run an application, show a text, open a specific drive or folder window, move a window, load a NeoDesk information file, and do any of dozens of other functions. A NeoDesk macro can even load a different set of NeoDesk macros. Without question, NeoDesk's macro function is one of its salient strengths. 

How NeoDesk does it

NeoDesk does not record keystrokes and mouse movements when you create a macro. Instead, it keeps track of system activity. This is, at the same time, a much better way of recording macros than the typical method of mimicking keystrokes and mouse clicks, and a much worse way. It all depends on what you want a macro to do. If you want a macro to exactly reproduce every keystroke and every single- and double-click of your mouse, you should purchase the Geneva Macro utility from Gribnif or CodeKeys from CodeHead Software. However, if you only want your macros to reproduce the results of your keystrokes or mouse clicks, NeoDesk's macro function is ideal.

Perhaps an example will make this distinction clear. Suppose you have installed the icon for EDGE.PRG, the Diamond Edge hard-disk maintenance utility, on your desktop. You start the begin-macro function in NeoDesk, run Diamond Edge, and then exit. At that time you end the macro and assign a key combination to it.

Any time you want to run Diamond Edge, you can simply press that hotkey. Does that mean that NeoDesk is double-clicking on the EDGE.PRG icon for you? (This is what CodeKeys would do, if you were to create a macro to run Diamond Edge from the NeoDesk desktop with CodeKeys.) You can find out by removing the EDGE.PRG icon from your desktop and pressing the hotkey again; Diamond Edge runs as before. What NeoDesk recorded when it monitored your activity when creating the macro was that a file named EDGE.PRG in a specified folder and path was being opened and, therefore, run.

This difference between the way NeoDesk records and runs macros and the way an external program such as the Geneva Macro utility or CodeKeys runs them is crucial. Because NeoDesk monitors all its system activity, its macros can do anything that you can do at the keyboard or with the mouse. We'll have a few dramatic examples of this below. 

Make me a macro. (ZAP! You're a macro.)

NeoDesk macros are easy to create and even easier to use. You can drop the "Options" menu down and click on "Begin Macro," or press Control-Esc. From that point on, your desktop operations will be recorded until you end the macro with a menu click or a second Control-Esc. NeoDesk 4 then asks you to assign a "Keyboard Shortcut" -- a hotkey -- to the macro. You can click on the "Read Key" box and press any key on the keyboard, and then decide whether you want to add any of the modifier keys to the hotkey by clicking on one or more of the four modifier-key buttons. (Any combination is possible.)

Then click on one of the three radio buttons at the bottom (Install, Remove, Cancel). "Install" saves the macro in the NeoDesk 4 configuration stored in your computer's memory. The macro will run, but it will not be saved permanently unless you choose "Save Configuration" under the "Options" drop-down menu. "Remove" erases the macro from memory. "Cancel" does not operate the way you might expect: Rather than canceling the macro, it cancels your decision to end the macro. Think of it as the "Cancel-macro-end" button and you'll understand it better. If you are creating a macro and decide to cancel it, you must click on "Remove" and not "Cancel." 

Macros that do more than run programs 

NeoDesk macros are great for running your favorite applications with one keystroke. But if that is all you do with NeoDesk macros, you are missing out on a lot of NeoDesk's flexibility.

Macros can chain programs together; that is, a single NeoDesk macro can run a series of programs, with each succeeding application running when the previous one stops. (Just keep the macro recorder on while you do this yourself from the desktop.)

Macros can show text files. Big deal, right? It IS a big deal if one of your text files happens to be a list of macro-key assignments -- in other words, a Help file. After you have set up your macros, open up your word processor or text editor and write a neat, single-page list of macros and their functions. Entries could look something like this:

Diamond Edge............F2    Close all windows....RS-Undo 
ST Fax..................F3    Close window............Undo
ST Writer...............F4    Close folder..........A-Undo
Flash II................F5    Select all items......Insert
Good HD backup..........F6    Send formfeed............C-F
GEnieLamp............LS-F3    Reload configuration.....A-R
Spell check...........A-F4    Load macro set #2.......LS-2

In this list, "LS" stands for "Left Shift" and "RS" stands for "Right Shift." "A" means "Alternate" and "C" means "Control."

If you decide to create a macro that lists macro-key assignments, I suggest you follow the convention of using F1 to display the Help file. Then make use of the NeoDesk Desktop Notes function by writing a short desktop note that says the following:

Press F1 for Help

This keeps most of the Desktop Notes capacity free for other memos. 

Special macros, or how to make them call themselves 

One of the mysteries of NeoDesk, to many users, seems to be one of the menu items under the "Options" drop-down menu. It's always grayed out, and that means you can't do anything with it. So why is it there?

In truth, this menu item -- "Load Configuration" -- is not always grayed out, but there is something you need to do to before you can use it. It switches from gray (the universal indication in most user interfaces that a menu item is turned off) to normal as soon as you click on any NeoDesk configuration file. In other words, if a NeoDesk configuration file ending in the extensions ".INF," ".MAC" or ".NOT" is selected, the "Load Configuration" function is enabled. This allows you to load another configuration into NeoDesk -- another complete NeoDesk information file, another set of macros or another collection of desktop notes.

NeoDesk's pre-assigned hotkey for that function is Control-L. So, by clicking once on an alternate NeoDesk information file and pressing Control-L, NeoDesk will immediately take on a new configuration.

But that's too much trouble, especially since a macro can do it all. Do the same thing while recording a macro, and then save the macro under a key combination that makes intuitive sense -- Alt-I for the main alternative information file, for example, and Alt-Shift-I for a lesser-used one.

Do the same for macro keys. Somehow, there's a sense of minor triumph in getting a macro program to load and unload its own keys. First, of course, you'll need to create separate sets of keyboard macros, saving them under different names (but all with ".MAC" extensions). Then click on each of the macro-key sets one at a time, creating new macros among the primary macro keys that load each of the other macro-key files. But be careful to include one macro in each set of macros that reloads the main set.

If this is confusing, let me try a simple explanation. Here is a set of three macro keys, which in this small example could be the primary NeoDesk macros:

F1 Show Help file 
F2 Run Aladdin 
F3 Load macro set 2

Here is macro set 2:

F1 Run Calligrapher 
F2 Run spell checker 
F3 Load macro set 1

That's how easy it is. Keep your layout simple at first; if you're not careful, your macros-calling-macros operation can become too convoluted to follow. This, in itself, is a good reason to maintain a Help file that can be viewed with a single keystroke. (Ideally, of course, each set of macro keys should share many common macros -- keystrokes for closing windows, for selecting all files in a window, and so on, and especially for viewing the Help file. But I cannot emphasize enough the need for a macro in each set of macros that returns you to the master macro assignments. If you leave that out, you will have to manually load the original macros back in.) 


PATH=, and all that garbage 
NeoDesk 4 is unusual in offering complete control over the Atari system environment. By "environment" I am referring to an area of memory that the operating system uses as a sort of information pool that all applications can make use of. The concept of a system environment may be familiar to MS-DOS users, who often need to set the DOS environment through such statements in their bootup files as "PATH=;C:\;C:\DOS" and so on. The ability to set environmental variables was built into the Atari operating system from the start, although few users know about it.

The system environment can contain pointers to locations in your file storage where certain support files can be found, and it can tell an application where to create temporary files. It can do a lot of other things too, if the applications that are running support it.

That's the problem. Most applications do not make use of the environment in any creative way, and so the system environment is one of those aspects of NeoDesk that you could safely ignore most of the time. But if you take advantage of it, you may find it surprisingly useful when running some applications.

The most common use is to set a temporary-path variable, available to any application that checks the environment. Archivers that are properly written usually look for a TEMP statement to find the designated location of a temporary storage area to hold scratch files that are deleted after the archive is finished. To enter a variable for a temporary storage area, create a folder on a partition of your hard drive (or on a large-capacity floppy disk) that has 1 megabyte or more of free space. Name the folder TEMP. In the "Edit Environment" menu under the "Options" drop-down menu, type "TEMP=C:\TEMP\" (or whatever the pathname is) in one of the environmental-variable slots, and then save the configuration file. In my own setup, I have a second temporary-path variable named "TMP=C:\TEMP\" because some applications look for a "TMP" variable instead of one named "TEMP."

Another function of the system environment is setting a general PATH variable. This is used by all GEM applications to locate their resource files, and is entered as "PATH=C:\PATHNAME\". If you make use of this variable, you can place all the ".RSC" files of every GEM application in your collection into a single folder (or into a group of folders, if you have more than 100 or so), and of course you can then remove all the ".RSC" files from their scattered locations among dozens or even hundreds of folders. This GEM pipeline for resource files should work properly for all applications that follow standard programming guidelines; I have seen only a few programs that could not find their ".RSC" files this way. If an application complains through an alert box that it cannot find its ".RSC" file, you can move that particular file back into the same folder that the application runs from.

Desk accessories present a difficulty for this method, however. Because DAs run before NeoDesk takes control of the system environment, they will not find their resource files and therefore will refuse to load. STeno and STalker are two common desk accessories that must locate their resource files before NeoDesk loads. (This problem is not solved by installing NeoDesk as an auto-running application under the TOS desktop.)

You can get around this in three ways. The most effective is to purchase Geneva, which provides complete environmental control in addition to its multitasking abilities. The second is to place the resource files for desk accessories in the root directory of your boot drive (or in the folder the accessories are loaded from, if you use ACC.PRG or MultiDesk). The third is to avoid using NeoDesk's environment manager and use Ian Lepore's GEMENV.PRG instead. GEMENV.PRG runs from the AUTO folder, is easily configured, and has the advantage of working with the TOS desktop as well as the NeoDesk desktop. 


TOS out your old receptacle 
NeoDesk comes with a recoverable trash can, which can be used as a NeoDesk-compliant desk accessory or as a stand-alone application. In either method of operation, dragging an icon of a file or a filename to the special NeoDesk recoverable-trash-can icon removes the file from view and makes it appear to be deleted. At regular intervals, you click on the trash can and select the files you want NeoDesk to dump. At that time they are erased. Until you empty the trash, you are able to open the trash can and take out any files you have decided to keep.

This is an excellent idea, and is the way some other operating systems work. (The Apple Macintosh's trash can also saves files that are deleted, but it does not save them indefinitely the way NeoDesk will do if you fail to empty the trash; this is both good and bad, depending on how much disk space you have available and how much you value your files.)

However, there are a few cautions that you should be aware of.

First, the way NeoDesk 4's recoverable trash can stores its pending-delete files and folders is non-standard. (If there WERE a standard, it would be non-standard, if you know what I mean.) This means that any application that searches through root directories and folders for all available files and then reorganizes them to improve disk performance will scramble everything being saved in the recoverable trash can. To make this as clear as possible, if you use Diamond Edge, Cleanup ST or any other hard-disk defragmenter, you must first empty the NeoDesk trash can.

Second, the sole purpose of tossing anything away is to get rid of it. This may seem too obvious for a comment, but if you use a recoverable trash can as a regular way of putting files and folders into suspended animation, you probably are ignoring some basic housekeeping duties. (And you may have a few closets that the local fire-inspection brigade would like to look at, too!) Old files that are not needed just get in the way.

Third, you may wish to consider an even better recoverable trash can if you are worried about the danger of using a disk utility when files and folders marked for deletion are in the NeoDesk trash can. This better method is simple: Create a folder named TRASH on your hard disk and assign a trash-can icon to it (call it "Trash folder" when you place it on the desktop). If you have files that you want to delete but are unsure if you may need to refer to them in the next week or so, drag them onto this icon the same way you would drag them into the trash. Every now and then, open this folder and drag all the files you know you don't need into the real trash can.

This method has no drawbacks, except of course for the progressive loss of disk space if you forget to empty the trash folder. Hard-disk defraggers will cause no harm, since everything in the trash folder is still alive and well -- and, of course, visible to the rest of the operating system. A minor inconvenience of this method is that restoring files to their former folders is not automatic, as it is with the NeoDesk trash can; you have to remember where they came from and put them back manually. But it's a lot safer. 


A,B,D,C and so on 
NeoDesk can show the contents of a root directory or folder in five different orders, sorting by name, date, size, type, and, in effect, none of the above. It is this last sort option that matters most, because it shows you the actual physical order of each file and folder in the disk directory. This is important because the Atari operating system loads and runs programs in the AUTO folder in the order that they are found in the directory. It also loads desk accessories in the order they are found in the boot disk's root directory. It does not use alphabetical order, as many users assume.

Among the mysteries of the way directory entries are ordered is a genuine oddity. Normally, directory entries are written anew each time a file is created in the folder or moved into it, with the latest additions taking up a directory slot at the end of the list. But this does not hold true if a file is deleted and another file is copied into the folder; the operating system sometimes will place the latest file's directory entry into the slot just vacated, and sometimes will put the new entry at the end.

The only way to know for sure what order the files are in is to view the list with the "No Sort" option turned on, under the "Sort" drop-down menu. This would hold only academic interest except for the "Reorder Items" option in the "Sort" menu, which lets you arrange the contents of a folder or a root directory in any way you like. When you click on "Reorder Items" a second time, NeoDesk rewrites the directory listing to match the exact order of files in the top desktop window.

Reordering files in the AUTO folder is a common activity among Atari users, and NeoDesk makes it easy. But NeoDesk 4 can also be used to reorder the desk accessories in the root directory of the boot disk, too, because of a second quirk in the way the ST, TT and Falcon operate. Desk accessories are not necessarily loaded in the order in which they appear in the "Desk" menu, even though the order that they load can be very important. MultiDesk Deluxe, for example, should always be loaded last. To make sure it loads last, place it at the bottom of the list of desk accessories using the "Reorder items" facility.

Finally, reordering a root directory or folder in any location has a further benefit. When NeoDesk 4 rewrites the directory, all the slots still occupied by deleted files and folders are cleared out. This makes directory searches appreciably faster; the difference in a directory with hundreds of files in it (and perhaps just as many deleted file entries) can be measured as a speedup of five times or even more.

However, keep in mind that this kind of directory cleanup eliminates most chances of restoring files that have been deleted. The rough-and-ready method of file restoration used by many utilities depends on the presence of a valid directory entry for every file that has been deleted -- which NeoDesk 4's reorder function eliminates. 


What, no icons?
Among your alternative NeoDesk configurations can be one that presents a blank desktop or one that shows nothing but a desktop background picture. The only item visible on such a desktop is the main GEM menu bar. This is a neat little trick, one that you will not see on many computers under Windows, OS/2 or the Macintosh Finder -- nor, of course, on other Ataris.

Every experienced Atari user knows the apparent drawback of a desktop with absolutely no icons. Because no device icons are installed, there is no way to access any files.

Actually, this is not the case. The only thing you can't do is click on a drive icon. You CAN drop down the "Options" menu and load another configuration, however, and you can run any macro.

So the way to do this is to create an alternative desktop that has no icons on it. Delete all of them by selecting them in a group, pressing Control-D and then clicking on the "Remove" box, and then saving that desktop under a unique name. I suggest NEOBLNK3.INF for an ST high-resolution desktop, for example. (The "3" indicates ST hi-res, following official Atari practice for GDOS device names.) Then record a macro that loads that desktop information file. Make sure you have another macro that restores your standard desktop. 

Where's my trash can?

Another nifty trick is to take the trash can out of the desktop for those times when inexperienced users are going to work or play at your Atari. NeoDesk 4 still provides a way of deleting files without dragging them to the trash can (through a keyboard combination and by dragging files to the trash can icon within each window), but your data will be safer if your desktop trash can is stowed away. Again, make sure you have a macro that will reload the standard desktop. 

Just a couple of choices

Another trick is to create an alternative desktop that has only a few icons in it, perhaps just the icons for a basic word processor, a spelling checker and a telecommunications program. New users who become confused by too many choices will find such a desktop very friendly. 

It's up to you

Perhaps the best neat trick of all is to use your imagination to set up your NeoDesk 4 desktop in a way that suits you best. You're the judge of what you want; do it your way, and by all means make it fun.

(This document is part of the "Secrets of ..." series of guides to Atari computing. Others in the series are available from GEnie and some other online services.) 

Secrets of Geneva - by Al Fasoldt

posted Jul 16, 2019, 2:29 AM by Joshua Kaijankoski


Tips, tricks and things that should be obvious but may not be in getting the most of of Gribnif's amazing Geneva, the multitasking environment for Atari ST, TT and Falcon computers.

by Al Fasoldt

Technology Writer, Syracuse Newspapers and Newhouse News Service
Systems Editor, the Herald-Journal, the Herald American and the Post-Standard
Syracuse, New York 
Copyright (C) 1994 by Al Fasoldt. All rights reserved.
Version date: January 24, 1994. 

This can be reproduced in electronic form without permission of the author only if the entire document remains intact. Printed reproduction requires a prior arrangement. No commercial use of this document, for any purpose, is allowed. 

Geneva, the multitasking operating environment from Gribnif Software, is perhaps the most powerful application that can be run on an Atari ST, TT or Falcon. This is impressive enough, but what is even more unusual is the ease with which Geneva integrates itself into the way Ataris have always operated. You need not learn anything new to make use of Geneva, and you don't have to get rid of any old habits.

But Geneva's power runs as deep as it runs wide. Many of the features of Geneva are not obvious, and some are even obscure. The documentation that Gribnif supplies with Geneva abounds with explanations and examples, which, as most of us who write documentation know, most users will never read. They want to get their hands on the program right away, intending to look at the documentation later. And, of course, "later" never comes.

Perhaps companies such as Gribnif should offer enticements for customers to read and study documentation. Maybe each page should have a hidden code that holds the key to a discount or a cash reward, offering a prize on every page. Or maybe computer users, all of us, should try a little harder to learn how to read.
This essay is an attempt to encourage that. It is not a replacement for or supplement to the Geneva manual. Much of the information here will not make sense unless you are able to consult the manual, which you should do whenever something is not clear.

I must also add that this essay is not in any way intended to help those who have acquired Geneva illegally. If your copy of Geneva came without a manual, you do not have a legal copy, and you do not have a right to keep it. Fortunately, there is an easy way to get the manual, and a second copy of the software, without pain and trauma: Pick up the phone, call Gribnif, and order a copy. Then toss out the copy that you stole. Your mother will love you for it, and Gribnif will respect you. With love and respect and Geneva to boot, who could ask for more? 


Items 1 to 4 

Here's what Geneva is not: 

  • A new desktop for your computer.
    Geneva does not replace the desktop (also called the shell or the desktop shell). This means when you boot up Geneva, you don't have icons and windows and a trash can and things like that, unless you specifically run a separate desktop shell. 
  • MultiTOS.
    MultiTOS is made by Atari; Geneva is made by Gribnif. They are similar in a couple of ways, because they both support multitasking and they both take advantage of new code in many programs. This new code provides fancier displays and better menus, among other things. But that's where the connection ends. A very big difference is that Gribnif supports Geneva actively; Atari has all but abandoned customer support for its computers and computer software. 

  • A memory hog.
    With its support files, Geneva takes up about 5 percent of the memory of a 4-megabyte Atari computer. This is less RAM than the memory taken up by a typical word processor. To make the point more dramatically, if the code in Geneva were written into a displayable graphic form such as you'd find in a GIF picture, it would do little more than fill a single screen of a TT.
  • Molasses.
    Molasses is stuff you make great cookies with. Geneva is stuff you make great computing with. Many computer users assume that a system that can do many different things at once must therefore be much slower than a system that can only do one thing at a time. This is both true and false. Geneva has almost no overhead, so that all the basic operations occur at very nearly the same speed as before. (This is oversimplifying the situation, since what little overhead Geneva does have is often compensated for by its more efficient code.) On the other hand, if you run nine programs at once, you can be sure that each of them will run a lot more slowly than if you ran only one at a time. Geneva can't overturn the laws of physics. 

Items 5 and 6 

What Geneva cannot do: 

  • Turn soot into Shinola.
    (I know the saying is usually written another way, but kids and normal people might be reading this, too.) Geneva cannot turn a poorly written Atari program into a well written one. It will attempt to make that program behave, but it can't create a resizeable GEM window in a program that uses a fake-GEM, single-sized window, for example, nor can it force renegade TOS programs that assume nothing else is running from drawing detritus all over the screen. There are MANY poorly written programs for the Atari; fortunately, most of them aren't worth running even on a single-tasking system, and at least some of the rest are being replaced or updated. 
  • Magically impose order on the chaos of printing.
    When an application for the Atari prints a document, it usually grabs every available ounce of the processor's weight and muscle and refuses to let it go until the document is printed. To put it kindly, this is stupid and unnecessary. But it's so, and Geneva cannot change the way such applications behave. To work properly in a cooperative environment, a program has to be, first of all, cooperative, and nearly all word processors and many other printing applications are completely uncooperative when it comes to sharing the computer with anything else while they send their little bits and bytes to the printer. There's a way to alleviate this; it's called a print spooler. But there is no way for Geneva to get Atari Works, for example, to print in the background. No way. 

Items 7 to 10 

What Geneva does not require: 

  • A 68030 Atari.
    That number is the model type of the central processing unit -- the CPU chip -- in what is called (and pronounced as) the "Sixty-eight thousand" chip family. The first chip in this family, the oldest brother, so to speak, is the 68000; it's used in the ST, Mega, STacy, STe and Mega STe. The middle brother, the 68020, was never used officially by Atari, but a younger sibling called the 68030 shines in the TT and Falcon. (And that's why they're actually named the "TT030" and "Falcon030.") The 68030 handles memory a whole lot better than the 68000 and does other things better, but Geneva does not depend on a 68030 chip to do its stuff. Sure, Geneva works faster with the newer chip, and some operations are just plain done better, but that's it. 

  • A humongous hard drive.
    C'mon, Ataris don't run stuff like Microsoft Word for Windows, which takes up 20 megabytes of hard-drive space just for its own software. A dinky 20-megabyte hard drive can do just fine for many Geneva users. A bigger hard drive is fine, but not for Geneva's sake. 

  • A hard drive at all.
    Yes, many loyal Atarians never felt the need to add a hard drive to their systems, and Geneva won't force them to. A second floppy drive isn't even needed, although life at the keyboard is made a lot easier with two floppy disks always available instead of one. Even an Atari user with only one single-sided floppy drive can load and run Geneva; it fits easily on a single-sided disk (although that disk would have to remain in the drive if you want to access Geneva's own Help guide). 

  • NeoDesk.
    Is this heresy or what? Here's the author of the world's best-selling guide to NeoDesk (OK, I lied a little; it's free) telling you NeoDesk isn't needed to run Geneva? But that's absolutely true. There is no connection between Geneva and NeoDesk other than the fact that they both come from Gribnif. Period. End of story. Except that, like most tall tales, this one refuses to die. NeoDesk works great as the desktop on a system that is running Geneva, and in fact there's a giant, too-big-to-ignore advantage if you use NeoDesk (which we'll get to later). But Geneva does all its stuff on its own, without requiring NeoDesk. Full stop. End of paragraph. 


  1. Add memory to your computer.
    One of the most common complaints heard 'round the Atari community these days is, "Wha' happened to my memory?" Folks aren't complaining about losing their minds; they're talking about RAM. Since we already know that Geneva only occupies a smidgen or two of RAM (if you give me some allowance for smidgen sizes in these days of large applications), what could be happening to the rest of the computer's memory?

    The answer lies in the expectation factor. Once you realize that you don't need to quit one application before launching another one, the natural temptation is to keep both of them (or all three or four of them -- you know what I mean) in memory at the same time. Whoops! There goes that megabyte of RAM you used to have left over all the time.

    Geneva also lets you load up on desk accessories like a kid pumping himself another six SoftServes at the Ponderosa dessert bar. There's no limit to how many desk accessories you can have running at once, so why not just load a dozen or more and have fun? Nice idea, except for that slam-bam RAM cram, thank you, ma'am.

    There's a way to enjoy those desk accessories and still keep them from hogging memory, and I'll show you how a little later. As for stuffing RAM with simultaneous word processors, telecomm programs and other goodies, the best solution is in the chips. If your Atari has less than 4 megabytes of RAM, upgrade it now. It won't cost much.

  2. Add an accelerator.
    Three long-term champions of the Atari cause have been selling processor-chip accelerators for Ataris in North America for many years, and others have done it in Europe. Some of them are becoming hard to get, so this is the best time to shop for one. If your ST runs at 8 MHz (the standard speed of the original ST), it's time to consider having a 16-MHz accelerator put in. You can also get faster CPU chips, at higher prices. (A basic 16-MHz accelerator chip should sell for about $100, if you can still find one.)

    Everything that matters works faster on an accelerated Atari compared to a standard one. 

  3. Trade up to a faster machine.
    Sure, I know the facts; Atari's not making STs any more, so how are you going to upgrade to a faster ST -- to a Mega STe, for example? The used market is a vital source. Join either of the two most active online services for Atarians, GEnie or CompuServe, and check the electronic want ads. If you don't see what you want, post a message telling what you are looking for.

    (Modems are really cheap, by the way, so you have no excuse here. A new 2400-bit-per-second modem sells for $40 by mail-order, and used ones are a lot less. GEnie has a wonderfully easy automatic connection thingamabob called Aladdin, so start with GEnie if you want everything easy.) 

  4. Buy a Falcon.
    Falcons are the butt-ends of a lot of jokes in Ataridom, for no good reason. (Well, maybe for a lot of semi-good reasons, I'll grant you that.) Falcons run most of the standard Atari software, they're fast in many ways, they have gorgeous color displays, they're self-contained, they've got great audio capabilities and they can handle a lot of extra memory. Sure, a TT is faster, has a better keyboard and can drive a melt-your-eyes-out big-screen display, but TTs are no longer available new. (Atari says more TTs are coming, but no one believes this.)

  5. Upgrade your monitor.
    If all you have is a standard Atari color display, you're missing the picture. Under Geneva, you need all the real estate on the screen that you can get. (For one thing, having an out-of-the-way place to stick Geneva's floating Task Manager would be a great idea.) Atari's monochrome monitor is super-sharp and offers resolution almost as fine as VGA, the standard in the Rest of the World. Its picture is also clearer than most fancy-dan color monitors.
    So what are you waiting for? Atari dealers (yes, Virginia, there is an Atari dealer in some locales) still sell new monochrome monitors, and used ones are readily available, too. 

  6. Get a graphics card.
    Psst! Wanna know why Mega STe computers are so great? They've got VME! No, that's not some new kind of communicable disease; it's an adaptor-card slot at the back of the computer. It's normally covered, but if you take it off you'll see that there's an open slot there waiting to take the card of your choice.

    Graphics cards fit right in, and you just plug a Super VGA monitor into the connector on the outside panel of the card. Super VGA monitors are amazingly cheap these days, mostly because the crazy people who buy MS-DOS computers have been buying zillions of them, and they use S-VGA monitors. A graphics card will let your Mega STe show hundreds or even thousands of colors, and, better yet, it will let you use a display that has three or even four times the resolution of a standard Atari screen.

    Graphics cards aren't cheap, but they are bigger-than-big improvements to any Mega STe.

    If you don't have a Mega STe but have a Mega ST, you still may be able to find a graphics card for the Mega. Used cards are available now and then, and some dealers may even be able to get a new one.

    (If you have a TT, you have a VME slot, too. In fact, the TT and the Mega STe are like Boobsie and Bobsie in Las Vegas: twins when it comes to slots. Adding a graphics card to a TT is a great idea -- but if you're a TT owner, you probably already knew that.) 

  7. Add a faster and larger hard drive.
    Didn't I just say a while back that you can run Geneva with a tiny hard drive or even no hard drive at all? Sure. It's not Geneva that eats up storage space, it's the other applications you'll find yourself using. Look at it this way: Geneva adds a functionality to the Atari that has been missing for years, letting you continue to work on one program while you start another, and encouraging you to try out new applications without the need to quit what you are doing just to run something else. When you become accustomed to this kind of freedom, this sort of power, you tend to DO more with your computer ... and that means you could end up looking for extra floppy disks to store programs and data on when your hard disk fills up. Life is simpler, smoother and more enjoyable when your hard disk doesn't fill up, so consider buying a bigger one. 

  8. Get a better word processor.
    C'mon, the best Atari word processors are a LOT better than you might think, unless you've already tried the latest versions of the three or four top programs -- and they shine like never before under Geneva. Multitasking is only part of the improvement. How about menus that you can tear off and place off to the side of a document window? Geneva handles that for you (and for your word processor). How about 3D buttons in a button bar across the top of the screen? Geneva supplies those, too, if the word processor's own code has them available. How about faster-acting scroll bars and smoother mouse action? Geneva does that, too, by means of its superior code. 

  9. Buy a multitasking telecommunications program.
    Take it from an old hand at telecomm operations: The absolute DUMBEST thing you can waste your time on is watching your computer screen while your telecomm program does an upload or a download. Geneva makes background telecommunications a simple matter. You do, however, have to make sure your software can work in the background. Some of the best telecomm applications haven't yet been upgraded to full multitasking capability, but the list has doubled in recent months, and it should keep on growing. 

  10. Get real. Get a fax for your computer.
    It's not my intent here to suggest brand-name software in general (there are many great programs available for your Atari, and I'd be overlooking some excellent choices if I took sides), but in one area I must make an exception. An almost essential application for a serious Atari user is STraight FAX!, the send-and-receive fax program. It works exceptionally well under Geneva, too, disappearing into the background while waiting for a fax to come in or while pausing between scheduled fax transmissions. 


  1. You don't need a mouse to use menus.
    Do yourself a favor. Find someone who knows how to use Microsoft Windows (it can't be THAT hard to find a Windows user, even for Atarians) and ask that person to run it for a while without using the mouse. (A tip: If the Windows user says something on the order of "Huh? Of course you need a mouse," find another Windows user, and pray for the day that the Gatesian Rays that come out of PCs will be better shielded.) In just two or three minutes, you should be able to see how easily anyone can navigate through Windows just by using keyboard equivalents.

    Guess what? Your favorite Atari operating environment does the same thing. I am NOT referring to the little dialog-box enhancements that show up under certain characters on the screen; Geneva does that, too, but that's not what I am talking about. I'm telling you that Geneva turns any properly written GEM menu bar into a menu that works solely off the keyboard.

    But it doesn't do it by default. Unlike Windows, which is always ready to trip up your two-fingered typing style if you accidentally hit a menu hotkey, Geneva leaves it all up to you. If you do nothing to change things, you get a mouse menu; if you press a single key combination, you get a hotkey menu.

    That key combination is Alt-Spacebar. If you've tried it, you know that as soon as you press Alt-Spacebar the Desk menu drops down. You probably thought that was a Neat Thing -- and you may have thought that was all it did.

    No way. That Desk menu is just the start of something grand. Do it again, but this time look closely at all the other menu items. Each one will have an underline, usually below the first or second letter of the menu item. You can cause any of those menu items to drop their menus down by holding down the Alt key and pressing the underlined key. If you just want to browse through all the available menus, use the arrow keys; each time you press the right arrow key once, for example, the next menu will drop down.

    We're not through. Once a menu has dropped down, you'll see that its own menu items also have underlines. They work the same way. You just hold down the Alt key and press the letter (or number) that is underlined in the menu.

    It should be obvious that this has a couple of advantages. Anyone who is distracted by having to reach for the mouse while writing on a word processor, for example, should find Geneva's hotkey mode a joy to use -- especially if the application itself does not have keyboard equivalents for all its menu items. But a hidden advantage only shows up for those who use a macro utility (a program that performs keypresses and mouse clicks). A utility such as this cannot handle mouse movements as well as it deals with keypresses, for a number of reasons. (Mouse movements in a macro recording usually won't play back properly if you are not running the same resolution, for example.) Since Geneva is able to substitute keyboard hotkeys for mouse actions, you'll be able to create all sorts of powerful macros that duplicate anything you can do to a set of menus with the mouse. (I'll have more to say on macros later.) 

  2. You have a batch-file language right at your fingertips.
    It's been said that there are only two kinds of computer users -- those who know about and use batch files, and those who haven't got a clue. Batch files are lines of commands that are executed, one after the other, and they're widely used in the MS-DOS world. (But even MS-DOS PC owners often have no idea what a batch file does or how to use one, as I am often reminded by the questions readers send in to be answered in my newspaper columns.)

    So why am I mentioning this in an article about Geneva? Look again, friend; Geneva uses a batch file just like MS-DOS does every time it starts up. It's called GEM.CNF. You may have thought of GEM.CNF as some sort of scene-setter for Geneva, a list of little things it should know when it starts up, and in a way you'd be right. GEM.CNF does supply vital information to Geneva, such as the location of desk accessories, the filename extensions of executable programs and the name of the desktop shell, to list only three items.

    But GEM.CNF's power goes far beyond that, because it's not merely a list; it's a batch file that Geneva executes, line by line, whenever it comes to a "run" command. (The "run" command actually comes in two flavors, "run" and "runsleep," but both do the same thing -- run a program.) You can use the "run" command in a more-or-less standard way, telling Geneva to execute Program A first, then Program B, then Program C. If Programs A, B and C are multitasking applications, they will all be running at the same time when Geneva is finished booting up.

    Big deal. You could do the same thing under later TOS versions by sticking those programs into the AUTO folder, right?

    But suppose each of those programs was a single-tasking application (with flags in Geneva's Task Manager set to single-tasking)? What happens then? Geneva allows only one single-tasking application to be active at any time (which is, of course, the definition of single-tasking, after all), so something amazing takes place: Geneva runs Program A, then halts execution of the rest of the GEM.CNF commands. As long as Program A, a single-tasking application, is running, Geneva will not execute any other programs listed in "run" commands in GEM.CNF.

    This means that you can work with Program A for as long as you want. Then, when you finally exit Program A, Geneva immediately runs Program B. Geneva then suspends execution of GEM.CNF's "run" commands again, waiting for you to finish with Program B. When you have finally exited from Program B, it launches Program C.

    Anyone who has written complicated batch files for MS-DOS will know right away that Geneva's simple batch facility lacks a couple of important features. One that would add greatly to Geneva's power is a "goto" function, which would be paired with a labeling method. Lines with "run" commands would be prefaced with labels, and a "goto" at some point in GEM.CNF would force Geneva to jump directly to a "run" command that is located somewhere else in the file. (This facility would require some sort of if-then-else decision making ability, also.)

    But you can achieve the same effect by stacking "run" commands in GEM.CNF. All you need to do is list the single-tasking programs in separate "run" lines, in the order you want them executed, listing the same program more than once if necessary. In other words, if you always want your Atari to boot up with Aladdin (the software that handles calls to GEnie), and then always want it to run Flash so you can call a BBS, and then always want it to rerun Aladdin so you can send off your replies, just list those programs in A, B, C order in "run" commands in GEM.CNF.

    Keep in mind that this method is not limited to a series of single-tasking programs. Multitasking programs that are inserted in "run" statements will be launched all at once, and then will be put to sleep when Geneva encounters a single-tasking program in a "run" statement. You'll find that this works well except for the danger of fragmenting memory; you're usually better off if you run the single-tasking programs first. 

  3. You don't need to keep desk accessories active.
    Some of the best and worst features of the Atari ST, TT and Falcon computers center on desk accessories. They contribute an immense power to the Atari because they are always available whenever you are running a GEM-based application, or when you are using the desktop. They are also multitasking, able to do something in the background while your main program is doing something else. (Few desk accessories take much advantage of this feature, however.)

    But they have some conspicuous drawbacks. Under the standard TOS system, once a desk accessory is loaded and running, it can't be unloaded, and this means it takes up memory no matter what. Also, if you boot up without a certain desk accessory and then discover you need it, you have to reboot to get it to load (or else you have to use a desk-accessory manager such as MultiDesk Deluxe). And, of course, the TOS system limits the number of desk accessories that can be open at one time; only six are allowed, even if one of them is MultiDesk. MultiDesk appears as a single desk accessory to the operating system, but allows you to launch any other desk accessory one at a time from within MultiDesk. This is ideal in many situations, but the point to remember is that only one desk accessory within MultiDesk can be opened at a time.

    Under Geneva, desk accessories behave much differently. Most Geneva users know this well, and make good use of Geneva's removal of the desk-accessory limit. But too much of a good thing can be just as harmful as too little, especially when it comes to memory limitations. Running 12 desk accessories instead of six can knock a big chunk of available RAM out of your system in one quick bootup. What I am about to suggest is a way to use any accessory without the RAM penalty.

    The answer, in many cases, is to treat desk accessories as transient programs. This is not a foolproof approach, and it requires a bit of care. But it could be ideal for those who don't ordinarily have enough memory in their Ataris to run a full complement of desk accessories while running their regular programs. You do this by booting up with only the desk accessories you know you will need during the entire computing session. Candidates for desk accessories in this category might include corner clocks, a networking accessory, a text editor and so on. Then, when you need to use an accessory that is not loaded, run it from the Geneva Manager menu, from the Task Manager's menu or from a multitasking shell. When you are finished with that accessory, delete it from memory.

    This has a big drawback if it is not done properly. When you load a desk accessory while any other program is running, that accessory takes up the first position in RAM that is large enough to contain it. Usually, if the desk accessory is loaded early in a session, that spot in RAM is merely the top of the heap, so to speak. But if memory is fragmented -- divided up into chunks that are not next to each other -- the accessory will be placed into the first chunk big enough to hold it. If it loads on top of everything else, and (just as importantly) if the main programs that are running do not grab any extra memory from RAM while the desk accessory is open, you should be able to get back all the memory it took up when you kill off the desk accessory. (The easiest way to kill a desk accessory is to do a Control-click on its entry in the Desk menu, but there are other ways, described in the manual.)

    If the desk accessory you loaded has been placed into a fragment of RAM, you actually may be better off. If it is indeed small, this fragment will not be available to standard-size applications no matter what, so you may be able to use this pigeon hole in RAM as a place to stick other desk accessories, one by one, after you kill off the first one. There are many reasons why this may not work, however, and rather than get into the technical side of this, I'll merely point out that the succeeding desk accessories must not take up any more RAM than the size of the fragment used by the first desk accessory, and they must not allocate any extra memory for buffers and the like. The only way to find out how well this technique works is to try it.

    You will find that some desk accessories behave impeccably when you kill them. Atari's own XCONTROL.ACC is an example. When you terminate XCONTROL, it cooperates with Geneva, closes itself up, and leaves not a trace behind. Others, however, are less kind; Geneva is able to terminate them, but will warn you that problems could be caused if the desk accessory has hooked itself into system vectors. These are the computer equivalents of grab handles that accessories and programs sometimes use for their own purposes. You can't know beforehand if killing a desk accessory will cause a problem (often it will not, but you can't predict these things), so you MUST always save your work in other applications before terminating an uncooperative desk accessory.

    The issue of handling desk accessories in a limited-memory Atari seems more complicated than it actually is. Here are some guidelines:
    • Desk accessories that you want to have available all the time should be loaded at bootup.
    • Desk accessories that you need for only one task can be run when you want to use them.
    • If you intend to terminate a desk accessory, try to do it before running any application or any other desk accessory. 

  4. Sleep is good for you and your computer.
    Geneva is able to put any application or desk accessory to sleep. This can occur either manually or automatically. You put an application to sleep manually by any of the methods listed in the manual. Geneva puts a single-tasking application to sleep automatically whenever you run a multitasking application, and puts all multitasking applications to sleep whenever you run a single-tasking application.

    So far, so good. The concept of a sleeping application is so intuitive that it needs little explanation. When an application or accessory is asleep, it's not doing anything, but it's ready to pop out of bed in an instant. (Unlike humans, Atari software needs no wake-up period when Geneva's stern taskmaster is in charge.)

    But there's more to this concept than meets the pillow. There are many reasons you should consider putting all applications or accessories to sleep when you are not using them.

Sleeping programs:

    • Are cut off from the central processor, freeing up the CPU so that the task at hand runs faster.
    • Immediately disappear from the screen. This means they take up no space in your precious screen real estate.
    • Can't interfere with such system functions as the keyclick status, the audio level and the color palette.
    • Always return to the same spot you left them when you reawaken them.

Of course, you should not put an application or desk accessory to sleep if you need its services. Putting a desktop clock to sleep will remove it from the screen and won't give you a display of the time, for example. (But, to the clock, time itself isn't being suspended, as you'll see when you reawaken the clock; it will still show the right time.) Putting an accessory such as LittleNet to sleep will cut off one Atari's access to the other through LittleNet's networking services. Putting the Extensible Control Panel (XCONTROL) to sleep should not cause a problem, since Control Panel Extensions (CPXes) usually are not active in memory. (Even so-called resident CPXes aren't doing anything in memory, in most cases.)

The second benefit, clearing the screen quickly, can be put to good use when running NeoDesk. Rather than reducing screen clutter by manually closing NeoDesk's file and folder windows before you run a multitasking application, you can sweep NeoDesk's display away instantly by putting it to sleep; waking it up restores all the windows. If you are running an application from within NeoDesk, you obviously cannot put NeoDesk to sleep and then have NeoDesk launch the program. But a simple technique will let you launch an application from NeoDesk and then put NeoDesk to sleep, to clear away its windows and icons.

Before I explain this, keep in mind that you won't need to clear away NeoDesk's windows and icons if the application you are running fills the screen; in such cases, NeoDesk's own display isn't visible anyway. But many applications (when run in multitasking mode) merely replace NeoDesk's main GEM menu bar with their own, leaving the previous display on the screen along with their own windows. The technique to quickly shut down all of NeoDesk's windows and make all its icons disappear is very simple: First, click on part of the visible NeoDesk desktop to make it the foreground application. Then press the hotkey that puts the foreground application to sleep. Then click on the window for the application you just launched to bring it back to the foreground. (Note that it may have come back to the foreground anyway.)

Of course, once an application is asleep, you need a fast way of popping it back to life. You can do this with NeoDesk or any other application easily, as we shall see next. 

  1. Flags are for hotkeys, too.
    In the Flags menu of Geneva's Task Manager, you can set more than a dozen parameters for every application and desk accessory. But you can also assign the hotkey that brings the application or accessory to the foreground, or opens it if it is a desk accessory.

    But there is one more thing this hotkey does. It's not obvious until you use it. It wakes up a sleeping application. This means that every application you run can have at least two important hotkeys -- one that puts it to sleep and one that wakes it up. The put-to-sleep hotkey is a universal one, but the hotkey that wakes up an application must be assigned to each program and accessory through the Task Manager. The benefit, of course, is that this same hotkey pulls a non-sleeping application or accessory to the foreground, also.

    Assign these hotkeys carefully. Avoid using key combinations that another application needs to use, such as Alt-S and Control-S (commonly used as a Save command in many programs). Control-Alt-Shift combinations are often safe to use, and they can be easy to remember if they are employed with function keys.

    Here's a hot tip: Consider using the keypad number keys as hotkeys. Geneva uses these itself as hotkeys in window operations, but always with modifier keys. (Geneva never assigns a hotkey to an unmodified keyboard key in its default setup.) But you can blithely assign at least three of these keys safely, if you follow the guidelines here.

    The trick is to make sure that all applications and accessories that require these keys -- which means calculators, in nearly every case -- have the keys listed as reserved keys in the "keyboard settings" dialog of their "Execution flags" main dialog. My keys of choice are actually five keys on the keypad -- the open parenthesis, the close parenthesis, the 7 key, the 8 key and the 9 key. The two parentheses keys are nearly always safe because they aren't used in typical math operations (and when they are, you can always use Shift-8 and Shift-9 instead). The three other keys are needed in desk accessory or application calculators, of course, so you'll need to assign those three keys as "Reserved" in the Flags for the calculators you normally use. (Reserved keys are passed through to the program, instead of being acted on by Geneva.)

    Note that both MaxiFile and the Little Green Selector can be configured to use the keypad keys for keyboard shortcuts. In MaxiFile, you can turn off the keypad shortcuts by deselecting the "GUIDES" button in the configuration dialog. LGS has a similar configuration facility. If you want to use the keypad shortcuts with MaxiFile and LGS, avoid assigning them as hotkeys in Geneva, or make sure they are combined with one or more modifier keys.

    The advantage of using the two parenthesis keys and the 7, 8 and 9 keys as hotkeys without an Alt, Control or Shift modifier key is that you can press them with one hand. (If you have a pianist's finger spread, you may be able to press the right Shift key with your thumb while pressing one of the keypad keys with a finger, but the Alt and Control keys are in two-hand territory without a doubt.)

    Another hot tip: Use only the number keys on the keypad as your hotkeys, in eight levels. This will let you assign 80 different hotkeys, without needing to use any keys from the regular part of the keyboard. I won't list all the possible combinations, but here are eight to get you started:

    Keypad 1
    Alt-Kp 1
    Shift-Kp 1
    Control-Kp 1
    Alt-Shift-Kp 1
    Control-Shift-Kp 1
    Control-Alt-Kp 1
    Alt-Control-Shift-Kp 1

    A common misconception about Geneva's hotkeys is that they launch applications. They don't. The application must be running first; the hotkey brings it to the foreground and wakes it up if necessary. Another misconception is that they work only with regular programs. In fact, they work with desk accessories, too. Geneva's ability to pop open a desk accessory when you press a hotkey is a considerable asset. 

  2. Use NeoDesk. Don't use NeoDesk. Use TeraDesk. Use HotWire. Don't use them.
    We all know by now that the built-in desktop that comes with your Atari won't appear when you are running Geneva. It just plain can't. So in order to have a desktop sitting there in front of you, you need to run NeoDesk. Right?

    No, that's wrong. You can run TeraDesk instead of NeoDesk. Or you can run a different kind of desktop, one that is actually a file launcher and not a graphical interface, such as HotWire. The fact that you don't need to run NeoDesk has been touched on already, but it's one of those myths that refuses to die. Let's sort this out.

    First, Geneva is what provides multitasking. NeoDesk doesn't, nor do the other desktops. Second, Geneva's multitasking can't be turned off. These two facts bring us to a couple of conclusions:
    • The desktop either supports Geneva's multitasking or it doesn't.
    • No matter what desktop you are running, you can still do multitasking.

Let's look at them more closely.

Desktops are shells. They are programs that can launch other programs. Any desktop that runs under Geneva can do this. Repeat: Any desktop that runs under Geneva will let you launch your favorite programs. The difference between NeoDesk and the other desktops is simply this: NeoDesk will let you launch a program and then launch another one while the first one is running. The other desktops will let you launch a program and then launch another one after the first one has stopped running. (This is how single-tasking desktops have always worked.)

In other words, if you run, say, TeraDesk under Geneva, it will act just like it has always acted. You'll be able to run your word processor, and, when you have exited the word processor, you'll be able to run another program. TeraDesk won't be doing any multitasking.

But Geneva will. This is the point that gets lost. Geneva is multitasking all the time, even when TeraDesk (or any other single-tasking desktop) is running. That means you can go to the Desk menu, select the Geneva Manager or the Task Manager, and launch another application through Geneva while TeraDesk is running. This process may work more reliably if you set the desktop's flags to single-tasking, so that Geneva is forced to put that desktop (and any applications is has spawned) to sleep when you run another program. While that other program is running, you can switch back to TeraDesk through the Task Manager (or through the Desk menu or by a hotkey) and Geneva will either put that second application to sleep (if the desktop is set to single-tasking) or will run the two of them at the same time.

Note that all desktops except NeoDesk never expect to be running at the same time as other applications, so they may not behave properly unless they are set to single tasking, as I mentioned above. The only way to find out is to experiment.

But do you need to use a desktop at all? NeoDesk is ideally suited to Geneva, but you can recover 150 kilobytes or more of memory and speed up operations slightly if you run without NeoDesk. Obviously, launching applications is a simple matter; you merely use the Task Manager's file-launching menu or switch to the Geneva Manager and use its menu. (They do the same thing, and there is no advantage of using one over the other.) Even basic file operations are simple to do without a desktop, because the Geneva item selector lets you rename, copy, move, delete and find files and folders. You can also create folders and check on the free space of any of your disks.

Hot tip: Geneva's item selector can have up to 10 preset paths defined under its "PATHS" dialog. Make good use of them by defining them (and making sure you save them with the Task Manager's settings) so that you can use the shortcut method of switching paths -- by pressing a function key. You do not need to open the "PATHS" dialog to access this feature; just press the appropriate function key as soon as the item selector opens. If you regularly move or copy files to a set location, save that path in one of the function-key slots and merely press that function key after clicking on the "Move" button in the "TOOLS" dialog. (Of course, you don't even need to do any clicking. Pressing Alt-T will open the "TOOLS" dialog without the need for the mouse.)

If you have favorite desk accessories that supply most of the functions of a desktop (disk formatters, file-management utilities and so on), you should assign hotkeys to those accessories so that they can be called up with a keypress.

Another hot tip: The CodeHead macro utility, CodeKeys, works exceptionally well with Geneva, and is perfect for automating Geneva's 's outside the scope of this article), but if I were going to endorse anything outside of Geneva and NeoDesk, I'd put motherhood, apple pie and CodeKeys at the top of the list -- and not necessarily in that order.) 

  1. It's better to switch than fight.
    If you're like me, the first thing you did when you set up Geneva was to run as many programs as possible, arranging their windows as small as you could on the screen so you could squeeze 'em all in. Now THAT's multitasking, folks!

    It's impressive enough on the screen, but it's not a very effective way to work with your Atari. Multitasking doesn't mean doing many things at once; it means being able to do many things at once, whenever necessary. There's a big difference.

    When you are working with your word processor, you are probably not doing anything else. (Writing is hard enough on its own; I ought to know.) When you are extracting files from a ZIP file or an LZH archive, that's what you want to do at that time, and chances are you aren't doing anything else at the computer. I know of only one task that I regularly do on my Atari while simultaneously doing something else, and that's downloading files. Occasionally, I play MOD files while working, and sometimes I do image processing in the background. But for most of my sessions at the keyboard, the computer is doing only one or two things at a time.

    What this means is that I use Geneva more for its task-switching capabilities than its multitasking abilities. If this is the way you generally use your Atari, too, you can make things easier by setting many of your applications to single-tasking status. Geneva will put all other applications to sleep when you run a single-tasking program, clearing the screen and speeding up operations within that application.

    Watch out for problems with telecommunications programs (not accessories) that are online when you switch to a single-tasking application. Geneva cuts off all its access to the modem when a program is put to sleep. You may be able to switch to a single-tasking application safely for a few seconds, but longer timeouts will almost certainly cause the modem at the other end to let go of the line. You can prevent this from happening and still safely single-task any application if you use a desk-accessory telecommunications program. Even when Geneva puts all applications but the foreground one to sleep, desk accessories are not affected. 

  2. You don't need to scroll the desk menu.
    When Geneva broke the six-desk-accessory limit, Atari users were at last able to run as many DAs as they wanted. To accommodate Atari's oldest type of display, Gribnif added code to Geneva that kept the Desk menu from getting too long for the screen. Once the Desk menu has more than a certain number of items -- both accessories and running programs -- it turns into a scrolling list. The length of the scrolling list is perfect for an ST medium-resolution screen, but those with ST high-resolution displays and everyone who owns a TT or Falcon could make good use of a longer list, one that would extend, if necessary, right to the bottom of the screen.

    That is just what you can get if you load the Submenu CPX into the Extensible Control Panel (XCONTROL). The "Length" setting in the Submenu CPX extends the length of the Desk menu (and the Applications menu, which is what Geneva calls the Desk menu when it is torn off). A setting of 150 should work fine.

    Control Panel Extensions are usually freeware, and are available from GEnie and other online services as well as many bulletin boards. 

  3. C'mon baby, let's Undo the Twist
    Under Geneva, you never have to twist 'n' twirl to click one of the buttons in a dialog box. All GEM applications and desk accessories that are written to follow normal programming rules will show dialog and alert buttons that can be activated from the keyboard. Keyboard equivalents are assigned two different ways -- through Alt-key equivalents, shown as underlines, and through the first three function keys. The function-key method is easier to use, since it always follows the same pattern; F1 is always the first button, F2 is always the second and F3 is always the third, if there are three choices.

    An even handier shortcut is Geneva's method of checking dialog boxes, alert boxes and similar menus for the word "Cancel" or its equivalent. Pressing the Undo key will always activate the "Cancel" button in properly written GEM applications. (This feature of Geneva also works in many non-standard applications, too.) This means that the big Undo key at last takes on the role it should have had from the start, to cancel the dialog box that is active on the screen. From this point of view alone, Geneva makes a significant advance for Atari users. 

  4. You're a character! Put it there, pal.
    Sometimes you find pearls where you'd least expect them. Among all the adjunct features of Geneva is a utility that is surely little more than a gift of the programmer. It has nothing to do with multitasking or interface improvements, and could have been left out of Geneva; no one would have missed it yet. And yet this feature, the ASCII Table, is one of those precious stones that shine on their own. Its action is simplicity itself: Click on any character, and that character will appear in the foreground application.

    What is not obvious is that the ASCII Table will insert any character into text-entry lines of dialog boxes and other such items as well as into a word processor. It's easy to tell if the application itself will accept the character you choose; if you see it appear, it's usable. (Note, however, that you may not be able to use the entire character set in such things as filenames.)

    Unlike other GEM windows, the one the ASCII Table uses is supposed to be accessed when untopped -- that is, when another window is in the foreground. Geneva sends the character you choose to the topped window, so if the ASCII Table itself is the top window, it ends up trying to send the character to itself, which it obviously can't do. 

(The author is a long-time Atari user. His "Secrets of ..." articles have covered Flash, NeoDesk, TeraDesk, WordPerfect and LittleNet, with others scheduled to appear on a regular basis. He can be reached on GEnie as "a.fasoldt" and through the Internet at the address "" or through America Online.) 

Atari TT030 Revision Guide

posted Jul 28, 2018, 5:55 AM by Joshua Kaijankoski   [ updated Dec 6, 2019, 8:52 AM ]

What follows is a guide based on educated assumptions, logical conclusions, and some hard evidence. As such, the information provided may not be, or may never be entirely accurate due to lack of evidence. All information has been acquired from the internet, mostly from public forums, without explicit permission. Therefore, you might recognize a source as belonging to you and you may then request its removal. At the same time, the results of my public request for users to submit pictures of their motherboards has been disappointing and I hope this article will encourage TT owners to submit pictures as I'm willing to update this guide if new or contradicting evidence comes to light.

The Need for a Clear Guide

Longtime Atarians will remember that as long as the TT has been around, its owners have had to deal with questions as to its revision or version either to satisfy their own curiosity or finding it out for someone helping them troubleshoot it. This seems to affect the TT more than any other Atari model in my opinion. While almost every Atari 16/32bit system had several revisions of the motherboards, with probably the Mega ST having the most of them, there would never be a shroud mystery around them. STFM owners who bothered to find out their version probably only needed to know where the CPU was and that was enough for them.

Atari TT always intrigued people, right from the start. Here is why I think we pay so much attention to Atari TT revisions.

  • It was the fastest machine Atari ever produced
  • It was beyond most Atarian's grasp in terms of cost and a dream for many even today.
  • There were rumors and official documents acknowledging a TTX system that never saw production. 
  • Atari had originally intended the TT to be a 16MHz unit and at the last minute decided to go with 32MHz and implementing a solution that doubled the CPU clock while keeping the bus at the original 16MHz. This implementation is what we know as the daughter-board.
  • Some 16MHz units were sold to the public causing owners, especially 2nd-hand owners, to want to know if they were unfortunate enough to end up with one.

As years went by Atarians started to notice that TT motherboards changed and with Atari's very confusing versioning, all kinds of naming standards were created by users that probably had no base in reality. I myself have adopted Simbo's style as, love him or hate him (I wish he was around), he was one of the leading TT experts. However, as I have gone deeper and deeper into this rabbit hole, I've come to realize that this may not be the most accurate naming scheme after all.

At this point we need to clarify and recognize a few facts about Atari's versioning system and how they themselves refer to the different motherboard models. There are industry standards to PCB manufacturing at this scale. I won't pretend to be an expert, in fact I know jack squat. I do know that there are FAB (fabrication),  and ASSY (assembly) numbers and Atari used them typically in every system.

Cybercube's CaTTamaran installation guide offers some clues to identifying the various revisions but they seem to have yet another system of classifying revisions. They were, however, a very reputable company developing cutting edge TT030 specific hardware so we need to assume that they knew what they were talking about and probably saw and handled more TT's than most others. So we'll look at their instructions as well.

Explanation of Terminology

First we need to establish the TT lingo and help any newcomer to come to grips with the terminology that will get thrown in this guide. In no particular order:

  • SMD: Used to describe the latest model motherboard (surface mount device)
  • PGA: Used to describe the middle model with socketed CPU (pin grid array)
  • Daughter-board: A small PCB used on the earliest model that contained the CPU and circuitry to run the TT at 32MHz
  • Silkscreen: The (usually) white writing on PCBs used to denote components, revisions etc.
  • Rework: Hardware patch issued by Atari to upgrade system to a higher revision.
  • ECO: Engineering Change Order, same as rework
  • ASSY: Assembly. Atari always uses CAxxxxxxxx

Here are three versioning schemes typically found on the Atari TT:

1. The Silkscreen Revision (ASSY #)

This is the revision most of us are most familiar with. It appears on every single TT motherboard. Unfortunately, this is also the least accurate identification method since that number did not change at all since the early PGA (non daughterboard) model. Only the very first model can be identified by it but still it contains several revisions within it. Pictured below is how it appears in the various models.

Cybercube implies below, that some boards have had some handwritten REV numbers added later, perhaps after a rework procedure. I've heard of some reporting what looks to be a smudged letter but illegible.


Check the motherboard revision of your

You can usually find the revision printed on
a white label in the lower right hand or
left hand corner of the board. If your board
does not have one of these stickers, check
the REV ___ field as shown. If the revision
field is blank, check if the CPU (MC68030)
is situated on, the right side of the board .

2. The Sticker Revision (Also ASSY #)

This sticker appeared on the bottom left corner of the component side of the board in the SMD models. Earlier FABs did not have that sticker unless authorized Atari servicemen performed the rework procedures that upgraded the system and added the sticker. More on that further below. Since this method only applies to later models and doesn't tell the whole truth, this is only a semi-accurate but quick way of trying to identify your TT. Pictured below are a couple of examples.

Another excerpt from Cybercube:

/// How can I find out if I can install a CyReL CaTTamaran in my TT?

That depends mostly on your TT030 motherboard revision. To establish
which TT030 motherboard revision you have, you must open your TT030.
Please note that this may void your warranty. Once you removed the
cover (and any metal shielding), please check the lower lefthand or
righthand corner of your motherboard. Write down the revision level
usually found on a white sticker on the motherboard. For a quick and
easy installation, you should have at least REV. G.

I personally have never seen boards that have stickers from D-G. Keep in mind, Cybercube was a Canadian company and Simbo once theorized that perhaps the TT revisions vary regionally for whatever reason. He had observed, after servicing numerous TTs in Scotland, that the boards he typically got were from Europeans and the SMD models were usually stickered H,J, or K. Something to keep in mind. Again, if anyone has pictures of these boards, please email them to me.

3. The Fabrication Number

This is the only way of accurately determining the exact board revision (FAB) down to it's sub-revision (REV). Consequently you get the manufacture date from the same location giving you the week# and year (WWYY). It appears on every TT motherboard without exception. Unfortunately, this information is located inconveniently on the solder side (back side) on the edge of the motherboard where the rear connectors are. You would need to strip your TT completely just to get its revision number. I believe this to partly be the cause of the problem we have. We either are not aware of its existence or we don't want to (understandably) go through the risky process of dismantling the TT just to satisfy our curiosity. Pictured below is an example of this number and associated information.

The Absurdity of the Revisions

Here is a typical example of what we commonly call REV.H. All these can be found on same the PCB:
  • CA400770 (Silkscreen - CA# are always ASSY)
  • CA401146-001 REV.H (Sticker - ASSY)
  • C302406-001 REV A (FAB & REV)

The following pictures are of the same board depicting these numbers.

So it's a REV.H and a REV A? My PGA model is REV A as well but most are B1. But we call the PGA models REV.C! WTF?!

Do you now understand my primal urge to sort this once and for all?

Atari's Usage of Revisions

We fortunately have plenty of material that shows us Atari using a fairly consistent naming scheme. On internal documents such as rework guides, ECOs, and schematics Atari either used the full FAB number from the back or the last letters of that same number as shown below.

Here is another one.
Notice how Atari distinguishes REV from FAB?

For public documents we have an example below from the Atari System V release notes listing specific compatible revisions by the same FAB & REV combination.

However, I have not found documents where Atari is referring to the very first models by some revision number. All the rework procedures are for either B1 (or B.1) or D. And clearly B1 is the PGA model and D is the latest SMD model. And we know this for a fact as Atari included pictures of component placements for both revisions. But that only covers only two REV examples of the same FAB, or does it? Does this mean that the patches can't be installed on earlier than B1 revisions? But I successfully installed them on a REV A. Does it mean that later revisions from D don't need the patches? More on that later.

So I believe, from the evidence above, that the only way to accurately identify and communicate the TT revision is by following Atari's example of using the FAB & REV combination from the underside of the board. And this would be the end of this guide if it only were that easy. Since it is a massive undertaking for anyone to go through the process of dismantling the TT, there has got to be another easier way.

So already at this point I have to concede that we will have to continue to use our various ways of communicating the different revisions. And I'm totally fine with that. The point of this guide is to bring everyone to the same page. Give visual aids to help identify the board. And when the FAB & REV info is not available, use some other combination of facts to narrow it down very closely.

The Three Atari TT030 Motherboard FABs

Wait, what? Three? Surely there are more. Well, these are FABs and they have REVs. This is a logical conclusion and please prove me wrong if you can. But I believe Atari only had three major TT board FABs.
  • C300720-001 and its various REVs
  • C301763-001 and its various REVs
  • C302406-001 REV A

Don't worry about the other ASSY numbers. They are irrelevant but we can use their position on the board to help identify the different revisions. The REV.# on the sticker after the ASSY # is helpful but can be misleading as I'll show later.

So let's break down each of the three FABs and try to drill into their REVs.


What We Know

This is the very first TT motherboard FAB.
  • This board was not designed for 32MHz, hence the daughter-board that plugs into the CPU socket.
  • As the only FAB that can be identified by the ASSY#, it's ironically hidden under the daughter-board. But the daughter-board in itself is enough to identify the board as FAB C300720-001.
  • Other than the PALs and other circuitry that the subsequent FAB had, it appears that the rest of the board layout is pretty much identical.
  • If your TT has two fans at the back, you most likely have this FAB.
  • Almost certainly you have metal shielding in your case.
So what REVs are within this FAB? I will provide evidence that each of the three FABs had a REV A. So there's that at least. Chips 'n Chips only lists a REV 5 for this FAB for both the 16MHz and 32MHz PGA. I have never seen this REV mentioned or referenced elsewhere. I have only seen REV A. Here's an example:

It's bad quality but I assure you it's a C300720-001 REV A. So if this REV A has a daughter-board, maybe the REV 5 is the earlier 16MHz model? Could be, but according to this post, Eddy, who was one of the TT owners questioning his TT's performance, provides us with a very detailed description of his board.

This leaves no question then. His is a REV A, 16MHz unit as there is no way this particular FAB can be 32MHz without the daughter-board. So what does a TT without the daughter-board look like? Take a look below:

What Remains Unclear

At this time I do not know of any other REV than the one pictured. If someone has more information, please share it and I will update this guide. At this time I would like to discuss one issue relating to our current naming standard where A-C are the daughter-board and PGA models and D-K are the SMD models. We can safely assume that if REV A is in fact C300720-001 REV A and REV C is the PGA model we will talk about next, where does that leave REV B?

According to Simbo's post in Atari-Forum:
rev a had just a 68030 running at 16mhz no pal chips {beside the mpu}
then rev b was the same but had a better clock setup
and you can by this time add the 32mhz mpu daughter board it has the pal ics added to it

and here:
only rev a and a & c made it too market then rev d-k
rev A had the mpu onboard gold top and you could add a daughter board to its socket and it was 32mhz instead of 16

So not sure what to make of this. Simbo is basically saying REV B does not exist and has mentioned elsewhere that he has never seen one. Cybercube, on the other hand, speak of REV B as what we call PGA or REV C. They don't acknowledge a REV C at all.


I have enhanced the schematics and can be found here: Schematics

There are only two different schematics available for the TT despite there being all kinds of seemingly different versions. There is Revision 1, which is the one above and mistakenly referred to as Revision I. The other one is Revision G. That's it, that's all.

How do I know this is Revision 1 and therefore precedes Revision G? Simple. I've explained it on the schematic but I will illustrate it here. C300720-001 and C301763-001 REV A-B1 have components that don't exist in later models such as the RP42. And likewise, C301763-001 REV D and later have components that do not exist on the early models like the R888. Let's look at both:

TOP TIP: When searching for components in schematics you will typically find them in Sheet = 1st number of component. So RP42 will be found in Sheet 4. R888 is a small resistor connected between CPU U100 and component U112, so we will likely find it in Sheet 1.

I chose RP42 as it was part of a B1-only rework. Here it appears on Revision 1:
And RP42 not in Revision G. Just single resistors just like on the board itself:
Then we have the small R888 I chose because it plays a big part in reworks meant only for SMD models and CaTTamaran installation for SMD models. Here it is on Sheet 1 of Revision G:
And here it isn't on Revision 1 as it does not exist on the board:

Note that I highlighted the FAB C301763-001. This is further proof that the C300720-001 is very similar to the C301763-001. This schematic includes the daughterboard schematics so clearly meant to be used for that model. Also this schematic refers to REV D at times so this is a relatively late schematic for being our earliest.


Despite some seemingly contradicting information, this FAB remains perhaps the easiest to identify and communicate. I suggest that going forward we use any of the following to communicate this particular model:
  • Daughterboard model
  • REV.A in conjunction with another clarifying term
  • First Revision
  • CA400310
  • C300720-001 REV *



Although we usually hear and read of REVs B1 and D in this series, logically there has to be a REV A. My current TT happens to be one. Here are pictures of it prior to any mods.

Notice how the daughterboard circuitry is now located between the CPU and the TT-RAM connector? That's where the ASSY# was located in the C300720-001 FAB and that designation has moved to right above the VME circuitry. This is one way of telling the two FABs apart. 

I was surprised to find out I had, what perhaps is the first model of this FAB. Obviously one starts to think of what crucial change, that spawned REV B1, is missing from this board? Is it the rework shown above on the solder side? I've cleaned it up since by the way. So I don't know what to think of this.

I have very successfully made all the patches according to my Atari TT030 REV.C Rework Guide and outlined here: My TT Gets Some Love. Even though they were meant for B1. I have never had issues with this model. All upgrades (Thunder, Storm, Lightning, NetUSBee, Nova Mach64, ECL2VGA, PicoPSU, Parcp-USB) have performed flawlessly. The same could not be said of my previous B1 model. Thunder never worked on it, all kinds of weird issues. I actually bought this TT to replace that because of these issues I didn't want to deal with at the time.


This is the revision we think of when we talk about the PGA model. Here are pictures of my previous TT:

Please excuse the glare from the flash. Visually no discernable differences between A and B1 that I can see. Manufacture dates are within four weeks of each other.

One immediate question comes to mind; where is REV B? I assume that as REV B was about to go into production some last minute changes were done that warranted the B1 designation and REV Bs were never manufactured. However, with other models both revisions have been produced like Mega ST C103544-001 REV 1 & REV 1.1. 


Now comes the part where you will think I have gone nuts. I am including an SMD model in the same FAB as the PGA revision. This is the educated assumption part but I have good reasons to do it and I will provide compelling arguments for it. First we look at a picture of what I believe is a C301763-001 REV D.

It has no distinguishing markings telling us it's a REV D other than being a SMD model. Here's another board I believe to be a REV D:

Yes, that's right. It says REV.H on the sticker. But, I believe, that if you were to turn this board around it would say C301763-001 REV D on the back instead of the C302406-001 REV A we saw on a REV.H earlier. I know this overlaps with the next FAB but it's important to set the record straight at this point. Here is a board view of a REV.H on a C302406-001 REV A FAB.

Let's look at key differences. 
  • The REV.H on the bottom looks greener where the top one has metal plated areas and a darker overall appearance. 
  • The top one has wires on the board which seem to be all of Atari's known rework procedures whereas the bottom one only has one next to the CPU.
  • The top board clearly has the RTC Fix done to it by removing U402 as per Atari TT030 REV.D Rework Guide.
  • The bottom board has never had a U402 so the RTC fix is part of the C302406-001 FAB
This picture will help visualize:

Arguments and Evidence

Here come the compelling arguments as to why I believe the above to be true:
  • Atari's documents I posted earlier show that REV B1 and D are part of the same C301763-001 FAB
  • We know that REV B1 and D are PGA and SMD models from Atari's diagrams in their rework guide
  • REV B1 and D are very similar to each other but just have a different layout
  • There are no non-metal plated REV.H or higher with the patch wires we always see on metal-plated REV.H
  • Atari instructed the ASSY # and revision to be marked after rework procedure
    After rework the board essentially was upgraded to a higher revision, which is why our example C301763-001 REV D above can be a REV.H at the same time.
Now I'm going to take out the big guns. Have a look at this sheet:

We have here a board view of what clearly is meant to be a REV F. The top right shows the steps to get to REV F. Most important clue here is that REV D is the production release. This can be understood to mean that there weren't separate FABs for each revision. That would be ridiculous. So the base board to apply the patches was either C301763-001 REV B1 or REV D and then mark the revision on the board. The ASSY would be CA400961 compared to REV.H CA401146.

I think that Atari first marked the revisions as described above. This would confirm Cybercube's instructions. But apparently, as reported by users, the mark got smudged and became illegible. Atari at some point, I believe in the beginning of 1992, began using stickers on the bottom half starting with REV.H.

Another interesting observation is also on the top right corner. To get to REV E you would have to perform ECO# 1322 on the board. Look at the rework procedure on the top left. ECO# 1322 is only listed for REV B1, our PGA model. REV F on the other hand is ECO# 1323 meant for REV D. I firmly believe that that both reworks are the same thing for different boards which leads to some interesting conclusions:
  • REV E & REV F are the same revisions but on different board layouts?
  • There is no SMD model REV E or PGA model REV F?
But forget that because there is this:

This is Sheet 1 of the latest schematics known to exist. More on that in the next segment. Notice that the board revision is now G. Also note that this is still FAB C301763-001. Notice also that there are steps to get to REV G. But something is not right. REV D now has an ECO# for it, 1308. I do not have information about that procedure. But look at the rest of the REVs. They have different ECOs to the previous ones. Also, now they read Revised per ECO instead of Release. So in the less than two months between these two sheets there were further revisions.

Let's try figure out the rest of the REVs.


The ECO got changed for this REV. We don't have information about 1305. Seeing that this ECO precedes the ECO# 1308 for REV D, we could assume that it still only applies to the PGA model REV B1.


Interestingly this is the same ECO# 1322 as the REV E had earlier. Meaning that REV F is in fact only for the PGA REV B1 and therefore there probably is no SMD REV F in existence. That is, unless they managed to mark a few PCBs in the less than two month period.


The last of the C301763-001 FAB. I mean it has to be. Otherwise we wouldn't see REV.H on C302406-001 FABs as we clearly do. This also is same as the previous REV F.  Atari apparently nudged a rework procedure in the middle and bumped REVs E & F to F & G.


REV A and B1 use the same schematic as detailed in the previous section. Download here: Schematics
For REV D & G you will want to consult the REV G schematic found on


This is a lot of information to handle and condense. As to what we should call this FAB, we have to go by several names as there are two significant board layouts for this FAB.

REV A & B1
  • I think we can continue to call these boards REV.C or PGA
  • Those names don't conflict with other naming schemes
  • These names are already well established in the community
  • Using REV E or F is not recommended unless there is sufficient evidence and you are prepared to explain a lot.
  • My REV A has all available rework done to it and exceeds REV F by far.
  • Going by REV D to indicate the first SMD model is fine as long as it's not confused with the last SMD models
  • Using REV G if applicable is recommended if you can.


This section will be much shorter as I inevitably had to cover a lot of it in the previous sections. But here is a couple of board shots:

And a REV.J

Notice the lack of wires on the bottom part of the board unlike the previous REV D models. I do not have any pictures of a REV K but I would assume that it would probably have the same rework on it as we see in these two as these two as I explained in the previous section, I doubt that Atari would make another FAB REV to fix the changes.


Eh? We're back to this now? Time for a refresher. We're talking about the FAB and its revision:

I believe this to be the only revision of the C302406-001 FAB and as such, the very last TT board. I base this simply on the manufacturing dates shown above. We are well into 1992 at this point and Atari was starting to focus whatever little interest it had left on computers to the Falcon. And we know that it waned quite dramatically where Atari all but abandoned the Falcon and the computer line to go all in on the Jaguar.

We also haven't heard of any later revisions than REV.K and most of what I know of them is from Simbo's observations having worked on several of them.

Again, I'd like to be proven wrong so please send me pictures of boards that are not included here.


I'm inserting this part here as it has severe implications to the sections ahead. There are no known schematics for this FAB. I don't even have to prove that as both known schematics clearly indicate they are for C301763-001 and dated much earlier than these to REV.H models. You can verify this yourself by locating U402 next to the battery. It is the IC that gets removed in the RTC Fix. All boards prior to this need the chip to be removed. Since this FAB never had this chip, it's safe to assume that it would also not appear in the schematic. Just like we saw with the subtle differences between the two schematics from the same FAB earlier.

Also, Simbo confirms this rather emphatically here:
for h -jk conversions
best is holding out becouse prob knowone bought it from him schematic for rev J would be an orgasim for sure
i think this is a needed mos for h- j-k
like me

ill stick on some cash if some people want to go share
for the schematics for rev j
share on a board fund basis

if it takes payin a couple of homboys to go around
then so be it...

So the implications of not having schematics is that we cannot rely 100% on current schematics meant for another FAB as even within a FAB there can be changes. We can overcome this by being careful and logical.

The other problem is that we don't have a listing of revisions and the ECOs to get there as with the REV D-G.

Let's still cover the ASSY revisions then the best that we can, starting with:


I like to include a period between REV and the letter so as to distinguish it from the FAB revision. Well, we have plenty of pictures of this particular board leading me to believe that this is likely the most sold version of the SMD models, if not the entire line. 

If REV G was the last of the C301763-001, this being H must be the first of the C302406-001. And since we have two examples of C302406-001 REV A being REV.H we can 100% trust this.

With all this evidence, we have no choice but to accept, that the other REV.H is an upgraded REV D. And because none of the REV A REV.H models have the patches on the bottom of the board we have to conclude that if ECO# 1323, which is part of that wiring, upgrades to REV G, that only leaves one possible outcome. REV.H is achieved through the VME Bus Fix. If only that rework guide could have had the ECO# or date. 

This will help. Here is the last known Atari Technical Bulletin TT30-0007:
Looking at the date above, we're well past the manufacturing dates of the C302406-001 REV A boards. Also, this fix is meant for REV B1 & REV D boards that we now know without a doubt to be C301763-001 FABs. This confirms my conclusions that REV.H and later boards, or in other words all C302406-001 boards have this fix and all pre ECO #1369 patches. This also confirms that B1 PGA boards can attain this prestigious level.

What about the patches that we do see on C302406-001 boards? Those appear on earlier Atari Technical Bulletins. Most likely it is either TT30-0006 or TT30-0002 that 0006 was supposed to fix:

This variant of the fix is outlined and illustrated in my Atari TT030 REV.D Rework Guide.


Never seen or heard of REV.I, so we move to REV.J. And that's all I have to say about REV.J.


Seriously, I had nothing on J. REV.K on the other hand is supposedly the very last TT. As I mentioned earlier, I doubt that REV.K is free of rework. If it were, it would mean that it would be C302406-001 REV B or something and I find that highly unlikely due to reasons already stated. I think it's simply a small fix that got applied after REV.J's fixes.

How about the REV.K board settings schematics floating around? It doesn't seem to pertain to this REV.K. The date is wrong, the ASSY is wrong and, quite frankly, even if they were correct, it gives absolutely no helpful information. I'm not even going to post a picture of it.


So, just like my 1 month summer vacation is about to, we have reached the end of this saga. What to call your C302406-001?
  • Last Revision of the TT is fine
  • C302406-001 REV X is great
  • Don't call it REV.H without clarifying whether it's C301463-001 REV D or C302406-001 REV A
  • REV.J or REV.K is fine as there is no room for interpretation there.

Final Words

If you managed to read this far, congratulations, you deserve a/your TT. Treat it well. 

As to what to call the revisions, my opinion is that we primarily use ASSY REVs as they are the single most consistent naming scheme. Here is my suggestion:
  • REV.A - First model, C300720-001, 16Mhz or 32Mhz with daughterboard
  • REV.C - PGA model, C301763-001 REV A & B1 (if you actually happen to have REV.E or REV.F give them in conjunction with REV.C)
  • REV D + ASSY REV - first SMD model, C301763-001 REV D (example REV D upgraded to REV.G or REV.H)
  • REV.H, Latest FAB - C302406-001 REV A
  • REV.J
  • REV.K

If you have more information, suggestions or corrections, contact info is on the bottom of the page. Or you can reply to the threads that this gets posted to. I will update this guide as needed. When enough time had past, I will compile a PDF of it. 

TT VME Graphics - Revisited

posted Jul 27, 2018, 2:51 AM by Joshua Kaijankoski

Just recently I posted the article TT VME Bus Fix - Does it really make it faster? where I compared performance before and after Atari's VME Bus Fix which all REV.H motherboards and up seem to have. As kind of expected, the gains were not significant. I mean we would have noticed this years ago. What is unexpected, however, is the sudden performance boost (on average) than just a few days ago. So what has changed? Am I missing something? If so, let me know.

Before I show the results, here's what has changed (I'll list everything even if it is seemingly unrelated):
  • Motherboard recapped
  • Rest of the rework done (My TT Gets Some Love)
  • New storage (TT Cable Management and Cooling - Extreme Edition)
  • New HDDriver version 10.12
  • Lightning USB installed and drivers loaded
  • New GAL and hardware mod to Nova as per Lightning installation.
  • Fresh NVDI 5.03 installation with Nova option. (SYS files disabled as before).
  • New English version of menu.prg

Not changed:
  • NVDI version
  • Gembench version
  • Nova drivers apart from menu.prg
  • Test OS TOS 3.06 Thunder&Lightning edition
Here is a comparison in 1280x1024x256 against exact same reference. The difference is staggering but not all are gains if you look closely.

And here is 1024x768x65536. Same story. Hard to believe that 16bit color at this resolution is almost as fast as TT-High.

So how much faster is Mach64 to the ET4000? I happen to have both. The reference is before all fixes so keep that in mind. Also that test was done without NVDI so to be fair I tested without it now as well. Resolution is at 1024x768x256. Pretty crazy.

TT Cable Management and Cooling - Extreme Edition

posted Jul 26, 2018, 7:37 AM by Joshua Kaijankoski   [ updated Jul 26, 2018, 9:51 AM ]

I hate cables, especially ribbon cables like SCSI and IDE. Ever since I got Thunder (and Storm) I've been looking for a solution that plugs straight into Thunder. Challenge has been to a) find something small enough b) connector in right orientation c) high enough capacity. Never found anything close enough. Ideally I wanted a Compact Flash solution. Then I ran into TrueIDE that I bought from the lovely folks at Shipment was super fast and they included a nice Amiga postcard with a personal message. Thank you very much if you are reading.

TrueIDE checks all criteria apart from size. I wanted this to work. After I tested it with conventional methods with a brand new SanDisk Extreme 32GB CF and got it running at over 5500kbitsbytes per seconds (yay!) I knew this was meant to be. After careful measurements I had a plan ready. You can imagine my apprehension by looking at the pictures below. 

Yes, I know I could have done this without soldering by getting a DIN 41612 connector like the cards here have and just sandwich it between. But I was too eager to get it done. Also, have I mentioned I like soldering? And it's easy to reverse, flux and wick.

The keenest and most perceptive among you will notice three things. First, TrueIDE is missing the second connector. Yes, had to remove it as it wouldn't fit otherwise. No warranty for me. Second, there's an adapter below TrueIDE. Unfortunately the Master side is the "wrong" side. Otherwise it wouldn't have needed a riser but I quickly soldered one from a ribbon connector and same header strips I used in Thunder. Thirdly, I had to remove the header on Thunder to make room. All small sacrifices as it is a "great success".

So here we have my setup so far. PicoPSU, Lightning, Thunder, Storm, Mach64 is out of the frame. Next plan is to relocate it to the hard drive bay. I have a neat idea for the USB ports! Stay tuned for that.

Aaand here is my cooling solution. Noctua 120x120mm and 15mm thick. 15mm is crucial. Here it is on Noctua's website.

But will it fit???

LOL! Obviously temporary but such a nice fit and soo quiet. It moves air nicely through the top vents. I call this a success!

Here is a bonus speed report. It actually is kilobytes and readme confirms it as well. 

My TT Gets Some Love

posted Jul 23, 2018, 8:45 AM by Joshua Kaijankoski   [ updated Jul 23, 2018, 10:14 AM ]

I reckoned it would only be fitting that my TT030 receives all the rework procedures I had recently created visual guides for. I'm very happy and relieved to have done it all successfully. I also did a highly experimental "Poly-Mod" that I will outline at the end.

Essentially, with these fixes, my early REV.C (C301763-001 REV A) is now a REV.K.

I am not responsible for any problems or damage caused by these procedures. Attempt them at your own risk.

Rework Done

REV.C Rework Overview


Very straightforward. Nothing much to comment here. I haven't received my frequency counter yet so once I do I will adjust it. Frequency counters are very cheap and found from all usual sources.


I removed the 74ALS30 and soldered a socket in its place. I inserted the 7430 as pictured with pin 8 bent up. I shortened one end of the resistor and inserted it into the socket, which was a snug fit. The other end was soldered to pin 8 as pictured.

U703 was conveniently socketed already so I simply removed it, bent pins 17,18, and 19 as pictured and re-inserted it. I replaced U705 74LS244 with a socket and inserted a 74F244 in its place.

VME Bus Fix along with other fixes.

Rework Procedure 3

I love soldering. So this is U206. I cut the trace higher up right next to the via. Hot snot is recommended.

Again, very straightforward. Use hot snot where needed.

I simply use a leg from a cap or resistor to jumper pins on an IC. So much easier and neater.

Again, a simple link using a leg from a component. Note pins 12 & 13 are joined by the jumper. I simply exposed more wire and used it as a bridge.

Same picture again just to show U900 pin 83.

Rework Procedures 4&5

RP42 and U403. Just a simple matter of repealing and replacing. Again, I used sockets. It's good practice. Resistor pack is BOURNS 4116R-1-100LF Fixed network resistor, 10 ohm, 4100r series, 8 elements, isolated, dip, 16 pins. Black wire on top is for Thunder.


So we finally get to the highly debated subject of re-capping that seems to have proponents on both sides. Add to this the fact that polymer capacitors in Atari computers are still experimental.

Polymer capacitors use solid, conductive polymers as the electrolyte. The benefit of this is that the capacitor never leaks or dries out, which is the reason we re-cap in the first place. Other benefits are longer life, better stability, lower ESR. Polys also don't explode.

There were 3 capacitors I didn't replace with polys. CD02 didn't get replaced at all as I couldn't find a replacement. Axial polys are hard to find so C105 was replaced with a conventional Nichicon lytic. Polys typically don't go below 10uF so C845 is also a lytic.

I used Kemet exclusively with polymer. Where Panasonic, Nichicon, Rubicon, et al reign supreme in the electrolytic scene, Kemet has always been among the best ceramic and tantalum capacitor manufacturers. They make decent electrolytics as well. Kemet, however, is a leading supplier of polymer caps and by far the best manufacturer for my purposes. They have the best selection and the sizes are perfect as you will see in the pictures. Nichicon doesn't have a good selection of polys and many of them (FPCAP) are Fujitsu. Here is Kemet's through-hole product line: PDF

Here is a capacitor replacement guide. A PDF version is downloadable at the end.

Very pretty. Perfect fit.

TT VME Bus Fix - Does it really make it faster?

posted Jul 21, 2018, 7:24 AM by Joshua Kaijankoski

So I decided to attempt the VME Bus Fix as per Atari's rework procedure. The fix saves 1 clock cycle per transfer so it just might be faster. Before I did that, I took screenshots of two benchmarks:

I have a 2MB Mach 64. Only NVDI 5.03 and Idek's Nova drivers are loaded. Reference is the exact same setup and system sans Mach64. The Mach64 @ 1280x1024x256 colors is pretty much as fast as TT High. That says a lot. The ET4000 is faaar behind. 

Here is the same setup after the VME Bus Fix. First result is vs the first screenshot above. The rest are with the same TT High reference.

So the results are pretty conclusive and somewhat expected. Wasn't expecting huge differences but discernable gains. Average results are not affected that much but looking at single tests the gains are 1-3% faster. This is with gfx card. I don't know how it saturates the VME bus. Which is why I tried 16bit color as well. I haven't installed Lightning yet, I wonder what speed differences we would see with USB file transfer.

Atari 520STM Restoration Pictures

posted Jul 4, 2018, 2:55 AM by Joshua Kaijankoski   [ updated Jul 4, 2018, 2:57 AM ]

I thought I'd post pictures of my latest restoration project as I realized I had never done that . Unlike my previous projects, this was a "restored to order" job with some specific requests.

This was the starting point. A little dirty but not bad at all.

Here is the motherboard before any work has been done. Very clean. It's the last revision of the small STs and only one that supports 2-chip TOS.

Right off the bat I noticed that there has been minor rework on the board. It's clear that a bunch of resistors have been changed. They are connected to the RAM chips and the MMU (memory management unit). It seems that someone wanted 68ohm resistors instead of the original 33ohms. Marked in yellow. No idea why it was done and no reason to. I decided to revert to 33ohms.

The first specific request was for 1MB ram instead of the 512KB from factory. I chose to upgrade using the same method Atari used on the 520+, which was the piggyback method. I took some old 256KB simms with suitable 41256 chips and removed 16 chips that I then proceeded to solder on top of the 16 ram chips on the motherboard leaving pins 4 and 15 free to run wires. For more details see this thread on

I left wires long at this point. This board revision had nice locations for the wires. I installed 68ohm resistors and cut the bridge on the other side on RAS1.

Here I reverted back to the original 33ohm resistors. Notice the fruit of my OCD with the stripe alignments. This was worth doing just because this previous change was a botch job. The original resistors had been snipped off instead of properly desoldered and crazy amounts of solder was used. It was really crusty.

Here's a post op picture of the solder side of the same location. The solder mask was quite fragile so I applied solder mask where needed and cured it with UV.

Here's a shot of a cleaned top case. I always remove the badge as it's very susceptible to damage. I also always spray a few coats of matte lacquer on it to give it some protection.

The second specific request was for a dual TOS. There was to be no visible switch either. I had to hack a solution as I had a deadline to keep. Here is the result. I used two 27C020 chips. I'm picking VCC of the neighboring sockets because A17 (pin 30) is obscuring VCC on pin 28 of socket. Likewise it's easier to pick A16 from pin 22 of neighboring socket rather than routing it awkwardly under the chip. Then GND is connected to OE. A17 is pulled low by 10K resistor when jumper is off. That's one TOS version. Putting in the jumper pulls A17 to +5v and another TOS is selected. Not pretty but it works. I made a point of not soldering anything on the board in case the roms got changed.

Here we have all board work complete. I changed all the caps and pull-up resistors for the address lines to 3.3Kohms. All circled below.
Underside completed. Reflowed most of the connection. Applied soldermask where needed and then a thorough cleanup.

Like new. Keycaps are double-shot so very durable and you can't erase the legends. Note the different shade loose key. I've encountered at least three different shades of keycaps. 
Finished product. Picture doesn't do it justice.

For all this, the customer paid $140 + shipping.

Mega ST Keyboard Switches

posted Jul 3, 2018, 1:31 AM by Joshua Kaijankoski   [ updated Jul 3, 2018, 1:31 AM ]

They are mechanical and they are Cherry MX Blacks. I know because I finally took one out. No membranes anywhere. This is not a new discovery but something I had to verify myself because of lack of evidence.

Some people complain that Mega ST keyboards aren't as good as TT/MSTE membrane keyboards that have tactile feedback. And they would not be wrong if that's what they are after.

Mega ST's Cherry MX blacks are linear switches, meaning they have no click or tactile feedback by design. They are also one of the earliest Cherry switches from 1984.

The beauty of the Cherry MX switches, and therefore the Mega ST keyboards, is that they are replaceable. If I want click and tactile feedback, I can just replace the switches with Cherry MX Blues from 2007. Not the easiest task because each switch is soldered on the PCB with two pins and attached on a thick metal plate. This is why Mega ST keyboards are so heavy.

So I might just do that, replace all switches with MX Blues. Here are some pictures of the switch I removed. Phone had a hard time focusing.

Atari TT030 REV.C Rework Guide

posted Jun 10, 2018, 1:43 PM by Joshua Kaijankoski

This started out as a guide for myself to do the rework down the road. This is for REV.C (PGA CPU) which is the model after the daughterboard REV.A and one before the REV.D-K ("SMT Models"). Took a long time to do. I hope someone finds it useful. Filesize is big, but for a reason.

1-10 of 62