It uses sixty four NAND gates, twelve NE555 timers, two dozen diodes and some analog parts.
It's about the most basic version of the game. They later published a sound effects board and an on-screen scoring board that uses a couple of dozen more chips.
Of course, in the mid 80's that was a pedagogical tool to lead us toward register machines and von Neumann architectures, but there were still some old-skool EE hackers around who built things like guidance systems for the Navy which were hybrid analogue/digital "computers" totally without CPUs or code. Today we have FPGAs and high level tools for building ASIC, but cheap microprocessors effectively swept aside an entire approach.
Maybe we missed something. Many small and well constrained problems in IoT type applications might better be served by hard-configured solutions. They would use less power, be immune to malicious network hacking, not need 'firmware' updates,
They have the added security feature of oily fingerprints containing unique DNA imprinted on them. It's customary in functioning democracies to not sequence fingerprints on a ballot paper, but theoretically it could be done.
If you use the voting machines to keep a running tally of votes cast so results are available immediately after polls close, you have already gotten a large benefit from them.
However, to ensure the (most warranted!) concern of the electorate that the votes are not being tampered with, the machine should also print a receipt to the voter after his/her vote is cast, in a human-readable format, which is then deposited in an urn much like today.
So - you get instant results, and if the result is challenged, you can audit the actual ballots rather than just doing a code audit and hoping the numbers haven't been tampered with in some undetectable way.
Boards full of TTL are a fascinating engineering exercise, but there aren't many applications where they're a better solution.
It's also tempting to cheat and solve some of the sub-problems with monostables and analog timers. As soon as you do that you're introducing potential issues caused by temperature drift, component tolerances, and component ageing.
A fully clocked solution is always more reliable, but often that means a higher component count and cost.
FPGAs have real applications, but they're still harder to develop than code.
When I was a student one of the tutors said "We'll all be doing this in software soon" - and he was right.
We as EE engineers learned to test our creations. We are however slowly pushed to a SW process world where there are modules and integration tests and at the end, testing is just pingponged between EE and System and nobody do the testing.
That's the only one I don't quite understand. All your other points are definitely great objections.
Are you saying that a clocked system consistently uses less power than a stateful but quiescently 'static' circuit? I can imagine there's a reason, but it goes counter to my experience that the faster you clock a microprocessor the more power it consumes; therefore at zero clock rate a purely data-driven system should consume the least power. What am I missing?
1. Discrete logic chips tend to be built in substantially larger process nodes (microns vs nanometers) that are less efficient. This means higher leakage current and more static power.
2. Discrete logic has to drive traces on a PCB, which have substantially higher capacitance (C) and therefore use more power getting across a board.
3. Discrete logic operates at higher voltages. Contrast 5V TTL vs. 1V core voltage inside a processor. Power is proportional to the voltage squared.
4. A microprocessor running even at low speed can replace a massive number of discrete logic chips, so for simple solutions F is low. If you're doing something very simple and interrupt-driven, F can be in the tens-hundreds of kHz.
Consequently, there's a whole lot more of both static and dynamic power with discrete logic than with a uC.
There are ways to make a microcontroller use less power, by making it hard-sleep when nothing is happening, but you don't get that without extra work.
That will introduce practical problems, though. If you want your design on the best tech possible, that costs serious money that you may not be able to afford, especially if you don’t want an enormous number of circuits. Your 10,000 transistor design may fit a million or more times on a top-of-the-line die.
You are still going to use a very old and obsolete process, compared to the microcontroller.
As a rule of thumb, every generation of lithography that has made transistors smaller and more efficient, has also roughly doubled the NRE costs. As you move down the feature size slope, you get all kinds of useful properties, but the tradeoff is that you have to manufacture more of any given design for it to be able to make any economic sense. To the point where you can get an amazing chip that has an arm core, storage and memory in a single package that costs pennies (well, not right now it doesn't, but it did in the past and will again) and uses almost no power, so long as you can use the exact same device that is also shipped in the millions for other things too.
- They have to use significantly higher voltages and consider higher currents, than really need to work.
For example, typical logic output of universal TTL logic, considers connect to it more than 10 inputs, each of them drain some current.
And also, universal logic i/o MUST tolerate some differences in power supply voltages and interference on real circuits.
But if you don't need to communicate to outside of chip, you could make things much more optimized, make customized outputs, considering for only as much drain as really exists in scheme; make internal highly stabilized power supply and very powerful power distribution network.
For first CPUs this was not talked, they just considered as very expensive logic chip, but ~ from 80186, hard to say exactly date, appears division: some outputs become high power, others stay "normal", low power.
And in commodity cpus, in Pentium appear two voltages - one for core and other for interface circuits.
Well, you might still need flaws to be fixed in the device, but now flaws in the device can never be corrected.
- Perform such an update
- Sign off that they performed the update _correctly_
If you need an air-gapped system, it's still much easier to set it up so it can update from a USB flash drive and log "I did the update correctly" back to the drive.
Of course the cost of doing the above is one reason we don't do everything in hardware. If you have the money you could implement everything people do with computers in hardware, no software - I don't even want to think about the cost.
One including a datatype mismatch, that was also a bug in the specification.
My god how I wish that were true.
If a pregnancy test can run doom. It can run state level surveillance.
Always good to remain mindful that what we assume is 'progress' in one direction may not be progress overall, and that allowing backtracking to older interpretations is actually a more mature scientific stance.
This! It's very empowering and one of the things that drew me to tech/computers. Being able to understand things helped me realize the potential of what is possible with computers/computing technology.
I majored in EE in undergrad and didn't really appreciate my EE education until I got older (I was more interested in software).
The coolest part was our professors never told us we had to use logic (and then cycle through the pieces faster than the eye could see) to get the 5x7 led display to work for non-symmetric letters. They let us figure that out on our own. I was sitting in history class not paying attention when it came to me. I drew out the circuit I wanted and couldn't wait to get to electronics class to try it out.
Later on digital circuits, we got to design basic CPUs, with optional breadboard implementation, but no one bothered to go that far for optional stuff.