TIS-100: An emulator for a CPU that doesn't exist
eviltrout.comThe game itself I love. But I have some issues with it's implementation.
To be specific, it maxes out the CPU even when it's not doing anything. Given that it's supposed to emulate low-level hardware, at very slow speeds, and does not have any demanding graphics, I fail to see why it should do that.
(It's something I've seen happening in more games as of late, actually. For example, Desktop Dungeons - a very fun game which has no business demanding anything from my computer since it's turn-based, uses sprites, and barely animated. And yet my laptop heats up as soon as I open the game.)
In fact, it's a bit ironic, given that the whole theme of the game is squeezing out performance out of bare metal hardware, and I admit that I'm more annoyed by it for that somewhat irrational reason.
IIRC TIS-100 is implemented using Unity, which doesn't really give you a lot of leeway as to when you update and render (e.g. you choose a framerate and it renders and updates your objects at that rate). Admittedly, since most of the time in TIS100 the screen does not change, if it were implemented using a custom engine this could be fixed.
For desktop dungeons, I'm not aware of the specifics about that game (though I have played it), but generally, if you're using OpenGL or DirectX to render, repainting only part of the screen isn't an option, so if anything is animated (no matter how slight the animation), you have to redraw the screen every frame. There are exceptions to this (like the mouse pointer, although this requires platform specific code), but not many of them.
As I mentioned in the other comment, perhaps the problem is poor Linux support on the Unity side of things? Which would be... how shall we say... typical, since Unity also targets mobile platforms. You'd think they'd allow developers to properly optimise for fan noise.
Regarding DD: first, it's also implemented in Unity, so... but that aside, even if the whole screen gets repainted, it shouldn't max out. The graphics are just not demanding enough for that.
Well, repainting at 30 or 60fps is going to heat up a lot of computers, demanding graphics or not.
Although you're probably right that it's mostly a Unity Linux support issue. My understanding is that Unity Linux support is mostly a labor of love from the Linux-using employees at Unity, and that it doesn't get a lot of attention other than that.
This is common with games nowadays. Almost no one throttles the game loop outside of mobile I guess. I've had the same issue with the Analog/Hate _visual novel_ series. My laptop doesn't need to turn into a lapheater for some text....
It's still in early access, perhaps a bug report to the developer would be in order? It doesn't do this on my machine, so it might not be occurring for them.
I am running Linux, I have to admit. Could be poor Unity support in that regard.
To be fair the TIS-100 runs slower in the game to improve the visuals. To let you see (albeit in a blur at higher speeds) your code run rather than a click button, instant "level complete" popup. (note: I don't own TIS-100 yet, but it's fairly similar to their other game spacechem)
I too wrote a TIS-100 simulator in C ( https://github.com/hthh/tis100sim ) - it's interesting to compare styles.
(I get a bunch of errors on OS X unless I change "CC=gcc" to "CC=clang", btw)
Well, I wrote one in Haskell, so there!
(Currently trapped in legal hell. I work for one of those annoying companies that claims ownership of everything I do, even in my personal time, so I have to get it cleared before I can push it to github...)
I added some extensions to allow one node to program another; the PROGRAM <dir> opcode resets the node in that direction, and it can then be fed a series of numbers which form the program. Once complete it starts executing.
With this, it ought to be possible to program an arbitrary network with programs from a boot ROM attached to a single node at the corner. It would have to propagate the distribution program through the network, which would then in turn propagate the program to the right place and reprogram each node in turn. Because a programmed node wouldn't contain the distribution program any more we'd have to start at the outer edge and work inwards.
I do wonder whether it would be possible to get real work done with this. I bet a node could be implemented in a tiny handful of FPGA gates.
There's a reason to move to Silicon Valley - its illegal in CA for a company to claim work you do on your own time.
This is not quite correct. Even out here in CA you still need permission if your employer has an invention assignment agreement.
They ask you to sign those, but the state doesn't permit them to claim inventions done on your time on your equipment. Don't be fooled.
What exactly constitutes "your time"? Is there a legal definition for this that appeared recently?
I had a long-drawn out conversation with Chris DiBona about this very question, and the answer is that it's very very murky, and most of the time -- even in California -- the corps can win.
You will still want to work with the company so there is proof that you both agree you are exempt.
You can't sign your rights away. The company document is void.
I'm not arguing that. Completely disregarding the void document, you will still want to document _and notify_ the company that your IP is in the exempt category.
I'm assuming the law is similar to Kansas Statute 44-130[0]
(d) Even though the employee meets the burden of proving the conditions specified in this section, the employee shall disclose, at the time of employment or thereafter, all inventions being developed by the employee, for the purpose of determining employer and employee rights in an invention.
[0]: http://www.kslegislature.org/li_2014/b2013_14/statute/044_00...
Ah! I'm following now. I'm not sure about CA disclosures. I know the Delaware company I'm at now, asked for one.
That gcc error is strange, since I think in the recent versions of OS X gcc is just an aliases for clang.
Here's my output of `gcc --version` on OS X 10.10:
edit: also, should've said that's really cool and thanks for posting your source code.Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posixMy GCC seems to be GCC (don't remember why - I guess I installed it for something). I can also make it build using "--std=c99" (but that makes the undefined behavior mentioned in issue #2 show up, which is why I went with clang).
gcc: warning: couldn't understand kern.osversion '14.3.0 gcc (GCC) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I just learned about your project today and it's fantastic! We must think alike.
Remember that notch's silly space game with a simulated processor and the huge influx of emulators and whatnot after the announcement?
There is a lot of DCPU-16 emulators on the wild. Also, there is a few successor games projects of 0x10c that uses DCPU-16 or his own cpu's
I've been looking for a simple computer/CPU simulator for kids to play on. Something like this http://thlorenz.com/visulator/ is almost there but it's a bit too complex for elementary/middle school level kids to start on. A game would be even better but the one we're discussing here (TIS-100) is basically designed to confuse and challenge rather than illuminate. Suggestions and pointers are extremely welcome.
http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html This virtual machine has been implemented many times in various programming languages. The retro forth download includes most of the implementations.
Zachtronics makes amazing games. This is the same guy who wrote SpaceChem and Infiniminer (the inspiration for Minecraft)
Is this a good way to get started with assembly?
It doesn't have much in the way of a tutorial yet - this PDF might be a better place to grow your understanding of Assembly Language: http://www.drpaulcarter.com/pcasm/
Thanks for the tip.
It would be interesting to implement the emulator using the PyPy toolchain.
oh this brings up memories of corewars and redcode
it's only a matter of time before someone runs linux on it.
Doubtful. Having only one usable register (plus another non-addressable "backup" register) places a (IMO) insurmountable constraint on running any multiuser unix-like kernel.
Well, the trick to the game is that you have multiple cores, each with their own register and a pipeline between them. This effectively gives you six registers, since you can bounce values back from the core on an edge register.
There are also "stack" cores, which store an arbitrary number of values and allow you to pop them back off.
If you were able to expand the system to have N cores of any type, I could easily imagine someone being able to compile C down to it.
That's a great point. Using other cores' registers is required to pass many scenarios in the game, and I'm embarrassed I forgot about the technique after being away for only a few days :) Thank you!
So Transputers again
MMIX