Lua for TI99

[+MarkB]

Hi folks,

I mentioned on the zoom call last night that a Lua port to the '99 might be an interesting project to look into.  The Lua core is pretty small (about 30KLOC of C), is quite embeddable and it's easy to add C (or inline ASM) methods for speed critical stuff.  It would need quite a bit of plumbing for heap, io, and so on, and would need SAMS.

Would any game devs have any interest in using Lua?

Mark

 

[+TheBF]

That would be a amazing upgrade to TI-99.  

 

I am seeing that the LUA executable is about 42K and the libraries about another 22K.

I can't find out if that is on a 32 bit machine or not. 

If it is 32bit then should we could expect it to be smaller on 9900?

 

I did find a guy who compiled LUA for 16 bit MSDOS so we know it's possible. 

 

I wonder about the real world speed on a 9900 with the overheads that modern languages incorporate. ??

 

[Asmusr]

Don't you think it would be difficult to make the Lua interpreter run from paged memory?

[+MarkB]

31 minutes ago, Asmusr said:

Don't you think it would be difficult to make the Lua interpreter run from paged memory?

yes 🙂

I'm thinking none of the lua C modules themselves should exceed 24KB so we could put trampolines between modules in the interpreter.
And then maybe come up with a scheme where each file is in it's own 8k bank or something like that.  I can look into it.

[+MarkB]

53 minutes ago, TheBF said:

That would be a amazing upgrade to TI-99.  

 

I am seeing that the LUA executable is about 42K and the libraries about another 22K.

I can't find out if that is on a 32 bit machine or not. 

If it is 32bit then should we could expect it to be smaller on 9900?

 

I did find a guy who compiled LUA for 16 bit MSDOS so we know it's possible. 

 

I wonder about the real world speed on a 9900 with the overheads that modern languages incorporate. ??

 

Yeah I saw that one.  He did have the advantage of x86 segments but still it has been built for 16-bit so that is positive.

Size may actually get bigger if we have to do 32-bit operations for everything.  I was thinking if we could limit lua_number to be a 16-bit int and then handle floats completely separately then it might be doable.

Speed could be a concern too.  But that's the where being easy to switch between Lua and C could come in handy.

[+FarmerPotato]

This idea of a Lua port is intriguing.   I've worked on a product with Lua embedded in it (64-bit!).  

 

The garbage-collection part would deter me, but go for it!  

 

Some approaches that can increase the usefulness of 16-bit pointers:

Align objects on 16-byte boundaries, so that total reach is 2^20, two megabytes. 

Instead of pointers, use 16-bits index to table of page number and offset. 

 

 

 

[Tursi]

I have doubts that 32,000 lines of code counts as small on the TI99 scale. One quick test is to just get the code to build and see how big the resulting ELF is without any paging or anything coded in. That might give a quick idea of feasibility. I've done that with other things before.

 

 

[+MarkB]

7 hours ago, Tursi said:

I have doubts that 32,000 lines of code counts as small on the TI99 scale. One quick test is to just get the code to build and see how big the resulting ELF is without any paging or anything coded in. That might give a quick idea of feasibility. I've done that with other things before.

 

 

Yeah small is relative 🙂 I was thinking relative to python or javascript !

 

It does build, with a lot of stubbing.  An objdump of the resulting binary shows addresses from >A074 to >4A97E so that's 264K !

 

(EDIT: that was the interpreter unoptimised.  With -O2 the interpreter is 214K and the compiler is 181K.  I've ommitted mathlib, oslib, and loadlib)

[Tursi]

yeeeeah, that's looking a bit large. Feasible, 512k carts are not hard to build, but I'd really want a good reason myself.

 

Still, sometimes the journey is all the reason you need!

 

[jrhodes]

20 minutes ago, Tursi said:

Still, sometimes the journey is all the reason you need!

 

Thats the kind of advise that can get you featured in a Fluffee Talks video.

[lucien2]

What about TinyScheme? https://tinyscheme.sourceforge.net/home.html

I compiled it with VS5 on XP 32 bits, the executable is 128k. It's only 5000 lines of code.

I don't know the performance or RAM usage, compared to Lua.

[+Ksarul]

3 hours ago, Tursi said:

yeeeeah, that's looking a bit large. Feasible, 512k carts are not hard to build, but I'd really want a good reason myself.

 

Still, sometimes the journey is all the reason you need!

 

For that matter, even the 2M cartridge is pretty easy to build if you ended up needing an even larger total space than a 512K cartridge would give you. Of course, I just build stuff--you guys are the geniuses that write the wonderful code we use.

[Asmusr]

This project sounds fascinating because my kids use Lua to write mods/plugins for games, but to be honest, a cross compiled language with native SAMS support (something like C++) would be far more useful to me for writing games. It would be much faster, and would only need a small runtime for the memory manager. I believe page swapping, garbage collection, and code to emulate a 32-bit architecture could make Lua even slower than TI BASIC.

[retrodroid]

5 minutes ago, Asmusr said:

I believe page swapping, garbage collection, and code to emulate a 32-bit architecture could make Lua even slower than TI BASIC.

Now that would be an accomplishment!  😉

[Tursi]

2 hours ago, Asmusr said:

This project sounds fascinating because my kids use Lua to write mods/plugins for games, but to be honest, a cross compiled language with native SAMS support (something like C++) would be far more useful to me for writing games. It would be much faster, and would only need a small runtime for the memory manager. I believe page swapping, garbage collection, and code to emulate a 32-bit architecture could make Lua even slower than TI BASIC.

Nanochess just open-sourced a BASIC compiler he released for the ColecoVision. It seems to be getting good responses... maybe that's a starting point. It doesn't have a TI target yet

 

[+TheBF]

1 hour ago, Tursi said:

Nanochess just open-sourced a BASIC compiler he released for the ColecoVision. It seems to be getting good responses... maybe that's a starting point. It doesn't have a TI target yet

 

Is it a line number BASIC or a more modern form?

[Tursi]

2 hours ago, TheBF said:

Is it a line number BASIC or a more modern form?

I don't actually know

 

But looks like no line numbers in the screenshot! 

 

 

 

[+MarkB]

16 hours ago, Asmusr said:

This project sounds fascinating because my kids use Lua to write mods/plugins for games, but to be honest, a cross compiled language with native SAMS support (something like C++) would be far more useful to me for writing games. It would be much faster, and would only need a small runtime for the memory manager. I believe page swapping, garbage collection, and code to emulate a 32-bit architecture could make Lua even slower than TI BASIC.

It's possible.  Though it would be disappointing if it was even slower than the ROM+GPL of TI basic.  I might try and knock together a 32-bit variant of my emulator to try it out as a performance feasibility study.

Bear in mind that tms9900-gcc is a backend only so it does allow you to write in any language for which gcc already has a front-end.  "GCC can compile programs written in C, C++, Objective C, Ada 95, Fortran 77, and Pascal ".

 

native SAMS is tricky.  I was thinking once we could do something along the lines of segmented x86 with near and far pointers to use CS, DS and SS regs for far pointers but how to implement that needs a bit of thought, and possibly hardware support.

[+MarkB]

19 hours ago, lucien2 said:

What about TinyScheme? https://tinyscheme.sourceforge.net/home.html

I compiled it with VS5 on XP 32 bits, the executable is 128k. It's only 5000 lines of code.

I don't know the performance or RAM usage, compared to Lua.

Thanks - I'll check that out too.  But even at 128K it still poses the same challenges with managing banks.

[JasonACT]

34 minutes ago, khanivore said:

I was thinking once we could do something along the lines of segmented x86 with near and far pointers to use CS, DS and SS regs for far pointers but how to implement that needs a bit of thought, and possibly hardware support.

You and me both...

 

I've got the hardware (my Pico PEB - with 16MB available) and I was thinking for each word of generated assembler (be it reg-reg, reg-word, word-reg, word-word) I could have a PSRAM reserve (coded as an 'extra' word in the code) that told the device what was meant to be referenced via a segment reg (you forgot to mention ES).  You would have to set up memory (with my device) so it was interleaved, because there's no way timing would allow anything other than sequential byte access, given the long address setup time for the chips.  So, instruction word (that the CPU reads) and following segment data (following means less timing issues, as it gets read while the '9900 catches the required data).  Even then it's very iffy and probably wouldn't work without some overclocking - which I know is dodgy already on these PSRAM chips.  But instructions would have the word coded for the desired segment, data would have it set as zero, so there's no need for IAQ, the one data line I don't have access to.  Wastes half your memory, but no one would really care...

 

Fairly esoteric though, so I try not to think about it so much now.

[SteveB]

While academically interesting, I don't see the advantage of adapting another language, when the main issue remains a high-performance system-specific library. How to do sprites, how to define a character, how to make a sound ... ?

 

I liked the concept of Action! on the Atari 8bit. It focused on the hardware features of the platform and made them available in an optimized way in a higher language.

 

For the TI, I would suggest a language that focuses on speed by accepting some restrictions, doing things static and limited instead of dynamically, i.e. Strings to be declared with (max) length and always allocate this amount of memory. Declare procedures/functions as "overlay" like in Turbo Pascal to be put in a SAMS page, etc. 

 

Sadly, designing a compiler like this exceeds my programming capabilities by far. 

 

[+MarkB]

1 hour ago, SteveB said:

While academically interesting, I don't see the advantage of adapting another language, when the main issue remains a high-performance system-specific library. How to do sprites, how to define a character, how to make a sound ... ?

Well libti99 has some of that.  It does have functions for vchar, char, sprite, etc.  Maybe some other libraries have higher level functionality.  Creating functions to do these shouldn't be too much of a challenge and they can be in assembler if more performance is needed.

 

1 hour ago, SteveB said:

I liked the concept of Action! on the Atari 8bit. It focused on the hardware features of the platform and made them available in an optimized way in a higher language.

Hmmm.  Nice idea.  It could be a new front-end for GCC.  Or just a new compiler.  I have a recursive descent parser and stack machine lying around somewhere....

 

1 hour ago, SteveB said:

For the TI, I would suggest a language that focuses on speed by accepting some restrictions, doing things static and limited instead of dynamically, i.e. Strings to be declared with (max) length and always allocate this amount of memory.

Isn't that C ? 🙂
 

 

1 hour ago, SteveB said:

Declare procedures/functions as "overlay" like in Turbo Pascal to be put in a SAMS page, etc. 

That can actually be done fairly easily in a number of ways.  One way is to just call a functions via a trampoline.  Another is to have the compiler automatically emit a call to a trampoline for external functions.

I've some other ideas there so I'll start a new thread I think.
 

[+MarkB]

2 hours ago, JasonACT said:

I've got the hardware (my Pico PEB - with 16MB available) and I was thinking for each word of generated assembler (be it reg-reg, reg-word, word-reg, word-word) I could have a PSRAM reserve (coded as an 'extra' word in the code) that told the device what was meant to be referenced via a segment reg (you forgot to mention ES).

Yes.  We could get gcc to emit extra code if given a switch.  I didn't forget ES - I just didn't know what we would use it for 🙂

2 hours ago, JasonACT said:

You would have to set up memory (with my device) so it was interleaved, because there's no way timing would allow anything other than sequential byte access, given the long address setup time for the chips.  So, instruction word (that the CPU reads) and following segment data (following means less timing issues, as it gets read while the '9900 catches the required data).  Even then it's very iffy and probably wouldn't work without some overclocking - which I know is dodgy already on these PSRAM chips.  But instructions would have the word coded for the desired segment, data would have it set as zero, so there's no need for IAQ, the one data line I don't have access to.  Wastes half your memory, but no one would really care...

 

I've thought about trying to do it automatically with hardware assists but it does get tricky with 16-bit ptrs if you've lost the context.  We looked at IAQ and decided it wouldn't work anyway since if a multi-word instruction requires extra fetches for the parameters these are in code but IAQ isn't set while fetching them AFAIR so.

[SteveB]

3 hours ago, khanivore said:

Isn't that C ? 🙂

It can't be C because I could never wrap my head around C in the past .. dunno why, not my cup of tea. Perhaps it's too close to Pascal and not close enough for me to work. So I would never ever suggest something like C 🤪

[+arcadeshopper]

23 hours ago, Tursi said:

Nanochess just open-sourced a BASIC compiler he released for the ColecoVision. It seems to be getting good responses... maybe that's a starting point. It doesn't have a TI target yet

 

I asked him if he was thinking of targeting the tms9900 and he said we already have compilers so no