Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: Serial port expansion Message-ID: <3126@cbmvax.UUCP> Date: 11 Jan 88 22:29:52 GMT References: <4918@well.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 66 in article <4918@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) says: > Unit 0 should remain the internal serial port. Units 1 - MAXINT > should represent external ports. Exactly which ports they'd be would be > vendor-specific. The hardware expansion would come with a disk with an > installation program. The installation program would do the following: > Find the existing serial.device file in the DEVS: directory. Rename > the file to something else (intser.device?), and patch the file itself to > reflect this change. Next, copy into DEVS: the new serial.device, which > knows about the external ports. > This new serial.device also knows about the "old", renamed serial > driver. When a program opens the serial.device, the vendor's handler checks > the unit number. If it's zero, it opens the old one. The device would then > check subsequent I/O transactions to see if they are intended for unit zero. > If so, it just re-posts the transaction to the original driver, who will > process it and return it to the calling program. This sounds OK, except for two possible problems. The first one of these is the case of multiple add-on serial cards (OK, so I'm getting extreme, but someone has to). If they're of the same vendor, there's a good chance that they'd cooperate OK with his special "serial.device". If they're of two different vendors, there's a good chance that there will be a conflict, since there's no good way for each driver to tell the other what unit number it's up to. The other problem involves how "L:Port-Handler" talks to the serial.device. In the ideal case, I'd like to be able to add my additional serial devices in my MountList. Thus, I can deal with any number of vendor boards if I need to, and I'm not going to have any special problems dealing with a serial device that's not called "serial.device". And I can name my new serial ports MODEM:, VAX:, and PC: if I so desire, and then I never have to worry about what's connected to what. And neither does the novice user. A terminal program that supports multiple serial devices accepts the DOS name of the device on the command line, or as a TOOLTYPE. The program gets the device and unit designation from the DOS name, so it has the device abstraction afforded by DOS, plus the speed of directly acting on the EXEC level device and unit. Only, that only really seems to work for filesystem devices. The DOS device list stores the SER:, PAR:, and PRT: devices, but has no obvious link to an EXEC level device for such items. It does reference the "L:Port-Handler", but each of these devices is magically hardwired into the port handler. That makes add-on ports much more complicated, and much less general. > I project that this would slow down internal device transactions > minimally, and is sufficiently transparent that it wouldn't cause anything > untoward to happen. The only icky thing I can think of is that IOF_QUICK > transactions might get mucked up. Wouldn't this only slow up the initial opening of the device? My special, new serial.device sees a request for unit zero coming in. So it supplies the same information that the standard, unexpanded machine would for use of the standard serial.device. The device name is only meaningful to the OpenDevice() call. > Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ > \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac > O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") > "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"