8051-class "High speed" loader, USB or serial, for Membership Card

A discussion of a serial loader microcontroller for the 1802 Membership Card; and discussion of a popular USB to serial microcontroller. Posted Mar 14 2012 in Yahoo discussion group cosmacelf by the developer, Mark Moulding. Mark has since decided to use another processor for a more accessable solution, but the Atmel AT89C2051 and an old commerical C compiler he used for his prototype, was convenient for his development. He discussed, but did not use, a popular USB to serial device, the FT245R. He describes his work and his conclusions, and answered some questions, to me in email and on the cosmacelf discussion group. I've taken his posts and emails, and edited them into this Web page, with his permission. - Herb Johnson

Note for 2015: 1) The Rev G version of the Membership card includes a serial interface. Check the Rev G support page for details. 2) Discussion of serial interfaces for Rev F and earlier are at the linked Web page. These will require a monitor program in ROM (or loaded into RAM). Those pages refer to such programs; this site offers the IDIOT monitor program. - Herb

This copy edited Mar 25 2015 by Herb Johnson. Content used with permission of author. For more information look at the 1802 Membership Card Web page.

serial loader for Membership card, March 2012

Now that I'm developing a "high speed" (circa 1970s) loader, I'm becoming more familiar with the states [of 1802 operation], but it was definitely a bit confusing at first - more a documentation issue than functional.

My breadboard version is completed, and seems to be working. I've posted [on the cosmacelf Yahoo site the following files:] the schematic and C source in the Files section, and uploaded a picture into the "Marks Photos" folder of Photos.

I gave up trying to use the (very spiffy) FTDI FT245R chip, because it would require a bit of supporting logic, more components, and debugging time, when all I really wanted to do was get programs into the ELF without wearing out my fingers on the little toggle switches (not to mention reliably). (Mark discusses this chip later on. - Herb]

So I fell back to my original idea, which is [to use an Atmel AT89C2051,] a small single-chip 8051-based micro that I use in lots of other projects. The only other necessary components are a ceramic resonator, an FET, a resistor, and a reset capacitor; I also added a couple of status LEDs, a power supply filter capacitor, and an on/off switch.

The idea is that one can stream the Intel hex file output of an assembler or compiler directly to the serial port using just the built-in DOS MODE and COPY commands, thusly:

MODE COM1:1200,N,8,1 (or whatever)
COPY myfile.HEX COM1:

And, this in fact seems to work with the device I've cobbled together. There are a couple of limitations:

- In order to verify the checksum before sending out the buffer to the MC, I have to send the entire buffer during the time after the is received and before the ":" of the next line is completely received. Since the MC load speed is limited by the time needed for a DMA cycle, I had to limit the download speed to 1200 baud (about 8 mSec/char) to get the whole buffer sent to the MC in time. I'm still not sure that a long hex file line would be processed in time if the MC clock speed is turned down too far.

- Because the loader is just clicking the "Load" button, the contents of the hex file *must* consist of non-sparse, sequential data starting at address 0; there's no facility for random load addresses, which are a legal construct in Intel hex files. I haven't experimented with Ted Rossin's C compiler yet, but I know that my 8051 compiler writes little blurbs of memory all over the map, and in non-sequential order too. Hopefully cc1802 doesn't do that...

Conceptually, if time weren't an issue (such as if some sort of pacing mechanism was used with the PC) then there are enough signals brought out to the MC's parallel port that a loader could buffer up a line, pulse the /CLR signal to reset the PC, activate the memory protect, and step the /LOAD signal up to the load address for that buffer. It could then turn off the memory protect and proceed to load normally (sequentially). This would very inefficient, but still a whole lot better than flipping switches.

I'm not sure what the pacing method would be, though - at the moment, the loader has no up-link channel back to the PC. Perhaps I'll just have to break down and implement a full serial channel, either with an FTDI chip or a level-shifter chip (MAX232 or a DS275). This would need some custom PC software, as well. All this is drifting further from my original idea, so for now I'll probably content myself with 0-org'ed programs.

Once I get some hours on this thing, and resolve some of the issues above, I plan to lay it out on a small board that will fit entirely within a DB-25 head shell. When I get to this stage, I'll poll the group to see if anyone else would be interested, and if so I'll have several of the boards made. In this case, I'll be happy to sell them to anyone, along with a pre-programmed processor, at my cost. I'd be interest in a preliminary idea of the interest level now; if it's zero, I'll probably just stick with my breadboard...

- Mark Moulding

Development and access to tools, April 2012

[I asked Mark about his development tools, in email correspondence in April. Here's some of what he said. - Herb]

I use that Atmel AT89C2051 processor because it's cheap (and I have a bundle of them on hand), and the surface mount format of it (it's also available in DIP) is small enough to be compact, yet large enough to be managed by (my somewhat older) hands. However, it requires a dedicated programmer. There are several homebrew designs out there, and the Atmel site gives enough information to build one from scratch. I was lazy and bought one for $25 from India. [But] most people wouldn't have or be willing to acquire one for just this processor. [They may have other 8051 type processors and programmers.]

And then there's the C compiler. Here's the story: There's an industry standard 8051 compiler sold by Keil, which is completely above anything else available (in terms of speed, memory usage, or pretty much any other metric you could name). In the 80's this was sold in the US by a company named Franklin, whose branded version of the compiler I use. Slightly later in the 80's there was a large rift between the companies, and Keil abandoned the Franklin version entirely. [Mark wrote that the company appears to have ceased operations and doesn't respond to contacts.] Alternatively, one of the open source compilers (specifically SDCC) might work, but I haven't tried it.

I'm reconsidering how I want to implement the loader, in part because of feedback from the Yahoo group, and you and Lee as well. In particular, if anyone wanted to duplicate my work themselves, they'd probably want to make some significant changes.

For these reasons, I'm probably going to abandon this approach (although not the project), and drastically refactor the whole concept to make it more widely accessible. I'm currently considering an Arduino-based board, with bi-directional communication with the PC and a dedicated loader program. [Mark provided some notes on his progress with this approach. Like the 8051 solution, it would be on a card that fits the M/S form factor. He continues to use his 8051 prototype, to develop some of the revised software and protocols.] - Mark

Further discussion in cosmacelf


In a later post, Mark responded:

>David Williams: From what I have been able to find on the web it looks like
>>xon/xoff handshaking is turned on by default when using the Mode command.
>>Perhaps you can use this to pace the PC?

Naturally either of the handshaking methods (either DTR/CTS or Xon/Xoff) could be used - I prefer the former. Thanks for nudging my thought process. Either way, this would obviate the need for custom PC software. I'd still need a reverse channel to the PC though.

> How do you convert RS232 voltage to the voltage of your microcontroller
- or is that what the FET is for?

Yes, that's my ultra-easy and ultra-cheap level shifter. I have one built into a DB-9 headshell (wired right on the connector pins) that I use a surprising amount. It actually meets most of the standard RS-232 specs (not that I care very much). - Mark

In a later post, Mark added:

I am beginning to lean towards a full handshake solution of some sort. Once that's in place, I can also toggle the LOAD and CLR switches from the PC interface program, and as I discussed earlier can also load non-contiguous blocks of memory.

>Bill Rowe: [for my application] I am toggling the in switch on a 3 ms(two ms press, 1 ms between)
> cycle which seems fine - this lets the pc send at 19200
> so maybe your 1200 is pessimistic?

Actually, I'm toggling the LOAD line a lot faster than that - about 250 uSec low, followed by 250 uSec high before loading the next byte onto the data lines. The problem is that, since I wanted to verify the checksum before sending, I have to wait to the end of the hex file line before sending all the bytes on that line. As this is my first cut at the firmware, I haven't yet implemented double-buffering, so the whole record has to be complete before the next record starts to come in. Memory's pretty tight too, but I think there's enough.

> Lee Hart: Can you tell us what a safe toggle time is with the
> oscillator at its slowest?

This can be calculated fairly easily; I've just been too lazy to do so. Each DMA load cycle takes 8 clock cycles (I believe), and the minimum clock frequency I could set the clock to was 132 kHz. Assuming for safety 100 kHz, that's 12.5 kilo-loads/second, or about 80 uSec/load cycle. In practice, I tried to go that fast, and it didn't work - maybe it's 16 clocks/load cycle, or maybe the unterminated lines I was using were just too noisy. (It being 3 in the morning, I just wanted it to work somehow.)

FT245R USB to "parallel"

The FTDI FT245R module is pretty easy to use. As it comes from the factory, with no changes made to the built-in configuration EEPROM, and with the module jumpers in their default positions, the generic FTDI device driver will cause the device to enumerate as a standard serial port. At this point, you can send data to it just like any other COM port. There are of course a couple of differences, though.

Whenever a character is sent to the FT245, the RXF# line will be pulled low, indicating that data is available. Externally pulling the RD# line low then imposes that data byte onto the data lines turning on the output drivers. Bringing (or releasing) the RD# line turns off the output drivers, and shows the availability of the next character, if any, in the buffer with the RXF# line.

About that buffer... the internal transmit buffer (that's data *from* the PC) is 128 bytes, and from the PC end it will fill as fast as possible, regardless of the "baud rate"; this seems to happen at about 300,000 bytes/sec. When the buffer fills, the PC will stall (on "transmit buffer not empty") until characters have been clocked out of the buffer as above. Note that if another character is ready when the RD# line goes back true, the RXF# line *will not* raise and lower again - it just stays low. So the chip provides mostly, but not quite, a classic four-phase handshake.

If you've got a micro on the receive end, the chip/module is very easy to use. It's a little bit more work with just discrete logic, because of that missing transition when another character is already waiting. This is why I went with a dedicated microprocessor for my "simple loader" project.

I haven't used the "receive data" functionality yet, but it looks to be equally simple. There's a "receive" buffer also; that's 256 bytes. For bursting data to/from a microprocessor-based "something" on the end of a USB cable, it's really quite nice and easy to use.

The FTDI documentation sucks a bit. Despite having head offices in England, FTDI's data sheets read very much like poorly-translated "Chin-lish". I had to do some tinkering to grok the information I've described above. - Mark Moulding

Some months later, Mark added this information, in Jan 2014:

I looked fairly extensively at this [FTDI FT245R] chip, and it's *really close* to what one would need for a software-less solution to downloading into the MC.

First, it appears by default as a serial port to the PC (under Windows or Linux - not DOS, although XP and later work really hard to emulate the hardware registers serial ports COM1 and COM2 to a DOS shell). This means that no special USB drivers are needed - anything that knows how to talk to a serial port, such as a terminal emulator or even the command window, will work.

On the other end, any character sent to that serial port appears on the 8 data lines, and there's also a data-available output. A strobe input causes the next available character to appear at the output pins (there's a substantial buffer on the chip, and the effective baud rate is extremely high regardless of what speed the host "thinks" it's set to).

Sounds great, so far: just use the edge of the data-available output to trigger a load into the MC, then use a flip-flop to set the strobe input. The problem is that there's *not quite* a full four-phase handshake, because the data-available line doesn't reset between characters (normally, I'd expect it to switch back when the strobe was asserted, then activate again when the strobe was released).

I'm sure that a bit of time-dependent logic (a one-shot of some sort) could be used to retrigger the load if there's still data available, but at that point I got lazy and went back to my microprocessor-based solution. It's a very useful chip though, and I felt like it wouldn't have taken much more tinkering to come up with a working loader.

It's generally easy to use, although the datasheet is pretty vague. *No* external components are required - even the clock is right on the chip, and as mentioned before no low-level programming is necessary on the PC end. It's also available in a development module (UM245R), which puts the chip and a USB connector on a 24-pin DIP header for easy prototyping (no surface-mount soldering required).

I'm not sure this is the right approach for making a standard downloader module for the MC, but it's not far off. Personally, I still favor the microcontroller approach, using probably an Arduino, although a PICAXE is also a possible choice. But I'm definitely keeping the FT245R in mind for other projects... - Mark Moulding

Contact information for Herb Johnson:
Herb Johnson
New Jersey, USA
To email @ me, see
see my home Web page.

This page and edited content is copyright Herb Johnson (c) 2012, except for content identified as authored by others, where that author retains copyright. Contact Herb at www.retrotechnology.com, an email address is available on that page..