Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Here's another program, which also functions as a proof of the Turing-completeness of the virtual PC (well, technically just the same kind of almost-completeness C has, due to the available storage space not being infinite, but I think that's close enough for most purposes).

It's a proof by simulation, in that it implements an interpreter for a programming language which is already known to be Turing-complete, namely brainfuck.

I've tried to follow the implementors recommendations for BF, but the limitations of the underlying system make some of them difficult - as an example, output just goes to the screen in a binary format, instead of being displayed as characters, since there's no native character output and implementing it myself would take too much space (and be a project in its own right).

This program does work in Senbir's default mode, but in that mode it you only have 30 bytes of remaining space to distribute between the BF program and the memory tape it works on, which means you're quite limited in which BF programs you can run with it - and it's not particularly fast in that mode either (I'd guess about the same kind of usable as my Snake game, probably in large part because it uses the same overlay technique (and expects the overlay loader to be used as bootloader)).

However, if you use a mode with a larger disk, all that extra space will be available to the BF program or its tape, without changing the interpreter (beyond changing the BF program). It does not assume anything about the size of the disk (well, except for it being at least 256 words).

Since changing the BF program requires re-preprocessing the source code, for the interpreter to know where the BF program ends and its memory tape begins (it uses labels for this), it's not quite as easily reusable as I might like it to be - but at least it doesn't require manually changing the interpreter code itself.

The interpreter comes with a small example BF program which just reads characters from its input and writes them to its output, in an infinite loop.

Since the input comes from the keyboard and the output goes to the monitor, that allows the player to see what is going on and interact with it, though I'll admit it's not really all that interesting.

In theory you could create a BF implementation of a TC-06 simulator, run it in this interpreter, and then in that simulator run the interpreter again, etc... but I don't think I'd recommend it. :)

Since the interpreter source file is 472 lines long, I don't think I'll copy it in here - I'd say it's better to look in the git repository instead (which might even get updated if I find something more to fix).

FYI: The processed code is big enough, that in my install at least, Unity outright stops rendering text beyond a certain point in the code editor because of how long the string is.  "String too long for TextMeshGenerator. Cutting off characters."  Still functions normally, far as I can tell - the rendering's just messed up.

I can't say as that I've been able to test it yet, something's going wrong in my install that's preventing the processor from ticking as it should (probably just at low clockspeeds, like Default Mode's) - will update this when I fix whatever's broken.

All that being said: whoa.  This is a super neat idea, and I'm curious to know what one could actually pull off with it.  Given the proclivity of programmers to occasionally do utterly insane things (see also: Senbir itself, this interpreter, etc), there are tools for compiling/processing code from other languages into BF code, like this C compiler.  Though it's in a roundabout way, this does officially mean it's possible to write things in higher-level (?) languages, like C, and then run them in Senbir.  Would an OS or game made in Senbir-BF be usable?  Not in Default mode, or even Extended - I cannot begin to comprehend how slow it'd be with the base clockspeed of 60Hz.  Would it be a fun experiment?  Hell yeah, it would be!

(Also, sorry about kinda disappearing on everyone - I'm still working on the next update, but been sidetracked by playing Warframe, and working on Astronaut Plus Skateboard as of the past few weeks.)

I've seen that too, actually, Unity not rendering all the text. And yes, as far as I could tell too, it still worked, even allowed editing, it just didn't render all of it. I'd guess it's not really built for text-heavy applications. (At least not without some end-programmer effort to do things like split the text up into more manageable chunks.)

I don't see it much, though, probably in part since I've taken to minifying my code before pasting it in - not so much because of this, but because it means I don't have to scroll so much after pasting it in. (It's pretty easy to do, even - I just have the preprocessor output open in my editor, and use its regex replace to remove all instances of \s*//.*$ before I copy what remains. I've been thinking of making the preprocessor do it, but haven't bothered yet - dunno if I will.)

In theory, one could pull off essentially anything (computation-wise anyway) with it. In practice, though - what someone actually manages to do - yeah, that's where the interest lies, indeed. :) (I'll probably not do much/anything with BF myself, as making the asm do what I want in the space I have is tricky enough, but I certainly don't mind if others do.)

I'll note that clockspeed isn't the only problem for this with the default mode, I'd think the disk space is a bigger problem. I haven't tried it, so I'm making assumptions here, but I figure that anything even semi-significant having been compiled down to BF is likely to be large - and there's not really much space available here.

Also, the output method this interpreter uses means that it's even more limited than usual in user interaction, so game-type stuff is rather limited by that. OS-type stuff similarly. The thing about Turing-completeness is that it only talks about computation - and a lot of what modern computers do isn't really about that, instead involving things like real-time user interaction. Sure, a program on a Turing-complete computer could simulate such user interaction - but then it wouldn't be actual user interaction, now would it?

Still, even with those limitations, there's quite a lot that is possible. All it needs is for someone crazy enough to actually do it to come along... :)

The disk space and low computation speeds are both major issues, especially for the Default mode (I think you've probably made a program as fancy as is possible with your text echoer), but would probably be easier to handle with, say, the stats I have set up for working on SenbOS.

One major way I see to potentially improve the ability to make fancy stuff (like OSes, games, etc), would be to replace the current IO stream's binary representation with one pixel on an 8-bit-color monitor.  You'd have to choose between an 8-bit RGB palette (with 3 bits of R & G and 2 B, or similar), or an 8-bit grayscale, BUT, the payoff would be that actual output would likely be faster, and you can actually draw on a pixel-by-pixel basis with relative ease - the main challenge becomes picking where the pixel actually gets drawn (e.g, where in the 1-dimensional array of currentPixels is the output pointer), and I'm not sure if there's a way TO pick that.  Need to poke through the interpreter code more.

If that is possible, then the main issue remaining is that getting mouse input is impossible, and as such your OS probably has to be either command-line, or you control the mouse cursor with arrow keys or something.  Also, no first person shooters, but that's kind of a given with the super-low processor speed :P