To: Gibbons@Marketing@GRiD From: Strang Subject: Re: OS/2 Marketing Flash & 1537 Date sent: 04/02/89 2:05 PM Copies: Lieberman@marketing@grid Jefferson@marketing@grid Bailey In reply to the message of 04/02/90 08:05 AM from Gibbons@Marketing@GRiD: Mike, See my responses after your questions. Will -------------------------------------------- In reply to the message of 3/30/89 5:36 PM from Strang AT FRC@GRiD1 Hi Will, Thanks a lot for your note - you filled in a lot of 1537 gaps for me. Please keep it up with other software products as David and I could both use the refresher. Notes on your note (for Judy too): 1) SCSI support - will the Adaptec SCSI drivers that we will receive for desktops for 1.2 also work with the 1537? Or is this a separate set of drivers? A: I am sure that the 1537 will need separate OS/2 SCSI drivers from the desktops. The Adaptec 154x line of SCSI cards for desktops are "smart" cards that do PC/AT bus mastering, and take a fair pile of chips to implement. (There's more than half as many chips on a 154X card as there are in the whole 1537.) The new Adaptec AIC6260AL integrated SCSI chip (commonly called Sparrow) that is used in the 1537 is no where near as smart as a 154x, so the host processor must do a bunch of the work that is done on the 154x cards. Given the major difference in intelligence between the 154xs and the Sparrow, drivers for the Sparrow need to be larger and smarter. Adaptec has just introduced PC cards that use the Sparrow, with product numbers of 152x. Note that the 152x cards have on-card BIOS support, while the 1537 SCSI implementation does not. SCSI support in the 1537 will be entirely by loadable device drivers in the near to medium term. My understanding is that Adaptec will be supplying GRiD with loadable device drivers that provide the same functions as the 152x BIOS, except booting from a SCSI device, of course. According to Bruce VanDyke at Adaptec, the 2.0 release of the Sparrow driver will include ASPI support. 2) Display driver - does that display support the 6300 mode? We have a driver for that under development and I have a test copy I could let you play around with. OS/2 does come with an EGA driver - that should work as well, right? A: The 1537 uses the Chips & Technologies 455 VGA chip, which unfortunately does not support 6300 mode. EGA is the best standard resolution we can do on the 1537 internal display. The C&T 455 has not been popular, so it's quite possible that OS/2 has never been tested with a display adapter based on it, and might have some problem with it. Testing will tell. On the 1537, we continue the GRiD tradition wherein the maximum visible resolution changes when we switch from internal to external display. Thankfully, it's not as odd as on the 1520/30, where the internal 6300 mode can't even be displayed externally. 1537 users who mainly use an external display could install for VGA if they just avoided the bottom of the screen when using the internal display. I've done it under Windows, and it's wierd but possible. 3) Serial port - ACK! (no, not ACKnowledge, OOPS! I forgot one!) Is that an offer to write a device driver I heard? Sign that man up! (David - I'll revise the MRS.) A: Yes, that's an offer to write a device driver. Writing the necessary drivers is part of my pennance for getting to spec that serial port. I will take you up on your offer to help assembling an OS/2 development environment sometime soon. I would hope to start from the OS/2 COM1/COM2 driver sources in developing an 85C30 driver for the 1537, so that's someting I'll ask you for. Recall that I attended the OS/2 developers conference, and therefore in theory know something about how to do this. In fact, my knowledge is all theoretical, and 2.5 years old, but better than nothing. 4) GPIB - Hooray for SAIT! I have actually encountered problems with their cartridge before when our customers were using the National GPIB.COM with DMA - if I understand you correctly, this won't be a problem anymore. A: Being a big player in the National Instruments compatibility arena, IOTech knows how to build an NI PC-IIA compatible card. DMA was the big problem with SAIT's card, and it should not be with IOTech's card. By the way, IOTech says that they also put some extra features needed to support their XENIX GPIB driver into their GPIB cartridge. A few minor mods to their XENIX driver would be necessary to make it all work, but they would happily do so (for free) for a significant sales opportunity. 5) Applications support - if you do decide to start "porting", let me know if you need anything in the way of development packages like the SDK, etc. I guess it's up to you folks (and your demand for OS/2 applications) if that is the direction you want to go in, but let me know if I can help in any way. What specfic features would you want in a termulator? The only package I have in my posession does not run under PM - it's character based. I am aware of a couple of OS/2 products though, so tell me what you need and I'll try and get it. A: The special features of GRiDTerm 3.2.0 that are most useful are the hardware half duplex support, Baudot character set support, split transmit/receive windows, and loadable external file transfer protocol support. Note that hardware half duplex has NOTHING to do with the "Transmission mode" setting in GRiDTerm's "Communication line properties" form, under to options menu. Always leave that at "Full duplex". It's labeling is somewhere between confusing and wrong. For hardware half duplex, set "RTS active" to "Only while sending" in the "Advanced line properties" form, under the options menu. The "Delay after RTS" setting in the same form is also necessary for hardware half duplex with many devices. 6) 3+Open - YESYESYES - That is what I am trying to talk the MIS turkeys here into instead of Banyan! I understand from Simon Tam that Banyan stations will be talking to OS/2 soon, but I would think we need an OS/2 networking solution like Open to ensure compatibility. Have you heard about DCA's Comm Manager and its WAN facilities at all? I'm trying to talk to DCA about it wo much luck. A: Well, I must admit that I've used Banyan Vines only a little and 3+open not at all, but based on my research I think Lan Manager is a much better bet than Vines in the long term. Lan Manager has the enormous advantage of being based on an open, documented operating system, with well defined interfaces for writing drivers. I'm don't like the short list of external hardware supported by Vines. I think that Banyan is doomed to be eternally playing catch-up, with the single exception of StreetTalk, where the rest of the world will catch up to them before too long. I know only what has been written in the trade press about DCA's Comm Manager, which is to say, no details. Isn't that a joint project between DCA and Microsoft? Might Microsoft be more willing to talk about it? I'll poke around and see if I can find any info around here. Mike PS Thanks again for possible usages in the Federal sector - without that point of view I could leave critical features out of new OS's. -------------------------------------------- David and Mike, I like your recent Marketing Flash writeup on OS/2. It sounds like you're headed in the right direction. I'm glad we'll be supporting HPFS on laptops. For a while, it sounded like we wouldn't. Thanks for including the 1537 in your considerations. I can offer a few comments on OS/2 on the 1537, and where it could fit in federal business. First, regarding hardware support: Adaptec, the maker of the 1537's SCSI chip, has OS/2 drivers for that chip on their "to do" list. They will come out with a basic disk and ASPI driver for OS/2 first, then other drivers to sit on top of ASPI later, including one for tape. I suggest that we just wait for Adaptec in this area. For 1537 internal display support, EGA (640x350) is the way to go, if resources allow for it. Otherwise, I guess we will suffer with CGA. Just so that you know about it, I will mention an alternate approach that would require driver development. This is what we did in InteGRiD, because it was easy there. The 1537 run OK with VGA mode on the internal display, except that only the top 400 pixels of 480 are displayed. A driver that sets VGA 640x480 mode but only uses the top 400 lines of pixels for display makes optimal use of the 1537 internal display. I'm NOT saying we should do this for OS/2, but just mentioning it so you know about the possibility. The other possible hardware support need for OS/2 on the 1537 would be a serial driver for the "RS422" custom serial port. In the 1537, it is based on the AMD Z85C30 2 channel USART. One or both channels can be used, so if needed we could actually provide 2 serial ports, each with half the normal complement of control lines. I am developing InteGRiD, GRiDLink, and MS-DOS Int 14 drivers for this port, so I would be a possible resource for developing an OS/2 serial driver if we need one. For your amusement, a writeup on the 1537's serial ports is attached. You can get an AMD Z85C30 Technical Manual from Judy Jefferson, if you want one. Regarding Mike's facetious comment on the GPIB cartridge, IOTech has developed a GPIB cartridge for the non-Tempest 1500s, which I hear that SAIT is going to switch to selling, in place of their own GPIB cartridge. The IOTech cartridge is genuinely National Instruments PC-IIA and IOTech GP488B hardware compatible, which the SAIT cartridge was not. We can just wait for IOTech and/or National Instruments to develop OS/2 software support for their hardware. Regarding use of OS/2 in the federal sector: One use for OS/2 would be as a replacement for InteGRiD in certain situations. There are a moderate number of federal customers using InteGRiD based software for various sorts of portable serial communications, using either GRiDTerm or custom applications, most of which were developed by us (the federal Systems Development group). Many of these customers are indirect or hidden within the intelligence community, making a precise count impossible, but I would guess between 100 and 200 computers worth. These InteGRiD based applications are used for a mixture of 3 reasons: multi-tasking; ease of use; and special features. OS/2 certainly meets the multi-tasking requirement, more reliably and flexibly than InteGRiD, though with enough more overhead that a 16Mhz 80386SX seems the minimum acceptable platform. OS/2 has the capability to meet the ease of use requirements, though many of these users' environments are poor candidates for a pointing device, making a keyboard driven user interface necessary. The special features divide into the half duplex and related capabilities of GRiDTerm, and the much more specialized features of the various custom packages we have written. Almost certainly, we will not embark on porting any of these communications packages to OS/2 unless paid to do so. However, we (the federal Systems Development group) must start our abandonment of InteGRiD sometime, the sooner the better, and we need a place to migrate to. Under OS/2, we could hopefully find a terminal emulator with many of the special features of GRiDTerm, sparing us porting that over. To summarize, there has historically been a significant amount of custom development work in the federal sector, and and we need a multi-tasking platform to replace InteGRiD for this work. Another possible use for OS/2 is as part of a Tempest network server based on the 1537. The 1537 could make a decent portable Tempest network server. The problem is to find the right software and hardware parts to assemble around it. A LAN-OS is one of the hardest parts to fit, primarily because of device support needs. We would need to support the SCSI disk and tape, and possibly the RS422 serial port. Of the big 3 LAN OS's, the best choices appear to me to be 3Com 3+, which uses MS-DOS device drivers, and 3Com 3+ Open, which uses OS/2 device drivers. We will be getting some or all of these drivers in due course, as opposed to having to develop custom drivers for Vines or Netware. 3+ Open is my preference, since we could cleanly support the SCSI disk and (hopefully) tape, and the RS422 serial port, through OS/2 drivers. Also, 3+ Open sounds like the best platform for developing server-resident value added software on. Will