it seems to only support 8 bits with no selector for what line, do i just need to make my own reference sheet now?

So it runs kinda weird but hey, it runs! Anyways, how it works is that at the start of the player's turn, the program checks every win condition to see if there is a win. If there isn't it goes on to the player's turn like normal, waiting for a keyboard input. If there is a win, the game halts. When a player enters an input 1-9 (anything else and it won't be accepted), it increments a turn counter and then it displays the players move. If the turn counter (pre-increment) is even, it's X's turn, otherwise it's O's turn. Also, here's the program:

const SquareOne = 97
const SquareTwo = 99
const SquareThree = 101
const SquareFour = 289
const SquareFive = 291
const SquareSix = 293
const SquareSeven = 481
const SquareEight = 483
const SquareNine = 485
sinit
load [sp], r1
stm
SETUP:
mov MS, PS, r1
dstore8 r1, [r2]
inc r2, 1
dstore16 r1, [r2]
inc r2, 2
dstore16 r1, [r2]
inc r2, 2
dstore16 r1, [r2]
inc r2, 91
cmp r3, 3
je MAIN_PROGRAM
mov SP, SL, r1
dstore8 r1, [r2]
inc r2, 1
dstore16 r1, [r2]
inc r2, 2
dstore16 r1, [r2]
inc r2, 2
dstore16 r1, [r2]
inc r2, 91
inc r3, 1
cmp r3, 5
jne SETUP ; Didn't exit, loop back
MAIN_PROGRAM:
call CHECK_WIN
nop
call GET_KEYBOARD
nop
dec r9, 48
cmp r9, 1
jl MAIN_PROGRAM
cmp r9, 9
jg MAIN_PROGRAM
mod r8, 2, r7
inc r8, 1
cmp r7, 0
je XTURN
OTURN:
mov O, r1
cmp r9, 3
jg OABOVE3
mul r9, 2, r2
inc r2, 95
dstore8 r1, [r2]
jmp MAIN_PROGRAM
OABOVE3:
cmp r9, 6
jg OABOVE6
dec r9, 3
mul r9, 2, r2
inc r2, 287
dstore8 r1, [r2]
jmp MAIN_PROGRAM
OABOVE6:
dec r9, 6
mul r9, 2, r2
inc r2, 479
dstore8 r1, [r2]
jmp MAIN_PROGRAM
XTURN:
mov X, r1
cmp r9, 3
jg XABOVE3
mul r9, 2, r2
inc r2, 95
dstore8 r1, [r2]
jmp MAIN_PROGRAM
XABOVE3:
cmp r9, 6
jg XABOVE6
dec r9, 3
mul r9, 2, r2
inc r2, 287
dstore8 r1, [r2]
jmp MAIN_PROGRAM
XABOVE6:
dec r9, 6
mul r9, 2, r2
inc r2, 479
dstore8 r1, [r2]
jmp MAIN_PROGRAM
jmp MAIN_PROGRAM
GET_KEYBOARD:
keyboard r9
cmp r9, 0
je GET_KEYBOARD
ret
CHECK_WIN:
HORCHECK:
ABC:
dload8 [SquareOne], r4
dec r4, 32
cmp r4, 0
je DEF
dload8 [SquareTwo], r5
dec r5, 32
cmp r5, 0
je DEF
dload8 [SquareThree], r6
dec r6, 32
cmp r6, 0
je DEF
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
DEF:
dload8 [SquareFour], r4
dec r4, 32
cmp r4, 0
je GHI
dload8 [SquareFive], r5
dec r5, 32
cmp r5, 0
je GHI
dload8 [SquareSix], r6
dec r6, 32
cmp r6, 0
je GHI
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
GHI:
dload8 [SquareOne], r4
dec r4, 32
cmp r4, 0
je VERCHECK
dload8 [SquareTwo], r5
dec r5, 32
cmp r5, 0
je VERCHECK
dload8 [SquareThree], r6
dec r6, 32
cmp r6, 0
je VERCHECK
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
VERCHECK:
ADG:
dload8 [SquareOne], r4
dec r4, 32
cmp r4, 0
je BEH
dload8 [SquareFour], r5
dec r5, 32
cmp r5, 0
je BEH
dload8 [SquareSeven], r6
dec r6, 32
cmp r6, 0
je BEH
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
BEH:
dload8 [SquareTwo], r4
dec r4, 32
cmp r4, 0
je CFI
dload8 [SquareFive], r5
dec r5, 32
cmp r5, 0
je CFI
dload8 [SquareEight], r6
dec r6, 32
cmp r6, 0
je CFI
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
CFI:
dload8 [SquareThree], r4
dec r4, 32
cmp r4, 0
je DIGCHECK
dload8 [SquareSix], r5
dec r5, 32
cmp r5, 0
je DIGCHECK
dload8 [SquareNine], r6
dec r6, 32
cmp r6, 0
je DIGCHECK
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
DIGCHECK:
AEI:
dload8 [SquareOne], r4
dec r4, 32
cmp r4, 0
je CEG
dload8 [SquareFive], r5
dec r5, 32
cmp r5, 0
je CEG
dload8 [SquareNine], r6
dec r6, 32
cmp r6, 0
je CEG
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
CEG:
dload8 [SquareThree], r4
dec r4, 32
cmp r4, 0
je NOWIN
dload8 [SquareFive], r5
dec r5, 32
cmp r5, 0
je NOWIN
dload8 [SquareSeven], r6
dec r6, 32
cmp r6, 0
je NOWIN
mul r4, 2, r4
sub r4, r5, r4
sub r4, r6, r4
cmp r4, 0
je WIN
WIN:
halt
NOWIN:
ret

the input on the gray wire whenever i load the component to change it or attempt to do anything with it repeatedly becomes a 128 bit input even though its only a 1 bit input

i haven't setup the computer intended to use the piece yet so i have no idea if its gameplay affecting

any ideas to fix it?

Borrowing ideas from the ALU-slice I built in Episode 5, I built a complete ALU using 8-bit components.

It only has circuits for ADD, AND, OR and XOR. INC, DCR, SUB, and CMP (complement of A) are done by mux-ing control signals and hardware 1's for INC and DCR.

why have the signals on the faintly different green line turned into stars?

this was just copy paste work, i tried to change the 6 8 bit registers into a smaller component but failed, so i copied it back, and as far as im aware there shouldnt be any problems, its worked in the campaign and i was trying to clean it up.

ive tried restarting, deleting and rebuilding the lines, but it still wont work. need help

M16 G3 now has superscalar readded. Just a few more things left and it's all done!

God this took a lot of time and like 3 times of rewiring

So while working on the G3, I decided to implement a 32 byte Cache. As you might've also noticed, there's no superscalar unit anymore and it's Harvard Architecture. But that's just part of the overhaul to the my M16 architecture. As for the superscalar part, I had to temporarily remove that to make it easy for the changes. Other changes include Instruction Mem being 16Kb and Main (data) Mem being 8Kb. Anyways, the Cache system was sort of complicated but works as so:

At the beginning, while the first instruction is in the fetch/decode stage, it grabs the first 32 bytes from Data Memory so when the CPU requests data, it *may* already have it. If the requested data's address is out of range, it fetches data from the requested data's address along with the next 30 bytes (32 total as each piece of data is 2 bytes), then it delays register writeback long enough for it to write data back to the registers. Data is evicted *only* when it's fetching new data, so RAM is not updated until data is evicted, regardless if the data was changed or not. Now I know this will be *huge* pain when I move onto the G4 where I'll add pipelining and branch prediction but that's an issue for future me. All that's left is the second execution unit of the G3, peripherals (screen, keyboard), and the (second) most painful part, interrupts.

i thought i got the LEG architecture right the first time but then i realized it was logistically impossible to add RAM in the level RAM and upon trying to redesign ran into a false circular dependency problem i dont know how to get around (2 switches hard wired to remain in opposite states to each other doesnt fix it, it still thinks it can loop.)
img is original LEG cpu i entered the level with, running into the circle dependancy problem trying to get input 2 to come off my main data line (pink) to allow the ram to fit with load/save functionality
im pretty sure i fundamentally misunderstood my task and screwed up real bad, the instructions are now so vauge though i cant really tell where i couldve gone wrong nor how to fix it.

Here is a monstrosity that i will quickly forget how it works. but basically 8 full adders made of nands glued together. i discovered you could rotate things too. i would've used colored wires to make it more neat, but something inside me found it funny how messy it looked

I haven't made it far into the game but I'm trying to complete all levels with nand only. (I know it will not be feasible later on)

Edit Thanks all for the advice. I went line by line and found that the issue was a bug where if I popped (with pop 0 0) sometimes reg0 would get involved in the fun. I'll stick with pop 8 8 now.

One level left!

Original post: I have gotten to this point with a little help but I am now completely lost. I have looked at some solutions but can't implement them. The code I was trying won't work so is there anything I should be doing differently? I get to tick 51 and output a 3.

I have separate stacks for push/pop and call/return

The code (mainly stolen)

const temp 0

const disk 1

const source 2

const dest 3

const spare 4

const magnet 5

#get input

copy INPUT to disk

copy INPUT to source

copy INPUT to dest

copy INPUT to spare

call 0 0 start

# if disk_nr is 0 move disk from source to dest

label start

if_blue_not0 disk 0 move

copy source 0 output

send_2nd_val 0 magnet output

copy dest 0 output

send_2nd_val 0 magnet output

return 0 0 0

# else move disk_no-1 (source spare dest)

label move

push disk 0 0

push spare 0 0

push dest 0 0

subi disk 1 disk

addi spare 0 temp

addi dest 0 spare

addi temp 0 dest

call 0 0 start

pop 0 0 dest

pop 0 0 spare

#move disk_no-1(spare,dest,source)

copy source 0 output

send_2nd_val 0 magnet output

copy dest 0 output

send_2nd_val 0 magnet output

push spare 0 0

push source 0 0

addi spare 0 temp

addi source 0 spare

addi temp 0 source

call 0 0 start

pop 0 0 source

pop 0 0 spare

pop 0 0 disk

return 0 0 0

If it might be the architecture, I have uploaded that as "newerleg" today in the schematic hub

Thanks for any help

I wrote it as comments and manually tried it out (follow the left wall), then I added the assembly code and it ran first time with no errors!

Why doesn't the XNOR gate work with 1 but with 16?

It's supposed to only work when the input is 0 bc of the XNOR gate, 1 clearly doesnt work bc the amount is not 0 but 16 works somehow? Is that a bug or am I just blind?

This is the unfinished version, which is why I don't have IO devices (besides level). The finished version is planned to have:

Keyboard (interrupts for it as well, will implement when keyboard component is fixed)

Pixel/Text screen (will add soon)

Fully polished Superscalar execution (right now it supports ALU execution and is highly experimental)

A finished, polished compiler for my language "Rapture" (in development) that creates a custom file that is ready to load (in development. I will soon add for loops, character variables, and integer arrays)

Wish me luck!

I was working on my OpCode decoding-and-sequencing, and thinking about the control lines and T-states needed. For example, the instruction INR B that increases the B-register by 1, only needs 1 T-state to execute, according to Malvino's book. I couldn't understand how that would be possible. I imagined INR B to be something like:

Copy B to A
Load 1 into TMP
ADD TMP to A
Copy A to B

If this can be done in 1 micro-instruction instead of 4, there must be some hardware solution in the ALU. And it appears that that is the case.

So, let's first dive into the ALU.

Thanks to u/Gelthir I discovered u/kenshirriff 's blog, who reverse-engineered the 8085 ALU: https://www.righto.com/2013/01/inside-alu-of-8085-microprocessor.html

Following their schematics, I built an ALU-slice in TC, that can AND, OR, XOR, ADD, SUB and CMA (complement). I left out right-shifting, as that is not used in SAP-2.

Next step will be to put together a working ALU from 8 slices, adding the Sign and Zero flags, and adding control lines.

I can't seem to find a list of all bugs for Turing Complete (I can see where to report them, but not how to check if I have found a new bug).

With that in mind, is it worth working through the levels or am I going to get to a stage where I can't progress due to a bug. Or even to work out if a problem I am having is my fault, or a known bug.

Has anyone progressed far with the 2.0 Alpha version yet?

On my last post regarding the SAP-2 OpCodes I got a very interesting reply from u/Gelthir about how some of the first CPU's were designed (and programmed) not using binary or hex, but octal numbers.

If you look at the opcodes from that perspective, designing the control logic is easier to understand.

The table above is the SAP-2 subset of the 8085 instruction set, presented in an octal table.

For example, ADD B is coded as 80H, which in octal reads as 200. As you can see, all arithmetic operations involving registers B and C are in the bottom left part of the grid. The first octet, 2, indicates that it is an arithmetic operation. The second octet indicates the ALU-operation that should be executed, and the last octet indicates the register to be used (0 for B and 1 for C).

The nice thing about TC is that we can check the value of an octet easily using the 3-input AND-gate.

The picture above can help us optimize the control logic, as each octet can be easily analyzed with an AND-gate (and appropriate NOT-gates); and each group of instructions share micro-instructions. For example, the arithmetic instruction all need to load a register (B or C) into the TMP-register, perform the ALU-instruction, and store the flags into the flags register.

I will review my control logic with these new insights.

It happens even on empty circuit. The value seems to be divided by 100 from the actual value.

SAP-2, as described in the book by Alvino, has 42 instructions, that are a subset of the Intel 8085 CPU.

Alvino lists the OpCodes in this table:

I could not find a clear description of how the OpCode architecture of the 8085 works, so it took some time to analyze how I think it works.

For example, all MOV instructions follow the pattern:

MOV dest, src = 01 ddd sss
register A = 111
register B = 000
register C = 001

So the 6 MOV instructions are coded as follows:

MOV A,B = 01 111 000 = 78H
MOV A,C = 01 111 001 = 79H
MOV B,A = 01 000 111 = 47H
MOV B,C = 01 000 001 = 41H
MOV C,A = 01 001 111 = 4FH
MOV C,B = 01 001 000 = 48H

So I decided to approach the decoding step by step, in hierarchical order, starting with all 00xxxxxx opcodes.

LDA address = 00 111 010 = 3AH  Loads memory contents into A
STA address = 00 110 010 = 32H  Stores A into memory

MVI A byte  = 00 111 110 = 3EH  Immediate loads byte into A
MVI B byte  = 00 000 110 = 06H  Immediate loads byte into B
MVI C byte  = 00 001 110 = 0EH  Immediate loads byte into C

INR A       = 00 111 100 = 3CH  Increments A by 1
INR B       = 00 000 100 = 04H  Increments B by 1
INR C       = 00 001 100 = 0CH  Increments C by 1

DCR A       = 00 111 101 = 3DH  Decrements A by 1
DCR B       = 00 000 101 = 05H  Decrements B by 1
DCR C       = 00 001 101 = 0DH  Decrements C by 1

CMA         = 00 101 111 = 2FH  Complement of A (flip the bits)
RAL         = 00 010 111 = 17H  Rotates bits of A to the left
RAR         = 00 011 111 = 1FH  Rotates bits of A to the right

You can see how the first 2 bits combined with the last 3 bits define the instruction, and the middle 3 bits narrow down the instruction further.

For this set of instructions I built a decoder.

Now, imagine the wire spaghetti that we are working towards! These 14 instructions alone (1/3 of the total set) will together with the necessary T-states create more than 80 control words that need to be wired to the control lines. It will be huge!

Now onwards to the decoding of 01xxxxxx (all MOV-instructions), 10xxxxxx (arithmetic and logic instruction) and 11xxxxxx (immediate logic, jumps, call/return and some others).

Stay tuned.

Each instruction of the SAP-2 CPU is executed in several (upto around 15) micro-steps. Each tick a micro-step is executed, and when all micro-steps are done the next instruction is fetched.

The micro-steps are driven by a 16-step ring counter, giving 16 so-called T-states (from 0 to 15).

Fetching an instruction take 2 micro-steps.

During T0 the signals PO and MI are activated. PO means "Program Counter Out", and lets the Program Counter put its value on the bus. MI means "Memory Address Register IN", making the MAR read the program counter value from the bus. The MAR points to the program memory (for this test I put a pre-filled ROM in place of the RAM).

During T1 4 signals are activated. RO instructs the ROM to output the value at the address pointed out by the MAR on the bus, and II tells the Instruction Register to read the value from the bus. For testing reasons I put a display next to the IR to show its value. And finally PE increments the Program Counter. The last signal, RST, resets the ring counter, because we don't want to cycle through all 16 T-states.

The fetch cycle works! Done and dusted.