Fair price and ways to find a teletype

[Brent Hilpert]

On 2015-Oct-15, at 10:19 PM, Chuck Guzis wrote:
> On 10/15/2015 10:06 PM, Brent Hilpert wrote:
> 
>> For working form modern equipment, the bit rates for all of them are
>> potentially awkward. When working on the 28s, which were geared for
>> 75 bps, I lucked out as I found the USB-serial interface I was using
>> could do 75 bps - not entirely surprising as 75 is a factor of 2 down
>> in the common 9600,1200,300 bps series. How many USB-serial
>> interfaces are capable of this I have no idea. Regardless, the baud
>> rates are slow enough that bit-banging from a program is not
>> difficult, or an adjustable RC oscillator to a UART should do.
> 
> These were more common in the 8-bit area.  Typically, a Z80 machine would involve a CTC and DART, so you could set the CTC count/divide for any reasonable rate needed.
> 
> This is probably the case also for many current MCUs that feature a built-in UART/USART or even designs using the Intel 8251--which often would be fed by an 8253/54.   I believe the x86 "microcontrollers" such ash the 80186EB or NEC V20/V30 would also qualify.
> 
> For PC cards using UARTs with built-in divisors, simply changing the oscillator crystal would do the trick--IIRC, this was done with early MIDI setups.

Sure, if you can hack the hardware or have low-level access to the device you can typically set the interval-counter base in accordance with it's capabilities (time resolution).

But working from OSX unix system-call level to a plastic-encapsulated USB-serial dongle, I was pleasantly surprised that "75" was accepted by the IO/device driver. IIRC, it didn't accept 110 or other values outside the divide-by-2 sequence, and 75 was the final. So it wasn't a general frequency-to-period calculation from a high-res timer. Maybe it was a factor-of-two calculation that hit the counter resolution limit at 75, or the driver writer actually included 75 in a table lookup.