Opcode mods

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply
PurpleGirl
Posts: 30
Joined: 09 Sep 2019, 08:19

Opcode mods

Post by PurpleGirl » 22 Nov 2019, 01:01

In the past, I mentioned a way to use a spare NOP as a way to signal an external device, such as resetting a video circuit if you don't know the state. You could make a crude decoder to NOR the pins that are supposed to be off and AND them with the ones that belong on for your instruction. The NOPs do nothing, so they can trigger outside devices. Just leave one NOP as it is.

But then last night, an idea came to mind. There could be a way to expand the opcodes to have other instructions. Use 2 NOPs to do shifting. So one NOP switches in other control circuitry and another switches the original circuitry back. Thus a group of opcodes can do different things when shifted. Just save the ones used by video and the most commonly used IP-related instructions (like branches).

User avatar
marcelk
Posts: 400
Joined: 13 May 2018, 08:26

Re: Opcode mods

Post by marcelk » 22 Nov 2019, 07:11

The processor has no chips with hidden state. Therefore with the right programming and sometimes some extra decoding logic, you can trigger external devices from practically any signal on the board. There are many examples out there that do just that.

The XOUT register is a good example. After all, XOUT is an external device to the processor. The RAM and I/O expander is another good one, but it needs 3 new chips. A third example is how we used A15 to drive an LED in one of the first breadboard videos.

You can also use 3 output pins from XOUT to drive a chain of 74HC595 shift registers. That gives an unlimited number of output lines, 8 for each in the chain.

HG has designed a completely different decoding scheme (but not built it yet). I believe it's even part-neutral.

Anything goes.

PurpleGirl
Posts: 30
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 22 Nov 2019, 20:24

Yeah, I thought the concept of CPU escape sequences would be interesting. So intercept 2 of the unused NOPs and piggyback onto them. One of them switches out some of the control circuitry to allow for opcodes to be recycled to add additional functionality. The other piggybacked NOP switches the original circuitry back in and returns all opcodes back to their original functionality. Of course, besides the components, the cost would be 2 cycles, 1 for setup and 1 for cleanup. Plus it could make code a tad more confusing. So it would look a bit like this.
  • ALT NOP 1; enter alternative opcode set
  • New instructions that duplicate opcodes, perhaps 32 of them or some other even group of 16.
  • "
  • "
  • ALT NOP 2; return to original instructions
Some caveats would be not interfering with anything used by the video, the program counter, or any "interrupts," and the added functionality should justify the cost of changing modes/contexts. Plus the branch quirk would need to be taken into account when coding to not run the affected opcodes in the wrong context after a branch.

This idea is nothing new. The x86 processors did this. For instance, to do MMX and similar on the Pentium, they swapped out the entire FP set. The setup was costly to use the new multimedia or signal processing instructions. So programmers would make sure that the performance gained by the newer instructions would justify changing modes. Even for DOS programming, you could use the new 32-bit instructions of 386 and higher CPUs in real mode. They used an escape sequence to use the new instructions.

Post Reply