31 Jan
2025
31 Jan
'25
8: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
11: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
11: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.
12:30 p.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. 
12:58 p.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.
1:37 p.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
2:06 p.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.
3:23 p.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.
4:19 p.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.
5:43 p.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
9: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.
9: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.
4:19 p.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.
6:44 p.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.
6:55 p.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
6:55 p.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.
>
>
>
7:02 p.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
7:18 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.
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.
>>
>>
>>
8: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
2 Feb
2 Feb
7:47 p.m.
New subject: RS232 then and now (bitbanging)
I came across the following more recent discussion:
2022-05-05 Bit banging on a Tandy CoCo1 - Wikistix
<https://www.stix.id.au/wiki/2022-05-05_Bit_banging_on_a_Tandy_CoCo1>
And it reminded me of some of my own past exploration into systems that did
RS232 without an UART.
One example is the NEC PC-8001 (system from about 1979). I recall having
trouble getting it past 600 baud for some reason.
Another example is the Color Computer 3. UltimateTerm 2.4 from 1987 could
bit-bang reliably 9600 baud (also Twilight Term from 1996). The CoCo3 had
a higher speed CPU option than its original. "bit banging" (imo) is the
host system doing the work of producing the start/stop bits on its own.
Which seems to be a "lost art" and why I've wondered if anyone has tried
bit-banging on a modern-day 3GHz system - but bit-bang onto what? They took
away our serial and parallel ports, like talking directly to a pin is now
taboo (literally a security risk, as some networks lock out CD drives and
USB also - "no information out" policies).
With the UART assist of the RS232Pak cartridge, a CoCo3 managed 115200 baud
using a very optimized NetMate terminal written in 2021. That's with the
6551 ACIA doing the serializing work (but I don't think it has any FIFO at
all).
I've been curious how much faster Interlink/Laplink/FastLynx really was
across a parallel cable (I've yet to find reliable bytes-per-second rate
info on those). On modernPC to modernPC I really was able to achieve
45KBps (bytes per second) on a 460Kbps serial connection (USB/serial
adapters; ones with 128 byte FIFO) using regular ZModem protocol.
There are "laplink-style-USB" things, but I'm still curious if we did
USB/parallel adapters and a classic laplink cable on two modern PCs, could
it surpass the 45KBps serial connection? Still a relic approach, as modern
day WiFi+samba should be faster. But where is any modern-make software to
even try?
-Steve
On Fri, Jan 31, 2025 at 2:13 PM Paul Koning via cctalk <
cctalk(a)classiccmp.org> wrote:
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
8:23 p.m.
New subject: RS232 then and now (bitbanging)
On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
[...] "bit banging" (imo) is the
host system doing the work of producing the start/stop bits on its own.
Which seems to be a "lost art" and why I've wondered if anyone has tried
bit-banging on a modern-day 3GHz system - but bit-bang onto what?
CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was designed before the
Philips(?) patents expired.
I know there are controllers for SPI that eliminate the need for bit-banging, and
message-layer CAN controllers; but some people still do low-speed bit-banging
implementations, or subset implementations. IMHO hardware controllers are so cheap that
bit-banging doesn't make sense, given development time, and that it consumes a
dedicated CPU core while sending or receiving.
8:45 p.m.
New subject: RS232 then and now (bitbanging)
On Feb 2, 2025, at 3:23 PM, Jonathan Stone via cctalk
<cctalk(a)classiccmp.org> wrote:
On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
Bit banging also works if you have devices that specialize in it. A nice example is the
Programmable I/O (PIO) engines in the Raspberry Pico microcontroller.
I did a DDCMP implementation with those, including the "integral modem" feature.
That includes clock recovery and demodulation of the FM signal, at speeds up to 10 Mb/s
or so though of course no DEC DDCMP device ever ran nearly that fast. It looks like it
could also do 10 Mb/s Ethernet directly (handling AUI waveforms in software) -- I
haven't tried that but I might just for fun.
It would also be an easy way to do the 10 bit UART and 19 bit USRT needed to drive a PLATO
terminal.
I also used this machinery to drive a software-defined radio chip from Harris/Intersil, on
a board I originally designed for EPP mode parallel printer port interfacing. It has a 16
bit serial port that just runs continously, and the PIO handles that nicely. Similar but
different is the bit-serial interface you'll find on audio DAC devices, that too would
be a very simple case.
As for SPI, the standard driver for the CYW43439 WiFi chip on the Pico uses PIO to deal
with the not quite standard SPI used by that device. Or at least the mismatch in
expectations.
SPI is only barely standardized and it suffers very badly from the Dave Clark effect
("so many standards to choose from"). For example, the ENC28J60 Ethernet MAC
chip has a SPI interface that does multi-byte transfers with the CS signal asserted for
the entire time, while the "mode 0" SPI standard apparently says it's
dropped in between every byte. One solution is to ignore the built-in SPI blocks and use
the PIO; another is to use the standard SPI block but override the CS pin in software so
it remains asserted even though the SPI block dropped the assert. Ugh.
This sort of bit banging design is very effective as well as cost-effective, considering
that a Pico sells for $4 (quantity one, a whole module -- the chip alone is under a dollar
if I remember right).
paul
[...] "bit banging" (imo) is the
host system doing the work of producing the start/stop bits on its own.
Which seems to be a "lost art" and why I've wondered if anyone has tried
bit-banging on a modern-day 3GHz system - but bit-bang onto what?
CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was designed before
the Philips(?) patents expired.
I know there are controllers for SPI that eliminate the need for bit-banging, and
message-layer CAN controllers; but some people still do low-speed bit-banging
implementations, or subset implementations. IMHO hardware controllers are so cheap that
bit-banging doesn't make sense, given development time, and that it consumes a
dedicated CPU core while sending or receiving.
3 Feb
3 Feb
7:44 a.m.
New subject: RS232 then and now (bitbanging)
Well... From what I've seen (in these 1980 microprocessor cases), they are
using "bit shifters" to help pull off their bit banging. So it's not a
true self sufficient kind of bit banging.
I'm defining a UART as something that also does the work of applying the
start/parity and stop bit. The earliest "spec" of a UART that I'm finding
is the 1972-ish WD1402A, which does use that term "UART" and has that
feature of adding in these bits as programmed (e.g. No Parity would not
have the parity bit, and "two stop bits" if so programmed). But it
doesn't
have its own "baud generator" like later UARTs, the baud rate is
"externally selectable". Then on receive, does the opposite so that the
host is just handed a nice packaged byte.
The CoCo relies on the 6521 PIA (early Commodore's used something similar,
later ones using VIA's - still similar), a category of "bit shifters." If
they take a full byte, then you may need two bytes to formulate a proper
RS232 signal (since they need up to 10 or 11 bits with parity). If it's
normal 8-N-1, maybe with some really creative bit twiddling you could make
use of the extra 6-bits in the second byte (if it was a streamed buffer of
data, so that you knew the next byte to send). Anyway, doing this without
even a "bit shifter" assist is truly bit-banging!
And now I understand better that to make this RS232, it has to be "level
shifted" and the components involved have to be fast enough to provide that
kind of "voltage swing." And this swing makes the signal loud and clear,
even in noisy industrial environments, across fairly long distances. All
that's kind of a waste for a modem that's just a foot away in a quiet
room. For telescope work, I recall experienced setups running 100+
meter serial lines to a remote observatory across the property (and not
being able to do so with USB; but now-a-days there are powered USB
repeaters - though not sure how I'd feel about burying those compared to
long serial cables).
Well, all this RS232 conversation also revealed to me about the
current-loop interface on the IBM serial card. Never noticed that before!
IBM 5150 Technical Reference 6025005 AUG81
<https://www.minuszerodegrees.net/manuals/IBM_5150_Technical_Reference_6025005_AUG81.pdf>
Page 2-126 (specifies 20mA and what pins)
And 2-146 shows how to set the jumper (shunt module).
Sort of like the RCA-out pins on CGA cards- an obscure left over part.
Which I still never quite figured out how to adapt those 4-pins over to an
RCA round connector.
-Steve
On Sun, Feb 2, 2025 at 2:45 PM Paul Koning via cctalk <cctalk(a)classiccmp.org>
wrote:
designed before the Philips(?) patents expired.
On Feb 2, 2025, at 3:23 PM, Jonathan Stone via
cctalk <
cctalk(a)classiccmp.org> wrote:
On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk <
cctalk(a)classiccmp.org> wrote:
[...] "bit banging" (imo) is the
host system doing the work of producing the start/stop bits on its own.
Which seems to be a "lost art" and why I've wondered if anyone has tried
bit-banging on a modern-day 3GHz system - but bit-bang onto what?
CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was
I know there are controllers for SPI that eliminate the need for
bit-banging, and message-layer CAN controllers; but some people still do
low-speed bit-banging implementations, or subset implementations. IMHO
hardware controllers are so cheap that bit-banging doesn't make sense,
given development time, and that it consumes a dedicated CPU core while
sending or receiving.
Bit banging also works if you have devices that specialize in it. A nice
example is the Programmable I/O (PIO) engines in the Raspberry Pico
microcontroller.
I did a DDCMP implementation with those, including the "integral modem"
feature. That includes clock recovery and demodulation of the FM signal,
at speeds up to 10 Mb/s or so though of course no DEC DDCMP device ever ran
nearly that fast. It looks like it could also do 10 Mb/s Ethernet directly
(handling AUI waveforms in software) -- I haven't tried that but I might
just for fun.
It would also be an easy way to do the 10 bit UART and 19 bit USRT needed
to drive a PLATO terminal.
I also used this machinery to drive a software-defined radio chip from
Harris/Intersil, on a board I originally designed for EPP mode parallel
printer port interfacing. It has a 16 bit serial port that just runs
continously, and the PIO handles that nicely. Similar but different is the
bit-serial interface you'll find on audio DAC devices, that too would be a
very simple case.
As for SPI, the standard driver for the CYW43439 WiFi chip on the Pico
uses PIO to deal with the not quite standard SPI used by that device. Or
at least the mismatch in expectations.
SPI is only barely standardized and it suffers very badly from the Dave
Clark effect ("so many standards to choose from"). For example, the
ENC28J60 Ethernet MAC chip has a SPI interface that does multi-byte
transfers with the CS signal asserted for the entire time, while the "mode
0" SPI standard apparently says it's dropped in between every byte. One
solution is to ignore the built-in SPI blocks and use the PIO; another is
to use the standard SPI block but override the CS pin in software so it
remains asserted even though the SPI block dropped the assert. Ugh.
This sort of bit banging design is very effective as well as
cost-effective, considering that a Pico sells for $4 (quantity one, a whole
module -- the chip alone is under a dollar if I remember right).
paul
2 Feb
2 Feb
10:18 p.m.
New subject: RS232 then and now (bitbanging)
And it reminded me of some of my own past exploration
into systems that did
RS232 without an UART.
One example is the NEC PC-8001 (system from about 1979). I recall having
trouble getting it past 600 baud for some reason.
Infamously also the Commodore 64, which a) had the wrong prescaler value for
1200 baud in ROM and b) wasn't particularly efficient, such that software 2400
baud routines were widely used in place of the ROM ones. Part of b) was a
well-intentioned but incomplete and not well-implemented attempt at acting like
a 6551 ACIA in software. Until those 2400 baud routines started appearing, most
people drove the system at 300 baud and no faster (admittedly the VICMODEM and
1660 were only 300 baud themselves).
With a real ACIA cartridge, or a system like the Plus/4 which had an ACIA
built-in, the 64 had no trouble with faster rates. I used a Turbo232 with a 56K
modem for awhile.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Actually, we can overcome gravity (just not the paperwork involved). -------
3 Feb
3 Feb
1:07 a.m.
New subject: Bit-banging nightmares, wa: Re: Re: RS232 then and now (bitbanging)
I am reminded of the Regitel system, a POS system from the early
1970's. We ran 64 model 33's off of a three-or-four board Regitel mux
on a Nova 800; you'd basically load a bunch of registers with the
current bit for each port and it would bang them out; input was the
reverse. It was on the processor to the requisite mask-and-shift
operations to get the bits to the right place.
An image of the cover of the Registel System glossy simply screams 1970's:
https://learninglab.si.edu/resources/view/4446092
--
Christian Kennedy, Ph.D.
chris(a)mainecoon.com AF6AP | DB00000692 | PG00029419
http://www.mainecoon.com PGP KeyID 108DAB97
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
"Mr. McKittrick, after careful consideration…"
6:11 a.m.
New subject: Bit-banging nightmares, wa: Re: Re: RS232 then and now (bitbanging)
On 2/2/25 17:07, Christian Kennedy via cctalk wrote:
I am reminded of the Regitel system, a POS system from
the early
1970's. We ran 64 model 33's off of a three-or-four board Regitel mux
on a Nova 800; you'd basically load a bunch of registers with the
current bit for each port and it would bang them out; input was the
reverse. It was on the processor to the requisite mask-and-shift
operations to get the bits to the right place.
Exactly what else (other than bit-bang serial) did people think that the
8085 SID/SOD pins were intended for?
--Chuck
1:22 a.m.
New subject: RS232 then and now (bitbanging)
On 02/02/2025 2:47 PM EST Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
...
Another example is the Color Computer 3. UltimateTerm 2.4 from 1987 could
bit-bang reliably 9600 baud (also Twilight Term from 1996). The CoCo3 had
a higher speed CPU option than its original. "bit banging" (imo) is the
host system doing the work of producing the start/stop bits on its own.
Which seems to be a "lost art"
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
Will
You just can't beat the person who never gives up.
Babe Ruth
6:09 a.m.
New subject: RS232 then and now (bitbanging)
On 2/2/25 17:22, Will Cooke via cctalk wrote:
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck
10:50 a.m.
New subject: RS232 then and now (bitbanging)
On 2025-02-02 11:09 p.m., Chuck Guzis via cctalk wrote:
On 2/2/25 17:22, Will Cooke via cctalk wrote:
But then you could buy 12 bit wide memory.
9 bit memory also was rare.
Did any use a INDUSTRY STANDARD UART, with a external FIFO chip?
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck
11:28 a.m.
New subject: RS232 then and now (bitbanging)
On Mon, Feb 3, 2025 at 10:58 AM ben via cctalk <cctalk(a)classiccmp.org> wrote:
On 2025-02-02 11:09 p.m., Chuck Guzis via cctalk wrote:
Is that the meanng of 'a bit on the side' ?
On 2/2/25 17:22, Will Cooke via cctalk wrote:
But then you could buy 12 bit wide memory.
9 bit memory also was rare.
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck Did any use a INDUSTRY STANDARD UART, with a external
FIFO chip?
The DEC DZ11 uses the standard 40 pin 'dumb UARTS' and feeds the
receive data into FIFO ICs. I am sure there are others.
-tony
15 Feb
15 Feb
9:10 a.m.
New subject: RS232 then and now (bitbanging)
On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote:
On 2/2/25 17:22, Will Cooke via cctalk wrote:
..and it had a "sex" instruction.
IMO, one of the original RISC cpus.. LoL..
--
Bill Duncan | http://billduncan.org/
bduncan(a)beachnet.org | - linux/unix/networking/cloud
+1 416 697-9315 | - performance/reliability engineering, SRE
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck
2:46 p.m.
New subject: RS232 then and now (bitbanging)
On Feb 15, 2025, at 4:10 AM, Bill Duncan via cctalk
<cctalk(a)classiccmp.org> wrote:
On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote:
The PDP-11 almost did, but it was caught before release and renamed
""SXT".
On 2/2/25 17:22, Will Cooke via cctalk wrote:
..and it had a "sex" instruction.
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck IMO, one of the original RISC cpus.. LoL..
I would apply that label to the CDC 6600 (1964).
paul
3:21 p.m.
New subject: RS232 then and now (bitbanging)
On 2025-02-15 09:46, Paul Koning via cctalk wrote:
Maybe, but not before some manuals got out with it included. I have
seen one of the manuals that got printed and hastily withdrawn, with a
footnote 'plus 20 minutes on Saturday night'.
I think Bill was thinking in terms of RISC as what could been avoided by
using a wrapper!
cheers,
Nigel
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
On Feb 15, 2025, at 4:10 AM, Bill Duncan via
cctalk <cctalk(a)classiccmp.org> wrote:
On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote:
The PDP-11 almost did,
but it was caught before release and renamed ""SXT". On 2/2/25 17:22, Will Cooke via cctalk wrote:
..and it had a "sex" instruction.
Not quite lost. The 1802 crowd is doing amazing things.
See https://groups.io/g/cosmacelf/message/33678
And if you know anything about the 1802, it's, uh, not so speedy.
At its
introduction,it was one of few static CMOS CPUs. You could run
it from batteries and stop the clock when not needed. Perfect for
telemetry. I think the Intersil 6100 was another, but required 12-bit
wide memory.
--Chuck IMO, one of the original RISC cpus.. LoL..
I would apply that label to the CDC 6600 (1964). 
31 Jan
31 Jan
8: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
11: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
9: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.
1 Feb
1 Feb
10:31 a.m.
On 31/01/2025 18:55, Steve Lewis via cctalk 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?
As I've mentioned elsewhere, "UART" is Intel's term for an ACIA; and
other names exist from other manufacturers. Just a buffered shift
register and other logic in the same chip.
I wouldn't call it an ASIC myself, but other definitions are available.
It isn't specific to a user application. I built a disk controller using
a 6550 to serialise the data so you can't even say it's specific to RS-232.
And before MSI you could (and did) serialise data in a standard from
using a shift register. Before that discreet logic. Before that
transistors, and before that mechanically. So I don't think it's fair to
say that single chip UARTS/ACIA/SCI/SCC standardised anything - they
just made things easier to implement using a standard that existed for
twenty years or more.
4:28 p.m.
On 2/1/25 02:31, Frank Leonhardt via cctalk wrote:
On 31/01/2025 18:55, Steve Lewis via cctalk wrote:
As I've mentioned elsewhere, "UART" is
Intel's term for an ACIA; and
other names exist from other manufacturers. Just a buffered shift
register and other logic in the same chip.
The veneered and generated Intel 8251 is a USART--as were other similar
chips (8274, Zilog SIO, etc.)--capable of both asynchronous and
asynchronous data transfer. Synchronous for block/bulk transfer is far
superior in terms of carrying capacity (no start/stop "bits"; note the
quotes; asynchronous "stop" is simply a pause between characters) and
was very common in the 1960s and 1970s. Many a hobbyist has scrounged a
"good deal" used terminal only to find that it was block-mode synchronous.
As far as integration, the original LSI chipsets employed separate
devices for transmitting and receiving data.
Current-loop is probably still employed extensively in heavy
industry--better noise immunity and distance. One used to (in the
1970s) be able to purchase off-the-shelf "long haul" modems that
converted between EIA signal levels and current-loop. One of the
benefits of CL is that detecting a break in the line is simple--not so
for the voltage-oriented EIA signalling (RS-442, 232, 449, etc.). The
disadvantage is that signalling is done over a single wire pair--no
"handshaking signals.
If the 25-way DSUB connector bothers you, have a look at RS-449, which
employs a 37-way (DC37) connector: https://en.wikipedia.org/wiki/RS-449
--Chuck
4:43 p.m.
One used to (in the 1970s) be able to purchase
off-the-shelf "long
haul" modems that converted between EIA signal levels and
current-loop.
Sometimes called "line drivers", because that's not confusingly
overloaded terminology or anything. I was about to say "e.g. Gandalf
LDS family", but iirc those were actually _leased_, not purchased.
If the 25-way DSUB connector bothers you, have a look
at RS-449,
which employs a 37-way (DC37) connector
Some may be amused to remember that the DB/DC/... family of connectors
were known as "D-subminiature" when introduced.
De
5:05 p.m.
I'm happy to see people using the correct shell letter for DSubs around here!
Oldschool wisdom.
I get irritated hearing people on the vintage computing groups calling everything DB.
Here's a quick write up about it - there is no DB9! 🙂
https://www.rogerarrick.com/dcon/
[https://www.rogerarrick.com/dcon/dcon_1000.png]<https://www.rogerarrick.…
RogerArrick.com D-Subminiature Connectors
Explained<https://www.rogerarrick.com/dcon/>
D-Subminiature Connectors. In the 1950's the D-subminiature connector was introduced
and became popular on computers for communications. The pins are small and designed to
carry low-voltage signals, not for power, although pins can carry an amp or more.
www.rogerarrick.com
________________________________
From: Dennis Boone via cctalk <cctalk(a)classiccmp.org>
Sent: Saturday, February 1, 2025 10:43 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: Dennis Boone <drb(a)msu.edu>
Subject: [cctalk] Re: RS232 then and now
One used to (in the 1970s) be able to purchase
off-the-shelf "long
haul" modems that converted between EIA signal levels and
current-loop.
Sometimes called "line drivers", because that's not confusingly
overloaded terminology or anything. I was about to say "e.g. Gandalf
LDS family", but iirc those were actually _leased_, not purchased.
If the 25-way DSUB connector bothers you, have a look
at RS-449,
which employs a 37-way (DC37) connector
Some may be amused to remember that the DB/DC/... family of connectors
were known as "D-subminiature" when introduced.
De
5:36 p.m.
On 2025-02-01 10:11 a.m., Maciej W. Rozycki via cctalk wrote:
On Sat, 1 Feb 2025, roger arrick via cctalk wrote:
I have no idea what that is, but I am sure that has no SUB-MINIATURE price.
I'm happy to see people using the correct
shell letter for DSubs around
here! Oldschool wisdom.
You kinda have to when you get at things such as DA-3W3.
Maciej 
6:11 p.m.
On Sat, 1 Feb 2025, ben via cctalk wrote:
I have no idea what that is, but I am sure that has no SUB-MINIATURE price.
D-sub gear comes at varying prices; I guess consumer DE-9 stuff will be
cheap, but not necessarily when you ask for the wire-wrap variant. As to
DA-3W3 the first hit on the search engine is Farnell/Newark and you'll get
the prices there: nothing out of the ordinary IMHO.
Maciej
I'm happy to see people using the correct shell
letter for DSubs around
here! Oldschool wisdom.
You kinda have to when you get at things such as DA-3W3.
5:33 p.m.
On 2/1/25 09:05, roger arrick via cctalk wrote:
I'm happy to see people using the correct shell
letter for DSubs around here! Oldschool wisdom.
I get irritated hearing people on the vintage computing groups calling everything DB.
Here's a quick write up about it - there is no DB9! 🙂
In fact, if "keeping up with the times" is a thing, then this 35-year
old IEC standard should dictate what we call these beasts:
http://file.yzimgs.com/383992/2013022116300293.pdf
But then, the simple D-sub 25-way male connector would be a real
mouthful. Brevis esse laboro, obscurus fio.
Another pet gripe of mine is calling the old 50-way SCSI/etc. connector
a "Centronics" connector,regardless of application or number of
connections.
I prefer to refer to them as "blue ribbon" connectors, developed by
Amphenol in 1950 and used extensively in commercial telephone systems
long before Centronics or SCSI.
But in my dotage, I've learned not to beat a dead horse.
--Chuck
5:40 p.m.
On 01/02/2025 17:33, Chuck Guzis via cctalk wrote:
Another pet gripe of mine is calling the old 50-way
SCSI/etc. connector
a "Centronics" connector,regardless of application or number of
connections.
I prefer to refer to them as "blue ribbon" connectors, developed by
Amphenol in 1950 and used extensively in commercial telephone systems
long before Centronics or SCSI.
I've always called them Amphenol connectors, although strictly speaking
Amphenol made more than one design.
My #1 annoyances are IT types referring non-volatile RAM as CMOS and
motherboard configuration utilities as a BIOS.
6:25 p.m.
On 01/02/2025 17:33, Chuck Guzis via cctalk wrote:
Another pet gripe of mine is calling the old 50-way
SCSI/etc. connector
a "Centronics" connector,regardless of application or number of
connections.
I prefer to refer to them as "blue ribbon" connectors, developed by
Amphenol in 1950 and used extensively in commercial telephone systems
long before Centronics or SCSI.
I've always called them Amphenol connectors, although strictly speaking
Amphenol made more than one design.
My #1 annoyances are IT types referring non-volatile RAM as CMOS and
motherboard configuration utilities as a BIOS.
7:40 p.m.
On 2025-02-01 13:25, Frank Leonhardt via cctalk wrote:
On 01/02/2025 17:33, Chuck Guzis via cctalk wrote:
Actually, in 1971 they were originally marked A-MP, which stood for
Aero-MarineProducts.
And as far as the statement that Epson standarised the Centronics
connector goes, I say 'hogwash' - it was being used by Centronics many
years before Epson came on to the market. I was servicing teh
Centronics 101, 103 and 306 back in 1975, including making cables to
hook them up to PDP11s. I still remeember the connector part nuer, it
was 57-10360 - the 36 meaning 36 pins, which is why I said there was
never a 50-pin Centronics connector. Centronics printers did sometimes
ship with another parallel interface, it was Dataproducts printer comp
and had a Winchester-style connector I believe, but I never worked on one.
And yes, the 50-pin version was called a blue-ribbon, I saw enough of
those while working for Bell! Common on key sets in small businesses!
cheers
Nigel
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
Another pet gripe of mine is calling the old
50-way SCSI/etc. connector
a "Centronics" connector,regardless of application or number of
connections.
I prefer to refer to them as "blue ribbon" connectors, developed by
Amphenol in 1950 and used extensively in commercial telephone systems
long before Centronics or SCSI.
I've always called them Amphenol connectors, although strictly
speaking Amphenol made more than one design.
My #1 annoyances are IT types referring non-volatile RAM as CMOS and
motherboard configuration utilities as a BIOS.
7:46 p.m.
AMP and Amphenol were different companies, officially.
--
Will
On Sat, Feb 1, 2025 at 2:40 PM Nigel Johnson Ham via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2025-02-01 13:25, Frank Leonhardt via cctalk wrote:
On 01/02/2025 17:33, Chuck Guzis via cctalk
wrote:
Actually, in 1971 they were originally marked A-MP, which stood for
Aero-MarineProducts.
And as far as the statement that Epson standarised the Centronics
connector goes, I say 'hogwash' - it was being used by Centronics many
years before Epson came on to the market. I was servicing teh
Centronics 101, 103 and 306 back in 1975, including making cables to
hook them up to PDP11s. I still remeember the connector part nuer, it
was 57-10360 - the 36 meaning 36 pins, which is why I said there was
never a 50-pin Centronics connector. Centronics printers did sometimes
ship with another parallel interface, it was Dataproducts printer comp
and had a Winchester-style connector I believe, but I never worked on one.
And yes, the 50-pin version was called a blue-ribbon, I saw enough of
those while working for Bell! Common on key sets in small businesses!
cheers
Nigel
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
Another pet gripe of mine is calling the old
50-way SCSI/etc. connector
a "Centronics" connector,regardless of application or number of
connections.
I prefer to refer to them as "blue ribbon" connectors, developed by
Amphenol in 1950 and used extensively in commercial telephone systems
long before Centronics or SCSI.
I've always called them Amphenol connectors, although strictly
speaking Amphenol made more than one design.
My #1 annoyances are IT types referring non-volatile RAM as CMOS and
motherboard configuration utilities as a BIOS.
11:03 p.m.
>> Another pet gripe of mine is calling the old
50-way SCSI/etc. connector
>> a "Centronics" connector,regardless of application or number of
>> connections.
>> I prefer to refer to them as "blue ribbon" connectors, developed by
>> Amphenol in 1950 and used extensively in commercial telephone systems
>> long before Centronics or SCSI.
> I've always called them Amphenol connectors, although strictly speaking
> Amphenol made more than one design.
On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote:
Actually, in 1971 they were originally marked A-MP,
which stood for
Aero-MarineProducts.
And as far as the statement that Epson standarised the Centronics connector
goes, I say 'hogwash' - it was being used by Centronics many years before
Epson came on to the market. I was servicing teh Centronics 101, 103 and
306 back in 1975, including making cables to hook them up to PDP11s. I
Centronics had already STANDARDIZED the connector, but Epson made it known
to the general public.
I loved the 101.
When I retired mine, I tried unsuccessfully to get $25 each at swaps. So,
I donated them to a community colege that was desperate for sturdier more
rugged printers for their lab, and took $1000 each tax deduction.
2 Feb
2 Feb
4:18 p.m.
Same here!
Had a 101 in the basement connected to my PET upstairs because of space and
noise, with a 35-40 foot long ribbon cable far exceeding the recommended
maximum cable length; never a problem.
m
On Sat, Feb 1, 2025 at 6:03 PM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
>>
Another pet gripe of mine is calling the old 50-way SCSI/etc. connector
>> a "Centronics" connector,regardless of application or number of
>> connections.
>> I prefer to refer to them as "blue ribbon" connectors, developed by
>> Amphenol in 1950 and used extensively in commercial telephone systems
>> long before Centronics or SCSI.
> I've always called them Amphenol connectors, although strictly speaking
> Amphenol made more than one design.
On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote:
Actually, in 1971 they were originally marked
A-MP, which stood for
Aero-MarineProducts.
And as far as the statement that Epson standarised the Centronics
connector
goes, I say 'hogwash' - it was being used
by Centronics many years
before
Epson came on to the market. I was servicing teh
Centronics 101, 103
and
306 back in 1975, including making cables to hook
them up to PDP11s. I
Centronics had already STANDARDIZED the connector, but Epson made it known
to the general public.
I loved the 101.
When I retired mine, I tried unsuccessfully to get $25 each at swaps. So,
I donated them to a community colege that was desperate for sturdier more
rugged printers for their lab, and took $1000 each tax deduction.
4:43 p.m.
On 2025-02-02 11:18, Mike Stein via cctalk wrote:
Same here!
Had a 101 in the basement connected to my PET upstairs because of space and
noise, with a 35-40 foot long ribbon cable far exceeding the recommended
maximum cable length; never a problem.
m
On Sat, Feb 1, 2025 at 6:03 PM Fred Cisin via cctalk<cctalk(a)classiccmp.org>
wrote:
>>>> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector
>>>> a "Centronics" connector,regardless of application or number
of
>>>> connections.
>>>> I prefer to refer to them as "blue ribbon" connectors,
developed by
>>>> Amphenol in 1950 and used extensively in commercial telephone systems
>>>> long before Centronics or SCSI.
>>> I've always called them Amphenol connectors, although strictly speaking
>>> Amphenol made more than one design.
> On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote:
>> Actually, in 1971 they were originally marked A-MP, which stood for
>> Aero-MarineProducts.
>>
>> And as far as the statement that Epson standarised the Centronics
> connector
>> goes, I say 'hogwash' - it was being used by Centronics many years
> before
>> Epson came on to the market. I was servicing teh Centronics 101, 103
> and
>> 306 back in 1975, including making cables to hook them up to PDP11s. I
> Centronics had already STANDARDIZED the connector, but Epson made it known
> to the general public.
>
> I loved the 101.
> When I retired mine, I tried unsuccessfully to get $25 each at swaps. So,
> I donated them to a community colege that was desperate for sturdier more
> rugged printers for their lab, and took $1000 each tax deduction.
My first printer was a TeleType ASR35 (with typing reperforator!) I
got a few shocks being careless with the 20mA loop at 130VDC!
The ease of paper tape meant I was very late getting into the cassette
for backup, although I did build a kansas city interface for my 6800 dev
kit!
cheers,
Nigel
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
5:34 p.m.
On 2/2/25 08:43, Nigel Johnson Ham via cctalk wrote:
My first printer was a TeleType ASR35 (with typing
reperforator!) I
got a few shocks being careless with the 20mA loop at 130VDC!
The ease of paper tape meant I was very late getting into the cassette
for backup, although I did build a kansas city interface for my 6800 dev
kit!
My first personal printer was a Diablo Hitype I with the OEM 12-bit
interface. I used two S100 parallel ports (don't recall the card) and
wrote my own logic-seeking bidirectional driver. Still have the code
somewhere.
While that produced very nice copy, I lusted after the Teletype
DataSpeed 40 line printer. Almost bought one, but got sidetracked by
other shiny baubles.
--Chuck
3 Feb
3 Feb
12:25 a.m.
On 2/2/25 11:34, Chuck Guzis via cctalk wrote:
My first personal printer was a Diablo Hitype I with the OEM 12-bit
interface. I used two S100 parallel ports (don't recall the card) and
wrote my own logic-seeking bidirectional driver. Still have the code
somewhere.
While that produced very nice copy, I lusted after the Teletype
DataSpeed 40 line printer. Almost bought one, but got sidetracked by
other shiny baubles.
A guy at work traded me a HUGE Honeywell drum printer for a
Centronics 101.
That printer was so huge and heavy there was NO WAY it could
be in my upstairs computer room. It was part of a key to
tape system that was used as an off-line printer at an
insurance company. I had both the key to tape central unit
and the printer. I dragged a scope down there and ran some
tapes through it while scoping the signals. Then, I made up
a paddle card with 25-pair phone cable and designed an
interface to my Z80 S-100 system. I had a scheme of
overprinting various punctuation to simulate curly braces
and such stuff. 300 LPM printing on a Z80 CP/M system.
Jon
7:08 p.m.
On Sun, Feb 2, 2025 at 11:38 AM Mike Stein via cctalk
<cctalk(a)classiccmp.org> wrote:
Had a 101 in the basement connected to my PET upstairs
because of space and
noise, with a 35-40 foot long ribbon cable far exceeding the recommended
maximum cable length; never a problem.
I ran my 101 off the User Port on my Commodore 64. Wrote a driver to
intercept IEC device 4 that fit in the cassette buffer. I still have
that driver and that printer cable (left the 101 behind 38 years ago,
as mentioned, because of weight).
-ethan
7:05 p.m.
On Sat, Feb 1, 2025 at 6:03 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
I loved the 101.
When I retired mine, I tried unsuccessfully to get $25 each at swaps.
I had a Centronics 101 back in college. I'm sure I got it because
nobody wanted it. Probably got it for $25 or less at a Hamfest or
just "get this out of here!"
I left it behind when I moved from one college rental to another
because I couldn't get help getting it back down the stairs. It was
way too heavy for me to lift solo, even when I was 20.
-ethan
31 Jan
31 Jan
8: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
9: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
9: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.
1 Feb
1 Feb
3:37 a.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
4:11 a.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
5:39 p.m.
On Fri, 31 Jan 2025, Warner Losh wrote:
Yes. That's the overwhelming majority of usage these days. At least for me
when not dealing with retro gear.
As a matter of interest what are the use cases if I may ask and you are
allowed and willing to share this information?
Maciej
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.
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?
8:41 a.m.
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
That confused me at first as well. As you concluded: yes, not a "classic"
(or "real" serial port), but something adjusted to TTL-logic levels.
Reading the async-expansion for the IBM 5110, it talks about -25 to +25V
(the original spec of RS232?). On the 1980 Color Computer 1, I noticed it
uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to
sip less less power, and I think RS-232 revisions allowed for as low as -3V
to +3V swings? So those -5/+5V or 3.3 integrations get referred to as
more modern "TTL logic level serial port" (such as generally a USB/serial
adapter) to contrast from prior legacy devices.
But I suppose it means these devices have less range (max cable distance)
than the original spec? I don't recall all the specifics of the original
SAGE, but I think it was an array of IBM704s across buildings. Or at least
across floors of a building. So the gobs of voltage maybe made sense back
then. If P=IV, the using less Voltage should conserve some power, while
also being faster to "swing" (transition +/-) and allow greater speeds (but
at more limited range).
On Fri, Jan 31, 2025 at 9:37 PM Maciej W. Rozycki via cctalk <
cctalk(a)classiccmp.org> wrote:
> On Fri, 31 Jan 2025, Paul Koning wrote:
>
> > > 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.
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.
>
> > 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
>
9:55 a.m.
I wouldn't call them 'adjusted' to TTL levels. They're simply the levels
that are used between UART and line buffers, which, yes, are TTL but not
something arranged particularly for these devices. Of course, they aren't
any more suitable for external connections than any other internal
board-level signal. It's a hack, useful for making a short connection but
it's the USB part that's intended to be exposed externally.
Note that they're also inverted relative to the RS232 levels because line
buffers convert logic 1 to -15V.
Some USB-serial chips have the ability to choose whether the signals are
inverted. They also tolerate negative input voltages. This allows them to
interoperate with buffered lines which interpret 0v as a negative voltage,
but with extremely bad noise margins.
On Sat, Feb 1, 2025 at 8:48 AM Steve Lewis via cctalk <cctalk(a)classiccmp.org>
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
That confused me at first as well. As you concluded: yes, not a "classic"
(or "real" serial port), but something adjusted to TTL-logic levels.
Reading the async-expansion for the IBM 5110, it talks about -25 to +25V
(the original spec of RS232?). On the 1980 Color Computer 1, I noticed it
uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to
sip less less power, and I think RS-232 revisions allowed for as low as -3V
to +3V swings? So those -5/+5V or 3.3 integrations get referred to as
more modern "TTL logic level serial port" (such as generally a USB/serial
adapter) to contrast from prior legacy devices.
But I suppose it means these devices have less range (max cable distance)
than the original spec? I don't recall all the specifics of the original
SAGE, but I think it was an array of IBM704s across buildings. Or at least
across floors of a building. So the gobs of voltage maybe made sense back
then. If P=IV, the using less Voltage should conserve some power, while
also being faster to "swing" (transition +/-) and allow greater speeds (but
at more limited range).
On Fri, Jan 31, 2025 at 9:37 PM Maciej W. Rozycki via cctalk <
cctalk(a)classiccmp.org> wrote:
On Fri, 31 Jan 2025, Paul Koning wrote:
> > 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.
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.
V.28/V.24
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
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
5:51 p.m.
On Sat, 1 Feb 2025, Steve Lewis wrote:
Reading the async-expansion for the IBM 5110, it talks
about -25 to +25V
(the original spec of RS232?). On the 1980 Color Computer 1, I noticed it
uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to
sip less less power, and I think RS-232 revisions allowed for as low as -3V
to +3V swings? So those -5/+5V or 3.3 integrations get referred to as
more modern "TTL logic level serial port" (such as generally a USB/serial
adapter) to contrast from prior legacy devices.
I don't think referring to ±5V or ±3.3V as TTL levels is correct by any
means: you can't feed it to any TTL input and expect correct operation.
I'm not sure even whether a TTL circuit would survive supplying negative
voltage; it has been decades since I had a look at how a TTL gate looks
like at the transistor level and I don't remember the details anymore.
Maciej
7:01 p.m.
On Jan 31, 2025, at 10:37 PM, Maciej W. Rozycki
<macro(a)orcam.me.uk> 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?
What I meant is that a lot of modern computer modules come with serial ports that are not
RS232 but rather using standard logic levels (TTL 0 and 5 volts, or perhaps lower voltages
such as 0 and 3.3 volts) for their signaling. Those basically just expose the logic level
I/O of the UART or the embedded serial port.
Vendors like FTDI make adapters for this. You can get their UART to USB adapter with
actual RS232 interfacing, but also with 5 volt or 3.3 volt logic levels. That last one is
what you'd use to plug into the console port of a Beaglebone Black microcomputer
board, for example.
paul
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.
2 Feb
2 Feb
6:08 p.m.
On Sat, 1 Feb 2025, Paul Koning wrote:
What I meant is that a lot of modern computer modules come with serial
ports that are not RS232 but rather using standard logic levels (TTL 0
and 5 volts, or perhaps lower voltages such as 0 and 3.3 volts) for
their signaling. Those basically just expose the logic level I/O of the
UART or the embedded serial port.
That makes sense to me since you can then choose what "phy" to attach to
it: RS-232, RS-422, IrDA, etc. It's been done since forever, for example
I think all DEC Alpha machines had their CPU's debug UART wired to a pin
header, but it was up to you to add a line driver if you wanted to make it
a real serial port.
More recently e.g. the SiFive HiFive Unmatched RISC-V development board
has this arrangement for UART #1 (UART #0 is the console port, wired to an
onboard dual FTDI USB device already; the other FTDI port being used to
carry JTAG over USB) and I had to wire my own line driver along with a
DE-9 connector to make it a serial port.
But I wouldn't call a bare UART a serial port or use it for external
connections: it's just a UART you need to wire to make it a serial port.
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.
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? Vendors like FTDI make adapters for this. You can get
their UART to USB
adapter with actual RS232 interfacing, but also with 5 volt or 3.3 volt
logic levels. That last one is what you'd use to plug into the console
port of a Beaglebone Black microcomputer board, for example.
This makes sense to me too: depending on application you can use an FTDI
device which is just a UART with a USB interface (as with the console port
for the RISC-V device mentioned above) or one that actually implements a
serial port with a USB interface, which I'd expect to see with say a USB
RS-232 dongle the contents of which you want to keep to the minimum, so a
single ASIC with probably just a bunch of external passive components fits
perfectly.
Just my point of view, thanks for sharing yours!
Maciej
6:42 p.m.
On Sun, 2 Feb 2025, Maciej W. Rozycki wrote:
I forgot to mention: MIDI has been another notable example where you want
to wire a UART to another kind of line driver. I also have a computer
where one of USARTs is multiplexed (software-configurable) between an
RS-232 line driver with an external DE-9 connector (with pins multiplexed
between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DSR
inputs respectively) and an AC'97 audio codec (the codec uses the USART's
synchronous mode with internal clocking). This one obviously also uses
regular voltage levels to talk to the AC'97 device.
FWIW,
Maciej
What I meant
is that a lot of modern computer modules come with serial
ports that are not RS232 but rather using standard logic levels (TTL 0
and 5 volts, or perhaps lower voltages such as 0 and 3.3 volts) for
their signaling. Those basically just expose the logic level I/O of the
UART or the embedded serial port.
That makes sense to me since you can then choose what "phy" to attach to
it: RS-232, RS-422, IrDA, etc. It's been done since forever, for example
I think all DEC Alpha machines had their CPU's debug UART wired to a pin
header, but it was up to you to add a line driver if you wanted to make it
a real serial port.
10:24 p.m.
On 2/2/25 10:42, Maciej W. Rozycki via cctalk wrote:
On Sun, 2 Feb 2025, Maciej W. Rozycki wrote:
I forgot to mention: MIDI has been another notable
example where you want
to wire a UART to another kind of line driver. I also have a computer
where one of USARTs is multiplexed (software-configurable) between an
RS-232 line driver with an external DE-9 connector (with pins multiplexed
between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DSR
inputs respectively) and an AC'97 audio codec (the codec uses the USART's
synchronous mode with internal clocking). This one obviously also uses
regular voltage levels to talk to the AC'97 device.
Except that MIDI is a current-driven interface, not voltage like RS232.
5 ma currentloop, if memory serves.Voltage is secondary.
--Chuck
11:07 p.m.
On Sun, 2 Feb 2025, Chuck Guzis via cctalk wrote:
Sure, I just gave it as another example that you can wire a UART that
uses TTL or other standard digital circuit signalling to different line
drivers ("phys"). It all boils down to the application.
Maciej
I forgot to
mention: MIDI has been another notable example where you want
to wire a UART to another kind of line driver. I also have a computer
where one of USARTs is multiplexed (software-configurable) between an
RS-232 line driver with an external DE-9 connector (with pins multiplexed
between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DSR
inputs respectively) and an AC'97 audio codec (the codec uses the USART's
synchronous mode with internal clocking). This one obviously also uses
regular voltage levels to talk to the AC'97 device.
Except that MIDI is a current-driven interface, not voltage like RS232.
5 ma currentloop, if memory serves.Voltage is secondary.
1 Feb
1 Feb
7:03 p.m.
On Jan 31, 2025, at 10:37 PM, Maciej W. Rozycki
<macro(a)orcam.me.uk> wrote:
Sure does.
I don't know if the MAX3222 is older, or just different. The RS232 standard
doesn't apply to those high rates. And I vaguely remember seeing words that imply the
line drivers should have controlled rise/fall times. So I think the MAX3222 limits come
from implementing those rate limited edges, not from the age of the design.
paul
...
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?
2 Feb
2 Feb
6:26 p.m.
On Sat, 1 Feb 2025, Paul Koning wrote:
I don't know if the MAX3222 is older, or just
different. The RS232
standard doesn't apply to those high rates. And I vaguely remember
seeing words that imply the line drivers should have controlled
rise/fall times. So I think the MAX3222 limits come from implementing
those rate limited edges, not from the age of the design.
Fair enough. FWIW I have a couple of configurations of these I/O port
cards: dual serial, single serial/single parallel, the latter also in the
ExpressCard form factor, all with the relevant D-sub connectors. They all
had the 921600bps rate advertised, so clearly the line drivers used had to
support it. I was quite surprised though they could go so far beyond.
Sadly the PCIe UART/parallel port ASIC went out of production many years
ago and it's only residual hardware that's still available to purchase
brand new. It was a really good one: it went up to 15.625Mbps, with DMA
support, 128-byte FIFOs, etc.
Maciej
31 Jan
31 Jan
9: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.
6:14 p.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..
11: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 Feb
1 Feb
6:20 p.m.
On Jan 31, 2025, at 6:19 PM, Cameron Kaiser via cctalk
<cctalk(a)classiccmp.org> wrote:
That's not the case for the 202 modem I have; it is definitely 202 only and does not
offer 103 compatibility.
paul
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.
31 Jan
31 Jan
9: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.
9: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
11: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.
1 Feb
1 Feb
1:43 p.m.
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the Centronics
interface :-)
Not only was it TTL only and therefore easier to implement in hardware,
but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share for
printers with this, from a standing start.
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. 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.
2 Feb
2 Feb
3:48 p.m.
On 2025-02-01 08:43, Frank Leonhardt via cctalk wrote:
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
Why can you not acknowledge that it was standardised by Centronics years
before Epson came on the scene?
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the
Centronics interface :-)
Not only was it TTL only and therefore easier to implement in
hardware, but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share for
printers with this, from a standing start.
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.
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.
3:50 p.m.
On 02/02/2025 15:48, Nigel Johnson Ham via cctalk wrote:
On 2025-02-01 08:43, Frank Leonhardt via cctalk
wrote:
Understand the :-)
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
Why can you not acknowledge that it was standardised by Centronics
years before Epson came on the scene?
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the
Centronics interface :-)
Not only was it TTL only and therefore easier to implement in
hardware, but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share
for printers with this, from a standing start.
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.
Out in the field during the late 60s and 70s, I found
that the
Dataproducts interface was more common than the Centronics.
3:51 p.m.
On 02/02/2025 15:48, Nigel Johnson Ham via cctalk wrote:
On 2025-02-01 08:43, Frank Leonhardt via cctalk
wrote:
Did you miss the :-) ?
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
Why can you not acknowledge that it was standardised by Centronics
years before Epson came on the scene?
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the
Centronics interface :-)
Not only was it TTL only and therefore easier to implement in
hardware, but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share
for printers with this, from a standing start.
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.
Out in the field during the late 60s and 70s, I found
that the
Dataproducts interface was more common than the Centronics.
9:12 p.m.
after all, it's not the Epson interface ;-)
On Sun, Feb 2, 2025 at 10:48 AM Nigel Johnson Ham via cctalk <
cctalk(a)classiccmp.org> wrote:
On 2025-02-01 08:43, Frank Leonhardt via cctalk
wrote:
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
Why can you not acknowledge that it was standardised by Centronics years
before Epson came on the scene?
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the
Centronics interface :-)
Not only was it TTL only and therefore easier to implement in
hardware, but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share for
printers with this, from a standing start.
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.
Out in the field during the late 60s and 70s, I found that the
Dataproducts interface was more common than the Centronics.
1 Feb
1 Feb
5:42 p.m.
On 31/01/2025 23:07, Chuck Guzis via cctalk wrote:
On 1/31/25 13:57, Tony Duell via cctalk wrote:
I think the Epson MX80 was responsible for standardising the Centronics
interface :-)
Not only was it TTL only and therefore easier to implement in hardware,
but it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share for
printers with this, from a standing start.
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. 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.
6:33 p.m.
On 2/1/25 09:42, Frank Leonhardt via cctalk wrote:
You could get other interfaces as add-on boards,
including RS-232,
Apple, TRS-80 and IEE488. I believe they got a 50% of market share for
printers with this, from a standing start.
I vaguely recall that the MX-80 came with the parallel interface as the
default; serial EIA was an option. I rigged something up using a 9V
battery and some random logic added to the printer to get serial to work
without buying the option.
--Chuck
![https://www.rogerarrick.com/dcon/dcon_1000.png]<https://www.rogerarrick.…](https://www.rogerarrick.com/dcon/dcon_1000.png]%3Chttps://www.rogerarrick.com/dcon/%3E){kind=link}
10:53 p.m.
On Sat, 1 Feb 2025, Frank Leonhardt via cctalk wrote:
I think the Epson MX80 was responsible for
standardising the Centronics
interface :-)
Not only was it TTL only and therefore easier to implement in hardware, but
it was much faster than RS-232.
You could get other interfaces as add-on boards, including RS-232, Apple,
TRS-80 and IEE488. I believe they got a 50% of market share for printers
with this, from a standing start.
The IBM "Graphics Printer" was a REBADGED MX80, at least for the first few
years. That might also confuse any data about how many MX80s there were.
I don't know whether the IBM printer had any minor internal (firmware?)
differences from the commercially available models.
IBM used a DB25 socket for their printer port at the computer end,
(male on the card for serial, female on the card for parallel "Centronics")
THAT, of course caused some idiots to attempt to use the parallel port for
serial and vice versa. "I just need a 'gender changer'!" :-)
Similarly, IBM used DE9 male sockets for serial (previously a DB25
male) and DE9 female sockets for CGA, MDA.
The earliest Microsoft mouse had DE9 female plug or DB25 female on its
cord for serial, and DE9 male plug on the cord for "BUS mouse".
THAT, of course led some users to accidentally plug a bus mouse into a DE9
video socket, and vice versa. They later changed the design, changed the
name to "Inport", and changed the connector to Mini-DIN so that it could
be confused with PS/2 connectors.
TRS80 used a 34 pin card edge (in order to be confusable with their 34
pin card edge for floppy disk) on the "Expanion Interface" for printer,
but 36 pin Blue ribbon at the printer end, for most, but not all of their
printers.
The pinout was close enough to permit insulation displacement crimp on
connectors on a ribbon cable (cable number 26-1411? or 26-4401?)
Radio shack also came out with a special adapting cable to connect to the
40 pin expansion connector for those who didn't have the Exansion
Interface.
TRS80 also had more of the same issues of multiple same connectors for
different purposes, such as Power/Video/Cassette
Sorry, if I have errors in this (unrefreshed dynamic wetware memory)
--
Grumpy Ol' Fred cisin(a)xenosoft.com
2 Feb
2 Feb
7:29 a.m.
On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
IBM used a DB25 socket for their printer port at the computer end,
(male on the card for serial, female on the card for parallel "Centronics")
THAT, of course caused some idiots to attempt to use the parallel port for
serial and vice versa. "I just need a 'gender changer'!" :-)
The worst screw-up there (IMHO) came from HP in the HP150 series. This
machine had 2 RS232 serial ports as standard on DB25 sockets, wired
for some inexplicable reason as DTEs. There was an add-on board that
included a parallel printer port. To avoid confusion, this was a DB25
plug. But the board had been laid out for a DB25 socket using the IBM
PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12,
and so on.
-tony
9:57 a.m.
On 02/02/2025 07:29, Tony Duell via cctalk wrote:
On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk
<cctalk(a)classiccmp.org> wrote:
> IBM used a DB25 socket for their printer port at the computer end,
> (male on the card for serial, female on the card for parallel
"Centronics")
> THAT, of course caused some idiots to attempt to use the parallel port for
> serial and vice versa. "I just need a 'gender changer'!" :-)
Once saw an IBM Quietwriter damaged by that very action. It was not
happy with 12v on its Centronics port..
The worst screw-up there (IMHO) came from HP in the
HP150 series. This
machine had 2 RS232 serial ports as standard on DB25 sockets, wired
for some inexplicable reason as DTEs. There was an add-on board that
included a parallel printer port. To avoid confusion, this was a DB25
plug. But the board had been laid out for a DB25 socket using the IBM
PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12,
and so on.
-tony
Dave
G4UGM
31 Jan
31 Jan
8: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.
1 Feb
1 Feb
9:35 a.m.
I wasn't aware of current loop, been reading about it today. I also came
across an article on how RS232 is reasonable for non-noisy environments,
but for a busy industrial floor interference can become an issue.
Read through some old GoogleGroup archive, discussions in 1997 of the buggy
8250 support in the IBM BIOS (or rather, the tragic situation of the ROM
BIOS adjusted to address the bug, but then couldn't fully utilize the fixed
hardware that came later).
I tried using the X00 FOSSIL driver on the '286 to see if it sped up
performance, and it actually did not (it did seem to work but I had to
actually step down to 38400 instead of 57600 to get a reliable data
exchange). But if I understand the intent of the FOSSIL driver, it
essentially adds a user defined receive/send buffer beyond whatever the
UART might provide. And that is convenient, since all programs that use
the serial port could benefit from that (or have to implement their own).
I was running MSD and noticed it could detect if a mouse is a present, and
I wondered how does that work on a general serial port and pre-PNP days?
And a comment here made me realize it probably "play games" with one of
those unused pins like RI or DTR. I imagine Microsoft Mouse started some
convention along those lines that others followed? I could see at least
identifying the attached device is not a modem.
Thanks for the collective clarification that, from its beginning, RS232 was
focused on supporting modem interaction, moreso than raw data exchange.
On Fri, Jan 31, 2025 at 5:26 AM Frank Leonhardt via cctalk <
cctalk(a)classiccmp.org> wrote:
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.
>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
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.
31 Jan
31 Jan
11: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
12:19 p.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
1:08 p.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.
1:09 p.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.
1 Feb
1 Feb
2:15 a.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
2:31 a.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
1:37 p.m.
On 01/02/2025 02:31, roger arrick via cctalk wrote:
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
I certainly agree TTL would have made sense for microprocessors but
earlier computers ran at much higher voltages, and lots of them :-)
It was always a pain getting -ve on non-Intel/Zilog machines like 6502.
Why? 'cos Z80s already had it for dynamic RAM anyway.
We've all been talking about the voltage being +/-12V but the standard
was much higher (15V or 25V IIRC depending on the year). But that had
two effects - the input pins needed to stand the voltage swing, but the
output voltages could be whatever you liked - including +/- 5V. Quite a
lot of them were at this level in microcomputers. Why? Because the
voltage would drop in the cable and the receiver really didn't care as
long as it was one side or the other of GND by the time it arrived. A
long cable starting at +15V would look the same as a short one starting
at +5V.
IME +/- 12V was a de-facto standard on microcomputers because they
already had a +12V and -12V rail, along with +5V. The ubiquitous 4116
DRAM needed +5V, -5V and +12V so +/- 5V was a popular option too.
These days you can, of course, get RS-232 driver chips that take TTL in
on one side, +5V, and derive the correct voltages internally. For only a
few pence. Problem gone (except they tend to be SMD and a PITA to mount
on strip-board. Grrr).
Regards, Frank.
3:14 p.m.
On 2025-02-01 6:37 a.m., Frank Leonhardt via cctalk wrote:
IME +/- 12V was a de-facto standard on microcomputers
because they
already had a +12V and -12V rail, along with +5V. The ubiquitous 4116
DRAM needed +5V, -5V and +12V so +/- 5V was a popular option too.
Apple was smart with their switching power supply.
I picked up a S100 bus kit, and all I could build was the +8? supply
that later exploded taking out every thing. The real pain was that
most memory was static ram with like 8K per card.
These days you can, of course, get RS-232 driver chips
that take TTL in
on one side, +5V, and derive the correct voltages internally. For only a
few pence. Problem gone (except they tend to be SMD and a PITA to mount
on strip-board. Grrr).
That was ok when you had one brand of max232, now you have several,
and not all connections are the same. I pulled a schematic off the web
and got burned when I used the wrong brand. Worked like 10 minutes
before it died.
Regards, Frank.
7:10 p.m.
On Feb 1, 2025, at 8:37 AM, Frank Leonhardt via cctalk
<cctalk(a)classiccmp.org> wrote:
On 01/02/2025 02:31, roger arrick via cctalk wrote:
So did early logic ICs. TTL happens to be very well known because it was far more
successful than others, but it was preceded by DTL (6 volts) and RTL (3.6 volts). Also,
in the days of TTL, you might also find high end systems with ECL in them (-3 volts??? I
forgot).
And yes, of course in discrete transistor computers the voltages would be all over the
map. 6 volts in the CDC 6000 mainframes, who knows what else in other machines of that
era.
paul
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 certainly agree TTL would have made sense for microprocessors but earlier computers ran
at much higher voltages, and lots of them :-)
8:40 p.m.
On 2/1/25 13:10, Paul Koning via cctalk wrote:
you might also find high end systems with ECL in them (-3
volts??? I forgot).
If you ran Motorola ECL the Motorola way, with Vcc at gnd
and Vee at -5.2 for MECL 10K and -4.5 for 100K) logic levels
were -0.8 V for a 1 and -1.6 V for a zero.
If you ran it the IBM MST4 way (Vcc at +1.25 V and Vee at
-3V) then logic levels were +400 mV for 1 and -400 mV for zero.
Jon
8:44 p.m.
On 2/1/25 13:10, Paul Koning via cctalk wrote:
you might also find high end systems with ECL in
them (-3 volts??? I forgot).
If you ran Motorola ECL the Motorola way, with Vcc at gnd
and Vee at -5.2 for MECL 10K and -4.5 for 100K) logic levels
were -0.8 V for a 1 and -1.6 V for a zero.
If you ran it the IBM MST4 way (Vcc at +1.25 V and Vee at
-3V) then logic levels were +400 mV for 1 and -400 mV for zero.
Jon
9:12 p.m.
I used the 1488 and 1489 RS232 chips as level shifters on the semiconductor RAM board I
designed for the IBM 1620. Handy.
Dave Wise
________________________________
11:01 p.m.
On 2/1/25 13:12, David Wise via cctalk wrote:
I used the 1488 and 1489 RS232 chips as level shifters
on the semiconductor RAM board I designed for the IBM 1620. Handy.
In the 1970s/80s, there seemed to be two camps of though WRT EIA
receivers/drivers. There was the Motorola 1488/1489 crowd than there
was the TI crowd (75150/75154). Never bothered to ask which had
advantages over the other.
--Chuck
2 Feb
2 Feb
12:41 p.m.
On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis via cctalk wrote:
They're still sold and the datasheets are readily-available, so the
advantages can be quickly determined: On paper, the 75150 is faster and
slightly less power-thirsty than the 1488, but contains just two drivers
instead of four. It also costs over twice as much. So between the two of
them, the 1488 is the winner, especially if you need more than TxD and RTS.
My experience with ye olde Amiga was that its 1488/1489 serial drivers got
rather toasty and would occasionally go bang. I've not knowingly used the
75150, but that might just mean that it quietly gets on with its job without
incident and I haven't had to desolder the crunchy remains...
These days, the MAX232 (or better, one of the clones which doesn't need
chunky electrolytics) is the obvious choice, even if you have +/-12V
available on your board: it's cheaper and takes much the same board space as
than the two-chip 1488/1489 (if five-wire serial is good enough), works off
the +5V that's everywhere on your board so you save having to make space to
route the +/-12V to it, and doesn't burn your finger when you touch it.
Also, the number 1488 is somewhat unfortunate, especially given current
events.
On 2/1/25 13:12, David Wise via cctalk wrote:
[...]
I used the
1488 and 1489 RS232 chips as level shifters on the
semiconductor RAM board I designed for the IBM 1620. Handy.
In the 1970s/80s,
there seemed to be two camps of though WRT EIA
receivers/drivers. There was the Motorola 1488/1489 crowd than there was
the TI crowd (75150/75154). Never bothered to ask which had advantages
over the other.
9:10 p.m.
These days you can get rs232<>TTL converter modules for less than the price
of a MAX... chip; 3.3-5V (no 12V), only slightly larger than a MAX chip
only; for an extra buck or so you can get it with a DE-9 connector
https://www.amazon.ca/Converter-Breakout-Computer-Electronic-Components/dp/…
https://www.amazon.ca/NOYITO-Module-Conversion-Arduino-communicates/dp/B07B…
On Sun, Feb 2, 2025 at 7:41 AM Peter Corlett via cctalk <
cctalk(a)classiccmp.org> wrote:
On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis
via cctalk wrote:
They're still sold and the datasheets are readily-available, so the
advantages can be quickly determined: On paper, the 75150 is faster and
slightly less power-thirsty than the 1488, but contains just two drivers
instead of four. It also costs over twice as much. So between the two of
them, the 1488 is the winner, especially if you need more than TxD and RTS.
My experience with ye olde Amiga was that its 1488/1489 serial drivers got
rather toasty and would occasionally go bang. I've not knowingly used the
75150, but that might just mean that it quietly gets on with its job
without
incident and I haven't had to desolder the crunchy remains...
These days, the MAX232 (or better, one of the clones which doesn't need
chunky electrolytics) is the obvious choice, even if you have +/-12V
available on your board: it's cheaper and takes much the same board space
as
than the two-chip 1488/1489 (if five-wire serial is good enough), works off
the +5V that's everywhere on your board so you save having to make space to
route the +/-12V to it, and doesn't burn your finger when you touch it.
Also, the number 1488 is somewhat unfortunate, especially given current
events.
On 2/1/25 13:12, David Wise via cctalk wrote:
[...]
I used
the 1488 and 1489 RS232 chips as level shifters on the
semiconductor RAM board I designed for the IBM 1620. Handy.
In the 1970s/80s, there seemed to be two camps of though WRT EIA
receivers/drivers. There was the Motorola 1488/1489 crowd than there was
the TI crowd (75150/75154). Never bothered to ask which had advantages
over the other.
3 Feb
3 Feb
6:26 p.m.
Yes.
The chips I used were the engineering sweet spot for my task. The 1620 logic levels are
{ground, resistive pulldown to -12V}. The 1488 (plus clamp diodes) makes the right
levels. Shame about the part number but it's not the chip's fault. By injecting
current on the 1489's Response Control pins, I could level shift from 1620 to TTL with
low cost and part count.
Dave Wise
________________________________
From: Mike Stein via cctalk <cctalk(a)classiccmp.org>
Sent: Sunday, February 2, 2025 1:10 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: Peter Corlett <abuse(a)cabal.org.uk>uk>; Mike Stein <mhs.stein(a)gmail.com>
Subject: [cctalk] Re: RS232 then and now
These days you can get rs232<>TTL converter modules for less than the price
of a MAX... chip; 3.3-5V (no 12V), only slightly larger than a MAX chip
only; for an extra buck or so you can get it with a DE-9 connector
https://www.amazon.ca/Converter-Breakout-Computer-Electronic-Components/dp/…
https://www.amazon.ca/NOYITO-Module-Conversion-Arduino-communicates/dp/B07B…
On Sun, Feb 2, 2025 at 7:41 AM Peter Corlett via cctalk <
cctalk(a)classiccmp.org> wrote:
On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis
via cctalk wrote:
They're still sold and the datasheets are readily-available, so the
advantages can be quickly determined: On paper, the 75150 is faster and
slightly less power-thirsty than the 1488, but contains just two drivers
instead of four. It also costs over twice as much. So between the two of
them, the 1488 is the winner, especially if you need more than TxD and RTS.
My experience with ye olde Amiga was that its 1488/1489 serial drivers got
rather toasty and would occasionally go bang. I've not knowingly used the
75150, but that might just mean that it quietly gets on with its job
without
incident and I haven't had to desolder the crunchy remains...
These days, the MAX232 (or better, one of the clones which doesn't need
chunky electrolytics) is the obvious choice, even if you have +/-12V
available on your board: it's cheaper and takes much the same board space
as
than the two-chip 1488/1489 (if five-wire serial is good enough), works off
the +5V that's everywhere on your board so you save having to make space to
route the +/-12V to it, and doesn't burn your finger when you touch it.
Also, the number 1488 is somewhat unfortunate, especially given current
events.
On 2/1/25 13:12, David Wise via cctalk wrote:
[...]
I used
the 1488 and 1489 RS232 chips as level shifters on the
semiconductor RAM board I designed for the IBM 1620. Handy.
In the 1970s/80s, there seemed to be two camps of though WRT EIA
receivers/drivers. There was the Motorola 1488/1489 crowd than there was
the TI crowd (75150/75154). Never bothered to ask which had advantages
over the other.
1 Feb
1 Feb
9:31 p.m.
On 01/02/2025 19:10, Paul Koning via cctalk wrote:
On Feb 1, 2025, at 8:37 AM, Frank Leonhardt via cctalk
<cctalk(a)classiccmp.org> wrote:
I started with minilogs which were +/- 10V logic.
Anyone remember those?
I certainly agree TTL would have made sense for
microprocessors but earlier computers ran at much higher voltages, and lots of them :-)
So did early logic ICs. TTL happens to be very well known because it was far more
successful than others, but it was preceded by DTL (6 volts) and RTL (3.6 volts). Also,
in the days of TTL, you might also find high end systems with ECL in them (-3 volts??? I
forgot).
And yes, of course in discrete transistor computers the voltages would be all over the
map. 6 volts in the CDC 6000 mainframes, who knows what else in other machines of that
era.
paul
2 Feb
2 Feb
6:32 p.m.
On Feb 1, 2025, at 5:57 PM, Chuck Guzis via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2/1/25 13:31, Frank Leonhardt via cctalk wrote:
Similarly, early CMOS logic IC, both the original Philips 4000 series and the 74HC series,
support a surprisingly wide range of supply voltages. 3-15 volts for the 4000 series
(according to my Radio Shack reference that is), 2 to 6 volts for 74HC. The speed drops
off dramatically with lower voltages, though, as I found out when using a 74HC bus driver
in a 3.3 volt logic design.
paul
I started with minilogs which were +/- 10V
logic.
Anyone remember those?
I remember HTL (15V) being basically a high-voltage version of DTL.
--Chuck
7:04 p.m.
On 02/02/2025 18:32, Paul Koning via cctalk wrote:
On Feb 1, 2025, at 5:57 PM, Chuck Guzis via cctalk
<cctalk(a)classiccmp.org> wrote:
74HC run on +5V is not the same as TTL, which I fell over recently. The
CMOS version can push the output to Vcc whereas TTL can't quite get
there. Sometimes it matters - and in the spirit of the RS232 thread, I
was interfacing TTL to an ISP interface on an old MCU, which is done
using TTL level "RS232"; and you can have DTR flip it into programming
mode. Except the "switch to programming mode" pin on the MCU really did
need to be Vcc high, not the TTL '1' that the DTR line on the
USB->Serial adapter was putting out.
Buffered it through an HC gate and the cable worked.
74C (without the H) has a much wider supply voltage range (same as 4000
series)
Shame no one else hereabouts used minilogs :-(
On 2/1/25 13:31, Frank Leonhardt via cctalk
wrote:
Similarly, early CMOS logic IC, both the original Philips 4000 series and the 74HC
series, support a surprisingly wide range of supply voltages. 3-15 volts for the 4000
series (according to my Radio Shack reference that is), 2 to 6 volts for 74HC. The speed
drops off dramatically with lower voltages, though, as I found out when using a 74HC bus
driver in a 3.3 volt logic design.
paul
I started with minilogs which were +/- 10V
logic.
Anyone remember those?
I remember HTL (15V) being basically a high-voltage version of DTL.
--Chuck
1 Feb
1 Feb
11:11 p.m.
One mystery to me was why did the industry stick with the EIA-232 levels
for terminals and whatnot long after differential EIA-422 was
introduced. Higher-speed, better noise immunity, single-ended power
supply... Seems that the popular places were Appletalk and ST506 data
lines. But not on DTE/DCE. If you were using full-voltage (±15-±25)
at high speeds (>500Kbps), the slew rates were ridiculous.
Inertia? My old 80286 motherboard had junper-selectable 232 or 422.
Still have a couple of tubes of 422 drivers/receivers.
--Chuck
11:13 p.m.
On 2025-02-01 18:11, Chuck Guzis via cctalk wrote:
One mystery to me was why did the industry stick with
the EIA-232 levels
for terminals and whatnot long after differential EIA-422 was
introduced. Higher-speed, better noise immunity, single-ended power
supply... Seems that the popular places were Appletalk and ST506 data
lines. But not on DTE/DCE. If you were using full-voltage (±15-±25)
at high speeds (>500Kbps), the slew rates were ridiculous.
Inertia? My old 80286 motherboard had junper-selectable 232 or 422.
Still have a couple of tubes of 422 drivers/receivers.
--Chuck
DEC had RS422 available on their DLJ11J four-port interface, but I never
saw it used in the field.
--
Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU
Amateur Radio, the origin of the open-source concept!
Skype: TILBURY2591
6:25 p.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.
19
days inactive
34
days old
114 comments
31 participants
participants (31)
-
Adrian Godwin -
ben -
Bill Duncan -
Cameron Kaiser -
Christian Kennedy -
Chuck Guzis -
David Wade -
David Wise -
Dennis Boone -
Doug Jackson -
Ethan Dicks -
Frank Leonhardt -
Frank Leonhardt -
Fred Cisin -
Johan Helsingius -
Jon Elson -
Jonathan Stone -
Lars Brinkhoff -
Maciej W. Rozycki -
Mike Stein -
Nigel Johnson Ham -
Paul Berger -
Paul Koning -
Peter Corlett -
roger arrick -
Steve Lewis -
Tony Duell -
Warner Losh -
Wayne S -
William Donzelli -
wrcooke＠wrcooke.net