Outstanding piece. Towards the end, Ken Shirrif has a good discussion around this:
"[...] Still others would allow these functions to be packaged in a few chips, which would collectively make up the microprocessor.[...]"
Bit-sliced was certainly "interesting". It was the interim step from discrete logic processors to everything else. In addition to the Am2900 (and follow-on Am29300), there was the Intel 3000 line, the 74x181/381, MMI 5700, Fairchild 9000, Signetics 8x line, etc., etc. Many late 70s/80s/early 90s computers were bit-slice processors.
> Transistors, the electronic amplifiers and switches found at the heart of everything from pocket radios to warehouse-size supercomputers, were invented in 1947.
The cat-whisker detector is commonly described as the first solid-state device, discovered in 1874, patented in the early 1900s, and used in various experimental radios through the development of radio technology at that time.
Its not a "modern transistor design", but its solid state, its through a semiconductor... and its one step away from reliably amplifying. Its kinda funny that the physics to understand this thing were developed after its invention...
The patent exists but NOTHING was done with it and nothing was brought to market or practical use.
Ideas are cheap and worthless - it's the execution that matters. That execution in the context of a patent is a viable product or use.
MOSFETs were NOT viable until the 1960s. RCA made the first practical metal-gate CMOS that is known as the "4000 series" of logic parts. And even then, that technology didn't take off until all the other problems of mobile ions, threshold tuning, etc. were finally solved to give us CMOS as we know it today.
There are always wankers who point to this patent, but it really doesn't matter because it took another 50 years to achieve anything that mattered.
Among civilized people, calling someone (the author of the referenced article in this case) a wanker is considered an insult; and it is definitely not compliant with HN rules.
It's still an invention by definition (patent law). Thanks for the article; notably the article makes no doubt that the invention by Lilienfeld would have worked; apparently he just didn't build it himself.
Apparently this is an emotional topic; personally I have no stakes in it (besides that I'm a trained electrical engineer and had lectures in patent law), I'm just curious; Colby sent me this link which describes an experiment where they built Lilienfelds device in the nineties: http://public.gettysburg.edu/~bcrawfor/BECrawford-MS-UVM.pdf
The claim in the article was "invented in 1947"; a patent is by definition granted for an invention, regardless whether a working device was built or not.
No. It must be novel, non-obvious and "useful", which obviously was considered to be fulfilled by the patent office. The patent describes how the invention can be used instead of tubes.
Those sources appear to exclude Lilienfeld. He didn't create a good or tool. He didn't create a material. He didn't create a manufacturing process or a control procedure or a method of measurement.
Lilienfeld was a brilliant man but he didn't invent transistors any more than Albert Einstein invented gravitational wave detectors.
The patent doesn't mention the term "transistor"; but obviously the patent office came to the conclusion that it is a patentable invention, and the cited by list confirms that it is considered a relevant invention by Bell Labs and other notable institutions. Prior art by Lilienfeld did even stop some applications of Bell Labs from going forward. The transistor invented in 1947 was a point-contact transistor, which is not the concept applied in micro processors as the article confirms.
4004 had 2.5k transistors. 8008 had 3.5k. z80 had <10k transistors.
A modern 4 core ARM chip has 16b transistors, in 122mm^2 die area. So, if we scale current die area for 16b transistors to a Z80, on 10k, we get 1.6m scale factor. 122mm^2 scaled down 1.6m times. 16 x 10^9 / 1 x 10^4 == 1.6 x 10^6 == 1.6m
This size is of course slightly preposterous, but if we accept there is some linearity in die scaling at current VLSI scale, it becomes clear a Z80 will fit inside a hypodermic needle. Its within the size of current technology, to be injectable. Power would have to be an external RF source, or maybe we can exploit brownian motion, or have a motile tail and do some kind of strained-crystal voltage, run asynch clock, we can also do a tail for WiFi and do power and signal through RF.
Injectable VLSI is a research space. It has great potential for in-vivo monitoring. Subcutaneous, or intravienous is a detail at this point. (note, this is quite different to the boring RFID sealed in some bubble which people get subcutaneous, thats been a thing since pet-chipping and before. I'm talking active electronics here)
We maybe can't all suffer the bill gates injected 5G nightmare, but we could play a mario gameboy, inside our bloodstream. (The original gameboy was a custom CPU modelled on a Z80)
I'm fully vaxxed for C19. I wonder if I can hear the "tetris" theme inside...
The issue with this is while the transistors for the CPU scale like that, the structures to do wireless transmission don't.
If you go high enough in frequency that you can make it on the same scale as the CPU, you're in frequency ranges that are trivially absorbed by water. Which your device is surrounded by.
Sure, you can just keep upping the power of the applied field to get enough energy to the chip to do something useful, but it has this messy side effect of causing heating. If you're OK with boiling the bodily fluids of person the chip is in, it'll work great!
> note, this is quite different to the boring RFID sealed in some bubble which people get subcutaneous, thats been a thing since pet-chipping and before. I'm talking active electronics here
RFID capsules are active. That's how they work. They're powered by inductive coupling into a coil in the device. Interestingly, their size is largely set by the power coupling requirements, so at least to some extent they are basically what you're trying to describe, only actually implemented within the constraints of reality.
To go over it a bit more: the higher the frequency of radiation the smaller you can make the antenna. However in the frequencies we have the technology to send signals in, and don't intrinsically give you cancer, everything becomes more opaque when you increase frequency. As OP says, it's like trying to send a light flash from behind a concrete wall, when you can see it on the other side you're using enough energy to vaporise the concrete anyway.
This is basically the only reason why we aren't living in a surveillance dystopia to make the Matrix look tame. Thank you physics for limiting the amount of possible surveillance from smart dust.
That said, you could still use chemical or physical means of communicating with microchips inside you, the issue is that you're very limited in how much information you can send without having them come in contact with some type of macroscopic io device.
Unfortunately not, this was a famous problem taught by Feynman in his physics lectures. Essentially the Brownian motion of the ratchet and pawl mechanism (used in your watch) will eventually prevent the mechanism from harvesting energy [0].
The motion that winds a self-winding mechanical clock is the swinging motion of an arm. Swinging motion is directional, back and forth, i.e. predictable. Indeed, the very self-winding mechanism is possible only because of this predictable movement.
Brownian motion is literally random diffusion. By comparison, it'd be like vibrating the watch in every direction. It wouldn't wind from such motion. No known mechanism exists that would.
The problem is that once the particles in your watch bounce around at the same rate (it is in thermal equilibrium with the environment) then it's statistically impossible to induce a net flow of energy from the environment into the device.
Obligatory raining on the parade: small enough smart sand might be a cancer risk, the way asbestos is (suspected to be)[0] - apparently our bodies really don't like having small, stiff objects poking at it from inside, causing mechanical damage.
That said, I'm all for "smart sand" and programmable matter. IIRC, the tricky bits are in making the individual smart particles to stick to each other, and then making them behave in a coordinated fashion.
It's an interesting challenge to think about: you have a thousand, or a million, small little robots - how to get them to do something useful as a group? If the robots can barely sense their environment, can barely move on their own, can't communicate with each other except maybe their nearest neighbors - how to make them work together in a controlled fashion? Say, I have this bag of "smart sand", I pour it on a table and want it to form into a cube when I press "Enter" on my laptop - how do I translate a bulk concept like "cube shape" into instructions for a random pile of tiny robots?
Does anyone know of good papers dealing with this problem?
> It's an interesting challenge to think about: you have a thousand, or a million, small little robots - how to get them to do something useful as a group?
This was a big focus of a lot of the ALife research in the late 90s and early aughts. Cellular automata, swarming systems, etc. You can generally start with anything coming out of University of New Mexico and bounce around the citation graph of an interesting-sounding paper. You might also want to check out Dave Ackley's T2 Tile project and some of the youtube videos he has put out over the past few years. One thing he is very clear about is addressing robustness in the face of component failure (e.g. his 'Moveable Feast Machine' and 'Demon Horde' stuff is rather fun to watch as it responds to random and widespread failures.) Most of the work in this area is clearly bio-inspired, but why re-invent the wheel when you can steal from the best available examples...
Yeah I was thinking about it, the particles would have to be able to transfer power to each other by contact. If it's a problem of corrosion maybe through induction. And some particles are specialized eg. an IMU or a battery, etc... spatial would depend on external direction probably IMU combo. But the manufacturing would be insane... scale and then hopefully it's cheap enough it could be like dirt. In the end what is it for, is it strong structurally. Clustering compute of each particle would be interesting too.
Anyway at least you can model/simulate it, that would be a cool thing to design/program.
I guess in the same way you orchestrate any cluster of bots: you give each an ID, design your structure on your server and then and then pass those instructions to the bots.
They wouldn't be aware of each other in any "smart" way but you'd want to keep the logic as low as possible on the nodes so you have less compute power to miniaturise.
I feel that's not robust enough - what if some of your bots are missing? When we're talking millions of microscopic robots, I think we need to assume that many will break down, get misplaced, or be in a position disadvantageous for it to fulfill a designated role. A robust system cannot rely on all the robots in a predetermined ID range/set to be there - it needs to work with what's actually available.
Ideally, I imagine being able to point at a random pile of robots and make that pile do something, without knowing any of the IDs or health of individual cells up front.
So I wonder, is there a way to design the system in such a way that individual robots don't need to be micromanaged, but instead they self-assign to the appropriate role/place, without having full knowledge of the shared goal?
Imagine those experiments in making shapes from sand with standing audio waves, e.g. [0]. The grains of sand have no identity and no awareness. The person setting up the experiment doesn't care about what any individual grain of sand does. They just set up a pattern, encode it in a standing wave, and the sand moves to conform to it. I'm wondering if this kind of approach is possible, except with the robots moving on their own instead of being moved by air. And, as a next step, with a pattern being persisted in the pile of robots, instead of being supplied externally.
> I feel that's not robust enough - what if some of your bots are missing? When we're talking millions of microscopic robots, I think we need to assume that many will break down, get misplaced, or be in a position disadvantageous for it to fulfill a designated role. A robust system cannot rely on all the robots in a predetermined ID range/set to be there - it needs to work with what's actually available.
Nothing about what I posted assumes that. I'm just saying it's the server that would orchestrate them rather than them orchestrating each other. The server would obviously poll them for positional data (relative to neighbour), health status, etc.
> The person setting up the experiment doesn't care about what any individual grain of sand does. They just set up a pattern, encode it in a standing wave, and the sand moves to conform to it.
I didn't suggest that someone manually plots each grain either. Clearly you'd just set up a design in a CAD and then let the server define the algorithm and orchestration required.
Much like how when you manage nodes currently, you don't manually assign which node to scale up or down. You define rules and let the system manage the nodes itself.
Given the problems of miniaturisation and decentralised computing, this feels like a problem easier solved in a centralised system that then hands out instructions (and your requirements clearly stated there was a control system that you used to instruct the grains of sand when you said "press enter on my laptop").
Yes, something like that - and I'm wondering if there's a way to imprint a pattern on such flock of birds, so that they then flock into appropriate shape from whatever starting configuration they were in, and maintain the shape over time, even in the face of strong winds or some of the flock members dying.
Here's one idea I'm thinking about: flocking-like equations in "boids" simulations are local, a pure function of (the observed state of) the neighbors. In a typical implementation, they just compute velocity/acceleration vectors out of position/velocity/acceleration/class of the neighbors[0]. And the result are pretty, fluid, and uniform in steady-state flocks. But what if we added more observable state and equations to this?
Imagine each boid having a "color", a value that is a function of not just the color of the neighbors, but also of their position/velocity/acceleration/class. And then, the equations computing velocity/acceleration take this color into account too, e.g. by offsetting the result by some function of the neighbors' colors. Could we then design the f([colors]) -> v/a offset and f([everything]) -> color functions so that they end up forcing the flock into an arbitrary uniform shape? I believe we could, but I'm not sure how to define these functions for any particular shape.
(Or, in short: I'm looking for a method to turn an arbitrary picture into an error term for boids rules that makes the flock assume the shape of the picture, instead of an uniform blob.)
I'm sure there must be some pre-existing theoretical work behind finding such functions - this problem feels like a cousin of the "find a formula that draws a target picture on X/Y plot". I just don't know the right keywords to look this up.
But this is kind of the idea on the back of my head - encoding desired group behavior in a function that is common to every member of the group and is entirely local (only a function of the immediate observed environment), but that forces the system to settle in a desired configuration.
--
[0] - "class" being e.g. member of same species, a predator, or a prey.
The real problem with such research is it might work on a quadcopter with room for a chipset capable of relatively powerful real time compution (be that an off the shelf CPU or something more bespoke), but that doesn't scale down to the grain of sand level. At that point you'll want to offload as much computation overhead as you can. Which, again, brings me back to my original post.
Maybe one day in the distant future (if we haven't annihilated each other first) we'll have the technology to built smart grains of sand. But it's seems pointless theorising about something that might just as easily be deprecated by some other fantasy device by our current technological capabilities.
Anyhow, if you're after a paper on the actual calculations you'd run to convert a database of nearest neighbour coordinates into a matrix that can be used to instruct those robots, then I don't have anything directly to hand on that. When I've looked this stuff up in the past I've found most of the time it was proprietary. Maybe there is a paper I've missed. However I have seen papers doing similar work (in the sense that there is transferable logic) in a two dimensional fields, eg matrix reordering.
Thanks! I haven't thought about drone performances. In retrospect, it's a good starting point. I've seen plenty of videos of drone swarms being synced up to produce shapes and animations.
> Maybe one day in the distant future (if we haven't annihilated each other first) we'll have the technology to built smart grains of sand. But it's seems pointless theorising about something that might just as easily be deprecated by some other fantasy device by our current technological capabilities.
Maybe. But I feel this isn't pointless - I find myself constantly returning to this topic whenever I follow seemingly unrelated avenues of idle curiosity (e.g. "how to build self-maintaining systems", "how to do in-orbit construction" , "how to get rid of household cleaning chores", "how to build a food replicator", "ooh isn't biotech kind of fun", etc.). I think we'll eventually start building "smart matter" at some scale. Might be nanometer. Might be millimeter. Might be meter. Each of those scales has its own physics regime, but I think the concepts behind self-organization will be common. And we're already working on those ideas when studying biology at molecular and cellular level.
> When I've looked this stuff up in the past I've found most of the time it was proprietary.
Do you remember any names? Might be that some of the research is released. Or maybe my employer has access.
> However I have seen papers doing similar work (in the sense that there is transferable logic) in a two dimensional fields, eg matrix reordering.
I don't think that would work. Bloxels would need to know their location in the grid. And any kind of closed object would cause problems because bloxels would only adhere to the surface, not build up bulk inside.
Maybe better would be a kind of 3D printing model, where the shape is 2D and changes over time, which leads to accretion of a 3D shape.
Even so - without feedback and monitoring you'll get errors and holes.
And you'll still have the problem that unless you're using some novel form of programmable electrostatic bonding, adhesion between bloxels will be weak.
So you won't be able to do much with your finished shape except look at it. Probably not even pick it up, in fact.
> Bloxels would need to know their location in the grid.
That's the thing I'm trying to work around. If bloxels are like boids in the flocking simulations, they don't care about their location - they move and change state based on the movement and state of their neighbors. In the flocking simulations, boids automatically form stable shapes and recover from disruptions, and none of them have assigned positions or even any kind of unique identifier. It's the repulsion and attraction functions - identical in every boid - that determine the steady state shape of the flock.
That said, I think there's a way for bloxels to tell where they are in their "flock". Imagine each bloxel continuously publishing a "depth" value that's computed as e.g. length of the vector \Sigma_{n}^{Neighbors}: Depth(n) x DirectionTo(n). The values would initially fluctuate, but I feel it's possible to set this up so that over short time the system will settle, with every boid's "depth" value being a correct indication of how far it is from the centre of the group. So e.g. upon activation, a pile of bloxels could wait for "depth" values to stabilize, and then each bloxel would remember its value as its designated position, and execute some different algorithm with that bit of state fixed.
Note to self: there's a bunch of free "agent-based simulation" programs I saw on the Internet the other day; such "depth" calculation should be a simple thing to simulate and verify.
Related keyword: phase-locked loops. See also: fireflies that synchronize their flashing patterns over time.
> And any kind of closed object would cause problems because bloxels would only adhere to the surface, not build up bulk inside.
Why can't they build up bulk, using each other for support?
> Maybe better would be a kind of 3D printing model, where the shape is 2D and changes over time, which leads to accretion of a 3D shape.
I'm not sure what you mean. That sounds like regular 3D printing using "dumb" matter?
> Even so - without feedback and monitoring you'll get errors and holes.
Bloxels would be active and reacting to each other - this is a feedback-full system.
> unless you're using some novel form of programmable electrostatic bonding, adhesion between bloxels will be weak
I have no good ideas here. I don't know of any programmable bonding system that isn't too energy intensive to use with current technology. AFAIK electromagnets are power hogs. Mechanical locking systems are also energy intensive, and also tricky to use (maneuvering the mating endpoints to meet, compensating torque, etc.)
Well, crystals form into regular geometrical patterns without any sort of over-arching goal. So that could be one way to do it, have some simple check each piece could perform (like observing neighbors), maybe some kind of random 'seed' selection to determine starting points and later some annealing so everything joins correctly. That is where I'd probably start.
Yes. Imagine that the "boids" change colour as well as alter their X, Y, Z position. That supplies additional "guiding" information to provide purpose and also alter behaviour, in much the same way that hormones act on a growing foetus.
And this reminds me of those audience experiments with people holding up blue and red cards and using this "vote" to successfully steer a vehicle.
Yup. Also nothing says the boids have to execute a single behavior all the time.
In a parallel comment, I described an idea where boids first start doing nothing except publishing a "depth" value that's a function of their neighbors "depth" value, waiting for the system to settle (as detected by neighboring values not changing by more than some fixed epsilon over some fixed Δt). They could then record their individual values and continue to a second algorithm (e.g. traditional "boids"), that uses this (now fixed) "depth" value as a parameter.
This is, in general, a pattern for individual unit to discover their role in the group, without ever knowing the whole group. I just realized this sounds like things the field of "distributed consensus" deals with - I'll add that to my research list.
I remember the voting games and "Twitch plays X" events. It's kind of a different situation (external controllers voting on control input to a single actor), but there might be some parallels.
I remember reading of a primitive unicellular organism that can link up with its fellows and become mobile, searching for water sources if I recall correctly.
Smart sand that learns like neural nets. Recipe goes like this: Mix semiconducting grains and metal and solder bits. Apply electric pattern at one end of the bucket and shake the bucket until some useful pattern appears at the other end. Then you apply much higher current between those patterns. Solder bits melt and form more permanent neural routes. Repeat until the device works as expected.
I wonder how much performance we got out of the 1.6m scaling factor. I'd guess somewhere between 10k and 100k faster, but nowhere near a million times?
I would like to see that number as well, I actually expect it to be a lot more than a million.
Take 1000 times the clock rate, 4 cores, multiple instructions per clock instead of multiple clocks per instruction. Operations on 64 bits i.o 8 and the Z80 doesn't even have multiply or divide operators and would need to loop and add to do a multiplication/division. And then think about things like ARM SIMD instructions.
True, but can multiple cores, pipelining, etc... really make up for another factor of 1000x? And most of this complexity exists because memory latency couldn't keep up.
