Lua on Pokitto

I have found a nice repo with tiny libraries and it has a few small scripting languages, for example a Tcl interpreter in 500 LoC.

1 Like

I don’t like JavaScript or Scheme, and LIL claims “everything’s a string” which doesn’t sound fun to work with.
Picol and ‘My Basic’ might be alright I guess.

Lualite is actually just a C++ wrapper around the official Lua library.
(And it’s full of templates and standard library datastructures.)

TIC80 is opens source MIT license. Use standard Lua 5.3.1 as main language.
It use 80K Ram as doc on the Wiki but that count also the screen buffer and sound table.
Maybe just a subset of the API ?

I’ll have to look closer at LIL and Picol… I’d like to create a simple REPL toy with a small bitmap canvas to paint on (which could be saved to SD card as an image, in the linked repo there is also a number of tiny libs for various image formats). The challenge would be the onscreen keyboard and making it close to comfortable to type (command history, completion?, … etc.). I’d probably separate the keyboard into a reusable module.

1 Like

It says that 5 different languages are available, so it’s possible that it’s not using Lua’s environment and it’s compiling all the languages to some other format.

Although the ‘cartridge metadata’ implies that they might be compiling the other 4 to Lua bytecode.

I never pay attention to claims of specific amounts of RAM usage because RAM usage varies.

The memcpy, memset, peek and poke functions cause me concern.
It makes it seem like they dont know whether they want to be high level or low level.


The biggest problem is that the screen is supposed to be 240x136.
The Pokitto’s screen is 220x176, so that’s 20 pixels that are going to be ‘sliced off’.

Everything else seems doable.

You could just use serial (i.e. UART/USART) over USB to send the Pokitto keystrokes from a computer keyboard for now.

Or if you’re feeling more inventive, go out and buy a bluetooth capable microcontroller, connect it to the PEX and use a bluetooth keyboard.

Either way, Lua would be perfectly capable of filling that role.
lua.c compiles to a REPL program:

LuaREPL

(I’m not sure if the 2015 date on the copyright is a mistake or not.)

The easy part is registering your extra drawing functions.
There’s a nice tutorial for that here (it’s aimed at Lua 5.0 so some of the functions are a bit out of date, but it’s mostly the same), and a relevant section of the 5.3 manual here.

The difficult part is that you’d have to edit Lua’s source so all its stream operations work on Pokitto (i.e. stdin, stdout and file operations).


Also, here’s an online thingy that can run lua if you want to see some code examples or give it a try without having to compile it (although I feel the need to point out that for me it compiled completely out of the box).
https://www.lua.org/cgi-bin/demo

1 Like

Sorry I’m late to the party, but you ended up using full Lua (Wich is cool) but that means everything is 32bits in ram. ( elua is a more complicated port but I think it might have better performance)

If I recall pico8 isn’t of the shelf Lua but a custom implementation with some odd qwerks. It’s also wierd how it pacs the Lua and assats in a png

Unsure if files would work so things like Require might need to be stripped out (I forget if that’s part of Lua or the base library)

I’m not going to worry about that until I’ve tested some actual programs.

It’s a lot more complicated than just ‘everything is 32 bits’ - Lua maintains its own stack, and various objects are allocated dynamically, but there’s also a garbage collector involved, so ultimately there’s no way of knowing whether it’s going to use too much memory until it’s been tested.

The point of using Lua probably wouldn’t be to try to make large games in Lua, but to use Lua for adding extensions and scripting events.

No matter what you do, pure C++ will always do better at reducing memory usage and increasing performance compared to any dynamic language.

But the key advantage Lua has is that you can load and unload bytecode, effectively allowing you to store functional code on the SD card, and store higher quantities of it than you could on the Pokitto’s program memory.

I’ve had a look, but there’s no indication of how easy it is to get it running.
(Lua is by far one of the easiest things I’ve ever compiled.)

Part of what puts me off about eLua is the complex licensing there are lots of different parts to it that are under difference licences.

We’ve established that it doesn’t use floating points, but I have no idea what else it does or doesn’t do.

Usually anything that does that is actually just a renamed .zip file, like .doc/.docx files from MS Word.

There’s no reason that they shouldn’t be able to work after a bit of tweaking to make Lua use a different filesystem API (to read off the SD card).
I doubt they’d work ‘out of the box’ though.

The way pico8 program works it’s all in one plaintext file (Lua, tiles, map, souns tracker) and then put in the png header (or similar) that they call carts

Ok so for loading detectly of sd, what is it expecting?
A char string of the hole file? Or do feed it a line at a time and then do a protected call on the program?

Plaintext is an odd choice, but otherwise that doesn’t seem too bad.

I haven’t checked, but I assume it’s using the C FILE API from stdio.h, so it could be doing line by line or loading the whole file at once.

I’d assume it’s probably trying to load the whole file at once and then passing that to its ‘load lua source from string’ function, but hopefully it’s trying to read one line at a time.

I think it must work else the repl wouldn’t work.

I’ll probably look into it this week, a small engine perhaps

1 Like

I got LIL to work

image

Very simple to make it run:

Summary
#include "Pokitto.h"

extern "C"
{
  #include "lil.h"
}

Pokitto::Core pokitto;

static LILCALLBACK lil_value_t fnc_writechar(lil_t lil, size_t argc, lil_value_t* argv)
{
  if (!argc) return NULL;

  pokitto.display.setCursor(1,1);
  pokitto.display.print((char *) lil_to_string(argv[0]));

  return NULL;
}

int main()
{
  pokitto.begin();
  lil_t lil = lil_new();

  lil_register(lil, "writechar", fnc_writechar);

  while (pokitto.isRunning())
  {
    if (pokitto.update())
    {
      lil_value_t result;
      result = lil_parse(lil,"writechar Heey",0,0);
    }
  }

  lil_free(lil);
  return 0;
}

EDIT:

Also we need a plaintext editor for Pokitto so that we can write longer programs and save them to SD card.

3 Likes

You want a text editor on the pokitto?

2 Likes

I would love that.

1 Like

Yep, I’m thinking about it right now, just a plain notepad kind of thing, but extensible and embeddable (you could e.g. use it in the REPL as a script editor), at least at the source code level. Screen mode 1 because we need a big resolution and not many colors. Palette swapping would give you different themes. Would have a built-in onscreen keyboard but later also support for external keyboard. You could use it for all kinds of things from programming to note taking to reading short texts on Pokitto.

EDIT:

But I bet I’ll get stuck at the keyboard layout, I’ve already spent too much time sketching and thinking about it.

No worries I’ll help you out here.
This seems like a Project I can accomplish

I’d probably just go with the cursor select (hunt and peg) keyboard ( there’s actually one in the pokitto lib from legacy gamebuino)

But maybe a multy press design might be faster to type on

1 Like

Thank you, maybe we should make a specific topic to share our ideas and designs of the keyboard? I don’t think the Gamebuino one will do, it’s mean to type simple answers in games… I need a keyboard that offers all printable ASCII chars plus special keys for common text operations, and is as comfy as can be. It should probably remember and offer the most commonly typed characters and so on.

Since this thread is supposed to be about Lua, here’s the Lua equivalent:

#include <Pokitto.h>

#define LUA_32BITS
#include <lua.hpp>

void writeChar(lua_State * state)
{
	using Pokitto::Display;
	auto string = luaL_checkstring(state, 1);
	Display::setCursor(1, 1);
	Display::print(string);
}

int main ()
{
	using Pokitto::Core;
	using Pokitto::Display;

	Core::begin();

	lua_State * state = luaL_newstate();
	lua_pushcfunction(state, writeChar);
	lua_setglobal(state, "writeChar");

	while (Core::isRunning())
	{
		if (Core::update())
		{
			auto status = luaL_loadstring(state, "writeChar('Hey');");
			if (status != 0)
			{
				Display::println("Error loading!");
				Display::println(lua_tostring(state, -1));
				continue;
			}
			
			auto result = lua_pcall(state, 0, 0, 0);
			if (result != 0)
			{
				Display::println("Error running!");
				Display::println(lua_tostring(state, -1));
				continue;
			}
		}
	}

	lua_close(state);
	return 0;
}

You could omit the error handling of course, but I’d rather leave it in.

(I think auto status = luaL_loadstring(state, "writeChar 'Hey'"); would work as well.)

Weren’t you supposed to be making a raycaster-based game a few weeks back? :P

Probably for the best.
Same with LIL, that should be in a separate topic as well, otherwise it’s going to get buried and nobody will see it.

2 Likes

I’m getting ready for that, don’t worry. I also have to wait for something I can’t be specific about, but trust me it’s on my mind!


I’ll make a new topic if I have more to say about LIL and related stuff.

Let’s get back to LUA here.

For text editor discuss here:

3 Likes