I finally got started with developing something for the Prizm using C. (How many years late am I? 5? ) Things went reasonably well at first, but right now I have two questions. I am using Windows 7.

1. When I was going to download PrizmSDK, the wiki was rather vague about where I could find it. The PrizmSDK Setup Guide page says it's on the Prizm Programming Portal page, but the most relevant thing I could find there was a link back to PrizmSDK Setup Guide page. What I ended up doing was finding a link to PrizmSDK 0.3 on the news post about PrizmSDK 0.3 here at Cemetech. Now, I know that PrizmSDK 0.3 is outdated, so I'd like to update it if possible. How can I do that? I saw that newer versions of libfxcg were available somewhere, but that's not the entire SDK. I'm not sure if it's possible to download that and put it in the SDK I currently have or if there's somewhere I can find a complete SDK.

2. In the project I have, there's currently several .c and .h files in the src folder, and I also have one subfolder in the src folder that contains .c and .h files. More specifically, the subfolder contains one .h file that defines a bunch of types and one .c/.h file pair that contains a function called MallocWrapper. (If you're curious, it essentially just calls malloc and checks if the result is NULL, in which case it enters a loop where the only thing the user can do is to use the MENU key to exit.) The .h file that defines types works just fine, but I haven't been able to call MallocWrapper. When I try to make the program, what I assume is the linker gives me the build error "undefined reference to '_MallocWrapper'". What's wrong, and how can I resolve it? Do I need to do something special to make it pick up on .c files in subdirectories?

1) I'm not sure where the direct download link on WikiPrizm went, but there appear to be direct download links on Jonimus's website: http://jonimoose.net/2011/casio-prizm-gcc-sdk-v0-3/
2) You need to link the binary against the .o files created from your .c files. You should use a makefile for this, but the general steps that `make` would take for something like this would be:

Code:

1. That's not any newer than the version I already have, unfortunately.

2. Sorry, I don't really understand how those commands relate to what's in my project's makefile, so I'm not sure what to do with it... It did however make me realize that things are going wrong when turning the .c file into an .o file, not when linking the .o files, because the only .o files that show up in the build folder are the ones whose .c files aren't in subfolders of the source folder.

Hi JosJuice,

there used to be libfxcg etc builds for windows here http://jenkins.taricorp.net/job/libfxcg/lastSuccessfulBuild/ and they helped me to get rid of some of the problems by overwriting outdated parts of sdk - unfortunately those links appear dead now - hopefully Tari can help with this again if you ask him.

Regarding your sub-folder issues - I have no experience with this and not even sure if I ever managed to use gcc referred to above... but wonder: couldn't you just move source files up from the subfolder for example and try to make it work with some renaming of the files if they happen to use same names like main.c etc...

By the way thank you for your old post on icons design here.

Look again.

(And go up a bit because I can't be bothered mucking with that directory layout much: http://jenkins.taricorp.net/job/libfxcg/)

Much appreciated - thank you

Thanks! I couldn't find a better way to download the files other than doing it one by one, but anyway, I got it done. I then replaced lib/libc.a, lib/libfxcg.a and the entire include folder with the new versions. I could compile my program and use the headers as described on the wiki, but at the end of the build, I now have the errors "undefined reference to '_free'" and "undefined reference to '_malloc'". What can I do to fix that?

Yes, just placing all the files in the main folder works fine. Subfolders might become more necessary if my project becomes big in the future, but this is good enough for now.

This reminds me of setjmp problems i had and couldn't resolve so far. You could try locating header and associated maloc files and placing their copies in include folder or adding them in your src folder plus adding include statements in your code header. I recall something like this may have worked for me on previous sdk version but I struggled to make it again recently

Maybe someone here can help you through offering other solution like including maloc references via dos commands or via makefiles or maybe those things are missing in the libraries or .a files we have - I don't know how those things work to be honest

On my side even standard string comparison function was causing compilation errors despite string.h etc linkage but i just copied strcmp function from string.c directly into my code and compiler stopped complaining (like in my lock add-in source code for example)

By the way what are you developing for prizm?

I don't think the header is the problem. I'm including <stdlib.h> and have checked that include/stdlib.h contains a definition for malloc. Not including it gives me a different error. I don't think there's a .c file for malloc (it's part of the Prizm operating system, right?), and I don't know how the .a files work.

What I'm working on is a secret for now It's a rather complicated for being a first project, so I want to get a part of it working before announcing it. Announcing it early and then realizing I won't be able to get it done would be a disappointment.

I have just realised there are sys_malloc and sys_free or similar system calls listed on wiki prizm under heap.h so maybe that is what you need or more likely to work with prizm.

Hope this helps with your secret project.

I'm back with another question. (There's been very little progress on my project, unfortunately... I have so much else to do that it probably never is going to get to a usable state. But anyway, the question:)

I'm trying to use the byteswapping builtins that GCC has, such as __builtin_bswap16, but it's not working. When compiling, I get the warning "implicit declaration of function '__builtin_bswap16'" on the line where I'm calling __builtin_bswap16, and then linking fails with "undefined reference to ___builtin_bswap16". How come? I haven't included any header for __builtin_bswap16, but based on what I've read, it seems like there is no header for it.

By the way, about my malloc question from last time: I can't remember how I solved it (it's been a while after all), but the code I wrote is apparently using sys_malloc and sys_free now. So I guess I went with amazonka's suggestion

An old GCC bug suggests those builtins are target-dependent. Presumably the SH target doesn't support some or all of them.

What if you used a newer version of GCC? I recall that this intrinsic is supported by newer versions of GCC.

The way you upgrade to a newer version of the SDK is to simply clone https://github.com/Jonimoose/libfxcg
and compile GCC.
This script setups up GCC and binutils without any user intervention except downloading GCC and Binutils. All you need to do is download the latest version of GCC and Bintuils and place the archives in the same directory as the script. Also note that this script assumes a *unix system.

Code:

Unfortunately, I'm on Windows It's harder in that case, right?

Maybe I'll look into it later if I manage to get serious about any project for the Prizm.

Not that much harder. One can still run a similar script using msys64.