On 12/12/08, John Floren <slawmaster at gmail.com> wrote:
On Fri, Dec 12, 2008 at 12:27 AM, Chuck Guzis
<cclist at sydex.com> wrote:
Since there's little point (other than
nostalgia) of constructing a
machine with a genuine MC68000 CPU today and using the 68K-based
Coldfire MCUs is just too easy, why not implement your own CPU design
in an FPGA?
Well, I wasn't thinking the MC68000 processor exactly, just something
from that family. I *do* have some experience with FPGA, so I'll
consider doing that as well.
I have a bit of experience with the 68008 and 68000/68010 from the
design end (they were used in various released and unreleased COMBOARD
products)
A simple design with a real 68K processor isn't that hard to whip up
or debug - in fact not much harder than a simple 6502 or Z80 system.
SRAM, of course, is simpler to implement than DRAM, but DRAM can be
easier to expand over a couple of MB (for 1MB or less, I'd stuff in a
couple of JEDEC RAM sockets for a 16-bit RAM field). Let me amend
"simple" - simple is peripheral chips and memory that can keep up with
the cycle time of your processor so that you don't have to handle
wait-states, etc., and can therefore tie DTACK to ground (as advocated
by a famous newsletter, "DTACK Grounded". At 4MHz to 8Mhz, it
shouldn't be a problem these days unless you have a particular VLSI
chip you want to use for I/O (6821, 6522, etc.) and it isn't fast
enough. ROM and RAM that are fast enough shouldn't be an issue, even
with inexpensive parts.
I haven't handwired a 68K project, but I've worked on a few from
design to prototype. One thing we ran into with one design was that
UDS and LDS got swapped. Things mostly worked, but the one thing that
failed was byte-wide reads. We didn't do those in too many places in
our firmware, so it took a little work to figure out what the problem
was. Once I got a trace over a screenful of instructions, the flaw
was obvious. Other problems include byte-swapping between the 68K and
the Unibus or Qbus it was mounted in (not a problem for most designs)
and CAS/RAS undershoot between the DRAM controller and the RAM field
(the solution is now widely known to put 30-39Ohm resistors in-line
with the CAS/RAS lines). Our design was not one I'd call simple, so
these sorts of problems are less likely to crop up with a homebrew.
As pointed out, there are several varieties of 68K-core MCUs. Some of
those have so many I/O peripherals integrated that I think you could
get away with the MCU, some external ROM and RAM and little else.
Your design would look, perhaps, like a early Palm Pilot, but wouldn't
be hard to wire up and would look, to the software, like any other mix
of ROM, RAM and I/O, integrated or not.
I guess it comes down to what you want it to do when you are done. Is
it going to use terminals and run a custom OS or OS68K? Is it going
to have a framebuffer video of some kind? (I would
not call that a simple design at that point) IDE disks? CF cards?
Networking (ethernet?)
-ethan