This is no bug: http://ourl.ca/9028/177703
Please be a bit more careful before declaring everything as a bug or glitch.

I don't think m1ca4 even declared a bug. He was referring to an issue we have been having with OS versions. As far as we know, there are actually two versions of  OS 01.02.0200.  Make sure you fully read over posts first.

If you'll notice, there's also NOR ROM flashing. That's a part of test mode, so I suspect that the SD card can be accessed in diagnostics mode. There are a few other things in the OS I'll let you find  

However, the OS update is not a part of the SD card support. That section deals with the text that is displayed under certain circumstances. Nearby phrases don't necessarily have much relation.

Quote from: Casio

Thank you so much sending e-mail for your precious opinion and suggestion.

We have already transferred your message to our R&D section and asked them to consider seriously in this regard.
However, we regret to say that we have no schedule and no plan to release SDK for Prizm as we said previous reply as of now.

Regarding slow speed of the BASIC language and glitches in the OS, it seems there are some differences of recognition each other.
Therefore, we would highly appreciate it if you kindly point it out concretely with some examples and the we would like to look into it based your information.

Sincerely yours,

Well well. It looks like Casio really does care.   They will even let us talk to the dev team. I'm hoping with further email between us and Casio the bugs can get ironed out and maybe even some future dev tools could be added later.

Actually on my side I got a response saying they spotted the glitches and will tell the japan dev team to fix them, but they have no schedule on when the new OS will come out.

This is no bug: http://ourl.ca/9028/177703
Please be a bit more careful before declaring everything as a bug or glitch.

Try to not be rude to other people when calling them out, though. Everyone can do mistakes.

There are a few other things in the OS I'll let you find  

pr0n?

Maybe...

>_>

Man, I knew CASIO was better than TI, but this is awesome! j/k

Ok, so it look like the 7720/7721 architecture...

A very important and valuable hint, THX. Perhaps they changed to the 7720, because it contains a LCD-controller...

BTW a correction: of course, the RTC base-address is h'A413FEC0. I missed a little add #-h'1C....

Someone PMed and asked me to provide for a syscall tutorial.
I don't know, how detailed it has to be. So, the short form for a start.

F. i. GetKey, the blocking keyboard read function:

interface: int GetKey( int*keycode );
For details of GetKey refer to fx-9860G Libraries.pdf, which is included in the fx-9860G SDK.

On the fx-CG the underlying syscall is 0x0EAB.
Implementation as inline code for the use in assembler:
   add    #-4, r15    ; create local workspace
    mov.l #h'0EAB, r0    ; 0x0EAB waits, until a key is pressed (blocking)
    mov.l #h'80020070, r2
    jsr @r2
    mov    r15, r4    ; pass the parameter *keycode
    mov    @r15, r4     ; copy keycode* to r4 for further processing
    add    #4, r15    ; free local workspace
Implementation as assembler-function for the use in C/C++:
   .export _GetKey
_GetKey:
    mov.l #h'0EAB, r0
    mov.l #h'80020070, r2
    jmp @r2    ; mind the difference between jsr (see above) and jmp!
    nop          ; edited
Mind to precede the function name with an underscore. When calling from out of C/C++ the underscore must be omitted.
If you use a syscall inside of an assembler program, you have to setup the parameter-frame yourself.
The C/C++-compilers provide for that automatically.
The parameter passing in SuperH systems is documented in f. i. SHC Manual.PDF, which is included in the fx-9860G SDK.
If you want to build a syscall library, the following MACRO could be of help:
.MACRO BIOS_JUMP FUNO, SYSCALLNAME, TAIL=nop
    .export \SYSCALLNAME'
\SYSCALLNAME'
    mov.l #h'\FUNO, r0
    mov.l #H'80020070, r2
    jmp @r2
    \TAIL'
.ENDM

; so your minimum syscall library source needs one line per syscall only
BIOS_JUMP 0EAB, _GetKey
BIOS_JUMP 18F9, _PrintXY
BIOS_JUMP 0272, _Bdisp_AllCr_VRAM
BIOS_JUMP 025F, _Bdisp_PutDisp_DD
BIOS_JUMP 1348, _WordToHex
the interfaces:
void PrintXY( int x, int y, char*string, int mode, int color );
    x and y in text-cursor coordinates;
    the first two chars of *string are ignored (the reason of which will be unravelled later, hopefully)
    mode (bit-field) = 1: writes the string in reverse
    mode (bit-field) = 0x20: does not overwrite the background
    color=0: black; color=1: blue; color=2: green; color=3: cyan; color=4: red; color=5: magenta; color=6: yellow; color=7: none
void Bdisp_AllCr_VRAM( void );
void Bdisp_PutDisp_DD( void );
void WordToHex( unsigned short value, unsigned char*buffer );
    value: value to convert into a displayable 4-char hex-string
    buffer: buffer to receive the string (size 5)
The use of PrintXY inside of an assembler source is a bit complicated:
   mov.w #h'00, r5
    mov.l r5, @-r15 ; the 5th parameter has to be passed on the stack
    mov #4, r5 ; y
    mov.l #XTEST, r6    ; this would be the pointer to a string
    mov #5, r4 ; x
    mov.l #h'18F9, r0
    mov.l #h'80020070, r2
    jsr @r2
    mov #h'00, r7 ; deletes the background
    add #4, r15    ; readjust the stack due to the 5th parameter


; example source: this code has been assembled, linked and successfully run on a fxCG 20!

   .MACRO BIOS_JSR FUNO, TAIL=nop
    mov.w #h'\FUNO', r0
    mov.l #h'80020070, r2
    jsr @r2
    \TAIL'
    .ENDM

LOCAL_WORKSPACE .EQU h'1000

program_entry:
; start of a minimum syscall tutorial example
    mov.l r14, @-r15 ; the amount of registers to push onto the stack depends on the requirements of the function
; always be sure to push any of R8..R14, which the function uses.
    mov.l r13, @-r15
    mov.l r12, @-r15
    sts.l pr, @-r15
; pr should be pushed in every subroutine, even, if it does not bsr or jsr.
; the day will come, when you implement some bsr and jsr inside of the function and you forget to push pr
    mov.l #-LOCAL_WORKSPACE, r3
    add r3, r15

; at first clear the VRAM
    BIOS_JSR 0272
; transfer the VRAM to the display driver (though it is not necessary in this case, 0EAB provides for that, too)
    BIOS_JSR 025F

main_loop:
; now wait for key-input (blocking)
    add #-4, r15 ; create a local workspace
    mov r15, r4 ; setup the function's parameter: pointer to keycode
    BIOS_JSR 0EAB
    mov @r15, r13 ; save the keycode for later use
    add #4, r15 ; free the local workspace

; now you have to decide, what do do
; first we need a bit of workspace
    add #-h'10, r15
    mov r15, r12 ; save the pointer to that workspace for a rainy day
; initialize the workspace (don't care, skip it while reading)
    mov r12, r5
    mov.l #h'01010101, r0
    mov.l r0, @r5
    add #4, r5
    mov #0, r0
    mov.l r0, @r5
    add #4, r5
    mov.l r0, @r5
    add #4, r5
    mov.l r0, @r5
; now let's convert keycode to something displayable
    mov r12, r5
    add #2, r5 ; we have to skip two bytes because of a special feature of syscall 18F9
    mov r13, r4 ; fetch the previously saved keycode
    BIOS_JSR 1348 ; syscall WordToHex

; let's display the keycode
    mov.w #h'01, r5
    mov.l r5, @-r15 ; color
    mov #1, r5 ; y
    mov.l r12, r6
    mov #h'00, r7 ; deletes the background
    mov #1, r4 ; x
    BIOS_JSR 18F9
    add #4, r15 ; adjust the stack for the 5th parameter

    add #h'10, r15 ; free the workspace

    bra main_loop
    nop

; though this program won't ever quit, the proper finalization code is appended anyhow, as reference.
; BTW: h'0EAB is aware of the MENU-key, so it is not necessary to quit the program with the RESTART button
    mov.l #LOCAL_WORKSPACE, r3
    add r3, r15
    lds.l @r15+, pr
    mov.l @r15+, r12
    mov.l @r15+, r13
    rts
    mov.l @r15+, r14
; end of a minimum syscall tutorial example



Btw I didn't read the topic in a while, but are add-ins made by the community still always appearing at the same place all the time in the menu? I think I remember something about add-ins being overwritten by third-party ones. Also I think when I installed the add-in for memory viewing it erased the one by Kristaba (I think) where the screen showed the FPS and faded in/out from black to red.

Hmm... I don't know a lot about it, but I think that would likely happen when the programmer doesn't replace 0x0EBC in the header.