It seems that ?Google? engineer Bill Buzbee isn?t interested in microprocessors that can be purchased in marked. There is more fun to build own. Several years ago he built first ?Magic-1? processors , but now he makes its documentations widely available in his project website.
Thanks, Don. I absolutely LOVE doing this kind of thing. It should be required work for anyone in embedded programming, at least. 35 years ago I tried my hand at it and failed to get much useful. It wasn't until I later got access to a logic simulator that I was finally able to complete a successful processor design with 7400 logic, not using the
74181 ALU by the way, though I never built what seemed to work so well. Later, I picked up a Xilinx 4000 series demo board and, for the very first time, learned to write VHDL and finally coded up my first processor that worked!!! (I didn't do the floorplanning by hand -- way over my head at the time.)
Reminds me of the pdp11 look alike I worked on back in the early 70's... few hundred ttl chips , 64 bit diode matrix microcode, 8K ferrite sotore driven by loys of monostables to get the timing right.... I was used to poser some of the very first CNC machines in the UK- Herbert BatchMAtic and in Germany - Boehringer Vxxx series lathes. Those were the happy days......
That reminds me that there are some excellent course videos by David Culler of Berkeley showing how to build a CPU from logic gates. A bit of searching for his webcasts for course 61CL Fall 2009 in H.264 video should bring them up.
I had no idea until working through the lectures that *I* could build a CPU using components I already knew about. As part of the course he shows how to do so by working up from logic gates.
Back in '73 I worked on a 16 bit mini computer built entirely out of TTL, complete with a row of toggle switches on the front panel so you could enter machine code by hand. It had a paper tape reader and along with a paper tape punch you could use the two pass assembler - that's a lot of paper.
James Harris wibbled on Friday 26 February 2010 10:52
I knew a chap (York University Computing Services) who claimed to have a mate who built an elementary CPU from fruit machine relays. Occupied a bit of board about one square yard. He lost interest in building RAM from more relays, so wedged a 1k RAM chip with suitable interfacing on the side. Ran at about 1 IPS apparently...
 he got a box load from a surplus store, old stripped out ones. Had an unusual contact configuration that made them quite suitable.
In 1961 a colleague told me of a machine in a lab at Cornell named=20 CADET, which reputedly stood for "can't add, doesn't even try". But it=20 was a universal (Turing) machine. Most everyone has stood on the=20 shoulders of software to extend behavior. In another sense, cpu=20 development has also stood on the shoulders of software arts, for needs=20 drive real engineering, not possibilities, and software disciplines=20 provide the languages for expressing these needs.
Each to his own. Some yearn to create a theory, some to create a=20 bridge, some to create an impression. I still ponder the structure of a =
(programmable) computer of light and heavy marbles, gates, and a bunch=20 of elevators.
In the early 80's it was common to build "custom" processors out of 2900 bit-slice components. There was an excellent text (and some good AMD appnotes) devoted entirely to this (Mick 'n' Brick? yellow dust jacket).
In grade school, I build a combination (burglar) alarm using (bistable?) inter-latching relays for the code store. With a fire department klaxon as the annunciator (you *really* didn't want to get the combination wrong! :> )
In high school, I built a two-player (offense + defense) football (left-pondian football, that is :> ) game out of analog computers (integrators, adders), DTL and VOM's (to display: "down", field position, yards gained/lost on the play and yards 'til first down) but that just ran at "DC". It was also quite large (4' x 8' sheet of plywood to hold all the bits) and, thus, impractical to preserve.
Many years ago, I built a "digital clock" out of relays. But, it was very noisey and cost a fortune to keep replacing the incandescent lamps used in the "7 segment" displays.
Now, I am much more fascinated by electro-mechanical *mechanisms*. I have been working on a kinetic "sculpture" to act as a timepiece in the back yard. A tribute to Rube Goldberg -- with the exception that it must run *continuously* (most of his contraptions were "one-shot" devices). But, in order to keep *good* time, I need to "close the loop". Doing so without being noticed means using some "non-discrete" device that you can control. I.e., something like a liquid whose rate of flow can be varied without a critical observer being able to *easily* determine that this is happening. Living in the DSw poses a problem using water as it evaporates too fast (replenishing it from the domestic water supply would be "cheating" :< ). I also need to locate some larger solar panels so the device has no connection to the electric utility.
I would also like to build a "Jetson's" style doorbell (though programmable) to replace the electronic version I made some years ago. But, apparently, the design of tubular bells is more art than science (and, mistakes can be costly). So, I have a lot more research to do. :<
I designed a processor some years ago. A friend was responsible for writing the code for it.
*Nothing* worked! :< This was completely unexpected as we were both very competent in our individual responsibilities.
We soon realized that I had designed the instruction set expecting "word" addresses (memory was 16b wide and only accessible *as* 16-bit words -- hence it seemed *obvious* that addresses would be of "words") whereas he had assumed *byte* addresses. :< Simple fix. Took all of the drama out of the event! ;-)
I've seen other silly issues like this confound the initial startup of custom processors: e.g., confusion over which way the stack grows, whether the SP points to the last *used* location on the stack or the next *available*, etc. They are almost always "fun" problems to solve as they usually are easy to find and have dramatic consequences once found!