[HN Gopher] One-bit Computing at 60 Hertz
       ___________________________________________________________________
        
       One-bit Computing at 60 Hertz
        
       Author : Tomte
       Score  : 29 points
       Date   : 2021-03-24 18:36 UTC (4 hours ago)
        
 (HTM) web link (laughtonelectronics.com)
 (TXT) w3m dump (laughtonelectronics.com)
        
       | ctdonath wrote:
       | For speculative fun, what's the fastest rate such a design could
       | operate at? Are optical equivalent circuits reasonably possible
       | (or some such)?
        
         | CyberRabbi wrote:
         | 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).
        
           | simcop2387 wrote:
           | 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.
        
             | CyberRabbi wrote:
             | Very true, classic technique
        
       | buescher wrote:
       | Bravo. Reminiscent of the so-called Richards controller.
       | https://en.wikipedia.org/wiki/Richards_controller
        
       | CyberRabbi wrote:
       | 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.
        
       | barbegal wrote:
       | 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.
        
         | Dylan16807 wrote:
         | 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.
        
           | charcircuit wrote:
           | RAM chips have finite memory. It still won't be Turing
           | complete.
        
             | freeone3000 wrote:
             | 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.
        
         | dmitrygr wrote:
         | It is a DFA plan and simple
        
       | sm4rk0 wrote:
       | https://web.archive.org/web/20210324184305/https://laughtone...
        
       ___________________________________________________________________
       (page generated 2021-03-24 23:01 UTC)