In this strange year of lockdowns and social distancing, many of us will have had some spare time on our hands.
I chose to use this time as constructively as possible, and to advance my understanding of computer science, software and hardware design languages. After 35 years in industry as a hardware design engineer, I wanted to go back to basics and fill some of the gaps in my technical knowledge.
I devised a broad outline plan, based on what I had learned from building the Gigatron.
1. Create a new cpu based on a novel architecture. Define the instruction set and architecture ISA
2. Write a simulator in C, to test the ISA and prove that it is viable for general purpose applications
3. Port the cpu design to a hardware description language HDL - in this case verilog, and implement the cpu as a soft core on an FPGA
4. Develop a range of software applications so the cpu can perform useful tasks
5. Implement the cpu in real TTL
This has become quite a journey, but not an insurmountable challenge. The first step is the hardest, because it defines the direction of the rest of the project.
So it occurred to me, that based on what I learned from Gigatron, whether there might be value in creating an educational course around the Gigatron Project.
In 2013, I took the online course "From Nand to Tetris" (N2T) - the building of a modern computer system, starting with only the Nand gate. I followed the course through each of the chapters covering every aspect of the hardware and software.
It was a stimulating exercise, but unfortunately, it only existed as a simulation on a PC - there was no real hardware at the end of the course.
Marcel's Gigatron filled the gap left by the N2T course. Here at last was a real computer, build from real TTL devices, which proved that the theory supplied by N2T course was actually possible.
Indeed the Gigatron is a relatively simple cpu. It was designed as an exercise in minimalism, to create a cpu that was capable of hosting colour video games with audio.
It's simplicity is its appeal. Who would have thought that you could create a useful cpu in fewer than 1000 gates?
We live in an age of 10 billion transistor cpus, of overwhelming complexity. How is a newcomer ever going to understand their architecture or instruction set?
Students of CS probably never will fully comprehend the underlying principles of the machines that they program. Instead they rely on libraries of routines that were written decades ago.
Combining the structure of the N2T course with the real hardware of the Gigatron, would provide a real educational tool, and provide students of Compter Science and Electronic Engineering with a good grounding across a wide range of disciplines.
A $20 Teensy 4.0 can emulate a Gigatron in Arduino compatible code, at a rate of about 50 million instructions per second.
Whilst putting a Gigatron on an ASIC might be a somewhat unrealistic aspiration, we now have a wealth of low cost FPGA boards supported by open source tools, which could be used to provide a suitable experimental platform.
Gigatrons and Education
Re: Gigatrons and Education
I've learned a lot by studying the Gigatron over the past year even though I haven't built one or owned one yet.
As I've played with ways to mod it in my mind, I've learned more about why various decisions were made. I've asked myself many questions such as, "If I change how this is done, what would it break?"
For instance, placing Moves outside the scope of the ALU might be more efficient and reduce latency for those ops, but that would limit how the ports work. I love how you can move data to the ports, filter it through a bitmask, and increment the index register, all in a single cycle with only one instruction. Then, of course, you have X-Out. That requires having the data in the accumulator.
As I've played with ways to mod it in my mind, I've learned more about why various decisions were made. I've asked myself many questions such as, "If I change how this is done, what would it break?"
For instance, placing Moves outside the scope of the ALU might be more efficient and reduce latency for those ops, but that would limit how the ports work. I love how you can move data to the ports, filter it through a bitmask, and increment the index register, all in a single cycle with only one instruction. Then, of course, you have X-Out. That requires having the data in the accumulator.