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 23/10/2020 06:13 | #
Don't use MonochromeLib, it is currently incompatible with fx-9750GIII models. Someone may be able to provide a patched version, or if you feel up to it install WSL and use gint instead.
Citer : Posté le 23/10/2020 09:23 | #
Hello Druzyek
It's totally fine to post in english, we're used to it. o/
As Kbd2 said MonochromeLib is not compatible with fx-9860GIII because the screen has changed, thus breaking the MonochromeLib's driver. I think @Lephenixnoir can provide a patch.
But today MonochromeLib is a bit out-of-date, as gint is way far better, faster, stronger and more compatible with different models than everything else. Some good news for you:
– fully compatible with all B&W models
– enable more RAM on the SH4 models
– provides a gray engine
– better input API
– so fast /o\
– and more…
This requires installing a custom GCC and some tools, but the tutorial is quite clear and you still can ask questions if you're stuck
Citer : Posté le 23/10/2020 09:48 | #
For completeness, here is the GIII-compatible ML_display_vram() function. Other direct-DD functions should be changed as well, but people normally don't use them as the double buffering method is fast enough on these small-screen models.
{
char *LCD_register_selector = (char*)0xB4000000, *LCD_data_register = (char*)0xB4010000, *vram;
int i, j;
vram = ML_vram_adress();
for(i=0 ; i<64 ; i++)
{
*LCD_register_selector = 8;
*LCD_data_register = i|128;
*LCD_register_selector = 8;
*LCD_data_register = 4;
*LCD_register_selector = 10;
for(j=0 ; j<16 ; j++) *LCD_data_register = *vram++;
}
}
If you consider taking the gint route as suggested (in which case thank you!), please be aware that some extra work is needed to set it up, and libc support is not yet as complete as the fx-9860G SDK (though this is improving).
Citer : Posté le 24/10/2020 00:04 | #
Thanks for the answers. The new ML_display_vram works fine! I think this will be enough to play around with for a little while.
I have Ubuntu installed on a virtual machine, so I'll give gint and fxSDK a try this weekend. libc support is not totally necessary, so that's no problem. Should I be able to use everything on my GIII or will I need to make adjustments?
Citer : Posté le 24/10/2020 00:12 | #
Excellent, happy fiddling around!
You should be able to use gint out-of-the-box on the GIII, I am aware of no compatibility issues for this model right now. There is no package for it on Ubuntu (unfortunately) so here's a roadmap to hopefully make it easier:
• First get a cross-compiler; there is a tutorial in French, which DeepL provides a quality translation for.
• Then you can install the fxSDK; there are instructions in the repository.
• Finally you can install gint; again there are instructions in the repository. Please checkout and build the dev branch.
There are some introductory gint tutorials (in French again!), since you seem to have experience you might prefer browsing the headers for an overview of the features.
Citer : Posté le 24/10/2020 00:16 | #
No adjustment necessary for gint, it's compatible with most monochrome calculator models
Note that gint isn't fully compatible with Casio's 9860G emulator (the one used in the Casio SDK) yet, so that may be buggy if you decide to test gint programs with it.
Citer : Posté le 24/10/2020 00:18 | #
Ah yes that's a good note here, the oldest models are the ones I'm having the most trouble with (mainly because I don't have them physically so bugs go untested x_x). Support for the fx-9860G SDK emulator is partial and this will show in mainly three situations: add-ins over 220 kiB, calling the main menu while executing, or using the filesystem.
Citer : Posté le 26/10/2020 01:58 | #
EDIT: I got it to work by cloning the dev branch of gint instead of the master!
I got everything set up and was able to compile,
but the add-in crashes my calculator.I downloaded gcc 9.3.0 (scrolled all the way down and missed the 10.x versions at the top of the page) and binutils 2.9.1. Trying to build binutils caused an error, which I should have noted, so I switched back to 2.32. fxsdk and gint installed fine. I made a new folder and started a project with "fxsdk new testprog" then compiled with "fxsdk build-fx" which produced testprog.g1a. It installed on my calculator and the icon shows in the menu. When I try to start it, the screen goes blank for a few seconds then the calculator restarts. Ubuntu shows the size of the g1a file as 19,584. I also tried installing in a different directory with the script posted yesterday by Dark Storm for installing under Ubuntu then changing the PATH to point to the new installation. The resulting g1a was 19,376 bytes in size but also crashes my calculator. I tried running the last version in the Windows SDK and it also crashes with the error "Nonexisting memory by data read access at A4490004."
Any ideas?
Ajouté le 26/10/2020 à 04:22 :
I saw in the thread on Terrario that the 9750GIII has about 90k of heap but that malloc can be buggy. Can I get a pointer to where it starts and manage the heap myself? Will all of it be free when the add-in starts? How about XRAM and YRAM? I also saw that the SH4 models have 32k of stack, which seems like several times more than you would be likely to use for locals and return addresses. Can I use one end of it like heap memory? Thanks in advance.
Citer : Posté le 26/10/2020 08:30 | #
The fxSDK and gint repository are not perfectly in-sync right now (some changes in gint dev are already in fxSDK master which is quite bad) and I'm looking at ways to make sure it doesn't happen in the future. Thank you for bearing with it.
We generally know the heap address but not the heap format, and as you have guessed is an important issue, not whether the heap is empty. The general answer is probably not because of the E-ACT mechanism that allows two apps to be started simultaneously. Until now I am not aware of any attempt to manually use the heap space for add-ins.
I would recommend to avoid it if possible because of risks that the heap manager changes and other compatibility issues with models that don't all have the same heap size. If you need large buffers, you can probably allocate them somewhere else :
• In the fast ILRAM (4 kiB) (GILRAM)
• In the XRAM (8 kiB) or YRAM (8 kiB) of the integrated DSP (GXRAM, GYRAM)
• In the newly-discovered SPU memory areas (32-bit access only, up to 424 kiB, after spu_zero())
gint has macros for the first three areas, you can declare a simple global variable like this:
/* This will be allocated in XRAM */
GXRAM uint16_t z_buffer[2048];
The SPU memory is a recent discovery for which I have added support just this week (!), just call the fixed function spu_zero() to pull in the SPU driver (which will initialize the SPU and that memory at startup) and you're ready to go. There are quite a few limitations, please see the linked documentation to see if it suits your needs.
I don't know about the size of the stack, I don't think it is easy to determine. However there is more of what we call "static RAM" which is a fixed area at 08100000 basically for the .bss and .data sections. SH4 models do have 32 kiB of it while older SH3 models only have 8 kiB. Currently there is not SH4-only linker script in gint, thus the size of these sections is limited to 8 kiB.
This means that the other 24 kiB are absolutely free for you to use, you can access them at 08102000. Because this area is not declared in the linker script, you'd have to assign addresses to every variable manually, so it's easier if you use it for large buffers rather than trying to arrange small variables by hand.
Citer : Posté le 07/05/2021 21:18 | #
I redid my Ubuntu VM and tried to reinstall, but the instructions for installing fxSDK have changed! Can someone help me install fxSDK? I cloned GiteaPC then tried running make then install.sh but then got all kinds of errors:
install.sh: 30: [[: not found
install.sh: 30: [[: not found
install.sh: 30: [[: not found
install.sh: 30: [[: not found
install.sh: 30: [[: not found
I have to say doing it this way is much less intuitive than how it was done before! Having no readme for GiteaPC doesn't help either.
Citer : Posté le 07/05/2021 21:25 | #
I'm sorry about that! Since we last discussed it I decided to use CMake instead of plain Makefiles, because it is easier for me to maintain in add-ins and it covers a wider range of platforms that the previous system didn't (such as Mac OS).
You can still build manually, the original instructions are listed at the end of the README file or on the repository page. This uses CMake now, but it is simply a matter of installing it and running the new commands, no trickery involved.
Given the errors that you have with GiteaPC, it is clear that you're using either sh or bash in compatibility mode as your shell. The one-liner to use GiteaPC specifically says bash in the command, so I'm not sure how you end up with sh. Breizh_craft might know. But anyway don't feel compelled to use GiteaPC if you don't feel it is more natural, it's meant mostly for beginners that aren't familiar with the build process.
Edit : The GiteaPC details are actually in this topic (which should be understandable with a layer of DeepL), I should have linked it properly. Sorry for that.
Citer : Posté le 07/05/2021 21:44 | #
Thanks for getting back to me and for the GiteaPC instructions! I'll try the manual build instructions since it's similar to what I did before. First, do I need to do anything special to clean out the failed GiteaPC install? I removed giteapc from the bin directory. Is there anything else?
I tried running "cmake - B build" and got this:
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:41 (find_package_handle_standard_args)
CMakeLists.txt:8 (find_package)
As for compatibility mode, I'm a total beginner to Linux so that may be true. Would the command be "bash install.sh" instead of "sh install.sh"? I don't honestly know the difference yet.
Citer : Posté le 07/05/2021 21:58 | #
Ideally you should have removed GiteaPC with itself, but that's no problem, you can still finish manually. To fully clean up, you should also remove:
With these files gone there will be no trace left of the attempt.
Ok so you're starting with a bare-minimal install. pkg-config is a tool used by libraries to supply compilation and link flags, and it's used extensively in all distributions. The fxSDK uses it to find libraries like libusb or libpng. You can install it with the pkg-config package with apt.
As for sh versus bash, sh is the historical shell in Linux distributions, and bash is one (arguably the most popular) of its evolutions. The difference is that bash is newer and has more features, basically. The [[ thing that failed the script is a syntax for conditions that is used in bash (but not available in sh). If you look at the GiteaPC topic you will see that the recommended command uses bash because install.sh needs it; if you had typed "bash install.sh" it would likely have been fine. But then again - it's just an optional tool to make things quicker, manual installs are fine too.
Citer : Posté le 07/05/2021 22:27 | #
Making progress I think! Next error for building fxSDK:
-- No package 'udisks2' found
CMake Error at /usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:463 (message):
I ran "sudo apt install udisk2" before trying to install. Here is what I get when running it again:
Yes, it's a bare minimum install for this and only one other thing I can't do on Windows
Citer : Posté le 07/05/2021 22:30 | #
Hello, on Ubuntu developpement packages are separated. You probably need libudisks2 and libudisks2-dev.
Citer : Posté le 07/05/2021 22:31 | #
UDisks2 is a tool in Ubuntu that manages removable disks. There is a recent feature in the fxSDK to send files to calculators with USB Mass Storage (such as the GIII) from the command-line, and this uses UDisks2 to access the filesystem.
I'm not sure yet why CMake would not find it if it's installed. You can try to install libudisks2-dev ; in Debian and its derivates usually the files for program development are separate.
If it's still doesn't work, there is a flag called -DFXLINK_DISABLE_UDISKS2=1 that you can pass to the cmake command (not the make command) which will disable this feature and will allow you to build without this dependency. If you're using a virtual machine then it might be easier to share the folder with your G1A file and send it using tools on Windows, depending on your preferences.
Thank you for your perseverance, you should be up and running soon.
Citer : Posté le 10/05/2021 06:09 | #
Installing libudisks2-dev didn't stop the script from erroring. Would I have to modify it to point to that instead of udisks2? It compiled and installed with the -DFXLINK_DISABLE_UDISKS2=1 option.
On the fxsdk gitea page it shows that "fxsdk create" will create a new project, though I think that should be "fxsdk new."
fxsdk build requires a newer version of CMake than you can get with Ubuntu 20.04. I'll try upgrading to 21.04 and trying again tomorrow.
Citer : Posté le 10/05/2021 08:44 | #
Installing libudisks2-dev didn't stop the script from erroring. Would I have to modify it to point to that instead of udisks2? It compiled and installed with the -DFXLINK_DISABLE_UDISKS2=1 option.
There is no pointing to do, since pkg-config will find it on its own. I'm surprised, because the list of files for libudisks2-dev on Debian has a udisks2.pc file (near the end) which is exactly what pkg-config will use to find the library. Well, that may warrant more investigation, but I agree it's simpler to move on for now.
I had missed that during some update, thank you.
That's annoying. I have reduced this required version number several times already, and people keep running into this issue. I don't really understand how distributions have versions 18 months old, but I guess I'll have to try and get it lower. Sorry for the inconvenience. >_>
Ajouté le 10/05/2021 à 15:35 :
I've set the minimum version to 3.15 on the main repositories (dev branch for now), this is the oldest easy version to grab (some of the new features of CMake 3.15 are used in the fxSDK). It's a July 2019 release.
Seeing that Ubuntu bionic is still in 3.10 (November 2018) is kind of disappointing, but I guess this is how LTS is handled. Ubuntu focal has CMake 3.16 so everything should be alright. I found that one of the files still requested version 3.18 by mistake, so if you run into that simply grab the dev branch of the repository or change the file, it's not a hard requirement.
Citer : Posté le 10/05/2021 16:41 | #
Thanks! fxsdk runs now and complains about not finding gint, so on to the next step.
I cloned the dev branch of gint and tried building with cmake -b. It errors in CMakeLists.txt because it can't find GitVersionNumber, Fxconv, or git_version_number. Any ideas?
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.