The Surprising Story of the First Microprocessors (2016)
spectrum.ieee.org
spectrum.ieee.org
Along those lines, there was also a set of "bit-sliced" chips from AMD, which looked very interesting: https://en.wikipedia.org/wiki/AMD_Am2900
P.S. The "Mick & Brick" book: https://www.amazon.com/Bit-slice-microprocessor-design-John-...
Is this true? Recently this article https://people.idsia.ch/~juergen/turing-oversold.html pointed to the following invention of the field-effect transistor from 1925: https://patents.google.com/patent/US1745175
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...
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.
Gutter language does not make the argument more convincing.
This I agree with. Similarly, elitist virtue-signaling like "gutter language" and "among civilized people" aren't compliant with the rules either.
You're free to check.
But clearly, you've picked this hill to die on and this conversation is going nowhere. Have a good day.
I politely disagree.
Lilienfeld was a brilliant man but he didn't invent transistors any more than Albert Einstein invented gravitational wave detectors.
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...
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.
> Injectable VLSI is a research space.
Lol
https://en.wikipedia.org/wiki/Dipole_antenna
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.
It's not about power (as in energy over time), but about free energy or entropy.
Brownian motion is essentially just heat. In order to get any useful work out of heat, you need two different temperatures.
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.
Because even random macroscopic motion still has less entropy than a room temperature watch.
It will basically be like this die when students placed a small MIPS core. http://pages.hmc.edu/harris/cmosvlsi/4e/lect/lect2.pdf (See slide 29)
But the center will be a whole lot emptier.
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?
--
[0] - https://en.wikipedia.org/wiki/Health_impact_of_asbestos#Mech...
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...
Anyway at least you can model/simulate it, that would be a cool thing to design/program.
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.
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.
--
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").
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.
> 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.
Thanks, I'll look it up.
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.
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.)
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.
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.
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.