vt100 terminfo with padding for an actual vt100?

[Paul Koning]

> On Sep 6, 2016, at 7:18 PM, Eric Christopherson <echristopherson at gmail.com> wrote:
> 
> On Tue, Sep 06, 2016, Paul Koning wrote:
> [...]
>> 19200?  I didn't think the VT100 supported that.
>> 
>> You've got to be careful with that setting, even on devices that claim
>> to do it.  When it first appeared, it was often a "just barely
>> possible" setting on the clock generator, with an actual bit rate off
>> a couple of percent from the correct value.  If both ends used the
>> same clock generators, no problem of course.  But if one end uses an
>> accurate one, you may get framing errors.
> 
> Is this why modems went to 14400 instead of 19200?

No, that's a matter of what next step modulation scheme had become feasible.

> [...]
>> On the other hand, flow control issues do not result in "garbage"
>> characters.  The only way you'd get what looks like garbage is if
>> escape sequences are corrupted so a portion of that sequence is
>> mistaken for text.  If you see garbage in a full screen editor, that
>> could be the reason.  On the other hand, if you're just sending a
>> large document to the screen and you're seeing garbage, flow control
>> is not the cause.
> 
> Interesting. I've been trying to get a WiFi device for the Commodore
> 8-bits working consistently in 9600 bps mode, and have just been
> assuming the garbage characters I get when I receive a screenful of text
> all at once were due to buffer overruns. The garbage characters there
> look like actual garbage, not like partial CSIs like [3;1m or whatever.

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.

>> Earlier on there was some discussion about modern interface devices
>> with non-compliant "RS232" transceivers.  If your RS232 output is
>> marginal, that could cause garbage.  If the clocks are off, ditto.  An
>> oscilloscope could be used to test both those theories.
> 
> I wonder if it's a similar sort of timing issue between my device and
> the computer. I'll have to try a few computers and see if behavior
> varies.

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