to Courtney.

Sorry I was busy at work.

<<Yes, it would be easier to get others involved if they can see everything, and what is proposed or built. I don't know what diagramming software or sites for that are out there. I see all the diagrams that some post, but don't know how they make them. I am not going to sit in Paint and make this stuff. My art skills are not that good. >>, most of the time I am using Logisim for diagrams and simulation, but you can also use this drawing online tool at www.draw.io website, I am using it a lot.

<<I'd need to gains some tools, resources, and skills to do this. I've never worked with SMT. I might want to invest in a flow oven or similar. And I just hope I don't have to work with BGAs. Even SOICs are a bit daunting. And going that far, I might need a microscope too (and new glasses).>>, That real a big problem, also for me I am not an electronic engineer my self, but referring to some electronicians, the problem is not that big, you can charge at some point  someone else to do the electronics, or you can take certain time to learn.

<<I think Power/Exp might be handy to add. I'm not sure about SqrRt. I mean, I am not quite up to doing IEEE floating-point. Maybe fixed point, but can't really do that past a fractional part more precise than 1/256.>>, if you are really thinking of using a fixed point solution, one way to do it is to implement for each operation 2 type, one returning the real result and the other the fractional part, in my sense, it would be more manageable.

<<So, a battery, supercapacitor, or flash could help preserve the index into the random count.>>, I think a simple, small serial flash memory could do the trick too.

<<For instructions, it would be nice to have native instructions for most BASIC commands. However, things like ASC, Char, Val, etc., would likely not be good for a Harvard machine as native instructions. I don't see any real way to do those instructions outside of using microcode or software.>>, personally, I would implement them like a normal functions.

<<I had another brainstorm. What if the bootstrap/reset unit were to run the system ROM through the decoder ROMs on boot and then cache that into SRAMs?>>, by the system ROM and decoder ROM you mean program ROM and Control Unit ROM, if so? I don't know if that would work, but you will face a problem with the control signals, normally you will need a lot of them, plus the data and instruction output.

@Kara Abdelaziz 

I have created a page for this. Trust me, the Gigatron crowd hasn't shown much interest. This goes for the main forum, the Discord "Unofficial Gigatron Server," and my own Homebrew Computing Discord server. So it will be helpful to use my page here to collect everything together and have a unified place for posting things as I mention it in other places. I find many in this realm don't enjoy talking about it as much as I do and having never built anything like this does little to help my credibility or make others want to listen to me.

Actually, the left shift is easy to implement in software on the Gigatron. All you have to do is use the Ac=Ac+Ac instruction multiple times, and the native ROM does this.  Adding a number to itself is a left-shift. 

A right shift is harder to do on the Gigatron since there is no hardware assistance at all here, but it is possible. You might not be able to do it with your creation since you may have removed the hack that makes this possible. See, the Gigatron has the pipeline and you can trick it into having unassociated things in the Data (eg., immediate operand space) register by doing a Load during a branch. That takes advantage of the pipeline. You don't have to Nop things out immediately after a branch/jump. If you branch during branches to load things, this is called a trampoline. I don't understand it, but you can build a table or load software from the ROM this way. I don't understand it, but Marcel put a right shift table in ROM.

So the Gigatron can already do shifts in both directions. The left shift is the easiest. Still, having those in an ALU would be faster.

I could just put all the shift operations and even a PRNG table in the same space in ROM and use the operand field to set which one to use. I tell more about this on my project page (well, will as soon as I save the details). So maybe reserve 4 bits for the distance, 1 bit for the direction, and that leaves 3 bits. Those 3 bits can determine which of the PRNG subtables to use. As long as at least 1 of those upper bits is 1 then a random number is returned. In fact, maybe only 1 of those bits should be used for this for simplicity. Just make the RNG index counter wider to use all the bits before the bit to enable it. Real PRNGs are tables even if they're mathematical equations since if you start with the same seeds, you get the same results every time. So you can have an index counter that runs in the background, and when RNG is requested, that counter post-increments and provides one of the operands, and it can be 13 bits or so. 8K is a lot of gibberish. And really, it might be more helpful to have the RNG stuff to happen in stage 3, to allow for a way to make more "random" numbers. So the first "ALU" could provide the scrambled numbers, and the main one would be free to add something to it. If the table is balanced, then it will still be balanced if you add something to it for the same "period." With 8-bit addition, truncation would occur and you keep what doesn't overflow.

Even my older idea comes to mind of providing a 2nd control unit and ALU. It took a lot of thought to figure out how to do this without disrupting the critical path. In that case, let the data register also enter a decoder ROM, and have a bit on the main one to specify whether the second decoder will be valid. Of course, it would need to be limited in scope to avoid hazards. In that new instruction set, I'd make 0 be NOP for ease and compatibility. It could only be instructions that use no operands, and I guess it should have its own accumulator, etc. On memory, it should either use it sparingly or not at all.

Yes, instead of using fixed-point math, storing a modulus might be more helpful, and you are right that the programmer could trap for divide by 0.

I love what Drass has done. His TTL/CMOS 20 Mhz board is amazing. It would be nice if Bill Mensch would have done some of the things he did with the 65c02 and the WD65c816, which only do 14 Mhz these days. A few things stand out about how he got the faster clock rates. For one, he pipelines the microcode so that it is ready when the next instruction is ready. Since the 6502 is fairly orthogonal, he only has to trap for a few instructions so bootstrapping is not a problem. So the microcode gets loaded a cycle earlier than on the 6502. That gains a few Mhz. 

Then there's the carry-skip adder. That could be done on the Gigatron if you add 2 more chips. The "fast" 4-bit adders add a bottleneck when you chain them. They work in series on the Gigatron. Sure, both start at the same time, but the upper one is not reliable until there's a chance for the lower one to send a carry. Now, if you add an adder, you can have the carry-in of one upper adder tied to the ground and the other tied to the Vcc. So one assumes no carries and the other assumes a carry. Then the carry-out line of the lower adder toggles a multiplexer. It is faster to switch which upper adder goes on the bus than to wait on the upper adder to finish. On the Gigatron, adding that now could allow for a faster clock rate, but if you split the control unit from the ALU (eg. adding registers to create a new pipeline stage), it likely would gain nothing (unless you speed up the control unit). Technically, you could do this with LUTs, but there'd be no advantage unless space is an issue. You could do it if you want to do 16-bit operations, though really, one could have another adder in stage 3 and let the main ALU handle the upper byte. Then it would already know if a carry is involved. I'm not sure how to break up subtraction. But it would need knowledge of both bytes from the start, I think. Drass had to rethink the ALU altogether for 100 Mhz, and it was faster to use more chips and build a faster one. On counters, he found that it was faster to multiplex the inputs with ground to reset them than to use the reset line.

Drass also worked to get the BCD math out of the critical path. That is costlier in terms of carries since you carry by adding 6 and borrow by subtracting 6. I don't know if there'd be any advantage to adding that to a Gigatron, though it would help with emulating the 6502.

On transistors, I'm not sure if you can still get RF transistors. Those are what you'd need here. I doubt they'd help me at 100 Mhz. And using transistors, if possible, one might want to use "CMOS" tech, and not NMOS or PMOS tech if possible. I mean, I think throwing another transistor is faster than waiting on the current to pass through a resistor. NMOS tech uses a resistor to pull things one way and PMOS uses the resistor to pull things the other way. It can be faster to have 2 transistors "fight" each other than to have them "fight" a resistor. But it all depends on if you can find fast enough PNPs. I think NPNs are faster, but I could be wrong. PNPs are the oldest bipolar transistors, IIRC.

Another idea on finding memory pops into mind, I might know a way to make say, a 15 ns SRAM work at 100 Mhz. What if you had 2 overlapping 50 Mhz clocks, double the memory used, and alternate between them? And I guess the slower clocks would need to be about 180 degrees out of phase with each other and not 90. And skewing the faster one to start a tad earlier might be beneficial (such as for MUX setup time). The pipelines would need to be deep enough to allow for that. There might need to be a stage after the last ALU.

Another project idea would be to see if one could build a truly asynchronous Gigatron. On that, one would want to have I/O clocks for sure, since you lose all references to time, beyond locally to each stage. So most bit-banging would be useless. If doing it the way I propose for the current idea, it might be helpful to use 9 and 18 bit SRAM and initialize all the parity bits to 1 when copying from the ROMs. Thus you'd have operation completion markers for the handshaking between stages. I don't really know how async computing works, but I hear it generally takes twice the circuitry. The advantages would be not having clock circuitry all over the place, maybe lower power consumption, and less EMI. The clock is the main source of EMI, and without the clock, you'd have more spread-spectrum emissions since all operations don't take the same time every time. And it would have some inherent protection against certain conditions. If it starts to get hot, the circuits won't work as efficiently meaning that the other logic will slow since there would be fewer handshaking signals between stages. And if you have power issues like occasional sags, that would also slow things down. WIth combinational logic, the ALU would work closer to ideal for each instruction, and even within the same instruction. For instance, adding 0 would finish faster than adding 1 to 255 and a NOP could literally do nothing at all beyond fetching it. A 6502 built around that would need no special care in designing the BCD portion of the ALU since those would naturally take longer and everything else can run closer to ideal. But it would never work in an old Apple.

A good thing about having multiple counters or ALUs would be that it would not increase the complexity of the startup unit by much, at least in terms of the ROMs used. If you can copy to 1 SRAM, you can copy to 2.

So back to the ALU. Since I'm aiming for 4 control lines, I'd like to know what else I should have it do.  Obviously, the Gigatron has these:

1. Add

2. Subtract

3. And

4. Or

5. XOR

6, Load

7. Store

8. Branch

So far, other possibilities include:

9. Shift (both directions and PRNG)

10. Neg (maybe)

11. 8/8/16 multiplication

12. 8/8/8 division

13. Push/Pop. If I can't find other things to put in here, portions could be used as stack space.

14. Program storage. That's a thought too if we can't think of other things to add.

Thanks for your interest and support. It means a lot.

<<Actually, the left shift is easy to implement in software on the Gigatron. All you have to do is use the Ac=Ac+Ac instruction multiple times, and the native ROM does this.  Adding a number to itself is a left-shift.>> That is true, i made a mistake, the right shift is the one that it was impossible to formulate with other operations, and yes, it is also possible to do it by software using a lookup table, which is feasible for an 8 bit value.

<<Even my older idea comes to mind of providing a 2nd control unit and ALU>> If you are looking for multistage pipeline, normally you will need a specific controller for each stage, I can't clearly visualize how you are intended to implement the pipeline.

<<On transistors, .... oldest bipolar transistors, IIRC.>> You need to check there datasheet but I think the most of them are faster that 10 ns. And by the way, Gigatron already used a similar technique in the CU to create an AND gate with a bunch of resistors and diodes.

<<Another idea on .........the last ALU.>> I have no idea if that would work or not, but one problem arises, you need a way to synchronize the 2 RAMs.

<<Another project idea would be to see if one could build a truly asynchronous Gigatron. On that, one would want to have I/O clocks for sure>> I think it would not be difficult by simple synchronization mechanisms, like ready signals and so on....

<<So back to the ALU. Since I'm aiming for 4 control lines, I'd like to know what else I should have it do.  Obviously, the Gigatron has these:>> Normally, push/pop needs an additional register or a counter that can increment and decrement.

And more important you need to create a specific project where you could put some diagrams and maybe videos of testing things, It would be mush more helpful.

The pipeline isn't hard. It will just eat up registers. The stages shouldn't be really any different than having IR/DR now. Those are used to decouple the ROM from the rest of the system. So you do similarly between the other stages, and yes, any outputs they make would need to be held in them. So just like you'd use multiple control ROMs, you'd need multiple registers to hold the signals until they are needed since things will change. Care would need to be taken to make sure this causes no hazards/races. You don't want something later in a pipeline to change settings before earlier things that need other settings can work. No, you'd register that so it gets changed when that instruction needs it. That is important, IMHO, when applying global "modes." It seems it would be safer on stuff like that to let the ALU apply it and not the control unit directly.

And speaking of global modes. That's always risky on any CPU design. This is a hazard even on the WDC '816. It lets you be in "emulation" mode (6502 compatibility mode) or "native" mode (WDC65C816). An example here is handling hardware interrupts. Let's say your software uses one mode and your ISRs use another. The only safe way to do that, IMHO, is to test the mode upon entry to the ISR, set it to what is needed, and change it back, and hope that doesn't make things too late for whatever requested it. So having lots of CPU "modes" of operation really isn't good practice, despite seeming like a good thing.

On the slower parallel pipelines idea, syncing them is what the 2 slower, mirrored clocks are for. Let one of them drive the multiplexer (and the mux defaults to the other slow clock). So the 100 Mhz side only sees continuous traffic, agnostic of the source. It would just take a lot more parts, it seems. Also, I imagine it might make skew/jitter more problematic, but there's only one real way to know. If that would work, imagine making a 25 Mhz Gigatron out of two.

Yes, I didn't mention the stuff about Push/Pop since I know what all is involved and it's glaringly obvious. So even if I had to do the table route, that isn't hard. Both of the last 2 stages or at least the 3rd one (since that's the memory management stage) would likely need an incrementer/decrementer or 2. And if using tables, do both on the same chips where possible. If you go over 256 bytes, you'd likely need an upper stack register. And it would be easier to merge them, ie., make them count together, not how X works on the Gigatron.

Yes, it would be easier to get others involved if they can see everything, and what is proposed or built. I don't know what diagramming software or sites for that are out there. I see all the diagrams that some post, but don't know how they make them. I am not going to sit in Paint and make this stuff. My art skills are not that good. I'd need to gains some tools, resources, and skills to do this. I've never worked with SMT. I might want to invest in a flow oven or similar. And I just hope I don't have to work with BGAs. Even SOICs are a bit daunting. And going that far, I might need a microscope too (and new glasses).

A few more thoughts. I think Power/Exp might be handy to add. I'm not sure about SqrRt. I mean, I am not quite up to doing IEEE floating-point. Maybe fixed point, but can't really do that past a fractional part more precise than 1/256.

On the table-based RNG, I know what would make it seem more random, but not sure how one would do it. The persistence of the RNG's index between boots would help. So you get different numbers each time. 

One thing that was done on pinball/arcade games was to have a small SRAM for the high scores. Watching repair videos of those machines, I see the problem with that. They would put batteries in the unit (and blocking diodes of course), often the holder was soldered to the mainboard. When Ron Lyons works on them in the videos, he often gets a flash/SRAM hybrid chip to put in place of the SRAM holding the high scores and removes any batteries and their holders. In one video, Ron was rather aggressive in dealing with corrosion. He just started clipping chips loose and tossing them. He did it that way in case traces wanted to lift so he could gently remove the pins after physically cutting the chips out. Then he scrubbed and washed the PCB, and then repopulated it with new parts. He didn't want to leave any corrosion to spread. 

So, a battery, supercapacitor, or flash could help preserve the index into the random count.

And the same "counter" for the RNG, even if it is a table, could update X, any stack, etc.

For instructions, it would be nice to have native instructions for most BASIC commands. However, things like ASC, Char, Val, etc., would likely not be good for a Harvard machine as native instructions. I don't see any real way to do those instructions outside of using microcode or software.

Would there be any use for BCD math? Besides writing a better 6502 emulator, I don't see much use. That said, it still finds modern uses in financial applications. And 6502 games likely used that for dealing with scores. There are tradeoffs with each approach. If you only work in binary, you don't have the overhead of making a special case of carries. But you have more work in converting to ASCII. I don't know how it would be done on the Gigatron, but on a PC, I'd keep dividing by 10 and build the strings (right to left) from the remainders (and add the ASCII offset to each digit to produce the characters). BCD has more overhead in more conventional CPUs, but converting to characters is a little simpler. You don't have to split the individual digits out.

I had another brainstorm. What if the bootstrap/reset unit were to run the system ROM through the decoder ROMs on boot and then cache that into SRAMs? Then the machine runs out of those, and you have 3 stages, not 4. I think that would save registers and use the same amount of memory. So the ROM is converted to the control signals and stored in SRAM.

Oh, I get what you were saying on doubling memory to use in alternating cycles. Yeah, I was only referring to control and ALU memory which could be dealt with through an additional pipeline if necessary. 

You were likely meaning user RAM. Yes, coherency could be a problem since that is bidirectional. With the others, having 2 tables would suffice since you start with concurrency and maintain it. But system RAM could be a challenge. As for the other memories being doubled, I don't quite see how the clocks would work, or if they would, but at the least, it would take 3 fast cycles to do it.

To courtney :

<<I imagine fewer than 21-bits could be used with the ALU ROM. I don't see much need for 32 operations.>>. Actually, Gigatron uses only 8 ALU operations, thus need only 3 additional bits, which makes 19 bits in total for the ROM input, despite the fact that Gigatron uses 5 bits, caused by the way the ALU wes designed.

<<I just like the idea the one used to emulate having a Carry-in line for a ROM-based ALU>> That is really amazing, never seen that before, it is really awesome how people become inventive with restricted hardware.

<<So the ALU would just be a LUT in RAM. The same speed could be used for all SRAMs>>, I agree, it seems there is non ROM faster that 10 ns, the fastest I found was 20ns, in the other hand SRAMs are way faster.

<<I'm curious how you'd add hardware interrupts.>>, An idea was to add in total 3 registers, 2 the save the PC and one for the IRQ signals, 1 bit indicating an interrupt had occurred and the others the type of IRQ, the 3 registers would be accessed through the data bus, the Control Unit needs 3 more command output signals to control those registers and one additional input from the interrupt bit to know when interrupter happen. The implementation would need to burn and reserve on the program ROM the interrupt handler code at address 0, and when an interrupt arrives, makes the CU saving the PC and resetting it to 0. I think this solution should tested though, I am not 100% sure about it.

<<You likely won't find faster than 7ns in async/SDR SRAMs. Once you go lower than that, the complexity of the SRAMs increases. You run into synchronous with more control lines and DDR/QDR, etc.>>, Personally I never worked with RAMs/ROMs faster than 50ns, I have no idea about the lurking complexity.

<<Then another issue would be designing the board, let alone assembling it. Once you reach about 40-50 Mhz, crosstalk and so on might start to become a problem....with hard drives, the PATA interface doesn't go past UDMA-133. For 150+ MTs, the industry switched to SATA.>> Sure, in any case, it is not breadboard circuit, a lot of problems come with higher frequency, this kind of design needs its proper expertise.

I might just make a page for this and I can go into details more there. I don't want to hijack your page.

I think I'd want to use a 20-bit ALU ROM to add more ALU ops such as full left-shifts, right shifts, and maybe multiplication. I'd use a 16-bit wide ROM to have flags, though like I said, the flags could be sacrificed for multiplication. For 8-8-8 division, if I add that, I might want to return an 8bit result, maybe use up to 4 bits for a fixed point fractional part and the rest for flags. You really need an exception/DBZ flag. Maybe a zero flag. Know of any other helpful native ALU ops? Neg is a possibility, but that already takes just 2 cycles. To negate a number now, you XOR it with 255 and then add 1 to it.

Another thing I'd like to see would be a hardware RNG. The Gigatron currently takes cycles to scavenge the memory for random bits. Well if we can run code anywhere in the scanline and much faster, it may be easy to outrun it or run it dry. I have 3 different ideas in mind. One could do a shift-XOR RNG. That may take a shift register, two regular registers, an XOR gate, and multiplexers. Generally, you'd have to shift it and then XOR it. But there are cases where you'd need to trap one or the other operations. And a ROM and a counter could help for an XOR value table. Or, there could be 2 additional oscillators, an XOR gate, and a shift register. Or, this could be a table. Heck, it could be in the ALU ROM with a counter as the input.

Speaking of counters, I wonder how to manage that. I mean, the PC and X use counters, as would 2 of the 3 RNG ideas. I don't think there are any really fast counters like there are no fast or wide adders. Drass of 6502.org had to make his own adder and maybe program counter too for his 100 Mhz TTL 6502. I think he used transparent latches for that. If worse comes to worst, guess what could be used for that? In that case, a 16-bit wide shadowed ROM and a register could be used for the PC. The register could be looped back into the SRAM. So for every location, have the result to be one higher, except for $FFFF which would be 0.

It might be better to start more modestly, such as shoot for 50-75 Mhz. Really, it should be a multiple of 6.25, but a multiple of 12.5 or 25 would work. And getting other speeds isn't too bad since there are PLL and clock multiplier chips. The Pierce oscillator could still be used, but I'd feed it through a clock chip to get higher rates and a cleaner signal. As it is, there are harmonics and ringing on it.

<<I might just make a page for this and I can go into details more there. I don't want to hijack your page.>> It is not a problem for me, but I think the best way to collectively brainstorm the design of a new variant of Gigatron is to use the Gigatron forum, you will be in touch with a community akin to the project.

<<Know of any other helpful native ALU ops?>> I think every necessary operation is already implemented. The shift left remains a mandatory operation knowing that it would be impossible to replicate by software.

<<You really need an exception/DBZ flag>> Not necessarily, you can bear the responsibility of checking the division by zero to the programmer and use the remain 8 bits for the remainder.

<<Drass of 6502.org>>, I haven't heard about Drass before, but God this is what we call a good project. I did an implementation of the 6502 on Logisim before, different from the internal 6502 micro-architecture (used by Drass) but still instruction accurate, at that time I had thought about an implementation using TTL chips, everything seems fine, except for the multiplexers, I needed 8 inputs 8 bits Muxes , which imply 64+3 lines in total, and I needed 2 of them for the whole processor, that was unlucky of such a simple task. One not explored yet idea was to use transistors instead, I think it would be easier if possible, than using an enormous number of TTL, I didn't try it yet, so I've no idea if it would work or no.

<<If worse comes to worst, ..... except for $FFFF which would be 0.>> It seems like the ROM solution is unavoidable to replace the slowest combinatory logic, nevertheless, it is always possible to use +1 function with ALU to increment the register value, or even using X+1 operation with ALU, which of course will require more cycles, or maybe you could think about adding some transistors aside the register to mimic the counter, normally transistors are faster that average TTL chips.

<<It might be better to start more modestly, such as shoot for 50-75 Mhz. Really, it should be a multiple of 6.25, but a multiple of 12.5 or 25 would work.>> I think it is really a good project that need realization. Hope you good luck, and hearing about it soon.

Someone has since come up with a RAM expander, I/O expander, and video accelerator for the Gigatron. Bus-snooping is the approach that is used. So the device knows when software is writing to video memory and reads the memory independent of the CPU.

The 4 stages I propose are Fetch > Control > Access > ALU.

The reason I suggest 4 stages (or 3 if already shadowing the ROM) is because once you take the ROM off the table, the execution unit is the next consistent bottleneck. Due to it being a Harvard machine, you don't use RAM for every single native instruction. Marcel partially hid this by using the staggered clock arrangement. So the execution unit is the next bottleneck. If you consider the 2 main activities of the EU (RAM access aside), the control unit takes up the most time. Right now, with a 2-stage pipeline, you could create higher stability during overclocking by adding 2 more chips to the ALU (to make a carry-skip adder arrangement), but splitting the EU into CU and ALU would increase the clock rate more. 

As for dealing with memory, I think that having an access stage between the CU and the ALU would be a good way to deal with it. All RAM writes are direct stores, but reads may be conditional. No processing is done for writes. So have "Access" before the ALU stage in case the ALU is needed because of the type of memory read.

As for why I've suggested a ROM control unit instead of a combinational one (and shadowing this ROM to get <10 ns) is to make it easier to add more instructions. If one wants to still bit-bang VGA, one would need to deal with the differing clock rate between the CPU and the video. That's one issue with having the video too coupled to the CPU speed. I get why Marcel put everything on the left side of the screen in the test ROM. There was no way to use the time between the pixels and keep the current resolution. Now, what would make that possible would be another set of index registers. So if you're doing 100 Mhz, you'd only need to write to the screen every 16 pixels. That isn't enough time for a vCPU slice. But, if you had an extra X and Y, you can keep both the video context and the vCPU context active at the same time. So even if you need 2-3 pixels at 100 Mhz to get enough 15-instruction gaps, you can do the screen-writing as part of the vCPU with the help of more registers to eliminate the need for context-switching.

I read about doing a ROM-based ALU. I've thought of that for a long time. But in the example I found, they used a 16-bit ROM to do an 8-bit ALU. The extra data bits give an inherent Flags register. And they suggested a 21-bit address bus. So if you use 8 for operand A, 8 for operand B, then that leaves 5 bits for control bits, making it capable of 32 sets of tables. This seems promising since if one wanted to, they could sacrifice the Flag bits and have the upper half of an 8-8-16 multiplication there. In the example of a ROM LUT ALU I saw, they handled the Carry-In bit in an interesting way. Sure, they could have used one of the 5 leftover address bits for that and sacrificed half of the possible ALU ops. Instead, they included instructions that assumed an incoming carry was set and clear, arranged them to where 1-bit was different and added board logic to assume one and revert to the other as needed. For instance, assume ADC and if the carry-in line going to the multiplexer isn't set, it would do an ADD instead. And similar with SBB vs SUB, etc.

I suppose your are aiming to break the 100 MHz wall for Gigatron.

<<Due to it being a Harvard machine, you don't use RAM for every single native instruction. Marcel partially hid this by using the staggered clock arrangement.>> , you can find also in the datasheet that this kind in purpose clock skew is mandatory when using the 70ns SRAM by Gigatron, and not for the 55ns (when its not overclocked). Even though 50ns is too high for 100MHz, normally you would need less 10ns in one pipeline stage. It is possible on the internet to find 5ns or less if you want.

<<As for why I've suggested a ROM control unit as opposed to a combinational one (and shadowing this ROM to get <10 ns) is to make it easier to add more instructions.>> I am already using a ROM for the CU in Megatron (actually three, they are labeled CUROM in the breadboards image) mainly to gain a certain level of flexibility compared to the combinatory circuits, sadly, the EROMs I am currently using are too slow, they are 120ns.

<<Now, what would make that possible would be another set of index registers. So if you are doing 100 Mhz, you'd only need to write to the screen every 16 pixels. That isn't enough time for a vCPU slice. But, if you had an extra X and Y, you can keep both the video context and the vCPU context active at the same time.>> I agree, and I could add another proposition for decoupling more Gigatron from the VGA, an interrupt mechanism, I think it would be relatively easy to add one to Gigatron with a minimum of modification, also, it would be beneficial for other hardware/software tasks.

<<I read about doing a ROM-based ALU. I've thought of that for a long time. But in the example I found, they used a 16-bit ROM to do an 8-bit ALU.>> Gigatron uses the 74283 and a bunch of multiplexers for its ALU, and I personally used 74181 ALU, but in either case, they too slow for a 100MHz implementation, and in my knowledge, I didn't encounter any ALU IC faster than 10ns. Using a ROM like ALU seams the unique solution you have (aside FPGAs and PLAs).

<<they could sacrifice the Flag bits and have the upper half of an 8-8-18 multiplication there>> I didn't understand what means "8-8-18 multiplication" ?, normally if you need more inputs for a circuit, you just have to multiply the size of the ROM, for instance 21 bits address is 2M words, if you need 22 bits it is sufficient to use a 4M ROM (or using 2x2M ROMs)...and so on.

I made a typo on the multiplier comment. I meant 8/8/16 (A/B/Q). When you do unsigned multiplication on two 8-bit numbers, you can have up to a 16-bit result. I mentioned before about having a Flags register that would come from the upper 8-bits of 16-bit (data size) ROM that is shadowed in an SRAM. That could be where the upper 8 bits could be the upper 8 bits of the result and not be used as flags for multiplication. The Gigatron uses no flags at all.

I didn't mean to say the multiplication would result in 18-bits. I meant 16. But there is RAM with 18 data bits. Not as common, but presumably intended to be used as parity RAM, giving 1 extra bit per 8 bits. FPGA block RAM works that way. The minimum width that is committed is 9-bits whether you use them all or not. That could be useful if one wanted extra status lines. However, I don't think there is any ROM based on 9 or 18-bit word sizes.

I imagine fewer than 21-bits could be used with the ALU ROM. I don't see much need for 32 operations. I just like the idea the one used to emulate having a Carry-in line for a ROM-based ALU. While someone could sacrifice a line, go wider, or mess with decoders, another approach is instruction aliasing. So you can assume the carry-in operations (result+1) all the time, but omit a bit to use the ones that don't add 1 to the result. I'm not sure that ability is needed for a Gigatron, but I found this approach interesting.

The idea would be to take the system ROM, CU ROM, and ALU ROM and copy them each to SRAM on boot, then everything is done from SRAM. So the ALU would just be a LUT in RAM. The same speed could be used for all SRAMs.

I'm curious how you'd add hardware interrupts.

I'm not 100% sure I wish to build this, but finding parts would be an issue. I haven't found anything in the desired speeds in the denominations needed. You likely won't find faster than 7ns in async/SDR SRAMs. Once you go lower than that, the complexity of the SRAMs increases. You run into synchronous with more control lines and DDR/QDR, etc. Even the packages are harder to deal with (PLCC, BGA, etc).

Then another issue would be designing the board, let alone assembling it. Once you reach about 40-50 Mhz, crosstalk and so on might start to become a problem. Multi-layer boards with at least 1 dedicated power plane would be helpful, as would things like extra board fill. I don't know how extreme one would have to get such as staggering the lines between layers to make room for ground planes or anything like that. But I understand that designing for 100 Mhz parallel circuits will be a challenge. For instance, with hard drives, the PATA interface doesn't go past UDMA-133. For 150+ MTs, the industry switched to SATA.

The reason for the pipeline applies indirectly to VGA. I mean, the ROM is 70 ns. With the pipeline, it can go a maximum of 14 Mhz, if you can make the other stage that fast.

Really, I'd go the other way with a 4-stage pipeline. See, you have one to copy from the slow ROM, one for the control unit, one for memory access, and one for the ALU. If you can get all the stages to 7-10 ns, then you can do 100+ Mhz. So you could put everything in a ROM (the CU and the ALU) and have a circuit to copy it to the SRAM. So if you have 7-10 ns SRAM for the 2 main tasks, then you can go at 100+ Mhz.

Oh god, it had been a long time since I touched this project, but I have to finish it anyway. I remember the VGA was the main driving force in the hardware and software design of the Gigatron, and the reason of using the pipeline in the first place by the original authors, was to comply with the VGA specifications, and in my humble opinion had brought some complexity. My initial goal was to simplify the board and to reduce the component number for educational purposes, thus I decided to remove the VGA :), and use an independent display controller found inside the current small TFT screens.

Yes, I think it would be possible to approach 100 MHz using 4 pipeline stages, and using circuits faster than 10 ns. The slowest circuits for now are the ROM and the RAM, and it is absolutely possible to find faster components on the Internet, your idea is clearly a good and feasible idea, thank you for the advice.