Compiling stuff for Prizm

[JonimusPrime]

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.

[z80man]

That would really be great if we could get the wiki updated. I believe Jos Juice currently is the wiki admin and controls all of the major changes. In fact what I had in mind for the syscalls page was an organization system similar to wikiti.brandonw.net so that full documentation could be provided for each call. Right now the only syscall documentation is just copied from the .chm and is geared more towards asm coders and provides little insight to those who code in C. What we'll need in the discussion is an explanation of what each call does exactly, what all the args do, the use of the return value, ram locations destroyed, and how to effectively use it in a program.

But then again we aren't as reliant on syscalls for the Prizm as we were on the 83+. So far the only reason why I use a syscall is to draw the screen or depending on the program draw text. But they will become more important in the future as we start experimenting with some of the hardware such as the usb.

[JosJuice]

Making separate wiki articles for the syscalls will make it much easier to find information. I'll create the category, links to it and such right now, but I'll need some help with adding information about the syscalls since there are so many of them.

EDIT: I've added a few syscalls, and they can be accessed by hexadecimal number from Category:Prizm syscalls. Maybe there should also be categories that are based on what syscalls are used for (displaying things, file management, etc.) or lists with names of syscalls?

[z80man]

I don't think the syscalls should be organized by number as it has little relevance to its actual use. A good way to have them organized could be by the library file each is stored in such as "display.h". But for the time being I'll see how well I can get the current list filled with important information.

[JosJuice]

I was planning to do it like on WikiTI, in which the article names use numbers and the lists use names. I haven't figured out how to use names within the automatically generated lists, though.

[JonimusPrime]

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.

[z80man]

We also need to modify the header files from both SDK's to have proper #ifndef blah_h, #define blah_h, #endif statements so that other libraries don't end up being accidently included twice once more third party libraries become available. 

[Lionel Debroux]

The stdlib related headers could be organized as such but even there simon didn't follow the C standard and I really think that should be fixed.

Agreed. If there are C99/C1x functions in the OS, but these functions are not defined in the appropriate headers, it makes it harder to port programs to the new platform

In GCC4TI, I had to improve several things in the library and in the toolchain for the quite portable p14p and Lua code bases to be easier to compile. No official (I have posted the patches) release of p14p for TI-68k and the modified Lua89 can occur until the next official release of GCC4TI, otherwise Windows users wouldn't be able to compile them. *nix users can build from GCC4TI Git.

[JonimusPrime]

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.

[Eiyeron]

Hello!
I want to begin coding for Prizm, but i don't understand any micro/mini/nano/shufle sdk...
COud you help me, please?

[bynary_man]

I have the same problem... I don't know how can I build some g3a.

[z80man]

Hello!
I want to begin coding for Prizm, but i don't understand any micro/mini/nano/shufle sdk...
COud you help me, please?

I have the same problem... I don't know how can I build some g3a.

I find that the easiest way to get started is to the gcc SDK hosted on cemetech at http://cemetech.net/forum/viewtopic.php?t=6613&start=0
start with the default project and compile it by running make.bat
To start your own project use the included makefile as a template and modify the sections that read default to that of your own project. Or for the time being while you learn, just modify the code of default and see what you can do. If you have any questions I recommend that you start a help topic here for your projects.

[Eiyeron]

I made a french tutorial to use mini-SDK, inspired by the Cemetech's...

[DJ Omnimaga]

Nice. Is it available for download somewhere?

[Eiyeron]

http://www.planet-casio.com/Fr/forums/topic10062-1-[C]-Du-C-sur-la-Prizm-Du-monochrome-a-la-couleur.html
Enjoy!