11 Dec
2008
11 Dec
'08
9:39 p.m.
Hi everyone
As a 4th year computer engineering student with a part time job, I
definitely have too much time on my hands, so I've been thinking about
doing something like building my own computer. I remember playing with
the 68k SBCs back in my assembly class, so I thought something from
that family might be an interesting choice. It's ambitious, but
ideally I'd like to do 16/32 bits and a few megs of memory.
Have any of you built something like this? I'm looking for links to
project pages, shared experiences, and advice on what processor to
use. Reminiscence is welcome too, if you have fond memories of such a
thing :)
Thanks
John Floren
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
11 Dec
11 Dec
10:17 p.m.
Have any of you built something like this? I'm
looking for links to
project pages, shared experiences, and advice on what processor to
use. Reminiscence is welcome too, if you have fond memories of such a
thing :)
Well, in MY day, we BUILT a simple 68K computer from scratch in our
class, from "kits" supplied by Motorola.
I had the foresight to buy a couple of tubes of 68000s at a hamfest
for a couple of bucks. By the end of the semester, I had sold every
one of them...
--
Will
12 Dec
12 Dec
8:29 p.m.
there are millions of Sega Genesis' out there. Might not include every peripheral chip
you're looking for though...
--- On Thu, 12/11/08, William Donzelli <wdonzelli at gmail.com> wrote:
From: William Donzelli <wdonzelli at gmail.com>
Subject: Re: 68k homebuilts
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Date: Thursday, December 11, 2008, 10:17 PM
Have any of you built something like this?
I'm
looking for links to
project pages, shared experiences, and advice on
what
processor to
use. Reminiscence is welcome too, if you have
fond
memories of such a
thing :)
Well, in MY day, we BUILT a simple 68K computer from
scratch in our
class, from "kits" supplied by Motorola.
I had the foresight to buy a couple of tubes of 68000s at a
hamfest
for a couple of bucks. By the end of the semester, I had
sold every
one of them...
--
Will 
11 Dec
11 Dec
11:56 p.m.
John Floren wrote:
Hi everyone
As a 4th year computer engineering student with a part time job, I
definitely have too much time on my hands, so I've been thinking about
doing something like building my own computer. I remember playing with
the 68k SBCs back in my assembly class, so I thought something from
that family might be an interesting choice. It's ambitious, but
ideally I'd like to do 16/32 bits and a few megs of memory.
Have any of you built something like this? I'm looking for links to
project pages, shared experiences, and advice on what processor to
use. Reminiscence is welcome too, if you have fond memories of such a
thing :)
In 1985 I was fresh out of school, moved to Sunnyvale CA to work for BTI Computer Systems,
and in within two weeks of starting work had been through the first round of layoffs.
They were kind on the college kids and didn't lay us off, but told us to start
interviewing.
As a result, I had some time on my hands. One thing I did was to design and build a 68000
computer. I used an S-100 backplane and boards, although I didn't adhere to any
standard.
The design had 256KB of DRAM, a uart, and a timer chip. I debugged it by writing a
"JMP
*" program and looking at the waves with an oscope until it looked like it was
working.
Then I wrote a short program that printed some fixed string to the UART and didn't use
any
DRAM. Then I wrote a simple program to read from the uart and echo it back, again not
using DRAM. Once I had I/O capabilities, it was easy to write short memory test programs
until I had that debugged.
Next I found the source for a 68K monitor program, call VuBug. As I recall the 68K
assembler was in the BTI dialect of FORTRAN. I believe it was a version of RM Fortran
(Ryan McFarland).
The 68K debugger was primitive, so I enhanced it. Luckily, I managed to keep the
5.25"
floppies that contained the source, and you are welcomed to use it if you want. Here is
the comment block from the debugger:
****************************************************************************
* *
* DBug is a 68000 debugger. It allows downloading, examining/changing *
* memory, disassembling, single-stepping, tracing, breakpointing, *
* and examining/changing registers. It was originally called VuBug. *
* *
* This is its history: *
* *
* 1) Vubug was written by Edward M. Carter at Vanderbilt University. *
* See the copyright notice below. *
* *
* 2) Mark Isfeld and Dave Conroy modified VuBug for work on the SCC *
* project. The modifications they made were: *
* -- *
* *
* 3) Jim Battle took VuBug and modified it in these ways: *
* -- made syntax checking stronger and error reporting better *
* -- added the Lookup subroutine to allow word commands instead of *
* single letter commands *
* -- added text substitute to substitute memory (SM) command *
* -- changed copy to allow bigger than 64k blocks *
* -- rewrote register (R) command *
* -- added ability to evaluate expressions and changed all commands to *
* allow expressions for parameters *
* -- added disassembly capability *
* -- added symbol managment and changed the load command to read *
* symbols. *
* -- added ascii, asm, bsr, clear, clearsym, dis, fill, help, set, *
* setsym, and = (calc) commands *
* -- changed I/O dependent routines (especially the TERM command) *
* *
****************************************************************************
*******************************************
* *
******** VUBUG *********
* *
* Copyright (C) 1983 *
* Vanderbilt Univ. *
* Comp. Sci. Dept. *
* PO Box 1679 *
* Station B *
* Nashville, Tenn. *
* 37235 *
* *
* Author: *
* Edward M. Carter *
* *
*******************************************
* *
* Although the information contained here-*
* in, as well as any information provided *
* relative thereto, has been carefully re-*
* viewed and is believed correct, Vander- *
* bilt University assumes no liability *
* arising out of its application or use, *
* neither does it convey any license under*
* its patent rights nor the rights of *
* others. *
* *
*******************************************
DBUG.68K: 4227 lines (a few authors)
ASSEM.68K: 2447 lines (entirely written by me)
DISASSEM.68K: 2308 lines (entirely written by me)
It was the first 68K code I ever wrote so it is pretty brute-force, which means it is easy
to understand:
* output in #<quick8>,Dx format. <quick8> is [7:0] and Dx is [11:9]
Dis_MOVEQ equ *
move.b #'.',(a1)+ send '.L' as a reminder
move.b #'L',(a1)+
movea.l a4,a1 point to operand buffer
move.b #'#',(a1)+
move.w d0,d5
bsr SymOr_slzsb signed, leading-zero-suppressed format
move.b #',',(a1)+
move.w d5,d0 recall opcode
rol.w #7,d0 move bits [11:9] to [2:0]
bsr Make_Dx
rts
Once I had it all working, I simply moved on to something else. I had no need to actually
use it for anything, since I had quite capable computers all around me anyway. That next
project was a modula compiler. I only completed a subset of that before I got my next
job, and then there was no time to develop it further. It will need to wait for my
retirement in 20 years. :-)
12 Dec
12 Dec
12:27 a.m.
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?
That would be fun and you'd learn something too.
Cheers,
Chuck
P.S. I built both NS PACE and GI CP1600 CPU boards to plug into an
S100 bus on my own time out of curiosity, but couldn't think of
anything to do with them, so they got recycled for other projects
after a few years.
10:22 a.m.
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.
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
12:47 p.m.
John Floren wrote:
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.
Most of the FPGA designs I have seen are RISC's or some 6502 offshoot.
I am sticking for now to CPLD's, since you don't have to configure the chip
like a FPGA, Also a little cheaper if you stick to a bare design like a
PDP8.
Two CPLD's for the data path and 1 CPLD for control.
John
3:29 p.m.
On 12 Dec 2008 at 10:47, bfranchuk at jetnet.ab.ca wrote:
Most of the FPGA designs I have seen are RISC's
or some 6502 offshoot.
I am sticking for now to CPLD's, since you don't have to configure the chip
like a FPGA, Also a little cheaper if you stick to a bare design like a
PDP8.
Two CPLD's for the data path and 1 CPLD for control.
How about a 20-bit word size, 4 bit opcode, 65KW addressing space,
simple one-address+accumulator machine? Enough directly-addressable
memory to do just about whatever you need to do, simple to implement.
Cheers,
Chuck
3:34 p.m.
On Fri, 12 Dec 2008, Chuck Guzis wrote:
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
Date: Fri, 12 Dec 2008 12:29:26 -0800
From: Chuck Guzis <cclist at sydex.com
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org To: "General
Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org Subject: Re: 68k homebuilts
On 12 Dec 2008 at 10:47, bfranchuk at jetnet.ab.ca wrote:
Very similar to what we use for embeddded 8,16,32 bit CPUs in FPGAs. For I/O
(well memory) intensive operations, the accumulator oriented architecture
beats the socks off of RISCy designs with only memory load and store (that are
basically designed for systems with large slow memory instead of small fast
memory)
Most of the FPGA designs I have seen are
RISC's or some 6502 offshoot.
I am sticking for now to CPLD's, since you don't have to configure the chip
like a FPGA, Also a little cheaper if you stick to a bare design like a
PDP8.
Two CPLD's for the data path and 1 CPLD for control.
How about a 20-bit word size, 4 bit opcode, 65KW addressing space,
simple one-address+accumulator machine? Enough directly-addressable
memory to do just about whatever you need to do, simple to implement.
Cheers,
Chuck
4:31 p.m.
Chuck Guzis wrote:
On 12 Dec 2008 at 10:47, bfranchuk at jetnet.ab.ca
wrote:
How about a 20-bit word size, 4 bit opcode, 65KW addressing space,
simple one-address+accumulator machine? Enough directly-addressable
memory to do just about whatever you need to do, simple to implement.
Cheers,
Chuck
That was last weeks design. :(
That is 3 opcode bits and a indirect bit. Going to 4 opcode bits
gives you 32K of memory and would make a nice small machine
that dates around the early 60's.
The problem is that I want to have local function variables, and that
requires
a stack frame pointer and one index register at least for structure address.
(A 6809 DP style register provides global variables, but hardware
relocation is
not possible.) This architecture requires a register file and alu design
rather than
the dedicated logic of a AC,PC,MAR and MBR on a classic machine.
The CPLD's don't have ample hardware for a complex machine like a PDP-11
but they do just have the capacity for machine's hardware somewhere between
the 6800 and the 6809.
Word and byte operations for LD,ST,ADD,SUB,AND,OR,XOR. {AC,IX,SP)
Addressing modes
1) # long :immedate long
2) #short :immedate short
3) (0,dp,ix,sp) + nnn : indexed
4) @ (0,dp,ix,sp)+ nnn : indirect indexed.
Direct and # addressing modes AC ONLY
JMP,JMS,JZ,JNZ,ADC,SBC
Direct only - INCRIMENT/DECRIMENT MEMORY
INC,IN2,DEC,DE2
Special function - AC,IX OPERANDS
LEA,STX,NEG,NGC,SCC,{SHIFT},EI,DI
5:19 p.m.
On 12 Dec 2008 at 14:31, bfranchuk at jetnet.ab.ca wrote:
That is 3 opcode bits and a indirect bit. Going to 4
opcode bits
gives you 32K of memory and would make a nice small machine
that dates around the early 60's.
The problem is that I want to have local function variables, and that
requires
I suppose that a 16-bit (or 20-bit 3-(16/32 register) address design
would be too complex. But it would give you the flexibility you need
without an explicitly-implemented hardware stack. Make one of the
registers PC and branches get interesting.
Who needs registers or indirect addressing anyway? IA was an
*option* on the CADET. Instruction modification was a way of life.
Cheers,
Chuck
5:23 p.m.
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:
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
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.
5:47 p.m.
On Fri, Dec 12, 2008 at 5:23 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 12/12/08, John Floren <slawmaster at
gmail.com> wrote:
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
On Fri, Dec 12, 2008 at 12:27 AM, Chuck Guzis
<cclist at sydex.com> wrote:
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
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.
13 Dec
13 Dec
7:19 p.m.
On 12/12/08, John Floren <slawmaster at gmail.com> wrote:
On Fri, Dec 12, 2008 at 5:23 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
> 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)...
.
.
.
Thanks for the info
You bet.
Can you, ethan, or anyone else point me to a good
source of 68k
processors?
I don't know about 68008s, those weren't common, even 20 years ago,
but 68000s should be available from the usual sources we trade here -
BG Micro or Unicorn. The actual MC68000 hasn't been made in 12 years,
apparently, but I know where a several dozen could be located quickly
;-)
Freescale, as you've already discovered, would be the likely source of
the newer MCUs with a 68K core.
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...
Yep.
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).
Easy enough, then.
Framebuffer would be nice but it's probably a
difficult goal.
Framebuffers, unless you were planning on reusing an existing
component, say and ISA video card, can be fiddly to work with. Simple
textual video, as with a 6845, isn't too bad (but have a look at a
late-model PET schematic to see what sort of support logic is needed),
and since there's no character ROM, a straight bits-to-pixels
"framebuffer" isn't hard in and of itself, but then you have to work
up graphics primitives and font routines to see any results (and video
logic is always full of timing issues no matter how you implement it).
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.
It's easy to support PATA and CF cards - there are designs out there
for plenty of microprocessors, and with the 68000, you have a 16- bit
data bus, which is the native size of the PATA bus, simplifying that
interface (to a small handful of chips, really).
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?
There are encapsulated Ethernet modules for embedded computing now, or
some of the 68K MCUs have a serial port that's fast enough to
bitbang-out 10Mbps Ethernet (I have something like that in a network
appliance called a WebRamp - runs OS68K, has some form of 68302 or
68306 and a 10BaseT media converter). I'm sure the software end of
that design isn't simple, but the hardware end is.
-ethan
12 Dec
12 Dec
6:03 p.m.
Ethan Dicks wrote:
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.
Was not that newsletter for a APPLE II, co-processor board?
Did anybody ever use one, or any kind of general purpose co-processor
boards for the PC?
-ethan
6:28 p.m.
On 12 Dec 2008 at 16:03, bfranchuk at jetnet.ab.ca wrote:
Was not that newsletter for a APPLE II, co-processor
board?
Did anybody ever use one, or any kind of general purpose co-processor
boards for the PC?
Z80 boards were quite popular. I recall using one called "Blue
Lightning" or something like that. But 68K, Z8000, NS16032 and
others were certainly made. Didn't someone also make Clipper and/or
Transputer boards for the PC?
Cheers,
Chuck
6:44 p.m.
Chuck Guzis wrote:
On 12 Dec 2008 at 16:03, bfranchuk at jetnet.ab.ca
wrote:
I've got a couple of ARM ones too, just to add them to the pot.
I'd love to fine a NS32016 or m88k one (not sure if the latter ever existed)
Was not that newsletter for a APPLE II,
co-processor board?
Did anybody ever use one, or any kind of general purpose co-processor
boards for the PC?
Z80 boards were quite popular. I recall using one called "Blue
Lightning" or something like that. But 68K, Z8000, NS16032 and
others were certainly made. Didn't someone also make Clipper and/or
Transputer boards for the PC?
Transputer ones certainly existed; IIRC seeing one (I think it was Inmos
themselves) which supported plug-in TRAM modules at the far end of the board
(I had a photo of it too, but can't find where I've filed it right now)
cheers
Jules
13 Dec
13 Dec
2:57 p.m.
Didn't
someone also make Clipper and/or
Transputer boards for the PC?
Transputer ones certainly existed; IIRC seeing one (I think it was Inmos
themselves) which supported plug-in TRAM modules at the far end of the board
(I had a photo of it too, but can't find where I've filed it right now) 
3:57 p.m.
On Dec 13, 2008, at 2:57 PM, Tony Duell wrote:
There are certainly transputer boards for the PC. The most common
in my
experience si the B004, which is am ISA card with a T4 or T8 chip
on it,
rows of DIP DRAM, the link interface and ISA bus logic and not a lot
else. It has the nromal link connectors on the rear bracket so you can
hang more transputers off it. There's at least one non-INMOS clone of
this board.
I had a Transputer ISA board (T414) for a while. Brian Hechinger
has it now.
-Dave
--
Dave McGuire
Port Charlotte, FL
Didn't someone also make Clipper and/or
Transputer boards for the PC?
Transputer ones certainly existed; IIRC seeing one (I think it was
Inmos
themselves) which supported plug-in TRAM modules at the far end of
the board
(I had a photo of it too, but can't find where I've filed it right
now) 
6 p.m.
New subject: INMOS boards (was: 68k homebuilts)
Tony Duell wrote:
There are certainly transputer boards for the PC. The
most common in my
experience si the B004, which is am ISA card with a T4 or T8 chip on it,
rows of DIP DRAM, the link interface and ISA bus logic and not a lot
else.
All that DIP RAM was usually 2Mbytes so that you could run the occam
compiler in it. Remember, this was in the days of 640k PC memories.
It has the nromal link connectors on the rear bracket
so you can
hang more transputers off it. There's at least one non-INMOS clone of
this board.
It used 0.1-inch Berg connectors, which were notorious for falling
out when you least expected it.
There was also a TRAM motherboard for the PC. I forget
the number
(B008?)
Yes, the TRAM motherboard for the ISA bus was the B008.
It has the link interface (with ISA logic) and IIRC a
C004 link
swithc on it. You can fill it with TRAMs (TRAnsputer Modules, the
simplest being transputer + RAM, but ones iwth SCSI, GPIB, ethernet, etc
interfaces exist, as does one with a vector processor chip (alongside the
transputer).
The Zoran chip?
Anyway, the so-called BOO boards were (as best I can remember them):
B001: Single Rev.A transputer and SRAM on ITEM card
B002: Single Rev.A transputer and 2Mb DRAM on ITEM card
B003: Four transputers and RAM, on an ITEM card
B004: Transputer and DRAM on ISA card
B005: M212 disk transputer with MFM hard disk and floppy disk
B006: Early TRAM demo board with T212 TRAMs
B007: transputer with VRAM, 6545 and G170 palette chip, ITEM card
B008: TRAM motherboard for ISA bus
B009: A100 DSP chips on ISA card
B010: NEC PC version of B004 (?)
B011: TRAM motherboard in ITEM card format (?)
B012: VME card with transputer and memory
B013: Never built!
B014: TRAM motherboard (with C011 and C004) for VME bus
B015: NEC PC version of B008 (?)
B016: VME bus master card with T801 transputer
B017: TRAM motherboard on MCA card for PS/2 hosts
B018: Special TRAM motherboard for B300
B019: Special differential link I/O board for B300
B020: Transputer with SIMM memory and G332 graphics chip
B042: 6x7 array of transputers for burn-in, used in-house
The ITEM (INMOS Transputer Evauation Module) was a sub-rack holding
a dozen or so extended-Eurocard-sized boards.
The B300 was the ethernet gateway, with four differential links
accessible via TCP/IP.
I worked for INMOS 1989-1994, writing drivers for some of these boards.
--
John Honniball
coredump at gifford.co.uk
14 Dec
14 Dec
2 p.m.
New subject: INMOS boards (was: 68k homebuilts)
Tony Duell wrote:
That sounds about right. All in 41256s IIRC.
There are certainly transputer boards for the
PC. The most common in my
experience si the B004, which is am ISA card with a T4 or T8 chip on it,
rows of DIP DRAM, the link interface and ISA bus logic and not a lot
else.
All that DIP RAM was usually 2Mbytes so that you could run the occam compiler in it. Remember, this was in the days of
640k PC memories.
[...]
[TRAMs]
interfaces
exist, as does one with a vector processor chip (alongside the
transputer).
The Zoran chip? B011: TRAM motherboard in ITEM card format (?)
Are you sure? I thought the B011 was a VME card. I seem to rememebr
seeing one in the particle physics lab at Bristol, where I was making my
own transputer-based machine.
[..]
The ITEM (INMOS Transputer Evauation Module) was a
sub-rack holding
a dozen or so extended-Eurocard-sized boards.
The oen I have is a 3U rack with the horizontal adapter for 6U boards (if
you see what I mean, the extended Eurocard boards fit horizontally).
There's a PSU at one end and a fan unit at the other. It lokes to take 5
such PCBs.
-tony
2:26 p.m.
New subject: INMOS boards (was: 68k homebuilts)
On Dec 14, 2008, at 2:00 PM, Tony Duell wrote:
That's the one. I have such a TRAM somewhere...
Hmm? What chip is this?
-Dave
--
Dave McGuire
Port Charlotte, FL
interfaces exist, as does one with a vector processor
chip
(alongside the
transputer).
The Zoran chip? 
12 Dec
12 Dec
6:50 p.m.
Was not that newsletter for a APPLE II, co-processor
board?
Did anybody ever use one, or any kind of general purpose co-processor
boards for the PC?
>
HP made the 82300C BASIC Language Processor and the 82324A Measurement
Coprocessor cards, which were basically 68000 and 68030 based HP 9000
200/300 class systems on ISA bus cards which used the host PC for I/O
and ran HP BASIC 5.x or 6.x
http://www.hpmuseum.net/display_item.php?hw=681
http://www.hpmuseum.net/display_item.php?hw=909
Not really general purpose co-processors, although I suppose your
could always write your own software to run on them instead of HP
BASIC if you were motivated to do so.
13 Dec
13 Dec
12:39 p.m.
On Dec 12, 2008, at 6:03 PM, bfranchuk at jetnet.ab.ca wrote:
I used to use a CP/M board in my XT, back when an 8MHz 8088 was a
"real screamer". It had 64KB of onboard memory, and I had a little
program that ran from autoexec.bat on the XT which made my DOS-
available memory 704KB using that board. It otherwise sat idle when
DOS was running.
-Dave
--
Dave McGuire
Port Charlotte, FL
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.
Was not that newsletter for a APPLE II, co-processor board?
Did anybody ever use one, or any kind of general purpose co-processor
boards for the PC?
6:27 p.m.
On 12/12/08, bfranchuk at jetnet.ab.ca <bfranchuk at jetnet.ab.ca> wrote:
Ethan Dicks wrote:
Yes. That was the basic product, but the newsletter has lots of 68K
design info.
A simple design with a real 68K processor
isn't that hard to whip up
or debug... tie DTACK to ground (as advocated
by a famous newsletter, "DTACK Grounded"...)
Was not that newsletter for a APPLE II, co-processor board? Did anybody ever use one, or any kind of general
purpose co-processor
boards for the PC?
Not me, but I remember such things existed for a while in the days
before the 486 was dominant.
-ethan
6:51 p.m.
Ethan Dicks wrote:
I seem to remember something about co-processor boards with i860 chips
on them?
Peace... Sridhar
Did anybody
ever use one, or any kind of general purpose co-processor
boards for the PC?
Not me, but I remember such things existed for a while in the days
before the 486 was dominant.
15 Dec
15 Dec
3:45 a.m.
On Dec 13, 2008, at 7:03 PM, William Donzelli wrote:
In 1988 or so, I used a similar OCR setup at work. I think it was
called Calera, but I'm not sure. It used an ISA board with a 16MHz
68020 and a bunch of memory on it. It ran under DOS. Its code was
all RAM-based, and was downloaded into the board at boot time by
programs run from autoexec.bat.
-Dave
--
Dave McGuire
Port Charlotte, FL
I seem to
remember something about co-processor boards with i860
chips on
them?
Yes, RCS has some of those kicking around.
Quite some time back I used an OCR package on a 486 that used the AMD
29K PeeCee development board for the horsepower.
8:52 a.m.
Dave McGuire wrote:
On Dec 13, 2008, at 7:03 PM, William Donzelli wrote:
In 1988 or so, I used a similar OCR setup at work. I think it was
called Calera, but I'm not sure. It used an ISA board with a 16MHz
68020 and a bunch of memory on it. It ran under DOS. Its code was all
RAM-based, and was downloaded into the board at boot time by programs
run from autoexec.bat.
That's interesting - so I wonder if they made a design decision to use the
68k, or did they already have a product based around a 68k (possibly on a
Mac?) and it made the porting effort to the PC platform a lot easier just to
sell the product with a copro board? Back then most OCR products commanded a
huge price tag, so doubtless adding the cost of an ISA card didn't make much
difference (but I assume that they bought in the card from somewhere else
rather than making in-house?)
cheers
Jules
I seem
to remember something about co-processor boards with i860
chips on
them?
Yes, RCS has some of those kicking around.
Quite some time back I used an OCR package on a 486 that used the AMD
29K PeeCee development board for the horsepower.
9:34 a.m.
Jules Richardson wrote:
The first generation Palantir (later renamed Calera) OCR machines contained a pipeline of
four 8 MHz 68000s, each doing a bit of the pipeline. It was a $30K machine.
The second generation machine upgraded to 68020s running at 16 MHz, as I recall, but it is
kinda blurry since I also spent a fair amount of time prototyping systems with 16 MHz
68000s from Thompson. We tried a number of configurations to see which gave the best
performace/$. The second generation machine came out at $30K, and they continued to sell
the first generation machine at a reduced price, like $24K. The funny thing is the first
generation machine was more expensive to build, so in time they switched to shipping 2nd
generation machines with delay loops to the customers who could afford only the $24K price
tag.
The 68020-based ISA accelerator was $2K, and ran as fast as the first generation machine.
Although a 16 MHz 68020 isn't four times as fast as four 8 MHz 68000s, the pipeline
nature of the 1st gen machine meant that frequently one or more processors were idled
waiting for input or output. The 68020 on the ISA card ran full out all the time that
work was available.
So why the 68020 on the ISA card? 68K code compatibility was part of the decision,
although the vast majority of code was done in C. The bigger reason was that at the time,
RISC was a new trend. At the time I don't know if Sun had announced SPARC yet. MIPS
was
around, but the R2K was expensive and hard to fit on an ISA card. R3K was manageable, and
that came later.
BTW, Caere also came out with 68020 accelerator board for doing OCR around the same time
Calera did, although they didn't use any ASICs for acceleration. It was all
software.
Eventually Caere acquired Calera, or they merged. Caere's Omnipage name lives on as a
Scansoft product, although they recently got acquired by a different company. I've
read
that the latest couple of versions (I think they are at Omnipage 16 now) are a step
backwards.
Dave McGuire wrote:
...
In 1988 or
so, I used a similar OCR setup at work. I think it was
called Calera, but I'm not sure. It used an ISA board with a 16MHz
68020 and a bunch of memory on it. It ran under DOS. Its code was
all RAM-based, and was downloaded into the board at boot time by
programs run from autoexec.bat.
That's interesting - so I wonder if they made a design decision to use
the 68k, or did they already have a product based around a 68k (possibly
on a Mac?) and it made the porting effort to the PC platform a lot
easier just to sell the product with a copro board? Back then most OCR
products commanded a huge price tag, so doubtless adding the cost of an
ISA card didn't make much difference (but I assume that they bought in
the card from somewhere else rather than making in-house?)
8:56 a.m.
Dave McGuire wrote:
On Dec 13, 2008, at 7:03 PM, William Donzelli wrote:
In 1988 or so, I used a similar OCR setup at work. I think it was
called Calera, but I'm not sure. It used an ISA board with a 16MHz
68020 and a bunch of memory on it. It ran under DOS. Its code was all
RAM-based, and was downloaded into the board at boot time by programs
run from autoexec.bat.
-Dave
(somehow cctalk and cctech are both on the distribution list -- I'm taking cctech
off)
Heh, thank you, thank you. I designed that board, as well as two of the three ASICs on
it. I later designed a replacement ASIC that combined all of them into one, and was pin
compatible with one of the existing parts so the same board could be used. Forgive my
ramble, as the opportunity to talk about this 20 year old product doesn't happen very
often.
The first year Byte magazine ran their top 10 products of the year, it was one of the
winners.
One ASIC, the first one I ever designed, was what LSI logic called a "structured
array".
It contained a 2KB RAM and about 5K usable gates. This part would be programmed with the
x,w,w,h of some putative location of a character image on the 1 bpp frame buffer. It
would fetch the bitmap and turn it into a normalized MxN gray scale image, although 5x7
was always what was used. Added as an afterthought, because I had a few hundred unused
gates, I added the ability to rotate a 32x32 block of image. The 68020 would write 32
words to registers on the chip (really, it went into that 2KB RAM), then it would read
them back out at a different address and get them rotated. By stepping through the image
in the right order, you could rotate the entire image. It was considerably faster than
having the 68020 do the rotation in software.
The other ASIC I designed for that product was a 68020 memory controller plus vector
compare logic. The memory controller had flexible timing control to allow interfacing to
different types of DRAM, and also took care of parity generation/checking (optional). The
vector compare logic would be loaded with one of the normalized 5x7 character images
(although other sizes were permitted, software only ever used 5x7) and would be given a
stream of pointers to reference 5x7 images in memory. The vector compare would compute
the sum of squared differences on each image, and would save the best fit distance and an
index to which reference character generated that best fit. A large part of the memory
contained these reference characters sets. A hierarchical search was used to find the
closest match very quickly, instead of a brute force compare each character against all
reference images.
Right now I'm drawing a blank what the 3rd ASIC did. It was designed by a guy named
Jeffrey Soreff.
This was before Verilog was widely used, so all of it was done via gate-level schematics,
drawn using LSI's schematic capture program.
While the ASICs were in fab, I designed the ISA card. We had no spec for the ISA bus, so
I simply looked at the schematics and timing diagrams that came with one of our Compaq
computers and with an early IBM PC.
There was a control register that the ISA side could write to control the 68020; the ISA
side could reset the 68020 and it could also raise an interrupt. There was an 8 bit
"mailbox" register that both sides could read or write. Both sides could also
read and
write the DRAM on the board, although on the ISA side only an 8KB window was visible at
any time, selected via a mapping register.
One very interesting and touchy part of the design came from the marketing dictate that
there be no user configuration jumpers on the card, which was nearly universal at the
time. Instead a very elaborate configuration sequence was used; I contributed some of the
ideas, but most of the hard work of making it reliable fell to a guy named John Taves.
I described how it worked on this list a few years ago; in fact, I see it was on January
31, 2005. Search the archives for that date or the text "Calera Recognition
Systems" and
you should find it, if you care to.
I seem
to remember something about co-processor boards with i860
chips on
them?
Yes, RCS has some of those kicking around.
Quite some time back I used an OCR package on a 486 that used the AMD
29K PeeCee development board for the horsepower. 
7:08 p.m.
One ASIC, the first one I ever designed, was what LSI
logic called a
"structured array".
It contained a 2KB RAM and about 5K usable gates. This part would be
programmed with the
x,w,w,h of some putative location of a character image on the 1 bpp frame
buffer. It
would fetch the bitmap and turn it into a normalized MxN gray scale image,
although 5x7
was always what was used. Added as an afterthought, because I had a few
hundred unused
gates, I added the ability to rotate a 32x32 block of image. The 68020
would write 32
words to registers on the chip (really, it went into that 2KB RAM), then
it would read
them back out at a different address and get them rotated. By stepping
through the image
in the right order, you could rotate the entire image. It was
considerably faster than
having the 68020 do the rotation in software.
Wish I could understand what you are saying :) But it will take some
time...
8:16 p.m.
Alexandre Souza wrote:
That made sense to me, I think - and thanks, Jim... It's nice when the people
involved in some of the stuff that gets talked about here speak up and go a
little into the internals; for some reason that doesn't seem to happen much
here and I wish it did :-)
One ASIC, the
first one I ever designed, was what LSI logic called a
"structured array".
...
Wish I could understand what you are saying :) But it will take some
time...
2:01 p.m.
--- On Mon, 12/15/08, Dave McGuire <mcguire at neurotica.com> wrote:
BYTE had a coprocessor project sporting a 68020. For the life of me I can't remember
what it's job was though. Something tells me it was related to graphics, but not an
actual crt controller or what have you.
Quite some
time back I used an OCR package on a 486
that used the AMD
29K PeeCee development board for the horsepower.
In 1988 or so, I used a similar OCR setup at work. I
think it was called Calera, but I'm not sure. It used
an ISA board with a 16MHz 68020 and a bunch of memory on it.
It ran under DOS. Its code was all RAM-based, and was
downloaded into the board at boot time by programs run from
autoexec.bat.
3:43 a.m.
On Dec 13, 2008, at 6:51 PM, Sridhar Ayengar wrote:
I seem to remember something about co-processor boards with i860
chips on them?
MicroWay's Number Smasher 860. One showed up on eBay in September.
-Dave
--
Dave McGuire
Port Charlotte, FL
Did anybody ever use one, or any kind of general
purpose co-
processor
boards for the PC?
Not me, but I remember such things existed for a while in the
days
before the 486 was dominant. 
13 Dec
13 Dec
6:13 a.m.
Date: Fri, 12 Dec 2008 16:23:00 -0600
From: ethan.dicks at gmail.com
To: cctalk at classiccmp.org
Subject: Re: 68k homebuilts
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)
... 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.
The 68k CPU even provides signals to interface the 6800/6809 era I/O
peripheral chips like the ACIA, PIA and PTM. The 68k synchronizes to the
E clock when VPA is asserted. The 68k is really easy to use together
with SRAM and simple I/O. I have designed one for my StarShip when I
discovered that the 6802 was no longer sufficient. In the end, the 68000
was replaced by the pin-compatible 68010 (but the '010 has a different
stack frame, so interrupt (exception) processing (in the OS) has to be
adapted. And now I am using a VME bus card with an 68020 at 30 MHz.
Should pick up that hobby again!
So little time, so many (geeky) things to do ...
- Henk.
9:50 a.m.
New subject: Canon Cat was: 68k homebuilts
Hi
First I'd like to mention that the Canon Cat is an interseting
68K machine. With an assembler written in Forth for the 68K
one could even use it to create their code for their home
built 68K machine.
Behind the Cat's editor is a nice Forth that give one complete
access to the Cat's I/O and memory space. It has a bit mapped video
as well.
It would be a great machine to create code and debug. The
ability to attach code words to the Forth makes it an
easy way to run code in an environment that is one of the
best for experimenting and debugging. One can use the
editor to write the code and then assemble and debug
using Forth as a debug monitor.
A few of us have started a google group specifically for
the Canon Cat. It can be found at:
http://groups.google.com/group/canon-cat
We are new ( a few weeks old ) and are looking for more members.
We welcome talk on other related subjects. This includes the
Swyft prototype, Apple II's SwyftCard and SwyftWare.
Talk on Jef Raskin's concepts of Humane Interface are also
welcome.
You say, this is all fine but you don't have a Canon Cat and
these machines are as rare as hen's teeth.
It seems that one has just come up for auction. See:
http://www.vintage.org/special/2008/accrc/
The suggested price is not giveaway but reasonable, considering
that they have gone for as high as $1800 on ebay.
Dwight
_________________________________________________________________
Send e-mail anywhere. No map, no compass.
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhe…
14 Dec
14 Dec
9:32 p.m.
New subject: Canon Cat was: 68k homebuilts
On Dec 13, 2008, at 9:50 AM, dwight elvey wrote:
First I'd like to mention that the Canon Cat is
an interseting
68K machine. With an assembler written in Forth for the 68K
one could even use it to create their code for their home
built 68K machine.
Behind the Cat's editor is a nice Forth that give one complete
access to the Cat's I/O and memory space. It has a bit mapped video
as well.
It would be a great machine to create code and debug. The
ability to attach code words to the Forth makes it an
easy way to run code in an environment that is one of the
best for experimenting and debugging. One can use the
editor to write the code and then assemble and debug
using Forth as a debug monitor.
That machine sounds like a great deal of fun. It's a shame there
aren't more of them out there.
-Dave
--
Dave McGuire
Port Charlotte, FL
15 Dec
15 Dec
1:36 p.m.
New subject: Canon Cat was: 68k homebuilts
--- On Sun, 12/14/08, Dave McGuire <mcguire at neurotica.com> wrote:
That machine sounds like a great deal of fun.
It's a
shame there aren't more of them out there.
There would be if some reverse engineered the asics. Or developed a generic Canon Cat
board. Maybe those roms (or the forth portion anyway) would work in any 68k system.
My IBM System 23/Datamaster has a built in FORTH interpreter. Haven't had time to
experiment. Anyone have experience w/that?
What benefits does having FORTH in rom have over BASIC? Or a ml monitor?
4:16 p.m.
New subject: Canon Cat was: 68k homebuilts
On Dec 15, 2008, at 1:36 PM, Chris M wrote:
No, I didn't know it had a Forth, I thought the System 23 had
BASIC in ROM. Neat!
That machine
sounds like a great deal of fun. It's a
shame there aren't more of them out there.
There would be if some reverse engineered the asics. Or developed
a generic Canon Cat board. Maybe those roms (or the forth portion
anyway) would work in any 68k system.
My IBM System 23/Datamaster has a built in FORTH interpreter.
Haven't had time to experiment. Anyone have experience w/that? What benefits does having FORTH in rom have over
BASIC? Or a ml
monitor?
Hmm, what benefits...Howabout "Forth is less ugly than
BASIC"? ;) [dave ducks]
-Dave
--
Dave McGuire
Port Charlotte, FL
4:38 p.m.
New subject: Canon Cat was: 68k homebuilts
--- On Mon, 12/15/08, Dave McGuire <mcguire at neurotica.com> wrote:
Hmm. Can't find any references to this upon googling. Could it be a myth? Could the
reports have solely originated from this list...
My IBM System
23/Datamaster has a built in FORTH
interpreter. Haven't had time to experiment.
Anyone have
experience w/that?
No, I didn't know it had a Forth, I thought the
System 23 had BASIC in ROM. Neat!
16 Dec
16 Dec
12:41 a.m.
New subject: Canon Cat was: 68k homebuilts
From: mcguire at neurotica.com> Date: Mon, 15 Dec
2008 16:16:36 -0500> To: cctech at classiccmp.org> CC: > Subject: Re: Canon Cat
was: 68k homebuilts> > On Dec 15, 2008, at 1:36 PM, Chris M wrote:> >> That
machine sounds like a great deal of fun. It's a> >> shame there aren't
more of them out there.> >> > There would be if some reverse engineered the
asics. Or developed > > a generic Canon Cat board. Maybe those roms (or the forth
portion > > anyway) would work in any 68k system.> > My IBM System
23/Datamaster has a built in FORTH interpreter. > > Haven't had time to
experiment. Anyone have experience w/that?> > No, I didn't know it had a Forth,
I thought the System 23 had > BASIC in ROM. Neat!> > > What benefits does
having FORTH in rom have over BASIC? Or a ml > > monitor?
Hi
I've tried to explain this to people over the years and about the best
way I can say it is, it is about problem factoring.
Dwight
> Hmm, what benefits...Howabout "Forth is less
ugly than > BASIC"? ;) [dave ducks]> > -Dave> > -- > Dave
McGuire> Port Charlotte, FL> >
_________________________________________________________________
Send e-mail faster without improving your typing skills.
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_…
12 Dec
12 Dec
12:34 a.m.
Jim Battle wrote:
In 1985 I was fresh out of school, moved to Sunnyvale
CA to work for BTI
Computer Systems, and in within two weeks of starting work had been
through the first round of layoffs.
First round then, maybe -- trust me, there were a bunch well before then ;)
[snip]
Next I found the source for a 68K monitor program,
call VuBug. As I
recall the 68K assembler was in the BTI dialect of FORTRAN. I believe
it was a version of RM Fortran (Ryan McFarland).
That would probably be right. Aside from the Dragon complier and the
assembler I think pretty much everything in the timeframe in question
was purchased from RM.
--
Chris Kennedy
chris at mainecoon.com AF6AP/AFA6KY
http://www.mainecoon.com PGP KeyID 108DAB97
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
"Mr. McKittrick, after careful consideration..."
10:08 a.m.
Jim Battle wrote:
In 1985 I was fresh out of school, moved to Sunnyvale
CA to work for BTI
...
Thanks for that; I've seen quite a lot of homebrew machines over the years,
but they always seem to be lacking the back-story of quite why their inventors
built them, or of how they got them working, so that was a good read!
(I've always been curious as to how many homebrew machines 'just work' on
their first try - in the sense that at at least the CPU, enough memory, and
enough I/O comes to life in order to debug things further.)
cheers
Jules
10:35 a.m.
Thanks for that; I've seen quite a lot of homebrew
machines over the years,
but they always seem to be lacking the back-story of quite why their inventors
built them, or of how they got them working, so that was a good read!
(I've always been curious as to how many homebrew machines 'just work' on
their first try - in the sense that at at least the CPU, enough memory, and
enough I/O comes to life in order to debug things further.)
I did two lo these many years ago. It was 1987, but I still can't
bring myself to think it's been over 20 years. Anyway, they were
part of a larger, multi-processor system. As I recall, they did
mostly just work. But I should mention that I used static RAM
rather than dynamic and I'm sure that helped. I never did finish
debugging the floppy controller though... It was for my master's
and once I had defended, I don't think I ever powered it up again.
And re the other thread, my schematics were all hand-drawn. They
were good enough that my (at that time newlywed) wife was able to
do the wire-wrapping on one of them.
BLS
10:16 a.m.
On Thu, Dec 11, 2008 at 10:56:35PM -0600, Jim Battle wrote:
John Floren wrote:
>Hi everyone
>
>As a 4th year computer engineering student with a part time job, I
...
Next I found the source for a 68K monitor program,
call VuBug. As I recall
the 68K assembler was in the BTI dialect of FORTRAN. I believe it was a
I wrote my own 68K monitor program years ago for the surplus mac boards
that were becoming available. Complete with mini-disassembler and
S code downloader.
- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
4:06 p.m.
Hi everyone
As a 4th year computer engineering student with a part time job, I
definitely have too much time on my hands, so I've been thinking about
doing something like building my own computer. I remember playing with
the 68k SBCs back in my assembly class, so I thought something from
that family might be an interesting choice. It's ambitious, but
ideally I'd like to do 16/32 bits and a few megs of memory.
Have any of you built something like this? I'm looking for links to
I've built several machines from scratch, but never a 68K-based one. But
I do feel that's a pretty good choice for a processor :-)
I would start by tracking down a _second edition_ of the 'Student Manual
for the Art of Electronics' (that may not be the exact title, but if you
can't find it I'll dig out my copy and post more details). This is the
'laboaratory book' for the famous 'Art of Electronics' book (which you
should have anyway :-)), and the last few exercises are making a
68008-based computer (so 8-bit data bus) with something like 8K of static
RAM a bit of I/O, etc. You won;t want to copy that design, but it'll give
you ideas.
As regards RAM, I really would use static RAM, at least to start with.
It's a lot easier to work with than dynamic RAM, and SRAM is getting
pretty cheap these days.
You also need to think what I/O you want. Do you want a toggle-switch
panel to load ROM, a monitor program (hex keypad and display, or an ASCII
terminal interface?), a bootstrap for some larger OS (to be loadrd from
what device?) and so on. Personally, I'd probably add a serial port and
have a simple machine code monitor in EPROM, but it's up to you.
-tony
5:09 p.m.
On Fri, Dec 12, 2008 at 4:06 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Well, part of my motivation for doing this is that I'm really an
operating systems guy, so in a perfect world I'd be able to make
something I could hack around with easily. With that in mind, I'm
thinking a serial terminal interface, but also including a front panel
with toggles and lights to play with. It would be really fun to go so
crazy as to do a PDP-11 to the point where I could boot one of the old
OS's, but that may be too ambitious for me at this time (can you even
buy PDP-11 microprocessors anymore?).
Given my druthers, I'd go with a 32-bit system, but I'm not sure if
that will increase the complexity beyond my abilities. I'm competent
with soldering and ok when it comes to breadboarding; things could
quickly go downhill if I tried to assemble on perfboard since I've
only tried that for very small circuits. The whole process of
assembling a computer system from the chip level is new to me, so any
tips would be appreciated. My reasons for preferring 32-bit is that
the potential capabilities are much greater.
What does it take to do video (bitmapped) output, by the way? That
would be especially interesting, in my opinion.
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
Hi everyone
As a 4th year computer engineering student with a part time job, I
definitely have too much time on my hands, so I've been thinking about
doing something like building my own computer. I remember playing with
the 68k SBCs back in my assembly class, so I thought something from
that family might be an interesting choice. It's ambitious, but
ideally I'd like to do 16/32 bits and a few megs of memory.
Have any of you built something like this? I'm looking for links to
I've built several machines from scratch, but never a 68K-based one. But
I do feel that's a pretty good choice for a processor :-)
I would start by tracking down a _second edition_ of the 'Student Manual
for the Art of Electronics' (that may not be the exact title, but if you
can't find it I'll dig out my copy and post more details). This is the
'laboaratory book' for the famous 'Art of Electronics' book (which you
should have anyway :-)), and the last few exercises are making a
68008-based computer (so 8-bit data bus) with something like 8K of static
RAM a bit of I/O, etc. You won;t want to copy that design, but it'll give
you ideas.
As regards RAM, I really would use static RAM, at least to start with.
It's a lot easier to work with than dynamic RAM, and SRAM is getting
pretty cheap these days.
You also need to think what I/O you want. Do you want a toggle-switch
panel to load ROM, a monitor program (hex keypad and display, or an ASCII
terminal interface?), a bootstrap for some larger OS (to be loadrd from
what device?) and so on. Personally, I'd probably add a serial port and
have a simple machine code monitor in EPROM, but it's up to you.
-tony
8:56 p.m.
--- On Fri, 12/12/08, John Floren <slawmaster at gmail.com> wrote:
What does it take to do video (bitmapped) output, by
the
way? That
would be especially interesting, in my opinion.
adding a subsystem based around some crt controller (the early Macs incidentally lacked a
dedicated crt controller). W/some low level graphics primitives to boot if you felt like
it. If I understand the question...
13 Dec
13 Dec
2:52 p.m.
Well, part of my motivation for doing this is that
I'm really an
operating systems guy, so in a perfect world I'd be able to make
something I could hack around with easily. With that in mind, I'm
thinking a serial terminal interface, but also including a front panel
with toggles and lights to play with. It would be really fun to go so
crazy as to do a PDP-11 to the point where I could boot one of the old
OS's, but that may be too ambitious for me at this time (can you even
buy PDP-11 microprocessors anymore?).
Given my druthers, I'd go with a 32-bit system, but I'm not sure if
that will increase the complexity beyond my abilities. I'm competent
Making a 32 bit system is not inherently any harder than making a 16 bit
one, there are just more data bus lines to wire up, more RAM/EPROM chips,
more bufferes, etc.
It ;s worth rememberign at this point that the cirtcuit can be divided
into 'data path' and 'control' sectiosn. In this case, 'data path'
is the
data buffers nas the physical connetions to the chips, which is
relatively easy to design, but the number of connections increases with
the data width. 'Control' is when to enable those buffers, the chip
selects to the RAMs, EPROMs, etc, the DTACK/ generator, and so on. More
complesx to design, but essentially independant of data width.
with soldering and ok when it comes to breadboarding;
things could
quickly go downhill if I tried to assemble on perfboard since I've
only tried that for very small circuits. The whole process of
assembling a computer system from the chip level is new to me, so any
tips would be appreciated. My reasons for preferring 32-bit is that
the potential capabilities are much greater.
I don't want to put you off, bnt I think you might be taking on rather
more than you should to start with.
Avoid those plugblock-type solderless breadboards. You will have no end
of problems from bad connections, and maybe even stray capacitance.
Solder it up (or wire wrap it) from the start. You can build it on
stripboard (in fact I would recomend against making a PCB for an
experimental machine, since you want to be able to change things).
My recomentation is that you look at that book I suggested. And possibly
uild the machine descried there (if you can get a 68008, are they easy to
get now?). The point is, it's an 8 bit bus, with 8K of RAM, or something
like that. Easy to wire up. You know the instruction set (I beleive), so
you'll have no problems writing simple programs for it. Maybe all you'll
do is blink LEDs, detect swtich closeures, that sort of thing. But I can
assure you ity's agreat feeling when your homebuilt machine runs a
program, no matter how simple.
And from building that you'll get skils and confidence to try soemthing
bigger.
What does it take to do video (bitmapped) output, by the way? That
would be especially interesting, in my opinion.
A sup[rising amount of logic. Basically you need an area of memory that
can be accessed both by the CPU and by the video hardware. Typvially RAM
with multiplexers to switch it between the 2 devices. Then counters to
scan trhough the RAM, and also generate the video sync signals (take a
look at the 6845 chip to have some idea as to what's involved). Read
bytes out of RAM into a shift register, shift htem along to make the dot
stream, combine it with the syncs to make a composite signal and feed it
to the monitor
I guess yuo could use an FPGA to house most of the logic, but I find it's
easire to debug something like this when I can clip my 'scope or logic
analyser onto just about any point in the circuit.
-tony
6:05 p.m.
Tony Duell wrote:
Agreed - it's likely to be more of a pain in the backside due to the amount of
wiring, but shouldn't necessarily be any more complex (at least if using SRAM
for memory - I've seen some really convoluted DRAM refresh designs for CPUs of
16 or more data bits)
Way back I had some sort of RS232-capable graphics box called Pluto - I
believe the idea was that you could send it graphics primitive commands via
RS232 and it'd render them on a suitable display (I think it was VGA, but it's
been so long now).
Whilst that's not quite what the OP's after, I think there's some potential
there in that a modern PC with a serial port could be initially and quickly
used to do that task, with the 'real' hardware built later. (I suspect it's
the route I would take, purely as offloading the graphics ability elsewhere
seems to have a certain 'cool factor' about it :-)
Given my
druthers, I'd go with a 32-bit system, but I'm not sure if
that will increase the complexity beyond my abilities. I'm competent
Making a 32 bit system is not inherently any harder than making a 16 bit
one, there are just more data bus lines to wire up, more RAM/EPROM chips,
more bufferes, etc. Avoid those plugblock-type solderless breadboards. You
will have no end
of problems from bad connections, and maybe even stray capacitance.
I've heard of people having no problems with 8 bit CPUs, but I'm sure it does
become an issue at some stage - maybe even for an 8MHz or so 68k.
Solder it up (or wire wrap it) from the start. You can
build it on
stripboard (in fact I would recomend against making a PCB for an
experimental machine, since you want to be able to change things).
One of the things that's kept putting me off doing this myself over the years
is actually *how* to best tackle the design phase. I'm not sure what the best
technology is to use (given the large amount of interconnects), but then I've
never tried wirewrap before.
(if you can get a 68008, are they easy to get now?)
Were they ever? I've got two 68008 ICs (one in the Cumana copro for a BBC
micro, and one in a STE-bus board) and those are the only two I've ever come
across. Compare that to a healthy pile of Z80 and 68000 (and '010 etc.)
processors...
I'm not sure they ever really saw much widespread use (actually, what
commercial machines used them other than the Sinclair QL?)
What does it
take to do video (bitmapped) output, by the way? That
would be especially interesting, in my opinion.
A sup[rising amount of logic. Basically you need an area of memory that
can be accessed both by the CPU and by the video hardware. Typvially RAM
with multiplexers to switch it between the 2 devices.
I think quite a few systems did it on the falling edge of the clock signal,
didn't they? i.e. the memory was only accessed by the CPU on the rising edge,
so (if fast enough) was essentially free on a falling edge. Elegant, but
probably hell to debug and get working as a first project (particular if DRAM
refresh is thrown in there)
cheers
Jules
6:20 p.m.
On Sat, Dec 13, 2008 at 6:05 PM, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Tony Duell wrote:
After doing some looking I thought I'd go with 68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
try something even simpler first, if I can get my hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
(if you can get a 68008, are they easy to get
now?)
Were they ever? I've got two 68008 ICs (one in the Cumana copro for a BBC
micro, and one in a STE-bus board) and those are the only two I've ever come
across. Compare that to a healthy pile of Z80 and 68000 (and '010 etc.)
processors...
I'm not sure they ever really saw much widespread use (actually, what
commercial machines used them other than the Sinclair QL?)
6:50 p.m.
John Floren wrote:
After doing some looking I thought I'd go with
68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
try something even simpler first, if I can get my hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
My vote is for processor-from-scratch. Designing and building a simple
RISC architecture into a CPLD is still one of the most fun exercises
I've ever undertaken.
BTW, my machine runs FORTH. Most of the FORTH environment consists of,
as has been suggested as a good method, off-the-shelf FORTH primitives
written in FORTH.
Peace... Sridhar
8:30 p.m.
Sridhar Ayengar wrote:
John Floren wrote:
How do you have RISC from a CPLD since RISC implies a large register stack?
Live long and prosper ... Spock
After doing some looking I thought I'd go
with 68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
try something even simpler first, if I can get my hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
My vote is for processor-from-scratch. Designing and building a
simple RISC architecture into a CPLD is still one of the most fun
exercises I've ever undertaken.
BTW, my machine runs FORTH. Most of the FORTH environment consists
of, as has been suggested as a good method, off-the-shelf FORTH
primitives written in FORTH.
Peace... Sridhar
10:33 p.m.
bfranchuk at jetnet.ab.ca wrote:
Sridhar Ayengar wrote:
Not necessarily. That's one possible advantage of a RISC design, but it
isn't necessary in order to be a RISC.
Peace... Sridhar
John Floren wrote:
How do you have RISC from a CPLD since RISC implies a large register stack?
After doing some looking I thought I'd go
with 68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
try something even simpler first, if I can get my hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
My vote is for processor-from-scratch. Designing and building a
simple RISC architecture into a CPLD is still one of the most fun
exercises I've ever undertaken.
BTW, my machine runs FORTH. Most of the FORTH environment consists
of, as has been suggested as a good method, off-the-shelf FORTH
primitives written in FORTH.
Peace... Sridhar
14 Dec
14 Dec
9:19 a.m.
How do you have RISC from a CPLD since RISC implies a
large register
stack?
It does? I thought it implied a (moderately) minimalist instruction
set. This tends to correlate with having lots of registers, but that's
hardly necessary - consider the PDP-8, for example.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
15 Dec
15 Dec
12:43 p.m.
der Mouse wrote:
The idea of a RISC is that out of few general addressing modes
( to keep decoding simple ) you generate all the other needed
ones in software. Since decoding is so simple you can ran faster by
pipelining
everything and goes real fast, providing *gotya* main memory is that fast
too.
The 8 is reduced because you have to cram everything in 12 bits.
How do you
have RISC from a CPLD since RISC implies a large register
stack?
It does? I thought it implied a (moderately) minimalist instruction
set. This tends to correlate with having lots of registers, but that's
hardly necessary - consider the PDP-8, for example.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:44 p.m.
bfranchuk at jetnet.ab.ca wrote:
der Mouse wrote:
The idea of a RISC is that out of few general addressing modes
( to keep decoding simple ) you generate all the other needed
ones in software. Since decoding is so simple you can ran faster by
pipelining
everything and goes real fast, providing *gotya* main memory is that fast
too.
But again, none of those performance enhancement strategies are
*required* to be in a RISC chip.
Peace... Sridhar
How do
you have RISC from a CPLD since RISC implies a large register
stack?
It does? I thought it implied a (moderately) minimalist instruction
set. This tends to correlate with having lots of registers, but that's
hardly necessary - consider the PDP-8, for example.
14 Dec
14 Dec
12:45 a.m.
On Sat, Dec 13, 2008 at 6:20 PM, John Floren <slawmaster at gmail.com> wrote:
After doing some looking I thought I'd go with
68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
try something even simpler first, if I can get my hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
The 68020 can actually run with a 8-bit data bus. See Motorola
Application Note AN1015, "68020 Minimum System Configuration", I have
it in my copy of the 16/32-bit Applications Manual, DL409/D. If you
can't find it on-line, I could scan it next week some time.
Joe.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
2:13 p.m.
After doing some looking I thought I'd go with
68020 if I were to do
32-bit, or 68000 for 16-bit. I may take Tony's excellent advice and
IIRC, the 68020 has the feature that you can set the bus width by the
states of a couple of pins. This was normally done to allow efficient
access to 8-bit I/O devices (you can change the states of these pins
depending on the current address ,of course), but there's no reason why
you shouldn't hold the pins in the states for an 8-bit data bus and just
have 8 it memory. Of course it's slower (4 memory cycles for each 32 it
access), but it will work.
try something even simpler first, if I can get my
hands on the Art of
Electronics books... they're on Amazon, I'll probably just have to
buckle down and shell out the money.
'The Art of ELectronics' is IMHO a book every electronics engineer should
own. There's a lot of good stuff in it. Sure there are the odd things I
disagree with, there are things I'd do differently, but by the time
you've read it, you'll know enough to be able to work out how you'd want
to do things.
My criticism of the Student Manual is that as it was written for a
university course, it assumes you have access to some nice test gear
(like a 'scope, bench PSU, etc). This means the esperiments possibly
can't be done by the average hobyist just starting out. But again there's
a loot of good stuff in it, and I don't think you need too much exotic
stuff for the 68008 circuits.
-tony
9:38 p.m.
On Dec 14, 2008, at 2:13 PM, Tony Duell wrote:
'The Art of ELectronics' is IMHO a book every
electronics engineer
should
own. There's a lot of good stuff in it. Sure there are the odd
things I
disagree with, there are things I'd do differently, but by the time
you've read it, you'll know enough to be able to work out how you'd
want
to do things.
Agreed 100%. That book always lives in an easily-grabbable spot
in my library.
My criticism of the Student Manual is that as it was
written for a
university course, it assumes you have access to some nice test gear
(like a 'scope, bench PSU, etc). This means the esperiments possibly
can't be done by the average hobyist just starting out. But again
there's
a loot of good stuff in it, and I don't think you need too much exotic
stuff for the 68008 circuits.
Eh, a good scope and bench power supply can both be had for less
(possibly much less) than $100 these days. That's not much of a
limitation.
-Dave
--
Dave McGuire
Port Charlotte, FL
13 Dec
13 Dec
7 p.m.
(if you can
get a 68008, are they easy to get now?)
Were they ever? I've got two 68008 ICs (one in the Cumana copro for a BBC
micro, and one in a STE-bus board) and those are the only two I've ever come
across. Compare that to a healthy pile of Z80 and 68000 (and '010 etc.)
processors...
I'm not sure they ever really saw much widespread use (actually, what
commercial machines used them other than the Sinclair QL?)
14 Dec
14 Dec
2:07 p.m.
[Adding a video display]
I think I have one of those somewhere. I thoguht the video outptu was
analogue RGB at TV rates, but I could well be mistaken.
[...]
On 68K machines it;'s more ocmmonly done by delaying DTACK until the
video hardare has completed oth its memory cycle and allowed the CPU to
do one.
-tony
A sup[rising
amount of logic.
Way back I had some sort of RS232-capable graphics box called Pluto - I Whilst that's not quite what the OP's after, I
think there's some potential
there in that a modern PC with a serial port could be initially and quickly
used to do that task, with the 'real' hardware built later. (I suspect it's
the route I would take, purely as offloading the graphics ability elsewhere
seems to have a certain 'cool factor' about it :-)
Another possibilty would be to add some slots compatible with HP's DIO
(strictly now DIO-1) bus. This uses the same connectors as the S100 bus,
but it's basically the 68000 bus (23 address lines, 16 data lines) with a
few extras that yuu could mostly ignore. About the only thing you'd have
to have on your processor board would be the prioirty encoder from 7
interrupt lines to the CPU's IPL signals.
There is at least one DIO monochrome video board set -- the 98204 IIRC.
It comes in 2 versions, for differnt horixontal scan rates (the 98204A is
TV-rate I think). It's all standard chips (maybe the odd PAL), I am
pretty sure I have scheamtics.
And of course there are DIO RAM boards, I/O boards, etc.
I think there's some info on the DIO hardware spec in one of the
_Pascal_ OS manuals on bitsavvers. I can dig out the URL if anyone can't
find it.
Basically you need an area of memory that
can be accessed both by the CPU and by the video hardware. Typvially RAM
with multiplexers to switch it between the 2 devices.
I think quite a few systems did it on the falling edge of the clock signal,
didn't they? i.e. the memory was only accessed by the CPU on the rising edge,
so (if fast enough) was essentially free on a falling edge. Elegant, but
probably hell to debug and get working as a first project (particular if DRAM
refresh is thrown in there) 
12 Dec
12 Dec
5:27 p.m.
John,
When I first started we built our own microprocessors out of discrete
transistors and built our floppy drives from scratch. Also we had to walk
through the snow to get to school and it was uphill both ways...
All seriousness aside, start with something not too ambitious so as not to
get overwhelmed early on because then it will never get done. If you want to
start REALLY simple, I have VHDL code for the Motorola MC14500B ONE bit
microprocessor. You can't get a smaller data buss than that !! You can
tackle more ambitious projects as your expertise grows. Wiring up a 32 bit
buss would be a real bitch or a labor of love. I'm certain you will get a
plethora of great ideas from these guys. Good luck !
Best regards, Steven
P.S. Personally I like the RCA / Hughes CMOS 1802 running FORTH.
Hi everyone
As a 4th year computer engineering student with a part time job, I
definitely have too much time on my hands, so I've been thinking about
doing something like building my own computer. I remember playing with
the 68k SBCs back in my assembly class, so I thought something from
that family might be an interesting choice. It's ambitious, but
ideally I'd like to do 16/32 bits and a few megs of memory.
Have any of you built something like this? I'm looking for links to
project pages, shared experiences, and advice on what processor to
use. Reminiscence is welcome too, if you have fond memories of such a
thing :)
Thanks
John Floren
8:27 p.m.
got to read further down the messages. For fun, you might want to pull apart a Sega
Genesis. Radio Electronics had (2) project 68k thingees - 1 was just a write up of
supposedly a popular kit or project in Europe back when (never heard of it otherwise,
maybe it circulated around uni's and whatnot) - the other was a bona fide Gernsback RE
project, several installments (I don't have a complete set). It turns out that project
is still *supported*, presumably by the person who developed it, and received *free*
advertising in the magazine. He wants an absorbadent amount of money for anything related
to it. The schematics and artwork even was featured in the magazine, but rom listing were
not. You'll likely want to write your own.
There has been interest in these items on the list in the past. Like I said I don't
have a complete set of articles, but at least 1 or 2. I'll dig them out and look them
over and get back to you. One neat thing about the RE unit - it had an 8-bit ISA bus.
--- On Thu, 12/11/08, John Floren <slawmaster at gmail.com> wrote:
From: John Floren <slawmaster at gmail.com>
Subject: 68k homebuilts
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Date: Thursday, December 11, 2008, 9:39 PM
Hi everyone
As a 4th year computer engineering student with a part time
job, I
definitely have too much time on my hands, so I've been
thinking about
doing something like building my own computer. I remember
playing with
the 68k SBCs back in my assembly class, so I thought
something from
that family might be an interesting choice. It's
ambitious, but
ideally I'd like to do 16/32 bits and a few megs of
memory.
Have any of you built something like this? I'm looking
for links to
project pages, shared experiences, and advice on what
processor to
use. Reminiscence is welcome too, if you have fond memories
of such a
thing :)
Thanks
John Floren
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl
fhtagn
5698
days inactive
5702
days old
65 comments
23 participants
participants (23)
-
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
blstuart＠bellsouth.net -
cclist＠sydex.com -
chris＠mainecoon.com -
chrism3667＠yahoo.com -
coredump＠gifford.co.uk -
db＠db.net -
dkelvey＠hotmail.com -
ethan.dicks＠gmail.com -
frustum＠pacbell.net -
glen.slick＠gmail.com -
henk.gooijen＠hotmail.com -
joachim.thiemann＠gmail.com -
jules.richardson99＠gmail.com -
mcguire＠neurotica.com -
mouse＠Rodents-Montreal.ORG -
pcw＠mesanet.com -
ploopster＠gmail.com -
slawmaster＠gmail.com -
steven.alan.canning＠verizon.net -
wdonzelli＠gmail.com