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.
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 - 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
[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
In a later post, Mark responded:
>David Williams: From what I have been able to find on the web it looks like 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 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) 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 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.)
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
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..
Development and access to tools, April 2012
Further discussion in cosmacelf
development
>>xon/xoff handshaking is turned on by default when using the Mode command.
>>Perhaps you can use this to pace the PC?
- or is that what the FET is for?
> cycle which seems fine - this lets the pc send at 19200
> so maybe your 1200 is pessimistic?
> oscillator at its slowest?
FT245R USB to "parallel"
Contact information for Herb Johnson:
Herb Johnson
New Jersey, USA
To email @ me, see see my home Web page.
