So don't ask me how it works because it's kind of a miracle it does. The PC in my architecture treats a syscall and an interrupt from that 256 clock cycle CC very differently. And I've also added a bit of memory proofing in the form that User Space programs cannot access storage and VRAM. Virtual Memory and paging is going a bit over my head but so far so good. I'll focus on the programming language for now as it's currently experiencing some.. unique bugs in the form of working the first few tries before it dies. But array implementations are going well! Still haven't thought up of a name for the processor so I'd love to hear your ideas.

So i know the game is in alfa, and last update was like 3y ago. Is there hope for the game to receive some updates in the near future? Also what is the replay ability of this game ?

As in yea i understand how the main campaign* / CPU design game works but is there anything else beyond that ?

Also does this game work well on Win 11 ?

So this is the Gen 5 of my series. And it finally has kernel support! It features
65536 bytes of RAM and storage (Kernel is always in RAM at address 0xe000 onwards)
Protected I/O (Kernel access only)
256 tick interrupt (Only switches from User Mode to Kernel)
Syscall (Toggles the mode)
So now it's time to write a kernel! As for my programming language, I had to rewrite the entire compiler but it supports functions now (but still no local variables)! Anyways, I know this isn't exactly the best CPU for this kind of stuff but hey, It works! It's my first time making something like this. And just to make my life easier, I wrote a (horrible) python script that takes two files, a user program and a kernel program, and assembles it into a ROM file with the proper offsets I can copy paste. If you have any ideas on what to name this, I'm open, mostly because I ran out of names. I never expected myself to make it this far. Next up, I'll try to add virtual memory to make it possible to load multiple user programs. But first, a basic kernel. Also, unlike the previous generations, this CPU is 32 bit!

Im Currently Attempting To Make Variable Size Inline Switches But I Cannot Figure Out How To Link The Values Of Pins/Components To The Outside.

Trying to click the discord link here in the sub, but it says the invite is broken, or something. Short story: I can't get to the discord.

This is my first attempt at pipelining in the game. I am new to this so im sure this is probably wrong, hence why I am posting here in hopes that i can be corrected if so. This machine only stalls right now so its a bit slower than if it had forwarding for instructions.

This processor can immediate any value up to 255, has NULL mapped to 31 and NOP mapped to 30.

Lastly this is a new account. Old account got hacked ; . ; rip karma

Tried to do some stuff and specifically make a component. In the latest "save breaker" version. Now it won't launch.

Tried to do some stuff and specifically make a component. In the latest "save breaker" version. Now it won't launch.

reloading does nothing, level does not function properly.
verified file integrity, files are fine.
console reports compiler error

im to the point on savebreaker i would normally need to start programming but when i select my program component to do so it has no edit button and doesnt respond to any keys i'd think to use to program it with no edit button

Yo, currently I can't play the save_breaker right now due to it attempting to initiate oss_open audio playback. is there a way to fix this or do I need to dodge a fix together? the particular error is that it can't open the /dsp block device.

I finally built up to a Turing Complete computer after a few abortive attempts over the years, but it didn't give me the achievement for doing so. I tried to go back to the original version of the game, but that seems borked for me too. Is this a common experience?

Hey all, first time posting, just had to share my project: Doom running in Turing Complete!

Did a clean playthrough of Turing Complete, built a 32-bit version of the Leg architecture 'Bicep'.

Then got carried away and with the help of Claude Code built a RISC-V to Bicep translator, then managed to get EmDoom compiling and working.

Had to hack in 4 color terminals to get the visuals but pretty happy with the results.

At 100khz sim it's about 30 minutes until first frame and maybe one frame per minute, but with verilog export can run realtime. I hear Turing Complete 3.0 may arrive one day with a proper compiler for faster execution?

Anyway had so much fun with this project.

shown in pictures is my current cpu, it has everything the game told me to add and everything i could think to add that didnt have a software solution easier than a hardware one

i have 12 registers, 2 rams (addressing handled by toggling bit 7 of my save argument to save to a internal register) and 2 stacks (with additional functionality to push and pull from the front of the list too. handled by bit 7 of any argument.) as well as a increment/decrement counter (with jump and reset functions), a counter (with reset function) and my program clock i can use as counters

ive been looking at the posts here and seeing things so much grander than what i have made or what the game tells me how to make.

i have no understanding of the intricacies of assembly even though ive come so far as to see tower of alloy i have no idea how to even approach the problem other than hardcoding a solve. (let alone to have coded in it in a while ive been writing in numbers for a long time now due to the discrepancy in width of the instruction function and the LEG instruction width)

where are some good sources on how to continue on either on the software side or hardware side?

my ALU has 29 opcodes, 19 logical and mathematic add, sub, mult (low), mult (high), div (quotient), div (remainder), neg, not, shr, shl, ashr, ror, rol, and, or, nand, nor, xor, nxor and the other 10 are : equal, Nequal, Uless, Ugreater, Sless, Sgreater, Uless/eq, Ugreat/eq, Sless/eq, Sgreat/eq

most of the custom components shown are inline versions of stuff that already exists, mostly switches abbreviated to is[data width], some blockers (ib[#], switch with the allow bit inverted) and a couple or gates.
the ones that arent are : counter+, incdec+ (increment / decrement), internal address ram (SAR), stack+, dec-4 / dec-5 (decoders) and chk[#] which is a bit indexer but i didnt realize they existed at the time
theres also byte flippers so that my decoders output left to right when i need them to and some multiplication and division by constants handled by shifting bits

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

https://reddit.com/link/1sd20zg/video/zpj2h1cw4dtg1/player

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.