Apple II for intro to microprocessors

From: Mike Ford <mikeford_at_socal.rr.com>
Date: Wed Jul 18 12:03:48 2001

>The things the more generously appointed systems like the AIM or the Apple
>don't
>allow you to do is (1) use address lines as device selects, (2) use ambiguous
>decoding, (3) adapt the processor speed to the code being executed, (4)
>anything
>else that involves changing system memory mapping or system timing to the
>target
>application. That's what I mean by "their features get in your way."

>but it means, at the outset, that you have to learn about the Apple rather
>than
>the target.

Precisely, but once you KNOW the Apple II, you know it for all future
projects. I basically followed the rules for expansion cards which allowed
me to use address lines as device selects, if by ambiguous decoding you
mean using just a "few" address lines, sure by including the slot enable
signal or whatever it was (partial address decoding was done for me on
Apple II for each slot).

Number (3) seems like really bad form, making a circuit that depends on the
processor running at some specific rate. Much better to write code that is
"aware" of the processor speed and compensates for it.

Number (4) never bothered me either. If the target system was sufficiently
different, then I worked on the Apple II and downloaded code or burnt
eproms that ran on the target. Sometimes I made conditional assembly, ie
set a flag and code would compile that ran in the Apple II, set a different
one and the code ran in the target.

Since the whole point of this is learning microprocessors, what is the big
problem in learning the MOST elegant implementation of the Apple II?
Received on Wed Jul 18 2001 - 12:03:48 BST