ews00461@uxa.cso.uiuc.edu (02/03/90)
I simply want to dump a text file to the serial port at 9600 baud or so. My reading of IM II makes this look rather simple, but I *think* I'm having overflow errors on some buffer. After opening the driver and the text file, I read a buffer full from the text file. The number of characters I read here is one parameter I have tried to vary (any suggestions?). Then I FSWrite this buffer to the serial port and go back through the loop immediately. Is there some way to check to see if the port is actually ready for another block of data ? My problem manifests itself through a nasty beep from the printer (a DecWriter) and garbage text later in the printout. I opened the Driver through OpenDriver, not RamSDOpen. I am using the modem port. My program works fine for small files. Thanks in advance... Eric W Sink e-sink@uiuc.edu
minow@mountn.dec.com (Martin Minow) (02/04/90)
In article <227700053@uxa.cso.uiuc.edu> ews00461@uxa.cso.uiuc.edu describes
a problem dumping a text file to an attached serial printer at 9600 Baud.
The printer "beeps" and garbage is printed.
I would guess that the printer is trying to XOFF the Macintosh and the
Mac isn't responding to the XOFF (or is responding too slowly). You might
try looking at the serial line setup parameters (SerHShake on IM II-251).
Off the top of my head, you should set the SerHShake parameter block to:
fXOn true -- DECwriter can XOFF host.
fCTS false (but check the DECwriter manual and cabling)
xON ('Q' & 0x1F)
xOff ('S' & 0x1F)
errs 0
evts 0
fInX false -- Mac can't XOFF the DECwriter
null 0
Note: fCTS requires hardware/firmware support in the DECwriter and a cable
that passes the correct signals. I have no idea if that's possible.
Also, I *think* I have fXOn and fInX correct: you want the Mac to react
to XOFF/XON sent from the DECwriter, but don't want the Mac to send these.
Also, if the DECwriter engineers used the same algorithm I used for DECtalk,
it should be able to accept about 1/4 second worth of text after sending
an XOFF.
Hope this helps.
Martin Minow
minow@thundr.enet.dec.com
The above does not represent the position of Digital Equipment Corporation