# Lets code a little 2

A project log for NEDONAND homebrew computer

NEDONAND is 8-bit homebrew computer entirely built out of many 74F00 chips (2-input NAND gates)

ow let's code with remembering the fact that we have a pipeline with 2 stages. 3/4 of all instructions (with codes 0xxxxxxx and 10xxxxxx) use only 1st stage, because ALU is doing nothing when they executed - it's A=n, R=~R and R1=R2 including G=R that does jump to new value of program counter (I'm not sure yet about RST/RET and SAEFF/SANFF). Other instructions (with codes 11xxxxxx) use ALU so they took 2 cycles to work and because of that we may have some situations which require special treatment (with special circuitry around). For example, this is subprogram of 16-bit increment:

```0) A=E ; no ALU involved on the next step
1) A=A+1 ; ALU will be used on the next step
2) E=A ; copy A to E, but in the same time ALU will change A
3) A=D ; no ALU involved on the next step
4) ADC 0 ; ALU will be used on the next step
5) D=A ; copy A to D, but in the same time ALU will change A
```
ALU instructions are on 1 and 4 steps. On steps 2 and 5 we have a conflict - A used and modified in the same time. So proposed solution is modify execution of such copy instruction in place - for example here E=A will turn into E=ALU & A=ALU (both registers get ALU output) and D=A will similarly turn into D=ALU & A=ALU. But what if two ALU instructions with A as an argument used one after another:
```0) RRC A ; on the next step A shifted right
1) RRC A ; on the next step A shifted again (new A stored?)
2) RRC A ; on the next step A shifted again (new A stored?)
3) ... ; here new A stored as a result of previous ALU instruction```
Here we have a little conflict, because A will be copied in the same time when it's buffered for ALU - some tricky circuitry should be done in order to fix it. Slightly different situation when we set or clear flag C before ADC and SBC command - everything should work automagically (with flags at least). Another conflicting pair of instructions that will be widely used to calculate AND:
```0) NAN B ; on the next step ALU should calculate ~(A&B)
1) A=~A ; here A must be inverted and stored from ALU in the same time
```

In this case we should execute storing to A - not direct, but inverted! Next one - what if A is modified immediately after instruction with ALU? For example:

```0) NAN B
1) A=B```
Here ALU output must be ignored (only flags will be used). Accumulator will get value from B at the end on step 1 and not ~(A&B). But if it's direct modification of F:
```0) NAN B
1) F=0```
then most likely we should use flags from ALU, but PC-bits from instruction...

## Discussions 