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:

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.

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)

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.

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.

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!

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.

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

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

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.

Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.