declan@portia.Stanford.EDU (Declan McCullagh) (08/20/90)
In an earlier message, Mark Adler (madler@piglet.caltech.edu) writes... >Paul is quite correct---this is a case where the calculator does not >respond to xon/xoff flow control. I posted my question aware of that, >with the belief that my NeXT should be able to keep up with the >incredibly low rate of about 1000 characters per second WITHOUT having >to slow down the source to less than that. It seems clear to me that >the hardware is more than capable of that, and that the serial drivers >are not getting the resources they need (physical memory? cpu?) to do >the job. By the way, this is when the computer is not engaged in any >other activities (at least no others that I've requested, and I'm the >only user). Also, Kermit transfers from my calculator also experience >an undue number of packet failures and 9600 bps, and I suspect that >the cause is the same: lost characters in long continuous >transmissions (in this case, long is only about 100 or so characters, >the length of a packet before Kermit wants an acknowledge). >I hope that NeXT has tried to improve or is improving the serial >drivers for version 2.0. This is a sterling example of one of NeXT's unresolved problems. To the best of my knowledge, there is still no DMA channel reserved for the serial ports, even though one was promised (to me, as a developer) for NextStep v1.0 as early as July 1989. I don't think one will be in NextStep v2.0, either. I've talked to people at NeXT about it, and the responses vary. Some of them mention the 56001's SCI (serial communication) and SSI (synchronous serial) interfaces as possible solutions. Some are rather defensive about it. The majority frankly acknowledge that it is a problem, but say they don't know when it will be solved... The lack of hardware flow control and the lack of faster serial port speeds are serious faults with the current machine; I hope that NeXT will find the necessary resolve to fix them. -Declan ------------------------------------------------------------------------------ Olympic Technologies / Registered NeXT Developers \ declan@portia.stanford.edu ------------------------------------------------------------------------------
davis@groucho.ucar.edu (Glenn P. Davis) (08/22/90)
I don't where all this serial port whining is coming from. We have a daemon that catches 9600 baud data from a satellite reciever, (no flow control) and it works fine on the NeXT. NeXT supplies a MIDI driver that runs over the serial chips. Midi is ~33kbaud (?) and definitly not flow controlled. Try doing that on your Sun. The fellow who was having problems with his HP calculator might want to grab unidata.ucar.edu:sdm/src/ldm2/tty.c via anonymous ftp as a example. Glenn P. Davis UCAR / Unidata PO Box 3000 1685 38th St. Boulder, CO 80307-3000 Boulder, CO 80301 (303) 497 8643