pgmfi.org

Hi gents.

Addressing ROM positions isnt a problem - very easy to access offline maps etc on both P30 and P72 binaries. I'd like to ask a question about realtime access of the RAM positions like loc 012C / 00C2 / 012D etc. (P30 code)

I have RTP devices like the Moates to use for this communication - really a basic question of addressing right now. If anyone would like to share their invaluable experience in this sphere, please post up.

Cheers

To add to the above, I really thought it would be as simple as the ROM loc addresses but I noticed these from P30 code spec:

0123.3 / 0116.2 / 0116.3 / 021A.3 etc.

I have no idea how one would begin to locate that let alone read from it.

Cheers.

im not 100% sure what your questions is, but you can get values from polling certain addresses (ie. datalogging). it depends on how the serial communication routines are setup on the rom if you can send a single address and expect the value back or if you need to send an array of certain values or some other combination of data.

im assuming that 0116.2 is looking at the 2nd position of the binary value in that address.

look thru the moates protocols for how to read/write to the emulator...
http://forum.pgmfi.org/viewtopic.php?f=28&t=20434

Ah...

then I know what to do this line turned on the lights: "...im assuming that 0116.2 is looking at the 2nd position of the binary value in that address."

I have a fair understanding on the Moates protocol, so shouldn't have trouble polling these. Let's see if I come right

xxxx.2 is actually the third bit.

0 1 2 3 4 5 6 7

Sorry, yes, 0 based. Thanks for that, appreciated.

Hi again,

Location 7000, P30 code, reading back 00 30 50 70 90 B0 D0 E0 F0 00 (no need to elaborate, most of you guys know this refers to Millibar scale).

I am a bit confused, see item 10 (9 from 0 / 7009) is also 00 - same as 7000.

Roughly translated we get:

142.2882 | 314.4765 | 429.2686 | 544.0608 | 658.853 | 773.6451 | 888.4373 | 945.8334 | 1003.229 | 142.2882

The problem is the last index.

I am trying to get back to this:

114 | 288 | 403 | 519 | 634 | 750 | 865 | 923 | 981 | 1035

of stock P30 NA code

This is something stupid that I haven't worked out yet keep me awake.

If you look at the code in which the table is accessed it finds a value in the table that is below the altered MAP reference. If all else fails, it's always at or above 0, thusly keeping it within the constraints of the table.

MAP in mBar = (MapVolt * 367) - 59

Hex scale value = Hex (((255 / 5 * MapVolt) - 24) * 2)

$7000=#00 => #00 => MapVolt = 0.4706 Volt => 113.7 mBar
$7001=#30 => #30 => MapVolt = 0.9412 Volt => 286.4 mBar
.......
$7008=#F0 => #F0 => MapVolt = 2.8235 Volt => 977.2 mBar
$7009=#00 => #100 => MapVolt = 2.9804 Volt => 1034.5 mBar

dip + smooth1 > thanks for both comments.

My problem was the last index, instead of using it as 100 -> I was using as 00, same as index 0. Now with that slight code change - I sort of match what I know these scales to be.

Thanks again.

here's a little gem.

After unpacking data from 637B and 637C (Little Endian format 16bit) - how does one re-pack back to the hex equivalent? For example, from 7600 split back between the two bytes located at 637B/C.

I am 100% agree with your statement about it. This post is really nice, I hope that people will really like. You declared all information related to RAM is very much true and helpful details, I also want to mention about it.