AJ@IBM-B.RUTHERFORD.AC.UK (Andrew Jessett) (06/12/91)
We have users who wish to use FTG Data Systems EMU-TEK Tektonix emulation
software over PC/TCPs TNGLASS using int14. When we try this some of the
data is lost or corrupt. Using EMU-TEK via a serial connection works fine.
Using MS-Kermit Tektronix emulation also results in similar errors.
I have also tried the Waterloo TCPPORT in place of TNGLASS with similar
results.
Running EMU-TEK across a differnt protocol (Pinkbook) works OK.
Does anyone out there have experience of using these or other emulators
via INT14 redirectors and can suggest what we might be doing wrong?
Andrew Jessett Internal ext. 5659
DDI 0235 44 5659
Rutherford Appleton Laboratory
Central Computing Department
Software and Devlopment Division
Communications & Small Systems Group
Didcot, Oxfordshire, England.jrd@cc.usu.edu (Joe R. Doupnik) (06/13/91)
In article <9106120816.aa05135@louie.udel.edu>, AJ@IBM-B.RUTHERFORD.AC.UK (Andrew Jessett) writes: > > We have users who wish to use FTG Data Systems EMU-TEK Tektonix emulation > software over PC/TCPs TNGLASS using int14. When we try this some of the > data is lost or corrupt. Using EMU-TEK via a serial connection works fine. > > Using MS-Kermit Tektronix emulation also results in similar errors. > I have also tried the Waterloo TCPPORT in place of TNGLASS with similar > results. > Running EMU-TEK across a differnt protocol (Pinkbook) works OK. > > Does anyone out there have experience of using these or other emulators > via INT14 redirectors and can suggest what we might be doing wrong? > > > Andrew Jessett Internal ext. 5659 > DDI 0235 44 5659 > Rutherford Appleton Laboratory > Central Computing Department > Software and Devlopment Division > Communications & Small Systems Group -------------------------- Andrew, I'll take a guess since these things (TNGLASS w/Kermit and Waterloo's TCPPORT w/Kermit). The guess is the host is sending some 8-bit characters, though why it would do this to a Tek 4000 series device is a mystery. TNGLASS, at least, uses a 7 bit channel. The second guess, if I can squeeze in another, is flow control is lacking at the host end. Graphics stuff is pretty time consuming to perform, and even so Kermit is using direct hardware manipulation in assembler to get there. Similarly, if you have some other TSR stuff (including and especially DOS's PRINT) they will consume cpu cycles in unfortunate ways. However for a network connection that should make little to no difference aside from the time delays (hence the flow control effect yet again). Joe D. > Didcot, Oxfordshire, England.