|
I appear to be taking the same approach with this game as I did with TIS-100: perform competitively in the first few levels and feel good about myself, before giving up and muddling my way through the rest with hilariously bad designs that somehow work.Kaislioc posted:Holy gently caress Device 2A27. I've dropped 24 yuan and 11.6k power on it and I still can't loving Divide and conquer. Handle the X axis and the square separately
|
#
?
Oct 9, 2016 14:42
|
|
|
|
| # ? Jun 10, 2024 17:28 |
|
|
How the gently caress are people doing traffic signalling in what looks like 9 yuan from the histogram? Sure, it looks like it should be easy with logic gates, but then you realise that you have to restart the cycle every time an emergency vehicle goes by. I ended up sticking an I/O expander on the output, using an MC6000 and an MC4000 to initialise some RAM with the sequence of values to send to it, and then using another MC6000 to cycle through the RAM sequence checking for zeroes in the process. That took me 16 yuan.
|
|
#
?
Oct 9, 2016 16:04
|
|
|
Kaislioc posted:Holy gently caress Device 2A27. I've dropped 24 yuan and 11.6k power on it and I still can't loving Ok, interesting. My 10 yuan and 1k power kludge is mid range. I would offer the opinion that you may need a fresh approach there  GotLag posted:I appear to be taking the same approach with this game as I did with TIS-100: perform competitively in the first few levels and feel good about myself, before giving up and muddling my way through the rest with hilariously bad designs that somehow work. I'm just getting through them all first to get everything unlocked. Once I have all the toys I can go back and try to beat high scores.
|
|
#
?
Oct 9, 2016 16:09
|
|
|
pumpinglemma posted:How the gently caress are people doing traffic signalling in what looks like 9 yuan from the histogram? Sure, it looks like it should be easy with logic gates, but then you realise that you have to restart the cycle every time an emergency vehicle goes by. I ended up sticking an I/O expander on the output, using an MC6000 and an MC4000 to initialise some RAM with the sequence of values to send to it, and then using another MC6000 to cycle through the RAM sequence checking for zeroes in the process. That took me 16 yuan. Mine is 9 yuan: One I/O expander, one MC6000 (that does nearly all the work), one MC4000. No RAM is needed.
|
|
#
?
Oct 9, 2016 16:32
|
|
|
Morholt posted:Mine is 9 yuan: One I/O expander, one MC6000 (that does nearly all the work), one MC4000. No RAM is needed. (More traffic control talk) And here I was planning a crazy 3-CPU ring structure. Actually I find the RAM idea clever, since I first thought "ROM would be handy", but then remembered the dials. The RAM version sounds like it'd be pretty good at power.
|
|
#
?
Oct 9, 2016 17:35
|
|
|
OddObserver posted:(More traffic control talk) Yeah, my approach to the traffic control was to have one processor load a microprogram into RAM, adjusting for the dial values, then the other processor executes the program, aborting if the emergency signal is active.
|
|
#
?
Oct 9, 2016 18:06
|
|
|
This game scratches a (very aggravating) itch for me! I just finished the Drinking Game scorekeeping thing after staring at it for twenty minutes last night. I laid in bed and thought through the steps of what I was doing, then had to resist the temptation to get back up and finish the puzzle. I completed it in a shameful 780 power usage but this was a first completion - did it the brute-force-ish way with one component for each input that both send an XBUS signal to a third, which actually tracks the score, which is (I'm assuming) both the obvious and inefficient way to do it. I'm glad to have the leaderboards in this game! Mild optimization of the same thing, I realized that both of the small components on the left had only 5 instructions in them, so I collapsed them into one of the larger components and used "acc" to track the status of the "point" input and "dat" to track the other one, which managed to cut a beefy 60 power off of my design, woohoo, still at the bottom! Ignoranus fucked around with this message at 18:29 on Oct 9, 2016 |
|
#
?
Oct 9, 2016 18:22
|
|
|
I unlocked the prototype game sandbox and some of these parts aren't even in the manual. What is this strange rear end box with 4 p-inputs? How exactly does this gamepad work??? What in god's name is even going on here 
|
|
#
?
Oct 9, 2016 19:59
|
|
|
Color Printer posted:I unlocked the prototype game sandbox and some of these parts aren't even in the manual. What is this strange rear end box with 4 p-inputs? How exactly does this gamepad work??? What in god's name is even going on here N4PB-1000: Pushbutton, sets simple bus to 100 as long as it's held down. N4SW-1000: Toggle switch, sets simple bus to 100 when in "on" position. N4DL-1000: Constant generator, supplies the shown value on XBus whenever you read. The value can only be adjusted when the system is running, not when designing. N4GP-1000: Gamepad with 8 buttons. A numeric value is printed on each button. When you press a button down, it outputs the button's value on XBus, when you release a button it outputs negative the button's value on XBus. The bus is async, reading from it when there isn't any input gives value -999. (Example: Press Start (Enter), next read from the bus will return 8. Any further reads will return -999 until you release the button or press another button. When you release the Start button it generates -8 on the bus.) Simple demo circuit. ???????: Random generator, has just one connected pin (simple bus) which changes to a random value 0 to 100 each cycle. LX100R/G/A/W: Single-color LED, simple bus input and lights up the amount corresponding to the bus value. LX300RGB: RGB-LED, three inputs corresponding to the additive primaries. N4BZ-1000: Buzzer speaker, when given a simple input greater than 0 it produces a tone, the frequency depends on the input value. LX700: 2½ digit 7-segment LCD display (range is -100 to 100), displays the same value until it receives a new one on XBus. Sending -999 to it turns off the display. LX900C: Custom LCD display, you can make your own raster for this. nielsm fucked around with this message at 20:20 on Oct 9, 2016 |
|
#
?
Oct 9, 2016 20:16
|
|
|
Does anyone have any hints for Color-Changing Vape Pen aka COOL DAD!!!? I seem to have hit a wall here. My first attempt was with one MC6000 processing whats coming in on radio-rx, sending off each of the 3 color data packets to 3 different MC4000s via xbus, and trying to use one simple bus to control on/off for each using a simple bus but I can't come up with a means of continually looping outputting to the LED until a new xbus packet comes in, since waiting for data on xbus is locking, and only one value can be sent on simple bus for each slp cycle. I've considering trying to also send the on/off commands via xbus, which would allow me to send a special command to break out of the output loop and go back to waiting for incoming new color data, but then I'm up against some major space constraints trying to route everything and it's getting quite expensive, with 4x MC4000 and a MC6000. I know I'm missing some better way of handling it.
|
|
#
?
Oct 9, 2016 20:37
|
|
|
NickPancakes posted:Does anyone have any hints for Color-Changing Vape Pen aka COOL DAD!!!? I seem to have hit a wall here. My first attempt was with one MC6000 processing whats coming in on radio-rx, sending off each of the 3 color data packets to 3 different MC4000s via xbus, and trying to use one simple bus to control on/off for each using a simple bus but I can't come up with a means of continually looping outputting to the LED until a new xbus packet comes in, since waiting for data on xbus is locking, and only one value can be sent on simple bus for each slp cycle.
|
|
#
?
Oct 9, 2016 20:57
|
|
|
zedprime posted:Simple IO holds its value. So for Cool Dad's Cool Vape pen, you send intensity once on a simple IO to the LED pin, and don't touch it until the specified time is up or a new packet comes in. That's fairly simple to do with conditionals if you understand you only need to mov to a simple IO when you receive a packet or when the timer runs out. Its kind of a tutorial on how to turn xbus packets into an array of simple IO output. Perfect, that's just what I needed. Thank you!
|
|
#
?
Oct 9, 2016 21:11
|
|
|
Anyone know if there is a German word for "feeling of almost solving a puzzle except for being unable to find a way to connect a pair of pins?"
|
|
#
?
Oct 9, 2016 21:29
|
|
|
Why look to German when the relevant comparison is your feng shui is off. Don't feel bad, my feng shui is awful as well. 
zedprime fucked around with this message at 22:30 on Oct 9, 2016 |
|
#
?
Oct 9, 2016 21:48
|
|
|
Everything in this game is just a little bit too small. Your code doesn't fit by one instruction, the board is one column too short to fit your components, and your head just isn't big enough to wrap itself around whatever other problem you're having. It makes it very satisfying when you do get everything to fit together.
|
|
#
?
Oct 9, 2016 23:14
|
|
|
zedprime posted:Why look to German when the relevant comparison is your feng shui is off. Wait. You can run wires under chips? I got all the way to security nightmare without realising that, then. 
|
|
#
?
Oct 9, 2016 23:34
|
|
|
Jabor posted:Everything in this game is just a little bit too small. Your code doesn't fit by one instruction, the board is one column too short to fit your components, and your head just isn't big enough to wrap itself around whatever other problem you're having. One instruction short keeps costing me hours. I'm trying to get through all of them unlocking parts, then go back and fiddle once I have all the toys. Then I waste time trying to rearrange or find a trick to get a space instead of split the problem and slap another MC on.
|
|
#
?
Oct 10, 2016 00:24
|
|
|
Watching all your X-ray screenshots I realize that connecting pins to wires that run directly under the components is a thing that works. That would have helped a lot in some of the later levels!
|
|
#
?
Oct 10, 2016 01:03
|
|
|
Oh hey, a new Zachtronics game. Think I'll check this out and play a few minutes before I go back to shitposting about the debates.
|
|
#
?
Oct 10, 2016 05:27
|
|
|
zedprime posted:Why look to German when the relevant comparison is your feng shui is off. That is good feng shui. Bridges are admissions of failure, and in my opinion should cost like 1 yuan or something.
|
|
#
?
Oct 10, 2016 08:12
|
|
|
On the very first version of the game Thursday morning they did cost 1. Now that I've learned you can out the wires through corners and stuff certain things have gotten way way easier.
|
|
#
?
Oct 10, 2016 09:50
|
|
|
Thorium is driving me loving barmy and oh my god it's 2 30 in the morning. Here's where I'm at so far, someone please give advice. Paused on the second sim, it gets through the first. I understand what's wrong but not what to do about it, i.e. to make the first chip take priority by shutting off the second chip's signal.  (edit) Nevermind, figured it out  Histograms suck but idc i'm tired Ciaphas fucked around with this message at 10:31 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 10:25
|
|
|
The three stages of SHENZHEN I/O solutions:
|
|
#
?
Oct 10, 2016 11:56
|
|
|
I got the "SafetyNet" final puzzle (I think?) solved last night. It ended up being really tight on timing, depending on NOPs and funky instruction re-ordering, even some redundant operations, to get all the MCs synced up properly. Both functions in my implementation work by having shared access to memory banks. The location reporting sets the address pointer in a ROM bank to point to the appropriate value, using modulo wraparound of addresses and special casing for the central area. The radio connection then takes one micro-cycle longer to reach the read from that bank, so the sector ID can be reported in the same I/O cycle. For the audio output, I write the length and audio data to a RAM bank, with connections to both address/data ports by the reader and writer. The reader is precisely synced to the writer, so the reader actually reads the audio length and first sample value in the same cycles as they are written to the RAM bank. I didn't think that would work but it's cool it does. There isn't any other sync between the radio input and audio output than reading shared memory, but if I can add a direct XBus sync I can probably save a lot of power on the audio output MC idling.
|
|
#
?
Oct 10, 2016 13:28
|
|
|
Living in rural New England, I always wondered how the farming simulator games were so popular. Who wants to spend their free time pretending to be working? Queue me blowing 6 hours this weekend optimizing power usage and debugging spaghetti code instead of shooting super mutants.
|
|
#
?
Oct 10, 2016 16:20
|
|
|
I just started playing this last night, and it's making me feel even dumber than SpaceChem did. My first working scorekeeper module (points/fouls):  It works, but my cost and power usage are way higher than is apparently possible. I tried it with just the MC6000 but couldn't store the state of both buttons and the score with only two registers. The logic I used for the MC4000's is: If the input is greater than it was the previous cycle, we know someone hit the button and send 100 to the MC6000. Otherwise, either the button isn't being pressed, or it's still being held down from the previous press. Either way, we send 0 to the MC6000. Then we store the current state of the button in the accumulator so we can check again during the next cycle. I think my issue is with how I'm handling things in the MC6000. Before I started using SLX <pin>, I couldn't keep anything in sync. I'd either have the display output show up one cycle too late, or I'd have a condition where there was nothing to display on the very first cycle. I think I don't quite understand exactly how SLP works, and it isn't explained very well in the manual.
|
|
#
?
Oct 10, 2016 16:59
|
|
|
slp 1 just pauses the chip until the next time unit. All processors need to be sleeping for time to advance. You don't need those slx instructions, just an slp 1 at the end of that chip.
|
|
#
?
Oct 10, 2016 17:13
|
|
|
Dr. Stab posted:slp 1 just pauses the chip until the next time unit.
|
|
#
?
Oct 10, 2016 17:45
|
|
|
Made an optimized version of the Security Nightmare, that is still fully spec compliant. Looking at the scoring histograms I wonder if some of the cheapest/lowest energy cheat massively and just check some of the digits? (Like, just check the three first digits, surely that's sufficiently unique.) Well it would be fitting for the puzzle name...
|
|
#
?
Oct 10, 2016 17:59
|
|
|
New Zealand can eat me posted:Another thing I just realized you can do: run traces under chips oh my god
|
|
#
?
Oct 10, 2016 18:04
|
|
|
nielsm posted:Made an optimized version of the Security Nightmare, that is still fully spec compliant. Its like the packet form in spoiler blocking headphones is asking you to cheat.
|
|
#
?
Oct 10, 2016 18:11
|
|
|
WhiteHowler posted:When I tried the same layout without the slx, the MC6000 kept trying to evaluate the inputs before the MC4000's had time to calculate and send values. It's not blocking because it's processing values faster than they can be calculated, it's because it's never allowing time to advance. Each chip needs to hit a sleep instruction before the next time unit starts. You could equally have only one of those slx instructions, or an slp 1 at the end of the block.
|
|
#
?
Oct 10, 2016 18:16
|
|
|
Dr. Stab posted:It's not blocking because it's processing values faster than they can be calculated, it's because it's never allowing time to advance. Each chip needs to hit a sleep instruction before the next time unit starts. You could equally have only one of those slx instructions, or an slp 1 at the end of the block. Does the XBus work differently because it actually waits for an input? Removing the slx lines saved 61 power. When you unlock more components, can you then go back and use them in earlier designs? I don't see how people are doing this one at a cost of $4-5.
|
|
#
?
Oct 10, 2016 18:34
|
|
|
WhiteHowler posted:I thought that was what I tried before, but I guess my original design was using the basic I/O (p0/p1) pins with slp 1 at the end, and it was running into those timing issues. Yes, you can go back and use them. However....you can do that one with $3 and the components it comes with. 
|
|
#
?
Oct 10, 2016 18:41
|
|
|
nielsm posted:Made an optimized version of the Security Nightmare, that is still fully spec compliant. Figuring out clever ways to cheat is half the fun of this game, IMO. For a lot of puzzles, I have, say, a ¥15 doorlock that does exactly what the customer wants, and then a ¥10 fomo sacer fucked around with this message at 19:28 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 18:46
|
|
|
Jeffrey of YOSPOS posted:Yes, you can go back and use them. However....you can do that one with $3 and the components it comes with. Edit: Ugh, I'm not sure how to do this without having someplace to store the previous button state. WhiteHowler fucked around with this message at 19:51 on Oct 10, 2016 |
|
#
?
Oct 10, 2016 19:44
|
|
|
WhiteHowler posted:I kind of hate you for telling me this, because now I'm not going to be able to proceed until I figure it out. I stayed up until 3am and did it in response to a co-worker telling me that, and his solution is still faster somehow. Just paying it forward.
|
|
#
?
Oct 10, 2016 19:51
|
|
|
nielsm posted:Made an optimized version of the Security Nightmare, that is still fully spec compliant.
|
|
#
?
Oct 10, 2016 19:55
|
|
|
Jeffrey of YOSPOS posted:I stayed up until 3am and did it in response to a co-worker telling me that, and his solution is still faster somehow. Once I get that working, I'll give it a shot with an MC4000.
|
|
#
?
Oct 10, 2016 20:30
|
|
|
|
| # ? Jun 10, 2024 17:28 |
|
|
WhiteHowler posted:I'm pretty close to getting it using a single MC6000 -- just one too many lines of code. I had a line of code to spare!
|
|
#
?
Oct 10, 2016 20:33
|
|