search

isotherm / betawise

Tools to create applets for the AlphaSmart NEO / NEO2.
MIT License
39 stars 4 forks source link

Porting modern scripting language to Neo #3

Open lykahb opened 3 years ago

lykahb commented 3 years ago

It would be great to run a modern language on Neo. Compiled Micropython takes about 50-60kb so it should fit. Alas, the project does not officially support m68k but there is an experimental branch with it https://github.com/mmicko/micropython/tree/mc68000/ports/rosco-m68k. It has some parts irrelevant to Neo like UART and I doubt that printing strings works the same way on Rosco and Neo.

Depends on #4 (custom toolchain) May depend on #5 (file management functions)

isotherm commented 3 years ago

Thanks for your interest!

One of the general obstacles right now to porting code is that the Neo has a special global data pointer (similar to but not the same as PalmOS had), and right now I have a hack in place that requires declaring all of the global data in a struct. This works ok for simple apps or those ported from assembler, but it can become quite a headache for porting C. The first task for porting any modern language will be a custom gcc build for the Alphasmarts, or otherwise some smart trick to make the compiler do what we need to do.

Looking specifically at MicroPython, its Kickstarter page indicates rough requirements to be 64kB+ RAM, 256kB ROM, and 70MHz CPU. We can have a 256kB smart applet, though it would be quite large. Consuming 64kB RAM is what EhBASIC does right now, though I hope to change that once I can figure out the structure of the Neo's file table and creating/loading/saving files. The CPU also seems it could be quite slow. There was a port of Python 1.5 to PalmOS that would be closer in terms of hardware, but it is nearly 20 years old.

I won't categorically exclude MicroPython at this juncture, but I think we could consider the following as potential languages that could be suitable for on-device compilation or interpretation:

lykahb commented 3 years ago

Thanks for explaining the scope. Making a custom GCC looks like a large challenge. Nearly everything that seems to be interesting to port is written in C.

Micropython has many build flags, I cannot find where I saw 50kb anymore. There is a discussion about small boards here. They got it down to 150kb.

I am not too attached to Python. But I think that a language with REPL would be the best fit for Neo. Without a fast feedback loop Free Pascal or C would be more painful to use. eLua looks nice.

There are also two JS engines: JerryScript and Espruino. They need even less ROM than Python.

isotherm commented 3 years ago

The lack of toolchain was a primary reason for starting with EhBASIC, since it is assembler and doesn't assume anything about the system it's running on.

I created issue #4 to track a custom toolchain, which this task will depend on.

isotherm commented 3 years ago

I did update EhBASIC in the recent 0.2 release. It only requires 4kB of RAM now, and doesn't stop scrolling after 16 lines. I know it's not great, but it does have floating point and isn't too bad if you enable Caps Lock. :smile:

A very early attempt to compile MicroPython resulted in about a 200kB applet, which isn't too bad. However, there is a long way to go to get to a point where we can build an applet that can actually run - still depending on #4.

isotherm commented 1 year ago

Per the changes referenced in #4, I now got a MicroPython applet compiled and even running (gives Python prompt and takes input), but it then crashes because the structures aren't initialized up properly.

TheTechRobo commented 1 year ago

A very early attempt to compile MicroPython resulted in about a 200kB applet, which isn't too bad.

Would gzip'ing the applet (or similar) (and adding gzip to the applet to decompress it, of course) shrink the size down or is the NEO not powerful enough/would bundling gzip negate the size difference?

isotherm commented 1 year ago

Would gzip'ing the applet (or similar) (and adding gzip to the applet to decompress it, of course) shrink the size down or is the NEO not powerful enough/would bundling gzip negate the size difference?

Neo could handle gzip, however, it has plenty of ROM and not much RAM. Compressed code in ROM would have to be decompressed to RAM in order to run, so this wouldn't help much.

The general problem with 200kB is that the M68000 processor in the Neo can only reference +/- 32K compared to a pointer. I did work around that, though, in one of the recent commits. But I'm still a ways off because of the need to initialize pointers to relocatable data and code.