Herb Johnson, last updated July 2 2017 (C) Herb Johnson.
There are more recent notes and suggestions at this linked Web page.. These notes are preserved for more background information and reference. - Herb.
The Lee Hart's 1802 Membership Card kit, has a TTL interface and software "bit-bang" simulated UART, for serial "terminal" operation. Lee Hart and others have corresponded on work with TTL/RS-232 to USB adapters. They correspond at the Yahoo discussion group "cosmacelf". Much of the discussion was quoted from the threads titled ""Re: BOOTS v88 firmware" and titled "USB - TTL/RS-232 adapters and buffering."
Those discussions are quoted and edited in this note. Edits by me are in []'s. Look for other Web documents on this site, about use of the 1802 Membership Card, and use of serial interfaces including RS-232 and USB. An informative Web page is this offer of an 1802 ROM monitor, RAM and serial connectors
Here's the background, and the bottom line.
The TTL to USB adapters, include processors with transmit and recieve buffers back to the PC; they operate based on Windows/Linux drivers which have controlable features. But PC-based legacy software, which assumes serial UART hardware, provides "useless" delay options. The USB device + driver perform their own processing and local buffering "outside" the PC. And, the hardware on the serial side (1802 side) of the adapters, also vary in their response to hardware signals (CTS, RTS, etc.) Ordinary users of these devices - and the 1802 developers in this discussion! - vary in their ability to manage all these resources. An old-school PC with hardware UARTS, avoids these USB device problems; but many users wish to use modern computers with USB only.
On the 1802 side, there's delays not only between characters, but as characters are processed, or as whole lines are processed (as in entered BASIC lines, monitor commands, etc.) The ELF-typical bit-banged software UART and 2MHz 1802 are limited resources. An XMODEM type protocol supports checks and signaling, but it's also limited by these considerations, at the 1802, the USB/UART, and at the modern PC.
Bottom line? A legacy PC with hardware UART, provides a simpler and known-vintage chain of hardware and software to the 1802 Membership Card. Slower baudrates, give the 2Mhz 1802 time to process bits and characters. Even so, some 1802 programs are old and expect even more time-delays. Legacy PC's, with communications software & hardware to control the PC UART, can provide some (but not all) of those delays. Modern PCs with USB/serial drivers, provide some (but not all) of those controls via their device drivers.
The discussion below, walks through the process of discovering these circumstances, suggests technical resources and some USB/UART products, and discusses various remedies and strategies. - Herb Johnson
Dec 13 2015, Lee Hart:I found a USB-RS232 adapter that works with both the 1802 and Z80 MCs. The TRENDnet TU-S9 USB to Serial Converter, distributed on Amazon costs $9.77 + shipping as of Dec 2015. [Drivers are available from trenddnet.com. NOte there are two versions, V1 and V2.]
The RS-232 Trendnet version works with the 1802MC and my Windows 2000 system. I've been using it to try to keep up with [Chuck's Yakym's work on 1802 M/S card monitors]. It works at 1200 baud with [Herb's version of my] IDIOT ROM, up to 4800 with Chuck's monitor. I haven't gotten around to trying it with the toggle-in loaders at 9600.
[There's also] a USB-TTL serial adapter that works *and* supplies power: I haven't had a chance to try this one with the 1802MC yet. It's the Sparkfun FTDI Cable 5V, DEV-09718 a USB cable with embedded FT232RQ at $17.95 as of Dec 2015. [Drivers are available from the Sparkfun listing.] - Lee Hart.
Feb 2017, Lee Hart in the Rev I manual: "TTL-level serial I/O is on P4 (the 6-pin power connector). TTL levels are +3v to +5v idle, and 0v to +0.5v active. They are routed to the 1802 through 1K resistors for protection. P4 pinouts match the Sparkfun #9718 USB-serial cable to provide both serial I/O and power." - Lee Hart.
Dave Ruske, June 7 2017: I don't know how much it'll help PC users, but as a data point for others I've had no problems using the ELF2K with CoolTerm on macOS and a cheap USB to serial adapter. [Here's the] CoolTerm software, with versions for macOS, Windows, and Linux). [The adapter is sold at Amazon. I typically use the UART on the ELF2K, though, at 9600 baud. High-tech old-tech. - Dave
Lee Hart, Jun 8 2017: I have this same adapter, and second the opinion that it works fine (even on my old PCs). This adapter provides real RS-232 output levels, complete with handshake lines. [Herb notes: note the context of Lee's reply - logic levels and old PC's. Read on to see other issues arise.]
[Herb notes:] The Amazon link is to the TRENDnet USB to Serial Converter, USB 1.1 to RS-232 Male (9-pin) DB9 Serial Cable, with Prolific Chipset. The chip is documented as DS_PL2303EA.pdf on the prolific Web site. I have a copy on my Web site - Herb.
The PL2303EA document does not discuss internal operation of the chip. But a functional diagram, shows an "inbound" serial recieve buffer of "256/384 bytes", and an "outbound" transmit buffer of "256/128 bytes". These buffers have consequences which are discussed below. - Herb
Mark Ablene, June 16th: I've used several USB-to-serial breakout adapters based on the FTDI FT232RL chip. These adapters are commonly used with Arduinos, and widely available by mail order or at Fry's Electronics (west coast U.S.). The "OSEPP" branded one is an example. It allows for throttling the PC by asserting its CTS line. Sparkfun also sells full-blown USB-to-serial breakout boards that expose all the hardware flow control lines. I've worked with these on other systems. They're also based on the same FTDI chip.
If my XMODEM tests are ultimately unsuccessful without hardware flow control, I may dream up a simple scheme that signals on this CTS line. Of course folks using a UART don't have any of these problems... Mark [See Mark's XMODEM comments below. - Herb]
The Yahoo discussion group "cosmacelf" carried a June 2017 discussion thread titled "Re: BOOTS v88 firmware". In the thread there's discussion of buffering issues with USB serial adapters. "Buffering" is how the adapter holds bytes of characters sent or recieved serially between the serial device and the USB emulation of serial for the "terminal" computer program. Here's quoted exerpts of that discussion. - Herb Johnson
Robert Armstrong, Jun 6 10:31 PM: I understand that some people are having problems with the buffering added by USB to serial dongles, but that's going to be a problem with xmodem too. With a bit banged port you're going to require a small inter-character delay to allow the firmware time to do something with the character, and that's not going to change. - Bob
Mark Abene, 12:02 AM: Bingo! I haven't had a true serial port in a PC for well over a decade, so I'm one of those people. So are most people, in fact. In the absence of robbing an EF line to implement basic hardware flow control, a much more resilient transfer mechanism is needed than ASCII with crossed fingers. That's where XMODEM comes in....Actually, XMODEM's 128 character pacing with checksum and NAK to request a retransmit would ultimately be faster and more reliable than having to delay between every character plus double-time for every carriage return. I'd be willing to test this. - Mark
Lee Hart, June 7 2017 1:04AM That's my conclusion as well. I'm an "ogre" (Old Generally Retired Engineer). All my PCs are old, and have real serial and parallel ports. I also tend to use simple old modem programs, which are documented and well-behaved. So I haven't had [these] problems with communications between my old computers.
But everyone else seems to use modern PCs, which have no serial or parallel ports. So they use various el-cheapo USB-serial adapters. And, they use various free bloated terminal programs, which are often encrusted with poorly-documented features that don't quite work.
To help people sort out the issues with these new-fangled doo-hickeys, I've been trying to use them myself. The result? Lots of problems. No wonder people have trouble getting them to work!
I've found that the pacing delays and handshaking options in modern PCs and modem programs don't work as advertised. The "pacing" delays get lost in the USB-serial drivers. Thanks to software buffers and hardware FIFOs, they don't stop sending when the handshaking tells them to stop! [But you'll see in further comments, there's hardware problems in the USB adapters. - Herb]
XMODEM sends packets, and the sender must wait after each packet for an acknowledgement before proceeding. This is a form of software handshaking that prevents the sender (a super-fast PC) from over-running the receiver (a pore 'lil ol' 1802). Thus, it should work without having to fiddle with handshaking and character/line pacing options.
[And] I'm working on [delays on processing each character]. :-) If the inter-character processing can be done during the Stop bit, then the 1802 can receive a line or packet of tight-backed serial data. [But] it will still need time to process that line or packet; so some form of handshaking (that works) will also be needed.
I'm thinking that we need to use the 1802's /INT pin. Generate an interrupt when the Start bit arrives. The interrupt handler then reads the character, and sticks it in a buffer. If there's a pause after that character, return. But if another character follows immediately, stay in the interrupt handler. Keep reading characters and putting them in the buffer.
If the buffer gets close to full (like 16 characters left?), send your handshake signal to the PC. But you have to be able to do this while *continuing* to read characters (because the PC won't stop for a while).
{About transfer speed.] XMODEM is binary; it transfers 8 bits per character. HEX only transfers 4 bits/character. - Lee hart
Mark Moulding, June 7 2017 11 AM:
[Lee Hart says:] "The 'pacing' delays get lost in the USB-serial drivers. Thanks to software buffers and hardware FIFOs, they don't stop sending when the handshaking tells them to stop!" - end quote
[I was] writing software to control some industrial machinery, where I really needed to know when a string of characters I was sending was actually finished. I found that using the Windows [serial program's] status calls was completely worthless - all of the buffering was happening inside the USB<=>serial adapter itself, so Windows had no idea of the true state of the buffers.
The only way I was able to work around this, was to calculate the time it would take to send the characters (at the given baud rate, stop bits, etc.) and program a delay period to wait until it should have been sent. It turned out that the transfer of (at least short) strings to the USB dongle was essentially instantaneous - on my time scale, anyway - so it was fairly easy to get the waits to be quite accurate; my initial calculations without accounting for transfer time were nearly dead right.
This was using short-ish strings - about 15 characters or so. Longer strings might fill the USB buffer, but I suspect that one could monitor the characters-sent flag, then start timing once that indicates that Windows thinks it's finished. For this type of stuff, a little extra delay isn't really much of a problem. -Mark Moulding
I'll point you to Ward Christensen's original overview, in case you're curious. - Regards, Mark
Mark Abene, Jun 7 3:32 PM: Mike's XR [implementation] is a good starting point, being that it's a "bare bones" XMODEM implementation. It uses no timers/counters for timeouts, it doesn't verify the block number against its complement, and most importantly, it doesn't verify the checksum. A failure of any of these conditions would normally elicit a resending of the block. There is also no Josh Bensadon, Jun 7 3:40 PM: I recently did a bit of experimenting with the USB TTL converters. I wrote up my findings in the latest Z80MC firmware manual. In a nut shell, it matches [the reported] findings, which is that the USB driver has its own technique of buffering data then sending packets. The sending of packets itself incurs an independent time delay.
[I put these in] Appendix A of the Z80MC manual [and]
I'll upload a copy to
my folder here [in cosmacelf Yahoo]- Josh Bensadon
Josh, June 8 12AM: In a nut-shell, character pacing is useless. The delay just causes the driver to finish the packet and send to the *real* uart at the other end of the USB interface. A fixed, like it or not delay of 14mSec is added as overhead to every packet sent. So, your 1mSec [serial software character] delay now causes a huge 14mSec [packet] delay.
Next, when sending multiple characters, they are received by the driver as fast as possible. The UART TX Busy flag is not simulated in the USB driver.
So, let's talk about 9600 baud where 1 character takes about 1mSec. If you send 100 characters, the driver accepts them all in a few microseconds and sends them to the real UART in a packet. The real UART now takes 100mSec to send them. Let's say you added 25mSec line pacing delay. The 25mSec starts after those few microseconds. The Terminal program is now sending the next line, but the real UART has only sent the first 25 characters (about 25mSec worth).- Regards, Josh
Herb adds: See the Recent USB TTL adapter notes above,
for references to data sheets for USB and UART chips, in adapters discussed by Dave Ruske and Lee Hart.
Note: the discussion in cosmacelf continues on how ElfOS and XMODEM and software UARTs fail or succeed under various conditions. It's informative but not about USB hardware. - Herb
This discussion was quoted and edited from the June 16 2017 thread titled "USB - TTL/RS-232 adapters and buffering" at
the Yahoo discussion group "cosmacelf". Many of these responses, are to many questions and comments posted by "Chuck" posting as "cmdrcosmac". I"ve limited my quotes here, to apparent results and findings, to reduce confusion. Review the full discussion thread, for more details and any updates. - Herb
Mark Abene, Jun 16, responds to questions from "Chuck" AKA cmdrcosmac
Does the USB bridge tell the PC to pause when its buffer is full?
No, that's what the CTS line is used for on the OSEPP/FTDI breakout adapters.
How can the Elf tell the bridge to pause?
You would have to rig some output [from the 1802] to signal to (for example) this CTS line [on the Bridge]. I described this in detail in another thread, and how I do it on other micros with UARTs using the IRQ line.
I was just thinking today, that I can probably create a latch with Q as input that would hold CTS until the full byte was "serviced". I'm going to think on this a bit. Of course it would only work with these particular adapters, but again they are extremely common and often used with Arduinos. If this idea works, I'll look into expanding it to work with the adapters that break out true RTS/CTS.
XON/XOFF [character handshaking] isn't an option for data transfer protocols over bit-bang [ports like those on the 1802 Elf's]. I'm currently working on XMODEM, which means I need, at a minimum, to be able to transfer 128 bytes at a time with minimal errors, which my PC tries to dump on my serial adapter all at once. I'll let you know how this shapes up. -Mark
Josh Bensadon, Jun 17, responds to questions from "Chuck" AKA cmdrcosmac
cmdrcosmac: There are hardware RTS/CTS lines on the CH340 chip. Perhaps these would work?
Josh: But the ELF is not wired or programmed to produce hardware handshaking.
cmdrcosmac: I believe the behaviors and timings Josh found will vary among the different devices.
Josh: I agree. I am restricting my experiments to the CH340, just because it seems to be the cheapest and it works on my older XP machines (while the driver for the newer CP2102 chip does not).
cmdrcosmac: The Arduino forums have lots to say about these bridge chips.
Josh: Right, most (99% ?) Arduino boards have one of these chips on board.
But unlike the ELF, the AT Mega cpu is fast, so articles about buffering and handshaking might be rare. Still, it's a great place to look! Good idea.
cmdrcosmac: Some of FTDI's chips also allow you to disable the internal buffers if you install their driver.
Josh: I shy away from FTDI as their driver may brick cheap knock off chips that have flooded the market. I'm not saying what FTDI did was wrong, but it potentially creates trouble that I wish to avoid. In other words, it's not my fight so I don't want to be a casualty.
Lee Hart, Jun 17, responds in detail to questions from "Chuck" AKA cmdrcosmac. Lee discusses his strategies.
A first experiment would be to get an old PC with a serial port. Hit the used junk places or Craigslist for an old Dell or such.
That's just what I've done. I have an 8088 XT, with a real serial port. I run
Procomm, a popular classic communications program. I have the manuals for
everything. It all works according to the documentation.
There are lots of serial protocols, many of which include various forms of
hardware and software handshaking. Hardware handshaking can use CTS/RTS, or
DTR/DSR; and can handshake in both directions. Software handshaking can use a
variety of characters; ctrl-S/ctrl-Q, DC1/DC3, XON/XOFF, ACK/NAK, etc.
A key feature of each is that when the handshake signal says stop, the PC
*stops*. It finishes the character it's already started to send; but does not
start another one.
There are many "pacing" options as well. If you tell it to add an X msec delay
between characters, or after each new-line character, it does exactly that.
You can also define various pacing characters that should be ignored or do
special things (like NUL, Backspace, or DEL). You can define a character that
the sender must receive as an acknowledgement before proceeding (for example,
suppose you're running a monitor program that sends ":" as its prompt when it is
ready for more input. Then set Procomm to wait for a ":" after each CRLF).
The killer is that virtually *none* of this works right if I run Windows 7 with
a USB-serial adapter. - Lee Hart
[Use that physical UART PC serial-port and} Manipulate the CTS and DSR lines to the serial port while watching the data flow with a scope or LED's.
Lee Hart: I've done this. With enough fiddling, I can get a setup that works FOR ME, with
my particular combination of [serial-port PC] hardware and software. The problem is, no two people have the same setup. I'm trying to sell boards, and provide software that
"just works" for anyone. The newer the OS, the more complicated it gets, and the more legacy [PC] stuff it leaves out or gets wrong. Most people don't know how, or have trouble figuring all this out on a case-by-case basis.And I don't know enough to help them all. - Lee
I read Josh's "Appendix A" and read a few data sheets and forums. I believe the behaviors and timings Josh found will vary among the different devices. Some are internally programmable, and they implement differing sets of handshake leads.
Lee Hart: Right again. No standards. All for none, none for all, and every man for himself. :-)
Lee's strategy: Based on my limited knowledge and ability, what I'm trying to do is:
XMODEM is another option. It's actually a form of the above, with ACK and NAK as
the software handshake characters. But a big advantage of XMODEM is that the
protocol says the sender must stop after each packet, and *wait* for a
response before proceeding. This greatly simplifies things for the 1802 (it
doesn't have to do step 4 above).
Almost all modem programs support [a version of] XMODEM, so if we get this to work, it ought to work on just about anyone's PC. XMODEM also includes error-checking; essential for reliable transfers.
Or we could do hardware handshaking with the an output port on the elf..
See above. I tried it; my PC [with USB dongle] would ignore the handshake line, and merrily keep right on sending until its [USB bridge] buffer ran out of data. - Lee
From "USB - TTL/RS-232 adapters and buffering" discussion thread in cosmacelf Yahoo,
June 2017.
Chuck cmdrcosmac, June 18: Regarding FTDI chips, googling "FTDI driver brick fix" yields loads of info about the fake/brick issue. See esp. [this article on "how to unbrick FTDI Based Arduino Nano"]
Essentially, the problem can be identified and fixed/worked around.
The reason I harp about the FTDI's is that their buffers can be disabled. Others may
be as well. [After] further research: Not totally sure the buffers can be disabled. The latency timers can be adjusted. FTDI has a huge knowledge base at ftdichip.com.
Google [search can also find] "USB serial port latency" and "ftdi AN232B" and "D2XX Programmers guide". Some of these devices are internally programmable. See Silabs and Cypress [documentation].
Mark Abene: I've been using FTDI adapters and breakouts for years with several versions of Windows, from 95 up to and including the most current Windows 10, including lots of different Unixes and linuxes. Never heard of this "driver bricking" thing. [Reference to disabling the USB adapter by trying to change its firmware. - Herb]
As far as being able to adjust the buffering and latency, you most certainly *can*. I've attached a photo of the "Advanced" section for the COM port settings. The default is 4K transfer sizes, and the lowest you can set them is 64 bytes each for xmit and recv (separately). The latency timer defaults to 16, lowest setting is 1 msec.
[Mark is apparently referencing an FTDI chip's "advanced settings for COM4", which
may be a feature of the Windows device driver from FTDI. You'll have to check specific FTDI device support at ftdichip.com for details. - Herb
Again this is an OSEPP branded USB-to-serial breakout board commonly used with Arduinos, and it uses an FTDI FT232RL controller chip. - Regards, Mark. [Herb notes: OSEPP is a producer of Arduino compatible products. osepp.com is their Web site. They provide a link to drivers from ftdichip.com, who produce the FTDI chip.]
Lee Hart, private communications, June 24-26 2017:
Indeed, it's difficult [to make USB work on pre-PC serial devices]. But it must be solve-able, because you can buy an Arduino and it "just works". I think they hide most of the variations between systems in their huge custom IDE software; and either supply the USB-serial adapter [on older Arduinos;] or [USB to serial is] built into the particular Arduino (and that avoids all the variations between [USB-to-serial] adapters).
Another course is to set the USB-serial baud rate so low that the 1802 has time to process each character even for tight-packed serial data. The old IDIOT monitor can do this (at least up to 1200 baud). Tiny BASIC can do it within a line [of serial-entered BASIC code]; but not if it has to then insert that line into a program (which requires a block move). [So] BASIC3 will still be a problem. It takes an unpredictable time to process each character, so even 300 baud may not be slow enough. It needs time to "compile" each line into its internal format. - Lee Hart
This page and edited content is copyright Herb Johnson (c) 2017. Originators of copied content, hold copyright for their published content.
Contact Herb at www.retrotechnology.com, an email address is available on that page..
Responses to buffering discussion
1. Write an interrupt-driven bit-banger serial input for the Elf.
(Start bit causes an interrupt; after that, it's the usual bit-banger).
2. The interrupt handler puts received characters in a buffer.
3. When the buffer approaches full, send the "stop sending" software
handshake character.
4. Keep reading serial data *simultaneously* while the handshake character
is being sent.
5. Eventually, the PC will stop sending (once its various buffers empty
and the software notices the Stop command).
6. Now the 1802 can exit its interrupt handler, and process whatever is in
the buffer.
7. Once the buffer is empty, then send the "resume" handshake character.
Resolutions of problems with USB serial adapters
