I love Zachtronics' games, but they're kind of in the uncanny valley of gameplay for me. After a few hours, I start to wonder why I'm optimizing all these in-game circuits when I could be doing the same with my actual code! (On the other hand, they also make me realize how great Woz must have felt when he got Breakout down to just 44 chips.)
The performance comparisons to other players is a brilliant feature, though.
Once I found myself trying to implement a mutex in it... I've just spent all day at work doing stuff like this, and then I come home from work and keep doing it there as well.
Me, I'm wondering how many FPGA gates you'd need to implement a TIS-100 node, how many nodes you could get on an average Xylinx, and whether you could actually get useful work done on the result. Finding a HLL that would usefully compile down into a network of nodes would be... interesting.
I/O would take 48 pins with 11 bidirectional pins per port to hold the word and 1 latch pin to release. The ISA would only require 4 bits to select an instruction. The ALU wouldn't be too complicated and there are only direct memory addressing modes, so that simplifies things. If the instructions are kept on die and not in externally addressable memory that makes things a little easier, but does not address how each node is loaded with instructions.
The only real challenge that I see would be the I/O. That's quite a few pins for most FPGA parts I've worked with. Maybe things have gotten easier in 15 years? The architecture design of the chip doesn't seem all that complicated, but clock cycles would not match the game.
The easiest way to handle I/O is to cheat; don't expose the internal channel interface but instead have some fake nodes at the edge of the grid which act as I/O processors with a message-passing interface.
For programming, add an instruction PROGRAM <val>. This writes <val> to program slot BAK and adds one to BAK. Each node starts with its program memory full of PROGRAM ANY and starts with BAK=0. To program a node, simply send the program to it, one word at a time. When the program counter wraps round, your program runs.
To initialise the network, have a serial EPROM connected to a fake I/O node. After startup, the contents of the ROM gets sent, one word at a time, on the I/O node's port. This programs the node it's attached to, which starts running; this then forwards messages on to the next node, which gets initialised and starts running, etc. That way you'd fill the network with message-forwarding programs. Once done, each node starting at the most remote would be overwritten with your real program, and once the root node gets overwritten initialisation is complete.
I think the message network misses one of the benefits of this architecture, and that is non-blocking execution at each node. As each node possesses it's own memory for instructions, it only blocks when it is in a read, waiting for another node to write, or when it is in write, waiting for another node to read. Your message network would imply a bus, which wouldn't scale arbitrarily.
Admittedly, a TIS-100 built like this "simulation" would be hard to program without some way of addressing each node.
You only use the message network for deployment --- you have to stream data from the boot source (attached to one node at the edge) to every node on the chip in order to program them, somehow. But since deploying the program onto a node requires erasing that node, once the network has finished deployment, it no longer exists.
Hmm... writing a TAS-100 simulator would be trivial. Maybe I could --- NO! I've got too many stupid projects on the go as it is!
it should be fun for kids to start learning to code. but then, the move things around like that may do more damage than good on understanding multicore :)
The most similar real world example that works like this is the GA144. 144 cores are laid out in a grid, and you pass data from one core to another by sending it "north", "south", "east" or "west".
It's a puzzle game, though, and probably aims less at being a practical teaching tool than a set of novel and obscure problems. If it teaches anything it'd be approaching odd problems in general, just like spacechem did.
TIS-100 is way more pleasurable to program on than real hardware. It is so easy to debug! Everything is visible.
People accomplished great things back in the 8-bit era with the tools they had, but the stuff they do today with the same hardware is truly mind blowing. I attribute that at least partially to things like that C64 emulator [1] where you can just view all of the system's memory during execution.
This game is brilliant, in case you haven't tried it. Also, it will teach you the true fury of stream programming with only twelve instructions and a single addressable register.
The instruction set design really deserves praise: people who haven't done assembly before report picking it up without too much trouble, and it manages to fit several opportunities for subtle tricks in the space of the 13 instructions.
The moment you realize that you can use JRO with a direction to control flow from another node, it feels like a genuine revelation while being immediately obvious and logical in hindsight.
JRO UP? As in pulling in a value from the up port. I didn't see how that gives me a whole lot since wouldn't I need to know in the other node what the offset would be? I considered that this would be valid, but I couldn't see a way to make it really useful.
It allows you to use another processor to do control flow based on an input, freeing up cpu time. For example, suppose you wanted to emit to DOWN:
0 if LEFT is <= 0
UP if LEFT is > 0
So you have two options
S: MOV LEFT ACC
JGE E
MOV 0 DOWN
MOV UP NIL
JMP S
E: MOV UP DOWN
Or you could do this:
S: JRO LEFT
MOV UP NIL
MOV 0 DOWN
JMP S
MOV UP DOWN
And left would send 1 if its value is <= 0, or 4 if it's >0. In this case it only saves one cycle for the node under consideration, but it could be a good deal more if the conditional is more involved.
This is much more familiar than the assembly in 0x10c. I haven't tried JRO with ports yet! I just assumed it would be an illegal operation :) Real instruction sets are clouding my mind.
> This game is kind of a throwback to the kinds of games I used to make
I think this is a very important part. Personally I enjoyed pre-spacechem games a lot (e.g. http://www.zachtronics.com/the-codex-of-alchemical-engineeri...) because they were difficult and because they were very simple. Spacechem got grander and it was still fun, but for my simple tastes infinifactory isn't bare enough.
It's not really intended as a replacement for reversing/assembly challenges: design-wise it's actually fairly similar to his previous games like SpaceChem, in that you're trying to break up solutions into discrete chunks that each individual node can handle.
The performance comparisons to other players is a brilliant feature, though.