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
Thanks for the info
Can you, ethan, or anyone else point me to a good source of 68k
processors? It seems that they were good enough for the early Sun
workstations, so they should be good enough for me ;) Their widespread
use and the resulting information available should be useful too. I'd
be interested in one of the MCUs you mentioned... were you thinking of
stuff like Freescale's ColdFire? Those look cheap and I may be able to
sample one for free...
To answer your other questions: I plan to use terminals (I've got a
vt-220 and an ADM-3A lying around, might as well use them).
Framebuffer would be nice but it's probably a difficult goal. I'd like
to implement some kind of storage, yes, and since floppies are kinda a
pain, I guess IDE or CF would be a good choice if it's not too much
work. As for networking... depends on how easy it is to put in. It
seems that other people have done ethernet on homebuilt boxes, so that
might be possible, or maybe PPP/SLIP to one of my other boxes?
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn