I think I better follow this one. Assembly has always barely eluded my grasp. I skirted through the CS class that dealt with it. I stopped reading The Art of Computer Programming when Knuth introduced his own assembly language and attempted to present an implementation of an algorithm in it. But it still intrigues me.

I could see some CS professors having a lot of fun with this, especially in graduate-level classes. Hell, I've thought about using TASes as teaching tools for Computer Organization/Architecture, namely the ones that corrupt memory and optionally inject code. The lines are blurring, people...

It's more like SpaceChem and his other games than it might seem at first. So it's sort of an abstract or simplified assembler, although not that far off from what I remember. It's the pipelining through various registers that makes it mechanically like the other games.

The two sides to every story are true and false, not yours and theirs. Facts are not political; lies are. - Deven Green (Mrs. Betty Bowers)

Currently on the second row. The restrictions on number of operations in a node, and there only being one accessible local register are the current blocks for me.

The sequence matching one would be easy if I could put more operations in a single cell.
Edge detection would be easy if you had two registers (you can only access ACC directly) and so I'm going to have to use adjacent nodes as extra storage. I can't think of another way of subtracting i(n) from i(n-1) and keeping i(n) around for the next comparison. I'll look into moving i(n) to another node, saving i(n) into BAK, subtracting i(n-1) from i(n) in ACC, MOVing the result to another node that will handle the conditional negation and difference comparison, and then SWPing BAK to ACC for the next comparison. I'll be dreaming about this game tonight, I expect.

I'm up to the sequence reverser puzzle now (3-3) where you start getting Stack nodes.

The sequence matcher took me the longest time to solve, but I got inspiration on the drive home tonight - a design which pipelines 3 consecutive samples in three nodes, each of which emits a 0 or 1 into the adjacent column of nodes, which then adds up those three values and matches with 3.

I was very happy with what I saw as a neat design, but then the SpaceChem thing happened where my lovely solution uses 3 times as many cycles as most other solutions.

It's definitely a game where I do most of the solving away from the computer, such as when I should be sleeping.

Some of the initial outputs annoy me though - the sequence puzzles want zeroes outputted for the first two samples which means I have to add special initialisation code to nodes to fool them into outputting stuff early. Maybe this makes other designs simpler.

And bought!
I'm stuck on the third one, yeesh. (I keep trying to think of the most efficient course rather than actually solving the darn thing)

edit: and now I have a block on the left trying to write to the block on the right, and the block on the right is trying to read from the block on the left, and yet it's still in deadlock, so f*ck me I guess.
edit2: Got it! Did you know that LEFT and RIGHT are totally different things. (the right block was actually trying to read from the right block, I'm tired okay)

RolandofGilead gifted me this, even though it was not on sale. Huge thanks! I assume this will go the way of SpaceChem - I will spend tens of hours on it, feel totally inadequate and yet enjoying every minute of it. The manual is sweet as well

Hello ASM, haven't seen you in twenty years!

It's easy to play piano: all you have to do is touch the right key at the right time.

It's a damn fine game. I've "solved" 12 of the puzzles, but judging by the friend-leaderboards, I have a ways to go for optimization. Seriously, Mooquack, how the f*ck did you get such minuscule cycle counts on those? I'm just barely able to some of these to complete at all, and your times are like a THIRD of mine.

After finishing Her Story, I decided to pick up another game that involved an ancient computer and lots of typing. I played for 2 hours last night and fell asleep thinking of optimizations. Based on my experience with Spacechem, I expect I'll never get to the later levels, but it's fun so far!

It's a damn fine game. I've "solved" 12 of the puzzles, but judging by the friend-leaderboards, I have a ways to go for optimization. Seriously, Mooquack, how the f*ck did you get such minuscule cycle counts on those? I'm just barely able to some of these to complete at all, and your times are like a THIRD of mine.

By Mooquack, I assume you mean DudleySmith, Assembly King and Emperor Of All Things 8-bit?

Serious point though, that I learned from SpaceChem and applies here - remember that you can hit a top score on ONLY ONE HISTOGRAM AT A TIME. That insanely low cycle count might be the result of cramming every node full of code. Likewise, yes, I only used 3 nodes there, but it took 8 billion cycles.

Sidebar - you have my permission to use "Node Full Of Code" as the name for your next mathrock project.

ClockworkHouse wrote:

You've never known true joy until you've shaken a lich stick at someone.

Serious point though, that I learned from SpaceChem and applies here - remember that you can hit a top score on ONLY ONE HISTOGRAM AT A TIME. That insanely low cycle count might be the result of cramming every node full of code. Likewise, yes, I only used 3 nodes there, but it took 8 billion cycles.

Yup, exactly. But it's hard not seeing the trinity of low scores and feeling vastly inferior, in every way.

Serious point though, that I learned from SpaceChem and applies here - remember that you can hit a top score on ONLY ONE HISTOGRAM AT A TIME. That insanely low cycle count might be the result of cramming every node full of code. Likewise, yes, I only used 3 nodes there, but it took 8 billion cycles.

Yup, exactly. But it's hard not seeing the trinity of low scores and feeling vastly inferior, in every way. :)

Personally, I love this in both SpaceChem and TIS-100. The double feeling of "Finally made it! I'm S.M.R.T.!" and "Need to do some serious optimization here..." is just great. And by "great" I mean "feeding my OCD".

It's easy to play piano: all you have to do is touch the right key at the right time.

Since the MOV command is blocking, you tend to use that like an event to synchronise nodes.

I have seen some really efficient solutions for the simpler puzzles that use them to get two nodes to do something in fewer cycles than one can. They're also useful for solutions using JRO on inputs for padding the instructions out to the right places.