I wonder why the input from the mux has to be “deglitched.” Is it due to noise or that the input lines are not synchronized with the clock?
Also because it’s going to a CMOS input you really need to watch the RC time constant. If it’s too large, the input mosfets will both conduct for a relatively long period of time (called “shoot through”) and may cause the IC to malfunction, potentially permanently.
Also he has no discharge diode connected to the cap in that circuit, which could cause the cap to discharge damaging amounts of current through the IC on power down if the cap is relatively large.
Also you have to make sure the resistor is large enough to avoid damaging inrush currents from the input mux to the cap.
That RC filter really bothers me. Maybe it really is necessary to “deglitch” but if so he should really include the values he used because naively selecting rc values there will cause potentially serious errors. A Schmitt trigger buffer would be far less error prone.
It's hard to analyse devices like this. It's clearly not Turing complete but it isn't a Turing machine. It can clearly compute any output for any given input (like a programmable logic array) but it can do a bit more given it can have several bits of internal state.
Turing machines are a minimal model that don't map easily to normal computers.
This, on the other hand, is a very normal computer. It's just that it has an extremely small amount of memory. If you put a RAM chip between those output wires and input wires then it could be Turing complete.
Turing complete, in common usage, refers to the ability of finite Turing machines, not infinite ones, since any machine we physically built are built according to physical laws.
If the RAM fills up then swap it with a bigger chip behind the machine's back.
And for any calculation you expect to complete on a physical device, the computational difference between finite and infinite memory is basically nothing.
The combination of an instruction that does two actions at the same time like branch and set an output kind of reminds me of the raspberry pi Pico subsystem.
Old EPROMS are not very fast. 200 to 250ns access times were common back then, which would limit your clock rate to about 4Mhz or so. Of course you could use a modern NOR flash compatible pinout, which are about 70ns (~14MHz).
This is why a lot of times you speed up embedded systems by loading the eeprom or flash data to ram, to avoid all the waiting by amortizing it at start up. A lot of times yiu can queue up the next but while waiting on the initial request, meaning you pay for a single wait and change on average in the end.
