Explaining microprocessors to people in 1982-83

TEC-1 1 Minute

Explaining microprocessors to people in 1982-83

This illustration is a composite of sketches Ken Stone and I made to attempt to explain the workings of CPUs and machine code to hobbyists back in the early 80s.

This was published in issue 10 of Talking Electronics in early 83 to go with our TEC-1 computer kit. For a few years the TEC-1 was the cheapest, most accessible way for Australian hobbyists to enter the mysterious world of computing.

Before long of course that space would be filled with consumer systems that could actually do things that were useful apart from just learning how to program.

Unknown's avatar

Published by John Hardy

Closures are a poor man's object. Objects are a poor man's closure.

Published

6 thoughts on “Explaining microprocessors to people in 1982-83”

  2. First Surname too low level. It’s actually too simple in that you need to write a whole lot of of it just to get even the smallest task done.

    Talking about this stuff with my developer colleagues I get a kind of blank stares of disbelief. One said:

    “Man I’m sure glad I wasn’t born back in those days…”

    Like

    Reply

  3. John Hardy I studied robot systems. Since that can be seriously close to underpowered metal, we had a course in assembly, specifically for ATmega32’s, in 2011. From that we learned C and C++, which seemed high level and easy to use.

    Many of my colleagues today (who are younger than me; the company is big on hiring straight from university) think of C and C++ as archaic languages which nobody learns.

    We programmed an autonomous Scalextric race car with optocouplers, H-Bridge motor control and interfacing with Bluetooth in assembly during second semester.

    Like

    Reply

  4. Assembler is actually much easier than C++ or Python.

    You make an algorithm and you code.

    With the modern language, you have an algorithm, you start coding and then you look for reference for the proper function or method or whatever. Then you code. Then look reference manual. Then code…

    Like

    Reply

  5. Olivier Malinur looking in a datasheet for operations or a reference for correct implementation is very much the same to me. Plus, I don’t have to bother with how to structure memory in an interrupt and a non-interrupt so that they don’t corrupt each other’s registers.

    And don’t get me started on portability; just the fact that different versions of same model had different errata sheats (and thus required different implementations of the same functionality) makes the chills run down my spine.

    Like

    Reply

Leave a reply to Olivier Malinur Cancel reply