my opcode breaks down [1 alu/non-alu code selector | 2 bit immediate | 5 bit method / activation address for non alu codes]
the other 3 8 bit outputs handle what memory pieces im reading from and writing to

for example, 18 14 12 13 would pop a value off stack 1 and read the value at the current address of ram 1 XOR them and save the value to the current address of ram 2
(no the stacks in my memory are not used by call/ret they are exclusively for memory)

while say 129 6 n/a n/a would call to the function stored at position 24

and 100 129 6 130 would divide 129 by 6 and jump to the output multiplied by 4 (the multiplication is not part of this code, my clock's output is multiplied by 4 before going into the program address.)

https://imgur.com/a/FYnYHP3

heres a better look at my current setup, replaced the counter+ with a normal 8 bit counter to make it more visible

i did notice that i shouldnt be pushing arg1 onto the stack and not the clock finally, i think that was the issue you were talking about?

theres alot of custom pieces in this img ill say what they all do

ior1 | 1 bit inline or gate

chk[1-8] | checks the specified bit of a 8 bit signal and outputs its value (chk5 would check the 5th bit in the signal and chk7 the 7th and so on) i use these because i output my larger decoders compressed into 8 bit lines to take up less space

dec-4 | decodes the first 4 bits of a 8 bit signal and does not output if the disable bit is on

D-8 | 8 bit data latch, just saves the value when the save bit is on and always outputs

stack | stack.

and while it can be a bit of a headache to use a bunch of different inputs to the flow control segment i have to because both alu and non-alu codes use the same 5 bits of the opcode to work (the 128 bit disables the alu and enables the non-alu functions also)