gnu (01/05/83)
Martin Levy's message on how well the SmartModem works just points up the dichotomy. If you raise DTR, set settings, dial, converse, and drop DTR to hang up, of course it works -- hopefully they test the things. It's if you want to change settings while in the middle of a call -- like speed, or parity, or flow control, or 7-bit/8-bit, that you run into trouble. I have NO personal experience with SmartModem. But I implemented PCNet on the Apple II with DC Hayes Micromodem, and found the same thing. If you don't do anything the designers didn't do themselves, you won't get burned. Maybe I was the first to install that jumper, but if you turn interrupts on (it takes soldering! but is documented), you get continuous interrupts for the entire duration of each ring of the phone. (This typically crashes whatever program was running, unless it knows how to deal with the interrupts.) Clearly the designers never considered the possibility that someone might want to use this capability -- or they never debugged it themselves. (It took us about 5 wires on the board to hook up a spare AND gate and make it software controllable, but we couldn't expect PCNet users to have to modify their boards, so couldn't use the feature and thus couldn't run full duplex.) I can well believe that, say, trying to switch from 300 to 450 or 600 baud in mid-call -- as PCNet likes to do if its 300 baud conversation reveals that the other end can also handle it -- would give the SmartModem fits. It's nothing that the components of the SmartModem couldn't (necessarily) handle, it's just bad global design. John Gilmore, Sun Microsystems