offset 5428 for project magenta

[Patrick M]

Hello Pete

I need your help for a strange problem.

i would like to write at offset 5428 to program the cdu magenta software.

if i use fs 9 this offset is by default at zero and every ascii caracter writed is displayed in the cdu software

by example i write '65' at this offset a 'A' is displayed in the cdu software.

if i use fsx this offset is by default at 593 and only some ascii caracters writed are displayed in the cdu software

i need to write several time the same value to display the caracter in the cdu sofwtare.

i have sent an email to PM whithout reply.

do you know if this offset is used by fsx ??

thank you

Patrick

P.S. I am using the last build of FSUIPC 4

[Pete Dowson]

i would like to write at offset 5428 to program the cdu magenta software.

if i use fs 9 this offset is by default at zero and every ascii caracter writed is displayed in the cdu software by example i write '65' at this offset a 'A' is displayed in the cdu software.

if i use fsx this offset is by default at 593 and only some ascii caracters writed are displayed in the cdu software

593 is hex 0251, which is PM's encoding of "Ctrl Q". Both FSUIPC3 and FSUIPC4 write this every 7 minutes or so, at PM's request, and have done since around Feb 2003. Ctrl Q should make the CDU terminate. It is to do with PM's demo mode I think. It also writes 'Q' to offset 542A at the same time, to terminate the Glass Cockpit.

i need to write several time the same value to display the caracter in the cdu sofwtare.

i have sent an email to PM whithout reply.

do you know if this offset is used by fsx ??

No offsets are "used by FSX", they are all memory owned by and maintained by FSUIPC. All of those assigned for Project Magenta use are reserved for Project Magenta use, though that doesn't stop anyone from writing to them.

Please persist with PM support. I'm sure they are the only folks who can help. as far as I know the action of FSUIPC writing these values is still correct, but I'll double check anyway. I wouldn't have thought it was this causing you the problem -- unless you are running PM in demo mode, i.e. not purchased yet?

[LATER]

I do note one thing different with FSUIPC4 from FSUIPC3 -- the values are written within the first minute, then every 7 minutes or so, whereas FSUIPC3 doesn't write them for the first 7-8 minutes. Maybe I need to make FSUIPC4 do the same.

Regards

Pete

[Patrick M]

Pete,

Of course it's the full registered cdu software and not the demo mode.

but value of 593 is present before i start pm cdu or other pm software ( i am writing by pm filecheck utility).

I have found a solution

by writing the value 1 at this offset, i can after send and display each ascii caracter.

i can also read at this offset the last written value (before it was always 593.

after about 3 minutes the value become again 593

Any idea

Thank you

Patrick

[Patrick M]

Pete

Don't worry about this

by writing everytime a value of 1 and after the ascii caracter (or function key...), i can manage this cdu interface and it's working with my home built cdu hardware

Patrick

[Pete Dowson]

Of course it's the full registered cdu software and not the demo mode.

but value of 593 is present before i start pm cdu or other pm software ( i am writing by pm filecheck utility).

Yes, sorry. I found that FSUIPC4 is doing it initially and then every 7.5 minutes, whereas FSUIPC3 does it only after 7.5 minutes.

I have found a solution

by writing the value 1 at this offset, i can after send and display each ascii caracter.

i can also read at this offset the last written value (before it was always 593.

after about 3 minutes the value become again 593

Well, it should be about 7 minutes, not 3, according to my code. As i said, this is there at PM's request, and it happens on FSUIPC3 too. The only difference is the one I mentioned above and before.

I have asked Enrico why this was required, and he cannot remember either, so I will probably take it out. It is odd that many folks use these offsets and FSUIPC3/4 have been doing this for years with no one mentioning any problems.

I'll remove the code in the next updates. It might not be for a few days though.

Regards

Pete

[Patrick M]

thank you Pete for your help

i am not lucky because now even by writing value '1' at this offset ,

this value is'nt stored like this morning and i must write several times the ascii code to display in the cdu sofwtare.

i will check and check again to find a solution.

i don't understand why this procdedure was working and now why not !!!

i can of course send a key to the window of cdu, but this windows must be active

Patrick

[Pete Dowson]

i am not lucky because now even by writing value '1' at this offset ,

this value is'nt stored like this morning and i must write several times the ascii code to display in the cdu sofwtare. i will check and check again to find a solution.

Okay. It sounds like the 392 bit was just a misleading worry (a red herring). However, in case it is contributing to the problem I will go ahead and remove it from FSUIPC -- sorry, it will be monday or Tuesday now.

i can of course send a key to the window of cdu, but this windows must be active

If you load the CDU using a "Run ..." parameter in WideClient.INI, you can direct keystrokes from a KeySend to it even if it has not got the focus. This is a standard facility of WideFS.

Regards

Pete

[Patrick M]

Hello Pete

I am in holidyas this week but always working on cdu interface.

i have tried the last beta fsuipc (4.266) and now every caracter or key write at offset 5428 is displayed in the cdu software.

I can too write the same key twice by changing bit 11.

Thank's a lot for this work!

Patrick

[Pete Dowson]

Thank's a lot for this work!

Okay.

Strange that it didn't affect many folks, all this time!

Regards

Pete