Who wants to see a 100 Mhz Gigatron?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Sugarplum
Posts: 66
Joined: 30 Sep 2020, 22:19

Re: Who wants to see a 100 Mhz Gigatron?

Post by Sugarplum »

Actually, some of what I propose could actually be done on a stock Gigatron with a board that plugs into the ROM socket. Then, like the versatile I/O expander, it could add new instructions and registers. However, that would not give you 75+ Mhz. It could just add shifts, multiplication, more registers, maybe division or some trig functionality, or even 1-cycle random numbers. However, that would have a lot of parts redundancy. Here is an idea one could use:

https://laughtonelectronics.com/Arcana/ ... intro.html

What Jeff Laughton did was create a hardware wrapper for the 65C02 that snoops the bus and follows the normal memory instructions in parallel. However, it intercepts the 46 "NOP" instructions. 32 of those are actually "boring," single-cycle NOPs. The other 14 of those take other cycle lengths and actually puts values on the address bus that are read to nowhere (load and discard).

Another thought, If you intercept the ROM, the RAM, and all the ports, then you'd have something more complex overall than a new "Gigatron" designed from scratch.

The snag I'm running into now for the proposed project of this thread is finding suitable ROM and RAM, and I can use help with that.
Sugarplum
Posts: 66
Joined: 30 Sep 2020, 22:19

Re: Who wants to see a 100 Mhz Gigatron?

Post by Sugarplum »

Just an update. I still need to find suitable ROM and RAM. On ROM, it seems to be most of what I'd consider is discontinued, and the rest is on backorder. Any suggestions?

Does anyone know of any ALU ops I should add? While 512K memory for an ALU would be enough to provide the functionality of the Gigatron, I figure I might as well add 1 Mb of addresses (20 lines). So that means there is room for 8 more core operations.

What about memory modes and instructions that are not specific to the ALU?

So far, on memory ops, I've considered adding:

1. Shifts in both directions and a PRNG (and yes, part of the same instruction). The idea is to use maybe 5 bits of one operand for the direction and distance of the shifter. The next bit up (or even all the way up, unless other things can be crammed in here) could be to enable the RNG. For the shifter, the other operand would be the value to shift. For the RNG, a counter supplies the other operand and even the other bits of the first operand besides the one that enables the RNG.

2. Single-cycle 8/8/16 multiplication.

3. 8/8/8 Division.

4. Neg is a possibility, but I see no real need for it. This can be done in 2 cycles already. Just XOR with 255 and then add 1. So not sure if this would be of much use.

5. I know this is probably a bad precedent, but unused ALU memory space could be used as a stack.

6. If no other uses can be found for more ALU operations, parts of its memory could be used for program storage.
Sugarplum
Posts: 66
Joined: 30 Sep 2020, 22:19

Re: Who wants to see a 100 Mhz Gigatron?

Post by Sugarplum »

Would an instruction where you multiply something in memory and then jump to that address (all in a single cycle) be helpful in designing a more efficient vCPU? So you could space out the landings of the jump table wider. And if I were to add that, what would be more helpful? Causing the extra bits to overwrite that part of Y or adding them to Y?

Overall, outside of SMD parts, adding a reset unit, designing a new clock circuit, and having to rework the power supply section to use different voltages, and adding level shifters where the ROMs interface with other chips, I think the overall machine would be simpler than the Gigatron in many ways. It would be mostly just SRAMs and registers. There would be no diodes (except power protection and LEDs), no decoders, and no inverters other than what is in the clock if I use that design. There would be no use for inverters because the correct signals would be coming out of the control SRAM. So if you need /WE low, it would send it low directly.
---

Now, when I get this built, would anyone be interested in modifying the native assembler or writing one? And would anyone be willing to help write a ROM for it? The differences would just be additional instructions in slots that are not currently used and having 3 delay slots. So if you really need to clear the pipeline, it would need 3 NOPs. Otherwise, put 3 instructions after the jump that will execute before the jump target.

---
And I figured out something someone could do if they wanted to make something closer to the stock Gigatron faster. They could take a stock ROM image, run a program to decode the ROM, and put the decoded instructions into 3+ ROMs. Then they could put the control signals in registers and keep DR. Then disconnect most of the control unit and feed the outputs of the registers there. And if they get their ROMs to 40ns, then they could do up to 25 Mhz, I think. If the ALU is lagging a bit for that, then replace the high adder with a board that has 2 adders and a mux. I wouldn't do this, but it would be a way to speed it up for sure.

Wait a minute. There could be a compromise of that on mine. The startup unit could run the system ROM through a control matrix ROM and cache those signals into fast SRAMs, and use fewer parts. So it could cache the entire system ROM in decoded format. Then it would only be a 3 stage pipeline. And if I were to handle the ALU and RAM much like the Gigatron does now, that would push things to around 50 Mhz. But if I continue with at least 3 stages, that should get close to 100 Mhz. And there is only one way to really know.
Post Reply