There was discussion recently on the feasibility of porting Python to the Prizm. Merth and I have been working on implementing big chunks of the C library to support Python, then.

The fruits of those efforts have been accumulating in the pycompat branch, and at this point many of the harder functions are done (I just finished implementing the core of printf).

I have yet to really get things running on the device (mucked about with serial, but I need a scope to figure out what I need to do with that before things will really work), but most of the functions have been tested in a cross-hosted environment (that is, on a PC).

Because there's nothing terribly interesting to look at right now, here's a screenshot from testing printf:


Edit by Merth: I'm stickying this.

For serial you might want to see if the source to FXTerm is available, it should have all the code you need to implement it.

I was looking at that earlier and forgot about it by the time I got home from work.

Looks like the source for fxterm isn't available, though.

FXTerm is in-process and I will release next version with sources.
If you need just serial communication, you can use CGPlayerA, it uses syscalls to access COM. Unfortunately it was deleted from cemetech archive, so there is only download at omnimaga (see http://ourl.ca/15297 ).
But I would recommend you to read Simon's great manual (fx_calculators_SuperH_based_xxx.chm)

Indeed, I referred to the .chm documentation when documenting those on WikiPrizm and subsequently adding them to libfxcg.

As far as the docs go everything was working (nothing returned failure), I just couldn't see anything electrically, so I chalked it up to a hardware configuration issue- hence I need to poke at it with a scope.

Which Python version are you aiming to support initially? This sounds like a cool project

I've been working against the latest 3.x release (3.2.3). I even found a bug and got it fixed.

I can get good chunks of it to build at this point, but it's rather unhappy about some Unicode things, which I'll have to investigate further.

How difficult would it be to maintain a 2.7 build alongside it?

Turns out it shouldn't be too difficult to build 2.7 as well. I've hit a few more functions 2.7 depends on for compiling, but they're things that I'm sure need to be implemented at some point to get the thing to link (fseek..).

The unicode issues I was having stemmed from bad configure values, which have now been resolved.

Current stumbling block is the import machinery depending on a stat() implementation, which I'd rather not have to implement (I'm against making this thing look like a POSIX system). It feels like a regression since things indicate that defining DONT_HAVE_STAT should avoid using it, but I have yet to investigate the use of such in 3.x (I know 2.7 is using it to check if things are directories).
EDIT: after poking at it some, I think I'll have to implement stat(), but only in a very basic form.

I've updated the nightlies to track our pycompat branch rather than master, as nothing's changing on master.

Tarball: http://media.taricorp.net/libfxcg-latest.tar.bz2
Build log: http://media.taricorp.net/libfxcg-latest.log

Highlights:

• Simpler build. Compiling libfxcg itself can be done simply with `make' from the root of the source tree, and fewer linker options are required when compiling your own programs.
  
• Many standard library components: math functions, string manipulation (including printf!) and file I/O wrappers.
  
• Better header and function names.

Yes, you read that right. You can now use fopen() and friends.

Caveats: big chunks of the I/O stuff (particularly file I/O) are untested. There are probably also corner cases in other functions that need to be worked out yet. I/O to the standard streams (stdin, stdout, stderr) is directed to the serial port, which I'm not sure if it works (again, untested code).

Setting up this bleeding-edge version on your old PrizmSDK 0.3 should be fairly easy:

• Unpack the include directory to the SDK include directory. Overwrite files where prompted, but do not overwrite types.h (just skip that one).
  
• Unpack the contents of the lib directory to the SDK lib directory. Overwrite where applicable.
  
• Modify your makefiles to use libc. This should just be a matter of removing "-lfxcg" and "-nostdlib" from the CFLAGS and adding "-nostartfiles" to LDFLAGS.

Some programs will now fail to compile since we've been removing some crufty headers. In most cases you'll simply have to change inclusions- post for help in such a situation.

I strongly encourage everyone to try out these new features so I can fix the inevitable bugs and get feedback on the changes. Get to it!

libfxcg now supporting printf and fopen, etc. - sweet!

printf will save me from using dozens of concat()s and itoa()s, and file I/O will make porting existing code much easier.

Are the old file I/O functions (syscalls) still supported? This is important to allow older code to build.

Yes, they are building this as a separate set of new features rather than removing any existing features/support, as far as I can tell. I agree that it's great both that we're getting a solid stdlib and that Python support may be here soon.

I don't think Python will be much faster than Basic with the exception that IMO it's a "better" language, that can also be written on the calculator if a text editor is ever developed.

I don't think it will be hugely faster either, but it will be able to run a vast set of existing programs, plus the fact that it's a language many people already know.

OK... my failure to pass a parameter to the tar command made types.h be overwritten. Does anyone have the previous one, or from where can I get it...?

EDIT: this time my backup system worked and I have a copy of the old file...

Yes, all the raw syscalls are still available. I hope to maintain support for any old code that's out there as well, as I've outlined over on WikiPrizm.

No argument with any of that, but don't forget that Python is much better for interfacing with native code. It's very easy to write extension modules, so Python can be much more powerful than BASIC.

OK, so as said on SAX, here are a list of things that need fixing:
* disp_tools.hpp is broken
* keyboard.hpp is lacking the definition for KEY_PRGM_0 (it should be 71)
* there are conflicting types for malloc and realloc in stdlib.h

And here's my build log for CGlock, with some errors caused by the new libfxcg and others caused by my code: http://pastebin.com/dBrcTPPF

Wanna tell us what's "broken" about disp_tools.hpp? We can't fix something if we don't know the problem.

It's there in the build log.

The problem stems from the removal of headers that correspond to things which we don't have source for. My plan is to extract the relevant object files from the old libfxcg.a and throw them in git as straight-up blobs, then re-add the relevant headers with _FXCG_MINICOMPAT guards.

Haha, whoops, soory. No more posting for me until I get some sleep.