You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tested on Minecraft 1.20.1 with Fabric Loader 0.14.22 and no mods other than dependencies.
When a MOV instruction outputs to a port, it visually takes 3 ticks to complete and the instruction after it appears to be skipped (though it still executes internally). When it's the last instruction in a program, it actually does take 3 ticks before looping around, which is 1 tick more than usual.
I'm not sure if the latter should be fixed (it feels like a realistic quirk), but I'm documenting it here in case it causes an issue for anyone else.
In this example setup, I expected the execution modules to stay perfectly synchronized, outputting ABABABAB.... However, due to the above behavior, the bottom-right one loops every 5 ticks instead of 4, making the output ABABAABABA.... (In this case, moving one of the NOPs to the end keeps the modules in sync.)
The text was updated successfully, but these errors were encountered:
In fact, each TIS-3D cycle has two stages, first it will run modules and then it will transfer data. For MOV a immediate number to a port, it will be executed like this:
Cycle1:
load instruction to exec module
start transfer data (or be blocked then wait at here)
Cycle2:
other modules read data
exec module increase its PC (not in exec module's method,in instruction's callback)
But, the devs seems to forgot update the PC indicator to client at the callback method above. So exec module will load and execute another instruction , then update its state to client at exec module's method. PC will add 2 in this sequence.
Also, if this unchecked PC increasement is located at the end of program, it will let the PC overflow, then exec module will read a null value and cost 1 cycle to set the PC to 0.
Tested on Minecraft 1.20.1 with Fabric Loader 0.14.22 and no mods other than dependencies.
When a MOV instruction outputs to a port, it visually takes 3 ticks to complete and the instruction after it appears to be skipped (though it still executes internally). When it's the last instruction in a program, it actually does take 3 ticks before looping around, which is 1 tick more than usual.
I'm not sure if the latter should be fixed (it feels like a realistic quirk), but I'm documenting it here in case it causes an issue for anyone else.
In this example setup, I expected the execution modules to stay perfectly synchronized, outputting
ABABABAB...
. However, due to the above behavior, the bottom-right one loops every 5 ticks instead of 4, making the outputABABAABABA...
. (In this case, moving one of theNOP
s to the end keeps the modules in sync.)The text was updated successfully, but these errors were encountered: