While I may never try this, I just got a brainstorm from the 512K thread and Jeff Laughton's KimKlone.
https://laughtonelectronics.com/Arcana/ ... intro.html
A point raised in the 512K thread was that most ideas discussed over the years could be realized through the RAM and output register sockets. I pondered that other ideas could be realized by tapping the ROM and the accumulator. For instance, a coprocessor to add shifts, multiply, more registers, etc. could sit in the ROM and Ac sockets. That could be a way to add a discrete stack with its own SP and all. One could put new registers on such a board and easily copy to/from the Ac. As for interacting with the other registers, such a board could intercept and substitute the new instructions with immediate instructions. So moving from a 2nd accumulator or a W or Z register to X or Y could be a matter of the coprocessor board running the instructions in tandem with the Gigatron performing an immediate operation to X/Y.
That idea comes from Jeff Laughton's KimKlone which added an "exoskeleton" CPU wrapper that intercepted the undocumented opcodes of the 65c02. For some things, it just intercepted the opcodes and acted upon its own registers. They were already NOPs, so the CPU ignored those anyway. For other things, it would act on the opcodes and substitute what went to the 65c02 to work synergistically with it.
So one could do something similar with the Gigatron if they wanted to. So if you wanted to add extra registers, intercepting the ROM and the accumulator would be enough for most tasks, and if you want to move from new registers to X/Y, the board could change the opcodes to store immediates while using the original opcodes for itself. For other instructions, the board could perform the new instructions while forwarding a NOP to the Gigatron. It wouldn't even have to be the most elegant since it could send "dirty NOPs" with random "garbage" in the operand byte. And this board idea could even be used to apply my idea of a secondary ALU where unused immediate space could do things SIMD/"VLIW" style. And all of these changes would need a new ROM.
If a ROM board adds an upper index register, one could make a RAM board or a combined I/O and ROM coprocessor board and have a bus from a new native register to more RAM address lines. That might be more elegant than using command sequences to do similar.
Tapping the ROM
Forum rules
Be nice. No drama.
Be nice. No drama.
Tapping the ROM
Last edited by Sugarplum on 13 Feb 2022, 19:21, edited 1 time in total.
Re: Tapping the ROM
I didn't know about the KimKlone work.
The 512k extension only taps the RAM and the output register which can be used to peek at the ALU output.
Contrary to a 65C02, the Gigatron implements a Harvard architecture. Tapping the RAM does not reveal the instructions being executed. The only one we can detect is the CTRL instruction because it asserts both OE and WE during the second half of the cycle. Surprisingly this was enough to implement instructions that access a larger linear space, just like the KimKlone. Tapping the ROM would essentially allow pretty much anything. Besides hacking the processor, it would also allow for copying a slow flash rom into a fast SRAM, allowing ROM reprogramming on the fly. But frankly this is getting too far from the original for me.
The 512k extension only taps the RAM and the output register which can be used to peek at the ALU output.
Contrary to a 65C02, the Gigatron implements a Harvard architecture. Tapping the RAM does not reveal the instructions being executed. The only one we can detect is the CTRL instruction because it asserts both OE and WE during the second half of the cycle. Surprisingly this was enough to implement instructions that access a larger linear space, just like the KimKlone. Tapping the ROM would essentially allow pretty much anything. Besides hacking the processor, it would also allow for copying a slow flash rom into a fast SRAM, allowing ROM reprogramming on the fly. But frankly this is getting too far from the original for me.
Re: Tapping the ROM
That's why I said to tap the ROM and the accumulator since it's a Harvard arch. Tapping both ROM and RAM would give the most additional instructions. When registers other than Ac (since I propose tapping that too) are used, the instructions could be replaced on the fly on the Gigatron side. So if you want to copy between a new register and X/Y/Out, then use immediate instructions with the new board choosing the operand. So a new register or new ALU could pass things as operands to an "immediate" instruction, well as writes.
Tapping the RAM for various instructions would be okay if you wanted a vCPU coprocessor.
As for the control sequence. There are 8 opcodes that assert both control lines.
So you could add more memory lines from a board intercepting the ROM. The new native instructions would manage their own register and directly provide an extra memory bus. The rest of the Gigatron would not be the wiser.
There are ways around timing problems with intercepting the ROM such as shadowing into fast SRAM on boot and maybe clocking that board twice as fast. So fast multiplication, shifts, RNG creation, and more registers could be possible this way. That would be good for testing a new Giga-similar machine with new instructions.
If doing the 100 Mhz version I've proposed, I'd likely get rid of asserting both /OE and /WE and add a 3rd control line. That would be faster and would make things easier when adding I/O expansion compatibility. If the control lines are in LUTs, then directly producing a command signal would be faster than a NAND/AND to join the lines, assuming an extra line can be spared.
This could be a way to add some FP instructions too. Like an unused instruction could be used to access an FP register file with the original operand selecting the address, and then on the Gigatron side, it becomes a store from immediate, and the new register file contents would be passed at the address given as an immediate using a replaced instruction to whatever Gigatron register as an immediate instruction.
Tapping the RAM for various instructions would be okay if you wanted a vCPU coprocessor.
As for the control sequence. There are 8 opcodes that assert both control lines.
So you could add more memory lines from a board intercepting the ROM. The new native instructions would manage their own register and directly provide an extra memory bus. The rest of the Gigatron would not be the wiser.
There are ways around timing problems with intercepting the ROM such as shadowing into fast SRAM on boot and maybe clocking that board twice as fast. So fast multiplication, shifts, RNG creation, and more registers could be possible this way. That would be good for testing a new Giga-similar machine with new instructions.
If doing the 100 Mhz version I've proposed, I'd likely get rid of asserting both /OE and /WE and add a 3rd control line. That would be faster and would make things easier when adding I/O expansion compatibility. If the control lines are in LUTs, then directly producing a command signal would be faster than a NAND/AND to join the lines, assuming an extra line can be spared.
This could be a way to add some FP instructions too. Like an unused instruction could be used to access an FP register file with the original operand selecting the address, and then on the Gigatron side, it becomes a store from immediate, and the new register file contents would be passed at the address given as an immediate using a replaced instruction to whatever Gigatron register as an immediate instruction.