
IBM 5110 PALM (Put All Logic in Microcode) CPU from 1978 - peter_d_sherman
http://www.rugged-portable.com/history-portable-computers-rugged-bias/ibm-portable-pc-5110/
======
peter_d_sherman
After doing some Googling, I discovered that there was a company called
Microdata Corporation:
([https://en.wikipedia.org/wiki/Microdata_Corporation](https://en.wikipedia.org/wiki/Microdata_Corporation))

They apparently existed from 1969 to around late 1970ish or perhaps early
1980ish, during which time they made computers which were open to Microcode
programming by the end user -- they even gave the end user a manual on how to
do it:

[http://bitsavers.trailing-
edge.com/pdf/microdata/3200/761020...](http://bitsavers.trailing-
edge.com/pdf/microdata/3200/761020A_3200_Microprogramming_Ref_Feb76.pdf)

This manual should be entitled "How to build a late 70's style Microcode
programmable computer". It really gets into the guts.

~~~
bouvin
The Microdata building in LA is a part of the seminal movie Koyaanisqatsi
[http://www.spiritofbaraka.com/koyanisa579](http://www.spiritofbaraka.com/koyanisa579)

------
vt240
What other systems did they build similar to the PALM? I remember as a young
kid buying a quite large (~3ftx4ftx3ft) IBM minicomputer that was just filled
with those modules at a local thrift shop during the late 80s.

No keyboard or screen, although I seem to remember it had an 8in floppy drive.
Its been so long I can hardly remember it, but I distinctly remember those
cards with the square metal cans, many of them socketed. It had a really nice
set of schematics and service manual inside the case also.

edit: After some google digging, it must have been something like a 3274
terminal controller.

~~~
peter_d_sherman
This is tremendously interesting, if it would have worked (and if I could time
travel), then I would have wanted it!

10 or 15 years ago I was reading the classifieds, and a local company was
dumping an entire mainframe system with terminals. I don't remember which one
it was, but I think I looked up the model numbers and I found it was something
like a $150,000 mainframe system ten years earlier. The price? Make an offer!
I probably could have had it for a couple of hundred bucks and U-Haul rental
charges!

But yeah, I would have wanted one of those if it worked!

It would just be cool to have...

~~~
vt240
Despite my parents being computer illiterate, I'm glad they were pretty
understanding. I never had any IBM experience but I had spent plenty of time
on MicroVAX, HP 9000 and later with Sun. I did a number of local pickups (ahh
the memories of trying to shuffle a HP9000/835 down Columbia tower and into a
dodge caravan) of hardware and knew a person who worked with Sun in Seattle
who would sell me old demo stock for a $1. I spent years trying to get rid of
it all, no one would take it even for free, and unfortunately had to recycle
most of it. Although the Paul Allen museum bought some of DEC Alpha stuff. It
just cost too much electricity to even play with.

------
i336_
The Xerox Alto had a custom CPU that used microcode extensively - the CPU
actually did most system management tasks like re-blitting the entire screen
for every new frame and managing disk I/O, and only when it wasn't handling
these scheduled tasks did it execute an "emulation" task that actually
executed arbitrary code.

More info: [http://www.righto.com/2016/09/xerox-alto-restoration-
day-5-s...](http://www.righto.com/2016/09/xerox-alto-restoration-day-5-smoke-
and.html)

Start of story (the part 1 link is not easy to find):
[http://www.righto.com/2016/06/restoring-y-combinators-
xerox-...](http://www.righto.com/2016/06/restoring-y-combinators-xerox-alto-
day.html)

------
pavlov
Jimmy Maher's "The Digital Antiquarian" has a nice writeup on how these pre-PC
small computers at IBM led to _the_ PC:

[http://www.filfre.net/2012/05/the-ibm-pc-
part-1/](http://www.filfre.net/2012/05/the-ibm-pc-part-1/)

------
derefr
Is this using "microcode" in the same sense we'd use it today to refer to e.g.
"Intel CPU microcode"?

~~~
lvh
In the sense that you have microcode presenting a high-level instruction set
that internally is executed as a low-level instruction set, yes. (There are
clearly implementation differences, so if you'd pedantically want to find a
distinction there are plenty.)

~~~
rhizome
It would be interesting to see a history of CPUs in terms of their layers of
abstraction. When was something like "MOV AX, BX" invented, and how far is
that from physical ones and zeros (ons and offs) in the silicon? Obviously I'm
not a CS graduate.

~~~
peter_d_sherman
A CPU's registers is where all of the "bit transformation" (adding,
subtracting, multiplying, dividing, branching) work that Computers do, is
done. Registers are like very small scratchpads, typically 32 or 64 bits (or 4
bytes/8 bytes) wide. Computers with as little as one main register for
calculation, and another register for which instruction in memory is executing
(instruction pointer) are possible. CPU's as low as 4 bits have existed (Intel
4004), although there's no reason electronically a CPU could use less bits
than that (well, in order to execute a program, you need an address in memory,
and for that you need more bits for larger addresses, i.e., more memory).
Every electronic calculator from the 1970's is a computer IF it had memory,
conditional instructions (if results of last calculation were greater than
zero, go to (change instruction pointer) to this new address, otherwise,
continue with next instruction. MOV AX, BX is an abstraction for programmer
consumption only, a CPU's basic instructions are something like: 1) Move value
into accumulator (AX, R1 or EAX or RAX or R1 or Reg1) from somewhere in
memory. 2) Perform some sort of calulation on it (Add, Subtract, Multiply,
Divide, Bit Shift, And, Or, etc.) 3) Store it back to memory 4) Execute a
conditional branch instruction which says, as a result of the last
mathematical computation, either a) jump to a new address (bypass a section of
code), or b) continue with the next instruction.

The Zuse Z3 is probably the simplest Turing-Complete computer that was ever
invented (in 1941 no less!); I'd start there:

[https://en.wikipedia.org/wiki/Z3_(computer)](https://en.wikipedia.org/wiki/Z3_\(computer\))

~~~
dom0
The Z3 is a floating point machine... I'd wager that it is more complex than
the 4004. While the 4004 has a couple more transistors than the Z3 had relays
(about 600 in the "CPU"), the telephone relays used by the Z3 had many
circuits and thus can perform more complex stuff than a single transistor in a
logic circuit.

------
johnhattan
Wasn't that similar to those Transmeta processors that had most of their
instruction set written in software? Seemed like a cool idea, but (as I
recall) the Transmeta processors couldn't keep up speed-wise with the existing
x86 CPU's.

~~~
PeCaN
Eh, the Transmeta Crusoe (first gen) processors had pretty decent performance
compared to Pentium M at much lower TDP. The Transmeta Efficeon (second gen)
had performance comparable to bigger processors but had some thermal issues
that hindered it a fair bit. Efficeon kinda lost Transmeta's original goal of
decent performance at lower power consumption, and they went downhill
afterwards.

They weren't great but for a small, ambitious company without much chance to
iterate they definitely weren't bad.

The technology got incorporated into NVIDIA's Project Denver ARM chips, which
were very fast… sometimes. Actually, Denver 2 is shipping in the new Jetson
devkit, but I haven't seen much about that or been able to get my hands on
one.

That's the general problem with VLIW chips, is that they're amazing on some
workloads and pretty bad on others. Itanium, for all its faults, was by far
the best general-purpose VLIW CPU.

~~~
FullyFunctional
Thanks for the rare fair comment. People are quick to forget the difference
between concept and implementation. The Transmeta concept was clearly viable,
but the implementation needed more iterations to before we can fully judge the
concept.

Your comment about VLIW is true, but in this case that was a 2nd order effect.
Far far worse was The effect of the JIT (CMS): a small kernel running over a
long time (e.g., DVD playback) would work absolutely excellently, even on the
Crusoe, whereas a large codebase with relatively little reuse (say, Word)
would give very uneven performance. This problem was never solved [at
Transmeta].

The irony is that today, x86 compability is irrelevant in most places.

~~~
PeCaN
Yeah, code-morphing/hardware JIT is extra weird (and probably why Nvidia's
Project Denver kinda tanked—turns out, that doesn't work too great for
smartphone apps).

One thing I've thought about is having a code-morphing CPU as a sort of
_accelerator_ that a single process could be offloaded to (of course, this
would require an OS that can marshal processes). Think a database server, a
JVM, NodeJS—long-running processes that would benefit from JIT.

Might even be viable with upcoming cache-coherent interconnects like CCIX and
GenZ. A more ambitious implementation could offload groups of functions.

------
Koshkin
There is an absolutely beautiful introduction to microprogramming, by Mark
Smotherman:

[https://people.cs.clemson.edu/~mark/uprog.html](https://people.cs.clemson.edu/~mark/uprog.html)

~~~
dang
Discussed here:
[https://news.ycombinator.com/item?id=11412846](https://news.ycombinator.com/item?id=11412846)

------
jtlien1
A few years back I re-implemented a microcode assembler that I had used in a
silicon valley startup in the 1980s. I used some of the features of Haskell to
do it. See metalasm on Sourceforge. It can now do disassembly of horizontal
microcode as well.

------
dnm
My first paid programming job was on one of these (the 5120). Too
young/inexperienced to appreciate the hardware at the time.

~~~
kpgraham
My first programming job, also. One Christmas in the late 70s I had three
5120s set up in my living room. I was programming a complete accounts
receivable system with reporting and data entry (I was an accounting major,
long before small colleges had CS degrees). When all three were running I
could turn the heat off, and still have to open a window in the middle of
winter. I paid off my college loans with those computers. One thing not
mentioned in any of the discussions was how impossibly slow the systems were.
I ran the sieve program from Byte magazine a few years later and the results
came out in last place. I coded in BASIC and the IBM BASIC had a wonderful
ISAM built right into the language that made it very easy to handle indexed
files. If you have ISAM, you don't need a database. I took my last 5120 to the
the salvage yard 30 years ago. I still have some 8 inch floppies with the code
for my very first programs. Unfortunately, I have no way to read them.

------
userbinator
More info in here and its related links:

[https://en.wikipedia.org/wiki/IBM_PALM_processor](https://en.wikipedia.org/wiki/IBM_PALM_processor)

It appears to be based on the System/360 architecture.

~~~
masswerk
The 5100 / 5110 used two emulation layers, one for the S/360 architecture,
used to tun APL 360, and a S/3 emulation used to run BASIC. Amazingly, these
emulation characteristics weren't disclosed in the manuals.

Don't miss to google "John Titor" in this context ...

[Edit] Some links:

1) The sections on SCAMP (the prototype forerunner of the IBM 5100) and on
Small Machines in "The IBM family of APL systems" by A.D. Falkoff:
[https://web.archive.org/web/20071031134817/http://www.resear...](https://web.archive.org/web/20071031134817/http://www.research.ibm.com/journal/sj/304/ibmsj3004C.pdf)

2) On PALM and 32-bit microcode this talk at Wikipedia: 3)
[https://en.wikipedia.org/wiki/Talk%3AIBM_5100](https://en.wikipedia.org/wiki/Talk%3AIBM_5100)

3) On the John Titor story:
[https://groups.google.com/forum/#!topic/alt.folklore.compute...](https://groups.google.com/forum/#!topic/alt.folklore.computers/1KwE6rPwrd0)

~~~
knv
[http://www.strangerdimensions.com/2011/10/03/john-titor-
the-...](http://www.strangerdimensions.com/2011/10/03/john-titor-the-
ibm-5100/)

------
pkaye
Anyone wanting to learn more about Microcode in general, I found two old books
that has some information:

* Bit-Slice Design: Controllers and ALUs, Donnamaie White

* Bit-Slice Microprocessor Design, Mick and Brick

~~~
jhallenworld
Yeah, I poured over the Mick and Brick book. Once place where you can find bit
slice processors with microcode is early hard drive controllers. I remember
also a SASI floppy controller which used the 8x300.

------
Gracana
Modules for these machines come up on eBay for lowish prices. I have enough
different retro systems already, but it'd be neat to have just one of those
neat looking wire-wrapped cards.

------
digi_owl
The article calls the 5120 an ugly beast, but i find it kinda cute.

Also, 1.2MB pr floppy must have been massive back in '78.

BTW, when they say gate arrays, they mean that the whole thing was implemented
on FPGAs?

~~~
james_a_craig
Non-field-programmable - what were called ULAs (Uncommited Logic Array -
tellingly, wikipedia redirects to
[https://en.wikipedia.org/wiki/Gate_array](https://en.wikipedia.org/wiki/Gate_array)
).

These are chips with a large grid of gates, which they have in common with
FPGAs, PLDs, PALs and the like, but you program them by changing the final
metalisation layer during manufacture rather than by feeding a bit-stream into
them at initialisation.

They were cheaper and faster to make than truly custom chips. A stock of
etched and doped silicon wafers could be held by the manufacturer, so they
only needed one mask for the final metal layer to be produced for each
customer. This also meant that the turnaround from order of a new design to
delivery was faster, as only that single mask needed to be prepared.

------
hengheng
Is there any information about the microcode, or the hardware architecture?
I'd be interested in what caliber of today's guns one would require to emulate
this thing.

~~~
masswerk
See, e.g, this emulation in JS:
[http://members.aon.at/~nkehrer/ibm_5110/emu5110.html](http://members.aon.at/~nkehrer/ibm_5110/emu5110.html)

Some resources (including sources for a UNIX/X11):
[http://computermuseum.informatik.uni-
stuttgart.de/dev_en/ibm...](http://computermuseum.informatik.uni-
stuttgart.de/dev_en/ibm_5110/technik/en/5110.html)

