It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
I don't understand the question :)

>Read from In.1 through In.4
>Write the interrupt number when the value goes from 0 to 1
>Two interrupts will never change in the same input cycle

I cannot see any matching output or what is expected to be send, if a certain combination triggers.
Attachments:
You need to look at the columns, if for example in column 1, the value changes from 0 to 1, you would need to send 1 to out. -.-
avatar
disi: the value changes from 0 to 1, you would need to send 1 to out
but not from 1 to 0.

Basically you make a 2 part/stage function. for each input. So... something like this
[code]
st: mov up, acc
jnz one
mov nil, down
jmp st

one: mov 1, down
st2 mov up, acc
jez two
mov nil, down
jmp st2

two: mov nil, down
[/code]

i'm not sure if that will work, but the logic is basically there... some jumps could be optimized for size.

Alternatively you could try and make use of JRO jumps, which 0 makes it stay in place and 1 moves it down. then make use of the 'mov any, ACC' to get your data..

Hmmm now i gotta do that...
I thought about 1-4 check if they go from 0 to 1. If they do, they send their number down, it not, they send 0 instead (the idea of an interrupt).
Then we have the registers 5-8 in the second row go from left to right, picking up the value from above and exchange it with acc, if it is not 0.
In the end, it is just passed down and out.

Everything else, would be very tied down to this certain constellation and amount of registers, not very universal code.
I have seen people counting steps and time their send correctly to suit the puzzle...

p.s. I mean, if I get this working, you could then plug indefinite more devices into the system and the code would still work (given it is extended over those new interrupts).
Post edited July 22, 2015 by disi
I cannot test it (still at work). What do you think of this in 1-4 with the corresponding number for 1-4 to send down after jump to s1 (to detect the change):
mov up, acc
s0: mov 0, down
sub0: mov up, acc
jnz s1
mov 0, down
jmp sub0
s1: mov 1, down
sub1: mov up, acc
jez s0
mov 0, down
jmp sub1
Post edited July 22, 2015 by disi
avatar
disi: I cannot test it (still at work). What do you think of this in 1-4 with the corresponding number for 1-4 to send down after jump to s1 (to detect the change):
The 1 in 'mov 1, down' would be changed to correspond with each interrupt, so interrupt 2 it would be mov 2, down...

And i am going to say immediately the code is heavily flaws, namely you consume one of the values, then throw down 0 without even checking... Yes this will technically work on the first row, but if any on the first row starts with 1 this code will fail.

however if you dropped the next 2 instructions moving the jnz up to s0 the code looks like it would be a lot closer to completion... although the bottom of the loop is slightly confusing too... jumping to s0 where you have the mov 0, down so...

As a note, part of the manual says if you don't have any instructions at the bottom it loops to the top, so re-arranging some of your code you could make use of this as a (fast and) free jump instruction.

edit: Thinking about this makes my head hurt... Here's a hint in my image... learn from it... (Which has a lot of optimizations...)
Attachments:
int_hint.png (14 Kb)
Post edited July 22, 2015 by rtcvb32
I don't have idents here :(
it would look better like this:
mov up, acc << initial value, so we get the first 0 right
s0: mov 0, down << initial 0, yes I assume the first value will not trigger any interrupts for all four
sub0: mov up, acc << start inner loop of s0
jnz s1 << jump to s1, if a 1 comes down
mov 0, down
jmp sub0 << end of inner loop of s0
s1: mov 1, down << change of 0 to 1 here, this would be 2,3,4 for the others
sub1: mov up, acc << start inner loop of s1
jez s0 << 0 comes down and we jump back to s0
mov 0, down
jmp sub1 << end inner loop of s1

I assume it looks like this for the first interrupt:
0,0,0,0,0,0,1,0,0,0,0,00,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0
Post edited July 22, 2015 by disi
avatar
disi: mov up, acc << initial value, so we get the first 0 right
Bad assumption... One of the next passes could start it as the first one and give you a big red error... There's no guarantee all the inputs start as 0, if one of them starts as 1, you assume the previous value would have been 0...
avatar
disi: I don't have idents here :(
They aren't important, although if you want to indent you could put it in a code block. Some plugins (like mine) add the code so it's done properly (assuming the site doesn't remove it)
avatar
disi: mov up, acc << initial value, so we get the first 0 right
avatar
rtcvb32: Bad assumption... One of the next passes could start it as the first one and give you a big red error... There's no guarantee all the inputs start as 0, if one of them starts as 1, you assume the previous value would have been 0...
yes, one test is random.... I forgot!
avatar
disi: yes, one test is random.... I forgot!
only 50% failure on random per interrupt, and 4 interrupts, you have 6% chance that all of them will be 0 on the random test... Or to be on the upper end, 25% one of them will be on and 75% none of them will be on...
here you go :P
mov up, acc << initial value, so we get the first 0 right
jnz s1 << initial check for random test
s0: mov 0, down << initial 0, yes I assume the first value will not trigger any interrupts for all four
sub0: mov up, acc << start inner loop of s0
jnz s1 << jump to s1, if a 1 comes down
mov 0, down
jmp sub0 << end of inner loop of s0
s1: mov 1, down << change of 0 to 1 here, this would be 2,3,4 for the others
sub1: mov up, acc << start inner loop of s1
jez s0 << 0 comes down and we jump back to s0
mov 0, down
jmp sub1 << end inner loop of s1
avatar
disi: here you go :P
At first glance it looks right... Does it all fit? If so then roll with it :) If not the first three lines look like they could be omitted entirely... (and the jez s0 moved down 1 line and changed to jez sub0... But that's unimportant. Meh, requires too much to think about...)

As per the manual, if something is breaking, use F6 and step through until you get to the error, or add a ! before the instruction and it will break at that point, which can be early or later depending on when it occurs.
Post edited July 22, 2015 by rtcvb32
avatar
disi: here you go :P
avatar
rtcvb32: At first glance it looks right... Does it all fit? If so then roll with it :) If not the first three lines look like they could be omitted entirely... (and the jez s0 moved down 1 line and changed to jez sub0... But that's unimportant. Meh, requires too much to think about...)

As per the manual, if something is breaking, use F6 and step through until you get to the error, or add a ! before the instruction and it will break at that point, which can be early or later depending on when it occurs.
I think you can fit 15 instructions into one node.

5 could look like this:
mov up, right

6-7 could look like this:
s0: mov left, acc
jnz s1
mov up, acc
mov acc, right
jmp s0
s1: mov up, nil
mov acc, right
jmp s0

8 could look like this:
s0: mov left, acc
jnz s1
mov up, acc
mov acc, down
jmp s0
s1: mov up, nil
mov acc, down
jmp s0

p.s. gna... work
Post edited July 22, 2015 by disi
Only 248 cycles as is above! That is not bad...

p.s. the first input is always 0 btw. even in the random test. (247 cycles without the first check...)
Attachments:
Post edited July 22, 2015 by disi
avatar
disi: Only 248 cycles as is above! That is not bad... <snip>
Glancing at the screenshot, i wonder why you didn't add the results of your interrupts, as that would effectively pass it with only 2 instructions...

But if it works, it works :P