I like it, when everything works as expected: I've just executed my 1st ALU instruction! The ALU is the most important part of the CPU, because all calculations are done with it. Most of the time when you execute assembly instructions, these assembly instructions are related to ALU operations.
The ALU instruction has the following opcode format: 1000FFFF
The FFFF is the 4-bit opcode that defines which ALU function is executed - so I have 16 functions available:
- 0000: NOP
- 0001: XOR
- 0010: OR
- 0011: AND
- 0100: ADD
- 0101: NOT
- 0110: SHL
- 0111: ADC
- 1000: SUB
- 1001: NEG
- 1010: RCL
- 1011: SHR
- 1100: SAR
- 1101: RCR
- 1110: MOV8 (converts 2 nibble values - each 4 bit long - into a 8-bit value)
- 1111: SBB
But I've encountered the following interesting "problem": The 4-bit ALU opcode is taken from the instruction register and transferred into the ALU, where a 4-to-16 decoder generates the correct control signal. But when the instruction register is in the high impedance state (disconnected from the ALU), I'm getting a 1.6V value into the ALU, which the 4-to-16 decoder interprets as a logical 1.
Therefore the ALU works always, and gives me always a 11111111 result (which is transferred back to the data bus), because the A and B input registers are also in the high impedance state.
So I have to add a simple control line (ALU operation - yes/no) to the 4-to-16 decoder, so that the decoder only enables a control line if a ALU instruction is executed 😉
Stay tuned!
-Klaus
