Hi Bill, Thanks for you help! I will say that I have the getty running fine, baud rate, serial format, etc. all okay. Works just fine at 1200 baud and below. At higher baud rates, it seems like the vt100 is dropping some characters or bits after certain escape sequences, even with xon/xoff flow control enabled, so I?m *pretty* sure the issue is just with the padding values in the vt100 terminfo spec? To answer your question, though: since this is Ubuntu 16.04, systemd based, it runs agetty, and has no inittab. The sorta equivalent under systemd is serial-getty at .service, which on my system looks like what is posted below. I?ve also posted the effective terminfo (from infocmp) below that. cheers, ?FritzM. ---------------- snip ----------------------------------------------------- # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Serial Getty on %I Documentation=man:agetty(8) man:systemd-getty-generator(8) Documentation=http://0pointer.de/blog/projects/serial-console.html BindsTo=dev-%i.device After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service After=rc-local.service # If additional gettys are spawned during boot then we should make # sure that this is synchronized before getty.target, even though # getty.target didn't actually pull it in. Before=getty.target IgnoreOnIsolate=yes [Service] Environment=TERM=vt100 ExecStart=-/sbin/agetty --keep-baud 115200,38400,19200,9600,4800,1200 %I $TERM Type=idle Restart=always UtmpIdentifier=%I TTYPath=/dev/%I TTYReset=yes TTYVHangup=yes KillMode=process IgnoreSIGPIPE=no SendSIGHUP=yes [Install] WantedBy=getty.target ---------------- snip ----------------------------------------------------- # Reconstructed via infocmp from file: /lib/terminfo/v/vt100 vt100|vt100-am|dec vt100 (w/advanced video), am, mc5i, msgr, xenl, xon, cols#80, it#8, lines#24, vt#3, acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>, clear=\E[H\E[J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C$<2>, cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA, cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, el1=\E[1K$<3>, enacs=\E(B\E)0, home=\E[H, ht=^I, hts=\EH, ind=^J, ka1=\EOq, ka3=\EOs, kb2=\EOr, kbs=^H, kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy, kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, lf1=pf1, lf2=pf2, lf3=pf3, lf4=pf4, mc0=\E[0i, mc4=\E[4i, mc5=\E[5i, rc=\E8, rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmam=\E[?7l, rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>, rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7, sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;$<2>, sgr0=\E[m\017$<2>, smacs=^N, smam=\E[?7h, smkx=\E[?1h\E=, smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,

Fritz Mueller wrote: I've got a VT102 Video Terminal User Guide (EK-VT102-UG-003) which contains a table of fill characters required for different control codes / escape sequences / display characters at each possible baud rate. Here's what it lists for 19200 baud: 324 IND, LF, NEL, RI (Smooth Scroll) 191 DECCOLM 190 DECALN 144 ED (132 Col) 104 ED (80 Col) 32 IND, LF, NEL, RI (Jump Scroll) 6 EL (132 Col) 4 EL (80 Col) 7 DECINLM 2 All others except RIS and DECTST The appendix also seems to hint that the VT100 has different requirements so this may not be very useful to you but it might give you a rough idea. Regards, Peter Coghlan.

On 06/09/2016 09:43, Fritz Mueller wrote: I've had that problem with a printer and a double-buffered UART. As near as I could determine, the printer waited to send XOFF until there was only one or maybe two characters free in its software buffer, but by that time there was one char in transit, one more in the printer's receiver buffer register and another in the computer's UART's transmitter buffer register. That's at least one too many :-) -- Pete Pete Turnbull

Generally, DEC didn't have hardware flow control at that time because it was not in the standard. I'm pretty sure there was no hardware flow control available on the VT100. It used XON/XOFF. Regards, Peter Coghlan.

Warner Losh wrote: I may be misremembering too but my feeling is that it was much later on than that even when DEC only reluctantly began to offer RTS/CTS hardware flow control on terminal servers in order to support "high speed" async modems. As far as I recall, big bunches of serial ports on a VAX etc had gone away in favour of network attached terminal servers before that time and I don't think the directly attached serial ports ever provided hardware flow control. They could optionally provide "modem control" though, in that they could signal a modem to hang up and the modem could signal the machine that a connection had been established or gone away. I had a look in the VT102 guide and it explicitly says that there are only three ways of avoiding buffer overruns - XON/XOFF, fill characters and using a lower speed. On the other hand, it also says that the VT102 printer port can respond to DSR being dropped by stopping sending characters to it. It suggests that the printer can drop DTR when it's buffers are full and this should be wired to DSR on the terminal printer port so there is hardware flow control available there at least. Regards, Peter Coghlan.

On Tue, Sep 6, 2016 at 11:07 AM, Paul Koning <paulkoning at comcast.net> wrote: We never had luck with it on VAXen and hundreds of feet of wire in the 1980s, but we _did_ have 100% rock-solid performance at 9600. Of course, we also had few genuine VT100s as opposed to VT101, VT102, VT220, and CiTOH 101 terminals. I do recall that the real, original VT100 was _not_ as capable as any of its predecessors, supporting the recent comments in this thread about "not the same as a VT102". I would agree. I never had to fiddle any sort of padding characters (on non-printing/CRT devices). Our oldest terminals _were_ the original VT100, and probably represented at most 5% of our installed terminals. -ethan

No, that's a matter of what next step modulation scheme had become feasible. It's possible to imagine incompetently designed UARTs that do odd things. But given a normal UART, the first step it performs is to frame the character and the bits. That depends on an adequate signal, and a sufficiently accurate clock. After that step, you have a received character which should be correct. Next, that character has to be buffered and delivered to the consuming system. That probably involves a FIFO, and either an interrupt or DMA. If there is no room to buffer the character, it will be discarded, hopefully with a status in the UART registers to indicate that. But either the character will be buffered as received, or not at all -- it would not be modified at this point. Finally, if an XOFF is received, it has to be seen by the element that acts on it (either something in the serial port hardware, or the driver, or the application software) which has to stop the output stream. If that takes too long, or the output buffers beyond the stop point are too large, too many characters may get out after the XOFF was sent. That would generally cause a buffer overflow, which will drop characters as described above but will not modify them. You mean at the USB level? Or in a computer serial port? If the latter, the only timing issue I can think of would be baud rate clock issues. BTW, a serial port baud rate generator is a programmable divider. The range of speeds supported has changed over time; early on it was 110 to 9600 (or sometimes lower, say 110 to 2400). The clock crystal was chosen to deliver "sufficiently accurate" frequencies, taking into account the way the bit framing was done in the particular UART design. Some of those generators could do 19200 baud as well but that was often not supported because there the frequency was off too much. If you used it anyway, and both ends use the same generator, all would be well. You might be doing 19,900 baud rather than 19,200, but that's ok so long as the ends agree. But newer serial ports have a much higher upper limit, which means they have a higher frequency crystal and the individual error values for the individual speeds will be different. For the ones that were in spec all along that should not be an issue; for ones that were out of spec, it probably would be. paul

On Tue, Sep 06, 2016, Cameron Kaiser wrote: Not quite; someone named Daniel Dallmann found a way to do it on the user port, on both 64 and 128 (in the 1990s, I think). It's commonly called "UP9600". I've only found one terminal program* so far that actually performs well and doesn't drop characters or bring up garbage ones, on the device I mentioned (I have never tried it with a proper modem). I'm not sure what's different about the CIAs in the 64 and 128 but, in the case of this specific hack, it's theoretically easier to deal with a 64 -- or at least a 128 with no 1571 or 1581 -- because the 9600bps hack clobbers the SRQ line that those drives use for fast serial operations. (Things still work if you turn them to slow mode, as happens when you boot directly into 64 mode.) But I find that I never get it to work non-problematically except when I use that one terminal emulator using the C128's VDC for display. I'm not sure how much the 40-column mode's 1MHz clock contributes, and how much VIC emulated 80-column mode and the VIC's scrolling speed, contribute to the problem. (Will have to try it with true 40-column mode, but then the actual viewport will fill with characters and need a scroll twice as fast.) * The terminal emulator I've had success with is NovaTerm 9.6. I wish I could get more than one-sentence responses from the developer of the device. Hopefully he'll fix it in the future, if I can make a good case for it. -- Eric Christopherson

On Tue, Sep 06, 2016, Eric Christopherson wrote: I see a few mentions online about the 128 supporting 9600 natively, but no real details. Do you have any to share? I wonder if it'd be worth turning off the device's UP9600 support and seeing if the 128 will still talk 9600 to it. (If I do keep it on, apparently the 128 will be able to do 19200 -- but I'm not holding my breath, based on my experience with 9600.) -- Eric Christopherson

On Tue, Sep 06, 2016, Cameron Kaiser wrote: Supposedly the CommodoreServer.com service is capable of 38400 -- on an unmodified 64. I haven't gotten it to work yet (though the WiModem is supposed to be capable). -- Eric Christopherson