izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/21/89)
> From: ar1@h.cc.purdue.edu (Norton Lam) > Message-ID: <4521@h.cc.purdue.edu> > 1) There does not seem to be any way to send a Break. Break *will* be included in the next release. > 2) I am having no luck with Eight bits, no parity--only garbage. Seven bits > even parity works fine, though. Any thoughts? This garbage appears at > all baud rates. The DOV system accepts either automatically, and Kermit > works fine either way. Perhaps the host is seven, even? I can assure you that DesTerm's word construction is correct. If the host doesn't like 8N from DesTerm, then I doubt it would like 8N from any other terminal. > 3) I have found that the program is reliable only up to 4800 bps. 9600 bps > is marginal. (Mr. Welsh, I assume you're reading this: is there any way > to tweak the 9600 setting for maximum performance?) (1) DesTerm's 9600 is already "tweaked for maximum performance". Our benchmark was the USRobotics Courier HST, which refused all other 9600 bps terminals for the 128 because they weren't accurate enough. Using a carefully calibrated oscilloscope for tweaking and the HST for verification, we chose our timing constants very carefully. We spent literally hundreds of hours determining the best code and constants... (2) The 128's hardware limitations (bugs in the CIA chip as much as the lack of a UART) make it *impossible* for true asynchronous 9600 bps to be reliable if the 128 must both send & receive at 9600. No amount of tweaking will allow true full duplex operation at 9600. If there is demand, I may implement statistical duplex operation at 19,200 bps, which should provide performance equal to full duplex 9600 on lines that recognize the appropriate hardware handshaking lines. > 4) The VT-100 emulation seems to have many bugs. Believe it or not, we implemented everything possible from the VT-102 manual. We are discovering VT-100 "features" not mentioned in the DEC manuals but used by some systems. > Are there plans to upgrade the emulation for a future release? Matt and I are plotting a new release before the end of the month. When we let 1.01 out the door, we knew there would be problems (it supported only Hayes-type modems, it didn't work well with the 1670, YMODEM (batch) downloads *could* force the modem o hang up, etc... but we wanted to get something out the door. We will be improving the product constantly (or we wouls not have asked people to send in money to register it). By the way, the cure to the YMODEM hang-up problem (and a help to 1670 compatiblity, though it does not cure all problems there), is to alter the main program with POKE 22211,44. > While I realize that many users won't be using this > program for micro <--> mainframe communications, for me it is CRITICAL > to have near-perfect VT-100 emulation. For us, too. We use DesTerm with vi under AT&T Unix Sys V release 3.1.1, and with EDT under VAX/VMS. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (04/24/89)
In comp.sys.cbm article <2091.244FF979@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: ] > 2) I am having no luck with Eight bits, no parity--only garbage. Seven bits ] > even parity works fine, though. Any thoughts? This garbage appears at ] > all baud rates. The DOV system accepts either automatically, and Kermit ] > works fine either way. ] ] Perhaps the host is seven, even? I can assure you that DesTerm's word ]construction is correct. If the host doesn't like 8N from DesTerm, then I ]doubt it would like 8N from any other terminal. Funny, I had troubles too. A local system I use constantly with 8N (UWM's Gandalf PACX network, on an MNP line) refused to work with DesTerm and 8N. I had to switch to 7E. And DON'T tell me it would not like 8N from any other terminal.... I'm using it right now. :-? ] > 4) The VT-100 emulation seems to have many bugs. Understatement. ] Believe it or not, we implemented everything possible from the VT-102 ]manual. We are discovering VT-100 "features" not mentioned in the DEC manuals ]but used by some systems. I ran into problems with 'sysline', and things went downhill from there. I suggest that you have Matt look at Kermit, which has a beautiful VT100 emulation that I rarely have problems with (I have more problems with some VT100's at school....) Also, check various releases of the VT100 manuals. You know DEC... ;-) ] > While I realize that many users won't be using this ] > program for micro <--> mainframe communications, for me it is CRITICAL ] > to have near-perfect VT-100 emulation. Forget "near perfect." Perfect is more important.... the last "near perfect" emulation I used sometimes goofed up where the cursor should be and I would mess up files while using my visual editor. HIGHLY unsatisfactory. Sorry, Geoff, but now I have another few comments to make. I really wasn't too thrilled with DesTerm, at least after DavesTerm 128. I didn't care for the way it was set up, I didn't care for all of the menus (a few too many, DesTerm makes even setting the word length and parity an exercise in menu selection.... I would rather be able to see on a single menu what the current options are, too!).... is my memory failing me, or is there actually a period after each menu entry? I do appreciate the attention to detail (did I see four "LED" status indicators on the top line?) but I don't like it. DavesTerm 128, while it still needs some work, is just as nice in most ways and much nicer in some ways. If Dave ever polishes it up, the only thing DesTerm will offer over it is speed. -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
dg@lakart.UUCP (David Goodenough) (04/25/89)
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) sez: ] ] > From: ar1@h.cc.purdue.edu (Norton Lam) ] > 2) I am having no luck with Eight bits, no parity--only garbage. Seven bits ] > even parity works fine, though. Any thoughts? This garbage appears at ] > all baud rates. The DOV system accepts either automatically, and Kermit ] > works fine either way. ] ] Perhaps the host is seven, even? I can assure you that DesTerm's word ] construction is correct. If the host doesn't like 8N from DesTerm, then I ] doubt it would like 8N from any other terminal. A distinct possibility - lakart runs all it's terminals (when not in raw mode) as 7E1, and we're a UN*X system. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/25/89)
> From: jgreco@csd4.milw.wisc.edu (Joe Greco) > Message-ID: <2206@csd4.milw.wisc.edu> > Funny, I had troubles too. A local system I use constantly with 8N > (UWM's Gandalf PACX network, on an MNP line) refused to work with > DesTerm and 8N. I had to switch to 7E. And DON'T tell me it would > not like 8N from any other terminal.... I'm using it right now. :-? I'm puzzled. I've never had trouble using any framing. Ideas as to source/cure are welcome! > I ran into problems with 'sysline', and things went downhill from > there. I suggest that you have Matt look at Kermit, which has a > beautiful VT100 emulation that I rarely have problems with (I have > more problems with some VT100's at school....) Also, check various > releases of the VT100 manuals. You know DEC... ;-) We're constantly finding new things about the VT-100, and Matt has already made a LOT of modifications to the code. > I didn't care for the way it was set up, I didn't care for all of the > menus (a few too many, DesTerm makes even setting the word length and > parity an exercise in menu selection.... I would rather be able to see > on a single menu what the current options are, too!).... is my memory > failing me, or is there actually a period after each menu entry? I do > appreciate the attention to detail (did I see four "LED" status > indicators on the top line?) but I don't like it. We've heard the menu layer gripe and we've added hot keys and a menu screen (activated by the HELP key). The dialing directory now supports the setting of every parameter imaginable, so you can configure your system for word framing, function keys, etc., all to switch in automatically on connect. > If Dave ever polishes it up, the > only thing DesTerm will offer over it is speed. "If Dave polishes it up"... we are working on DesTerm every day! -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/26/89)
> From: dg@lakart.UUCP (David Goodenough) > Message-ID: <512@lakart.UUCP> > izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) sez: > ] > From: ar1@h.cc.purdue.edu (Norton Lam) > ] > 2) I am having no luck with Eight bits, no parity--only garbage. Seven > ] > ] Perhaps the host is seven, even? I can assure you that DesTerm's word > ] construction is correct. If the host doesn't like 8N from DesTerm, then I > ] doubt it would like 8N from any other terminal. > > A distinct possibility - lakart runs all it's terminals (when not in raw > mode) as 7E1, and we're a UN*X system. Matt has come up with a more likely reason; because DesTerm handles PC graphics (hi-bit set), outcoming parity settings might be interpreted as graphics bits. The solution to this is to enable the "mask high bit" setting. As far as I'm concerned, "Mask high bit" is a short-cut that allows you to work with parity-based systems even if you don't know what parity they are (assuming they ignore incoming framing errors). Since you know 7E1 works, why not stick with it? DesTerm automatically switches to 8N1 for the duration of file transfers, so that isn't going to cause problems there. Geoff -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG
jgreco@csd4.milw.wisc.edu (Joe Greco) (04/27/89)
In comp.sys.cbm article <2178.24553F5E@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: ] > Funny, I had troubles too. A local system I use constantly with 8N ] > (UWM's Gandalf PACX network, on an MNP line) refused to work with ] > DesTerm and 8N. I had to switch to 7E. And DON'T tell me it would ] > not like 8N from any other terminal.... I'm using it right now. :-? ] ] I'm puzzled. I've never had trouble using any framing. Ideas as to ]source/cure are welcome! It looked 'zactly like what happens when I try to run Kermit 2.1 at 2400 baud. ] We're constantly finding new things about the VT-100, and Matt has already ]made a LOT of modifications to the code. Please don't forget VTquirks. An emulator that emulates quirks correctly is priceless! (Especially since I've seen software relying on them, once in a while.) ] We've heard the menu layer gripe and we've added hot keys and a menu screen ](activated by the HELP key). The dialing directory now supports the setting of ]every parameter imaginable, so you can configure your system for word framing, ]function keys, etc., all to switch in automatically on connect. Good... I seem to recall having some problems with the dialing directory. The real problem is getting un-used to whatever program you are already used to.... ;-) ] > If Dave ever polishes it up, the ] > only thing DesTerm will offer over it is speed. ] ] "If Dave polishes it up"... we are working on DesTerm every day! As it stands, I am more impressed by DavesTerm 128 than I am by DesTerm. Sorry, Geoff. There is a "feel" that Dave has managed to give to his program that DesTerm doesn't quite have. Dave's work on DavesTerm 128 has been VERY thorough, from what I've seen. I remember his DavesTerm 64, which offered 80 columns, a 20? 30?K editable buffer (with an editor that was nicer than BTPRO), support for the Volks 6480 even.... I only had about 20 minutes to run each program on a 128, so I can't make any earth shattering revelations. I did hear that he was calling a local Apple system and using some kind of Apple terminal emulation (does Datamedia or ProTerm ring any bells?).... it also has a hi-res picture viewer that can apparently load/save/view pictures in RLE format (perhaps even GIF) and several common Commodore formats. Another "module" is a disk editor / directory editor. Somehow that seems a little irrelevant, but I can already think of times I could have used it. I guess a future project will be some kind of "script" language to replace the BTPRO style macro system he has right now. In any case, it all matters very little to me since I don't regularly use a 128. I tried calling csd4 (here) with both programs, and neither was able to handle the "strenuous" VT100 emulation, so I went and loaded up old, reliable, faithful Kermit. (oh I love throwing kindling on the fire... hehe) -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)
ross@ziebmef.uucp (Ross Ridge) (04/30/89)
In article <2206@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes: >In comp.sys.cbm article <2091.244FF979@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote: >] > 2) I am having no luck with Eight bits, no parity--only garbage. Seven bits >] > even parity works fine, though. Any thoughts? This garbage appears at >] > all baud rates. The DOV system accepts either automatically, and Kermit >] > works fine either way. >] >] Perhaps the host is seven, even? I can assure you that DesTerm's word >]construction is correct. If the host doesn't like 8N from DesTerm, then I >]doubt it would like 8N from any other terminal. > >Funny, I had troubles too. A local system I use constantly with 8N >(UWM's Gandalf PACX network, on an MNP line) refused to work with >DesTerm and 8N. I had to switch to 7E. And DON'T tell me it would >not like 8N from any other terminal.... I'm using it right now. :-? Well, I can probabably guess what the "problem" is. Most terminals tend to treat 7E and 8N the same way, they ignore the high order bit. My guess is that DesTerm, treats these differently and displays a special character for char's above 127. Your network maybe be 8N, but your host computer may still be using 7E (this is the case with the University of Waterloo's Sytek and Gandalf networks.). >] > 4) The VT-100 emulation seems to have many bugs. > >Understatement. > >] Believe it or not, we implemented everything possible from the VT-102 >]manual. We are discovering VT-100 "features" not mentioned in the DEC manuals >]but used by some systems. > >I ran into problems with 'sysline', and things went downhill from >there. I suggest that you have Matt look at Kermit, which has a >beautiful VT100 emulation that I rarely have problems with (I have >more problems with some VT100's at school....) Also, check various >releases of the VT100 manuals. You know DEC... ;-) Having written a terminal programme that can emulate the VT100 pretty well, I know how easy is it is to goof it up. Things like how handle ESC[r, end of line, scrolling, and host of other sometimes obvious looking items are easily botched. There are thousands of programmes out there that have failed to do it properly, so don't give Geoff too hard of a time. I used the ANSI X3.64-1979 standard to write my terminal programme (it's an ANSI conforming terminal programme, with VT102 additios.) For VT102 emulation I actualy used a Rainbow manual. It turned out to be better than the VT series manuals I've seen. >] > While I realize that many users won't be using this >] > program for micro <--> mainframe communications, for me it is CRITICAL >] > to have near-perfect VT-100 emulation. > >Forget "near perfect." Perfect is more important.... the last "near >perfect" emulation I used sometimes goofed up where the cursor should >be and I would mess up files while using my visual editor. HIGHLY >unsatisfactory. Perfect emulation isn't really needed, the full VT100/102 command set need not be implimented, but the ones that are have to be done perfectly. My own terminal which leaves out a fair bit, works perfectly with Unix (at least anything that uses termcap/terminfo), because it knows what to do at the end of a line, not because it supports double height/width characters. Ross Ridge P.S. I'm not really trying to "push" my own terminal. I don't distribute it, nor do I think it's a perfect VT100 termnial, it's just a programme I wrote because there is nothing for a 64 with a BI-80. -- l/ attcan!tmsoft!ziebmef!ross // [OO] [oo] -()- -()- db 6502 assembly forever! //
jgreco@csd4.milw.wisc.edu (Joe Greco) (05/03/89)
In comp.sys.cbm article <1989Apr29.174422.4573@ziebmef.uucp>, ross@ziebmef.UUCP (Ross Ridge) wrote: ]Well, I can probabably guess what the "problem" is. Most terminals ]tend to treat 7E and 8N the same way, they ignore the high order bit. ]My guess is that DesTerm, treats these differently and displays a ]special character for char's above 127. Your network maybe be 8N, but ]your host computer may still be using 7E (this is the case with the ]University of Waterloo's Sytek and Gandalf networks.). Wonderful, first thing I have to do is wade through the less than friendly communications parameters selection menus. heheheheh.... you may be right. ]Having written a terminal programme that can emulate the VT100 pretty ]well, I know how easy is it is to goof it up. Things like how handle ]ESC[r, end of line, scrolling, and host of other sometimes obvious ]looking items are easily botched. There are thousands of programmes out ]there that have failed to do it properly, so don't give Geoff too hard of ]a time. Which are all important. I do not appreciate bugs that cause me to lose data. On the other hand, I am also a software author and I *do* understand just how easy it is to botch things. I just do not appreciate seeing buggy software released. And why can't I give Geoff a rough time? It's almost fun to ruffle him a little. ;-) ]I used the ANSI X3.64-1979 standard to write my terminal programme ](it's an ANSI conforming terminal programme, with VT102 additios.) For ]VT102 emulation I actualy used a Rainbow manual. It turned out to be ]better than the VT series manuals I've seen. DEC always did have interesting manuals. ]>Forget "near perfect." Perfect is more important.... the last "near ]>perfect" emulation I used sometimes goofed up where the cursor should ]>be and I would mess up files while using my visual editor. HIGHLY ]>unsatisfactory. ] ]Perfect emulation isn't really needed, the full VT100/102 command set ]need not be implimented, but the ones that are have to be done perfectly. ]My own terminal which leaves out a fair bit, works perfectly with Unix ](at least anything that uses termcap/terminfo), because it knows what ]to do at the end of a line, not because it supports double ]height/width characters. I'm not asking for dh/dw characters. I'm also not asking for LED status indicators (especially when the basics are still buggy). If my local UNIX can know where my cursor is at all times, I will be happy. This is not a heck of a lot to ask when using error correcting modems on both ends. In other words, I agree. On the other hand, the more implemented, the better. I have vt100 termcap entries that will make my visual editor crawl because certain features are not listed as "implemented," and others that implement a few "special" features and make things fly. But only if the emulator emulates them. :-) ]P.S. I'm not really trying to "push" my own terminal. I don't ]distribute it, nor do I think it's a perfect VT100 termnial, it's just ]a programme I wrote because there is nothing for a 64 with a BI-80. What do you call C64KERMIT? It works very well with a BI-80, thank you very much (and I wouldn't try a VT100 emulation on a 64 without it, although KERMIT does an admirable job trying.... just can't keep up). By the way, has anybody successfully make c64kermit run at 2400bps? -- jgreco@csd4.milw.wisc.edu Joe Greco at FidoNet 1:154/200 USnail: 9905 W Montana Ave PunterNet Node 30 or 31 West Allis, WI 53227-3329 "These aren't anybody's opinions." Voice: 414/321-6184 Data: 414/321-9287 (Happy Hacker's BBS)