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

I just downloaded BasicExtension_001.zip and had a look a the source.

It installs a timer-handler and starts the built-in Basic-Interpreter (APP_PRGM). While the BASIC interpreter waits for input, the timer-handler injects keycodes (via PutKey) based on a fixed text, hardcoded in the G3A. The built-in BASIC interpreter receives the keycodes and acts accordingly. But alas, I cannot see, how it should be possible to change the behaviour of the BASIC interpreter this way.
Some years ago, I wrote LOADER for the fx-9860, which followed this scheme to load BASIC-programs from storage memory:
http://www.casiokingdom.org/modules.php?name=Downloads&d_op=viewdownloaddetails&lid=542&title=FX9860G%20LOADER%202.00
If I am not totally mistaken, the upload contains some source and knowhow. But I do not know, if casiokingdom's download area is still operable at all.

If you want to change/extend the BASIC-interpreter, you either have to write a completely new interpreter as G3A (sagarvaze did this some years ago at casiokingdoms) or you have to mod the OS.

@bsl: are you one of the SDK-chums, which have been around at casiokingdoms some years ago? The old syscall-wrapper: long time no see!

I just sent this email to Renesas based off some new found evidence

Quote

Hello I have an inquiry about a device that uses a Super H processor. This device is the Casio fx-cg10 graphing calculator which is believed to use a modified SH3. Based off a reading from the rom chip the identifier "RENESAS SH7305" and "RENESAS SH7355" are found. Now Renesas does not appear to be selling either a 7305 or 7355 brand Super H so I have reason to believe that this is a custom order. If it is at all possible would a full hardware documentation be available for this version of the Super H or at least could I know which processor it is most closely related to?

Thank you for your time,
[my name was here]

I found this identifier at the end of file produced from the spreadsheet app. In my case SHEET.g3m. There appears to be more written at this location too if anyone can decipher it.

Usually the documentation of the customized processors (7305, 7355 and 7337) is under nondisclosure agreement.
A lot of the 7305-registers are those of the 7730.

Perhaps this is interesting, too:
http://ourl.ca/9887/189504
http://ourl.ca/9887/189510

Does somebody know how to enable true color mode programatically?

Try syscall 0x0921 with argument 1.

The differences between a fxCG10 and a fxCG20 (first 7 MB) are (apart from the calc-ID and the checksum)

fx-CG10: 0x303[1] : 0x41
fx-CG10: 0x305[1] : 0x5A

fx-CG20: 0x303[1] : 0x44
fx-CG20: 0x305[1] : 0xAA

Or have a look at "fx_calculators_SuperH_based.chm".

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.

Well, at least Insight can be compiled with -cpu=sh4 and -fpu=single
But I did not notice any difference.

Smart idea.
There will be differences, if you declare float-variables. The compiler uses fpu-commands, indeed. But, alas, the Prizm crashs with "Illegal Code Err", t. i. no fpu-support in the processor.