15 Oct
2015
15 Oct
'15
10:58 p.m.
On 2015-Oct-15, at 10:19 PM, Chuck Guzis wrote:
On 10/15/2015 10:06 PM, Brent Hilpert wrote:
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.
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.