Jonimus' build is Windows-only. You'll have to build gcc for SH yourself on other platforms. It's somewhat easier than building cross-compilers for other platforms at any rate, since we don't build newlib.

I don't know what tools Jonimus uses to build it, though. Maybe he'll pop in and elaborate on the build procedure..
As Tari stated the build I have uploaded is Windows Only, but I do most of my libfxcg work on linux. I could throw together a script to compile gcc and binutils but following is pretty simple, just replace i586-elf with sh3eb-elf and set the prefix to where ever you want to toolchain installed.

Then just update the PREFIX line in the makefile and convert the \ to / where needed. I used \ because all the exe's work fine with both but window's del fuction uses / for options so I just used / to be consistent. That said the latest Makefile and libfxcg.a at have been updated to be a little nicer. Just drop libfxcg.a in PREFIX/lib and replace the existing makefile with the updated one and you should be set. You'll still need all the headers from the windows only release though.

When I make my next release I'll be sure to include a stripped down, only what you need version.

Oh and you'll need to build a copy of Tari's mkg3a as well, he should be able to link to the latest source for you.

EDIT: Oh contrary to what Tari said and I am working on getting newlib built for newer versions but one of the downsides of using newlib is you can't easily override libc functions with your own version without messing with the build system. I already have programs linking against it and using libc functions like snprintf but there appear to be some glitchyness, possibly encoding related, I have yet to figure out.
TheStorm wrote:
Oh and you'll need to build a copy of Tari's mkg3a as well, he should be able to link to the latest source for you.

Clone, build, and install to /usr/local/bin:

$ hg clone
$ mkdir mkg3a/build
$ cd mkg3a/build
$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local ..
$ make
# make install

/usr/local is CMake's default prefix, but I include that so it's obvious what to change if you want to change the install location. You should also be able to just run the binaries without installing, should you wish.

To install a specific tagged version (rather than the latest revision), specify a revision while pulling:

$ hg clone -r 0.1e
There's no reason not to use the latest revision right now, all that differs between tip and 0.1e is some compiler compatibility fixes and improved build tagging.
_player1537 wrote:
It works if I use Wine, I just think it's odd that there wasn't a Linux version made that works out-of-the-box with `make'. Oh well Smile
I'm almost positive that that's not the case; even the Windows version lets me use MingW's `make` binary.

Edit: Whoops, just saw Jonimus and Tari's posts on the final page of the thread. Fair enough.
Thanks Jonimus! I managed to get the compiler working, though my code itself is broken, now Razz I'll try it out on some code that I know works. Then all that's left is to get mkg3a and I'll be set Smile
I have a problem with PRGM_GetKey(), I include keyboard.hpp and keyboard_syscalls.h but the compiler throws undefined reference error for this function: (I use copy of default SDK v0.2 project and make.bat)


int GetKey_NonBlock() {
    int key;
    key = PRGM_GetKey();
    if (key == KEY_PRGM_MENU)
    return key;

What can I do? I need a nonblocking getkey for my arkanoid game Smile
PRGM_Getkey is a function Simon added to his SDK that I never included and forgot to remove from the header. But here is the code for it if you want to use it.

int PRGM_GetKey(){
unsigned char buffer[12];
   PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
thanks a lot Smile
No Problem, I think Kerm, ended up using a better non blocking routine for Oblitr8 which now that I think about it I should most likely include in future releases of the SDK.
Indeed, I think I posted it in the Useful Routines topic (edit: nope, I did not, now I did). Here it is again:

unsigned short key;
int kcol, krow;

I wanted to know what I should download to be as up-to-date on the SDK as possible. I have 0.2, but I see that prizm.ld and libm.a are newer, and libfxcg and libc and crt0, for that matter. Tari wasn't sure. Smile Cheers.
The makefile, libfxcg and libm should be useable, I am working on packaging it all up and hopefully I can actually finish that soon.

I wanted to make the Makefile more robust among other changes but it just seems like it isn't meant to be yet, for the time being I will put together a version 0.3 but time permitting I was to completely redo things to be more like the DevkitPro setups used for the Wii, DS, and PSP programmers. One of these days I'll start a thread discussing that. Razz
I look forward to that, I hope you do! Remind me, did you ever get a Prizm, or am I thinking of someone else? Anyway, I grabbed libc.a, libm.a, libfxcg.a, and merged your makefile with mine, compiled a program, and ran it on my Prizm, and everything seems to be working nicely. Thanks for your help, Jon.
Yes I do now own a Prizm, but I warn you string routines in libc seem horribly broken, and who knows what else. Libm seemed fine but it could be utterly broken as well. Razz
Register to Join the Conversation
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.

» Go to Registration page
Page 3 of 3
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum