I have to apply a correction to the last version of fx_calculators_SuperH_based.chm
(http://ourl.ca/8207/238670):

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.

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)

Quote from: DJ_O on February 25, 2012, 10:34:28 pm

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)

Quote from: MPoupe on April 09, 2012, 06:49:26 am

Quote from: DJ_O on February 25, 2012, 10:34:28 pm

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.)

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?

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.

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?

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.