A viable way to support RaspberryPi (with linux)

[carlsmith]

Issue #618 (A viable way to support RaspberryPi (with baremetal)) suggests running TIC-80 without an OS. It's a really cool idea, but I wanted to explore something less ambitious.

Based on previous feedback, it looks like TIC-80 will run on the Model 3 B, though the device struggles to run some games. The 3B+ uses the same CPU, but (due to improved cooling) it's clocked at 1.4GHz (instead of throttled at 1.2GHz).

It would be relatively trivial to derive a distribution from Raspbian Lite that boots directly into TIC-80, on top of X (without a desktop environment or window manager).

The OS can be configured to render each soft pixel as a block of hard pixels (like TIC-80 does), so TIC-80 could run without scaling, leaving the OS to do it, which would make the mouse behaviour legit too.

You can swap the OS on a RPi by just swapping the Micro SD card, so creating a distro that's optimised for one thing (Chrome, Kodi, RetroPie et cetera) is normal.

Using Linux under the hood gives us a ton of functionality for free, even if end users do not directly use it (a bit like Chrome OS).

A bespoke distribution can bundle all of the supported languages and plugins, all the best games and demos, and any extra resources, like spritesheets and libraries.

On performance, Raspbian is optimised for the RPi hardware, so makes full use of the GPU. If the baremetal approach doesn't do that, the benefits of dropping the OS are less obvious.

It's also part of the fun to create games in a limited environment, so having to also work within the 3B+ hardware limitations isn't an issue for people who want to support that 'console'.

I have a few ideas about the approach I'm suggesting here (and am willing to work on this), but it's already a long post, and would like to hear what other people think.

TLDR: Use RPi 3B+ to create a physical clone of a fantasy console.

[greywire]

I really want to see this happen.

I've been noodling about the best way to teach programming (I have a 10 year old son) to the new generation. I've concluded that there's nothing existing today thats the equivalent of what I grew up with (sinclair, commodore, etc). I considered creating some kind of simplified virtual machine, when I found Tic-80, which is almost exactly what I wanted.

I want to see this, or something like it, running as close to the metal as possible, to create a modern equivalent of an 80's pc. I don't have the time to develop this myself, I was hoping to get Tic-80 running on my raspberry pi.

I want to focus on developing the educational tutorials using a system like this. I think there is something to be said for, yes, PAPER! You then have to actually type in the commands. Just like in the old days of typing in a game from a magazine.

At any rate, I have not been able to compile tic-80 on my PI...

[carlsmith]

@greywire - A tutorial for installing TIC-80 on the new Raspbian (Stretch) would be really useful (I failed when I tried to install it too).

My motivations are educational as well. I'd like to do something similar to what you described, but any issues with setting up the student's environment are always a nightmare.

The only other issue I can see with using TIC-80 to teach coding is the code editor. Using an external editor with TIC-80 is clunky, ruins the experience, and creates one more complication for noobs. Generally, addressing a usability issue by recommending users use something else has to be a temporary solution. I personally use the builtin editor (with the smaller font), but new programmers need any help with readability they can get.

Does anyone know if there's a plan for improving the internal code editing solution?

[greywire]

I had trouble getting it to compile even on my ubuntu box (problems I think with 16.04 version).

I like tic-80 and it comes really close to what I am looking for.

I am also thinking about the posibility of developing something more hardware based in lock-step with the software. Something like an arduino or STM32 board or ESP8266 or something, paired with a small low res tft display, and a simple keyboard. I like the idea of Lua because I think its simple enough to learn with (like BASIC was in the old days) but more usable as you advance.

Have a complete, self contained little device thats powerful enough to run fun games and easy to program but with none of the distractions of being internet connected with an app store honeypot of games, I think is a good thing...

[carlsmith]

I like tic-80 and it comes really close to what I am looking for.

It is really nice, and the built in editor might get upgraded to use a higher resolution (#723) soon, which was my only issue (beyond installation issues, which should improve over time).

I am also thinking about the posibility of developing something more hardware based in lock-step with the software.

Have you looked at CToy? It might be a good starting point for that kind of thing.

[hseiken]

Just as a point of view, and not to make any assertions on talent involved with this project, limitations of OS layers, etc., I think it's important to point out the extremely odd aspects of making a fantasy 8 bit console that has trouble running even a 1.2Ghz device when the devices it aims to simulate were generally clocking in at 2-10mhz.

I just wanted to point that out. I understand that the older systems were made to run fast through using highly optimized assembly, but even still I think the fact that emulators like MAME can operate similar hardware to what TiC-80's functionality aims to be on even a 200mhz computer should at least be a motivator to raise the optimization standards of the system. Pico8 is essentially done and won't be further optimized in anyway. I also understand that both systems aim to be run byte identically with virtual machines running on the web which presents it's own challenges and adds it's own layer of complexity adding the need for faster machines to function at an acceptable speed.

These problems, however, should not necessarily be inherent for native versions and as a user with slow hardware as well, I can point out at least one example where these functionalities are present and work at nearly 100x speed of TiC80. One such product is DivStudio by MikeDX of DivArena. The original project was actually developed for DOS, but essentially has the same goal of TiC80; an all-in-one playground with a scripting language and graphics editor, though it was designed as a professional tool for it's time and required systems of about 166mhz as baseline for running, but yet featured 16 bit graphics, and even had a 'mode 7' feature which operated almost identically to the SNES mode 7 allowing a deformable background image. It also allowed all sprites (up to 256 I believe) to be scaled and rotated in real time, but did some very nice things to keep the speed, namely completely getting rid of floating point math within it's custom scripting language. I think optimizations like this are sorely needed and definitely work wtihin the concept for which TiC80 wishes to exist in.

In the case of Div Studio, instead of scaling of 1x starting at the literal 1, a normal sized object is actually a 1000 and can go up to 65535 and down to 1. All values were like this and if the need for decimal points was present, you can split a number up manually by telling the system where to put the decimal point after it does the integer math since a decimal point is simply created by multiplying by .1 etc., which can be a command to shift the decimal over visually, but the value is treated internally as an integer.

I don't know how much this would optimize TiC80, nor know if Lua would be capable of being limited in this way without major changing of it's core, but I assume that it does take a major load off of the system to get it to run faster and has the side effect of dealing with numbers the way 8 bit computers dealt with them; there was a lot of speed loss if you were creating a decimal point with 20 digits to the right of the decimal. What is really desireable from DivStudio is that this speed was translated over to windows, Linux and Mac; the resulting games made are ridiculously fast even on slow computers (anyone with a Pi should be able to verify this).

To it's credit, it does internally compile it's code, and I'm not especially knowledgeable if this is how Lua works. Maybe simply adding a compiler layer to Lua for speed optimizations could a lot for speed gains, I just don't know as that's not my field of expertise.

I just wanted to chime in by citing comparative systems, and try to point out the seemingly odd aspect of a 1.4Ghz system unable to run at a decent speed a virtual machine intended to look like it was a 3mhz system. This alone makes me scratch my head and begs the question of whether things are really optimized or thought out enough.

And just to be fair, Pico8 has the same problems as TiC80 and likely has the same base reasons for those problems...if TiC80 overcame them, especially in the speed of execution and display department, I think it would be a very attractive difference.

I do appreciate the work in TiC80 and look forward to future updates but I strongly believe that throwing hardware at slow programs doesn't fix the problem, it just sells new computers.

[mscottnelson]

Also want to chime in, having trouble getting this to build on my Raspberry Pi. I have the same educational motivations. I want my pi to boot directly into TIC-80 and be a great little device for a novice to hack on. Sidenote: there are two sets of build directions in this repo, one of which I believe is outdated (?) which I got to via the website.

[msx80]

hi guys, i have some update on #618 , there's a testable preview available if anyone is interested :)

[RobLoach]

In other news, there's also the TIC-80 libretro core PR. With any luck, once the core is compiled for Raspberry Pi, you'll be able to run TIC-80 through Lakka or RetroArch on RPi.

I have yet to test across all other platforms, so I'd love some help in that arena.

[nesbox]

we distribute TIC as .deb package for Raspbian