does jmp acc work?

[Terezi_pyrope]

Hey, it's a simple question.

If I make, say, 5 jump points,
0: 1: 2: 3: Side:
and in 0: through 3: it jumps to side
and in 0: through 2: adds 1 to the accumulator, but 3: resets it to zero
and 0: through 3: do 1 line of code each (mov val xbus)

Then Side: does some code, and then does

jmp acc

Will it jump to the numerical values in the accumulator, meaning 0: through 3:, or will it try to jump to a jump point called acc: ?

I was stuck on a puzzle and went to sleep, and literally dreamed a solution that involved jmp acc, and I just don't have the drive to code and debug when I first wake up.

[BlaXpirit]

jmp accepts a label name.

[Terezi_pyrope]

Originally posted by BlaXpirit:

jmp accepts a label name.

I got that, but just to be sure, another way of asking is,
if a register contains a valid label name, will using that register as a called label name, move to a label matching the value at the register, or a label matching the register's name.

because saying "jmp accepts a label name" can mean both.

[lisamariefan]

There is no equivalent to a "JRO <value/acc/port>" in this game like there is in TIS. Your code cannot be structured in such a way, and you will have to write it with this in mind.

In fact, if you refer back to the documentation you can see that the syntax is "jmp L" where L stands for label. R, I, and R/I are distinctly defined in the notation reference. Acc is a register/R.

I see what you're thinking with the idea of "dynamic" label jumps, but it is simply not possible in this game. There are other...ways around this limitation that are possible with the game's pieces/mechanics/behavior.

Tbh I'm curious as to what puzzle you're stuck on and if I can try to offer any guidance.

[Zednaught]

I really miss having the JRO and SWP commands.

[Terezi_pyrope]

Originally posted by lisamariefan:

There is no equivalent to a "JRO <value/acc/port>" in this game like there is in TIS. Your code cannot be structured in such a way, and you will have to write it with this in mind.

In fact, if you refer back to the documentation you can see that the syntax is "jmp L" where L stands for label. R, I, and R/I are distinctly defined in the notation reference. Acc is a register/R.

I see what you're thinking with the idea of "dynamic" label jumps, but it is simply not possible in this game. There are other...ways around this limitation that are possible with the game's pieces/mechanics/behavior.

Tbh I'm curious as to what puzzle you're stuck on and if I can try to offer any guidance.

I just now got back to the game and found that... it wasn't the puzzle in the game I'm stuck on.... I'm actually currently on the lazer tag one.... I was re-reading the manual and got to the DX300 example, stepper motor controller. My brain put the required output together as 4 different pulses, each one 4 steps long, and offset from eachother by one step, which is different from the example. Then I went to sleep. I then had a dream about that stepper motor controller being one of the puzzles, as I miss-remembered it, From there, controling 4 offset pulse waves, in 12 to 14 lines of code with an I/O expander, using "jmp acc", which doesn't actually work. but again, I was asleep.

I posted this thread within literally minutes of waking up, and was still quite groggy. Now I am laughing quite hard, at this imagined "puzzle" that doesn't exist. feel free to laugh.

[lisamariefan]

Originally posted by Zednaught:

I really miss having the JRO and SWP commands.

Me too somewhat, but I like being able to multiply and not having to work with a stack, making lookup tables/indexing values easier.

...I need to get back to that guide but I guess I also needed some space from the game for a while...ish...

Also, with the way dat behaves you don't need a swp command tbh fam.

[Cheese]

Originally posted by Terezi_pyrope:

I posted this thread within literally minutes of waking up, and was still quite groggy. Now I am laughing quite hard, at this imagined "puzzle" that doesn't exist. feel free to laugh.

It's great actually to remember these kinds of dreams when you know it's your mind solving problems while you're asleep and preparing for different problems that might arise. There is a command like in your dream in TIS-100, another Zachtronics game that has is just text based programming. Also probably in every real-life assembler language you can use direct memory addresses to jump.

[Zednaught]

Originally posted by lisamariefan:

Originally posted by Zednaught:

I really miss having the JRO and SWP commands.

Me too somewhat, but I like being able to multiply and not having to work with a stack, making lookup tables/indexing values easier.

...I need to get back to that guide but I guess I also needed some space from the game for a while...ish...

Also, with the way dat behaves you don't need a swp command tbh fam.

I was missing it on the targeting computer level in the bonus campaign when I typed it..but after beating it i realized I didn't need it.

I've just reached the Kelp Harvester level...pray for me

[lisamariefan]

Ah, the Kelp Harvester. I dunno if I hate it but I'm very curious about one of the "requirement" lines. :/

[Terezi_pyrope]

welp, I just finished the vape, and I think my solution is a bit pants-on-head... what do you guys think?
http://steamcommunity.com/sharedfiles/filedetails/?id=1098069973

[Zednaught]

Congrats on finishing it! I remember this being the first really tough puzzle for me. That said, if you'd like some critique from a non-expert, here goes.

Your first node has many redundancies. You move x1 to acc first, then move from acc to another part. You could simply move from x1 to another place. That'll save some code.

Each node thereafter has to test if it's -999 or not. You can set it up so that you only do that test on the first part.

More importantly, it's possible to do this in 8 yuan, by seeting up a 'loop.' and containing the distribution instructions within the same circuit. Right now, your large circuit sort of does a loop, but it's a bit inefficient, and it serves as the timepiece for the other circuits, telling them when to go.


Instead, visualize it this way: that fourth number from the receiver sets up a condition that says: output the previous three numbers continually unless two conditions are met: either a new input happens, which you can always tell because a new input will be anything other than -999 or that a set amount of time passes, which you can mark by subtracting 1 each time through the loop.

So, on that circuit, you fit, essentially: (1)a test to see if the pen got a new command, (2) a command distributing those numbers, and (3) a loop that asks if the proper amount of time has elapsed, after which it returns to the off state.

[Terezi_pyrope]

Originally posted by Zednaught:

Congrats on finishing it! I remember this being the first really tough puzzle for me. That said, if you'd like some critique from a non-expert, here goes.

Your first node has many redundancies. You move x1 to acc first, then move from acc to another part. You could simply move from x1 to another place. That'll save some code.

Each node thereafter has to test if it's -999 or not. You can set it up so that you only do that test on the first part.

More importantly, it's possible to do this in 8 yuan, by seeting up a 'loop.' and containing the distribution instructions within the same circuit. Right now, your large circuit sort of does a loop, but it's a bit inefficient, and it serves as the timepiece for the other circuits, telling them when to go.


Instead, visualize it this way: that fourth number from the receiver sets up a condition that says: output the previous three numbers continually unless two conditions are met: either a new input happens, which you can always tell because a new input will be anything other than -999 or that a set amount of time passes, which you can mark by subtracting 1 each time through the loop.

So, on that circuit, you fit, essentially: (1)a test to see if the pen got a new command, (2) a command distributing those numbers, and (3) a loop that asks if the proper amount of time has elapsed, after which it returns to the off state.

you can't do mov xbus xbus, it blocks itself.
you can't do mov xbus basic I/O, the other chips read at the wrong time and get the wrong value.

I tried both of those.
So you MUST send data like this over xbus, to ensure sync.

If you have the first chip test for if -999, it can't do nothing, it still has to send something to the other chips, because they're reading FROM an xbus, and will block from sleeping, so no matter what a recieving chip still has to recieve something to be a 'do nothing' instruction, which may as well be that initial -999. Otherwise it's over-complicating it.

and yeah, I saw a solution ~after~ I finished it, that's only 2 chips. The first chip reads the values in a loop, and passes the 3rd to a 2nd chip over xbus. but reading the code, I couldn't make heads or tails of what was actually happening, it was like i was trying to read the freaking necronomicon or something, it was just gibberish that hurt my head. why oh why couldn't it just be rgb on/off instead of intensity values, I could have just used an expander.

[Cheese]

My tip is that you could use the slx x? command. It makes the chip sleep until there is output so nothing is blocked.

I checked my solution, I too used two chips in the end. Not sure if it looks like something from H.P. Lovecraft. :) My solution had acc as counter for the time in the first chip and dat was the first input that was always checked if it was -999. The other chip was just sleeping until the counter was zero or G or B was coming. The first chip also took care of R.

[Zednaught]

I think Doomcheese is right, the slx command is what would help you to sync things up. With respect, your solution is a bit over-complicated. You can cut down on lines of code and parts needed by asking yourself: when are the only times this part needs to read from something, and how can I ignore the other conditions?

My original solution used two chips as well, but here's a solution that might illustrate what's happening a little better.

So, basically each small chip sleeps until it gets a command, after which it will put that value through the I/O and sleep again until it gets a command to output a new value.

On the large chip, the first command tests if the value is -999 or not. If it is greater, think of it like being in the 'on' state, so anytime it's turned on, it outputs new values to the three chips. Otherwise, it needs to do a second test: is the thing couning down after being turned on.

The fourth number starts a countdown, which says: if this number falls below 0, turn the thing 'off' and have all the chips output 0.


https://steamuserimages-a.akamaihd.net/ugc/858352080350452835/2B9606F4A2D59AE0435977C0BED05FB3F11FAC4F/

[Terezi_pyrope]

I forgot the SLX command existed. I've never needed it before now.

also, you don't need 2 of those chips, instead of using x0 and x3, you can just use p0 p1