Gigatron Hackers

It's been a long time since I've looked at the Gigatron, but it keeps calling me back. I want to make a version that removes the things I didn't really like about it, but wanted to hear what people here thought.

I want a von Neumann architecture so I could do native assembly executing out of RAM (no vCPU reliance). This opens the possibility of expansion slots for hardware with their own memory space. I also didn't like counting lines for racing the beam in native assembly. So I want to include an interrupt and an external timer. Then you shove the video drawing into a interrupt service routine, and don't ever have to worry about counting lines again. And of course, I still want to get a native keyboard (no pluggy).

I laid out a design, but it adds 10 more chips to the design. It keeps the same instructions with two exceptions: instead of the input register being put on the databus, it's now a peripheral in the memory space. Instead the Y register can be put on the databus. This is required for saving the register values during an interrupt anyway. And then I have to add a return from interrupt instruction.

Of course this means software is not really compatible anymore. It might not take a lot to convert some software, but I just wanted to make native assembly more fun to write. What do people here think about this? Do you just prefer to write in vCPU or BASIC? Is it worth the 10 extra chips?

I read your post, I understand your wishes.

I met Marcel in September 2019 in Cambridge UK, for a vintage computer festival. We presented the Gigatron to the UK computer enthusiasts.

Marcel and I worked on a superfast Gigatron 12.5 MHz.

IMHO. Please don't try to re-invent the Gigatron. Leave it, as it is - as a lasting memorial to it's creator Marcel van Kervinck.

If you have ambitious ideas, then post them here, but leave the Gigatron for what it is, so eveyone can enjoy it, and Marcel's talent

I agree. The Gigatron and Marcel are a great inspiration. And they are not the only ones that I draw inspiration from. Even the Gigatron includes ideas from other designs. For example, the ALU design did not originate with Marcel and other CPU designs share the same ALU. I think it's which ideas we choose to draw from which create something new and unique. The Novasuar, the Kobold, the Isetta, Eater's CPU - they all are very similar because they're all gate-level CPU designs with graphics outputs. But they are still all very different. I don't have a name for mine just yet, but I'll let you know when I do.

Are you familiar with this project Minimal-64x4:

https://github.com/slu4coder/Minimal-64x4-Home-Computer

https://www.youtube.com/watch?v=L1oECH6rPvs

I think that for me a lot of what is interesting about the Gigatron, and would thus make something "Gigatron-like" is exactly the sort of thing you might be trying to get away from.

I feel Marcel found a point of balance, where he could use a relatively small amount of logic and yet get a machine that was relatively fast and powerful. I imagine that most small changes would result in something that was both bigger and worse. Quite how much luck or judgement were involved, I don't know.

Programming the Gigatron often involves quite a lot of "Sudoku solving", but I think the quirky architecture throws up solutions as often as problems. A good example of this is the way that the combination of the Harvard architecture, pipeline without hazard detection and segmented memory map allows for the right-shift table, which would be much slower and more space intensive otherwise. Apparent shortcomings that actually go a long way to compensate for another apparent shortcoming (no right-shift instruction).

A good point for discussion might be what the essential Gigatron traits are, and which are incidental. For example, I definitely consider the Harvard architecture an essential feature, but the XOUT register is definitely an implementation detail.

I'll touch on what is already here and then post some ideas. I use "Gigasimilar" to refer to homebrew ideas/projects that heavily borrow from the Gigatron. We really shouldn't try to promote something as a "Gigatron 2.0" or similar since you cannot significantly "improve" on the Gigatron and still have a Gigatron. We have the effort and sacrifice of Marcel. Most of us didn't know about his health, and he pushed through. He wanted to leave us a legacy, and we should respect that.

Touching on the first post
For the Gigatron, there isn't that much difference between Von Neumann and Harvard really. If you remove most of what is in ROM and replace it with only a vCPU implementation, and do the rest in a "classical" manner and not use multiplexing, then you would have a VN machine with little effort. The ROM would function as microcode. As for interrupts, while it's ideal to use specialized hardware, you could repurpose the Input port (use DMA or I/O mapping to add one) and poll it each instruction. Leave the function calls, though some would need to be modified for the new usage.

Better Hardware vCPU Support
Building on the above, while you can use most of the Gigatron as-is as a VN machine, there are things one can add. One of the bottlenecks, of course, is having to bit-bang the peripherals, but so is the overhead of all the context-switching and dispatching. So avoiding bit-banging not only increases the net speed, it also improves the gross speed in that overhead is not spent changing contexts, scheduling, and dispatching.

Another bottleneck is the lack of a true ADC (and I guess SBB) instruction. Unlike the 6502 which uses ADC and requires CLC if you want to use ADC as ADD, the Gigatron has the opposite issue that is harder to manage. There is an ADD instruction and no ADC. So there is no way to propagate the carry for multibyte additions, and that contributes to the vCPU bottlenecks. The ADDW instruction and likely the vPC suffer from needing to do multi-byte additions another way than expected.

Then there is the jumplist issue. You cannot currently use all the virtual opcode slots in the map. You can't even make a decent trampoline (in the general sense, not the Gigatron sense) since there is not enough room. Also, jumping to another jump isn't efficient. So what if you could jump entire paragraphs or 2 in the ROM? So a solution I see is the ability to have 256 paragraph jumps. So the Ac or the immediate field replaces the center 8 bytes of the address and always sets the lowest 4 bits to 0 (the other 4 bits are the top half of Y). So I'd like to see a native paragraph jump instruction. That way, you can use inline code for most of your vCPU handlers inline and make every potential opcode available without prefixes. (If there is a significant number where this isn't enough, you could make it double-page addressable. If it is just a few, then reserve enough room to jump elsewhere.

Another thing that could help would be more registers. Even if you keep bit-banging, you can save context swap time this way. But we must be reasonable since, like adders and decoders, muxes don't scale well. One way to visualize a multiplexer is to decode the selector lines, AND them with their corresponding inputs, and OR the results of each stage. The more selectors mean more decoding circuitry to signal a 1 when only the desired combination is selected, and the longer the OR chain. (I know this is an over-simplification, and it might use the opposite type of logic, since negative logic may be cheaper and faster.) So you'd likely use tristate buffers instead of muxes to add more registers, though you have to be mindful of parasitic capacitance.

If Speed Is All That Matters
If you really want to overclock things and beat the record of around 15 MHz, you could first start with the usual stuff. A faster crystal, a 4-layer board with ground planes, BAT42/BAT43/Toshiba diodes, lower value resistors, 74F or 74ACT components, etc. You could also mod the ALU with another adder and at least one mux. Now, one more step would be to gut most of the control unit, add 1-2 more ROMs, and add just as many flip-flops as new ROMs. Then each "instruction" would be control signals instead of numbered opcodes. When clocked at the normal speed, it should work the same as before. Just write a program to read the existing ROM file and convert that to your control signal matrix format. And you will actually have more instructions available at the discrete signal level, and you might find some to make the ROM code faster.

My Previous 4-Stage Pipeline Idea
Now, I had considered a 4-stage pipeline, hoping that 100 MHz was possible. I now figure that with existing parts you can get, maybe 25-37.5 MHz is more reasonable. The 4 proposed stages were Fetch, Decode, Access, and Execute. But I found a problem. You have to think about how neighboring instructions interact with one another in a pipeline. See, I was planning on reading/writing the SRAM in Stage 3 and making stage 4 have the ALU. But I recently realized that would cause a race condition and would almost never work. If you compute a value in Stage 4 and write it during the next instruction, the asymmetry here would cause the Accumulator to be flushed a cycle early (while the ALU is working on the needed value). So maybe the way to mitigate it is to force writing in Stage 4 (instead of using the ALU for computations). Reading in Stage 3 makes sense so the ALU stage can read this out of the pipeline. But writing there will likely be a hazard.