Is this a bug? or am I just missing something?

[Big Fat Travis]

So I've played for a couple hours now and I got to the part where you get a bit of a sandbox mode to make a "game."

While I was screwing around with some of the new toys they gave me, I noticed an issue that only seems to manifest when the simulation speed is turned up. Basically I have a N4PB-8000 (The WASD-IJKL button module) hooked up to a MC6000 through the x3 pin, and I have an FM blaster plugged into x0. The code I'm using in the MC6000 is

mov x3 dat
tgt dat 0
+ mov x3 acc
+ mul -10
+ mov acc x0
slp 5

So the idea is that you press a key, it sends the corresponding number to the the processor, multiplies it by 10 and feeds it into the FM blaster to make a neat little sound. I'm multiplying the numbers by -10 because they came in negative for some reason, but that's not really what I'm here to ask about. If I turn the simulation speed up all the way, it seems like the mul instruction is executed multiple times before proceeding to the next instruction. I believe this to be the case because if I tap a key quickly while the sim speed is turned up, sometimes I see 999 appear in the acc monitor, and the FM blaster makes a very distinct high pitch noise. If I turn the sim speed down all the way it doesn't happen. Does anyone have any idea why this is happening? Is this worth submitting to the dev team as a bug or am I just being dense?

[cake>pie]

Short answer:
Your code does not account for situations where a key is held down for longer than one "tick".

You expect to be tapping the keys quickly without holding them down. But when the simulation speed is cranked up to the highest, you sometimes are unable to release the key quickly enough.

You can test this by holding down each key for a longer time instead of just tapping quickly --
even on slower simulation speeds, you will get consistently get the high pitch noise if you hold the key down long enough.


Long explanation:
The N4PB-8000 is non-blocking, i.e. similar to the radio chip. It produces three types of outputs:

[button] when the corresponding key is pressed
-[button] when the corresponding key is released
-999 if neither of the above

To gain a better understanding of how the part works, I suggest you create the following setup and watch the memory cells as you press, hold, and release buttons.
http://steamcommunity.com/sharedfiles/filedetails/?id=1266384854
Notice that if you hold down a key for a longer time instead of tapping quickly, you can get "-999" values in between the button-down and button-up values. This is the root of your problem.
You can even press a different key while holding the first one down! Try it and see what happens.

Currently, you expect your code to do this:

mov x3 dat        # read a value to dat
tgt dat 0         # if the value is positive, a key has been pressed (e.g. w=1)
+ mov x3 acc      # read the next value, expecting the key release event (e.g. -1)
+ mul -10         # (!) strictly speaking, you're actually using the button-up event
+ mov acc x0      #     to trigger the FM blaster, rather than the button-down
slp 5

But what happens when a key is held down (or the simulation speed is high, and you don't manage to release the key fast enough), the following happens:

mov x3 dat        # read a value to dat
tgt dat 0         # if the value is positive, a key has been pressed (e.g. w=1)
+ mov x3 acc      # key hasn't been released yet, you get "-999" instead of "-1"
+ mul -10         # (!) this computes as -10 * -999 = 9990, but is clamped to 999 (max)
+ mov acc x0      #    => very high pitch (theoretically >78 octaves above middle C)
slp 5

The easy solution to this would be to use the value from the button-down to trigger the FM blaster, and just ignore the negative button-up values along with the "no-event" -999s.

A more interesting thing you could do is to play the sound when the button is pressed, and stop the sound when the button is released. (This one has a potential pitfall you'll need to handle: if a second key is pressed while the first one is still being held down, you'll probably want to stop the first note and play the second one instead. Then, you should ignore the button-up for the first key, and only stop the second note when the second key is released.)

[Big Fat Travis]

Oh you're right. I must have been tired when I was working on this, because in my head I was moving dat into acc but I clearly was not doing that with the instructions. I changed it and now it's working as I had initially expected.

Thank you for taking a moment to point out where I was going wrong here. I probably would have spent a while trying to debug this today before I'd realize what was wrong.