|
The digs at China and western expats there are right on point. I love it. I don't understand why I'm having such a hard time using the memory cell, but it blocks when the data port is written to. I've checked out the manual and am just writing the most simplest code I can to try to figure it out. It's the dumbest thing, but I can't figure out what I'm going wrong. New Coke fucked around with this message at 23:04 on Dec 17, 2016 |
# ? Dec 17, 2016 23:01 |
|
|
# ? May 6, 2024 01:58 |
Did you place a ROM bank when you meant to use a RAM?
|
|
# ? Dec 17, 2016 23:07 |
|
edit: yeah that was it.
New Coke fucked around with this message at 23:15 on Dec 17, 2016 |
# ? Dec 17, 2016 23:13 |
|
That's a ROM bank. You meant to use a RAM bank. Like nielsm said. You put the values in a ROM bank manually during design, not automatically during code execution. edit: awww, put your image of shame back up. edit again, it was this
|
# ? Dec 17, 2016 23:15 |
|
Yeah I'm an idiot. Double checked after responding to neilsm's post and realized he was right. Thanks!
|
# ? Dec 17, 2016 23:24 |
|
print meat on the cheap with a $14 meat printer my first solution had an OR gate and two NOTs acting as diodes for one of the cases, looking like a giant plate of spaghetti. it still came in at lower power/lines of code than this one though. optimization is weird. edit: even more efficient meat, $11/216/17. i was aiming for an $8 solution but i ran out of room to extrude the meat. Dieting Hippo fucked around with this message at 03:41 on Dec 18, 2016 |
# ? Dec 18, 2016 03:08 |
|
Finally beat the pollution sensing window bafter doing some line saving to fit all my code in. Then went back and improved a bunch of other solutions to use the RAM address pointer as an counter instead of ACC. Didn't save much power but it's been a very good Shenzhen weekend overall. One final push tonight. Some of these later puzzles really are kicking my arse and I think I've reached my limit.
|
# ? Dec 19, 2016 00:06 |
|
i have two puzzles on the workshop if anyone feels brave enough to attempt these (easy) challenges: RAY GUN this one was my first attempt. i was aiming for a puzzle that's straightforward but has cramped quarters. FACE CONTROLLER make a controller that activates different areas of a face based on the emotion. if wired right, it'll look like a face when it's done. thehustler posted:One final push tonight. Some of these later puzzles really are kicking my arse and I think I've reached my limit. i think i'm finally hitting a wall at the airplane drink machine. the color coordinating shoes were a walk in the park compared to this.
|
# ? Dec 19, 2016 07:24 |
|
Dieting Hippo posted:print meat on the cheap with a $14 meat printer
|
# ? Dec 19, 2016 09:03 |
|
thank you for freeing me from the shackles of ROM use. it's not quite $8 now, but i still got lower cost/power from dropping it.
|
# ? Dec 19, 2016 09:43 |
|
Dieting Hippo posted:i have two puzzles on the workshop if anyone feels brave enough to attempt these (easy) challenges: You can cheese that one by not using rom and just using one IC per ingredient
|
# ? Dec 19, 2016 10:20 |
|
Hah! My time on Security Nightmare became easier when I realised that you only had to store one active card number, not every card stored. And with that, another one down, and maybe this game ain't over for me yet... *looks at next one* Gulp. Edit: How poo poo were everyone's hash functions?
|
# ? Dec 23, 2016 00:29 |
|
thehustler posted:Edit: How poo poo were everyone's hash functions? "Literally toss six of the ten numbers directly into the garbage" poo poo. That level is the greatest thing in the entire game. I redid my old solution from scratch a few days ago and figured out I could do the whole thing in one MC6000. I've come a long way since complaining about almost every level in this thread, so thanks to everyone who helped! Be sure to play a little bit into the 2nd campaign for a callback. Dieting Hippo posted:RAY GUN I just got this in 4/267/9 which was off the charts on cost and power. Nice! GuavaMoment fucked around with this message at 06:58 on Dec 23, 2016 |
# ? Dec 23, 2016 01:47 |
|
I think I added together every digit and then added 20 and multiplied by 3 Now I'm wondering how simple I can make it to save lines or power. You probably don't need every digit but the less you use the more chance there is of a hash collision. Is it possible to do this without RAM? I ran out of registers and I'm literally using the first memory location and nothing more.
|
# ? Dec 23, 2016 13:58 |
|
You definitely don't need ram but it might be that or a second MC. My hash function is precisely one power per digit.
Jeffrey of YOSPOS fucked around with this message at 18:17 on Dec 23, 2016 |
# ? Dec 23, 2016 16:35 |
My cheap/simplified door lock solutions have been either MC4000+MC6000 or MC6000+ROM.
|
|
# ? Dec 23, 2016 17:13 |
|
thehustler posted:I think I added together every digit and then added 20 and multiplied by 3 You must process every digit (either add, sub, or mov somewhere) otherwise they're going to sit in the xbus buffer and ruin your day. The trick is to just find a sequence of add/sub/mov nulls that won't get a hash collision in the test set.
|
# ? Dec 23, 2016 19:39 |
New Coke posted:The digs at China and western expats there are right on point. I love it. old post but same here. i live very close by shenzhen and it's pretty funny
|
|
# ? Jan 13, 2017 11:17 |
|
85 wins in Solitaire... I'm close!
|
# ? Jan 14, 2017 15:02 |
|
double riveting posted:85 wins in Solitaire... I'm close! I'm still disappointed that you don't get an email reprimanding you for wasting company time at 100.
|
# ? Jan 14, 2017 17:04 |
|
Eliza posted:I'm still disappointed that you don't get an email reprimanding you for wasting company time at 100. So send that in to the devs as a suggestion. They have a sense of humour so it may even happen.
|
# ? Jan 14, 2017 22:35 |
|
913 and counting
|
# ? Jan 15, 2017 17:06 |
|
I think I need a new hobby
|
# ? Jan 21, 2017 11:11 |
|
I'm stuck on the kill switch. I was hoping that I could fill up commands with junk numbers bigger than 1 and the dx300 would ignore them, but it doesn't work and I'm at a loss for where to go from here without brute forcing it.
|
# ? Jan 30, 2017 04:19 |
|
Pomp posted:I'm stuck on the kill switch. I was hoping that I could fill up commands with junk numbers bigger than 1 and the dx300 would ignore them, but it doesn't work and I'm at a loss for where to go from here without brute forcing it. if it's not separate yet, try splitting off any code solely for controlling the DX300 to a new MC. that should give you a bit more room to work with and help to avoid working with junk numbers.
|
# ? Feb 1, 2017 02:41 |
|
what a mess edit: Pomp fucked around with this message at 21:47 on Feb 3, 2017 |
# ? Feb 3, 2017 21:44 |
|
lol you didn't need to abandon the dx-300 completely!!
|
# ? Feb 3, 2017 21:58 |
|
Pomp posted:what a mess it took me a bit to see what was going on and i love it. weaker men would use a dx300.
|
# ? Feb 6, 2017 07:45 |
|
Zach Barth is coming to my office to do a QA later this month. If anyone has any questions they'd like me to ask them lmk and I'll post back afterward.
|
# ? Feb 15, 2017 01:43 |
|
Whoa! Just found this thread. Been playing for a couple weeks, I'm in Avalon City on the electronic target practice problem. I've got shot counting and scoring worked out, but coordinating all the display necessities is driving me nuts. Setup: (1)MC4000 that reads "detect" and keeps tract of shots. (2) and (3)Two MC6000 calculate the Pythagorean distance (squared) and assign it a value When a shot is made, both sequence number and value are sent to and (4)MC600 which divvies up the values for archer 1 (1-4) and 2 (5-8). 8 triggers an EOG signal Two (5) and (6) MC6000s then keep score and output. Each has an (7) and (8)MC4000X coprocessor to handle flashing the display. It all seems rather sloppy and over-coded at this point, like I need some clever insights on how to chop down on the data movement and complexity. Current status: It doesn't work ATM but I've been working on it for several days. I don't want spoilers, but any hints as to algorithms or data structures to make the back end run efficiently would be appreciated.
|
# ? Feb 25, 2017 05:45 |
|
That's what most of my solutions end up looking like :p But seriously, it seems like you've got a reasonable approach of dividing things between MCs, it's just a matter of making everything fit. A few tips that might help: - Make sure you're using all the space on the board! There's a whole column off to the right there you're not using right now, shuffling things over to make use of that space will free up room for more traces, maybe some larger/additional MCs, that kind of thing. - Think about all the components available. Is a RAM useful here? What about a ROM? what about the PGA? (Actually, I've never found the PGA useful. But it seems like it might end up being helpful, at some point). - Does dividing the labour a bit differently help things? This is most useful when you have one chip that you're having trouble fitting everything in, taking a small part of its job and moving it somewhere else can often help. - You can put a label on the very first line of code, rather than needing an instruction at the very end to jump to. Ultimately once you have something functional (even if it's a bit messy), you can then look at it and see how to cut things down to be more elegant. Getting something that actually works is the first step.
|
# ? Feb 25, 2017 06:28 |
|
|
# ? May 6, 2024 01:58 |
|
Thank you for mentioning RAM. It turned out to be the solution to the score problem by detaching the two processes. Got it solved. It's crappy and inefficient, but it works. On to the next one.
|
# ? Feb 25, 2017 18:26 |