18 Jul
2001
18 Jul
'01
11 a.m.
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(a)dittman.net
18 Jul
18 Jul
11:42 a.m.
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(a)dittman.net>
To: <classiccmp(a)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(a)dittman.net
19 Jul
19 Jul
5:04 a.m.
1a) Get a copy of the book "From Chips to
Systems"
by Rodnay Zaks.
I have to agree with this wholeheartedly. It's a great book!
You might also want to look into the DIY6502 (google for it). It's a
really neat SBC based on the 6502. You can build it for under $100 and
it's a great way to learn since it's so very simple.
g.
9:02 a.m.
I have a couple of the ZAKS books and found them rather lame. The approach is
pretty conservative and some of the stuff he recommended in the books I got
didn't work as advertised. I don't know whether that's bad or not. I never
had
the sense that his work got deeply enough into any specific processor that it
would help with the selection of one CPU over another, which is, after all, one
of the things one wishing to learn about microprocessors in general needs to
know, but the general field is covered in a very rudimentary way.
It's my belief that anyone who's learned how to read can get more from the data
sheets and data book app's information than his books offer. Now if you want a
cookbook approach, which he spreads from one CPU to another, it's there if you
want it. I suppose it IS better than no approach at all, and you've got to
start somewhere.
One thing I never saw in a book, particularly of this sort, was adaptive clock
switching. In one environment, I found that I could put a 16K block of fast RAM
in the bottom of the 6502 memory map and that it would, therefore, run the
software we were using about 4x as fast when I switched the CPU clock to 5 MHz
(pushing the Synertek 4 MHz 6502C processor just a bit) for cycles accessing the
bottom 16KB of memory. Since none of the I/O was slow, whenever I/O was used,
it cycled in 200 ns as well. Consequently, all the software I used back then,
which was assembled to load at 0x0200 and none reached above that 16K block,
except for the memory buffers used by the assembler and editor, ran at full
speed, only switching to 1 MHz when it reached outside that block or outside
I/O. It was wonderful to have that level of performance back in the late '70's,
particularly without paying the price of a fullcompliment of 55 ns RAM.
There were numerous others that I've run into over the years, but nothing really
interesting ever shows up in books about the basics. I guess that's as it
should be.
Dick
----- Original Message -----
From: "Eric J. Korpela" <korpela(a)ellie.ssl.berkeley.edu>
To: <classiccmp(a)classiccmp.org>
Sent: Wednesday, July 18, 2001 6:14 PM
Subject: Re: 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.
1a) Get a copy of the book "From Chips to Systems"
by Rodnay Zaks.
2) Read the data sheets. ....
Other steps unmodified...
8406
days inactive
8407
days old
4 comments
4 participants
participants (4)
-
dittman＠dittman.net -
edick＠idcomm.com -
geneb＠deltasoft.com -
korpela＠ellie.ssl.berkeley.edu