Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: