more problems with x pins, "part not sleeping blocked on read"

[ahueonao]

I know this has been answered before, but I'm an utter and complete beginner at this so i'd appreciate some truly foolproof explanation. I've kinda brute forced my way through the first five or six puzzles without an inkling of knowledge of programming or electronics, but xbus pins are being my stumbling block right now.

I just don't understand HOW (and how NOT) to use conditional instructions (teq, tgt, tlt) with xbus ("x0", "x1", etc) pins, or how to move them to 'acc' (mov x0 acc, add x0, etc).
I know that both previous threads and the manual say that xbus pins require "information on both ends, a writer and a reader", and that lack of information (i.e. an 'idle' connection) on a x pin doesn't equal zero.

So far I've condensed that info to two points:
1) Don't program assuming that an inactive x pin will have a value of 0. for example, don't use:
teq x0 0
+ jmp [the do nothing line]
2) If a microcontroller is receiving info from an x pin, make sure it's being read at some point every turn, and there isn't a possible chain of instructions that skips on reading that x pin.

I'm guessing these are less than correct and they've only served me for the first few puzzles, and usually require a lot of redundant lines of command to give those x-inputs SOMETHING to do.
And I'm STILL getting plenty of "part not sleeping - blocked on read/write" so I know there's something else on the "don't do" category that I must be missing.

Right now I'm on the laser tag gun thingie and I can't get the fire and reload mechanism to work because I can't move the ammo counter to acc without getting a damn "not sleeping" message even though I keep double-checking everything the way I *think* should work. Any help would be appreciated.

[BlaXpirit]

When something sends a value on X-Bus, then something else must receive it, and it can receive it only once. There is no persistence. You cannot read the same value twice because it will not be there the 2nd time

[BlaXpirit]

Maybe you just need the `slx` instruction

[L4z3r]

Your points are correct

[mudfarmer]

Originally posted by ahueonao:

Right now I'm on the laser tag gun thingie and I can't get the fire and reload mechanism to work because I can't move the ammo counter to acc without getting a damn "not sleeping" message even though I keep double-checking everything the way I *think* should work. Any help would be appreciated.

I'm gussing you are refering to trying to read the little widget with the Max Ammo count? If you are getting a Not Sleeping error it means you are looping forever with no SLP command. Note that many devices that have XBus pins (other than the Controlers) are concidered to be always ready, so using the SLX instruction on a port connected to one of these devices will always fail to sleep (basicly same as a SLP 0).

[L4z3r]

Part not sleeping can be avoided with slx or slip commands. You should almost always end a “turn” with slp 1. One exception is if a micro controller only performs a task that is signaled by an xbus input. Then, you could maybe begin the program with slx.

[L4z3r]

Blocked on read/write is when communicating MC’s are not synchronized, generally when a MC attempts to read when there is no signal available. Check the discussion titled “part not sleeping blocked on read” and feel free to ask about any specific questions you have.

[mudfarmer]

also to point 1, there is nothing inherently wrong with using

TEQ X1 0

as long as the other side is explicitly sending data which may or may not be zero.

[L4z3r]

I you want a MC to do nothing until it receives a certain xbus input, it is often optimal to use the slx instruction.

[L4z3r]

In the example you give at the bottom, the “not sleeping” error is likely not directly due to your attempt to move ammo to acc. You can post your code or link to a screenshot if your want specific debugging help :)

[ahueonao]

That helps a lot, thanks!
But now I'm stuck on how to integrate x-bus signals into conditional instructions within a larger set of commands- if i enter a 'slx' line the whole thing will be on hold until it reads a signal. I'm trying to come up with an instruction (or combination of instructions) that will do a thing if it reads an xbus signal, and carry on with the rest of the lines it if doesn't.
right now i'm stuck with the x-signal ALWAYS giving a signal to be read, and merely changing that signal from like, a 1 to a 2 to give a different result, but that seems to eat up a lot of power, so I'd be open to suggestions in case anyone has come up with a more power- and line- efficient solution.

[ahueonao]

http://steamcommunity.com/sharedfiles/filedetails/?id=1265201337

here's how I solved the laser tag project - using always-on xbus pins as toggles got the job done, but the terrible score this solution gave me (pretty much bottom of the barrel on all accounts) suggests this is far more convoluted than it should be. If anybody has any tips, I'm all ears!

[mudfarmer]

So theres a lot that can be improved, but don't worry just geting anything working is an acomplishment. To match the better scores you'll want to investigate how to use some other components like DX300 and the logic gates. in the mean time some tips...

In the upper left, your first controler tracks the 'alive' state in the Acc (0 or 100), then tests Acc and sends a token to the next controler (1 or 3). That controler looks at the token and reconstructs the value to send to the Alive pin (0 or 100 again). Why not just do an unconditonal Mov Acc X1?

The upper right controler, its only job is to combine and pass on the values of Reload and MaxAmmo to the next controler. but that controler has plenty of pins, why not just connect them directly? The code in the second controler does not even need to change much...

tgt p0 0
+mov x0 acc

[L4z3r]

This one is tricky because there are many pins that are all interrelated. Try to think about which groups of pines work together and control them with a MC. For example, hit, respawn, and alive are all related, so one MC could probably interpret hit and respawn inputs and send the proper output to the alive pin. This MC might also send an input to an MC involved in the firing process to signal that the person is alive and can thus fire.

[L4z3r]

One thing I really don’t like about this puzzle is that I believe DX300 and logic gates are “not recommended” :( DX300 especially is EXTREMELY useful. Learn this part to simplify your design greatly.

[L4z3r]

Also, using xbus to as a trigger for a certain part of your program is inefficient as you must create your own non blocking xbus signal so that your program still functions when the trigger is not active (as you realized). (Non blocking is when the writing MC sends a signal that simply means “trigger not activated” to prevent “blocked on read” in the receiving MC) Use simple signal for this instead because “no signal sent” is read as “zero”. DX300 should free up some simple signal pins.