SDK programming on fx-9750GIII
Posté le 23/10/2020 05:06
Hi, I hope it's ok if I post a question in English. Please answer in French if you like.
I just got an fx-9750GIII that I would like to make an add-in for. I setup the SDK as described here:
Programmer en C sur Graph 35/75 +E I was able to compile the example program and run it in the simulator.
I copied the Default folder and MonochromeLib files described here so the SDK will produce an SH4 add-in.
[Tutoriel] Configurer le SDK pour le rendre compatible SH4 I created a new project and got warnings about SH4_compatibility.h redefining key macros. I put #define __KEYBIOS_H__ at the top of my file so keybios.h would not include key constants and the warning went away.
My project contains MonochromeLib.c, SH4_compatibility.c, and main.c. It compiles to a G1A that is 4.34k. When I run it in the simulator, I get an error saying "Nonexisting memory by data write access at 87FFFFFC" and the trace jumps to the declaration for GetKeyMod, but maybe that is normal for the simulator if it doesn't support the new GIII. When I run the add-in on my calculator, the screen freezes and I have to press the reset button on the back.
What can I do? Does anyone have an empty project that will compile and run for the 9750GIII or 9860GIII that they can share?
Here is my code:
define __KEYBIOS_H__
#include "fxlib.h"
#include "SH4_compatibility.h"
#include "MonochromeLib.h"
// #include "string.h"
int AddIn_main(int isAppli, unsigned short OptionNum)
{
unsigned int key;
//Bdisp_AllClr_DDVRAM();
ML_clear_vram();
locate(1,4);
Print((unsigned char*)"This application is");
locate(1,5);
Print((unsigned char*)" sample Add-In.");
while(1){
GetKey(&key);
}
return 1;
}
Citer : Posté le 10/05/2021 16:43 | #
These modules are provided by the fxSDK, along with compiler settings. You can use fxsdk build-fx or fxsdk build-cg which will run CMake and make for you. If you want to pass additional parameters besides the default, use fxsdk build-fx -c ... to pass CMake parameters, or fxsdk build-fx ... to pass make parameters.
Citer : Posté le 10/05/2021 17:16 | #
So nothing to build or install for gint before I can use it? Hmm, I tried running sh-elf-gcc --print-search-dirs but I'm not sure where to move gint. Do the include and lib folders need to be copied separately to the existing include and lib folders?
Citer : Posté le 10/05/2021 17:27 | #
You do need to build and install gint; however it is now an fxSDK library, therefore you should build and install it with the fxSDK commands. Previously, gint included cross-compiling code and different build system tools that had to be replicated for every library or program destined to the calculator. Since the change to CMake, all these tools are now provided by the fxSDK.
gint, in a sense, is now an fxSDK project and you can build and install it like this:
% fxsdk build-cg install
It installs itself in the compiler's default search path (in the install search dir that you queried).
Once you've done that, you can create new projects with the fxSDK and have them use gint as it will be installed. (For new projects, you can pass --makefile to fxsdk new if you want the old Makefile-based system, or just fxsdk new with the new CMake-based one. There is an introduction to CMake here if you want details; you can copy-paste it to DeepL for a very good translation.)
Citer : Posté le 10/05/2021 17:39 | #
That's an interesting way to do it! Another error. Hmm, do I need to install OpenLibM separately?
In file included from /home/druzyek/fx9750giii/gint/gint/src/3rdparty/grisu2b_59_56/grisu2b_59_56.c:26:
/home/druzyek/fx9750giii/gint/gint/src/3rdparty/grisu2b_59_56/k_comp.h:26:10: fatal error: openlibm.h: No such file or directory
26 | #include <openlibm.h>
| ^~~~~~~~~~~~
Citer : Posté le 10/05/2021 17:46 | #
Hmm, yes, I forgot to mention it. This is required for math functions and floating-point printing in printf()-family functions. OpenLibm is a port of an existing project with its own build system, so it's not an fxSDK project. It is compiled with a simple make command, please see this section of the README.
As you can guess, over time the number of ported libraries and tools has increased. Most of them can be installed in minutes once you get used to the process, but I realize it's a bit tedious. This is another reason why I designed GiteaPC, as it automates some of this work. Because of the wide range of skill in the user base of the fxSDK, I have yet to find a comfortable way of handling the install process. Feedback is welcome.
Citer : Posté le 10/05/2021 17:49 | #
Holy moly
Citer : Posté le 10/05/2021 18:07 | #
There are no more dependencies, fortunately. There is a project to build a proper libc (as currently gint simply provides the most commonly-used functions), which would become one in the future, but at this point I might start shipping binary versions of the development environment. Right now you should be good to go
Once again thank you for bearing with me!
Citer : Posté le 10/05/2021 23:23 | #
It works! I feel like I should make something to prove it works. Thanks for all your help!
I noticed that Hello, World is now 26k. Is there any way to cut that down a little? Is it including the whole floating point package and other stuff I won't need?
Citer : Posté le 10/05/2021 23:32 | #
That's awesome! Good job! o/
It's a little bit heavy indeed. The floating-point is not included (as part of an effort to not blow up the file size). You can see exactly what's included by generating and checking the map file. This option will enable the generation during link in CMakeLists.txt:
then read build-fx/map after recompiling.
What you get in the default add-in is mostly base drivers, drawing functions, the heap and printf-style functionality (floating point excluded). It's difficult to cut it down, but the most important is what happens next. There are popular add-ins programmed "naively" that get over 100 kB because of imperfect structure, while others are much more compact. In general, since the storage memory is big, 25 kB doesn't matter too much.
Citer : Posté le 18/05/2021 15:11 | #
I'm back with more errors! I tried installing on a fresh copy of Ubuntu 21.04 rather than a copy upgraded from 20.04 which is how I got it working last time. Here's what I get when I try to run fxsdk build-fx on a new project:
CMake Error at CMakeLists.txt:10 (find_package):
By not providing "FindGint.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Gint", but
CMake did not find one.
I did try GiteaPC again on a fresh install of 21.04 and it installed but wouldn't work (I didn't save the error).
Here's my attempt at a build script:
export PAUSE_BETWEEN=false
export BINUTILS_VER="2.36.1"
export GCC_VER="11.1.0"
export PREFIX="$HOME/fx9750giii/sh-elf-$BINUTILS_VER-$GCC_VER"
export PATH="$PATH:$PREFIX/bin"
function pause_key() {
if [ "$PAUSE_BETWEEN" = true ]; then
read -p "$1"
fi
}
sudo apt install -y libmpfr-dev
sudo apt install -y libmpc-dev
sudo apt install -y libgmp-dev
sudo apt install -y libpng-dev
sudo apt install -y libppl-dev
sudo apt install -y flex
sudo apt install -y g++
sudo apt install -y git
sudo apt install -y texinfo
sudo apt install -y tree
sudo apt install -y cmake
mkdir -p $PREFIX
cd $PREFIX
sudo apt install curl
curl -u anonymous: -O ftp://ftp.gnu.org/gnu/binutils/binutils-$BINUTILS_VER.tar.xz
curl -u anonymous: -O ftp://gcc.gnu.org/pub/gcc/releases/gcc-$GCC_VER/gcc-$GCC_VER.tar.xz
tar -xJf binutils-$BINUTILS_VER.tar.xz
tar -xJf gcc-$GCC_VER.tar.xz
mkdir build-binutils build-gcc
tree -L 1
pause_key "Press enter if tree looks correct"
#moved above
#export PATH="$PATH:$PREFIX/bin"
echo "export PATH=\"\$PATH:$PREFIX/bin\"" >> $HOME/.profile
cd build-binutils
../binutils-$BINUTILS_VER/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --disable-nls --program-prefix=sh-elf-
pause_key "Press enter if build-binutils configured correctly"
make -j4
pause_key "Press enter if binutils built correctly"
make install
pause_key "Press enter if binutils installed correctly"
cd $PREFIX/build-gcc
../gcc-$GCC_VER/configure --prefix=$PREFIX --target=sh3eb-elf --with-multilib-list=m3,m4-nofpu --enable-languages=c,c++ --without-headers --with-newlib --disable-nls --program-prefix=sh-elf-
pause_key "Press enter if build-gcc configured correctly"
make -j4 all-gcc
pause_key "Press enter if gcc built correctly"
make install-gcc
pause_key "Press enter if gcc installed correctly"
make -j4 all-target-libgcc
pause_key "Press enter if libgcc built correctly"
make install-target-libgcc
pause_key "Press enter if libgcc installed correctly"
#END OF GCC/BINUTIL INSTALLATION
#INSTALLATION OF FXSDK
cd $PREFIX
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade Pillow
sudo apt install -y libpng-dev
sudo apt install -y libusb-1.0-0-dev
sudo apt install -y pkg-config
git clone https://gitea.planet-casio.com/Lephenixnoir/fxsdk
pause_key "Press enter if fxsdk cloned"
cd fxsdk
sudo cmake -B build -DFXLINK_DISABLE_UDISKS2=1
sudo make -C build
pause_key "Press enter if fxsdk built successfully"
sudo make -C build install
pause_key "Press enter if fxsdk installed correctly"
#END OF FXSDK INSTALLATION
#GINT INSTALLATION
cd $PREFIX
git clone https://gitea.planet-casio.com/Lephenixnoir/OpenLibm
pause_key "Press enter if OpenLibm cloned"
cd OpenLibm
OL_PREFIX=$(sh-elf-gcc --print-search-dirs | grep install | sed 's/install: //')
make USEGCC=1 TOOLPREFIX=sh-elf- libdir="$OL_PREFIX" includedir="$OL_PREFIX/include" install-static install-headers
pause_key "Press enter if OpenLibm built correctly"
cd $PREFIX
git clone -b dev https://gitea.planet-casio.com/Lephenixnoir/gint
pause_key "Press enter if gint cloned"
cd gint
fxsdk build-fx
pause_key "Press enter if gint built correctly"
echo -e "\033[0;32mCasio install done"
echo "RESTART SHELL"
Citer : Posté le 18/05/2021 15:48 | #
You're almost there! At the very last step you ran fxsdk build-fx which does build gint but does not install it (it's like make alone). Make that fxsdk build-fx install (which is like make install) and you'll be up and running.
Citer : Posté le 12/07/2021 06:29 | #
Has anything changed in the past few months by chance? I got a new linux machine and tried the steps above. fxsdk build-fx install is giving me this for the first time:
-- The ASM compiler identification is unknown
-- Didn't find assembler
CMake Error at CMakeLists.txt:4 (project):
The CMAKE_C_COMPILER:
sh-elf-gcc
is not a full path and was not found in the PATH.
gcc is definitely in PATH. Running sh-elf-gcc from the command line produces the familiar "no input files" message. Any ideas?
Citer : Posté le 12/07/2021 08:45 | #
Nothing changed recently that would cause such a bug. The compiler has always been specified as sh-elf-gcc so far and the PATH has always been resolved this way.
Do you run the fxSDK from the command-line too? The PATH might be different on command-lines and non-command-lines because the PATH is often set in .bashrc (or similar file for other shells) which is not read when starting a program outside of a terminal.
I can only suggest to try and determine the PATH within CMake. You should be able to print it with
although I'm not sure in which file is the best.
Citer : Posté le 13/07/2021 06:43 | #
I tried the process on a fresh VM identical to what I had when it was working previously and got the same error. Could it be some of the commits to fxsdk and gint I see over the past few months?
Yes, I can run fxsdk from the command line. It appears to build and install correctly. echo $PATH shows the same as it does on the VM installation you helped me with a few months ago.
I noticed that the old working version has a CMakeCache.txt in the gint/build-fx directory with directories properly filled in:
CMAKE_ADDR2LINE:FILEPATH=/home/druzyek/fx9750giii/sh-elf-2.36.1-11.1.0/bin/sh-elf-addr2line
//Path to a program.
CMAKE_AR:FILEPATH=/home/druzyek/fx9750giii/sh-elf-2.36.1-11.1.0/bin/sh-elf-ar
The newer one that fails does not:
CMAKE_ADDR2LINE:FILEPATH=/usr/bin/addr2line
//Path to a program.
CMAKE_AR:FILEPATH=/usr/bin/ar
Any idea how that could happen?
Citer : Posté le 13/07/2021 09:19 | #
Hmm I reviewed all the commits from the last 3 months, but only a couple affect the CMake system, and none evokes such an error, which is strange. If you have enough time, you can always try an older version or even bisect it.
There are no commits that change the build system in 2.5.1 and 2.5.2. On May 18th when the last message on this topic was posted, version 2.4.0 was already up so the only time frame is between 2.4.0 (7804ccf000) and 2.5.0 (33fb115ab), where 3 commits change the build system:
Of these, only the second suggests it could possibly change PATH detection. Maybe set the minimum version to 3.18, either by locally reverting the commit or simply editing the files at their install site.
Some things to try and put in FX9860G.cmake or FXCG50.cmake :
message("The PATH is: $ENV{PATH}")
# Have the shell find and run it
execute_process(COMMAND sh-elf-gcc -print-file-name=.)
# Have CMake find it
find_program(SHCC sh-elf-gcc)
message("SHCC: ${SHCC}")
Citer : Posté le 14/07/2021 23:48 | #
I tried adding the line to show PATH in FX9860G.cmake and it doesn't have the path to the compiler in either the old working version or the new non-working version.
For what it's worth, the CMakeLists.txt for the working version of gint shows 2.4.0.
I think the CMakeCache.txt file in gint/build-fx might be the key to this. It contains the full path in the working version above and something generic in the non-working version. I'll try to understand how this is generated and report back.
Citer : Posté le 14/07/2021 23:53 | #
So can you confirm that the PATH within CMake is different from outside of it in the terminal?
CMakeCache.txt is generated based on variables computed in the CMake script. It is used to optimize reconfiguration, essentially. In most situations you don't have to worry about it except delete it (along with the whole build directory) when you want to reconfigure from absolute scratch.
Good luck with this, I'm as puzzled as you there.
Citer : Posté le 15/07/2021 00:50 | #
Correct, the PATH in cmake has only the minimal set of folders and nothing added to PATH in ~/.profile including the gcc path. It does have the full path in the terminal version of PATH.
It sounds like CMakeCache.txt is not what I need. Replacing it with a copy from the working version with correct paths stops it from complaining about CMAKE_ASM_COMPILER not being defined, but it still complains about CMAKE_C_COMPILER since it's not defined in the file. Adding a definition for CMAKE_C_COMPILER to CMakeCache.txt does not make any difference. It outputs a new CMakeCache.txt without CMAKE_C_COMPILER and with permissions set to 622 even after changing them to be able to add the CMAKE_C_COMPILER definition.
I'll keep looking...
Citer : Posté le 15/07/2021 09:05 | #
Normally you should not have to change CMakeCache.txt, this is unnatural.
I'm thinking that for an external program to have access to the environment variable, it needs to be exported. Does your .bashrc or .profile file really export it?
You can also add echo $PATH to the fxSDK script fxsdk/fxsdk.sh right around the call to CMake and see what the value is here. I think it would be useful to determine when exactly the value of PATH is lost to understand what went wrong.
Citer : Posté le 18/07/2021 02:20 | #
Here's .profile:
export PATH="$PATH:$HOME/fx9750giii/sh-elf-2.36.1-11.1.0/bin"
#set PATH so it includes user's scripts folder if it exists
if [ -d "$HOME/scripts" ] ; then
PATH="$HOME/scripts:$PATH"
fi
It seems to export $PATH successfully:
Do you mean I should add echo $PATH to the script /usr/local/bin/fxsdk? I tried putting it at the top of the script and only got the base $PATH version without gcc: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
I'm completely new to Linux and when I asked online trying to understand this, it seems this is somehow normal for $PATH.
Would I put the echo $PATH call near the call to cmake on line 176 or so below the comment "CMake version; automatically configure
"? I believe this is the only direct call it it in /usr/local/bin/fxsdk.
I'll start downloading old commits and try to find the first one that doesn't work.
Citer : Posté le 18/07/2021 15:55 | #
Thank you for investigating this! I thought you hade a bit more experience with Linux, so I included some details below to hopefully clear some things up for you.
Yes precisely. PATH is, as you may know, an environment variable, a kind of named variable that is defined for each process in the system (this applies to almost any OS, not just Linux). PATH is ubiquitous at it is used to locate programs, and it is important that it is passed properly from process to process, so that CMake can for instance find sh-elf-gcc.
The export command is a shell command that does two things; first it assigns a shell variable (which is like any variable in a C program); second instructs the shell to export it, meaning that every process which the shell spawns from that point on will have that PATH passed as an environment variable.
(For your information, when you log in you have what is called a login shell running behind-the-scenes along with your desktop, and that shell is what reads .profile. It exists as long as you are logged in. This is not the same shell that you obtain when you obtain a terminal; that one is tied to the terminal window and is closed with it.)
By printing PATH from inside the fxsdk script, you have proven that the value of this variable for the fxSDK process is not what we intend it to be. So the question is why would the shell not set the PATH as we intend when starting the fxsdk process? This all seems pretty strange to me, but there is surely a reasonable explanation. Do you run the fxsdk command with env or sudo or another wrapper program?
Addition: It doesn't matter where you put the echo "$PATH" in the script since the variable is never changed. Still, you are correct that there is only a single call to CMake.