PDA

View Full Version : 1 (Yes, ONE) bit computer? MC14500B


DKDeckmann
November 25th, 2006, 07:21 AM
Anyone seen, done anything with, heard of the Motorola MC14500B industrial control unit? It is pretty much a one bit computer, 16 instructions... Made as a replacement for relay logic. Looks like it would be the heart of a simple computer or could be used as the microcode controller for a more complex design. I've only found a couple of projects using it on the web, a KYTRON 4 "robot" and a chineese experimental board... I've found a 1977 book for the chip on eBay and am looking forward to receiving it... Functionally it seems like an early, scaled-down version of the AM2910...

The chineese board uses the MC14500B as a controller, MC4040 as a program counter, 6116 RAM (only 256 bytes used), MC4099 as an output latch, MC4512 as input register, an unnamed inverter as glue logic, and a MC4011 as the clock... also quite a few LEDs so one can witch execution states, nad a couple banks of DIP switches for input and programming...

mbbrutman
November 25th, 2006, 07:40 AM
It's not as bad as it seems.

The machine surely can hold instructions that are multiple bits long. You said 16 instructions, so it handles at least nibbles.

The 1 bit designation probably refers to the ALU (Arithmetic Logic Unit). To get more than a 0 or a 1 out of it the hardware 'clocks' it multiple times. For example, for 32 bits of precision you run your math through the ALU 32 times. For more precision, keep going.

Believe it or not, the Thinking Machines CM-2 super computer (early 1990s) used a bit serial processor as its CPU. The thing that made it a super computer was that it had 65536 of them. :-)

Not sure if what you found is based on the same principle, but it does sound similar.

DKDeckmann
November 25th, 2006, 09:41 AM
Yes, obviously the program/instruction memory is wider than a single bit, however the data path and logic unit is a single bit wide...

The ICU can't directly manipulate the program counter EXCEPT for incrementing it. The only conditional branch is skip next if result is zero... The only test instruction is exclusive XNOR (if data = result register then result register = 1 which is pretty much an adder without carry)...

Looks like a nice one day project IF the parts can be located...

Here are a couple of links. The second one is quite long... but the most interesting...

Manual in japanese MC14500B
http://www.d1.dion.ne.jp/~ytera/Files/MC14500B.pdf

Experimental circuit
http://translate.google.com/translate?hl=en&sl=ja&u=http://www.rlc.gr.jp/project/computer/hardware/MC14500/mc14500.htm&sa=X&oi=translate&resnum=10&ct=result&prev=/search%3Fq%3Dmc14500b%26start%3D30%26hl%3Den%26lr% 3D%26sa%3DN

Mike Chambers
November 25th, 2006, 10:27 AM
interesting little chip! here's a page w/ the full instruction set and a link to the original data sheet in PDF format: http://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/


looks like a perfect project for me. i'd like to get into emulator programming, and this looks like the perfect chip to start with. can't get much more simple than this! :)

nige the hippy
November 25th, 2006, 11:20 AM
Also the sort of thing that could be implimented in transistors (or valves!) for a really retro beastie.

Mike Chambers
November 25th, 2006, 11:45 AM
Yes, obviously the program/instruction memory is wider than a single bit, however the data path and logic unit is a single bit wide...

The ICU can't directly manipulate the program counter EXCEPT for incrementing it. The only conditional branch is skip next if result is zero... The only test instruction is exclusive XNOR (if data = result register then result register = 1 which is pretty much an adder without carry)...

Looks like a nice one day project IF the parts can be located...

Here are a couple of links. The second one is quite long... but the most interesting...

Manual in japanese MC14500B
http://www.d1.dion.ne.jp/~ytera/Files/MC14500B.pdf

Experimental circuit
http://translate.google.com/translate?hl=en&sl=ja&u=http://www.rlc.gr.jp/project/computer/hardware/MC14500/mc14500.htm&sa=X&oi=translate&resnum=10&ct=result&prev=/search%3Fq%3Dmc14500b%26start%3D30%26hl%3Den%26lr% 3D%26sa%3DN

if you do build the thing, and you want to be able to run compiled binary from a ROM... let me know because i just made a compiler for the thing.

the term "compiler" is used loosely here... the chip is so simple, there is no real code interpretation necessary. it just takes an text file containing the list of opcode mnemonics that you write and turns them all into their binary values, writing them out in the same order to a .BIN file.

grant
November 25th, 2006, 06:28 PM
Do you mean AMD's 2901 instead of 2910? The AMD2901 with some support logic and ROM can emulate a 8MHz 8080 (faster than any real 8080).

AMD's document on bitsavers.org covers this. But they call it a 9080 emulator because that's their copy of the 8080.

Micom 2000
November 25th, 2006, 07:25 PM
I have a Heathkit ET 3400 which used an 8-bit Motorola 6800. We used this trainer in my digital electronics course. Am I missing something, but couldn't something like this be implemented simply by discrete components, using flip-flops and transistors. To do anything meaningfull would of course take you back to the size of a roomfull of components. I must admit to not fully digesting all we studied tho.

Lawrence

Off-topic, but does anyone know where I might obtain a missing single numerical displaychip for the ET3400 ?

L

grant
November 26th, 2006, 03:00 AM
Not a whole room, just a small box! Read about this guy:

http://www.homebrewcpu.com/

The 1bit processors are nice because they decrease part count by quite a bit. That makes products less expensive because of the number of parts and because of PCB space.

You can do anything using TTL logic that you want. Even make a dual core P4...if you had a big enough warehouse! ;)

nige the hippy
November 26th, 2006, 04:59 AM
implimenting a 1 bit full adder is about 8 simple gates (this particular chip doesn't have an adder), logic functions are just logic with a bit of stuff round them to turn them on & off, addresses come from a counter, multiplication (shifting) can be done via memory especially if it's circular (e.g.drum store), jumps are a bit more complex, but I suppose you could load the counter from the opcode, I'm not saying it's trivial, but it is possible.

& the guy who made a homebrew grant mentioned above, looking at the schematics it's actually a 16 bit machine, Wow, Masochist!

DKDeckmann
November 26th, 2006, 12:34 PM
I would think Jameco or Digikey would have a suitable replacement for the ET-3400 trainer display. Its just a common 7 segment LED isn't it?

I have a Heathkit ET 3400 which used an 8-bit Motorola 6800. We used this trainer in my digital electronics course. Am I missing something, but couldn't something like this be implemented simply by discrete components, using flip-flops and transistors. To do anything meaningfull would of course take you back to the size of a roomfull of components. I must admit to not fully digesting all we studied tho.

Lawrence

Off-topic, but does anyone know where I might obtain a missing single numerical displaychip for the ET3400 ?

L

DKDeckmann
November 26th, 2006, 12:47 PM
The 2910 would be the "support logic", the microcode controller, where the 2901 would contain a full ALU along with 16 registers, MUX, etc. Also note the 2901 is a 4 bit data path, you'd need to stack as many 2901s as necessary to get the width you wanted without resorting to "tricks" like doing data manipulation a nibble at a time...

The 2910, being a control device rather than an arithmatic unit is why I drew the analogy to if from the MC14500B...

In 1978 AMD published a series of booklets illustrating how one might construct a micro/mini using the 2900 family...

Do you mean AMD's 2901 instead of 2910? The AMD2901 with some support logic and ROM can emulate a 8MHz 8080 (faster than any real 8080).

AMD's document on bitsavers.org covers this. But they call it a 9080 emulator because that's their copy of the 8080.

DKDeckmann
November 26th, 2006, 12:54 PM
I haven't located a chip with a price yet. Lots of sites that want to give quotes of course. I'm waiting to see the manual to see if they present a complete processor scheme. It would seem better to follow any existing standard for machine design so it would integrate nicely with any existing "prior art", rather than creating a bastard child for a complete processor versus a controller...

if you do build the thing, and you want to be able to run compiled binary from a ROM... let me know because i just made a compiler for the thing.

the term "compiler" is used loosely here... the chip is so simple, there is no real code interpretation necessary. it just takes an text file containing the list of opcode mnemonics that you write and turns them all into their binary values, writing them out in the same order to a .BIN file.

grant
November 26th, 2006, 03:25 PM
Call or e-mail http://www.unicornelectronics.com/ for a price. They don't mess around and will give you a much lower price than the other partminer type people. They might have a minimum order if its not in stock.

Micom 2000
November 26th, 2006, 09:53 PM
I would think Jameco or Digikey would have a suitable replacement for the ET-3400 trainer display. Its just a common 7 segment LED isn't it?

Yes, but it's quite a bit larger than (and older) than the common types. I really should get a jameco catalogue. I have a tendency to think that most of these old parts are in obscure shops known only to a knowledgeable few.

Thanks , I'll check them out.

Lawrence

paul
December 1st, 2006, 11:18 PM
It was made by Kuknke of Germany. When I worked in the UK in the early 80's I was involved in troubleshooting a small robot that utilized this PLC.

The robot was used at Audi's facility at Neckarsulm to operate manual tranny cars undergoing the 50,000-mile EPA driving cycle on a chassis dyno. It was installed where the driver's seat would normally go and operated the clutch, accelerator, and gearshift. The robot's operation (and the dyno) was directed by a minicomputer in the office building, which also verified the vehicle's speed was within the allowed tolerance at all times.

The car had a fuel nozzle permanently inserted into the tank filler and was refueled automatically when the rear wheel weight reached a certain point. The test was only interupted for oil and tire changes and otherwise ran 24/7. Even dyno maintenance was done while running via an underground tunnel. It was a state-of-the-art facility at that time with six (or eight?) dynos.

So in 1983 I found myself sitting in the back seat of a 1984 US-spec Audi 4000 watching the robot do its thing. After two hours of perfect driving we were stopped, "waiting at a light" when the robot tried to take off without releasing the clutch. The system of course shut down, but I had no idea what had actually gone wrong so I took the robot back to the UK for evaluation.

It turned out that the PLC used magnetic reed switches on the air cylinders to verify end positions had been reached. As the pistons wore down over time, the magnet would sometimes be too far away from the cylinder wall and not trigger the reed switch reliably. I guess a modern design would have logged the error, but not in this case.

-Paul

http://paulaxford.com/misc/Audi_robot_driver_2a.jpg