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@classiccmp.org> wrote: > > > > On Feb 2, 2025, at 3:23 PM, Jonathan Stone via cctalk < > cctalk@classiccmp.org> wrote: > > > > > > On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk < > cctalk@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. > > 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
