On 2006-08-03, Douglas Handy <[EMAIL PROTECTED]> wrote:
> Luc,
>
>>I don't know, this is what I observed on the T3 Simulator. Does it need 
>>those PRCs too?
>
> Yes.  The problem is that the T3's ROM image was produced before the final
> public API specs were available.  The the built-in apps use a different
> proprietary method which was only shared with those vendors creating apps for
> the initial T3 release.  But they never intended for those calls to be
> supported
> on any other devices, so they were only part of the non-disclosure to the
> vendors necessary.  
>

No, no, no. See below

> Once the real PIN manager specs were released, a pair fo "compatibililty"
> PRC's
> were made available to allow the T3 to conform to the new APIs.  So while
> there
> is some undocumented method to control it on a stock T3 or simulator, the PIN
> manager itself does not exist in the device ROM.
>
> What always surprised me though is that there was a T3 ROM upgrade published
> after the release of the PIN mgr and compatibility prc's, yet for some reason
> they were not included in the ROM upgrade.  Go figure.
>
> Or at least that is how I understand the history of it to be.
>
> Doug

The T3 simulator has the compatibility prcs already built-in. You cannot 
execute the T3 compatibility prcs on the sim anyway, because the sim
does not know how to handle ARM code.

FtrGet(pinCreator, pinFtrAPIVersion, &version) returns 0x1103000 on the
T3 simulator (and on the real device) which corresponds to version 1.1 of 
the PIN manager (pinAPIVersion1_1).
In version 1.1 of the PIN manager you can call 
SysGetOrientationTriggerState(). On devices that don't support changing 
the display orientation, this function always returns
sysOrientationTriggerDisabled (at least according to the SDK docs).

The notes in the doc about using SysGlueTrapExists are plain wrong.
All the PIN calls use the same trap (sysTrapPinDispatch, 0xA470) with a
selector in register D2. The selector value for pinSysGetOrientation is
19 (0x13). There is no trap 0x0013. All traps are 0xA0xx. Hence you get 
your false return value. Even on a real T3 it returns false (just checked 
it). There are many more 'trap with selector': High-density bitmap and 
window calls, float manager calls, VFS calls, ... For all these 
SysGlueTrapExists() cannot be used.

For somemore history about the DIA read section 9.13 in the Palm SDK 5.2
Developer Guide.

Ton van Overbeek

-- 
For information on using the PalmSource Developer Forums, or to unsubscribe, 
please see http://www.palmos.com/dev/support/forums/

Reply via email to