Designing Zachtronics' TIS-100(gamasutra.com)
gamasutra.com
Designing Zachtronics' TIS-100
http://gamasutra.com/view/news/244969/Things_we_create_tell_people_who_we_are_Designing_Zachtronics_TIS100.php
5 comments
I had the same thing with SpaceChem.
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.
Great game, but it's like catnip for programmers.
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.
Great game, but it's like catnip for programmers.
Reminds me of an article that came up on HN a few weeks ago:
Why Do We Play Video Games That Feel Like Work? - https://news.ycombinator.com/item?id=9495141
Why Do We Play Video Games That Feel Like Work? - https://news.ycombinator.com/item?id=9495141
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 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.
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.
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!
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.
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.
Just think of them as unbuffered channels.
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.
[1] http://icu64.blogspot.com/2009/09/first-public-release-of-ic...
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.
[1] http://icu64.blogspot.com/2009/09/first-public-release-of-ic...
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.
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.
Well I hadn't realized that. This. Changes. Everything.
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
S: MOV LEFT ACC
JGE E
MOV 0 DOWN
MOV UP NIL
JMP S
E: MOV UP DOWN
S: JRO LEFT
MOV UP NIL
MOV 0 DOWN
JMP S
MOV UP DOWN
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.
I was having trouble just last night: "Just one more instruction in this cell! Just one more, please!"
I did notice that you can shorten labels to fit another line of code in, though :)
I did notice that you can shorten labels to fit another line of code in, though :)
[deleted]
> 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.
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.
This is neat, but you can do some real hacking on software with something like http://www.ollydbg.de/
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.