Omnimaga
Calculator Community => Casio Calculators => Topic started by: Kristaba on February 15, 2011, 08:43:56 am
-
Hey guys :)
I saw nobody here posted a real tutorial about how to build stuff for SH3 (and later for Prizm itself) :(
Simon Lothar and Andreas Bertheussen, two casio hacker, made some years ago a good reverse engineering of fx9860 calculator, and they wrote some tools
for, and some informations about how to use GCC to make G1A Addin :
http://sourceforge.net/apps/trac/fxsdk/wiki/UsingGCC (http://sourceforge.net/apps/trac/fxsdk/wiki/UsingGCC)
I advise you to subscribe and download the Kpit GNU tools (most recent and up-to-date) at http://www.kpitgnutools.com/index.php (http://www.kpitgnutools.com/index.php)
They have a strange policy : they allow to download freely the code (because GCC is under GNU GPL license of course ::) ) but you need to subscribe to download the binaries, so I think it could be a good thing to distribute ourselves the binaries from their source in the future...
The link I give is about fx9860, so they are some thing to do before use this for the Prizm :
* In addin.ld change "rom : o = 0x00300200" by "rom : o = 0x00300000"
* crt.s need to be modified (we need to to do a reverse-engineering on the Prizm initilization code)
* a g3a wrapper
Edit :
Okay, so I disassembled Converter addin this morning (downloaded on casio.edu) to try to isolate the init stuff.
The complete disassembled sources (all conv.g3a), with only some labels to understand more the code (because 200 lines of assembly without any label to indicate constant values, loops and functions is really hard to read) is here http://pastebin.com/xT8XNAhH (http://pastebin.com/xT8XNAhH)
I rewrote the code that seems to be the init stuff, and as I expected it's very similar to the fx9860 crt0.s written by SimLo and/or Andreas, but it seems call only _GLibAddinAplExecutionCheck after the ram is initialized, and immediately jump to _main...
So it's either the Prizm OS does a part of the initialization that was did by the addin code in fx9860 OS, or a part of the Converter code I thought it's the "_main" code is in fact init code.
Maybe Simon Lothar already isolate the init stuff, so, if you see this, please say what you think about that...
crt0.s : http://pastebin.com/ccE3NPhZ (http://pastebin.com/ccE3NPhZ)
my addin.ld : http://pastebin.com/YMrdDHWS (http://pastebin.com/YMrdDHWS)
(and really sorry for my poor english ;D)
-
Great! I can't really check this out now, since I don't have a Prizm yet... But it certainly does look nice. Is this mostly for assembly, or is it for C?
* In addin.ld change "rom : o = 0x00300200" by "rom : o = 0x00300000"
Shouldn't this be 0x00307000 on the Prizm?
-
Great! I can't really check this out now, since I don't have a Prizm yet... But it certainly does look nice. Is this mostly for assembly, or is it for C?
* In addin.ld change "rom : o = 0x00300200" by "rom : o = 0x00300000"
Shouldn't this be 0x00307000 on the Prizm?
Yeah, I know the problem because I haven't my one yet too :/
It's a fully GCC so you can compile a lot of languages, mainly asm and C, but also C++ (with some change to remove the runtime), Ada, Fortan, etc...
And no, it seems Prizm set the MMU to 0x300000 as the first code address (Andreas wrote this in Casio Kingdom same days ago)
Edit 02/16/11 :
First post updated
-
Hmm nice, hopefully this could be useful, since both calcs are similar processor-wise.
-
I attached the current version of insight (see directory projects\insight\insight.g3a). The source and the tools to build the g3a are included, too. Only one exception: the BIN-directory of the legacy CASIO fx-9860 SDK, which is needed, is not included.
EDIT:
New version: http://ourl.ca/9205/182330
version 1.01 removed.
-
Nice, I just checked and I like it so far. :D
-
Insight version 1.02:
RTC read and set; battery voltage; new syscalls; a new library fxCG_TOOLS.LIB; 256 color bitmap to fxCG icon converter; memory search; memory backup.
Outdated: update here http://ourl.ca/9205/187104
-
Cool, thanks for the update. :D
-
I actually have my own built toolchain I built based on GCC as I didn't want to register to dl the one from that KPIT site. It can be found at http://jonimoose.net/prizm/sh3-unknown-elf/ (http://jonimoose.net/prizm/sh3-unknown-elf/) the two tars are identical one just used xz compression to be smaller.
-
Cool to hear Jonimus. :D
-
Insight version 1.03:
a little display demo: moving and bouncing objects; a HTMLHELP-file with some information concerning syscalls of fx-9860- and fx-CG-systems (to be continued).
EDIT: ah, yes. @cfxm: and a new pair of my cute icons, which everyone loves. ;D
EDIT(2011-04-03):
Updated: http://ourl.ca/9205/193577
version 1.03 removed
-
I totally like the display routine! :w00t:
-
For a bit I thought the display thing was separate from Insight and I couldn't find the file, so I had to sign up on Casio site to download the 9860G SDK and stuff, but then I realized it was part of Insight. X.x
Anyway this looks nice. I'm glad to see more showcases of SH3 ASM programs.
EDIT: Here's a screenshot (well... sort-of). Don't use Internets Exploder to ruin it.
-
I totally like the display routine!
So? Then if you like it crowded, try this...
@DJ_O: it is C, not assembler!
static unsigned int lastrandom=0x12345678;
unsigned short random( int seed = 0 ){
if (seed) lastrandom=seed;
lastrandom = ( 0x41C64E6D*lastrandom ) + 0x3039;
return ( lastrandom >> 16 );
}
#define NSHAPES 100
//
int MoveOne( TBdispFillArea a[], TShapeProps sp[], int idx ){
int vy1, vy2, j, k;
int xoverlap, yoverlap, overlap;
int xd, yd;
a[idx].x1 += sp[idx].dx;
if ( a[idx].x1 >= 384 - sp[idx].wx){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
sp[idx].dx = -1; // cold wall
return 0;
}
if ( a[idx].x1 <= 1){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
sp[idx].dx = 3; // hot wall
return 0;
}
for (j=0;j<NSHAPES;j++){
overlap = 0;
if ( j != idx ){
xd = a[idx].x1 - a[j].x1;
yd = a[idx].y1 - a[j].y1;
if ( xd * xd + yd * yd < 100 ) overlap = 1;
if ( overlap ) break;
}
}
if ( overlap ){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
k = sp[idx].dx;
sp[idx].dx = sp[j].dx;
sp[j].dx = -k;
return 0;
}
a[idx].y1 += sp[idx].dy;
if ( a[idx].y1 >= 216 - sp[idx].wy){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
return 0;
}
if ( a[idx].y1 <= 1){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
return 0;
}
for (j=0;j<NSHAPES;j++){
overlap = 0;
if ( j != idx ){
xd = a[idx].x1 - a[j].x1;
yd = a[idx].y1 - a[j].y1;
if ( xd * xd + yd * yd < 100 ) overlap = 1;
if ( overlap ) break;
}
}
if ( overlap ){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
k = sp[idx].dy;
sp[idx].dy = sp[j].dy;
sp[j].dy = -k;
return 0;
}
k = 0;
if (sp[idx].dy<0) k -= sp[idx].dy; else k += sp[idx].dy;
if (sp[idx].dx<0) k -= sp[idx].dx; else k += sp[idx].dx;
switch (k){
case 2 : sp[idx].color = 0x001F ; break;
case 3 : sp[idx].color = 0x03FF ; break;
case 4 : sp[idx].color = 0x07E0 ; break;
case 5 : sp[idx].color = 0xFFC0 ; break;
case 6 : sp[idx].color = 0xF800 ; break;
}
a[idx].mode = 0;
Bdisp_AreaClr( &sp[idx].saved, 1, -1 );
a[idx].mode = 1;
a[idx].x2 = a[idx].x1 + sp[idx].wx;
a[idx].y2 = a[idx].y1 + sp[idx].wy;
Bdisp_AreaClr( &a[idx], 1, sp[idx].color );
memcpy( &sp[idx].saved, &a[idx], sizeof( TBdispFillArea ) );
/*
vy1 = a[idx].y1 - sp[idx].wy / 2;
vy2 = a[idx].y2 + sp[idx].wy / 2;
if ( vy1 < 0 ) vy1 = 0;
if ( vy2 > 215 ) vy2 = 215;
Bdisp_PutDisp_DD_stripe( vy1, vy2 );
*/
return 1;
}
#define V 1
void F7_Handler(){
TBdispFillArea ar[NSHAPES];
TShapeProps mp[NSHAPES];
int ticks, i, iwork;
ticks = RTC_GetTicks();
random( ticks );
while (!RTC_Elapsed_ms( ticks, 100 ));
for ( i=0;i<NSHAPES;i++){
ar[i]. mode = 1;
memset( &mp[i], 0, sizeof( TShapeProps ) );
mp[i].wx = 10;
mp[i].wy = 10;
ar[i].x1 = 11 * ((i >> 2)+1);
mp[i].color = random();
ar[i].y1 = 10 + 11 * ( i & 0x3 );
iwork = random();
iwork = ( 3 * iwork ) / 0x10000 + 1;
if ( random() & 0x8000 ) iwork = -iwork;
mp[i].dx = iwork;
iwork = random();
iwork = ( 3 * iwork ) / 0x10000 + 1;
if ( random() & 0x8000 ) iwork = -iwork;
mp[i].dy = iwork;
ar[i].x2 = ar[i].x1 + mp[i].wx;
ar[i].y2 = ar[i].y1 + mp[i].wy;
}
while ( !(*(unsigned short*)0xA44B0000) ){
for (i=0;i<NSHAPES;i++){
MoveOne( ar, mp, i );
}
Bdisp_PutDisp_DD();
}
}
Attachment removed. Actual version included here:
http://ourl.ca/9205/218371
-
Yeah sorry I meant SH3 C and ASM. I am aware that this is C. I tend to just say ASM sometimes when it comes to calculator hacking, having been used to a platform with no decent C capabilities for years (the TI-83 Plus series). ASM here would be in reference to Qwerty.55 and z80man, although they use hexadecimal rather than SH3 mnemonics.
-
Looks pretty nice, congratulations ;)
I wonder when someone will be able tor replicate this bouncing boxes demo on the Nspire (CAS) CX, which is extremely likely to be even more locked down than the earlier Nspire models...
-
I totally like the display routine!
So? Then if you like it crowded, try this...
@DJ_O: it is C, not assembler!
If something has been wrong with this post, I'd like to apologize.
English is not my mother tongue, so perhaps the post sounded rude or impolite.
Never meant to be.
-
It's ok I understand. I think the part people could have found rude is only the "!" part, but from a language to another people have different ways to say some things. An example is how in French posting all-caps words is considered as yelling, while in USA it's considered as emphasis.
I am curious how far we'll be able to push the Prizm when display routines like IonFastCopy are written.
-
I am curious how far we'll be able to push the Prizm when display routines like IonFastCopy are written.
Imagine actually being able to use real color textures in a 3D engine. Its kinda hard to distinguish texture in 4-color greyscale but imagine being able to use real color texture in a game. If you can get a routine to work fast enough then you can produce some amazing games with just that alone.
Personally, I can entertain myself for a long time just by staring at the bouncing rectangles. Imagine what games developed later on would do. ;D
-
Personally, what I'm thinking of at first is some games similar to what GBA ones look like. It would be nice to see someone attempt a color raycaster, though. Also the great thing with the Prizm screen is that there's no blur. When I tried the version of Insight with fewer squares but higher framerate, it looked like on a real LCD screen.
-
ah... CASIO I haven't used mine for a while I use ti-84 plus SE
-
ah... CASIO I haven't used mine for a while I use ti-84 plus SE
same, I never even tried out a casio calc before ^-^ but maybe soon I'll stop touching TI calcs in favor of the more free-to-program Casio calcs ^-^
also, Mario, first time I've seen you here -- you enjoying your stay here on the forums? :)
-
miniSDK (version 1.04).
New with version 1.04: SDK equipped with a GUI, to configure the projects more conveniently. The documentation of which resides in the included HTMLHELP-file (fx_calculators_SuperH_based.chm; search for "SDK, getting started"); two new functions in INSIGHT to demonstrate the speed difference between direct draw and VRAM-DMAC.
EDIT:
Attachment removed.
New version: http://ourl.ca/9205/201161
-
Whoa how are you doing all of this? That's pretty cool, but how do we replicate this in our programs? Last time I checked the VRAM-DMAC was still undocumented. What I think we need is a long explanation of how insight exactly works and how you created all of those routines. I don't mean to put any pressure on you Simon, but me and I assume many others are starting to fall behind on all of these new finds. I have several projects that I wish to start, but I cannot not start them yet as I don't understand all of the inner workings. For me as an asm coder it is important to know this because I can't rely on C routines. Also a few of us have no prior experience with other Casio calcs, like me, and are unfamiliar with the previous SDK and syscalls. An explanation from the ground up would be very helpful.
-
For me as an asm coder it is important to know this because I can't rely on C routines.
ASM and C/C++ are both important tools, if you want to program the Prizm (as well as the fx-9860 series). I daresay it is not possible to avoid either of them. Of course you have to decide carefully, which of both is the appropriate tool in a certain situation. Though, mostly it will be C. Anyhow the next version of the miniSDK will accept assembler-source-modules as well.
What I think we need is a long explanation of how insight exactly works
INSIGHT is a C-program. Therefore a pre-condition to understand INSIGHT is the knowledge of C. I am sorry not to have a better message. But myhap it is not this bad, if you should decide to learn C.
and syscalls. An explanation from the ground up would be very helpful
I tried to explain the use of syscalls from out of assembler here:
http://ourl.ca/8207/178619
...Last time I checked the VRAM-DMAC was still undocumented.
I documented the VRAM-DMAC-syscalls 0x025F and 0x0260 the first time in the HTMLHELP-file of miniSDK version 1.03.
-
Wow I tried this last night and I was amazed. O.O Somebody should try making a scrolling tilemap demo to show what could be done.
-
Thanks for pointing out the help file Simon. I had trouble opening it at first due to Windows 7 incompatibilities, but soon fixed that using 7zip. I do have a small problem now that involves the fx 9860g SDK. Apparently to download that form Casio's site you must own an fx 9860g which I do not have. Hopefully this shouldn't be too much of a problem once I finish my assembler.
In other things. What I meant to say by the Insight explanation is if you could add comments to the code. I do already know C, but it can be hard to read without comments.
Lastly with the assembler/IDE I'm working on. I'm designing it to be much more advanced than the standard gcc assembler. New features that it will include are a special type of macro (too difficult to explain here), namespaces, structs, thread support, self-modifying code support, interrupts/exception handling, auto opts, and classes/objects. The IDE will be like any standard coding IDE with syntax highlighting and all that sort, but will add certain features such as helping the coder establish code and data blocks with proper displacements along with 16 bit color tools. At the moment this project is in development and early versions will be available soon.
-
Glad to see new updates and attempts at simplifying Prizm dev. :D
-
Okay I'm working on getting a shell up and running now, but I can't find a syscall that meets one of my needs. What I need to do is to create a list of the files contained in a directory. None of the MCS or Bfile syscalls seem to accomplish this so I'm wondering if such call dos exist, is it undocumented or do I need to write a routine to find this information.
The other thing I was wondering about was if it is better to do a syscall using the 80020070 address or to just call directly to the the syscall. My only concern with calling directly was that some OS's could use different locations for the calls making some older programs unusable.
-
Okay I'm working on getting a shell up and running now, but I can't find a syscall that meets one of my needs. What I need to do is to create a list of the files contained in a directory. None of the MCS or Bfile syscalls seem to accomplish this so I'm wondering if such call dos exist, is it undocumented or do I need to write a routine to find this information.
These are the syscalls for enumerating the storage memory:
syscall 0x1DB6: int Bfile_FindFirst( const unsigned short *filename, int*FindHandle, FONTCHARACTER *foundfile, FILE_INFO *fileinfo );
FONTCHARACTER is unsigned short in the current implementation (as in the legacy systems).
typedef struct tag_FILE_INFO
{
unsigned short id;
unsigned short type;
unsigned long fsize;
unsigned long dsize;
unsigned int property;
unsigned long address;
} FILE_INFO;
The members of the FILE_INFO-struct are not filled as documented in the legacy SDK!
The function checks the length of the filename first. In case it should be greater than 0x10A the function returns errorcode -3.
Every FindHandle has to be closed with Bfile_FindClose, if is is not needed any more!
syscall 0x1DB8: int Bfile_FindNext( int FindHandle, FONTCHARACTER *foundfile, FILE_INFO *fileinfo );
syscall 0x1DBA: int Bfile_FindClose( int FindHandle );
Concerning enumeration of the MCS: I have still to check, if it can be done in the same fashion like with the legacy systems. But the interesting thing is, that Bfile_FindFirst returns "@MainMem" as found file with a search pattern "\\fls0\*.*".
The other thing I was wondering about was if it is better to do a syscall using the 80020070 address or to just call directly to the the syscall. My only concern with calling directly was that some OS's could use different locations for the calls making some older programs unusable.
At any rate the use of absolute addresses should be avoided.
-
Yes, don't use absolute addresses without an abstraction layer. Usage of absolute addresses (beyond the abstraction layer offered by "kernels") wrecked havoc on TI-68k calculators in the late 1990s, when newer OS and hardware versions were released.
-
A mini-Prizm-SDK (version 1.05).
New with version 1.05: corrected the syscall name Bdisp_AllCr_VRAM() to Bdisp_AllClr_VRAM(). Support of assembler modules as additional project sources for the main program as well as for the tools library. Centralized common libraries (f. i. syscall library), hence the directory structure has been changed. Two new important syscalls: PrintMini and PrintMiniGlyph. Changed INSIGHT's moving-boxes example to a moving-balls example to demonstrate glyph-drawing. The console based version is not longer included.
EDIT:
Update http://ourl.ca/9205/204915
-
The Casio SDK currently required to compile code for the Prizm has been made available here (http://www.fishbot.co.cc/downloads/fx9860sdk.html). Please note that you must have a Prizm Serial ID in order to download the file.
-
I have made updated and known working exe's for gcc at http://jonimoose.net/calcstuff/prizm/ and I am working on getting a setup for the syscalls working that will link with gcc. Tari on cemetech is working on getting an addin.ld and program to wrap that output in a g3a, if all goes well we should have a usable setup by tomorrow night, no more need for the Casio SDK.
-
mini-Prizm-SDK
New with version 1.06:
Syscall Bdisp_WriteGraph accompanied by some demo in insight. Stay put until you have seen the crawling Alien!
In order to allow the usage of virtual class functions, the original setup.obj has to be used, when binding.
A bug has been fixed with the "Save as..." menu option.
Updated: http://ourl.ca/9205/218371
Attachment removed.
-
NIce, I'Ll have to check out the new demo.
I'll probably post a news article about this new version as well as the Cemetech PRIZM SDK soon. (I think their version is not dependent on the FX-9860G SDK, but I don't know about the other features, as I did not check forums much lately)
-
The fx-9860 SDK has been taken down from my site because of the arrival of the working GCC compiler.
-
Do you mean the one by Tari or another one?
-
Awesome work cfxm :)
-
A mini-Prizm-SDK (version 1.07).
New with version 1.07:
Insight: FKey-icon demo (find the FKey-bitmap pointer and display).
Insight: standard-progressbar demo.
Insight: scrollbar demo.
Update:
http://ourl.ca/9205/218794
Attachment removed
-
Cool to hear :D
That reminds me, has anyone tried 3D polygons on the Prizm yet? A demo would be nice. :)
-
Cool to hear :D
That reminds me, has anyone tried 3D polygons on the Prizm yet? A demo would be nice. :)
I could try in C, but it would take a little while for the code to get running, but if BASIC is good enough I would be more than happy to make a demo of its "speed"
-
A mini-Prizm-SDK (version 1.08).
EDIT: attachment removed. Use the new version 1.09:
http://ourl.ca/9205/224838
New with version 1.08:
Insight: direct access of the serial I/O-pins (measured a 17 kHz symmetric and sharp edged square wave with my scope, though higher frequencies are possible).
BTW: I went through a world of hurt, hunting this down!
EDIT:
The following passage of the documentation (CHM) has to be corrected. The published source is OK.
At first the outer gate has to be opened:
Set bit 3 of port 0xA4050162 to output mode, t. i. set control register 0xA4050142 accordingly.
Set bit 3 and bit 2 of port 0xA4050162. Do not ask why bit 2 has to be set, too. I do not know.
How to control the output of the serial transmit pin:
Set bit 2 of port 0xA4050130 to output mode, t. i. set control register 0xA4050110 accordingly.
Set or clear bit 2 of port 0xA4050130 to control the serial transmit pin state.
How to read the state of the serial receive pin:
Set bit 3 of port 0xA4050130 to input mode, t. i. set control register 0xA4050110 accordingly.
Read port 0xA4050130 and isolate bit 3 to obtain the serial receive pin state.
-
A mini-Prizm-SDK (version 1.08).
New with version 1.08:
Insight: direct access of the serial I/O-pins (measured a 17 kHz symmetric and sharp edged square wave with my scope, though higher frequencies are possible).
BTW: I went through a world of hurt, hunting this down!
Nice what is the address for direct line access. I had tried port Q earlier, but wasn't getting any feedback. I will though be testing the SIOF later because that can play .wav files.
-
Does it means we can now have music on-calc? O.O
-
Nice what is the address for direct line access. I had tried port Q earlier, but wasn't getting any feedback. I will though be testing the SIOF later because that can play .wav files.
Because the programming of the pin function controller is involved, I think it would be best to refer to the source of insight. See function "F17_Handler()".
-
Does it means we can now have music on-calc? O.O
I wrote wav player for 9860 some time ago. I attach source code. I hope it can be ported to cg :-)
-
Does it means we can now have music on-calc? O.O
I wrote wav player for 9860 some time ago. I attach source code. I hope it can be ported to cg :-)
The 7705.h (alas it's not included in your rar) has to be replaced by some 7305.h. The syscall-numbers have to be adjusted. SCIF2 is fairly compatible (only two register addresses have been changed on the 7305). The addresses of the interrupt priority registers are different and on the 7730 there are three more to save and restore. TMU- and WDT-addresses should be adjustable, too.
The 7305 FRQCR is incompatible to the 7705's. Hence its programming has to be reconsidered.
-
Hello,
I am trying to write something slightly bigger than "hello word" for cg, I use Simon's mini-Prizm-SDK. I would like to ask:
1. Is it possible to build program from .c sources ? I do not use C++ features so I would like to save room by removing C++ support. I tried to rename the project.cpp (autogenerated source) to .c and edit project.ini (both, manually and by the build tool), but it always asked me to provide project.cpp file.
2. Is it possible to build program from multiple sources (and link together)? I see that Insight has more source files, but I was unable to include additional source to mu project. I tried the GUI build tool (=not manualy editing/hacking the project.ini).
3. How to add new syscalls ? Is there some recommended way how to add new syscall to the SDK ? There are many syscalls, which are perfectly documented in the help file, but they are not included in the header (for example serial communication).
I am asking for recommended ways, because I would like to keep my sources compatible with mini-Prizm-SDK to enable another users to build it.
And one additional question for everybody: How do you debug your project for cg calculator ?
Martin
-
And one additional question for everybody: How do you debug your project for cg calculator ?
I think most of us simply run the program on the actual calculator. The only existing fx-CG emulator is the fx-CG Manager PLUS by Casio, which is intended for education and does not offer any debug features. Sometimes it also runs add-ins a bit differently when compared to the calc, but it is in fact a real emulator. Sadly, it isn't free.
-
Actually, the KPIT GNU tools have a very nice debugger. You have to play around with them a bit in order to get the CPU simulator working, though.
-
Hello,
I am trying to write something slightly bigger than "hello word" for cg, I use Simon's mini-Prizm-SDK. I would like to ask:
1. Is it possible to build program from .c sources ? I do not use C++ features so I would like to save room by removing C++ support. I tried to rename the project.cpp (autogenerated source) to .c and edit project.ini (both, manually and by the build tool), but it always asked me to provide project.cpp file.
Why do you need .c sources. The C++ compiler has no disadvantages and is able to process c-sources as well (without the need of implementing the special abilities of C++).
2. Is it possible to build program from multiple sources (and link together)? I see that Insight has more source files, but I was unable to include additional source to mu project. I tried the GUI build tool (=not manualy editing/hacking the project.ini).
It is possible, but I must admit, that it is not well documented. The mini-SDK allows several ways to include multi-sources. But flexibility requires a lot of documentation. Gimme some time. In the next CHM-file, I will add some hints. My mini-SDK is complex. I need a very flexible tool to provide and verify the information we all need to master the Prizm. I'll try to enhance the documentation.
3. How to add new syscalls ? Is there some recommended way how to add new syscall to the SDK ? There are many syscalls, which are perfectly documented in the help file, but they are not included in the header (for example serial communication).
Select File/Full Setup
Select the Tab syscall-library
Position the cursor to the syscall where you want to insert a new syscall.
Hit INSERT.
Enter the syscall number in hex in column "Key" (f. i. 1E6A).
Enter the syscall definition in column "Value".
The syscall definition starts with the interface, f. i. in case of 1E6A void DisplayMainMenu( void ).
Then enter a a semicolon.
The next item following the semicolon defines the headerfile, where the interface has to be stored. Ususally this is an alias, f. i. $(SYSTEM_SC). See at the begin of the syscall-library-list to find the actual header-file names.
The third item following the second semicolon represents the syscalls timestamp. Leave it empty, if you insert a new syscall. The system uses the timestamp to decide, if a rebuild of the syscall is necessary. Usually it is maintained automatically.
Finally hit the SAVE-button.
The next build with F9 should include the previously added syscall in the library.
---
Sorry, if my mini-SDK is too inconvenient. I cannot help it. I need it's flexibility to find the information we all need. I hope some of you agree. And I hope even my mini-SDK could help the one and the other in their progress to do better.
I like cfxm's extremly lean micro-SDK. And I like the KPIT/GNU/GCC tool developments, though I am a friend of the lean one's.
-
Simon, thank you for reply.
I use C sources because I would like to make the result binary as small as possible. It is probably not needed now, but it is my practice/tradition.
I do not think your SDK is inconvenient. You should see my old disassembler of cfx9850G ROM dump. Or better you shouldn't :-)
-
Hello,
I am trying to write something slightly bigger than "hello word" for cg, I use Simon's mini-Prizm-SDK. I would like to ask:
1. Is it possible to build program from .c sources ? I do not use C++ features so I would like to save room by removing C++ support. I tried to rename the project.cpp (autogenerated source) to .c and edit project.ini (both, manually and by the build tool), but it always asked me to provide project.cpp file.
Why do you need .c sources. The C++ compiler has no disadvantages and is able to process c-sources as well (without the need of implementing the special abilities of C++).
So the PRIZM can use C++?
-
2. Is it possible to build program from multiple sources (and link together)? I see that Insight has more source files, but I was unable to include additional source to mu project. I tried the GUI build tool (=not manualy editing/hacking the project.ini).
If you select "Full Setup/Project-compile/Source-Files", you can insert a new line (INSERT-key) and either fill the name of the sourcefile into the value-field or select a file from a file-select-dialog using the ellipsis-button. It is very similar to the old fx9860-SDK. You can add CPP- and SRC-files. Do not forget to save the setup.
-
So the PRIZM can use C++?
I used object oriented code on the fx9860-types very extensively. And I had no problems with some experimental object oriented code on the Prizm, yet. Usually it depends on the compiler/linker/library-system, whether a C++ source can be transferred into a G3A successfully. The hardware, especially if it is more powerful, shouldn't be a problem.
-
A mini-Prizm-SDK (version 1.09).
New with version 1.09:
Some news concerning timers (see the CHM-file).
C++ example code. An object oriented ASCIIZZ-class. An object oriented base ListViewer and some derived classes (f. i. MCS and memory-Viewer).
How to use the status area (controlling Text, Icons and Glyphs). Example code in INSIGHT.
Hint: the Bfile_FindFirst- and Bfile_FindNext-syscallnumbers previously published are not the perfect ones. Use 0x1DB7 instead of 0x1DB6 and 0x1DB9 instead of 0x1DB8.
cfxm asked me to add an option to INSIGHT to invoke the testmode (found by cfxm). See:
https://ourl.ca/9404/220269
-
THis is nice. Glad to see new updates :)
By the way sorry if I do not reply much here anymore. I unfortunately have quit calculator related stuff as a whole now, and hardly check on new stuff anymore (usually it's just for front page news)
-
Isn't the static RAM address supposed to be the bottom of the g3a stack. Or has that now changed to a new location?
-
This only affects so called RAM files which are not stored on the flash chip.
According to Simon, 0x88160000 was the bottom of the add-in stack - this has now changed to 0xE5200000 (purpose unknown).
-
When did this change? Was it when the update to 1.02.0200 happened?
EDIT: Or was this change something that was caused by the mini-SDK? I'm not sure if I understand what's going on...
-
No no, it's all about Simon's mini-SDK. There are a few dependencies I have to check with each release.
-
...0x88160000 ... has now changed to 0xE5200000 (purpose unknown).
The mini-SDK builds two different binaries. The first one is the standard G3A (f. i. INSIGHT.G3A),
which can be copied to the calc's storage memory using USB. The static RAM of a standard G3A is a part of the external RAM virtualized to address 0x08100000 by the system, when invoking a G3A.
The second binary is a special one (f. i. INSIGHT_RAM.SH3), which can be run from RAM. I load it via 3pin, using the protocol 7.00 "Upload'n'Run"-option. This accelerates development cycles.
But this requires to find fitting RAM-gaps, which are not used by the system (at least not during program testing).
For the RAM.SH3 program I use 0x880E3000 (the end of the main memory).
As static RAM for the RAM.SH3 I used some unused part of the external RAM at first.
Then, just out of curiosity, I tried 0xE5200000, which is a 4k IL-memory of the 7305.
I like to check out available options. Probing into the unknown is one of the ways to gain knowledge.
But beware: messing around with the 7305's IL-memories can cause funny calculator behaviour.
-
According to Simon, 0x88160000 was the bottom of the add-in stack...
I haven't been sufficiently exact with the naming. The 512 kB RAM area 0x88160000 to 0x881DFFFF should be called "add-in RAM" (I updated the documentation), because it is shared by add-in static RAM and add-in stack. The add-in static RAM starts at 0x88160000 (virtualized to 0x08100000). The add-in stack starts at 0x881E0000 and grows downwards (towards the static RAM).
When an add-in is loaded, the complete add-in RAM is virtualized in 8x64kB-chunks (0x88160000->0x08100000..0x881D0000->0x08170000), possibly allowing much more static RAM as with the legacy systems. Of course, you have to take care for the limits. Otherwise the system will do, crashing.
-
Here are more unconfirmed calls.
The sprintf routine is not a syscall, so its OS dependent.
I will try this myself in a couple weeks, it looks too useful even if its not sprintf.(vsprintf ?)
MMU_FlushCache? 0011
Disp_Manage? 0276
Disp_Save? 0278
Disp_GetPtr? 027A
Num_UintToBCD 0577
Num_BCDToUint 0578
strlen? 060D
strcpy? 060E
strcat? 060F
is_comma 07BD
Bkey_GetkeyTableInfoJumpFunc 0EAE
Expressions_OpcodeToStr? 1291
LocalizeStringID 12FD or 12FC
MCS_DirtypeToItemtype? 1549
MCS_ItemtypeToDirtype? 154A
MCS_OpenAlphaMemItem?? 1553
NextOPcodePRGM 1749
MCS_Flush 1845
Send38k 198A
Receive38k 198B
OpenCloseComPort38k 198C
Battery_IsLow? 1e72
GetIntPtrContent? 1E7D
GetdatatablePtr? 1E80
SetAppName? 1E9E
sprintf??? -- non-syscall --> (OS1.01:0x80309604, OS1.02:0x803093A0), use function pointer
-
How would I go about compiling for the Prizm on a Mac?
(Also, IDK if this was posted before, but can you please remove that annoying loading animation from Insight? I doubt anything is actually being loaded.)
-
Well, you'd have to use GCC and the -m3 flag to compile C programs for the Prizm with a Mac.
-
Well, you'd have to use GCC and the -m3 flag to compile C programs for the Prizm with a Mac.
Is there any tutorial available? I don't know much about GCC or compiling on the command line; I can compile a simple C program using GCC but that's about it.
-
Well, you'd have to use GCC and the -m3 flag to compile C programs for the Prizm with a Mac.
Is there any tutorial available? I don't know much about GCC or compiling on the command line; I can compile a simple C program using GCC but that's about it.
I think the binaries of the GCC-based SDK only are compiled for Windows... I'm not sure how to make it work on a Mac. You could try asking on Cemetech - some of the ones who made GCC work with the Prizm usually visit that site more than Omnimaga.
-
Mac OS is *nix, so the native linux GCC should work without much effort (no need for a port). The only question is whether the GCC he presumably already has allows the -m3 flag.
EDIT: The GCC binaries from here (http://www.superh-linux.org/platforms/index.html) support SuperH, so they might work.
-
...can you please remove that annoying loading animation from Insight? I doubt anything is actually being loaded.)
cfxm asked me once how to draw outside of the regular display bounds. This animation is only a demo, how to achieve this (as most of INSIGHT is how-to-do source). I can implement it as separate menu item. Until the next release of INSIGHT you can cancel the loading animation with EXIT.
-
...can you please remove that annoying loading animation from Insight? I doubt anything is actually being loaded.)
cfxm asked me once how to draw outside of the regular display bounds. This animation is only a demo, how to achieve this (as most of INSIGHT is how-to-do source). I can implement it as separate menu item. Until the next release of INSIGHT you can cancel the loading animation with EXIT.
Thanks; I don't know why I didn't try that.
BTW, you should add editing capabilities to the memory viewer. Maybe also add a feature to hex-edit files/variables without using a computer.
Also, somebody mentioned using the -m3 flag in gcc, but not only doesn't the man page mention that flag, but if I google "gcc m3" (no dash in the search, as that would be interpreted as without m3) all I find is stuff about using GCC to compile for some processor called the Cortex M3.
-
I attached a little note-viewer.
With the next release of the mini-SDK, its source will be included.
The file-selection dialog shows files with the extension *.txt and subdirectories, only.
The noteviewer is designed to support CRLF, CR and LF as line delimiters.
A search function is under construction.
Version 1.00 removed
Version 1.02 can be found here
http://www.casio-scene.com/downloads.php?do=file&id=103
-
Here are more unconfirmed calls.
The sprintf routine is not a syscall, so its OS dependent.
I will try this myself in a couple weeks, it looks too useful even if its not sprintf.(vsprintf ?)
MMU_FlushCache? 0011
Disp_Manage? 0276
Disp_Save? 0278
Disp_GetPtr? 027A
Num_UintToBCD 0577
Num_BCDToUint 0578
strlen? 060D
strcpy? 060E
strcat? 060F
is_comma 07BD
Bkey_GetkeyTableInfoJumpFunc 0EAE
Expressions_OpcodeToStr? 1291
LocalizeStringID 12FD or 12FC
MCS_DirtypeToItemtype? 1549
MCS_ItemtypeToDirtype? 154A
MCS_OpenAlphaMemItem?? 1553
NextOPcodePRGM 1749
MCS_Flush 1845
Send38k 198A
Receive38k 198B
OpenCloseComPort38k 198C
Battery_IsLow? 1e72
GetIntPtrContent? 1E7D
GetdatatablePtr? 1E80
SetAppName? 1E9E
sprintf??? -- non-syscall --> (OS1.01:0x80309604, OS1.02:0x803093A0), use function pointer
I could verify most of your assumptions.
Exceptions:
Disp_Manage? 0276 (Bdisp_Fill_DD(color,mode), directly draws one of three predefined color-filled rectangles)
Disp_Save? 0278 (Bdisp_Fill_DD_1(color) calls Bdisp_Fill_DD(color,1))
Disp_GetPtr? 027A (Bdisp_Fill_VRAM_2(color) calls Bdisp_Fill_VRAM(color,2))
Bkey_GetkeyTableInfoJumpFunc 0EAE (verified, returns the pointer to some keycode table)
MCS_Flush 1845 (checks the six MCS backup areas in the flash for some yet unknown purpose)
Send38k 198A (verified, serves both commands Send and Send38k)
Receive38k 198B (verified, serves both commands Receive and Receive38k)
GetdatatablePtr? 1E80 (returns the number of installed languages)
-
Nice Simonlothar. Sometimes people come to ask for noteviewers and stuff like that, so hopefully if we gain Casio users who needs such program we will try to link them here.
-
I know this is a bit of a necro bump but I did release the "cemetech"(as Kerm so happily dubbed it) GCC PrizmSDK-0.2 a while back and would love to help anyone get it setup if needed.
As for using it on Mac OS X you would need to install xcode and then compile and install a gcc targetting the superh series processors. If you want I can help walk you through the process any time, just hop on irc, or use the chat box, and highlight me. You would just need some parts of my sdk and I have all those individual files available for download.
As to keeping this on par with Simons work I would really love to work with him on standardizing things a bit. I'm fine with the automated syscall generating and have written a script to duplicate its work for use with my SDK but the biggest issues I have are with the header and helper functions organization. As it stands right now you can't easily use the headers from one SDK with another or even reliably compile code written with one on another.
I'd like to fix that so that it is easier for the end users of either SDK to adapt them to their needs.
My first issue is the lack of clarity on whether or not C++ is really supported and why some headers and source files use hpp/cpp instead of h/c. IMO we should keep the SDK's and their API's pure C and leave it up to the users as to whether they want to use C or C++. Many of your headers are already encased in Extern "C" {} so why even bother having them use the .hpp extension?
My second issue also relates to the headers and it is the fact that you mix equates and structs used by syscalls with custom functions you have added. This increase the amount of work for me greatly and adds to user confusion because they can't tell what is a syscall and what is something you added to the SDK yourself.
My last issue is that darn chm file. :P Yes its nice that there is some documentation but damn is it a pain in the arse to find any of it in there. Omnimaga was kind enough to host the prizmwiki at http://prizmwiki.omnimaga.org (http://prizmwiki.omnimaga.org) we should use it. I have been trying to update it with some of the things I have found but its just not all that useful as it currently stands. I think the first step would be to start getting the syscalls on there. The documentation for them is scattered about this forum, your .chm file and our heads. Getting on in a centralized location would help everyone move forward and allow one to much easier find the information they need.
-
That would really be great if we could get the wiki updated. I believe Jos Juice currently is the wiki admin and controls all of the major changes. In fact what I had in mind for the syscalls page was an organization system similar to wikiti.brandonw.net so that full documentation could be provided for each call. Right now the only syscall documentation is just copied from the .chm and is geared more towards asm coders and provides little insight to those who code in C. What we'll need in the discussion is an explanation of what each call does exactly, what all the args do, the use of the return value, ram locations destroyed, and how to effectively use it in a program.
But then again we aren't as reliant on syscalls for the Prizm as we were on the 83+. So far the only reason why I use a syscall is to draw the screen or depending on the program draw text. But they will become more important in the future as we start experimenting with some of the hardware such as the usb.
-
Making separate wiki articles for the syscalls will make it much easier to find information. I'll create the category, links to it and such right now, but I'll need some help with adding information about the syscalls since there are so many of them.
EDIT: I've added a few syscalls, and they can be accessed by hexadecimal number from [prizm]Category:Prizm syscalls[/prizm]. Maybe there should also be categories that are based on what syscalls are used for (displaying things, file management, etc.) or lists with names of syscalls?
-
I don't think the syscalls should be organized by number as it has little relevance to its actual use. A good way to have them organized could be by the library file each is stored in such as "display.h". But for the time being I'll see how well I can get the current list filled with important information.
-
I was planning to do it like on WikiTI (http://wikiti.brandonw.net/index.php?title=Category:83Plus:BCALLs:By_Name), in which the article names use numbers and the lists use names. I haven't figured out how to use names within the automatically generated lists, though.
-
I agree that the numbers are generally useless, but I disagree with using the header file name as the organizational method, a simple category based method would be just fine. The issue with going by the header file name is that is one of the issues I have with simonlothar's SDK is the naming and setup of the headers. The stdlib related headers could be organizer as such but even there simon didn't follow the C standard and I really think that should be fixed.
Since we don't have official naming conventions from Casio I would see if we can standardize them, unless the naming we have been using is based off of the older Casio calcs. If that is the case then fine but it still irks me.
-
We also need to modify the header files from both SDK's to have proper #ifndef blah_h, #define blah_h, #endif statements so that other libraries don't end up being accidently included twice once more third party libraries become available.
-
The stdlib related headers could be organized as such but even there simon didn't follow the C standard and I really think that should be fixed.
Agreed. If there are C99/C1x functions in the OS, but these functions are not defined in the appropriate headers, it makes it harder to port programs to the new platform :)
In GCC4TI, I had to improve several things in the library and in the toolchain for the quite portable p14p and Lua code bases to be easier to compile. No official (I have posted the patches) release of p14p for TI-68k and the modified Lua89 can occur until the next official release of GCC4TI, otherwise Windows users wouldn't be able to compile them. *nix users can build from GCC4TI Git.
-
What I think would be really cool is if we could somehow make it so the syscall and general routine library could be portable between the compilers. For syscalls the asm.h header just needs to use the proper macro for the platform, along with the asm source files but the C sources should easily be portable between them with a little clean up.
I already have libfxcg hosted on github so that is a start but many of simon's helper routines don't even compile with gcc due to header file case errors, syntax differences and a few other issues.
-
Hello!
I want to begin coding for Prizm, but i don't understand any micro/mini/nano/shufle sdk...
COud you help me, please?
-
I have the same problem... I don't know how can I build some g3a.
-
Hello!
I want to begin coding for Prizm, but i don't understand any micro/mini/nano/shufle sdk...
COud you help me, please?
I have the same problem... I don't know how can I build some g3a.
I find that the easiest way to get started is to the gcc SDK hosted on cemetech at http://cemetech.net/forum/viewtopic.php?t=6613&start=0
start with the default project and compile it by running make.bat
To start your own project use the included makefile as a template and modify the sections that read default to that of your own project. Or for the time being while you learn, just modify the code of default and see what you can do. If you have any questions I recommend that you start a help topic here for your projects.
-
I made a french tutorial to use mini-SDK, inspired by the Cemetech's...
-
Nice. Is it available for download somewhere?
-
http://www.planet-casio.com/Fr/forums/topic10062-1-[C]-Du-C-sur-la-Prizm-Du-monochrome-a-la-couleur.html
Enjoy!
-
Link doesn't work :'(
-
http://www.planet-casio.com/Fr/forums/topic10062-1-%5BC%5D-Du-C-sur-la-Prizm-Du-monochrome-a-la-couleur.html (http://www.planet-casio.com/Fr/forums/topic10062-1-%5BC%5D-Du-C-sur-la-Prizm-Du-monochrome-a-la-couleur.html) ;)
-
Ok thanks :D
Unfortunately I never got much into C as I never understood anything when I tried to learn 68K C from TechnoPlaza but hopefully it helps French people more.
-
Helder7 asked me to update NOTEVIEW.G3A
Helder7 provided new, far nicer icons (thx) and asked for support of country-specific-characters.
As for the country-specific-characters, I added a little converting tool (HexDump.exe), which can be used to individually adapt textfiles to country-specific needs before transferring them to the fx-CG.
Version 1.01 removed (it had a bug)
Version 1.02 can be found here
http://www.casio-scene.com/downloads.php?do=file&id=103(broken)
Edit:
Link broken; see
http://ourl.ca/9205/311915
-
Tanks for this update SimonLothar! It will be very useful
-
http://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=11141 (http://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=11141)
More easy!
-
Helder7 asked me to update NOTEVIEW.G3A
Helder7 provided new, far nicer icons (thx) and asked for support of country-specific-characters.
As for the country-specific-characters, I added a little converting tool (HexDump.exe), which can be used to individually adapt textfiles to country-specific needs before transferring them to the fx-CG.
Version 1.01 removed (it had a bug)
Version 1.02 can be found here
http://www.casio-scene.com/downloads.php?do=file&id=103 (broken)
Due to the broken link in the post above I added version 1.03 here. It includes the fx-9860-version (NOTEVIEW.G1A), too.
-
Cool to hear guys. Should hopefully be useful to our new Casio guys along with the others. :D
-
I have attached a small script using the optlnk.exe program that allows you to extract all modules from a Casio SDK library.
For the SDK startup/linker object files, only the symbol and section names are listed.