Intro to Microprocessors

From: Richard Erlacher <edick_at_idcomm.com>
Date: Wed Jul 18 15:42:43 2001

This makes a good deal of sense. I just favor using a single-chipper like the
6801L1, which has a ROM monitor in it so you can (a) establish that the "thing"
you've built is functional without hooking up lots of hardware, and (b) so you
can quickly verify that you can talk to the other features of your system.

I tend to start with the internal serial channel, then migrate to an external
one once I've established that I can talk to it. Likewise, if I want external
memory, I like to use the internal features so I can verify that the external
RAM/ROM is functioning the way I want before moving my reliance to the external
devices. Once I know the external stuff is working, the internal hardware can
be used as target hardware instead of development hardware. That requires the
sacrifice of some address space, but that's a small price. You can use whatever
CPU clock the CPU can tolerate once the external serial port is verified, since
the CPU clock no longer has effect on the serial channel. Likewise, if you have
to have an external timer, the Lilbug monitor easily supports that as well.

An 805x type device (and probably quite a few others) will allow the same thing,
BTW, though it requires a little more "fancy" hardware. The 805x types have
separate program and data memory, though they support 64K bytes of each. What
that means is that if you map a portion of a RAM into program memory space, you
can run a monitor that loads upper data ram with a program, then, on reset, uses
that instead of the resident monitor. Moreover, it can also be mapped such that
you can use the internal or external EPROM monitor (which YOU have to provide
unless you have a ROM monitor part comparable to the MOT part I mentioned
earlier) to transfer control to your code. Since most code sets are smaller
than the 64 KB space, this mapping works out well. In those cases where you're
operating close to the limits, a more imaginative approach is needed, though
there is no dearth of those.

Both the 805x and 6801/03 types use the same sort of latched lower-address bus
that the 8085/86 types use, so compatible support devices are commonly
available. Though the 8080, 8085, 8086, 680x, 650x, etc, were widely used in
the 70's and '80's, they're gone now, simply because the common external
peripherals have been moved onto the chip. Unfortunately, that deprives the
user of the "fun" of devising the most effective implementation, and also
eliminates the ability to attach external devices in many cases. The current
MOT 8-bit devices, for the most part, no longer support external devices, though
they still make some MCU's that do.

The more basic 68K-core MCU's, and the DSP's still require the skills one would
acquire from designing with the old 8-bit types, and the coding techniques will
probably never become obsolete.

Dick

----- Original Message -----
From: "Eric Dittman" <dittman_at_dittman.net>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, July 18, 2001 2:00 PM
Subject: Intro to Microprocessors


> My take on learning microprocessors:
>
> 1) Pick a reasonable processor. An 8085, Z80,
> 6502, or 680x is reasonable. A Pentium III is
> not.
> 2) Read the data sheets. Get an idea of what the
> timing requirements are, how you interface to
> the timing, address, data, and I/O. Don't rely
> on other people's schematics unless you absolutely
> have no idea what you should do. Make sure after
> using other people's schematics that you do under-
> stand what they did and why.
> 3) Build a simple circuit on a large wire-wrap
> board. Include the processor, minimal ROM,
> minimal RAM, and a simple I/O port with eight
> LEDs attached. Write a small program to write
> different values to the LEDs. Verify they are
> correct. Use a wire-wrap board with enough room
> to add lots of stuff later. You'll be glad of
> the room later.
> 4) Add a serial I/O port. Write a small program to
> read data from a terminal (or equivalent) and
> echo the data back.
> 5) Start extending the program to write your own
> machine language monitor. You've got the I/O
> routines. Add the functions one or two at a
> time, testing along the way. You'll want to
> add memory read, memory write, memory fill,
> register read, register write, port read,
> port write, program start, breakpoints, but
> not a disassembler or assembler. Learn the
> machine code first. Later you can add the
> assembler/disassembler.
> 6) Add some kind of program storage, either out
> through the serial port, through an additional
> serial port (adding another shouldn't be
> difficult), or some other way. Be creative.
> 7) Go off on your own. Experiment. Add some
> A/D converters. Add some D/A converters.
> Whatever you find interesting. But the most
> important point to remember is to understand
> the whats and whys of everything you do.
>
> Step (5) is probably the one you'd be most tempted to
> cheat on, but it really isn't that difficult to roll
> your own. If you'd like, after you've got the basic
> functions going, you can either add features from
> some other monitor program, or use a completely
> different monitor program modified to work with your
> system, but definitely write the basics yourself so
> you know what's going on.
>
> Any comments?
> --
> Eric Dittman
> dittman_at_dittman.net
>
>
Received on Wed Jul 18 2001 - 15:42:43 BST