I've been working on a new driverless serial backend for libticables on windows please see this topic for details on testing. I'm posting here so that hopefully more people will see it and test as the number of people who have all the required prerequisites is fairly low and I would like as many testers as possible.

Though it makes some sense when it comes to development speed and ease of testing. When the hardware and software were simpler there was less to debug and fewer things to go wrong, here with much more complex display hardware and wanting to support more complex configurations using tested hardware that already has all the requirements for their needs most likely saved development costs and time. They already had hardware that worked and could power that display and by using simpler links they don't need the hackish things they did so that you could connect any NSpire up to the display where with previous calcs you had to connect the teacher viewscreen models up or use the crazy hack of a device that was the USB Viewscreen adapter.

ephan, if you want to get my tools going under Linux just message me on IRC and I will get you started. I should really just make an automated script for it but its not to hard to do yourself.

Juju, for this to work with USB one would have to emulate an well supported USB TTL chip, I know there was some talk on doing this on the TI-89T a while back but I doubt we know enough Prizm's USB controller to do this, but I'd love to be proven wrong.

What I think would be really cool is if we could somehow make it so the syscall and general routine library could be portable between the compilers. For syscalls the asm.h header just needs to use the proper macro for the platform, along with the asm source files but the C sources should easily be portable between them with a little clean up.

I already have libfxcg hosted on github so that is a start but many of simon's helper routines don't even compile with gcc due to header file case errors, syntax differences and a few other issues.

I agree that the numbers are generally useless, but I disagree with using the header file name as the organizational method, a simple category based method would be just fine. The issue with going by the header file name is that is one of the issues I have with simonlothar's SDK is the naming and setup of the headers. The stdlib related headers could be organizer as such but even there simon didn't follow the C standard and I really think that should be fixed.

Since we don't have official naming conventions from Casio I would see if we can standardize them, unless the naming we have been using is based off of the older Casio calcs. If that is the case then fine but it still irks me.

I know this is a bit of a necro bump but I did release the "cemetech"(as Kerm so happily dubbed it) GCC PrizmSDK-0.2 a while back and would love to help anyone get it setup if needed.
 
As for using it on Mac OS X you would need to install xcode and then compile and install a gcc targetting the superh series processors. If you want I can help walk you through the process any time, just hop on irc, or use the chat box, and highlight me. You would just need some parts of my sdk and I have all those individual files available for download.
 
As to keeping this on par with Simons work I would really love to work with him on standardizing things a bit. I'm fine with the automated syscall generating and have written a script to duplicate its work for use with my SDK but the biggest issues I have are with the header and helper functions organization. As it stands right now you can't easily use the headers from one SDK with another or even reliably compile code written with one on another.
 
I'd like to fix that so that it is easier for the end users of either SDK to adapt them to their needs.
 
My first issue is the lack of clarity on whether or not C++ is really supported and why some headers and source files use hpp/cpp instead of h/c. IMO we should keep the SDK's and their API's pure C and leave it up to the users as to whether they want to use C or C++. Many of your headers are already encased in Extern "C" {} so why even bother having them use the .hpp extension?
 
My second issue also relates to the headers and it is the fact that you mix equates and structs used by syscalls with custom functions you have added. This increase the amount of work for me greatly and adds to user confusion because they can't tell what is a syscall and what is something you added to the SDK yourself.
 
My last issue is that darn chm file. Yes its nice that there is some documentation but damn is it a pain in the arse to find any of it in there. Omnimaga was kind enough to host the prizmwiki at http://prizmwiki.omnimaga.org we should use it. I have been trying to update it with some of the things I have found but its just not all that useful as it currently stands. I think the first step would be to start getting the syscalls on there. The documentation for them is scattered about this forum, your .chm file and our heads. Getting on in a centralized location would help everyone move forward and allow one to much easier find the information they need.