I still need to figure out that GCC issue but I may be able to solve it by building libgmp and the others from source and working from there. If I get it working I will update the archives and post with the updates.

The other thing that is needed is getting all the "tools" and misc. routines that should be in libfxcg included. If Kerm or anyone else could get a list of all of them and help to organize them as well as finalize some header organization that would be great. If I get a chance tomorrow I'll start a libfxcg thread and we can work from there.
I know that there's at least random()/srandom() and PRGM_getkey() that I had to find in Simon's SDK and explicitly put into my source after I switched to the GCC-based PrizmSDK. I'll check to see if there are any more; when you start a thread, I'll post up my findings.
Could those just go in the useful prizm routines thread?
merthsoft wrote:
Could those just go in the useful prizm routines thread?
By contrast, I think that a lot of the Useful Prizm Routines should turn into a sort of library, which I think might be something that Jonimus has in mind. I don't want to have to include a sprite-XORing routine in every program I make when I can just call it. Smile
Kerm, the issue is since we are static linking that is basically what you are doing. But yeah not having to have it in the source file every time would be nice.
TheStorm wrote:
Kerm, the issue is since we are static linking that is basically what you are doing. But yeah not having to have it in the source file every time would be nice.
Certainly there's some way to only statically link in routines that are used from certain libraries?
KermMartian wrote:
TheStorm wrote:
Kerm, the issue is since we are static linking that is basically what you are doing. But yeah not having to have it in the source file every time would be nice.
Certainly there's some way to only statically link in routines that are used from certain libraries?
Yes, that is how I have the linker setup currently. I compile the lib with -function-sections, though most of the functions are already in their own object file anyway since I do one per source file, and then on the SDK side I link -gc-sections so that any unused routines are removed.
Hi!

Now, I've successfully done a hello world program using C and the PrizmSDK 0.3
But I prefer C++. I read somewhere that it's possible to do, but I haven't found any example code. Can you post me one please? And describe the way of the compiling?
I am adding tutorials to the prizm wiki and it will cover C++. I am still working on them.
I'm trying to compile fdlibm for prizmSDK 0.3, but i need again errno.h... Does that means that any thing I will try to port a libm will finish by a crash?
Hello

I cant download Casio fx-9860 SDK. Every time I try it the message "CASIO COMPUTER CO., LTD. currently does not provide any support for the SDK." is coming.

Who can help me?
You need to have an account on Casio Éducation to download the fx-9860 sdk from their servers Wink.
You can also download it from community servers like here for example (in french, but you should be able to find out how to download it :p ) : http://www.planet-casio.com/Fr/logiciels/voir_un_logiciel_casio.php?logiciel=SDK_Graph_75_85_95_logiciel&showid=76
I don't know about a download from Cemetech or another English (Casiopeia maybe) site because that's not a SDK for the Prizm, and I'm not very aware of the English or American community for this devices.
Thanks for the information. Now I cant downlaod Casio Prizm Mini-SDK. If I click on the links, this message is coming: You are not allowed to access this section. I just registrated me, but it didnt help me.
Oh, if you want to program for the Prizm, you'd better follow instruction here : http://prizm.cemetech.net/index.php?title=PrizmSDK_Setup_Guide
The Mini-SDK is more or less outdated Smile.
I did some experimentation with Docker and revamping the recommended configuration for a toolchain last week, with the net effect that there's less magic involved in building a program against libfxcg. Previously:
Code:
sh3eb-elf-gcc -m4a-nofpu -eb -mhitachi -I/path/to/libfxcg/include -L/path/to/libfxcg/archives -nostartfiles -lgcc
Now:
Code:
prizm-gcc -mhitachi

The Dockerfile can be found on Bitbucket, or I've published builds on Docker Hub.

In short, GCC is now assumed to be prizm-gcc. If using a configuration similar to the Dockerfile, you probably don't need to do anything special. If using a differently-configured GCC, a wrapper on your PATH should do the trick:

Code:
#!/bin/sh
exec sh3eb-elf-gcc -m4a-nofpu -eb -I/path/to/libfxcg/include -L/path/to/libfxcg/archives -nostartfiles -lgcc -lfxcg $@
Libfxcg now requires prizm-gcc to build.

For users running on Windows who don't want to try to compile a new GCC, I'd like to investigate setting up a build bot to build Windows binaries. Until then, it may be feasible to combine Vagrant with my Dockerfile for fairly easy setup of the toolchain in a VM. It may require some tweaks to the Dockerfile to be usable under Vagrant, since my current configuration is tuned more for running as a Jenkins slave- ask me if you want to try this, and I'll see what I can do.
Wouldn't setting the sysroot option when compiling binutils and gcc have a similar effect? See https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
That's exactly what I do (among other things).

In other news, I added a Vagrantfile to the package. In short:
Code:
$ hg clone https://bitbucket.org/tari/docker-prizmsdk
$ cd docker-prizmsdk
$ vagrant up --provider=docker
$ vagrant ssh
$ prizm-gcc --version
Nice I'll try this later today, this will help me getting a cleaner dev-environnement, because mine is a mess actually ^^. If I understand well, following the commands you mentionned will build a new toolchain and libfxcg, isn't it ? By the way, nice work, I'm happy to see some activity on this forum section. Wink
..kind of. It'll give you access to the tools in a way that's easy to set up but not excessively convenient to use. Vagrant gives you what is effectively a virtual machine that shares the contents of the /vagrant directory with your machine, so you can share your source and use the packaged compiler within the VM.

It's ultimately easier to use if you build your own compiler, since you won't need to deal with container isolation. For users unable or unwilling to build the toolchain, Vagrant is the way to go. Otherwise, you can build and install the toolchain yourself by borrowing the build sequence from the Dockerfile, which should be pretty self-explanatory.
Oh... I understand better now, I think I'm going to follow the build sequence provided by the Dockerfile you provided, as I'm not very aware of the VM's concepts and usages.

EDIT : The build worked nice, thank's ! Cool
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 5 of 7
» 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

 

Advertisement