7 ms·

Lessons Learned from Shenzhen I/O

319 points by akkartik 10y ago

mmastrac 10y ago
The tests are an important part of the lesson for certain. Even better is the lesson that throwing a test spec over the wall to your development team may result in them writing code that passes the test but isn't necessarily ideal for production. I've played many hours of this game and have committed many grievous programming sins to improve my scores.
- legulere 10y ago
  > throwing a test spec over the wall to your development team may result in them writing code that passes the test but isn't necessarily ideal for production. This is also known as Goodhart's law: https://en.m.wikipedia.org/wiki/Goodhart%27s_law https://en.m.wikipedia.org/wiki/Goodhart%27s_law
- otakucode 10y ago
  That sounds similar to an XY problem. You actually need help with X, but you think you already know how to go about it so you ask about your approach, Y, instead... resulting in whatever answers you get being much worse than if you had actually clearly explained what you were doing in the first place.
saboot 10y ago
A few of the lessons he talked about I've seen repeated on Casey Muratori's "Handmade Hero" series. Specifically point #3, he talked early on about writing simple code that fulfills one metric: it works. Afterwards you can see the implicit parts that should be made into functions, remove code duplication, and clean things up. However having that "full view" of a chunk of code makes the process easier. Also point #4, he writes an interactive write-compile-test system using an executable hooking into a shared library which contains all of your code. That way you can compile and see the results quickly on a still running executable of your game. Very fast feedback without having to "respawn" to a part of your game to test.
ketralnis 10y ago
> Only once you know for a fact that a better solution is possible can you actually think of that solution This section reminded me of something a friend posited about space travel. There are some inventions that just being exposed to the idea of them is enough to invent them. For instance, it seems that cultures that encounter others that have written language fairly quickly invent their own, even without knowledge of how the others work. The Cherokee syllabary was invented by an illiterate silversmith in the 1820s after he saw other people communicating via paper and knew that they represented a way to transmit information (https://en.wikipedia.org/wiki/Sequoyah#Sequoyah_and_Cherokee_literacy https://en.wikipedia.org/wiki/Sequoyah#Sequoyah_and_Cherokee...). The writing system that he invented was a syllabary, not an alphabet like the people he'd been observing or a logographic system like some other Native American languages. Having a writing system is a contagious idea all its own and knowing that they exist is sufficient to invent one. It may be that efficient space travel is one of these inventions: just seeing someone else do it may be enough to invent it ourselves. I don't mean in the sense that we may observe details that give us hints as to how it works (though that's probably also true), I mean in the way that the article says "If nobody had gotten to the score of 180 before me, I couldn’t have thought of any faster way of solving this puzzle. Without that piece of information, the brain just comes up with reasons why the score is already optimal". Simply observing working space travel may be enough for us to invent it ourselves. We may even invent a system entirely unlike the one we observed.
- Frqy3 10y ago
  The idea of using a fake result to break a paradigm has been used in a number of science fiction stories. I believe that the earliest is "Noise Level" (1952) by Raymond F. Jones, though the idea originated with John W. Campbell [0]. I first came across this concept in Robert Silverberg's "Double Dare" (1956) [1]. [0] https://nevalalee.wordpress.com/2016/09/28/astounding-stories-18-noise-level/ https://nevalalee.wordpress.com/2016/09/28/astounding-storie... [1] https://archive.org/stream/galaxymagazine-1956-11/Galaxy_1956_11#page/n73/mode/2up https://archive.org/stream/galaxymagazine-1956-11/Galaxy_195...
  - toolslive 10y ago
tofflos 10y ago
To the author of the article: I'm jealous you found such a great friend to play the game with. ;-) I found the game interesting but without social interaction it wasn't able to keep me engaged... So I uninstalled it after a day or so. Secondly... I reinstalled the game and opened up the second puzzle to see what my score was. Surely _my_ solution must have been better than the standard 240? Nope! Now I'm scratching my head trying to figure out how you did it. You bastard! ;-)
- piggybox 10y ago
  Same here. I'm gonna lose a few days of sleep thanks to the author.
  - TeMPOraL 10y ago
    Me too. Also a friend of mine installed TIS-100 just last night and started working on beating my scores, so I need to take care of that too!
    - otakucode 10y ago
      Yeh, I haven't tried Shenzen I/O yet, though I intend to. But I've played TIS-100 and I actually got into it because I saw people on IRC competing via leaderboards with one another. It's quite fun.
- gravypod 10y ago
  > I'm jealous you found such a great friend to play the game with. ;-) I found the game interesting but without social interaction it wasn't able to keep me engaged... So I uninstalled it after a day or so. I'm in a university, surrounded by people who do this sort of thing for fun, and no one I know will play the game. We've come to jokingly call it "work-simulator" and most people I've talked to who should enjoy this game just see "oh no it's work".
  - StavrosK 10y ago
    My reaction was pretty much the same. Not really "oh no, it's work", but "if I'm going to code, I want to code something other people (and I) can use. For example, a friend and I had a few spare hours, so we made this: https://www.timetaco.com/ https://www.timetaco.com/ That sort of thing seems like a better use of my time than playing a game. Then again, there are times when I just want to play a game, and I don't want to code, so I don't begrudge anyone how they choose to spend their time.
db48x 10y ago
Shenzhen I/O is indeed amazing. Most Zachtronics games are at least great.
doublerebel 10y ago
This is why I love learning and writing in multiple programming languages. The abstractions and advantages in each language push me to search out the best in whatever language I'm working in at the time, rather than being limited by the common paradigms in that language.
xt00 10y ago
In all seriousness, I was expecting the article to be like "on nov 5th, I went to Shenzhen to attend the annual Shenzhen I/O hardware hacker conference.. and boy was I blown away.. lots of cool stuff people are working on..".. then I'm like, um, a game? what?
- qwertyuiop924 10y ago
  It's not just a game: it's a Zachtronics game.
  - alphapapa 10y ago
    Excuse the intrusion, but there's no PM system on HN... I've noticed your recent, prolific rise to prominence here on HN. You seem to have come out of nowhere and shot past most other users whose accounts are much older. I would be interested in reading an article from you on what you've learned and observed over the past year. [Boy, harsh. It's not like there's an email address on the guy's profile. Guess I should have contacted him telepathically. Yet another reminder to keep showdead on.]
    - qwertyuiop924 10y ago
      Gee. I had a prolific rise to prominence? I didn't notice. I'm certainly one of the less interesting and skilled people on this forum, so I'm frankly baffled. Well, since you asked... The most important thing that I've learned is that it's a good idea to put yourself out there: Say what you think, be honest, and be ready to defend your ideas (but also be ready to admit you were wrong if you find out that you are). Also, don't worry about the possibility saying something stupid. Some of the best conversations I've had on HN happened because I said something stupid: If you say something stupid, that usually means that you aren't well educated in that area, and hold misconceptions. It's best to get those misconceptions out there, so that you'll know that they're wrong. Remember to attack ideas, not people. Even when you really, really, want to attack people. It's not worth it. Don't focus on your karma too much: just because you got downed doesn't mean it wasn't worth saying.
pmontra 10y ago
I remember when a friend and I started optimizing a DES library in C at university in 1990. We had the same dynamics of the post, each other skimming off some cycles even when we thought that one of us got to an unbeatable implementation. We obviously had tests to prove correctness and measure speed. Bizarrely there weren't many tests around in the industry back then. I can't remember when I wrote my first unit test after then.
rockdoe 10y ago
The predecessor TIS100 is in the current Humble Bundle. Most of the stuff from the post applies, save maybe the story aspect.
- jbpetersen 10y ago
  Plus Infinifactory in the Beat The Average level of the bundle, which is another Zachtronics game.
Mithaldu 10y ago
He makes one observation in which makes a small but important mistake: When he mentions tests he calls them first unit tests, then automated tests. And yes, unit tests usually are automated. They are however just one type of automated test, and at the smallest scale too. Integration and system tests are just as important and can give much more bang for much less buck.
- brian-armstrong 10y ago
  This is a good point. The tests in the game are integration tests, and only mediocre ones at that
vasili111 10y ago
What you think about Shenzhen I/O vs TIS-100 ?
- cprecioso 10y ago
  Shenzhen I/O is an improved TIS-100. The story is much more worked on, and also has the solitaire aame extra (it's fantastic). Also, to some extent, Shenzhen I/O = TIS-100 + SpaceChem
- brian-armstrong 10y ago
  I'd say TIS-100 is the better game. But I think that's just because it favors a style of optimization that I really enjoy. Ultimately that's what I think it will come down to. TIS-100 felt more like building some interconnected pipeline but Shenzhen feels more microcontroller-y
- psyc 10y ago
  It's a very polished (graphics, UI, story) and expanded (many more chip types) sequel.
RossBencina 10y ago
I don't really see the point of these TIS-100 style games that use made-up instruction sets. Wouldn't it be more interesting if the game used a real instruction set (e.g. AVR, x86)? Then we could be learning something useful while playing, and make use of the results.
- MichaelBurge 10y ago
  The instruction set is finely tuned to make interesting puzzles. Most of my time in each puzzle was spent trying to cram 1 more instruction into a chip here or there. Since real instruction sets have to be practical for production use, I imagine it would be harder to get the same effect. Plus you wouldn't get cool features like being able to conditionally execute every instruction.
  - RossBencina 10y ago
    > Since real instruction sets have to be practical for production use, I imagine it would be harder to get the same effect. I'm not so sure. Have you ever hand-optimised asm? I recall spending hours if not days trying to reduce the instruction count by 1 or 2 instructions in a tight DSP loop (Motorola 56k). It always seems like an interesting puzzle to me.
  - salicideblock 10y ago
    > Plus you wouldn't get cool features like being able to conditionally execute every instruction. You would be very close if it were ARM :) My wild guess is that the developer wisely chose to sidestep imbalance towards parts of his public and any possible IP issues on the IS. Plus if he writes this kind of games he probably had fun writing his own IS.
  - tech2 10y ago
    ARM had that early on, all instructions were conditional, but with many more condition codes: https://en.wikipedia.org/wiki/ARM_architecture#Conditional_execution https://en.wikipedia.org/wiki/ARM_architecture#Conditional_e...
- qwertyuiop924 10y ago
prashnts 10y ago
It really is an interesting game. I'd first started with this sort of genre playing Human Resource Machine, which simulates a single accumulator architecture, and very interesting set of puzzles. The puzzles really are just standard sorting, string reversal, prime factorization. The best part I find about it is the way Pointers and Memory allocation/access and stack access is done. I'd recommend this game very much as the puzzles aren't very hard and the progress is really satisfying. Shenzhen I/O is a great game too! But I got stuck at one point and as another comment points out, I also gave up on it. Maybe it's time to log into Steam. :) [*] https://tomorrowcorporation.com/humanresourcemachine https://tomorrowcorporation.com/humanresourcemachine
trishume 10y ago
Great article, I too loved this game. In fact the article prompted me to fire it up again and figure out the tricks to match his 148 on the 2nd problem and it was really fun. Now for that second campaign...
jpatte 10y ago
For those wondering (spoilers), the puzzle he's talking about in section 2 ("the second puzzle in the game") is a simple puzzle where you just have to double the values provided as input to produce an output. The naive solution at 240 points he mentions is extremely straightforward: mov p0 acc # place input value into internal register mul 2 # multiply register by 2 mov acc p1 # place register value into output slp 1 # sleep 1 cycle, wait for next input The only way (I can think of) to optimize this is by cheating, i.e. by writing an algorithm specifically fitted for the kind of input we have to deal with. Looking at the input, we see that for example there are only 3 input values (0, 25 and 50) and there seems to be more zeros than other values. Based on this info we can try to predict what value is likely to show up as input and follow a dedicated path to handle it, in order to be as efficient as possible. I must admit I was happy with the 240 solution and never thought there was a better way until I read this article. Now I feel obliged to at least go down to 156 :D
- jessermeyer 10y ago
  >The only way (I can think of) to optimize this is by cheating, i.e. by writing an algorithm specifically fitted for the kind of input we have to deal with. Programmers must stop equating cheating with engineering.
contingencies 10y ago
You can't optimize for all three judged outputs (production cost, power usage, lines of code) at once. For this reason, you can replay every level three times with a different optimization goal. Some of the optimization techniques I found before life took my interest away from the game (we[0] are building a real embedded system of significant complexity, and actually visited Shenzhen a few months ago) were judicious use of leading @SLP (usually as a final optimization), use of memory (acquired later in the game) instead of processing inputs, careful investigation of the limited use of conditionals to split codepaths, and basic addition using shared buses. [0] http://8-food.com/ http://8-food.com/
cdevs 10y ago
Some of the related videos for their intro video on their site are great and make me want to try it. There was one of a guy who created a old school 3D maze with random generated levels and one wich played the whole "rick roll" song . It amazes me we can simulated computers and hardware in a computer with this depth ...inception level 1

319 points by akkartik 10y ago

The tests are an important part of the lesson for certain. Even better is the lesson that throwing a test spec over the wall to your development team may result in them writing code that passes the test but isn't necessarily ideal for production. I've played many hours of this game and have committed many grievous programming sins to improve my scores.

legulere 10y ago
> throwing a test spec over the wall to your development team may result in them writing code that passes the test but isn't necessarily ideal for production. This is also known as Goodhart's law: https://en.m.wikipedia.org/wiki/Goodhart%27s_law https://en.m.wikipedia.org/wiki/Goodhart%27s_law
otakucode 10y ago
That sounds similar to an XY problem. You actually need help with X, but you think you already know how to go about it so you ask about your approach, Y, instead... resulting in whatever answers you get being much worse than if you had actually clearly explained what you were doing in the first place.

saboot 10y ago

A few of the lessons he talked about I've seen repeated on Casey Muratori's "Handmade Hero" series. Specifically point #3, he talked early on about writing simple code that fulfills one metric: it works. Afterwards you can see the implicit parts that should be made into functions, remove code duplication, and clean things up. However having that "full view" of a chunk of code makes the process easier. Also point #4, he writes an interactive write-compile-test system using an executable hooking into a shared library which contains all of your code. That way you can compile and see the results quickly on a still running executable of your game. Very fast feedback without having to "respawn" to a part of your game to test.

ketralnis 10y ago

> Only once you know for a fact that a better solution is possible can you actually think of that solution This section reminded me of something a friend posited about space travel. There are some inventions that just being exposed to the idea of them is enough to invent them. For instance, it seems that cultures that encounter others that have written language fairly quickly invent their own, even without knowledge of how the others work. The Cherokee syllabary was invented by an illiterate silversmith in the 1820s after he saw other people communicating via paper and knew that they represented a way to transmit information (https://en.wikipedia.org/wiki/Sequoyah#Sequoyah_and_Cherokee_literacy https://en.wikipedia.org/wiki/Sequoyah#Sequoyah_and_Cherokee...). The writing system that he invented was a syllabary, not an alphabet like the people he'd been observing or a logographic system like some other Native American languages. Having a writing system is a contagious idea all its own and knowing that they exist is sufficient to invent one. It may be that efficient space travel is one of these inventions: just seeing someone else do it may be enough to invent it ourselves. I don't mean in the sense that we may observe details that give us hints as to how it works (though that's probably also true), I mean in the way that the article says "If nobody had gotten to the score of 180 before me, I couldn’t have thought of any faster way of solving this puzzle. Without that piece of information, the brain just comes up with reasons why the score is already optimal". Simply observing working space travel may be enough for us to invent it ourselves. We may even invent a system entirely unlike the one we observed.

Frqy3 10y ago
The idea of using a fake result to break a paradigm has been used in a number of science fiction stories. I believe that the earliest is "Noise Level" (1952) by Raymond F. Jones, though the idea originated with John W. Campbell [0]. I first came across this concept in Robert Silverberg's "Double Dare" (1956) [1]. [0] https://nevalalee.wordpress.com/2016/09/28/astounding-stories-18-noise-level/ https://nevalalee.wordpress.com/2016/09/28/astounding-storie... [1] https://archive.org/stream/galaxymagazine-1956-11/Galaxy_1956_11#page/n73/mode/2up https://archive.org/stream/galaxymagazine-1956-11/Galaxy_195...
- toolslive 10y ago

tofflos 10y ago

To the author of the article: I'm jealous you found such a great friend to play the game with. ;-) I found the game interesting but without social interaction it wasn't able to keep me engaged... So I uninstalled it after a day or so. Secondly... I reinstalled the game and opened up the second puzzle to see what my score was. Surely _my_ solution must have been better than the standard 240? Nope! Now I'm scratching my head trying to figure out how you did it. You bastard! ;-)

piggybox 10y ago
Same here. I'm gonna lose a few days of sleep thanks to the author.
- TeMPOraL 10y ago
  Me too. Also a friend of mine installed TIS-100 just last night and started working on beating my scores, so I need to take care of that too!
  - otakucode 10y ago
    Yeh, I haven't tried Shenzen I/O yet, though I intend to. But I've played TIS-100 and I actually got into it because I saw people on IRC competing via leaderboards with one another. It's quite fun.
gravypod 10y ago
> I'm jealous you found such a great friend to play the game with. ;-) I found the game interesting but without social interaction it wasn't able to keep me engaged... So I uninstalled it after a day or so. I'm in a university, surrounded by people who do this sort of thing for fun, and no one I know will play the game. We've come to jokingly call it "work-simulator" and most people I've talked to who should enjoy this game just see "oh no it's work".
- StavrosK 10y ago
  My reaction was pretty much the same. Not really "oh no, it's work", but "if I'm going to code, I want to code something other people (and I) can use. For example, a friend and I had a few spare hours, so we made this: https://www.timetaco.com/ https://www.timetaco.com/ That sort of thing seems like a better use of my time than playing a game. Then again, there are times when I just want to play a game, and I don't want to code, so I don't begrudge anyone how they choose to spend their time.

db48x 10y ago

Shenzhen I/O is indeed amazing. Most Zachtronics games are at least great.

doublerebel 10y ago

This is why I love learning and writing in multiple programming languages. The abstractions and advantages in each language push me to search out the best in whatever language I'm working in at the time, rather than being limited by the common paradigms in that language.

xt00 10y ago

In all seriousness, I was expecting the article to be like "on nov 5th, I went to Shenzhen to attend the annual Shenzhen I/O hardware hacker conference.. and boy was I blown away.. lots of cool stuff people are working on..".. then I'm like, um, a game? what?

qwertyuiop924 10y ago
It's not just a game: it's a Zachtronics game.
- alphapapa 10y ago
  Excuse the intrusion, but there's no PM system on HN... I've noticed your recent, prolific rise to prominence here on HN. You seem to have come out of nowhere and shot past most other users whose accounts are much older. I would be interested in reading an article from you on what you've learned and observed over the past year. [Boy, harsh. It's not like there's an email address on the guy's profile. Guess I should have contacted him telepathically. Yet another reminder to keep showdead on.]
  - qwertyuiop924 10y ago
    Gee. I had a prolific rise to prominence? I didn't notice. I'm certainly one of the less interesting and skilled people on this forum, so I'm frankly baffled. Well, since you asked... The most important thing that I've learned is that it's a good idea to put yourself out there: Say what you think, be honest, and be ready to defend your ideas (but also be ready to admit you were wrong if you find out that you are). Also, don't worry about the possibility saying something stupid. Some of the best conversations I've had on HN happened because I said something stupid: If you say something stupid, that usually means that you aren't well educated in that area, and hold misconceptions. It's best to get those misconceptions out there, so that you'll know that they're wrong. Remember to attack ideas, not people. Even when you really, really, want to attack people. It's not worth it. Don't focus on your karma too much: just because you got downed doesn't mean it wasn't worth saying.

pmontra 10y ago

I remember when a friend and I started optimizing a DES library in C at university in 1990. We had the same dynamics of the post, each other skimming off some cycles even when we thought that one of us got to an unbeatable implementation. We obviously had tests to prove correctness and measure speed. Bizarrely there weren't many tests around in the industry back then. I can't remember when I wrote my first unit test after then.

rockdoe 10y ago

The predecessor TIS100 is in the current Humble Bundle. Most of the stuff from the post applies, save maybe the story aspect.

jbpetersen 10y ago
Plus Infinifactory in the Beat The Average level of the bundle, which is another Zachtronics game.

Mithaldu 10y ago

He makes one observation in which makes a small but important mistake: When he mentions tests he calls them first unit tests, then automated tests. And yes, unit tests usually are automated. They are however just one type of automated test, and at the smallest scale too. Integration and system tests are just as important and can give much more bang for much less buck.

brian-armstrong 10y ago
This is a good point. The tests in the game are integration tests, and only mediocre ones at that

vasili111 10y ago

What you think about Shenzhen I/O vs TIS-100 ?

cprecioso 10y ago
Shenzhen I/O is an improved TIS-100. The story is much more worked on, and also has the solitaire aame extra (it's fantastic). Also, to some extent, Shenzhen I/O = TIS-100 + SpaceChem
brian-armstrong 10y ago
I'd say TIS-100 is the better game. But I think that's just because it favors a style of optimization that I really enjoy. Ultimately that's what I think it will come down to. TIS-100 felt more like building some interconnected pipeline but Shenzhen feels more microcontroller-y
psyc 10y ago
It's a very polished (graphics, UI, story) and expanded (many more chip types) sequel.

RossBencina 10y ago

I don't really see the point of these TIS-100 style games that use made-up instruction sets. Wouldn't it be more interesting if the game used a real instruction set (e.g. AVR, x86)? Then we could be learning something useful while playing, and make use of the results.

MichaelBurge 10y ago
The instruction set is finely tuned to make interesting puzzles. Most of my time in each puzzle was spent trying to cram 1 more instruction into a chip here or there. Since real instruction sets have to be practical for production use, I imagine it would be harder to get the same effect. Plus you wouldn't get cool features like being able to conditionally execute every instruction.
- RossBencina 10y ago
  > Since real instruction sets have to be practical for production use, I imagine it would be harder to get the same effect. I'm not so sure. Have you ever hand-optimised asm? I recall spending hours if not days trying to reduce the instruction count by 1 or 2 instructions in a tight DSP loop (Motorola 56k). It always seems like an interesting puzzle to me.
- salicideblock 10y ago
  > Plus you wouldn't get cool features like being able to conditionally execute every instruction. You would be very close if it were ARM :) My wild guess is that the developer wisely chose to sidestep imbalance towards parts of his public and any possible IP issues on the IS. Plus if he writes this kind of games he probably had fun writing his own IS.
- tech2 10y ago
  ARM had that early on, all instructions were conditional, but with many more condition codes: https://en.wikipedia.org/wiki/ARM_architecture#Conditional_execution https://en.wikipedia.org/wiki/ARM_architecture#Conditional_e...
qwertyuiop924 10y ago

prashnts 10y ago

It really is an interesting game. I'd first started with this sort of genre playing Human Resource Machine, which simulates a single accumulator architecture, and very interesting set of puzzles. The puzzles really are just standard sorting, string reversal, prime factorization. The best part I find about it is the way Pointers and Memory allocation/access and stack access is done. I'd recommend this game very much as the puzzles aren't very hard and the progress is really satisfying. Shenzhen I/O is a great game too! But I got stuck at one point and as another comment points out, I also gave up on it. Maybe it's time to log into Steam. :) [*] https://tomorrowcorporation.com/humanresourcemachine https://tomorrowcorporation.com/humanresourcemachine

trishume 10y ago

Great article, I too loved this game. In fact the article prompted me to fire it up again and figure out the tricks to match his 148 on the 2nd problem and it was really fun. Now for that second campaign...

jpatte 10y ago

For those wondering (spoilers), the puzzle he's talking about in section 2 ("the second puzzle in the game") is a simple puzzle where you just have to double the values provided as input to produce an output. The naive solution at 240 points he mentions is extremely straightforward: mov p0 acc # place input value into internal register mul 2 # multiply register by 2 mov acc p1 # place register value into output slp 1 # sleep 1 cycle, wait for next input The only way (I can think of) to optimize this is by cheating, i.e. by writing an algorithm specifically fitted for the kind of input we have to deal with. Looking at the input, we see that for example there are only 3 input values (0, 25 and 50) and there seems to be more zeros than other values. Based on this info we can try to predict what value is likely to show up as input and follow a dedicated path to handle it, in order to be as efficient as possible. I must admit I was happy with the 240 solution and never thought there was a better way until I read this article. Now I feel obliged to at least go down to 156 :D

jessermeyer 10y ago
>The only way (I can think of) to optimize this is by cheating, i.e. by writing an algorithm specifically fitted for the kind of input we have to deal with. Programmers must stop equating cheating with engineering.

contingencies 10y ago

You can't optimize for all three judged outputs (production cost, power usage, lines of code) at once. For this reason, you can replay every level three times with a different optimization goal. Some of the optimization techniques I found before life took my interest away from the game (we[0] are building a real embedded system of significant complexity, and actually visited Shenzhen a few months ago) were judicious use of leading @SLP (usually as a final optimization), use of memory (acquired later in the game) instead of processing inputs, careful investigation of the limited use of conditionals to split codepaths, and basic addition using shared buses. [0] http://8-food.com/ http://8-food.com/

cdevs 10y ago

Some of the related videos for their intro video on their site are great and make me want to try it. There was one of a guy who created a old school 3D maze with random generated levels and one wich played the whole "rick roll" song . It amazes me we can simulated computers and hardware in a computer with this depth ...inception level 1