Various coders at Cemetech have been hard at work building applications, programs, games, and tools for the Casio Prizm color graphing calculator, which we here at Cemetech feel represents the TI coding community's best option over the crippled TI Nspire CX. Unfortunately, the end of the Spring semester is looming for our college and graduate school students, and the busyness of everyday life continues for our other members, so project progress has been slow, particularly with regards to Direct USB globalCALCnet. Luckily, I'm happy to present two completed Prizm games, two Prizm games in progress, and a wonderful toolkit for writing Prizm programs that will make life even easier for coders.

The previous SDK for developing Prizm C programs is functional, but complex to set up, and several users have encountered confusion and difficulty. Cemetech administrator Jon "TheStorm" "Jonimus" Sturm and long-time user Peter "Tari" Marheine have teamed up to write a full GCC-based toolchain for the Prizm, turning C (and potentially other languages) into .g3a Add-Ins for the calculator. Like GCC itself, it is cross-platform, allowing Windows, Linux, and Mac OS X developers to all write Prizm programs. They have worked very hard on this, including attacking a stubborn bug preventing interrupts from being properly set up, even though neither yet has their own Prizm calculator. We are proud to offer the very first version of the SDK at the link at the end of this article.

Secondly, several Prizm games are complete or in progress. Our extraordinarily productive (newly-minted) administrator Shaun "Merthsoft" McFall has released polished versions of his Minesweeper game and of the classic Conway's Game of Life for the Prizm, both of which are available below from the Cemetech Archives. Global moderator Tanner "_player1537" Hobson has been developing a game of Checkers for the Prizm; the screenshot below is a poor representation of the excellent progress he has made. Finally, Christopher "Kerm Martian" Mitchell, yours truly, has been porting my popular Obliterate game from the TI-83+/84+ series of calculators to the Prizm; you can see screenshots of its full-color splashscreen, menus, and rudimentary gameplay in the [Prizm] Obliterate topic.

I hope that you all with embrace the Prizm, show TI what we can do with an open platform, enjoy programming on a full-color graphing calculator, and show off your C coding skills!

Download
Prizm GCC-Based SDK by TheStorm and Tari
Prizm Minesweeper by Merthsoft
PrizmLife (Conway's Game of Life) by Merthsoft


Prizm games under development. Left: Checkers by _player1537; Right: Obliterate by KermMartian

Thanks Kerm, as I get things cleaned up I will release updates. Maybe Merth or someone could whip up some project scripts to assit programmers and make up batch files.

The included Makefile example should be enough to get going but if someone has some suggestions I can surely help with questions.

I have uploaded the source to libfxcg at https://github.com/Jonimoose/libfxcg as more syscalls are found we can add them and also look into maybe including graphics and utility libraries as well.

I was able to figure out the makefile, and can I correctly assume that if I add the /bin/ directory of the PrizmSDK to my path, I will be able to "make"?

Yup that is a correct assumption, though you may need to edit the paths in the Makefile as it currently assumes it is running from that folder with nothing your path. It should just be a matter of removing the ./ and ../ from it.

Can we get some Lifey screenshots?

I'm sure Merth has it in his thread but here ya go.

I'm not sure if this is the latest one though.

From PrizmLife in the Cemetech archives:



Jonimus: I'm still stumbling around trying to figure out how to use the PrizmSDK; I'd be happy to help with a Readme once I figure it out.

@Kerm:

Hmm. I don't see that

J/k, fixed it to "classic"

The GCC toolchain is working? Viva la GCC! Now I can use my old Dev-C++ standby (yes, I still use it, leave it alone) to make g3a add-ins! Thanks for all of your efforts!

All of these games looks great, too! I'll be sure to put them on my calc today to play during math class <.< >.< >.>

How do you use GCC? Or what is needed to run this SDK?

You should ask that in the appropriate thread.

Nice catch Raylin, thanks for the fix, ComicIDIOT. No one noticed my BBCode flub on the front page, though. Raylin, you need a working "make" plus this tool from Jonimus, or you could just use a batch file.

So, I get the feeling that Jonimus never tested the thing before uploading, so I fixed things up some and included a make binary in a package. C compilation isn't working because gcc complains about a missing libgmp dll, though.
Specifically, I fixed the makefile to refer to .c files rather than default.cpp, and cleaned up the mkg3a invocation to just what's needed.

http://media.taricorp.net/PrizmSDK-patch1.7z
Just merge the contents of that archive with your current PrizmSDK directory.

I tested it but I was way to tired to antiquity test it, thanks for the fix. I'm not sure how gcc could be missing libgmp.dll, I told the build to be entirely static. As to the Makefile fixes thanks for that. Maybe we should get a repo up for everything other than the GCC binaries and such so that someone other than me is in charge of not making stupid mistakes while tired.

I think a repository would be a nice idea. I got the same libgmp-xx.dll error when I tried to run make, hence why I was thinking I would need to make a batch file for this. I think I should still make the batch template, though.

*bump*


Code:
Any ideas?

I pointed out in IRC earlier that this is thrown by the linker because the data section is larger than the 64k region defined as available RAM which it needs to fit into. Did you manage to find a fix with the discussions earlier, or is GCC still being dumb about section locations?

I did not manage to find a fix. We have discovered that when I have a const char variable wrapped inside a .rodata section label, the size of the .data section grows to a ridiculous magnitude; you mentioned:

To keep this discussion logical for those only following on the forum:

Background: the Prizm loads add-in code at 0x00300000 when running it, and we have 64k of scratch RAM at 0x08100004. The earlier problem was due to defining the stupidly large title screen image (~160k IIRC) as non-const, which put it in the .data section, where it overflowed the 64k of RAM available to the linker and caused that error. Adding a const qualifier to the static image data makes the compiler put it in .rodata, which we link into the program image and don't put in RAM at all.

The new problem:
Kerm discovered a case in which the linker was giving back ~129MB binaries. We've traced it to the existence of a .data section in the compiled program which makes it become huge. .data is pre-initialized writable data, which the initialization code in crt0 copies into RAM at the VMA of .data, reading from the LMA, before handing control off to the program proper.

My working theory right now is that I screwed up (duh), in that ld writes code to the corresponding VMA when writing in binary mode, rather than the LMA I want, such that the data section gets written to where the linker thinks RAM is, which is around file offset 0x7E00000 (0x810004-0x300000, precisely). The fix I'm considering is to not have the linker generate straight binaries as we have (since it seems to by design write to VMA only), but instead use objcopy to do basically the same thing. Nothing in the docs say so explicitly, but I suspect ld writes binaries to the VMA while objcopy will write to the desired LMA of the segment, as we want. If that were not the case, I fail to see why there would be the two tools duplicating so much functionality.