Path: utzoo!utgpu!water!watmath!clyde!rutgers!ll-xn!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!imagine!pawl17.pawl.rpi.edu!jesup From: jesup@pawl17.pawl.rpi.edu (Randell E. Jesup) Newsgroups: comp.sys.amiga Subject: Serial port expansion Message-ID: <197@imagine.PAWL.RPI.EDU> Date: 6 Jan 88 08:29:43 GMT Sender: news@imagine.PAWL.RPI.EDU Reply-To: beowulf!lunge!jesup@steinmetz.UUCP Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 117 [This is a piece of mail I recieved from Bryce re serial port expansion. ] [I am posting this response to both usenet and bix, as the issues raised here] [are important to all developers and users. His text is '>', mine is the ] [rest. Note - Bryce's text is all here. REJ ] > Just a quick note to let you know what is going on: > > I am *at this moment* implementing a multiple serial port controller. The > first hardware is due out 1Q 88, I believe. The software should pre-date > this. > > More docs will be made available soon. Once it is out *every* hardware > manufacturer will have equal access to the materials. Things are still > a bit rubbery, in case changes need to be made. I like this idea in theory. However, I still disagree with your implemetation, and other serial manufacturers may also. > I should have direct BIX access in 2-3 weeks. Good. All you need is a MC/Visa and a phone call (see byte). > The serial.device changing priority is *not* a problem. My driver can link > ahead of it no matter what it's priority, just by insterting at the head > of the list. Besides, Commodore is not planning on changing the serial > device for V1.3 or V1.4 (they don't have anyone to do it; this comes from > both bart and jimm). The real problem is not the priority, but how it is mounted: How can you have two serial.devices in the devs: directory? You can't, of course. You can link in drivers before the regular serial.device by running a program, but this is NOT the same as OpenDevice("serial.device",...). Remember the Amiga device scheme is set up for LOADABLE, dynamic devices. They aren't loaded until needed, which is part of their beauty. So, now, one more time I'll make my point: The one and only thing needed to handle any number of serial ports is a name-mapping utility. If a scheme is based on assigning unit numbers according to when they register with your high-priority serial.device during binddrivers, there are several problems: 1. The unit numbers will depend on the order in which they register. This means it will not neccesarily be the same from one boot to the next, and the user will have no means but experimentation to figure out which unit is attached to what. 2. Your device must be loaded and have created it's port before binddrivers is executed, it opens the old serial.device, AND each driver that registers MUST (of course) be in memory to register. Therefor, all the serial drivers end up in memory always (longer boots (PLEASE NO!), less memory, more disk grinding). My contention is that all one needs is a name-mapper, that maps what thing (modem, laserwriter, whatever) you want to open to a device and unit number. If you read my last posting there is a long explanation of this. > Thanks for echoing BIX <---> USENET. Both sides of that fence should have > a say in this. Certainly. However, for things that mainly involve developers and Commodore itself, I feel you should have said something on bix OR usenet before you did. Your first message (that I replied to on usenet, pointing you at the ongoing conversation on bix) implied 'that since no one else is doing anything about it, I decided that I should, and here it is.' > You comments are appreciated! The only comment of yours that has me > baffled is the one about not wanting the drivers to be loaded ahead of time. > Just how would you propose NOT having at least something loaded? Remember > that my design goal is multiple serial ports from multiple manufactueres > all on one machine. Maximum user installation must be "clicking or dragging" > an icon. It's easy to come up with a design that doesn't require any of the serial drivers to be loaded until they are opened. All you need is a name- mapper that knows about the entries you've dragged over. Of course, you can customize them as well (for example, the microbotics serial card might default to MB_Serial_1 and MB_Serial_2. If you installed a modem on the second port, you could either keep calling it MB_Serial_2, or you could double-click on the 'Serial Names' icon that came with this new wonderful multi-serial port handling software, and tell it MB_Serial_2 is also a Modem, and a Modem_2400. One of the advantages of this scheme (using name-mapping INSTEAD of higher unit numbers) is that installing another board won't affect anything you have already set up. As I have said, it requires no more work for those writing programs than adding higher unit number support does. (See my last message) You said yourself you planned to have a name-mapper, that maps names to unit numbers. If you have that, why not something that maps names to device/unit number pairs? I think no user should EVER have to care about unit numbers, just about what piece of hardware they attached to which board. Terminal programs would default to opening 'modem', which of course the user could change. This way, when the user got a new program that uses a modem, he wouldn't have to tell it he always uses unit 3 as the modem, but just runs it (assuming he bothered telling the system at some point that that piece of hardware was connected to a modem, otherwise he tells it MB_Serial_1 or whatever.) Once he's told it once that there's a modem there, he doen't have to worry about configuring every piece of software. (Or worry about changing the configurations when he adds a new board or causes the order in which binddrivers reads the files in the expansion drawer to change.) I'm sorry if I go on at length, but I feel strongly about this, as I suspect whatever we come up with will be around a long time. And once again, even if I seem derisive, I'm just trying to make some points. I thought I had explained them sufficiently in my last message, so I'm being a bit more explicit in my criticisms. Bryce: Call microbotics ASAP. They are also doing a serial port (and other things) board right now, and you should talk to them. Talk to Redmond Simonsen, who has been following this on Bix. ---------------------------------------------------------------------------- Randell Jesup, Lunge Software. (518) 272-2942 Bix: rjesup usenet: beowulf!lunge!jesup@steinmetz.UUCP // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)