New native instructions
I did not realize this was possible until a couple day ago when I finally found the time to fix my flawed extended memory banking scheme (see
https://forum.gigatron.io/viewtopic.php?p=2838#p2838). This fix required lots of changes: the extended ctrl codes, the verilog, the rom, the demo programs, and even the compiler which gained support to place vCPU routines in specific memory ranges, which can be useful when one swap memory banks. Then I realized that when a ctrl instruction is executing --which I know because the SRAM signals /OE and /WE are both low--, I can also see the value of the AC register on the ALU pins of the output register. This happens because ctrl() is just a st() instruction in disguise.
This gave me the idea to extend the set of native operations in order to provide direct access to the whole 512K ram instead of banking things around. To do so, I am stealing parts of the extended ctrl code space that cannot be used from vCPU because the SYS_ExpanderControl call clears the low two bits of the ctrl code. Since all usable extended ctrl codes end with 0000, we can use 0001, 0010, and 0011 for additional opcodes.
The current CPLD program (see
https://github.com/lb3361/gigatron-lb/b ... /rtl/top.v, only 314 lines) implements a new Z register and a couple new native instructions.
Code: Select all
ENCODING OPCODE DESCRIPTION
C141/ctrl(0x41) -- no operation
C1*2/ctrl(0x*2) ld(*,Z) load immediate * into register Z
C151/ctrl(0x51) ld(AC,Z) copy AC into register Z
C961/ctrl(Y,0x61) ld(Y,Z) copy Y into register Z
C171/ctrl(0x71) ld(V,Z) copy three upper bits of the current video bank into Z,
using AC<7> to decide whether targeting even or odd pixels.
But how then do we use the register Z? Well, we use prefix instructions that change the addressing mode of the next Gigatron opcode which can be a load or store. For instance, instruction ld([Y,X]) becomes ld([Z,Y,X]) which uses bits from the Z register to form a large enough address to access all the RAM as a big linear space. More exactly the prefixes change the addressing mode of the next instruction as follow:
Code: Select all
[d],AC --> [Z,0,d],AC
[X],AC --> [Z,0,X],AC
[Y,d],AC --> [Z,Y,d],AC
[Y,X],AC --> [Z,Y,X],AC
[d],X --> [Z,0,d],X
[d],Y --> [Z,0,d],Y
[d],OUT --> [Z,0,d],OUT (load only)
[Y,X++],OUT --> [Z,Y,X++],OUT (load only)
[Y,X++] --> [Z,Y,X++] (store only)
The prefix instruction are the same as the instructions above with an additional bit that indicates that the addressing mode
of the next executed instruction must be changed.
Code: Select all
ENCODING OPCODE DESCRIPTION
C1c1/ctrl(0xc1) far() prefix for next insn
C1d3/ctrl(0x*3) far(*,Z) same as ld(*,Z) + prefix
C1d1/ctrl(0xd1) far(AC,Z) same as ld(AC,Z) + prefix
C9e1/ctrl(Y,0xe1) far(Y,Z) same as ld(Y,Z) + prefix
C1f1/ctrl(0xf1) far(V,Z) same as ld(V,Z) + prefix
All this seems nice but is far from being tested. I wrote the new CPLD program and checked that the Gigatron still runs normally. I have to write a native SYS call to exercise these new opcodes and see how well this works. Overall I am quite confident except for the ld(AC,Z) instructions because I am not sure the ALU has already produced AC when I process the ctrl() instruction. The next step is to update the native assembler to understand things like adda([Z,Y,0x23],X) and generate the correct program. We could then provide new vCPU instructions that work with the large linear address space. Or maybe convince at67 to have a look at this
The CPLD is now 94% full with 9/144 macrocells remaining. What can we do with these?
[
Update] - Going from 6 bits audio to 8 bits audio takes two more macrocells. Let's see whether it helps.