SHENZHEN I/O

SHENZHEN I/O

View Stats:
Zednaught Jan 24, 2017 @ 6:51am
Question about inputs connected to multiple circuits
One of the few remaining questions I have about the mechanics in this game is regarding when an input is connected to multiple circuits.

For example, I'm on the meat printer level, and although the solution seems straightforward, I can't quite figure out how to get it all on a single MC6000 unless there's a faster way to read ROM. I think I have to split the keypad input to multiple circuits to have space to process them all, and it would save some lines and power if I could do this automatically with wiring.

What I'd like is that all circuits sharing the same green wiring all receive the same input at once. Instead, it seems like only one circuit gets the input. The signal isn't shared to all of them, and I don't know the rules for determining which circuit gets the packet.

Thanks!
< >
Showing 1-5 of 5 comments
AlexMBrennan Jan 24, 2017 @ 9:06am 
An xbus packet can only be read once, and attaching multiple MCs trying to read the xbus packet does not change that - you will have to resend the packet however many times you will later try to read it.

Order is random, so you will need to use NOP to get the timing right - one xbus packet will wake
all listening (with SLX) MCs, but only one of them will be able to read the packet.

Alternatively, you could use simple IO which can be read multile times but which cannot wake MCs.
Zednaught Jan 24, 2017 @ 10:31am 
Originally posted by AlexMBrennan:
An xbus packet can only be read once, and attaching multiple MCs trying to read the xbus packet does not change that - you will have to resend the packet however many times you will later try to read it.

Order is random, so you will need to use NOP to get the timing right - one xbus packet will wake
all listening (with SLX) MCs, but only one of them will be able to read the packet.

Alternatively, you could use simple IO which can be read multile times but which cannot wake MCs.

Ah, thanks for the explanation, that makes sense. With only one XBUS packet able to be read, I'll just have to route that data through a couple of circuits.

The simple IO seems like it could accomplish what I want, but getting the timing right seems trickier.
ShadowCluster Jan 24, 2017 @ 12:02pm 
In the case for example of an xbus input 'expected' every cycle (i.e there is never a case where an input isn't given on that cycle) and you want to split to 2 MCs, make one of the MCs use slx and the other use slp 1 (at the end). This allows for you to offset them as one of them rests of the slx, while the other rests of the mov x_ _.
mudfarmer Jan 24, 2017 @ 2:53pm 
remember that the Xbus pins on the I/O expander are non-blocking and can easily be connected to multiple controlers. Another tip you might find usefull for this level:
overflowing the address for a ram make the pointer wrap around. ie 14 becomes 0
Zednaught Jan 24, 2017 @ 2:55pm 
Thanks for the help. I just solved this--quite pleased with the solution. It's the first time I'm at the top of my friend's list. Usually those guys are sitting at the top 10% or higher.

Plus, I just used the tcp command for the first time. I'm starting to see how useful it can be.
I'll keep that RAM/ROM trick in mind for the future, thanks.

http://images.akamai.steamusercontent.com/ugc/99478222108424851/5CC81A21220BA9BFFE0B8ED47F67BE83C9F44100/
< >
Showing 1-5 of 5 comments
Per page: 1530 50

Date Posted: Jan 24, 2017 @ 6:51am
Posts: 5