þa‹Rþw5þ mW<þhý oþ nSystem-wideHere's some background info on the GPIB ports for various GRiD computers: 1. The original GPIB port was on the Compass. This used a TI 9914A chip. The port was accessible only from GRiD-OS (MS-DOS access was not supported, and in fact was just about technically impossible). The original driver was in PROM, and was full of bugs; there were many versions of a RAM-resident driver issued which fixed most but not all of the bugs. Because the driver was written under GRiD-OS, it was a multitasking driver. The calls to access the driver (what in today's language is called an "API", or Applications Program Interface") were not like any other GPIB implementation. 2. When the 1307 was designed, there was a strong desire to make the GPIB port compatible with the Compass (instead of making it compatible with the rest of the GPIB world), to protect our Federal customers' software investment. Thus a TI 9914A chip was used, even though it was starting to get out-of-date (technically obsolete) at that time. The then-current version of the Compass (GRiD-OS) RAM-resident driver was used as the starting point for the 1307 GPIB driver; code was added to "fool" the multitasking driver into working in the single-tasking MS-DOS environment (since the 1307 was basically an MS-DOS machine). The driver was put into PROM. An InteGRiD driver-access routine was released (called "GPIB~Dev~, I think), although we messed up and didn't include it with the first bunch of 1307's shipped. 3. When the 1307 was initially shipped, the GPIB was only easily accessible from GRiD-OS or InteGRiD (running under MS-DOS). The driver calls were identical to the Compass GRiD-OS calls. Access to the driver from MS-DOS was not supported (although it was technically possible). It was also possible to directly access the 9914A hardware chip, and minimal documentation was provided to allow that. 4. Some time after the release of the 1307, there was enough interest from the customer base (like maybe 6 requests) to provide MS-DOS access to the GPIB driver in PROM. This was done by providing a "Microsoft C Library" which allowed a C-language applications program to call the driver in PROM. The calls to access this library were modeled after the BASIC driver for another brand of GPIB half-card, one which seemed popular back in 1985 but which is not a major player in today's market (they may even have gone bankrupt, I'm not sure). The result is that the "Microsoft C Library" access calls aren't like anything in common use today. 5. By using "Microsoft C Library", one could avoid having to write low-level ASM code to access the 1307 GPIB from MS-DOS, and avoid likely interaction problems with the ROM GPIB driver used for disk access. But even if someone used the library, their application still would not be compatible with the SAIT cartridge (see #6 below). 6. The SAIT cartridge was designed with no attempt whatsoever to be compatible with anything GRiD had done in the past. It was designed to be as compatible with the "real world" of GPIB as possible (unlike the 1307), so it could be used with off-the-shelf GPIB software such as LabView and Asyst. To accomplish this, SAIT basically did a re-layout of the off-the-shelf "IoTech" GPIB half-card to fit into a cartridge. The IoTech card itself is basically a low-cost clone of the National Instruments half card; National Instruments has become the "established standard" for GPIB PC hardware over the past 5 years (I don't think they even existed back in 1981 when the Compass was designed). Both the IoTech and the National cards use the uPD7210 chip, which (at the hardware level) is totally incompatible with the TI 9914A chip. The latter still exists, but it has lost most of its market share, since the uPD7210 is a much better (more efficient, easier to program) chip. 7. The SAIT cartridge is shipped with the GPIB driver provided by IoTech (called "Personal488"). This driver seems to be a pretty well-designed piece of software, and is the preferred way to use the SAIT cartridge. The IoTech Personal488 driver also supports some other manufacturer's GPIB cards, including the National Instruments PC II and PC IIA cards and the IBM GPIB Adapter. Note that National Instruments has it's own GPIB software driver, called "GPIB-PC". This driver supports the National Instruments cards completely, and the IoTech card/SAIT cartridge partially, but seems to have problems with DMA I/O on the IoTech card. The National Instruments driver has a very different application program interface (API) from the IoTech driver, providing more low level GPIB control, but at the cost of greater complexity and a longer learning curve. written by Geoff Walker, 4/21/89 modified by Will Strang, 5/1/89