31 Jan
2025
31 Jan
'25
12:20 a.m.
Hey all! So, I've found myself studying up on RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
From what I've read, "50 baud" was a kind of an initial goal to beat,
since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
Then 75/110/130 baud to have digital-systems interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure what
a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
I couldn't find much details (like a manual) on the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
I know from 1962, both RS232 and ASCII standards still took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Well, sorry for the rambling - have other RS232 related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
31 Jan
31 Jan
3:25 a.m.
On 31/01/2025 08:20, Steve Lewis via cctalk wrote:
Hey all! So, I've found myself studying up on
RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
Hi Steve,
I don't find RS232 boring - it's what started my career :-)
A couple of points you might like to consider, which you may already
know but stuff you've said above doesn't spell it out:
RS232 is not serial - make yourself clear. Before RS232 the same data
format was used in current loop (often 20mA or 60mA).
RS232 (AKA V.24) is only understandable when you realise it was
connecting a terminal (or later computer) to a modem. It's very
specific, yet like most technology has been subverted for other
purposes. I've kept at last one full RS232 modem in my loft (it was
government surplus, and I used to to run a BBS in 1980). Things got
weird later, particularly with the Hayes Smartmodem, but modems were
dumb devices. The lines went straight through. There were two
oscillators (for FM) and the appropriate one was switched in by the TX
line being high or low. Likewise the data separator looked for a high or
low tone and flipped RX between -12V and +12V. These were all individual
boards!
Then there's the line control board, which operated RI when a high
voltage was connected and DTR looped the phone line through.
Most of this makes no sense in other applications!
RS232, being voltage based, was only suitable for short distances
compared to current loop. Basic electronics - voltages drop over
distance due to resistance so after a while you don't know what you'll
get at the other end. A current flowing through a loop being turned off
and on has to be the same when measured at any point on the loop. The
"break key", of course, simply broke the current loop while you held it
down signalling whatever was required.
The speed of transmission is interesting. A purely analogue modem (or
current loop) can operate at any speed as long as both ends agree. The
original limit was the mechanical terminal. 110 baud makes sense as a
target as it's a nice round 10cps for ASCII - start bit, and seven data
bits, one parity bit and two stop bits. Two stop bits were necessary for
mechanical timing.
If you do five bit Baudot with no parity you've got about 75 baud for
10cps. When the V.23 standard was being developed (asymmetric 1200/75)
it was considered that 75bps was the fastest typing speed required which
is another reason why 50 was the bear minimum and 75 a better target. My
the time I was involved 75 was the "standard" for teleprinters so most
people couldn't out-type them.
UART? Crystal? Much later. Originally the timing came from a fixed speed
motor in the terminal. Have a look at how a teleprinter works. It wasn't
uncommon to adjust the speed of the motor at both ends to go as fast as
it could without errors.
And for amusement, someone wrote in the PCW saying they'd heard a
salesperson at Radio Shack trying to convince a punter that RS is RS232
stood for Radio Shack.
Hope the talk goes well. I assume you're a long way off - otherwise you
could borrow some of the kit hereabouts (but it's Very Heavy).
Regards, Frank.
From what I've read, "50 baud" was a
kind of an initial goal to beat, since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
Then 75/110/130 baud to have digital-systems interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure
what a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
I couldn't find much details (like a manual) on the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
I know from 1962, both RS232 and ASCII standards still took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Well, sorry for the rambling - have other RS232 related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
3:56 a.m.
On 2025-01-31 4:25 a.m., Frank Leonhardt via cctalk wrote:
A couple of points you might like to consider, which
you may already
know but stuff you've said above doesn't spell it out:
RS232 is not serial - make yourself clear. Before RS232 the same data
format was used in current loop (often 20mA or 60mA).
RS232 (AKA V.24) is only understandable when you realise it was
connecting a terminal (or later computer) to a modem. It's very
specific, yet like most technology has been subverted for other
purposes. I've kept at last one full RS232 modem in my loft (it was
government surplus, and I used to to run a BBS in 1980). Things got
weird later, particularly with the Hayes Smartmodem, but modems were
dumb devices. The lines went straight through. There were two
oscillators (for FM) and the appropriate one was switched in by the TX
line being high or low. Likewise the data separator looked for a high or
low tone and flipped RX between -12V and +12V. These were all individual
boards!
I always wondered why one needed a 25 pin connector?
Now every thing seems to be just 3 wire TTL.
Before RS232, how many wires where needed for the current loop
and did they have standard connector?
I can see 2 wire pairs, and ground.
4:30 a.m.
On 31/01/2025 11:56, ben via cctalk wrote:
On 2025-01-31 4:25 a.m., Frank Leonhardt via cctalk
wrote:
Just noticed in the bit you quoted - "RS232 is not serial" - that could
be taken the wrong way!
The 25-pin D-sub was a recommendation, not a requirement (at least
initially). There were 11 pins in the standard but sometimes other pins
were used for a synchronous clock and vendor specific stuff.
I really keep banging on about it, but RS232 was for controlling a modem
and most of the pins are to do with that. RS232 has come to be used to
mean (incorrectly) asynchronous serial in general, which ain't helpful.
So current loop - it's the same idea as your (analogue) telephone line,
and it can be used to transmit over long distances as the current is
constant. You can push up the voltage at the start to overcome loop
resistance until the current reaches the value you need.
And for current loop you need two "pins" - loop in and loop out. It's
just transferring a signal; it doesn't need extra pins for controlling a
modem or whatever. You send a mark (1) by breaking the loop - the
current stops flowing at all points 'cos that the laws of physics.
If you think about it, you can have as many listening devices on a
current loop as you like. Each will see the character bits in the form
of the current coming off and on, and each will print the same. This was
used with IBM DCCUs and suchlike to have identical printouts at
different stations in a bank.
It also means it's half duplex! Although you can have two current loops
(four wires) for a full duplex application.
IIRC RS-232 was only specified to work over 50 feet (15m) at maximum
data rate 19,200. Whether it'd work at higher speeds over that length is
questionable. Current loop circuits for teletypes would work over 500m,
no problem at all. As long as the current source could have the voltage
tweaked up high enough to overcome resistance on the loop. There did
come a point where the voltage needed would be too high for safety at
the near end, of course.
Regards, Frank.
A couple of points you might like to consider,
which you may already
know but stuff you've said above doesn't spell it out:
RS232 is not serial - make yourself clear. Before RS232 the same data
format was used in current loop (often 20mA or 60mA).
RS232 (AKA V.24) is only understandable when you realise it was
connecting a terminal (or later computer) to a modem. It's very
specific, yet like most technology has been subverted for other
purposes. I've kept at last one full RS232 modem in my loft (it was
government surplus, and I used to to run a BBS in 1980). Things got
weird later, particularly with the Hayes Smartmodem, but modems were
dumb devices. The lines went straight through. There were two
oscillators (for FM) and the appropriate one was switched in by the
TX line being high or low. Likewise the data separator looked for a
high or low tone and flipped RX between -12V and +12V. These were all
individual boards!
I always wondered why one needed a 25 pin connector?
Now every thing seems to be just 3 wire TTL.
Before RS232, how many wires where needed for the current loop
and did they have standard connector?
I can see 2 wire pairs, and ground. 
4:58 a.m.
On Fri, Jan 31, 2025 at 04:56:06AM -0700, ben via cctalk wrote:
[...]
I always wondered why one needed a 25 pin connector?
Now every thing seems to be just 3 wire TTL.
Before RS232, how many wires where needed for the current loop
and did they have standard connector?
I can see 2 wire pairs, and ground.
The minimal three-wire variant carries *only* payload data, and does not
have flow control or other out-of-band control signalling. Relatively
complex devices can run a protocol which multiplexes everything to reduce
wire count, but this complexity is not always warranted when running extra
wires is cheap.
There are a half-dozen out-of-band control signals. That makes nine wires,
which conveniently fits in the now de facto DE-9 serial port standard.
However, some devices are complex enough to want to out-of-band control
*data* (e.g. to send a phone number to an autodialler) and so there is an
optional secondary channel. This adds "only" five more wires, bringing the
total to 14, and so theoretically one could use a DA-15. However, there were
other obscure bits of signalling that some devices wanted, and the next
standard size is DB-25.
It's not always all-or-nothing either: for example, late-model dialup modems
use "AT" commands to multiplex the control data stream and some control
signals onto the payload data, but still use RTS/CTS for flow control.
5:37 a.m.
On 31/01/2025 11:56, ben via cctalk wrote:
On 2025-01-31 4:25 a.m., Frank Leonhardt via cctalk
wrote:
Lets look at some of the other pins:-
RTS/CTS - Request to send/clear to send - Hardware flow control.
DTR/DSR - Is comms up and running
RI - Ring Indicator - a call has arrived
TCK/RCK - Used for timing on synchronous links so BI-SYNC/SDLC/HDLC
LL/RL - enable loop back...
There is also a secondary channel which can be used for out-of-band
control...
A couple of points you might like to consider,
which you may already
know but stuff you've said above doesn't spell it out:
RS232 is not serial - make yourself clear. Before RS232 the same data
format was used in current loop (often 20mA or 60mA).
RS232 (AKA V.24) is only understandable when you realise it was
connecting a terminal (or later computer) to a modem. It's very
specific, yet like most technology has been subverted for other
purposes. I've kept at last one full RS232 modem in my loft (it was
government surplus, and I used to to run a BBS in 1980). Things got
weird later, particularly with the Hayes Smartmodem, but modems were
dumb devices. The lines went straight through. There were two
oscillators (for FM) and the appropriate one was switched in by the
TX line being high or low. Likewise the data separator looked for a
high or low tone and flipped RX between -12V and +12V. These were all
individual boards!
I always wondered why one needed a 25 pin connector? Now every thing seems to be just 3 wire TTL.
Lots of thinks need hardware handshake...
Before RS232, how many wires where needed for the
current loop
So RS232 was designed for modems, so audio tones on a phone line. So:-
Computer <= RS232=> Modem <= audio on phone line => Modem <=RS232=>
Terminal.
Confusingly both the computer and terminal are called "Data Terminal
Equipment" (DTE) and the modems are data communications equipment or DCE,
Current Loop was a physical connection, no modem, so just 2-wires for
half-duplex, 4-wires for full duplex. For long lines you can use polar
relays..
and did they have standard connector?
No
I can see 2 wire pairs, and ground.
No ground. Some loops are single-ended, so on-off keying, but in the UK
we used double ended, so reverse current direction.
Dave
6:06 a.m.
On 31/01/2025 13:37, David Wade via cctalk wrote:
On 31/01/2025 11:56, ben via cctalk wrote:
Actually, RTS and CTS weren't used for hardware flow control initially -
think about it - what would they be controlling? The modem was an
analogue circuit and there was no way it could pass flow control down
the line. With smart modems there was buffering involved, and therefore
the need for local flow control other than the XON/XOFF characters which
you wanted to pass through to the remote end.
RTS could be used to seize a half-duplex line (DCE didn't mean full
duplex modem exclusively), and CTS would be asserted once the line was
seized so you could start typing, start the tape reader.
I always wondered why one needed a 25 pin
connector?
Lets look at some of the other pins:-
RTS/CTS - Request to send/clear to send - Hardware flow control.
DTR/DSR - Is comms up and running
RI - Ring Indicator - a call has arrived
TCK/RCK - Used for timing on synchronous links so BI-SYNC/SDLC/HDLC
LL/RL - enable loop back...
There is also a secondary channel which can be used for out-of-band
control... Confusingly both the computer and terminal are called
"Data Terminal
Equipment" (DTE) and the modems are data communications equipment or DCE,
Indeed much fun was had with that one. As I said it only makes sense for
attaching something to a modem :-)
Fortunately the main lines come in pairs (DTR/DSR, RTS/CTS, TxD/RxD) so
you can make a mirror cable to connect a terminal to a computer port
that's expecting a modem (aka a null modem cable). If the computer was
expecting a terminal it'd be configured DCE port so the terminal could
plug in using a straight through cable.
But it's not orthogonal. DCD and RI are from DCE to DTE only. As a V100
didn't have a carrier signal and you didn't need to "ring" the computer
it didn't really matter.
Regards, Frank.
7:23 a.m.
On 2025-01-31 7:06 a.m., Frank Leonhardt via cctalk wrote:
So when did serial printers show up?
RTS could be used to seize a half-duplex line (DCE
didn't mean full
duplex modem exclusively), and CTS would be asserted once the line was
seized so you could start typing, start the tape reader.
I wanted to get a REAL computer for a long time, since the 70's and now
I have
nice 18 bit home-brew design, using 2 1508 CPLD's and 6 74LS219's for
the ALU and a 1508 for the control logic.
Back then you could get TTY's and other HARD copy output devices
and paper tape I/O.
Now that have my 1977 computer (It uses 68A50 ACIA's) is there low
cost paper tape punch/reader emulator for just a plain 1200 baud serial
port? All I have working now is just a serial boot strap and some ram.
A TTY emulator would be handy too, for me and all new PDP-8/11/10
emulators coming out.
Confusingly
both the computer and terminal are called "Data Terminal
Equipment" (DTE) and the modems are data communications equipment or DCE,
Indeed much fun was had with that one. As I said it only makes sense for
attaching something to a modem :-)
Regards, Frank.
Once I get better mother board PCB working, I then can
work on some kind of disk io, and timer interrupt.
No MMU is planned.
Ben.
8:19 a.m.
On Fri, Jan 31, 2025 at 08:23:18AM -0700, ben via cctalk wrote:
[...]
So when did serial printers show up?
1887 if we are to believe Wikipedia's article on teleprinters, although
their citation doesn't quite support that date. It's not going to be much
later though. The early teleprinters didn't speak RS-232, but that doesn't
mean they're not serial printers.
A fun factoid is that the modem was invented before the telephone and was
intended for the simultaneous transmission of multiple messages down a
telegraph line through having a different musical note for each. It wasn't
much of a leap of imagination to swap the Morse key for a microphone, and
that signalled the end of the electric telegraph.
9:43 a.m.
Long before flash drives were a reality,there were Philips cassette-tape
based paper tape emulators. I owned a dual-drive one from Techtran. It
had the advantage of being able to do high-speed searches and make fast
tape-to-tape copies.
The commercial embroidery world, like the CNC world was largely
paper-tape based. Eventually, there were not only tape-based emulators,
but also floppy disk-based ones. Paper tape eventually succumbs to
aging and mechanical stress, is difficult to edit and is very low
density. One can see the advantage of using later media to accomplish
the same end.
As far as RS232 and history, I submit that current-loop has more of a
place in telegraphy, as it's far more suited to long distances and is
less susceptible to signal noise. Many early 1970s serial interfaces
offered the choice between 20ma or 60ma current loop or RS232C.
--Chuck
1:36 p.m.
On Fri, 31 Jan 2025, Chuck Guzis via cctalk wrote:
As far as RS232 and history, I submit that
current-loop has more of a
place in telegraphy, as it's far more suited to long distances and is
less susceptible to signal noise. Many early 1970s serial interfaces
offered the choice between 20ma or 60ma current loop or RS232C.
up to the 5150 "Asynchronous Communication Adapter"
The "free" serial adapter used by IBM to discourage use of the eighth slot
was probably the same one.
1:52 p.m.
On Fri, Jan 31, 2025 at 9:36 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
On Fri, 31 Jan 2025, Chuck Guzis via cctalk wrote:
It was. The techref shows the jumper to fit so it can assert the data
buffer enable signal if it's placed in slot 8 of a 5160. Annoyingly
the 5155 cabinet is about 1/4" too small, the async adapter won't fit
in slot 8, it bangs into the disk drives.
To select between RS232 and current loop you have to remove the card
from the machine and turn a jumper block round. A couple of months ago
I worked out how to modify the card so that you didn't have to do this
Specifically :
You don't have to add any components or cut any traces, just add
(quite a few) jumper wires. There are no changes to the wiring to the
DB25
You can then fit the original IBM jumper block and select RS232 or
current loop, the board behaves just like an unmodifed one
But you can also fit a specially-wired jumper block, whereupon
The board will work in RS232 mode with standard RS232 cables.
Or with a specially wired cable (and RTS asserted from the board) it
works in current loop mode.
I've modified both the boards in my 5155.
-tony
As far as RS232 and history, I submit that
current-loop has more of a
place in telegraphy, as it's far more suited to long distances and is
less susceptible to signal noise. Many early 1970s serial interfaces
offered the choice between 20ma or 60ma current loop or RS232C.
up to the 5150 "Asynchronous Communication Adapter"
The "free" serial adapter used by IBM to discourage use of the eighth slot
was probably the same one.
8:19 a.m.
On 31/01/2025 15:23, ben via cctalk wrote:
On 2025-01-31 7:06 a.m., Frank Leonhardt via cctalk
wrote:
I wanted to get a REAL computer for a long time, since the 70's and
now I have
nice 18 bit home-brew design, using 2 1508 CPLD's and 6 74LS219's for
the ALU and a 1508 for the control logic.
Back then you could get TTY's and other HARD copy output devices
and paper tape I/O.
Now that have my 1977 computer (It uses 68A50 ACIA's) is there low
cost paper tape punch/reader emulator for just a plain 1200 baud
serial port? All I have working now is just a serial boot strap and
some ram.
I've still got a few actual teletypes. Be careful what you wish for. I
was going to suggest searching eBay for an ASR33 but I checked and there
aren't any.
My 1970's computer had a switch on the one ACIA between a Teletype and a
a CUTS cassette interface. The latter stored at 30cps. An advantage to
the CUTS is that you can't get paper tape easily AFAK (This list is
probably the place to ask).
I'm not sure how an emulator would look TBH. It wouldn't have the charm
of the original, but I do see your point. What were you thinking? Hard
copy or VDU? I see you can still buy matrix printers which, with the
appropriate driver, could be persuaded to do one character a time. I see
on Amazon they now cost a lot more than laser printers!
And store "paper tape" as files on a USB stick? Or you could use a
cassette, although they're getting hard to find. The FSK circuitry is
pretty straightforward (copy it from an OSI 600 board
https://osiweb.org/manuals/600revB.pdf Sheet 7).
And I don't know where you'd find such an awful keyboard - although you
could make one yourself out of 53 key switches. The final touch would be
a powerful subwoofer to make the whole house shake when you pressed a key.
I'd be up for working on one.
If you wanted a purely software emulation then any glass TTY program
that was able to record and play back from disk would do the job.
I also checked and you can still get electric typewriters. Brother does
one with a daisywheel; Silver Reed has a much cheaper dot matrix. I
don't know, but I suspect some of them still have computer interfaces.
So when did serial printers show up?
For home computers, from memory....
The big one was the Epson FX-80. They tended to have parallel interfaces
- cheaper than serial! You could buy a serial board to fit in to them
(I've got one knocking around).
A Teletype is, of course, a serial printer. And it was all I could
afford. £50 at the time, whereas a matrix printer was £200.
A few years later people were chucking out teletypes, so I picked up a
few more for spares.
Regards, Frank.
10:44 a.m.
Neat stuff. So what got me started (this year) dealing with RS232 is
trying to figure out a means for doing file-stream data exchange with the
Commander X16 (which is using a dual 16550 modern-make UART and ~14MHz
clock). It doesn't have a native terminal software yet with something like
YModem implemented. Which I've found YModem faster over "wireless serial
connection" (serial adapted to WiFi, so varied data rates over time) and
ZModem being faster over wired (null modem) connections (apparently since
ZModem has particular ACK-timeout requirements, which favors a reliable
data exchange rate).
So while some protocol gets developed for that system, I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
2) Why is it so slow even on modern systems?
The answer to the first question is the "magic" of those modern-make
USB-serial dongles. I don't fully understand if they're running at 3MHz
(since in thier manual I see references to higher clock rates, like
48MHz). But maybe also answer like this: going back to the early teletypes
days (pre-Bell 101 era), two systems can talk at "whatever-speed" just as
long as they both agree on and achieve that speed (a limit that also
involves the cabling between them).
In this case, as long as the UARTs can be throttled to within-1%-ish clock
speed of each other. But it's still the same RS232 principles even at
these super-speeds? (specialized chips, doing the 2-of-3 hits finding start
bits, etc, with higher clocks like 12, 15, 20MHz, I see SIIG offering UARTS
with 25 and 30MHz clocks). It seems to me that an S-100 system with a
~5MHz serial clock, or a later ISA card with a 7.3727 clock with a 16550,
those could be clock divided to support over 115200. But it just ended up
that the 1.8432MHz configuration was the most mass-produced and available,
because that is what was sufficient for phone lines of the 1980s? (i.e.
what the IBM PC did)
So I tested a bunch of (relatively modern, post-UART) vintage systems:
4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium
all null-modem connected to a modern-make PC - just to verify how fast they
should be pushed (download) a data stream. None of them (not even the
Pentium) could be clocked past 115.2K on this serial line. (I know the
host system isn't dictating the speed, but whatever integrated UART is
available-- then the software that controls that UART to clock divide to
"commonly defined baud rates").
- As IBM's own PC manual states, it can't be pushed past 9600 reliably (you
can, but it starts dropping characters). So despite a UART that can
technically achieve 115200, that system can't handle it (settling on a
YModem data exchange rate of about 0.9 KBps).
- The 286 mustered about 2.3 KBps (that is, the sustained download speed
using a very good implemented-in-assembler terminal with YModem, receiving
data from a modern make 3GHz PC USB/serial adapter). This was using a
57600 baud connection, so I'm not sure why the 286 couldn't do a little
better on throughput. I assume a limitation of its raw speed (12MHz) to
compute CRC checks, and then the combined memory/hard drive speed to write
received data to disk. Again, the UART could handle up to 115200, but the
system could not.
- The 486 handled a nice 11.3KBps download at 115200 (null modem, same
modern-make laptop and terminal program as above). So the combined
performance of its memory, write to disk, and raw 50MHz CPU, it could
"out-perform" its UART (or at least match it).
- The Pentium was slightly slower, 11.1KBps - but probably because it was
also running a GUI (WinXP) at the same time or maybe just due to having a
slightly different UART clock (being a laptop, I don't know what specific
clock it had. Still, you'd think an IBM ThinkPad would have a fancy ~7MHz
clock with 16550 and be able to do better than 115.2K, but nope (at least
not with the IBM drivers I could get). Then again, by late 1990s there
were many other better solutions for transfering files between systems and
"serial ports" on consumer laptops just had to be good enough for the
modems/phone lines of their day)
- Modern make laptop to modern make (two fancy i7's talking over USB/serial
adapters) achieved 45KBps (bytes per second) across a 460K baud connection
(ZOC, ZModem). And yes, it's a ridiculous way to transfer a file between
two nearby systems these days. It's neat to see RS232 pushed that far,
but on the other hand, that's really slow for a modern PC.
So that leads to the next question, why was only up to 460K stable? At
921K everything was misinterpreted. It could be the cables (and I do have
shorter ones coming, and will test). Those FTDI USB devices (or MAX232) do
have a published programming manual, so we could try various clock rates
that might net somewhere in between 460K and 921K baud. But thinking
through it a bit: USB is 4 wires (2-data), and that device is "emulating"
a flow-controlled RS232 connection. So then what protocol is USB using to
get its super speeds? Something-NOT-RS232. We can read all about that -
but I don't want to get too sidetracked on USB-isms. But it opens a
question, could we exchange data faster across traditional "serial port" if
we used something different than YModem? (it's just that most vintage
systems have an existing KERMIT, X/YModem implementation, and there are
other more practical ways to exchange files across modern systems, no one
has really looked into improved protocols across RS232? like... dual
channel across the RI line? ha!) But whatever that faster protocol is,
those vintage systems might not have the MHz horsepower (or memory capacity
or speed) to pull it off?
And, on the question of "why UART?" Well - hmm, history shows computers
exchanged data across long distances prior to the 1970 consumer UART
(TR1402A). Flow control makes that connection fairly reliable, and you see
those control flow lines listed on the Bell 103 (I tend to think the Bell
101 was kind of maybe a prototype of proof of concept, so far I'm not
seeing anything that used it; SAGE identified a specific need, so that Bell
101 maybe motivated thought on what such a thing could be used for). I've
also read CRC was also becoming a thing in early 1960s (which helped verify
blocks of data, prior to that error correction was just the parity bit).
I have to drive for awhile today, I'll ponder on the essence of when/why
UARTs became an essential part of these systems. Does a UART become
important when two systems are vastly mixed performance?
But for other fodder, I'm reading over the async card for the IBM 5110.
Page 12 of this IBM 5110 doc has a block diagram of IBMs version of
"asynchronous card" -
SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf
<http://www.bitsavers.org/pdf/ibm/5110/diagrams/SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf>
And its manual (from 1978) has some interesting paragraphs (plus how that
system was apparently obsessed with showing text-mode graphs of the error
rates; line quality is apparently still very rough by late 1970's):
SY31-0557-0_5110asyncComm_Jan1978.pdf
<http://www.bitsavers.org/pdf/ibm/5110/SY31-0557-0_5110asyncComm_Jan1978.pdf>
-SteveL
On Fri, Jan 31, 2025 at 10:20 AM Frank Leonhardt via cctalk <
cctalk(a)classiccmp.org> wrote:
On 31/01/2025 15:23, ben via cctalk wrote:
On 2025-01-31 7:06 a.m., Frank Leonhardt via
cctalk wrote:
I wanted to get a REAL computer for a long time, since the 70's and
now I have
nice 18 bit home-brew design, using 2 1508 CPLD's and 6 74LS219's for
the ALU and a 1508 for the control logic.
Back then you could get TTY's and other HARD copy output devices
and paper tape I/O.
Now that have my 1977 computer (It uses 68A50 ACIA's) is there low
cost paper tape punch/reader emulator for just a plain 1200 baud
serial port? All I have working now is just a serial boot strap and
some ram.
I've still got a few actual teletypes. Be careful what you wish for. I
was going to suggest searching eBay for an ASR33 but I checked and there
aren't any.
My 1970's computer had a switch on the one ACIA between a Teletype and a
a CUTS cassette interface. The latter stored at 30cps. An advantage to
the CUTS is that you can't get paper tape easily AFAK (This list is
probably the place to ask).
I'm not sure how an emulator would look TBH. It wouldn't have the charm
of the original, but I do see your point. What were you thinking? Hard
copy or VDU? I see you can still buy matrix printers which, with the
appropriate driver, could be persuaded to do one character a time. I see
on Amazon they now cost a lot more than laser printers!
And store "paper tape" as files on a USB stick? Or you could use a
cassette, although they're getting hard to find. The FSK circuitry is
pretty straightforward (copy it from an OSI 600 board
https://osiweb.org/manuals/600revB.pdf Sheet 7).
And I don't know where you'd find such an awful keyboard - although you
could make one yourself out of 53 key switches. The final touch would be
a powerful subwoofer to make the whole house shake when you pressed a key.
I'd be up for working on one.
If you wanted a purely software emulation then any glass TTY program
that was able to record and play back from disk would do the job.
I also checked and you can still get electric typewriters. Brother does
one with a daisywheel; Silver Reed has a much cheaper dot matrix. I
don't know, but I suspect some of them still have computer interfaces.
So when did serial printers show up?
For home computers, from memory....
The big one was the Epson FX-80. They tended to have parallel interfaces
- cheaper than serial! You could buy a serial board to fit in to them
(I've got one knocking around).
A Teletype is, of course, a serial printer. And it was all I could
afford. £50 at the time, whereas a matrix printer was £200.
A few years later people were chucking out teletypes, so I picked up a
few more for spares.
Regards, Frank.
10:55 a.m.
On Jan 31, 2025, at 1:44 PM, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
Neat stuff. So what got me started (this year) dealing with RS232 is
trying to figure out a means for doing file-stream data exchange with the
Commander X16 (which is using a dual 16550 modern-make UART and ~14MHz
clock). It doesn't have a native terminal software yet with something like
YModem implemented. Which I've found YModem faster over "wireless serial
connection" (serial adapted to WiFi, so varied data rates over time) and
ZModem being faster over wired (null modem) connections (apparently since
ZModem has particular ACK-timeout requirements, which favors a reliable
data exchange rate).
So while some protocol gets developed for that system, I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
Sort of no, because RS232 isn't specified for data rates that high. I forgot what the
formal limit is, though actual implementations work well above the specified speed and
distance limits. In my DDCMP work I've done RS232 signaling at several hundred kbps.
But mostly "not applicable".
RS232 isn't a UART standard, or a standard for data at particular speeds. Instead, it
is an electrical signaling standard. The main thing about RS232 is that it specifies a
set of interface signals, and electrical parameters for the signals. For example: drivers
generate bipolar signals within some voltage range, receivers handle bipolar signals
within another (larger) voltage range, with overvoltage tolerance, etc.
Sometimes people speak of RS232 in connection with TTL or other unipolar signaling
voltages. That can't be correct because RS232 specifically excludes 0 volts as a
valid signal level.
paul
10:55 a.m.
re: on UARTS..
Didn't it basically standardize the process of that task of converting a
byte to bits and vice versa, in a fashion specified by RS232?
And do so at the above-300-baud rates, since that task was too stressful
for 1MHz processors to pull off on its own (in addition to whatever else it
was doing, like flashing a cursor on a CRT?)?
And the buffer just gave grace time for if one of the systems got overly
busy? (like when scrolling said CRT)?
Might a UART be an early example of an ASIC?
On Fri, Jan 31, 2025 at 12:44 PM Steve Lewis <lewissa78(a)gmail.com> wrote:
Neat stuff. So what got me started (this year)
dealing with RS232 is
trying to figure out a means for doing file-stream data exchange with the
Commander X16 (which is using a dual 16550 modern-make UART and ~14MHz
clock). It doesn't have a native terminal software yet with something like
YModem implemented. Which I've found YModem faster over "wireless serial
connection" (serial adapted to WiFi, so varied data rates over time) and
ZModem being faster over wired (null modem) connections (apparently since
ZModem has particular ACK-timeout requirements, which favors a reliable
data exchange rate).
So while some protocol gets developed for that system, I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
2) Why is it so slow even on modern systems?
The answer to the first question is the "magic" of those modern-make
USB-serial dongles. I don't fully understand if they're running at 3MHz
(since in thier manual I see references to higher clock rates, like
48MHz). But maybe also answer like this: going back to the early teletypes
days (pre-Bell 101 era), two systems can talk at "whatever-speed" just as
long as they both agree on and achieve that speed (a limit that also
involves the cabling between them).
In this case, as long as the UARTs can be throttled to within-1%-ish clock
speed of each other. But it's still the same RS232 principles even at
these super-speeds? (specialized chips, doing the 2-of-3 hits finding start
bits, etc, with higher clocks like 12, 15, 20MHz, I see SIIG offering UARTS
with 25 and 30MHz clocks). It seems to me that an S-100 system with a
~5MHz serial clock, or a later ISA card with a 7.3727 clock with a 16550,
those could be clock divided to support over 115200. But it just ended up
that the 1.8432MHz configuration was the most mass-produced and available,
because that is what was sufficient for phone lines of the 1980s? (i.e.
what the IBM PC did)
So I tested a bunch of (relatively modern, post-UART) vintage systems:
4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium
all null-modem connected to a modern-make PC - just to verify how fast they
should be pushed (download) a data stream. None of them (not even the
Pentium) could be clocked past 115.2K on this serial line. (I know the
host system isn't dictating the speed, but whatever integrated UART is
available-- then the software that controls that UART to clock divide to
"commonly defined baud rates").
- As IBM's own PC manual states, it can't be pushed past 9600 reliably
(you can, but it starts dropping characters). So despite a UART that can
technically achieve 115200, that system can't handle it (settling on a
YModem data exchange rate of about 0.9 KBps).
- The 286 mustered about 2.3 KBps (that is, the sustained download speed
using a very good implemented-in-assembler terminal with YModem, receiving
data from a modern make 3GHz PC USB/serial adapter). This was using a
57600 baud connection, so I'm not sure why the 286 couldn't do a little
better on throughput. I assume a limitation of its raw speed (12MHz) to
compute CRC checks, and then the combined memory/hard drive speed to write
received data to disk. Again, the UART could handle up to 115200, but the
system could not.
- The 486 handled a nice 11.3KBps download at 115200 (null modem, same
modern-make laptop and terminal program as above). So the combined
performance of its memory, write to disk, and raw 50MHz CPU, it could
"out-perform" its UART (or at least match it).
- The Pentium was slightly slower, 11.1KBps - but probably because it was
also running a GUI (WinXP) at the same time or maybe just due to having a
slightly different UART clock (being a laptop, I don't know what specific
clock it had. Still, you'd think an IBM ThinkPad would have a fancy ~7MHz
clock with 16550 and be able to do better than 115.2K, but nope (at least
not with the IBM drivers I could get). Then again, by late 1990s there
were many other better solutions for transfering files between systems and
"serial ports" on consumer laptops just had to be good enough for the
modems/phone lines of their day)
- Modern make laptop to modern make (two fancy i7's talking over
USB/serial adapters) achieved 45KBps (bytes per second) across a 460K baud
connection (ZOC, ZModem). And yes, it's a ridiculous way to transfer a
file between two nearby systems these days. It's neat to see RS232 pushed
that far, but on the other hand, that's really slow for a modern PC.
So that leads to the next question, why was only up to 460K stable? At
921K everything was misinterpreted. It could be the cables (and I do have
shorter ones coming, and will test). Those FTDI USB devices (or MAX232) do
have a published programming manual, so we could try various clock rates
that might net somewhere in between 460K and 921K baud. But thinking
through it a bit: USB is 4 wires (2-data), and that device is "emulating"
a flow-controlled RS232 connection. So then what protocol is USB using to
get its super speeds? Something-NOT-RS232. We can read all about that -
but I don't want to get too sidetracked on USB-isms. But it opens a
question, could we exchange data faster across traditional "serial port" if
we used something different than YModem? (it's just that most vintage
systems have an existing KERMIT, X/YModem implementation, and there are
other more practical ways to exchange files across modern systems, no one
has really looked into improved protocols across RS232? like... dual
channel across the RI line? ha!) But whatever that faster protocol is,
those vintage systems might not have the MHz horsepower (or memory capacity
or speed) to pull it off?
And, on the question of "why UART?" Well - hmm, history shows computers
exchanged data across long distances prior to the 1970 consumer UART
(TR1402A). Flow control makes that connection fairly reliable, and you see
those control flow lines listed on the Bell 103 (I tend to think the Bell
101 was kind of maybe a prototype of proof of concept, so far I'm not
seeing anything that used it; SAGE identified a specific need, so that Bell
101 maybe motivated thought on what such a thing could be used for). I've
also read CRC was also becoming a thing in early 1960s (which helped verify
blocks of data, prior to that error correction was just the parity bit).
I have to drive for awhile today, I'll ponder on the essence of when/why
UARTs became an essential part of these systems. Does a UART become
important when two systems are vastly mixed performance?
But for other fodder, I'm reading over the async card for the IBM 5110.
Page 12 of this IBM 5110 doc has a block diagram of IBMs version of
"asynchronous card" -
SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf
<http://www.bitsavers.org/pdf/ibm/5110/diagrams/SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf>
And its manual (from 1978) has some interesting paragraphs (plus how that
system was apparently obsessed with showing text-mode graphs of the error
rates; line quality is apparently still very rough by late 1970's):
SY31-0557-0_5110asyncComm_Jan1978.pdf
<http://www.bitsavers.org/pdf/ibm/5110/SY31-0557-0_5110asyncComm_Jan1978.pdf>
-SteveL
On Fri, Jan 31, 2025 at 10:20 AM Frank Leonhardt via cctalk <
cctalk(a)classiccmp.org> wrote:
>
> On 31/01/2025 15:23, ben via cctalk wrote:
> > On 2025-01-31 7:06 a.m., Frank Leonhardt via cctalk wrote:
> >
> > I wanted to get a REAL computer for a long time, since the 70's and
> > now I have
> > nice 18 bit home-brew design, using 2 1508 CPLD's and 6 74LS219's for
> > the ALU and a 1508 for the control logic.
> >
> > Back then you could get TTY's and other HARD copy output devices
> > and paper tape I/O.
> >
> > Now that have my 1977 computer (It uses 68A50 ACIA's) is there low
> > cost paper tape punch/reader emulator for just a plain 1200 baud
> > serial port? All I have working now is just a serial boot strap and
> > some ram.
>
> I've still got a few actual teletypes. Be careful what you wish for. I
> was going to suggest searching eBay for an ASR33 but I checked and there
> aren't any.
>
> My 1970's computer had a switch on the one ACIA between a Teletype and a
> a CUTS cassette interface. The latter stored at 30cps. An advantage to
> the CUTS is that you can't get paper tape easily AFAK (This list is
> probably the place to ask).
>
> I'm not sure how an emulator would look TBH. It wouldn't have the charm
> of the original, but I do see your point. What were you thinking? Hard
> copy or VDU? I see you can still buy matrix printers which, with the
> appropriate driver, could be persuaded to do one character a time. I see
> on Amazon they now cost a lot more than laser printers!
>
> And store "paper tape" as files on a USB stick? Or you could use a
> cassette, although they're getting hard to find. The FSK circuitry is
> pretty straightforward (copy it from an OSI 600 board
> https://osiweb.org/manuals/600revB.pdf Sheet 7).
>
> And I don't know where you'd find such an awful keyboard - although you
> could make one yourself out of 53 key switches. The final touch would be
> a powerful subwoofer to make the whole house shake when you pressed a key.
>
> I'd be up for working on one.
>
> If you wanted a purely software emulation then any glass TTY program
> that was able to record and play back from disk would do the job.
>
> I also checked and you can still get electric typewriters. Brother does
> one with a daisywheel; Silver Reed has a much cheaper dot matrix. I
> don't know, but I suspect some of them still have computer interfaces.
>
> > So when did serial printers show up?
>
> For home computers, from memory....
>
> The big one was the Epson FX-80. They tended to have parallel interfaces
> - cheaper than serial! You could buy a serial board to fit in to them
> (I've got one knocking around).
>
> A Teletype is, of course, a serial printer. And it was all I could
> afford. £50 at the time, whereas a matrix printer was £200.
>
> A few years later people were chucking out teletypes, so I picked up a
> few more for spares.
>
>
> Regards, Frank.
>
>
>
11:02 a.m.
On Jan 31, 2025, at 1:55 PM, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
re: on UARTS..
Didn't it basically standardize the process of that task of converting a
byte to bits and vice versa, in a fashion specified by RS232?
No, RS232 is a way to send binary information between devices, using specified voltage
levels and interface conventions. It has nothing to with UARTs.
And do so at the above-300-baud rates, since that task
was too stressful
for 1MHz processors to pull off on its own (in addition to whatever else it
was doing, like flashing a cursor on a CRT?)?
And the buffer just gave grace time for if one of the systems got overly
busy? (like when scrolling said CRT)?
You can do a UART in software at pretty high speeds if the processor doesn't have too
much else to do. Conversely, a 110 baud UART is very painful in software on a 4004.
Might a UART be an early example of an ASIC?
Yes, I would say so.
paul
11:18 a.m.
Steve, remember that digital electronics ( I.E. integrated circuits like uarts) weren’t
around during the early days of data transmission. It was all analog back then, coils,
capacitors, and resistors, so then ideas regarding fast transmission had to wait for the
technology to evolve. Then as ic’s became available, what you could do with them sparked
new ideas. Example: data compression within the modem using a microprocessor, thus getting
higher overall throughput than the theoretical maximum of just the modulation rate.
Sent from my iPhone
On Jan 31, 2025, at 10:55, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
re: on UARTS..
Didn't it basically standardize the process of that task of converting a
byte to bits and vice versa, in a fashion specified by RS232?
And do so at the above-300-baud rates, since that task was too stressful
for 1MHz processors to pull off on its own (in addition to whatever else it
was doing, like flashing a cursor on a CRT?)?
And the buffer just gave grace time for if one of the systems got overly
busy? (like when scrolling said CRT)?
Might a UART be an early example of an ASIC?
> On Fri, Jan 31, 2025 at 12:44 PM Steve Lewis <lewissa78(a)gmail.com> wrote:
>
> Neat stuff. So what got me started (this year) dealing with RS232 is
> trying to figure out a means for doing file-stream data exchange with the
> Commander X16 (which is using a dual 16550 modern-make UART and ~14MHz
> clock). It doesn't have a native terminal software yet with something like
> YModem implemented. Which I've found YModem faster over "wireless serial
> connection" (serial adapted to WiFi, so varied data rates over time) and
> ZModem being faster over wired (null modem) connections (apparently since
> ZModem has particular ACK-timeout requirements, which favors a reliable
> data exchange rate).
>
> So while some protocol gets developed for that system, I experimented with
> other actual vintage system trying to "talk to" a modern PC (where
"modern
> PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
> are many other better options, but I still wanted to "push the envelope"
of
> what classic RS232 could do on these systems.
>
> And it was interesting that even modern-PC to modern-PC, it only handled
> 460Kbps. But it causes two "opposite" questions:
> 1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
> 2) Why is it so slow even on modern systems?
>
> The answer to the first question is the "magic" of those modern-make
> USB-serial dongles. I don't fully understand if they're running at 3MHz
> (since in thier manual I see references to higher clock rates, like
> 48MHz). But maybe also answer like this: going back to the early teletypes
> days (pre-Bell 101 era), two systems can talk at "whatever-speed" just as
> long as they both agree on and achieve that speed (a limit that also
> involves the cabling between them).
>
> In this case, as long as the UARTs can be throttled to within-1%-ish clock
> speed of each other. But it's still the same RS232 principles even at
> these super-speeds? (specialized chips, doing the 2-of-3 hits finding start
> bits, etc, with higher clocks like 12, 15, 20MHz, I see SIIG offering UARTS
> with 25 and 30MHz clocks). It seems to me that an S-100 system with a
> ~5MHz serial clock, or a later ISA card with a 7.3727 clock with a 16550,
> those could be clock divided to support over 115200. But it just ended up
> that the 1.8432MHz configuration was the most mass-produced and available,
> because that is what was sufficient for phone lines of the 1980s? (i.e.
> what the IBM PC did)
>
>
> So I tested a bunch of (relatively modern, post-UART) vintage systems:
> 4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium
> all null-modem connected to a modern-make PC - just to verify how fast they
> should be pushed (download) a data stream. None of them (not even the
> Pentium) could be clocked past 115.2K on this serial line. (I know the
> host system isn't dictating the speed, but whatever integrated UART is
> available-- then the software that controls that UART to clock divide to
> "commonly defined baud rates").
>
> - As IBM's own PC manual states, it can't be pushed past 9600 reliably
> (you can, but it starts dropping characters). So despite a UART that can
> technically achieve 115200, that system can't handle it (settling on a
> YModem data exchange rate of about 0.9 KBps).
>
> - The 286 mustered about 2.3 KBps (that is, the sustained download speed
> using a very good implemented-in-assembler terminal with YModem, receiving
> data from a modern make 3GHz PC USB/serial adapter). This was using a
> 57600 baud connection, so I'm not sure why the 286 couldn't do a little
> better on throughput. I assume a limitation of its raw speed (12MHz) to
> compute CRC checks, and then the combined memory/hard drive speed to write
> received data to disk. Again, the UART could handle up to 115200, but the
> system could not.
>
> - The 486 handled a nice 11.3KBps download at 115200 (null modem, same
> modern-make laptop and terminal program as above). So the combined
> performance of its memory, write to disk, and raw 50MHz CPU, it could
> "out-perform" its UART (or at least match it).
>
> - The Pentium was slightly slower, 11.1KBps - but probably because it was
> also running a GUI (WinXP) at the same time or maybe just due to having a
> slightly different UART clock (being a laptop, I don't know what specific
> clock it had. Still, you'd think an IBM ThinkPad would have a fancy ~7MHz
> clock with 16550 and be able to do better than 115.2K, but nope (at least
> not with the IBM drivers I could get). Then again, by late 1990s there
> were many other better solutions for transfering files between systems and
> "serial ports" on consumer laptops just had to be good enough for the
> modems/phone lines of their day)
>
> - Modern make laptop to modern make (two fancy i7's talking over
> USB/serial adapters) achieved 45KBps (bytes per second) across a 460K baud
> connection (ZOC, ZModem). And yes, it's a ridiculous way to transfer a
> file between two nearby systems these days. It's neat to see RS232 pushed
> that far, but on the other hand, that's really slow for a modern PC.
>
>
> So that leads to the next question, why was only up to 460K stable? At
> 921K everything was misinterpreted. It could be the cables (and I do have
> shorter ones coming, and will test). Those FTDI USB devices (or MAX232) do
> have a published programming manual, so we could try various clock rates
> that might net somewhere in between 460K and 921K baud. But thinking
> through it a bit: USB is 4 wires (2-data), and that device is
"emulating"
> a flow-controlled RS232 connection. So then what protocol is USB using to
> get its super speeds? Something-NOT-RS232. We can read all about that -
> but I don't want to get too sidetracked on USB-isms. But it opens a
> question, could we exchange data faster across traditional "serial port"
if
> we used something different than YModem? (it's just that most vintage
> systems have an existing KERMIT, X/YModem implementation, and there are
> other more practical ways to exchange files across modern systems, no one
> has really looked into improved protocols across RS232? like... dual
> channel across the RI line? ha!) But whatever that faster protocol is,
> those vintage systems might not have the MHz horsepower (or memory capacity
> or speed) to pull it off?
>
>
> And, on the question of "why UART?" Well - hmm, history shows computers
> exchanged data across long distances prior to the 1970 consumer UART
> (TR1402A). Flow control makes that connection fairly reliable, and you see
> those control flow lines listed on the Bell 103 (I tend to think the Bell
> 101 was kind of maybe a prototype of proof of concept, so far I'm not
> seeing anything that used it; SAGE identified a specific need, so that Bell
> 101 maybe motivated thought on what such a thing could be used for). I've
> also read CRC was also becoming a thing in early 1960s (which helped verify
> blocks of data, prior to that error correction was just the parity bit).
>
> I have to drive for awhile today, I'll ponder on the essence of when/why
> UARTs became an essential part of these systems. Does a UART become
> important when two systems are vastly mixed performance?
>
> But for other fodder, I'm reading over the async card for the IBM 5110.
> Page 12 of this IBM 5110 doc has a block diagram of IBMs version of
> "asynchronous card" -
> SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf
>
<http://www.bitsavers.org/pdf/ibm/5110/diagrams/SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf>
> And its manual (from 1978) has some interesting paragraphs (plus how that
> system was apparently obsessed with showing text-mode graphs of the error
> rates; line quality is apparently still very rough by late 1970's):
> SY31-0557-0_5110asyncComm_Jan1978.pdf
> <http://www.bitsavers.org/pdf/ibm/5110/SY31-0557-0_5110asyncComm_Jan1978.pdf>
>
>
> -SteveL
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jan 31, 2025 at 10:20 AM Frank Leonhardt via cctalk <
> cctalk(a)classiccmp.org> wrote:
>
>>
>> On 31/01/2025 15:23, ben via cctalk wrote:
>>> On 2025-01-31 7:06 a.m., Frank Leonhardt via cctalk wrote:
>>>
>>> I wanted to get a REAL computer for a long time, since the 70's and
>>> now I have
>>> nice 18 bit home-brew design, using 2 1508 CPLD's and 6 74LS219's
for
>>> the ALU and a 1508 for the control logic.
>>>
>>> Back then you could get TTY's and other HARD copy output devices
>>> and paper tape I/O.
>>>
>>> Now that have my 1977 computer (It uses 68A50 ACIA's) is there low
>>> cost paper tape punch/reader emulator for just a plain 1200 baud
>>> serial port? All I have working now is just a serial boot strap and
>>> some ram.
>>
>> I've still got a few actual teletypes. Be careful what you wish for. I
>> was going to suggest searching eBay for an ASR33 but I checked and there
>> aren't any.
>>
>> My 1970's computer had a switch on the one ACIA between a Teletype and a
>> a CUTS cassette interface. The latter stored at 30cps. An advantage to
>> the CUTS is that you can't get paper tape easily AFAK (This list is
>> probably the place to ask).
>>
>> I'm not sure how an emulator would look TBH. It wouldn't have the charm
>> of the original, but I do see your point. What were you thinking? Hard
>> copy or VDU? I see you can still buy matrix printers which, with the
>> appropriate driver, could be persuaded to do one character a time. I see
>> on Amazon they now cost a lot more than laser printers!
>>
>> And store "paper tape" as files on a USB stick? Or you could use a
>> cassette, although they're getting hard to find. The FSK circuitry is
>> pretty straightforward (copy it from an OSI 600 board
>> https://osiweb.org/manuals/600revB.pdf Sheet 7).
>>
>> And I don't know where you'd find such an awful keyboard - although you
>> could make one yourself out of 53 key switches. The final touch would be
>> a powerful subwoofer to make the whole house shake when you pressed a key.
>>
>> I'd be up for working on one.
>>
>> If you wanted a purely software emulation then any glass TTY program
>> that was able to record and play back from disk would do the job.
>>
>> I also checked and you can still get electric typewriters. Brother does
>> one with a daisywheel; Silver Reed has a much cheaper dot matrix. I
>> don't know, but I suspect some of them still have computer interfaces.
>>
>>> So when did serial printers show up?
>>
>> For home computers, from memory....
>>
>> The big one was the Epson FX-80. They tended to have parallel interfaces
>> - cheaper than serial! You could buy a serial board to fit in to them
>> (I've got one knocking around).
>>
>> A Teletype is, of course, a serial printer. And it was all I could
>> afford. £50 at the time, whereas a matrix printer was £200.
>>
>> A few years later people were chucking out teletypes, so I picked up a
>> few more for spares.
>>
>>
>> Regards, Frank.
>>
>>
>>
12:13 p.m.
On Jan 31, 2025, at 2:18 PM, Wayne S via cctalk
<cctalk(a)classiccmp.org> wrote:
Steve, remember that digital electronics ( I.E. integrated circuits like uarts) weren’t
around during the early days of data transmission. It was all analog back then, coils,
capacitors, and resistors, so then ideas regarding fast transmission had to wait for the
technology to evolve. Then as ic’s became available, what you could do with them sparked
new ideas. Example: data compression within the modem using a microprocessor, thus getting
higher overall throughput than the theoretical maximum of just the modulation rate.
True, though "digital electronics" and "integrated circuits" are not
directly related. Digital circuits were first built with relays and with tubes. What
makes them "digital" is that they deal in ones and zeroes rather than with
continuous real-valued signals.
paul
12:57 p.m.
Steve, remember that digital electronics ( I.E.
integrated circuits
like uarts) weren’t around during the early days of data
transmission. It was all analog back then, coils, capacitors, and
resistors, so then ideas regarding fast transmission had to wait for
the technology to evolve. Then as ic’s became available, what you
could do with them sparked new ideas. Example: data compression
within the modem using a microprocessor, thus getting higher overall
throughput than the theoretical maximum of just the modulation rate.
Some dates relevant to this discussion:
"First" monolithic IC in the lab: 1960.
First PCM multiplexed telephone circuit (T1, 1.544 Mbit/s): 1962.
First UART IC: 1972.
De
3:12 p.m.
On 1/31/25 12:57, Dennis Boone via cctalk wrote:
Some dates relevant to this discussion:
"First" monolithic IC in the lab: 1960.
First PCM multiplexed telephone circuit (T1, 1.544 Mbit/s): 1962.
First UART IC: 1972.
In the mid 70s, I was project manager for an internal product of a
remote (thousands of miles) operator's console. The engineer designing
the telecom (asynchronous) interface did not trust the MSI UARTs and
insisted on implementing the UART with available random bipolar logic.
Since this was pretty much a one-off, I didn't argue.
It did work.
--Chuck
1:14 p.m.
On 2025-01-31 15:18, Wayne S via cctalk wrote:
Steve, remember that digital electronics ( I.E.
integrated circuits like uarts) weren’t around during the early days of data
transmission. It was all analog back then, coils, capacitors, and resistors, so then ideas
regarding fast transmission had to wait for the technology to evolve. Then as ic’s became
available, what you could do with them sparked new ideas. Example: data compression within
the modem using a microprocessor, thus getting higher overall throughput than the
theoretical maximum of just the modulation rate.
Sent from my iPhone
>
Or maybe electro-mechanical some early machines used a brush turned by a
synchronous motor over a circular commutator that had segments for each
bit. On transmit when you pressed a key you closed switches connected
to the data bit segments and the motor rotated the brush around once to
transmit the character. When receiving the incoming start bit would
start the motor and as the brush went around it would pick solenoids to
select the correct character and the stop bits(s) would trip the cycle
clutch to print the character.
Paul.
12:51 p.m.
So I tested a bunch of (relatively modern, post-UART)
vintage
systems: 4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown),
386/486, and a Pentium all null-modem connected to a modern-make PC -
just to verify how fast they should be pushed (download) a data
stream. None of them (not even the Pentium) could be clocked past
115.2K on this serial line. (I know the host system isn't dictating
the speed, but whatever integrated UART is available-- then the
software that controls that UART to clock divide to "commonly defined
baud rates").
Most 80s-era UARTs probably don't support going faster than 115.2k, even
with a faster clock. In many cases you could generate arbitrary baud
rates (up to some limit tied to clock rate) by picking arbitrary
divisors, for some rapidly shrinking values of interoperability. The
8250 was deemed a bit pokey at the time, and the 16x50 chips faster,
partly because they were somewhat re-engineered, and partly because of
the built-in buffering that reduced interrupt rate on the main
processor.
- As IBM's own PC manual states, it can't be
pushed past 9600
reliably (you can, but it starts dropping characters). So despite a
UART that can technically achieve 115200, that system can't handle it
(settling on a YModem data exchange rate of about 0.9 KBps).
If you replace the brain dead BIOS serial routines, performance goes way
up. This is why the FOSSIL drivers came about. You still have the main
processor interrupt rate as a limitation, of course, but the FOSSILs
were overall much more efficient.
De
1:30 p.m.
On Fri, 31 Jan 2025, Steve Lewis via cctalk wrote:
So while some protocol gets developed for that system,
I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
2) Why is it so slow even on modern systems?
FWIW I was able to get reliable serial communication under Linux of up to
3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz
despite that line drivers used with said hardware (soldered onboard) were
spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven
operation, but then the UARTs used had decent FIFO sizes of 128 characters
and the FIFO trigger level for the interrupt was reasonably set.
Finally at 4.0Mbps data corruption reproducibly triggered, but it was
garbled rather than lost characters, so I conclude the reason was either
line drivers finally giving up or the transmission frequency hitting the
bandwidth limit of the serial communication cable used.
That was actually with POWER9 hardware rather than a boring x86 PC, but I
don't think the architecture of the system mattered much if at all.
So I tested a bunch of (relatively modern, post-UART)
vintage systems:
4.77MHz PC w/ 1.8MHz/8250, 12MHz 286 (with Unknown), 386/486, and a Pentium
all null-modem connected to a modern-make PC - just to verify how fast they
should be pushed (download) a data stream. None of them (not even the
Pentium) could be clocked past 115.2K on this serial line. (I know the
host system isn't dictating the speed, but whatever integrated UART is
available-- then the software that controls that UART to clock divide to
"commonly defined baud rates").
With slower host hardware and PIO operation this just boils down to
interrupt handling latency vs UART FIFO sizes. If a receive interrupt
cannot be served in time for the FIFO to keep from overflowing, you'll get
dropped characters. If there's no FIFO and all you have is the receive
shift register, then it's getting hopeless very quickly, just as it used
to be the case with the 8250/16450 UARTs.
With DMA (e.g. Zilog Z8530 SCC or some 8250 improvements) you should be
able to run at higher baud rates just fine even with slower host hardware
as the DMA transfer can continue between the UART and host memory while
the CPU gets to serving an interrupt request; that's how synchronous
serial protocols normally operate too.
References:
[1]
<https://lore.kernel.org/r/alpine.DEB.2.21.2106071700090.1601@angie.orcam.me.uk/>
Maciej
1:50 p.m.
On Jan 31, 2025, at 4:30 PM, Maciej W. Rozycki via
cctalk <cctalk(a)classiccmp.org> wrote:
On Fri, 31 Jan 2025, Steve Lewis via cctalk wrote:
Was that with an actual RS232 port, i.e., a device using RS232 signal levels, or a
"TTL" logic level serial port? I'm guessing the latter.
In my high speed experiments, I found that the limit for RS232 data rates comes from the
relatively slow rise/fall times implemented in RS232 drivers. If you have a port that
uses logic levels the transitions are likely to be much faster so loss of signal integrity
occurs only at much higher speeds. With the RS232 drivers I have used (MAX3222), 250 kbps
is roughly the upper limit.
paul
So while some protocol gets developed for that
system, I experimented with
other actual vintage system trying to "talk to" a modern PC (where
"modern
PC" is a 3GHz i7 laptop). For the actual task of transferring files, there
are many other better options, but I still wanted to "push the envelope" of
what classic RS232 could do on these systems.
And it was interesting that even modern-PC to modern-PC, it only handled
460Kbps. But it causes two "opposite" questions:
1) How is it even doing over 115.2Kbps? (is that still "RS232"?)
2) Why is it so slow even on modern systems?
FWIW I was able to get reliable serial communication under Linux of up to
3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz
despite that line drivers used with said hardware (soldered onboard) were
spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven
operation, but then the UARTs used had decent FIFO sizes of 128 characters
and the FIFO trigger level for the interrupt was reasonably set.
Finally at 4.0Mbps data corruption reproducibly triggered, but it was
garbled rather than lost characters, so I conclude the reason was either
line drivers finally giving up or the transmission frequency hitting the
bandwidth limit of the serial communication cable used.
7:37 p.m.
On Fri, 31 Jan 2025, Paul Koning wrote:
I'm not sure what you mean by 'a "TTL" logic level serial port',
please
elaborate. Do you mean signalling used between the UART and line drivers
by any chance, such as with a serial connection made between UARTs without
actual line drivers in between?
I've only seen such serial connections between onboard devices, such as a
SoC's onchip UART wired to an FTDI-like device soldered next to it on the
PCB for a USB serial console, which seems an industry's recent workaround
with development hardware for the usual lack of serial ports with modern
general-purpose computers. I don't expect this to work very well over a
cable unless very short.
FWIW I was
able to get reliable serial communication under Linux of up to
3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz
despite that line drivers used with said hardware (soldered onboard) were
spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven
operation, but then the UARTs used had decent FIFO sizes of 128 characters
and the FIFO trigger level for the interrupt was reasonably set.
Finally at 4.0Mbps data corruption reproducibly triggered, but it was
garbled rather than lost characters, so I conclude the reason was either
line drivers finally giving up or the transmission frequency hitting the
bandwidth limit of the serial communication cable used.
Was that with an actual RS232 port, i.e., a device using RS232 signal
levels, or a "TTL" logic level serial port? I'm guessing the latter.
In my high speed experiments, I found that the limit
for RS232 data
rates comes from the relatively slow rise/fall times implemented in
RS232 drivers. If you have a port that uses logic levels the
transitions are likely to be much faster so loss of signal integrity
occurs only at much higher speeds. With the RS232 drivers I have used
(MAX3222), 250 kbps is roughly the upper limit.
The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F
line driver, which according to the manufacturer's datasheet signals at
±5V minimum transmitter voltage levels and accepts up to ±25V receiver
voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24
Specifications for VCC at +3.3V ±10% and +5V ±10% Operations." While the
transmitter voltage levels are not the highest recognised by the standard
I do believe this line driver does comply with RS-232.
As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps,"
and according to my findings quoted above it is indeed the case (and well
beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental
slip I suppose.]
NB I've also used the TI TRS3122E line driver, suitable for operation
with 1.8V signalling per my requirement, and it is also documented to
handle "data rates up to 1000kbps, while maintaining RS-232-compatible
output levels." I haven't got a chance to go beyond 230400bps with this
device though, but these two samples do suggest that supported operation
at 1Mbps isn't that uncommon for currently available RS-232 line drivers.
I've looked up the MAX3222 datasheet and it does say 250kbps max though;
I guess it's older technology then?
Does this answer your question?
Maciej
8:11 p.m.
On Fri, Jan 31, 2025, 8:37 PM Maciej W. Rozycki via cctalk <
cctalk(a)classiccmp.org> wrote:
On Fri, 31 Jan 2025, Paul Koning wrote:
I'm not sure what you mean by 'a "TTL" logic level serial port',
please
elaborate. Do you mean signalling used between the UART and line drivers
by any chance, such as with a serial connection made between UARTs without
actual line drivers in between?
Yes. That's the overwhelming majority of usage these days. At least for me
when not dealing with retro gear.
I've only seen such serial connections between onboard devices, such as a
> FWIW I was able to get reliable serial
communication under Linux of up
to
> 3.5Mbps with off-the-shelf proper PCIe UART
hardware clocked at
62.5MHz
> despite that line drivers used with said
hardware (soldered onboard)
were
> spec'd for up to 1MHz only[1]. This was
with plain PIO
interrupt-driven
> operation, but then the UARTs used had
decent FIFO sizes of 128
characters
> and the FIFO trigger level for the interrupt
was reasonably set.
>
> Finally at 4.0Mbps data corruption reproducibly triggered, but it was
> garbled rather than lost characters, so I conclude the reason was
either
> line drivers finally giving up or the
transmission frequency hitting
the
bandwidth
limit of the serial communication cable used.
Was that with an actual RS232 port, i.e., a device using RS232 signal
levels, or a "TTL" logic level serial port? I'm guessing the latter.
SoC's onchip UART wired to an FTDI-like device
soldered next to it on the
PCB for a USB serial console, which seems an industry's recent workaround
with development hardware for the usual lack of serial ports with modern
general-purpose computers. I don't expect this to work very well over a
cable unless very short.
Yea, line drivers are to make runs over a few feet.
Warner
In my high speed experiments, I found that the limit
for RS232 data
rates comes from the relatively slow rise/fall
times implemented in
RS232 drivers. If you have a port that uses logic levels the
transitions are likely to be much faster so loss of signal integrity
occurs only at much higher speeds. With the RS232 drivers I have used
(MAX3222), 250 kbps is roughly the upper limit.
The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F
line driver, which according to the manufacturer's datasheet signals at
±5V minimum transmitter voltage levels and accepts up to ±25V receiver
voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24
Specifications for VCC at +3.3V ±10% and +5V ±10% Operations." While the
transmitter voltage levels are not the highest recognised by the standard
I do believe this line driver does comply with RS-232.
As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps,"
and according to my findings quoted above it is indeed the case (and well
beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental
slip I suppose.]
NB I've also used the TI TRS3122E line driver, suitable for operation
with 1.8V signalling per my requirement, and it is also documented to
handle "data rates up to 1000kbps, while maintaining RS-232-compatible
output levels." I haven't got a chance to go beyond 230400bps with this
device though, but these two samples do suggest that supported operation
at 1Mbps isn't that uncommon for currently available RS-232 line drivers.
I've looked up the MAX3222 datasheet and it does say 250kbps max though;
I guess it's older technology then?
Does this answer your question?
Maciej
1:55 p.m.
On 2025-01-31 14:44, Steve Lewis via cctalk wrote:
But for other fodder, I'm reading over the async card for the IBM 5110.
Page 12 of this IBM 5110 doc has a block diagram of IBMs version of
"asynchronous card" -
SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf
<http://www.bitsavers.org/pdf/ibm/5110/diagrams/SY31-0552-3_IBM_5110_System_Logic_Manual_197902.pdf>
And its manual (from 1978) has some interesting paragraphs (plus how that
system was apparently obsessed with showing text-mode graphs of the error
rates; line quality is apparently still very rough by late 1970's):
SY31-0557-0_5110asyncComm_Jan1978.pdf
<http://www.bitsavers.org/pdf/ibm/5110/SY31-0557-0_5110asyncComm_Jan1978.pdf>
-SteveL
Line quality depended on what you wanted to pay for. Voice grade lines
have a few problems the main ones being the limited bandwidth and echo
suppressors. But in the late 70s when I started with TP equipment, and
probably earlier you could also get "conditioned" lines that had a much
wider bandwidth and no echo suppressors. I recall people running 56K
baud and higher synchronous lines, but they did not use RS232 but rather
they used a V.35 interface. Already at that time people where using
fancy means to increase speed, I recall modems that used phase shift
keying and 90 degree shifts so you could encode 2 bits in every phase
shift by shifting by 0, 90, 180, and 270 degrees. In the late 70 early
80s I know for sure IBM communication controllers supported line groups
where the data would be fired down multiple pipes to get higher
throughput. I also recall dial-up conditioned lines that had a
special phone set on them that you could use to talk to people at the
other end, talking on them was line talking in a tunnel.
Paul.
10:14 a.m.
On Jan 31, 2025, at 8:37 AM, David Wade via cctalk
<cctalk(a)classiccmp.org> wrote:
On 31/01/2025 11:56, ben via cctalk wrote:
> On 2025-01-31 4:25 a.m., Frank Leonhardt via cctalk wrote:
>
>> A couple of points you might like to consider, which you may already know but
stuff you've said above doesn't spell it out:
>>
>> RS232 is not serial - make yourself clear. Before RS232 the same data format was
used in current loop (often 20mA or 60mA).
>>
>> RS232 (AKA V.24) is only understandable when you realise it was connecting a
terminal (or later computer) to a modem. It's very specific, yet like most technology
has been subverted for other purposes. I've kept at last one full RS232 modem in my
loft (it was government surplus, and I used to to run a BBS in 1980). Things got weird
later, particularly with the Hayes Smartmodem, but modems were dumb devices. The lines
went straight through. There were two oscillators (for FM) and the appropriate one was
switched in by the TX line being high or low. Likewise the data separator looked for a
high or low tone and flipped RX between -12V and +12V. These were all individual boards!
Low speed modems are just analog devices that can pass any signal up to whatever the
design speed limit is. For example, a 103 modem is good up to 300 bps, but will happily
carry anything less. A 202 modem (see below) is designed for 1200 but also will work at
lower speeds, and has been used at 1260 bps.
Faster modems use signalling schemes that involve clocked signal elements. QPSK (for the
212 modem) is likely one of these, and for the speeds above that it is definitely true.
So there the modem isn't just an on/off signaling pass-through device.
DTR/DSR - Is comms up and running
RI - Ring Indicator - a call has arrived
TCK/RCK - Used for timing on synchronous links so BI-SYNC/SDLC/HDLC
LL/RL - enable loop back...
There is also a secondary channel which can be used for out-of-band control...
Or for split-speed communication. Yes, by the time you have all that you're close to
using up 25 pins. Another consideration is that equipment at the time was much larger
than nowadays so the connector used was actually quite small for the time. Some other
modems used the V.35 standard (for high speeds) with a connector whose designation I
don't remember that's a whole lot bigger than the DB25.
An example of that is the not so well known Bell 202 modem. That uses FSK signaling like
the 103 modem but at higher speed, with a shift of (I think) 1000 Hz. Between that and
the data rate it ties up the entire voice channel one way, so if you wanted to use it in
full duplex mode you'd need four wires, rather than the standard Telco 2 wire circuit.
Alternatively you could use two wires half duplex. An example of the latter is the
original Ham radio "packet radio" system, which used 202 signaling carrying HDLC
frames. A standard 202 modem would do that just fine since it's a purely analog
device, but you need a separate clock recovery circuit.
Another place where 202 signaling is found is in the original PLATO IV terminal
commmications system. That is 1200 bps (or more precisely 1260 which works too) outbound
to the terminal, and something slow (126 bps) the other way. When carried over a modem
that would use the "1200" baud regular channel of the 202 outbound, and the
secondary channel inbound. There's enough bandwidth in the phone line to tuck away an
FSK band slice for that slow speed in what's left over from the 1200 bps channel the
other way.
Now every
thing seems to be just 3 wire TTL.
Lots of thinks need hardware handshake...
Before RS232, how many wires where needed for the
current loop
So RS232 was designed for modems, so audio tones on a phone line. So:-
Computer <= RS232=> Modem <= audio on phone line => Modem <=RS232=>
Terminal.
Confusingly both the computer and terminal are called "Data Terminal Equipment"
(DTE) and the modems are data communications equipment or DCE,
Current Loop was a physical connection, no modem, so just 2-wires for half-duplex,
4-wires for full duplex. For long lines you can use polar relays.. 
3:19 p.m.
Low speed modems are just analog devices that can pass
any signal up to
whatever the design speed limit is. For example, a 103 modem is good up
to 300 bps, but will happily carry anything less. A 202 modem (see
below) is designed for 1200 but also will work at lower speeds, and has
been used at 1260 bps.
I'd argue those are differing situations, though. Bell 103 and Bell 101 modems
use the same AFSK frequencies, just at different speeds. Bell 202 modems have
specific hardware to support Bell 103, effectively two modems in the same case.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Excellent guess, Kreskin. Wrong, but excellent. -- Space Quest 6 -----------
1:31 p.m.
On Fri, 31 Jan 2025, David Wade via cctalk wrote:
Lets look at some of the other pins:-
RTS/CTS - Request to send/clear to send - Hardware flow control.
DTR/DSR - Is comms up and running
RI - Ring Indicator - a call has arrived
TCK/RCK - Used for timing on synchronous links so BI-SYNC/SDLC/HDLC
LL/RL - enable loop back...
The first printers that I used on TRS80 were aSilent 700, and
later, a DTC300 (Hytype 1 printing terminal)
It took a while to figure out the cabling.
Interfacing printers to microcomputers was sometimes confusing.
Joe Capbells book "The RS232 Solution" was primarily about that.
There was even a case where a user handed over computer and printer to a
store to get an appropriate cable; after an excessive length of time, the
user shot and killed the store owner.
The first parallel printers might have been Centronics. Hence the
interface and blue ribbon connector being called "Centronics parallel"
The Epson MX-80 became one of the most popular; the FX-80 was an enhanced
descendent of it.
"serial" could be used to refer to only using one signal wire (plus a
groun).
But, it can also refer to whether the bits were sent one at a time, or in
parallel.
1:57 p.m.
On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
The first parallel printers might have been
Centronics. Hence the
interface and blue ribbon connector being called "Centronics parallel"
The first printer that Radio Shack/Tandy sold for the TRS-80 (at least
in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of
course) -- was a rebadged Cantronics with the obvious parallel
interface. I have the Centronics version here and repair it using the
Radio Shack service manual.
-tony
3:07 p.m.
On 1/31/25 13:57, Tony Duell via cctalk wrote:
On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
Out in the field during the late 60s and 70s, I found that the
Dataproducts interface was more common than the Centronics.
--Chuck
The first parallel printers might have been
Centronics. Hence the
interface and blue ribbon connector being called "Centronics parallel"
The first printer that Radio Shack/Tandy sold for the TRS-80 (at least
in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of
course) -- was a rebadged Cantronics with the obvious parallel
interface. I have the Centronics version here and repair it using the
Radio Shack service manual.
12:48 p.m.
On Fri, 31 Jan 2025, Frank Leonhardt via cctalk wrote:
And for amusement, someone wrote in the PCW saying
they'd heard a
salesperson at Radio Shack trying to convince a punter that RS is RS232
stood for Radio Shack.
I have seen a Radio Shack store manager (Albany, California) say exactly
that, in response to a customer gripe about TRS80 serial port not
completely matching the RS232 spec.
3:49 a.m.
On 31/01/2025 08:20, Steve Lewis via cctalk wrote:
Hey all! So, I've found myself studying up on
RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
Prior to computers, TTY circuits, or TELEX systems used current loop,
typically 60ma. So usually 100volts with a current limiting resistor.
This allows long lines, with the high voltage overcoming the inductance
in the operating magnet...
From what I've read, "50 baud" was a
kind of an initial goal to beat, since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
In Europe I believe we use 45.5 baud. Certainly European hams used 45.5
baud.
Then 75/110/130 baud to have digital-systems
interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure
what a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Just expensive to make faster. The IBM2741 could do 300 baud but is I
think is rather more complex that a tty.
Then, was it the SAGE program that demonstrated the
idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
so the 2741 used a 103.
I couldn't find much details (like a manual) on
the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
Why do you need a UART? It just takes serial data and spits it out.....
I know from 1962, both RS232 and ASCII standards still
took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Not always. Lots used parallel keyboards.
Well, sorry for the rambling - have other RS232
related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
Dave
4:19 a.m.
I can provide some details of implementation, but not the design phase,
from the early 1970s era.
I worked as an FE on a site with three Univac 418s ( 4 us cycle time,
18-bit bus) for Bell Canada from 1971-1975, which were connected to a
store-and forward message switcher using Teletype machines with 85A1
controllers. I believe that the system was installed in 1968.
The system drove 64 teletype lines all over Canada, and certainly
current-loop was the flavor-du-jour when it came to long distance
telegraphy, I remember getting some nasty shocks from the 130VDC on the
lines needed to drive the 60 mA current loops.
I would say that the current loops themselves were the main factor that
limited baud rate - each line had mercury-whetted relays as it left our
floor to drive the line down eight floor to the telegraph operating centre.
There were no crystals, clocking was done using RCL networks, and one of
my routines was to check and adjust the baud rate using a scope on all
lines. There were separate tunable inductors on a card in each serial
line controller for actual baud rate and duty cycle. I know this full
well because one Sunday morning, during scheduled down time, I went
through and adjusted all these the wrong way - adjusting the baud rate
coil for duty cycle and vice versa. Needless to say, I found God that
morning as I panic-strickenly tried and found my mistake and managed to
correct it just before my boss arrived after he was called in due to the
delayed startup! AFAIK he never found out what I did, but the yards and
yards of console paper with error messages proved I was not making it
up! The console of the 418 was a Teletype machine also, running at 110Baud.
Each serial line was controlled by two rows of cards, mounted in a 6U
panel 23 inches wide. There were no UARTS! There were 16 lines in each
CTMC cabinet (Communications Terminal Mode(?) Controller) sometimes
called SCS cabinets (Serial Communications Subsystems).
Next to the CTMC cabinets, We had a cabinet full of Bell 103 modems,
used for dialling out on to the TWX (Teletypewriter Exchange) network
. I believe there were some modems for the new high-speed 300 baud,
but I don't think they were used in production while I was there. Some
300-baud GE Terminettes appeared later which I heard of from old
friends. Incidentally, TWX lines were regular telephone lines, and had a
regular telephone number iun adidtion to their TWX number. For example,
in Toronto, the (610) 491-xxxx TWX number was translated to (416)
962-xxxx. I really impressed my work mates by dialling in to our
maintenence room and waking them up with a lot of Bells during the night
shift :-)
AFAIK, there were only 3 sites with Univac 418s in Toronto. Ours at
Bell, CN/CP Telecom had one doing the same job, and there was one at
Police HQ running the traffic lights around the city.
One time I had to get parts from the Univac FEs at the other telecom
company and showing my Bell ID at the door was strictly guarded while
the FE got the parts - such was the competitiveness between telecom
companies at 110 Baud!
Wonderful memories, thanks for triggering them!
cheers,
Nigel
On 2025-01-31 03:20, Steve Lewis via cctalk wrote:
Hey all! So, I've found myself studying up on
RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
From what I've read, "50 baud" was a kind of an initial goal to beat,
since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
Then 75/110/130 baud to have digital-systems interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure
what a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
I couldn't find much details (like a manual) on the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
I know from 1962, both RS232 and ASCII standards still took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Well, sorry for the rambling - have other RS232 related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
5:08 a.m.
On 31/01/2025 08:20, Steve Lewis via cctalk wrote:
<snip>
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud?
Almost forgot - why 300 baud? The modem the RS232 was driving was
modulating over standard telephone lines, which are obviously audio.The
original ones used Frequency Shift Keying (FSK)- basically switching
between high and low tones for zero and one. You need a certain amount
of tone to be present for a bit to register.
Given you want full duplex you need four frequencies (two each for high
and low). These were 1080Hz, 980Hz, 1750Hz and 1650Hz - i.e. 100Hz apart
for two pairs. The pairs needed a gap of around 600Hz between them so
they wouldn't be confused after the telephone system had mangled the sound.
In Europe the POTS bandwidth was around 3K, in the USA it was 2K (but
not starting at zero) so these frequencies were sufficiently inside the
available bandwidth to get to the other side.
If you up the bps you come to a point where there won't be enough of the
mark frequency to be detected - it won't have enough complete cycles.
And that point was basically 300 baud.
980Hz divided by 300 gives about 3 complete cycles to indicate a mark,
which is the minimum you need for easy detection by an analogue circuit.
Incidentally, the US had Bell 103 at up to 300 baud, Europe and V.21
which was slightly better but used the same frequencies. When originally
launched they were used at 110. You also get problems squirting tones
through the telephone system it also uses tones for internal signalling
and if you send harmonics you'll re-route the call. Bell 212 at
600/1200bps (aka V.22) used more complex QPSK modulation to encode more
than one bit per cycle. That's the one that sounded like someone being
sick down the phone line, as one of my colleagues put it. Eventually
more complex standards got to a total data rate of 56Kbps. Given the
telephone network by this time digitised at 64kbps, you'd be breaking
the laws of physics if you got a higher rate than that. Getting 56K was
pretty impressive in the circumstances. Regards, Frank.
5:09 a.m.
On 31/01/2025 08:20, Steve Lewis via cctalk wrote:
<snip>
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud?
Almost forgot - why 300 baud? The modem the RS232 was driving was
modulating over standard telephone lines, which are obviously audio.The
original ones used Frequency Shift Keying (FSK)- basically switching
between high and low tones for zero and one. You need a certain amount
of tone to be present for a bit to register.
Given you want full duplex you need four frequencies (two each for high
and low). These were 1080Hz, 980Hz, 1750Hz and 1650Hz - i.e. 100Hz apart
for two pairs. The pairs needed a gap of around 600Hz between them so
they wouldn't be confused after the telephone system had mangled the sound.
In Europe the POTS bandwidth was around 3K, in the USA it was 2K (but
not starting at zero) so these frequencies were sufficiently inside the
available bandwidth to get to the other side.
If you up the bps you come to a point where there won't be enough of the
mark frequency to be detected - it won't have enough complete cycles.
And that point was basically 300 baud.
980Hz divided by 300 gives about 3 complete cycles to indicate a mark,
which is the minimum you need for easy detection by an analogue circuit.
Incidentally, the US had Bell 103 at up to 300 baud, Europe and V.21
which was slightly better but used the same frequencies. When originally
launched they were used at 110. You also get problems squirting tones
through the telephone system it also uses tones for internal signalling
and if you send harmonics you'll re-route the call. Bell 212 at
600/1200bps (aka V.22) used more complex QPSK modulation to encode more
than one bit per cycle. That's the one that sounded like someone being
sick down the phone line, as one of my colleagues put it. Eventually
more complex standards got to a total data rate of 56Kbps. Given the
telephone network by this time digitised at 64kbps, you'd be breaking
the laws of physics if you got a higher rate than that. Getting 56K was
pretty impressive in the circumstances. Regards, Frank.
6:15 p.m.
I own my entire working career to some random happenings as a kid with
interfacing equipment to IBM PC clones using RS232.
As a late teenager I used to hang out at the local computer store who sold
Toshiba gear. I had a knack for making cables that allowed them to connect
brother printers using RS232.
One day a person from the local university dropped in asking if they knew
anybody who could help interface a piece of lab gear to their Toshiba
PC... I got recommended..
Then I helped to write the software to do the analysis work for them...
That was in about 1986.. and here we are in 2025 some 40 years later...
Remember
2 to 3
3 to 2
7 to 7
4, 5 to 6
6 to 4, 5
8 to 20
And 20 to 8...
And if that didn't work. Just tie those pesky handshaking inputs to their
nearest output and use software handshaking 😜...
Built a career on that.. I cringe a little now I understand the intent of
the signals.
Doug
On Fri, 31 Jan 2025, 7:20 pm Steve Lewis via cctalk, <cctalk(a)classiccmp.org>
wrote:
Hey all! So, I've found myself studying up on
RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
From what I've read, "50 baud" was a kind of an initial goal to beat,
since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
Then 75/110/130 baud to have digital-systems interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure
what a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
I couldn't find much details (like a manual) on the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
I know from 1962, both RS232 and ASCII standards still took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Well, sorry for the rambling - have other RS232 related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
6:31 p.m.
In 1977, at age 16, I went to work for Noakes Data Communications in Irving Texas.
We built an 8080 industrial computer, made modems, and repaired lots of comm gear.
RS232 was what we lived and breathed. And back then almost all the control signals were
actually used, not just jumpered or ignored.
I remember thinking at the time that the bipolar signal levels were such a waste of time
for office and personal computers. They should have just gone to a TTL version for
everything local like printers, and modems, and keyboards and terminals. Back then we had
to use 1488 and 1489 level converters with +/-12v power supplies. Such a costly hassle.
Of course, many years later we got MAX232 with 4 .1uf caps and 5v which solved the cost
problem.
I still have my blue breakout box from that year. It cost something like $300 at the time
which was the price of a used car 🙂
I documented the company here:
https://www.rogerarrick.com/noakes/
[https://www.rogerarrick.com/noakes/noakes_label.png]<https://www.rogerar…
Noakes Data Communications - Irving Texas -
1970s-1980s<https://www.rogerarrick.com/noakes/>
Noakes Data Communications. 1 May 2023. Click images for larger view 1973-1987 Noakes Data
Communications 3330 Stovall St, Irving, TX 75061 214-790-1050
www.rogerarrick.com
-- Roger Arrick -- Tyler, Texas, USA -- Roger(a)Arrick.com --
________________________________
From: Doug Jackson via cctalk <cctalk(a)classiccmp.org>
Sent: Friday, January 31, 2025 8:15 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: Steve Lewis <lewissa78(a)gmail.com>om>; Doug Jackson <doug(a)doughq.com>
Subject: [cctalk] Re: RS232 then and now
I own my entire working career to some random happenings as a kid with
interfacing equipment to IBM PC clones using RS232.
As a late teenager I used to hang out at the local computer store who sold
Toshiba gear. I had a knack for making cables that allowed them to connect
brother printers using RS232.
One day a person from the local university dropped in asking if they knew
anybody who could help interface a piece of lab gear to their Toshiba
PC... I got recommended..
Then I helped to write the software to do the analysis work for them...
That was in about 1986.. and here we are in 2025 some 40 years later...
Remember
2 to 3
3 to 2
7 to 7
4, 5 to 6
6 to 4, 5
8 to 20
And 20 to 8...
And if that didn't work. Just tie those pesky handshaking inputs to their
nearest output and use software handshaking 😜...
Built a career on that.. I cringe a little now I understand the intent of
the signals.
Doug
On Fri, 31 Jan 2025, 7:20 pm Steve Lewis via cctalk, <cctalk(a)classiccmp.org>
wrote:
![https://www.rogerarrick.com/noakes/noakes_label.png]<https://www.rogerar…](https://www.rogerarrick.com/noakes/noakes_label.png]%3Chttps://www.rogerarrick.com/noakes/%3E){kind=link}
Hey all! So, I've found myself studying up on
RS-232 this year for a few
reasons.
I'm mulling over doing an RS232 themed talk at June VCF. Not a super
exciting topic, but I do think that RS232 has an interesting history: In
the SAGE relationship, and as a follow up to (essentially) prior telegraph
communication.
From what I've read, "50 baud" was a kind of an initial goal to beat,
since
that's what the top telegraph operators could achieve (in small burst,
probably not all day). And those operators did have to also deal with
things like start/stop "bits". Maybe it wasn't an intentional goal, but
just that it establishes why "50 baud" is generally the lowest we ever see
mentioned (or, if you go slower than that, might as well use the older
tech).
Then 75/110/130 baud to have digital-systems interoperate with classic
mechanical teletypes. Going any faster and those systems jam up or
overheat? These weren't yet called "serial ports", so I'm not sure
what a
late 50s system would even call their equipment that facilitate this data
exchange (since I'm not sure what kind of crystal-clock they even had
yet).
Then, was it the SAGE program that demonstrated the idea of doing this kind
of data exchange across copper phone lines? That is, the idea of computers
collaborating not just in a room, but across long distances (miles)? And
doing so by using an audio tone presentation? (they settled on around
3100MHz, which ended up translating to 300 baud? hence, that's basically
why the first digital to digital system data exchange settled on that baud
rate, which was reliable on both 50 and 60Hz power systems, and
meaningfully faster than prior 110 baud - so a good milestone to turn it
into a product, which was the Bell Model 103?).
I couldn't find much details (like a manual) on the Bell 101 equipment
(anyone seen one or have a manual?). But I did find the Bell 103 manual -
the photo of its innards is grainy, so I don't understand how the Bell 103
did 300 baud without a UART (and one of the pinout lines I see did run
power, so not sure if that's-yet RS232 or not; I know RS232 was evolving
right at that same time circa 1962). I've about the 1970ish TR1402
initial DIP UART, with anything prior being an experiment (like a full
board concept by DEC).
I know from 1962, both RS232 and ASCII standards still took maybe another
decade to really gain traction as standards (at least, from what I've
read). Getting the world to comply with any standard always takes a lot of
effort (for a practical reason of everyone still having invested in the
older tooling that was still functional). But it's interesting how those
two standards are still in use (not in their original form, but least the
1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs.
Does anyone know of any grocery stories using RS232 in the 1960s? I think
barcode scanning was just introduced in that era. I can just imagine a
smart grocery store owner, in the backroom programming their minicomputer
for payroll and inventory management. In FORTRAN and without a CRT?
Actually, in the 60s, I think included software would be negotiated with
the provider of the computer (well, I'm not sure how that differed between
minis and mainframes).
I know early microcomputers used RS232 for keyboards (1974-1976 era). The
IBM PC keyboard is essentially another form of serial.
Well, sorry for the rambling - have other RS232 related questions, but
first wanted to focus on the historical aspects (and see if I'm somewhat on
the right track at least).
-Steve
0
days inactive
1
days old
40 comments
20 participants
participants (20)
-
ben -
Cameron Kaiser -
Chuck Guzis -
David Wade -
Dennis Boone -
Doug Jackson -
Frank Leonhardt -
Frank Leonhardt -
Fred Cisin -
Lars Brinkhoff -
Maciej W. Rozycki -
Nigel Johnson Ham -
Paul Berger -
Paul Koning -
Peter Corlett -
roger arrick -
Steve Lewis -
Tony Duell -
Warner Losh -
Wayne S