That instructables page is great because you can actually print out the cardboard components and build your own cardboard "computer" system!
The instructional manual probably makes a lot more sense with the actual system that it describes in hand.
As I see it, the genius of CARDIAC is this (emphasis mine):
> You will serve as CARDIAC's control unit by visually following its internal flow chart. While doing so, you will perform all of the operations described above.
Human-as-datapath is a fantastic idea for learning the basics of not just programming, but of microarchitecture. Once you start thinking, "hey, I could make a machine/circuit/etc. to do all of this stuff that I'm doing by hand" then you are on your way.
> Human-as-datapath is a fantastic idea for learning the basics of not just programming, but of microarchitecture. Once you start thinking, "hey, I could make a machine/circuit/etc. to do all of this stuff that I'm doing by hand" then you are on your way.
Having taken a survey course on computer architecture, hand simulation's the most I've ever been able to understand "complex" (scare quotes) mechanisms like out-of-order execution, multiple dispatch, speculation, etc. Which is a pity - the scare quotes belie the fact that these have been integral features of microarchitectures for decades, and they're key to understanding software performance and entire classes of security exploits.
In terms of actual implementation, I think I've only ever gotten as far as pipelining with result forwarding.
> While there are a number of great CARDIAC simulators out there (see Building a CPU simulator in Python for instance) and even an FPGA implementation (Al Williams - Paper to FPGA) there is nothing like holding and operating a physical device.
"Paper to FPGA" sounds like a cool idea, though the point of CARDIAC seems to be that you perform the operations yourself (by carefully following its flowchart/control specification and manipulating the cardboard device.)
That article has a link to an Excel implementation which allows you to "perform the operations" yourself without having to cut and assemble the computer.
I suspect this had a two-step teaching process for neophytes... First, they'd play with the cardboard machine and get a feel for assembly programming, instruction processing, memory, etc. Once then, after a bit more hacking on things like Star Trek or 4x4x4 tic-tac-toe they'd set out to write an electronic version (virtual machine!) of the cardiac "computer". Debugging that process taught all sorts of relevant things.
And it vaguely felt like a PDP-8, and I suspect it also felt like whatever very early minicomputer that was available.
> (3) that the typical 12-year-old youngster has the interest, skill and basic knowledge necessary to build and understand simple working models of practically anything
Indeed, or even younger. I look back to that time and realize that I was capable of quick breadth first knowledge aquisition - something that often escaped me when I was older and wanted to go deep on everything but this slows you down if you're just trying to get something finished.
My father recently gave me a big pile of stuff from my childhood (cleaning out the attic) and this was mixed in. I think he must have acquired it during HIS teenage years, since he would have been in high school at the time. It was fun looking it over and it makes me wonder whether it might not be a bad idea to return to paper exercises for students in some form.
This one is higher quality (https://content.instructables.com/F84/WG7G/K2XU5LKV/F84WG7GK...) and it's all kinda pointless without the "machine" https://www.instructables.com/CARDIAC-CARDboard-Illustrative...
I didn't get mine until about 1979 or 1980. Still have it, though.
That instructables page is great because you can actually print out the cardboard components and build your own cardboard "computer" system!
The instructional manual probably makes a lot more sense with the actual system that it describes in hand.
As I see it, the genius of CARDIAC is this (emphasis mine):
> You will serve as CARDIAC's control unit by visually following its internal flow chart. While doing so, you will perform all of the operations described above.
Human-as-datapath is a fantastic idea for learning the basics of not just programming, but of microarchitecture. Once you start thinking, "hey, I could make a machine/circuit/etc. to do all of this stuff that I'm doing by hand" then you are on your way.
> Human-as-datapath is a fantastic idea for learning the basics of not just programming, but of microarchitecture. Once you start thinking, "hey, I could make a machine/circuit/etc. to do all of this stuff that I'm doing by hand" then you are on your way.
Having taken a survey course on computer architecture, hand simulation's the most I've ever been able to understand "complex" (scare quotes) mechanisms like out-of-order execution, multiple dispatch, speculation, etc. Which is a pity - the scare quotes belie the fact that these have been integral features of microarchitectures for decades, and they're key to understanding software performance and entire classes of security exploits.
In terms of actual implementation, I think I've only ever gotten as far as pipelining with result forwarding.
> While there are a number of great CARDIAC simulators out there (see Building a CPU simulator in Python for instance) and even an FPGA implementation (Al Williams - Paper to FPGA) there is nothing like holding and operating a physical device.
"Paper to FPGA" sounds like a cool idea, though the point of CARDIAC seems to be that you perform the operations yourself (by carefully following its flowchart/control specification and manipulating the cardboard device.)
FYI, the link to the Al Williams article on DrDobb's website from the Instructables page seems dead but.. Wayback machine to the rescue:
https://web.archive.org/web/20180306072013/https://www.drdob...
That article has a link to an Excel implementation which allows you to "perform the operations" yourself without having to cut and assemble the computer.
It give me the concrete basis for "being the computer" that I put to use a year or two later programming assembler on a PDP-8I
:-)
I suspect this had a two-step teaching process for neophytes... First, they'd play with the cardboard machine and get a feel for assembly programming, instruction processing, memory, etc. Once then, after a bit more hacking on things like Star Trek or 4x4x4 tic-tac-toe they'd set out to write an electronic version (virtual machine!) of the cardiac "computer". Debugging that process taught all sorts of relevant things.
And it vaguely felt like a PDP-8, and I suspect it also felt like whatever very early minicomputer that was available.
Related, from 1959, many years before CARDIAC:
PAPAC-00 A 2-register, 1 bit, Fixed Instruction Binary Digital Computer
https://longstreet.typepad.com/thesciencebookstore/2010/11/a...
I got a 503
https://web.archive.org/web/20201109034337/https://longstree...
Published in CACM no less. Also:
> (3) that the typical 12-year-old youngster has the interest, skill and basic knowledge necessary to build and understand simple working models of practically anything
Indeed.
Indeed, or even younger. I look back to that time and realize that I was capable of quick breadth first knowledge aquisition - something that often escaped me when I was older and wanted to go deep on everything but this slows you down if you're just trying to get something finished.
I was given one of these by my eighth grade science teacher, ca. 1970. I still have it. It helped spark my interest in computers.
I go one of these as well. Sadly, I was too dense to "get it" at the time.
(It was Trek on the TRS-80 though that put the hook in me.)
My father recently gave me a big pile of stuff from my childhood (cleaning out the attic) and this was mixed in. I think he must have acquired it during HIS teenage years, since he would have been in high school at the time. It was fun looking it over and it makes me wonder whether it might not be a bad idea to return to paper exercises for students in some form.
Student-as-datapath is a great idea.
> Fig. No.5 Flow chart of repairing a flat tire
> Start: Are you a girl?
man, I was not prepared for that lol
I'd love a SUBLEQ mechanical computer with Eforth outputted into a teletype.