Typing 'robot project 68332' into the startpage.com search engine
(google is evil) gives you about 7 pages of results.

A few links from the first page:

http://robotics.jacobs-university.de/CubeSystem
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.7339&rep=rep1&type=pdf

https://en.wikipedia.org/wiki/Kismet_%28robot%29
http://groups.csail.mit.edu/lbr/hrg/1998/springer-final-cog.pdf

http://www.seattlerobotics.org/encoder/200010/332designs/const332.htm

http://web.cecs.pdx.edu/~mperkows/CLASS_479/S2006/1999-EyeBot-Family.pdf

http://elinux.org/Flameman/mrm

Feels like the 68332 plays in "another class of weight" than the 6502
when it comes to building robots.

I'd be tempted to say that the suitability as a target for C would be a big part of that.

Also on the topic of 6502-based robots, there's this thread here on the forum:

Microbot TeachMover 6502 based Robot Arm, Memory Map

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

What made the 68332 such a big success was the TPU, "Time Processor Unit".

NXP 68332 product site:
http://www.nxp.com/products/microcontrollers-and-processors/more-processors/coldfire-plus-coldfire-32-bit-mcus/68k-processors-legacy/m683xx/32-bit-microcontroller:MC68332?tab=Documentation_Tab

TPU reference manual, seems to be not visible at the 68332 product site,
somebody better archives this file:
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/TPURM.pdf

"The TPU is an intelligent, semi-autonomous co-processor designed for timing control.
Operating simultaneously with the CPU, the TPU processes microinstructions, schedules
and processes real-time hardware events, performs input and output, and
accesses shared data without CPU intervention. Consequently, for each timer event,
the CPU setup and service time are minimized or eliminated.
Figure 1-1 is a simplified block diagram of the TPU."



The A mask set (or original mask set) includes the following functions:
• Discrete input/output
• Input capture/input transition counter
• Output compare
• Pulse width modulation
• Synchronized pulse width modulation
• Period measurement with additional transition detect
• Period measurement with missing transition detect
• Position-synchronized pulse generator
• Stepper motor
• Period/pulse width accumulator
• Quadrature decode
The G mask set (or motion control mask set) includes the following functions:
• Table stepper motor
• New input capture/transition counter
• Queued output match
• Programmable time accumulator
• Multichannel pulse width modulation
• Fast quadrature decode
• Universal asynchronous receiver/transmitter
• Brushless motor communication
• Frequency measurement
• Hall effect decode

Block diagram for one of the 16 channels (one channel is tied to one I\O pin):



It's an interesting concept, and I hope that somebody from the FPGA section of the forum
might find the time for digging into it... someday.

It's been a long time that I did some RC servo hacking...
This included using a 24V L6203 driven gear motor and inductive LVDT position sensing.
At some point, I had built my own RC servo loop controller with 40xx chips, but I'm getting off topic.


If you are out to build a 6502 based robot, I'd say your best bet would be controlling
maybe up to eight RC servos with a 6522.

Since one RC servo needs a 1..2ms pulse at maybe 50Hz, IMHO the best approach
would be to generate a pulse train with PB7 toggled by a free running timer 1.

"Pulse train" means that the time between the PB7 "toggles" has to vary,
you would have to do some writes to the 6522 after timer overflow,
would be better to use a /NMI interrupt service routine for this.

A rising\falling edge on PB7 (detected by an XOR gate) then increments a 4017 counter
which generates the control signals for the individual servos.

Additionally, there has to be a re_triggerable monoflop which clears the counter
if there was no change on PB7 for, let's say, more than 5ms.
(A >5ms slot in the pulse train then always synchronizes the 4017 counter).

Seems like I'm running out of topics to be posted into this thread, so just some final words:

When the 6502 was invented, it aimed at small "embedded" projects from the start,
in a niche were we now have the microcontrollers.
(6530 had RAM, ROM, I\O and timer on chip, so it was possible to build a small computer with only two chips.)
From the designers, 6502 wasn't intended to end up in computers, this just had happened
because it was the least expensive CPU chip back then.

68000 was invented to compete with Minicomputers from the start, so interrupt response timing
wasn't a big issue to the designers.
From the designers, 68k wasn't intended to end up as a microcontroller,
this just had happened when applications became more complex and required more memory.
(68k showed up in early laser printers, for instance.)


You now may ask: so why 6502\65816 and 68k still seem to be there, despite ARM and 80x86\Pentium ?

To put it this way: as a human, you might be the "pinnacle" of evolution,
and it looks like designs like the shark and the crocodile haven't changed much during the past few million years.
Nevertheless, when trying to directly compete with those creatures for food in their natural environment,
chances for success won't be too good.


BTW: the 4004 also had started as an obscure calculator chip, and it didn't instantly appear to Intel
that it could be useful for any other applications.
There might be a parallel universe somewhere, in which PCs may look pretty different...

I think you've just introduced the "shark pool" test for computer architectures...

... I do agree with your points. We do get bound into historical accidents - being able to target C for example, or the von Neumann model of computation. It's a bit like the back problems we get from walking upright, to return to an evolutionary analogy.

Some minicomputers had extremely fast interrupt handling and were therefore used in real-time systems. So I'm not so sure about that competing with minis was the reason why the Motorola engineers didn't bother with fast interrupt handling for the 68000 (and it couldn't compete for other reasons too, e.g. those non-restartable instructions - fixed in the 68010). I don't think it was because they didn't think it important. It was probably just that it was difficult to avoid that (slow) side effect with the, at the time, ambitious design.

The design sure was ambitious for that time frame.
There is a story that Nick Tredennick did the 68000 microcode with "paper and pencil"...

;---

Somewhere above in this thread I had mentioned the 6530,
a chip with RAM, ROM, timer and I\O, so it was possible to build a little 6502 computer with only two chips.

I now stumbled over the PSD813 datasheet, that's also a neat chip with RAM, Flash, CPLD and I\O.
First manufactured by Waferscale, later manufactured by STMicroelectronics, unfortunately it's obsolete now.

Somebody better archives the datasheet before it disappears:
http://www.st.com/content/ccc/resource/technical/document/datasheet/eb/ab/40/d0/d5/3a/44/e4/CD00004948.pdf/files/CD00004948.pdf/jcr:content/translations/en.CD00004948.pdf



Unfortunately, I found no similar chip when searching the internet...

I have a data book and other literature from WaferScale Integration, from before STMicroelectronics bought them. It looks like they had really cool stuff. It looks like it's all gone now. Shucks.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I just got notification that the 10 I backordered have been shipped.

That's good!

I am not convinced this is the case. The 816 really is "just" a simple extension. The M/X bits are opcode bits 8 and 9 as far as the instruction decoder is concerned, so it should not be that hard to implement. What I think people don't want is to slog through 1024 hand-written chunks of Verilog; however, a tool like my SMG state-machine decoder generator (which I use to implement my Polaris/KCP53000 RISC-V CPU using the exact same PAL-type decoder that the 6502 uses) makes very quick work of writing instruction decoders indeed.

https://github.com/sam-falvo/SMG

Here's the complete instruction decoder logic for the KCP53000, my 64-bit (!!) RISC-V CPU.

https://github.com/KestrelComputer/pola ... MG/seq.smg

It's 283 lines long.

Run Deluxe Paint on the IIgs and on the A500. Put the IIgs in 16-color, 640x200 mode, and likewise with the Amiga. Grab a brush that is about 1/4 the screen size on the IIgs and do the same on the Amiga. Now, on the IIgs, drag that brush around the screen, and note how, despite being clocked at 2.8MHz, it's quite capable of keeping up with the Amiga doing the same task at 7MHz.

This is because the 65816 doesn't have to fight the blitter for access to memory, while the Amiga's custom chips, which gleefully allows 60fps HAM animations at 320x400, will cut into the CPU's processing power like a hot knife when driven at higher horizontal resolutions/bandwidths. Also, it doesn't help that the blitter, though clocked at 7MHz, can only touch memory no faster than 3.5 mega-transfers per second, and only during blanking periods at that. Ouch.

The 65816 is not a slow CPU. At 2.8MHz, the IIgs was *faster* at many kinds of graphics updates than the Mac Classic, and Jobs wasn't too happy about that. (Running a IIgs at 8MHz was magical; it felt every bit as fast as an Amiga to me.) GS/OS was, however, written in Pascal and largely based on MacOS System 1 code. I suspect that is where most of its sluggishness comes from. Deluxe Paint had its graphics routines in assembly language, I'm sure.

I say this, BTW, as a die-hard Amiga fan. I still have my Amiga 500 and it still boots today.

This is called "Non-Uniform Memory Access", or "NUMA", in today's literature. Yes, it's doable, and many CPUs already have this facility. I think the latest Intel CPUs have something on the order of *6* channels to memory capable of operating independently. Wait states on any particular bus are introduced only when one channel needs to access another channel's memory.

My homebrew RISC-V CPU works the same way; instruction and data fetch are on separate memory channels, but with the introduction of an external memory arbiter, may access a common memory pool.