SHENZHEN I/O

SHENZHEN I/O

View Stats:
logical questions - flip flop & mining zone edges
Having trouble figuring two things out, so I thought I'd ask them here

1: What determines which side of a flip flop (Two negator ver) is lit before any input is applied? How do I influence what it will be at the start of a verification test, besides sending direct input with a specialised microprocessor on the first cycle?


2: For the thorium mining unit, if an x/y value is on the edge of two areas, what's the logic for determining which it will be counted as? Where would x = 60, y = 40 end up?
Originally posted by thewifiwhisperer:
I learned that Runs 18, 28 and 65 start with "hit" being lit (output 100).

(simply connected an MC with the following code and set a break point (command-click on Mac) on the conditional)

mov p1 acc
teq acc 100
+ teq acc 100 ! <- breakpoint
slp 999

respawn (and therefore alive) is lit on runs 12,14,15,17,26,32,33,34,43,49,50,58,62,63,64,74,78.

Now the challenge here becomes one of "steps". the order of operations *within* a advance... I think that throws you off.

No idea hiow the bridges come into action.

[edit to update]
I think the problem is in the respawn/alive issue, because you always start out dead.

Note: using your photo, I could not pass the test, since you should always start out dead, but that setup (and what I guessed is on the right) always started out "alive".

Then using an MC to force a "hit" signal on the first turn would work, until I hit run 12, where I cannot distinguish the signal from the respawn from the alive state that your setup always starts with.

Hope this helps, so far?


[another update]
I could reliable reproduce the placing of the bridge(s) influenceing the start state. (3 bridges seemed to do the trick for me). This appears to me to be a pure bug, and I don't say that lightly, at all. You can try mailing Zachtronics. (Do note that they're technically defunct.)

I guess something decides where the top or the bottom "inverter" gets triggered first, and it's different on the second run due to... something.

And for that I applaud you. I think this is one of the very few, if not the first time, that I've seen someone report a legitimate bug for Shenzhen's logic!

Since it seems to revert on the 2nd run, I'd call the situation where you don't have any of the superfluous bridges installed (I get 0 on the "hit" side, and 100 on the alive/respawn side) the canonical situation and the one to solve. (I couldn't think of a quick way to solve it for run 12)

[last update]
I switched the direction of your inverters, top one arrow points left, bottom has the arrow pointing right, and I managed to get through the first 2 runs (it started me off dead), and then on the 3rd run, which has exactly the same start state as the other runs, it starts me off alive.

To confirm: I think it's a bug. You'll have to solve this one without a "flip-flop" (I don't doubt that you can).
< >
Showing 1-10 of 10 comments
mala 5 Jan, 2024 @ 3:36am 
1: (if i got the question right) The initial state of a flip flop is undefined, and depends on the physical implementation. Usually, if a specific state is required, you need to apply some kind of input to reliably achieve it.

2: looking at my solutions, zones are split in:

x: 0-19, 20-39, 40-59, 60-79, 80-100
y: 0-39, 40-79, 80-100

so, x = 60 and y = 40 should be the first point (lower left) in the 80 power zone
Thank you! That saves me so much time debugging all the zones individually.

What are the factors in physical implementation that the flip-flop? On the laser tag level, I'm using a flip flop to track the life state, and can seemingly change it to default to the dead state by moving the majority of parts (Or adding a bunch of useless bridges) so that their tops are at the same level of or above the top of the flip flop. That works for the first test, but after reset for the second test it defaults to the alive state.
mala 5 Jan, 2024 @ 3:23pm 
mhhhh never been a circuit guy, my answer was based on what i remember about physical flip flop. Not even sure how your diagram is supposed to work. If you search google for "flip flop initial state" you'll find some answers about the initial undefined status of the circuit, something about clocks and voltage, and the chance for an output to be 1 or 0 is basically 50-50. Maybe, being a videogame, you could set up a latch to have a predictable initial state
Ah, thank you anyway. Have a good day!
thewifiwhisperer 8 Jan, 2024 @ 11:32am 
I've never seen such a construction before. The bridges *should* not influence that at all...

I'll do some experiments and let you know what I find.
The author of this thread has indicated that this post answers the original topic.
thewifiwhisperer 8 Jan, 2024 @ 11:48am 
I learned that Runs 18, 28 and 65 start with "hit" being lit (output 100).

(simply connected an MC with the following code and set a break point (command-click on Mac) on the conditional)

mov p1 acc
teq acc 100
+ teq acc 100 ! <- breakpoint
slp 999

respawn (and therefore alive) is lit on runs 12,14,15,17,26,32,33,34,43,49,50,58,62,63,64,74,78.

Now the challenge here becomes one of "steps". the order of operations *within* a advance... I think that throws you off.

No idea hiow the bridges come into action.

[edit to update]
I think the problem is in the respawn/alive issue, because you always start out dead.

Note: using your photo, I could not pass the test, since you should always start out dead, but that setup (and what I guessed is on the right) always started out "alive".

Then using an MC to force a "hit" signal on the first turn would work, until I hit run 12, where I cannot distinguish the signal from the respawn from the alive state that your setup always starts with.

Hope this helps, so far?


[another update]
I could reliable reproduce the placing of the bridge(s) influenceing the start state. (3 bridges seemed to do the trick for me). This appears to me to be a pure bug, and I don't say that lightly, at all. You can try mailing Zachtronics. (Do note that they're technically defunct.)

I guess something decides where the top or the bottom "inverter" gets triggered first, and it's different on the second run due to... something.

And for that I applaud you. I think this is one of the very few, if not the first time, that I've seen someone report a legitimate bug for Shenzhen's logic!

Since it seems to revert on the 2nd run, I'd call the situation where you don't have any of the superfluous bridges installed (I get 0 on the "hit" side, and 100 on the alive/respawn side) the canonical situation and the one to solve. (I couldn't think of a quick way to solve it for run 12)

[last update]
I switched the direction of your inverters, top one arrow points left, bottom has the arrow pointing right, and I managed to get through the first 2 runs (it started me off dead), and then on the 3rd run, which has exactly the same start state as the other runs, it starts me off alive.

To confirm: I think it's a bug. You'll have to solve this one without a "flip-flop" (I don't doubt that you can).
Last edited by thewifiwhisperer; 8 Jan, 2024 @ 12:27pm
Originally posted by thewifiwhisperer:

........
(simply connected an MC with the following code and set a break point (command-click on Mac) on the conditional)

mov p1 acc
teq acc 100
+ teq acc 100 ! <- breakpoint
slp 999

respawn (and therefore alive) is lit on runs 12,14,15,17,26,32,33,34,43,49,50,58,62,63,64,74,78.
............
Thank you, but that's not what I was struggling with. I had already set up a situation like the screenshot except with a processor to start it as dead. However, I wanted to see if I could save that 3 yen by shaving that processor away. I couldn't move it to a different chip though, as all my other ports were busy.

Without the influence of an external >50 signal, the flip-flop initialises to either the left (State signifying being dead) or right (State signifying being alive) wire being active. I tinkered around and figured out that it wasn't RNG, and that I could control which one it would land on by moving parts around, and adding/subtracting parts (all those bridges into nowhere). With just the bridges, I was able to get it to start on the dead side for the first test without spending anything, but only for the first test. I haven't been able to get it work for both yet, and I can't check any beyond that.

I was wondering if anyone knew what the actual logic behind it was, and if it was possible to initialise as dead for every test without outside signals, as I had been trying to do.
Video demonstrating reliability, effects of changes, and test #2
https://youtu.be/NxUSDb9oAes
Oh, I'm sorry, completely misread your post. Thank you for the help!
Last edited by top (f(f(f x))) λ calculus fan; 8 Jan, 2024 @ 2:36pm
< >
Showing 1-10 of 10 comments
Per page: 1530 50