Apple II for intro to microprocessors

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Jul 16 09:55:45 2001

see inline comments below, plz.

Dick

----- Original Message -----
From: "Mike Ford" <mikeford_at_socal.rr.com>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, July 15, 2001 11:46 PM
Subject: Re: Apple II for intro to microprocessors


> >At the risk of opening old wounds, I'd point out that there's a significant
> >difference between microprocessors and microcomputing. While the one
requires
>
> >As in that infamous previous thread, it seems some people have chosen to read
> >what they wanted to read rather than was was written. That's not my fault,
> >though.
>
> I disagree, and wonder at the point of being so "can't do".
>
While there are a lot of processor-application-related things you are prevented
from, or at least, restricted in, accomplishing because of the restrictions
placed on the hardware by the design of the platform, there certainly isn't
anything you can't do from a computing standpoint. However, that was my point.
The things that define a microprocessor-based system are fixed in the Apple,
mostly by its video timing restrictions, but also by its memory map and the way
in which I/O is managed.

If you want to focus on the computING, it doesn't matter what platform you use,
since the platform will always impose restrictions that prohibit you from
applying the microprocessor fully so long as you're bound to that platform.
That's why, no matter how well-designed a "development system" was, it was still
difficult to manage the precise target timing. Consequently, many
microprocessor-based devices were badly designed and implemented, since their
timing was based on the development/in-circuit-emulator system rather than the
precise system requirements of their target.

The devices I recommended allow their synchronization with any task, yet still
allow all the computing capabilities of the device to be exploited. That's
where the meat and potatoes of the application of microprocessors, at least when
you separate the computing tasks from the hardware operational requirements.
That was, after all, the point I was trying to make.

For example, right on the floor at my feet are three microprocessor-based hard
disk drives. These are perfect examples of what I was driving at, namely, that
there are several processors on each drive, and each processor has a specific
task, for which it has a carefully selected operating frequency and a processor
that accomplishes that task efficiently because it was chosen for an instruction
set that provides features desirable for its tasks. This drive in my lap has a
Motorola processor handling the host interface, a TI DSP to handle servo and
read/write channel issues, and an Intel '188 to manage data transfers and
bufering between the two. Another drive, from the same mfg has an Intel
processor to manage the host interface, a different MOT processor, and a couple
of Fujitsu DSP's. Each one is essentially a separate subsystem with its own
memory and I/O. Each one operates with a crystal selected for its particular
role in this system. If you look in your supply of old hard disks, you'll
undoubtably see much the same thing. It's impossible to guess how much SSI/MSI
hardware these replace, but it's for sure that they replace a lot of it, and,
because they're computers rather than fixed logic, they can be mdified with much
less hassle than the SSI/MSI hardware could have.

If one had tried to work out the timing and the various decoding and other I/O
related tricks used to do these jobs on an Apple, or any other platform
dedicated to its video or other subsystems, it would have been MUCH more
difficult than it had to be. It's true, through computing, it's possible to
calculate how long a given loop takes, and, with considerable effort, to
calculate how that might interact with a process occurring in another subsystem
operating at a different rate. Most in-circuit-emulators didn't even support
speed-switching or different target and host execution rates. You either
operated at the host rate, or the system didn't work properly.
>
> Some if not most of my best microprocessor education came from BOOKS. I
> suggest the addition of an Apple IIe and a logic probe goes a LONG way down
> the road to understanding, lacking only in the experience that time and a
> wide variety of systems can give.
>
There's no question that one had to read quite a bit. However, most of the
materials written about microprocessors were really dedicated to microcomputing
rather than the application of microprocessors. Device manufacturers weren't of
much help either because they wanted you to buy their particular development
systems, with their limitations, and those didn't often help very much.

In the late '80's, third-party develpment support systems ultimately provided
support for those applications, of which the HDD's I mentioned were a typical
example. The advantage was that the platform didn't restrict the operating rate
of the emulators, since each one was slaved to target system timing, and the
host system used resources independent of the MPU support hardware.
>
None of this says that a given thing CAN'T be done, but it's certainly not as
convenient to work out a firmware set for a microprocessor that will be
processing data at a rate derived from the 1.544 MHz T1 rate on a system that's
firmly bound to the timing of a 3.579 MHz color burst crystal. Even if they're
running at the same nominal rate, the variation between their respective timing
references cause problems. Moreover, when you're devising a subsystem that will
be using its own private memory and I/O resources, having a fixed platorm's
memory decoding scheme imposing its restrictions on what you do won't make your
work easier.

That's why I recommended the devices I mentioned in my previous post as a more
convenient alternative to the Apple or any other fixed platform. They make it
much easier to isolate the processING from the processOR. After all, the
firmware/software can be develped on any platform. The hardware is the reason
that microprocessors became so important, not to suggest that they could
function without the firmware/software, but you get the picture.
>
Received on Mon Jul 16 2001 - 09:55:45 BST