Casio Prizm documentation

[SimonLothar]

I have to apply a correction to the last version of fx_calculators_SuperH_based.chm
(http://www.omnimaga.org/index.php?topic=5610.msg184546#msg184546):

syscall 0x1DA6: int Bfile_GetFileSize_OS( int HANDLE );
Returns the filesize.
syscall 0x1DA9: int Bfile_SeekFile_OS( int HANDLE, int pos );
Moves the current filepos to pos.
syscall 0x1DAB: int Bfile_Filepos( int HANDLE );
Returns the current filepos.

[DJ Omnimaga]

Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd.

The syscall that checks which keys are pressed will make SHIFT have the function it normally has in the OS, along with other keys like ALPHA and MENU. Allowing the user to use MENU to go to the main menu is desirable in some cases, and since there are no other known ways to return to the main menu, this syscall has to be used. There are other routines that can be used if the program wants to be able to detect every key. Other cases of not using SHIFT are probably just due to the programmer's preference.

Ok thanks for the info. Actually I noticed that the Zelda demo on Planète-Casio used EXIT to go back to menu and now Ashbad's MLP game uses SHIFT fine, unlike his contest demo that used F1. (I think the Cemetech entry used F1 too)

[MPoupe]

Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd.

2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)

[SimonLothar]

As for the Prizm's MPU again:
the SH 7724 is the closest match to the SH 7305 which has been found up to now (reported by brijohn (http://cemetech.net/forum/viewtopic.php?t=5507&start=156)).

[DJ Omnimaga]

Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd.

2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)

I see. I guess it's because I'm just so used to using 2nd as confirm key and ALPHA or Clear as cancel. On the TI-83+ series, 2nd=confirm and ALPHA=cancel is pretty much the standard in gaming since the last decade or so, although some games still use ENTER (the equivalent of EXE), some use the number pad and others the F1 to F5 keys (annoying)

[SimonLothar]

Because of the broken link in
http://www.omnimaga.org/index.php?topic=5610.msg184546#msg184546
I have to apply a correction:

"fx_calculators_SuperH_based.chm" version 12

New version 13
http://www.omnimaga.org/index.php?topic=5610.msg262856#msg262856

[AHelper]

Question, in PRIZM ASM and C, is there something special preventing people to use or convincing them to not use the 2nd key (like with ON on the TI-84+)? I am asking this because I noticed that most PRIZM games use F1 as confirm key instead of the standard 2nd/Enter and it tends to be rather annoying when you are used a lot to pressing 2nd.

2nd/Enter is much more inconvenient than F1 or exe (because of 2 key presses :-) ) and also Casio uses F1 as confirm key very common (at least since fx7700GB)

I see. I guess it's because I'm just so used to using 2nd as confirm key and ALPHA or Clear as cancel. On the TI-83+ series, 2nd=confirm and ALPHA=cancel is pretty much the standard in gaming since the last decade or so, although some games still use ENTER (the equivalent of EXE), some use the number pad and others the F1 to F5 keys (annoying)

I can understand that.  I, sadly, don't have the same experience running many games on my ti84pse since I mainly use it for GlassOS ;-) .  Do not forget the the Casio calculator line isn't the same as the TI line.  Key conventions are different.  I already made a topic on cemetech (which is also on wikiprizm) about the key conventions that Casio uses.  The key usage is what Casio set the standard at in their OS.  I am not saying that one key usage should be used and not the other, as I am not trying to debate.  I am simply stating that the two companies have different visions for how their calcs are to be used and the key usage in addins are from observations of how Casio did it.

@MPoupe, I believe DJ_O was referring to 2nd/Enter as either 2nd or Enter, not 2nd+Enter.

@SimonLothar, tytyty.  I haven't looked at this for a while and was very happy to see many things that the PrizmSDK has have documentation (especially PrintMini, PrintMiniMini (not in the SDK), Bfile_TellPos, and Scrollbar). Keep up the great work!  (Also, I documented a parameter for DisplayMBString that the chm doesn't have.)

[DJ Omnimaga]

Yeah I meant 2nd and Enter separately.

[AHelper]

I was reading through the LCD documentation and am confused.  How do I read and write directly to the LCD hardware?  I can see the syscall to select the register, but don't know what address to use for read/writing.

<edit>

I now realize that the 0xB4000000 is where you read and write to.  Maybe explain that in the chm so others don't get confused?

[AHelper]

(bump'd)

I am having an issue.  What causes the System ERROR exceptions to be triggered?  I need to find a way to prevent these as I am reading addresses.  I notice that Insight doesn't have this issue as it can read the address just fine, but I want to know how it does it.  I didn't find anything obvious in the source for insight. Any help?

<edit>

Fixed it.  Found out what ADDRESS(x) exceptions mean.  I also found out how to override exceptions.

[SimonLothar]

Sorry, that I did not answer earlier. (Some reasons: holiday, fair weather a. s. o..)

It seems to be not too simple to write to the Prizm's LCD-driver-interface 0xB4000000.

First the LCD-driver-register has to be selected.

If the OS issues a LCD-driver-register-select (syscall 0x01a2), it first clears bit 4 of MPU-port 0xA405013C (it looks as if this bit controls the LCD-driver's RS-bit; refer to the R61509-manual).
Then the SH-4A instruction SYNCO is performed.
Then the register number is written to 0xB4000000
Then the SH-4A instruction SYNCO is performed.
Then bit 4 of port 0xA405013C is set again.
Then the SH-4A instruction SYNCO is performed.

After a LCD-driver-register has been selected, it can be written to (by writing to 0xB4000000 again)

Every time register 0xB4000000 as well as port 0xA405013C are written to, the SH-4A-specific instruction SYNCO is performed immediately.

It is doubtful that directly writing to the LCD-driver enhances display-performance.
I observed, that writing to VRAM and moving the RAM to the LCD by DMA (syscall 0x025F/syscall 0x0260) is significantly faster than direct LCD-driver access.

[Eiyeron]

could be the last solution faster than the syscall? Could we get some more fps?

[AHelper]

Simon,, here's a question for you that I don't understand.  Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)?  That makes me think that the delay is not in the actual copying of data.  Any thoughts?

[SimonLothar]

Simon,, here's a question for you that I don't understand.  Why is it that there is no noticeable GPS change when you use Bdisp_PutDisp_DD vs Bdisp_PutStrip_DD(1,2)?  That makes me think that the delay is not in the actual copying of data.  Any thoughts?

I measured the following times when using syscall 0x0260

args   time in microseconds
0,0   179
0,43   5734
0,86   11281
0,129   16835
0,172   22390
0,215   28593

syscall 0x025F() is identical to syscall 0x0260(0,215).

t. i. calling 0x025F() consumes about 100 times more time compared to calling 0x0260(1,2).

Most of the time syscall 0x0260 waits for the DMA-hardware, t. i. the speed-controlling part is the DMA-hardware.

[calc84maniac]

But is it possible to have the DMA run while the program continues? The program may have to use double-buffering in that case, but it sounds possible.