Transfer files programatically

[gbl08ma Profile Website]

TeamFX, I don't understand: first you say it uses USB, but then you say FA-124 does not support the Prizm over USB? Or do you mean that despite a serial link being established over USB, FA-124 does not know how to use it and thus the 3-pin interface must be used if we want to use that software?

If that's what you meant, then it should be irrelevant as long as we can use custom software to talk to the Prizm over USB. FA-124 has no use on the Prizm case...

[TeamFX Profile]

The Prizm utilizes the CESG502(*) driver and does not tell the PC it is a USB mass storage device. Yet, FA-124 does not know how to treat this unknown type. But when communicating via 3pin, the Prizm tells any other calculator (or FA-124) that it is an fx-9860GII device.

By the way, the PV-S1600 has the hardware identifier GY502. The USB driver was then used for the ClassPad 300 and eventually for the fx-9860G.

[gbl08ma Profile Website]

I suppose the Prizm has additional USB client drivers for the Screen Receiver and Projector modes. I will take a look at your add-in when I get home, it sounds interesting.

As for other hardware having the same ID, well, we all know Casio likes reusing code between calculator models and even with other things that aren't calculators. For some reason the new fx9860GII calcs have a SH4 processor, it's so that it is easier to code for them (they do not need to have separate code trees and compiler for each CPU).

[TeamFX Profile]

And it is way cheaper to have Renesas produce fewer customized MPU designs.

With the arrival of the SH7305, they canceled the old ClassPad SH7291 and the GII SH7355 (an upgraded version of the SH7337 used on G1 models).

They also saved a lot by using a customized Renesas LCD controller on newer color displays and there have been rumors that starting with the GII, they also use static RAMs made by Renesas.

[gbl08ma Profile Website]

"The member fname1 must be set to the filename, which should be used on the remote calculator"

If I want the file to go to a specific directory in the remote calc, should I specify a full file name with fls0 and everything? Like this:
strcpy( x.fname1, "\\\\fls0\\TestDir\\InFile.txt" );

...or can one only specify the last part of the file name (not the whole dir)?

And what does syscall SetGetKeyPhaseFlag do (it is in your example code)? Is it necessary?

[SimonLothar]

"The member fname1 must be set to the filename, which should be used on the remote calculator"

If I want the file to go to a specific directory in the remote calc, should I specify a full file name with fls0 and everything? Like this:
strcpy( x.fname1, "\\\\fls0\\TestDir\\InFile.txt" );

...or can one only specify the last part of the file name (not the whole dir)?

I have not yet tested the thing with target subdirectories. I will do and report as soon as possible.

And what does syscall SetGetKeyPhaseFlag do (it is in your example code)? Is it necessary?

To be honest, I do not know the whole extent of the effects of this call. The OS calls it before it enters the transmit routine.

[gbl08ma Profile Website]

To be honest, I do not know the whole extent of the effects of this call. The OS calls it before it enters the transmit routine.

Are you sure the OS doesn't call it with any parameter, or heed for its return value?
Did you check if it calls it only just at the start of the file transfer, or does it call it at the end too?
I'm asking because I suspect it may have something to do with allowing Menu return... it may be the SetGetKeyToMainFunctionReturnFlag (or whatever it is called) we were looking for (you could only find the Get* implementation and had to code Set* yourself with a clever trick for getting the address of the flag).
Also, it may have something to do with manipulating g3a files without system errors (the bugs with the Add-In manager of my Utilities add-in prove that the OS doesn't like messing with g3a files under normal circumstances). I presume this is because the add-in array gets invalid/outdated in virtue of different file name/contents.

[SimonLothar]

Are you sure the OS doesn't call it with any parameter, or heed for its return value?

You are right. As far as I remember, SetGetKeyPhaseFlag needs two arguments. I missed to document the interface of SetGetKeyPhaseFlag properly in my doc version 18. I once spent a lot of time with SetGetKeyPhaseFlag, not finding significant information. But perhaps it is time to pick up the topic again. I'll have a look.

[gbl08ma Profile Website]

Based on our current knowledge, I would say that inside GetKey resides the task-switching core of the OS:
- it's GetKey that's responsible for switching between the guest (add-in) and main process (main menu)
- it's GetKey that is responsible for handling poweroff and startup (even though we can call PowerOff directly) and on the emulator it also waits for a special key for restarting (even if we can call reboot directly)
- it's GetKey that, on eActivity, switches between the eActivity and the add-in running as a "strip" (press Shift then the store -> key), including an intricate MCS emulation system (on the add-in running as a strip, the MCS appears as having only the free size of the eActivity file, around 28 KB when it is empty).
It's also GetKey that on the same strip, allows for switching between different apps (press Shift then the comma)

It's no wonder why GetKey must have a complicated flags system for signaling the enabled/disabled state of the Menu, Catalog, Clip, Poweroff, etc. It also has a key-remapping system you already documented. It definitely deserves a careful look

[SimonLothar]

Are you sure the OS doesn't call it with any parameter, or heed for its return value?

You are right. As far as I remember, SetGetKeyPhaseFlag needs two arguments. I missed to document the interface of SetGetKeyPhaseFlag properly in my doc version 18. I once spent a lot of time with SetGetKeyPhaseFlag, not finding significant information. But perhaps it is time to pick up the topic again. I'll have a look.

You bewildered me. I should trust myself a bit more.
SetGetKeyPhaseFlag takes no argument and does not return anything.
It does the following (on OS 1.04)

(syscall 02ca):

Code: Select all

void SetGetKeyPhaseFlag( void ){
  if (*(unsigned char*)0x880A2B09 == 0 ){
    *(unsigned char*)0x880A2B09 = 1;
    *(unsigned char*)0x880A2B08 = 0;
  }
  return;
}

( *(unsigned char*)0x880A2B09 != 0 ) seems to prevent AutoPowerOff and some battery low actions.