[HN Gopher] Mark 1 Homebuilt Forth Computer (TTL only, no microp...
       ___________________________________________________________________
        
       Mark 1 Homebuilt Forth Computer (TTL only, no microprocessor)
        
       Author : peter_d_sherman
       Score  : 69 points
       Date   : 2021-01-16 17:35 UTC (5 hours ago)
        
 (HTM) web link (www.aholme.co.uk)
 (TXT) w3m dump (www.aholme.co.uk)
        
       | jfk13 wrote:
       | Very cool! Might be worth adding a note of the date of the page.
       | (Original copyright is 2003; updated 2006.)
        
       | ChuckMcM wrote:
       | In my opinion I think everyone who considers themselves a
       | "software engineer" should be required to build a computer out of
       | discrete logic. Of course these days doing that with an FPGA
       | would count too, assuming you don't use too many pre-canned IP
       | blocks[1]. My reasoning here is that understanding a computer at
       | this level really helps understand programming, and perhaps more
       | importantly the translation between what you want a program to do
       | and how the computer would actually do it.
       | 
       | That said, some nits on the author's description, what he calls
       | "micro code" are simply instructions. When you look at computer
       | architecture texts you will see that architectures that implement
       | instructions with logic are "non-microcoded" and architectures
       | that implement instructions of one width as a sequence of
       | instructions of a different width, are "microcoded". The trade-
       | off is that that former executes operation codes faster, the
       | latter can be more efficiently implemented. A great real world
       | example to study here are the PDP-8 (straight opcodes) and the
       | PDP-11 (microcoded).
       | 
       | The most amazing thing to me is that today you can buy something
       | like the ULX3S[2] and with a fully open source tool chain for the
       | FPGA build a processor (RISCV) that boots Linux multi-user.
       | 
       | [1] Using a pre-made ALU is fine, starting from a previous CPU,
       | less good :-).
       | 
       | [2] https://www.crowdsupply.com/radiona/ulx3s
        
         | the_only_law wrote:
         | Interestingly, this is _partially_ how I realized I wasn 't
         | actually that great at programming. I really have just never
         | been very good with digital logic and have failed to really
         | grasp it multiple times. Starting 6 or 7 years ago, attempting
         | to design a 6502 computer, and could not for the life of me,
         | figure out how to design the address decoding how I wanted, and
         | more recently, trying to get into FPGA's. I'm not sure what it
         | is, as at a very broken down, individual level everything makes
         | sense, but as soon as it jumps into composing them into
         | anything (i.e. an address decoder or even just simple digital
         | logic devices) I get lost and have to just sit around and have
         | to drill the details down on paper for me to remotely get it.
        
           | mwcampbell wrote:
           | > I wasn't actually that great at programming.
           | 
           | Do you (or did you) write software that people find useful?
           | That's what matters most.
        
         | dfox wrote:
         | I second the suggestion that every software engineer should at
         | least be able to imagine how they would go about building
         | computer from discrete logic.
         | 
         | When commercial computers were built from discrete logic in
         | this manner, there was distinction between "horizontal" and
         | "vertical" microcode. With horizontal being what most people
         | would today call microcode, ie. implementing most of the
         | control logic as one somewhat wide memory array with datapath
         | being mostly directly controlled by bits coming form such
         | memory. The vertical approach essentially involved designing
         | simplistic RISC-like CPU with fixed width instructions which
         | then ran interpreter for the actual instruction stream of the
         | machine (ie. what the author's CPU does). And obviously there
         | are various middle-ground approaches. The reason for this is
         | that control-stores for purely horizontal microcode are not
         | that dense and involve memory with weird and large word lengths
         | (which is somewhat inconvenient for implementation from
         | commercially available (P)ROM chips)
        
         | Philip-J-Fry wrote:
         | I really want to get closer to the metal, like programming an
         | FPGA or properly learning assembly (I know that's like 2
         | completely different skill sets). But I never really know where
         | to start.
         | 
         | Is there any like definitive book or website to learn any of
         | this stuff?
        
           | krallja wrote:
           | eater.net/6502
        
           | IHLayman wrote:
           | There is an interesting game I played in the past week called
           | MHRD that has you start with NAND gates and gets you all the
           | way to a CPU, challenging you to use as few NAND gates as you
           | can each step. That was pretty fun and reinforced some of the
           | ideas (although it elides a lot of the JK Flip Flop and RS
           | Latch stuff by abstracting it into their own data unit). I
           | agree with other commenters talking about eater.net and
           | NANDtoTetris as they are both great instructional resources
           | (Ben Eater's YouTube series is extraordinary).
           | 
           | As far as learning assembly, you may want to try Zachtronics
           | games TIS-100, Shenzhen.IO, and Exapunks as it does offer a
           | bit of the instinct for assembly coding. To learn 6502, I
           | could suggest finding yourself a good C-128 emulator. The
           | C-128 how I learned both basic and assembly (using their
           | MONITOR command) and the 6502 is pretty easy to understand
           | even if underpowered.
        
           | qayxc wrote:
           | IMHO a great way to get into this is programming old game
           | consoles.
           | 
           | The NES or Gameboy are great little machines that are easy to
           | understand and have tons of guides, tutorials, and tools
           | available.
           | 
           | With very little investment, you can even get run homebrew
           | software on actual hardware.
        
           | uncledave wrote:
           | https://www.nand2tetris.org
        
         | harperlee wrote:
         | You mean build or design?
         | 
         | If it's the former, I generally agree. It does not take long -
         | I worked through nandgame.com over a slow afternoon and it
         | helped me refresh things that I remembered fuzzily.
         | 
         | If it's the latter, I think it is too high an ask nowadays
         | where so many people work at a high abstraction level.
        
         | qayxc wrote:
         | > My reasoning here is that understanding a computer at this
         | level really helps understand programming, and perhaps more
         | importantly the translation between what you want a program to
         | do and how the computer would actually do it.
         | 
         | This logic would've worked in 1985 and maybe, just maybe until
         | 1993. Modern CPUs cannot be programmed at the level that TTL
         | provides. The uArch itself has long since become an abstraction
         | in and of itself.
         | 
         | Depending on the instruction set, there's often no way to
         | predict beforehand how certain data- and code paths will
         | behave. That's why modern compilers use optimisation techniques
         | such as profile guided optimisation.
         | 
         | If you think that certain uArchs are easier to understand in
         | that regard than others (e.g. x86 vs ARM), think again. There's
         | inaccessible embedded hardware [0], and SoCs hidden behind
         | proprietary RTOSes [1] that prevent direct access.
         | 
         | Detailed knowledge about building the hardware is therefore
         | only of very limited use in real-world applications; unless you
         | plan to become a firmware-, driver-, or compiler developer.
         | 
         | Even in the embedded world, data sheets can be deceiving and
         | ultimately knowing your (compiler-) toolchain and knowing how
         | to test the behaviour in practise is far more valuable.
         | 
         | General knowledge should be required, yes, but going so far as
         | to build an actual computer "from scratch" isn't as helpful as
         | it might seem.
         | 
         | [0] https://news.ycombinator.com/item?id=25801500 [1]
         | https://en.wikipedia.org/wiki/VideoCore
        
           | TheOtherHobbes wrote:
           | Agreed. The distance between CS abstractions has widened to
           | the point where the lower level abstractions are only
           | relevant to the people who build them.
           | 
           | There's a close and obvious relationship between C statements
           | and the PDP-11 instruction set. And at least one PDP-11
           | series processor was implemented with gate-level logic with
           | no microcoding. So anyone with time to spare could copy that.
           | It's not a trivial job, and it's probably more time than it's
           | worth. But it's not unimaginably hard either.
           | 
           | There's no obvious relationship at all between (say) Python
           | and the gate-level internals of any mainstream modern CPU.
           | There are at least four (five? six?) levels of abstractions
           | between them.
           | 
           | It's useful to build a generic gate-level processor to have
           | some notional idea of what a computer is. And of course it's
           | essential if you go into processor design. But uArch details
           | are a graduate-level topic and not something most developers
           | need to worry about.
        
           | mulmen wrote:
           | The advice is not how to build _the_ computer. It is to learn
           | how to build _a_ computer.
        
         | analog31 wrote:
         | A possible middle ground is to do something with a primitive
         | micrcontroller, where the architecture isn't terribly
         | complicated but at least it requires learning about things like
         | binary numbers and how numbers actually get passed from one
         | piece of hardware to another. While they are much maligned, the
         | 8 bit PIC chips are still available, and are extremely bare
         | bones. I think there's a good reason why they were the favorite
         | of hobbyists for a long time, before Arduino came along.
         | 
         | My college physics curriculum included building a 4 bit
         | minicomputer from TTL (in the early 80s). While we were given
         | the design, we still had to understand it in order to make it
         | work, because nobody's machine ever came up on the first try.
        
       | loudouncodes wrote:
       | Wow! A webring! Haven't seen one of those in a zillion years.
        
         | jacquesm wrote:
         | A HN member is trying to revive them.
        
       | Jkvngt wrote:
       | Forth is an amazing language, too bad we're so far from the
       | hardware most of the time these days.
        
         | the_only_law wrote:
         | I have a an old network protocol analyzer from an HP-Aglient
         | subsidiary that's supposedly scriptable in Forth. Actually out
         | of all my old protocol analyzers this one is probably the
         | coolest from a technical perspective. It has six 68k's in it,
         | and is heavy as hell. Unfortunately I never get to use it
         | unlike all my other one's because it only has ISDN BRI
         | interfaces, and most of my hacking involves PRI (T1/E1) or V
         | series interfaces.
        
           | reaperducer wrote:
           | I've seen a couple of old scientific calculators/pocket
           | computers on auction sites lately that can be programmed in
           | Forth. Very tempting to try.
           | 
           | I've also seen ones that can be programmed in C, BASIC, and
           | even Pascal. Again, magnets for my disposable income.
        
       | peter_d_sherman wrote:
       | > _" This computer has no microprocessor. The CPU is discrete TTL
       | logic."_
        
         | detaro wrote:
         | the "no CPU" in your title is kinda wrong that way: it does
         | have a CPU, it's just not a single integrated circuit or
         | microprocessor. Maybe "TTL only" or "TTL chips only", without
         | the "no CPU" part is more accurate, if "no microprocessor"
         | doesn't fit?
        
           | peter_d_sherman wrote:
           | I have changed the ending of the title to (TTL only, no
           | microprocessor)...
        
       ___________________________________________________________________
       (page generated 2021-01-16 23:00 UTC)