Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Dissassembling and finding the maps


Guru

Status: Offline
Posts: 2338
Date:
RE: Dissassembling and finding the maps


If the general RPM limiters that were found by RR earlier are correct, then the RPM variable that to which those are compared is is 0xFFFF83B8. So that may be the second RPM ram value.

This information is to be confirmed.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

OK,

The engine conditionf flag FFFF8553 is confirmed. It changes the bits when exceeding max revs. The same thing with FFF8556 its some sort of engine condition value.

The supposed other RPM limits is a variable that gets shorter the more revs the engine has. Either it is maximum fuel injector cut off value or its an rpm value that is calculated as time between crank revolutions. This variable does not change based on fuel need (no affect with TPS or AT sensor changes)

Gauge RPM         VALUE
12500                0x4E3
9000                  0x766
6000                  0xA24
3000                  0x159D

I think I need better understanding of this, but have a hunch that RR has already discovered this with 16bit kawi and busa.

Additionally I found out a problem in the RAMread program counting the bits for differently sized ram variables so the RPM/100 is not RPM/100 its actually RPM/256*10 smile.gif as one would have guessed.

REVOLUTION time ,FFFF83B8 = 000006AA
Engine cond fc/igncut bit tbc ,FFFF8556 = 00008000
Engine cond fc/igncut bit 0,1 tbc ,FFFF8553 = 00000000
Coolant temperature,FFFF81D2 = 000000AD
Ambient pressure,FFFF81CA = 000002A8
Gear position sensor,FFFF83CF = 00000001
Unk AN10,FFFF81DC = 00000000
Actual RPM/100 ,FFFF8398 = 00005F3C
TPS Sensor ,FFFF81E6 = 0000011A
PORTH ,FFFFF72C = E1F7E1F7
PORTH H RAM ,FFFF8160 = 0000E30A


 



-- Edited by PetriK at 07:49, 2007-12-15

-- Edited by PetriK at 08:11, 2007-12-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think that the formula to calculate the timing is based on the crank wheel size as that is the timing element that generates the pulses.

If I use this formula: 24*10 / 0xFFFF83B8 * 65535 the timing pulses start to make sense.

4e312511250012573
766189490008304
a24259660006059
159d553330002843


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Here are the busa RPM variables found so far:

REVOLUTION time 230/X*0xFFFF ,FFFF83B8 = 00002AE7
Actual RPM X*100/256 ,FFFF8398 = 0000294A
RPM X/256,FFFF839C = 0000297D

[EDIT, the wheel has a missing tooth so the actual figure is 230 ?!?!!!]

... its interesting to see how these do not really match with each other ...

Additionally its possible that the pressure map x value is this:
Pressure map X,FFFF834E = 00000000


Edit, lets add a small sidenote here to benefit the others who try to find the same...
- There is a lot of functions with a clear reference to the map definition bytes. All these seem to load the same variables to certain register before calling the function which returns the map data value for given x/y. I found these variables mainly by reading the code and shortlisting the variables. Then tested all the variables with bike emulator by just varying one of the components to get these results.
- Regarding pressure map. There is two sensors, ambient pressure and manifold pressure. As part of the subroutine the formula ambient-manifold is used. Then the return value is driven throug a 2D map and finally the result is calculated to be the Manifold Air Pressure X variable.

The strategy to get the shortlisted variables was first to find what is the 2D map search function and 3D map search function and then to look very carefully all the variables acting as an input to those.


-- Edited by PetriK at 14:51, 2007-12-16

-- Edited by PetriK at 15:14, 2007-12-16

-- Edited by PetriK at 14:30, 2007-12-17

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

bozo wrote:

PetriK wrote:

Yes,

That definately is an expression that explains the format of the table. We just need to find the table conversion function and that should give explanation.



 it appears that the numbering scheme (for my ECU anyway) is as follows:

1  2   3   4   5   6

5  A   8   -   8  16

6  A  16   -   8  16

9  A   8   -  16  16

A  A  16   -  16  16

19 M   8   8  16  20

25 M   8  16  16  20

29 M   8  16  16  20

2A M  16  16  16  20

where the columns are:

1. format number

2. A(rray) or M(atrix)

3. bits per data point

4. bits per X (Y?) axis data point

5. bits per Y (X?) axis data point

6. record length (bytes)



Cheers,

Mark



I wanted to clarify this to make sure what your seeing is the same in the ZX-6 that I'm looking at now.


2D map table entry is

Type
X length
0
0
X data source addr
Map data addr
null addr

3D map table entry is

Type
X length
Y length
0
0
X data source addr
Y data source addr
Map data addr
null addr


Type on a bit level contains bit size flags

bit0  Map8
bit1  Map16
bit2  X8
bit3  X16
bit4  Y8
bit5  Y16
bit6  0
bit7  0

So for instance Type= 9 is a 2D map because niether Y is set and has 16bit X axis data and 8 bit map data

Type = 0x25 would be 3D map with 16bit Y, 8bit X, and 8bit Map

If this is correct and standard through out the 32 bit denso I think I might try my hand at writing a AutoEnginuity map xml generator that reads the bin file and defines all the maps found in the definition table with this format.



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, the map generation is semi automated with the excel tool which works fairly ok.

Then there is scaling which I have not yet been able to find a reasonable hint which variable is used so some degree of parametrization would be recommended ? Also there is quite a lot single value parameters which are used to define e.g. which map is used for initial variable compensation (ambient pressure - manifold pressure) -> correction map -> value.

mapdefs


mapdefs2

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Your Excel is better than doing it by hand but with these 32 bit ECUs having 100+ maps that is still a lot of numbers to enter by hand. I think I'll try to write something that can actually read the bin file and do the preliminary definition.

__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, I completely agree... i was more thinking along the lines if the file could be built from idc code with map names already in there. Right now the biggest pain is to move the info from idc to excel and then to xml. Like you said its over 100 maps + a lot of individual constants (like rpm limitere) there, hence automation would be really helpful. Another parameter is the scaling. With rpm there is two definitions. With tps/iap I have not had time to find out yet.

So how about you - are you thinking along the lines of just treating the .bin or .idc ?









-- Edited by PetriK at 17:21, 2007-12-16

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

That is kind of a chicken or egg question. If I have to manually step through the file on IDA and name all the maps before I can generate my auto-xml it seems to me to defeat the purpose.

I kind of like to look at the maps first and then find their details in IDA. Once I've got a basic definition of the maps with autogenerated map names using their address I can always do a Find and Replace with better names later.

Besides I think the bin will be easier to read out the data on. The idc has a lot text to search and parse just to find the map entries. The bin all I need is a starting address and I can jump right to it.

__________________


Guru

Status: Offline
Posts: 2338
Date:

I see your point. Thats what I would have done a couple of weeks ago too (if I would have had the tools skills smile.gif. [it takes way too long time to get the development environment working and relearn simple things like file IO.]

Anyway within ida there is a very clear area which you can just change into right lonwword format and you have the map addresses there (as you must know by now). That took a few minutes to type in d,d,d,d,d,d,d,d to convert into map address table. Now this information is most helpful when defining the map purposes as each map has a defined name already.

Maybe you have a different strategy? I am identifying these now by the AD converter variables, Port H MS input and based on if the input to the map find function is either TPS or Manifold pressure difference.

For me the key question here is how is all this newly built map name information easily outputted to any mapping definition file alongside the scaling information. (Luckily for TPS and IAP scaling there is only a few alternatives.)

Any suggestions ?

ROM:0002832C Pressure_MSoff_MAPC3_defs:.data.l h'2A152B00 ; DATA XREF: sub_10294:off_102DCo
ROM:00028330                 .data.l unk_2A610
ROM:00028334                 .data.l unk_2A63A
ROM:00028338                 .data.l MAPC3
ROM:0002833C                 .data.l 0
ROM:00028340 Pressure_MSoff_MAPC4_defs:.data.l h'2A152B00 ; DATA XREF: sub_10358:off_103D8o
ROM:00028344                 .data.l unk_2AD9E
ROM:00028348                 .data.l unk_2ADC8
ROM:0002834C                 .data.l MAPC4
ROM:00028350                 .data.l 0
ROM:00028354 TPS_MSno_MAPD1_defs:.data.l h'2A172B00  ; DATA XREF: ROM:off_107DCo
ROM:00028358                 .data.l unk_2B52C
ROM:0002835C                 .data.l unk_2B55A
ROM:00028360                 .data.l MAPD1
ROM:00028364                 .data.l 0
ROM:00028368 TPS_MSno_MAPD2_defs:.data.l h'2A172B00  ; DATA XREF: sub_10358:off_10400o
ROM:00028368                                         ; sub_10464:off_104E4o
ROM:0002836C                 .data.l unk_2BD6A
ROM:00028370                 .data.l unk_2BD98
ROM:00028374                 .data.l MAPD2

EDIT - these are more or less now confirmed:

FFFF8342, TPS 0xC00=0v, TPS normal range: 3900-DC00
FFFF8346, = FFFF8342/0xFF
FFFF84C7, FF when closed throttle and below 2000rpm. 0x00  when bigger than 0x110. Looks like somekind of closed throttle (injector shut off ?) variable ?

Additionally suspect the following, these are to be confirmed, very likely to present incorrect thinking:
Gauge data string to be written in two RAM variables: FFFF8228[7]->FFFF8212[7] ???
FFFF8405 TPS error flag ???
FFFF844E IF TPSx/256 > 0x40 Then FFFF844F + #0x01
FFFF84C6 ? used for selecting mapJ1,C1,E1




-- Edited by PetriK at 21:29, 2007-12-16

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 21
Date:


Don't forget it could try to limit the RPM differently for different situations.

For example

If you pin the throttle in neutral it will spin up much faster than in a gear and need to cut in earlier to prevent over reving.

Same as 1st gear verse 5th gear.

The engine accelerates much faster in 1st than it does in higher gears and would over rev more if you cut it out at the same point as a higher gear.

I know some people have complained of the limiter cutting in early when they bypass the clutch switch (so the ECU thinks the clutch is always pulled in)



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes - there is limites for all gears (including neutral/clutch) as well as generic limiters for fuel cut and ignition cut which are lower than gear limiters. Aditionally the ecu seems to cut ignition now and then when revving with neutral like it is slowing down the engine rpm acceleration on neutral.

Even changing the limiters is a complex matter , but luckily it looks like we are soon at a point where we can most likely document some findings while building the next set of enginuity definitions. Identifying the limiters is becoming much more easier now when the three different RPM variables are known.

I hope that soon someone else would start to work on Busa dissassembly too to challenge some of the obvious mistakes which I am likely to make during the process...

-- Edited by PetriK at 07:34, 2007-12-17

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

RR, come to think about the map auto generation and maybe there is a way to autogenerate the names from the .idc file for the autogenerated xml file. The key here would be that the autogeneration you are planning would name the maps e.g. with precice byte name like 0X28010 so that at later stage that could be converted to "RPM_correction_Unk1_defs" - if I may suggest.

There seems to be a MakeName syntax used for those addresses which should also be put also into the Enginuity file. I am currently naming only the map definition names but it would be as easy to name the actual maps too during the disassembly process.  Makename is used not only for maps, but also for variables: But as long as the .idc autonames are accepted only from data-area above 0002:0000 then that could act as an addicional input for adding signle variables like rpm limiters.

So first autogenerate the maps from the .bin
Then add names from the .idc for maps found from the bin.
As the last step generate new single variables based on makename command for those which have not yet been generated.

???

 MakeName (0X28010, "RPM_correction_Unk1_defs");
 MakeName (0X280A0, "map_280A0");
 MakeName (0X28020, "Gear1_defs");
 MakeDword (x=0X28024);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X28028);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (0X2802C);
 MakeDword (0X28030);
 MakeName (0X28030, "Gear2_defs");
 MakeDword (x=0X28034);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X28038);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeName (0X28304, "Pressure_MSoff_MAPC1_defs");
 MakeDword (x=0X28308);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X2830C);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X28310);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (0X28314);
 MakeDword (0X28318);

 MakeName (0X28318, "Pressure_MSoff_MAPC2_defs");
 MakeDword (x=0X2831C);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X28320);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (x=0X28324);
 OpOff  (x, 0, 0X0);
 OpOff  (x, 128, 0X0);
 MakeDword (0X28328);
 MakeDword (0X2832C);


-- Edited by PetriK at 09:21, 2007-12-17

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The SIO3 control protocol carries the gauge cluster data to busa gauge including temperature, FI error codes and fuel consumption. This data is stored in a variable that is then copied for SIO protocol to use.

Gauge data string to be written in RAM variables one for building the data the second for SIO to use for writing: FFFF8228[7]->FFFF8212[7]

Byte 0:FFFF83C2
Byte 1:built bit level based on several or sentences
Byte 2:built bit level based on several or sentences
Byte 3:built bit level based on several or sentences
Byte 4:built bit level based on several or sentences
Byte 5:FFFF8320
Byte 6:FFFF8320
Byte 7:FFFF85D9

The bit level functions are flags indicating various error codes, will have alook at that a bit later.
The .idc file is updated accordingly.

Additionally gave descriptive names to many AD converter based tables just by looking at the input variables for the map search functions.

The most difficult part seems to be now to find the engine condition flags for acceleration vs. cruise to understand which maps are used and when.

Also figured out that the RPM function is using 23 spoke wheel (one missing tooth) for calculating the RPM.

Oh and yes, looks like sometimes parts of the code is copied to RAM area using the DMA function. Perhaps that quarantees faster execution ?






-- Edited by PetriK at 21:26, 2007-12-17

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Based on practical measurements of the TPS values we know that fully closed TPS (misadjusted to 0v) is 0xc00, normal tps signal with proper idle adjustment is 0x3900 and fully open TPS signal is 0xDC00. Of course the bike emulator may have slightly misleading numbers, but based on this its fairly ok to assume that the min/max numbers are either 0x0000-0xFFFF or 0x00-0xFF for TPS/256 variable. On a standard TPS based map like below the values vary between 3700 - E800.

This gives us a practical problem, that should the number 0x3700 represent 0% Throttle opening or 21% Throttle opening. Usually Closed properly adjusted throttle is considered 0% opening so I would be enclined to use the same formula in defining the TPS scaling with this project ?

Any comments to this ?

This information becomes important when tuning the ecu as well as when defining the further variables like:  word_28C18 which could be then interpreted either 8% or 28% opening.

c003072-21 %
3700140800 %
3900145921 %
4800184328 %
58002252816 %
dc005632082 %
e8005939288 %
FFFF65535100 %

or

c0030725 %
37001408021 %
39001459222 %
48001843228 %
58002252834 %
dc005632086 %
e8005939291 %
FFFF65535100 %


ROM:0002C5A8 word_2C5A8:     .data.w h'3700, h'3800, h'3900, h'3A00, h'3B00, h'3C00
ROM:0002C5A8                                         ; DATA XREF: ROM:00028380o
ROM:0002C5A8                 .data.w h'3D00, h'3E00, h'4000, h'4200, h'4400, h'4600
ROM:0002C5A8                 .data.w h'4800, h'5000, h'5800, h'6000, h'6800, h'7800
ROM:0002C5A8                 .data.w h'8800, h'9800, h'A800, h'C800, h'E800



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I've gone back and forth on this issue myself. I guess my viewpoint is that at some point the end user is going to want to adjust the map for a particular throttle setting. The most accurate way to measure that is putting a data logger or volt meter on the TPS. So it seems to make more sense to scale the maps in actual % of TPS voltage.

If your on the dyno and you need to adjust something and you check the TPS voltage and its 2.5V then you look at the 50% Throttle section of the map. That just seems easier to me than saying figure out the %voltage and subtract 21%

Of course I'm a programmer and not an engine tuner. Maybe from a tuners perspective having the idle section of the map being 21% is confusing. I would say the community at large is probably used to the way dynojet does it on the power commander software.

__________________
Don


Veteran Member

Status: Offline
Posts: 40
Date:

We dyno tune all of the time and everything we have ever used was based on actual throttle position, not on the total A/D voltage range of the analog input port. Even while using the monitor portion of the Kawasaki Kit Racing ECU, the TPS is actually based on the actual TPS, not the voltage. For example, when the throttle is closed all the way, the tps position reads 0% and when it's wide open it reads 100%. It's the same way on all aftermarket racing ECUs and piggyback units that I've used. There is always some sort of "calibration" that tells the unit what the throttle closed and open voltages are to calculate %throttle, then all tuning is done based on 0 to 100% throttle. I hope this helps.

__________________
Don


Veteran Member

Status: Offline
Posts: 40
Date:

Just thinking about the practicality of tuning the ECU directly on the dyno without a power commander. We always use the power commander TPS position to tune all of the part throttle maps. It will be difficult to reliably tune the actual TPS values if we don't have any visual feedback of the actual TPS. Anyone have any ideas on how we can display TPS real time?

__________________


Guru

Status: Offline
Posts: 2338
Date:

For TPS real time I have used LM1 which has one sensor input as TPS signal.

But with AUD connector you can get more, you can actually get the real TPS figures from inside the ECU. This is what I am currently doing when testing for sensors and stuff. Then it becames an excersise of logging and analyzing the data from AUD.

Then back to maps. Today looked back to Map A/B selection criterias and looks like that its coded into flash which map to use. The way I read this its always MapB for both EU and US models. For clarity this set of maps is different to maps that can be selected by Map Select (MS) wire from the harness.

ROM:0000BB0A sub_BB0A:                               ; CODE XREF: Main_Loop_uncertain_sub_636+12BD8p
ROM:0000BB0A                                         ; DATA XREF: ROM:off_133A0o
ROM:0000BB0A                 sts.l   pr, @-r15
ROM:0000BB0C                 mov.l   @(h'A4,pc), r2 ; [0000BBB4] = EU0x80_US0x80_byte_29407 ; map select constant
ROM:0000BB0E                 mov.b   @r2, r0
ROM:0000BB10                 extu.b  r0, r0
ROM:0000BB12                 cmp/eq  #2, r0          ; 80 = 2 -> False
ROM:0000BB14                 bf      loc_BB1E        ; mapB
ROM:0000BB16                 bsr     sub_BD6C        ; mapA


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Well it sounds like 0-100% is the industry standard. Guess I'll have to rewrite some Enginuity XML

I think the AUD will be good for Alpha testing but for the end user I think we should patch the code to output data out the wire harness serial port that has RPM, TPS etc. like I assume the Kit Software does.

__________________


Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:
Then back to maps. Today looked back to Map A/B selection criterias and looks like that its coded into flash which map to use. The way I read this its always MapB for both EU and US models. For clarity this set of maps is different to maps that can be selected by Map Select (MS) wire from the harness.



 In the 16bit software, both busa and zx-12 there was also a softswitch that made the maps B always or MS selectable with B as default (no jumper)


 

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

RR, when  you have the scaling function for TPS redefined for Enginuity please post it here. I will use the same scaling with Busa. I am just about there to put TPS/IAP and RPM/LOWRPM scales on the maps (also including the information if the Map Select wire affects the map or not).

The other maps are software selectable where as these not (at least so far).
Anyway its really easy to reprogram that part of the code so that the map select function works too.

ROM:0000BB0C                 mov.l   0xFFFF8160, r2 ; use porth variable here...
ROM:0000BB0E                 mov.b   @r2, r0
ROM:0000BB10                 extu.b  r0, r0
ROM:0000BB12                 cmp/eq  #10, r0          ; Bit 4, MAP select
ROM:0000BB14                 bf      loc_BB1E        ; mapB
ROM:0000BB16                 bsr     sub_BD6C        ; mapA



The one area where I really would appreciate some advice and help is the timer function to start working on the actual map values and finding out how the values are built.

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:


 In the 16bit software, both busa and zx-12 there was also a softswitch that made the maps B always or MS selectable with B as default (no jumper)





Yes, having looked more carefully there appears to be four variables (FFFF8457,8,9,A) that will set if Map A or B is to be used.

The good news is that now all the major maps have been named according to the Gear/LowRPM/IAP/HighRPM on the .idc file so changing that info to enginuity .xml should be easy.

The area I am currently working is to understand fuel compensation calculations and engine conditions. E.g. I suspect that FFFF8507 bit0 is engine load as: 1 if RPM>8000, 0 if Clutch, first gear or rpm<7800.

Any comments on similiarities between busa, zx6 and sv1000 code ?







__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Member

Status: Offline
Posts: 22
Date:

PetriK:
------------------------------------------
RAM variables generation from AD converter:
Unk:                 F800->FFFF81C8
Manifold pressure:   F802->FFFF81CA
Voltage comp:        F804->FFFF81CC
Air temperature:     F806->FFFF81CE
Tipover sensor:      F808->FFFF81D0
Water temperature:   F80A->FFFF81D2
Air pressure:        F80C->FFFF81D4
Cov1:                F80E->FFFF81D6
Cov2:                F810->FFFF81D8
Cov3:                F812->FFFF81DA
UnkAN10:             F814->FFFF81DC
Antitheft:           F816->FFFF81DE
Oxygen sensor:       F820->FFFF81E0
Unknown AN13:        F822->FFFF81E2
Gps sensor:          F824->FFFF81E4
TPS sensor:          F826->FFFF81E6
------------------------------------------


These are the RAM variables for the Hayabusa. Are the converter addresses (F800...) and the relation to the sensors the same for GSXR 1000 K5/K6?

Best
   Christian


__________________


Guru

Status: Offline
Posts: 963
Date:

No they are not the same

For -41G10


RAM:FFFF81C0 ;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RAM:FFFF81C0 ;  Copy of Analog Registers
RAM:FFFF81C0 ;
RAM:FFFF81C0 ;  Values are right justified between 0-3FF
RAM:FFFF81C0 ;
RAM:FFFF81C0 AN0_TPS:        .res.b 2                ; DATA XREF: ROM:off_788o
RAM:FFFF81C0                                         ; sub_38B4:off_3A3Co ...
RAM:FFFF81C0                                         ; Throttle Position Sensor harness pin 8
RAM:FFFF81C2 An_1:           .res.b 2
RAM:FFFF81C4 An_2:           .res.b 2
RAM:FFFF81C6 AN3_IAT:        .res.b 2                ; Inlet Air Temp Sensor harness pin 27
RAM:FFFF81C8 AN4_TO:         .res.b 2                ; DATA XREF: ROM:off_BD8Eo
RAM:FFFF81C8                                         ; ROM:off_BEBCo ...
RAM:FFFF81C8                                         ; Tip Over Sensor harness pin 22
RAM:FFFF81CA AN5_ECT:        .res.b 2                ; DATA XREF: ROM:off_DC46o
RAM:FFFF81CA                                         ; ROM:off_DD6Eo ...
RAM:FFFF81CA                                         ; Engine Coolant Temperature harness pin 10
RAM:FFFF81CC AN6_SAP:        .res.b 2                ; Static Air Pressure harness pin 26
RAM:FFFF81CE AN7_COV:        .res.b 2                ; DATA XREF: ROM:off_BC68o
RAM:FFFF81CE                                         ; Yosh COV harness pin 54
RAM:FFFF81D0 AN8_COV:        .res.b 2                ; DATA XREF: ROM:off_BC8Co
RAM:FFFF81D0                                         ; Yosh COV harness pin 53
RAM:FFFF81D2 AN9_COV:        .res.b 2                ; DATA XREF: ROM:off_BCB0o
RAM:FFFF81D2                                         ; Yosh COV harness pin 52
RAM:FFFF81D4 AN10_Volts:     .res.b 2                ; System Voltage = (AN10/1024) * 20V
RAM:FFFF81D6 An_11:          .res.b 2
RAM:FFFF81D8 AN12_IAP:       .res.b 2                ; Inlet Air Pressure harness pin 9
RAM:FFFF81DA An_13:          .res.b 2
RAM:FFFF81DC AN14_GPS:       .res.b 2                ; Gear Position Sensor harness pin 23
RAM:FFFF81DE AN15_STP:       .res.b 2                ; Secondary Throttle Position harness pin 20
RA


-- Edited by RidgeRacer at 19:14, 2009-01-08

__________________


Guru

Status: Offline
Posts: 1344
Date:

petrik,is the busa .idc file still available??

__________________

09 busa.????? now what....still got what it takes.......!

I got what you need...!
www.poweredbyford.com

www.marc@poweredbyford.com

 



Guru

Status: Offline
Posts: 2338
Date:

old busa yes I made it avail New busa has not been generally made availabe, but dont see why not either.

Are you able to help us with this:
http://www.activeboard.com/forum.spark?forumID=99460&p=3&topicID=29221481


-- Edited by PetriK on Sunday 12th of July 2009 02:08:11 AM

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Senior Member

Status: Offline
Posts: 144
Date:

Hi there!

Recently i started disassembling the SV1000 ecu! It am in contact with Bozo! I have identified most of the maps and i have done lots of work! But i miss something on the fuel maps. I have found them but i can't identify which one is for the front and rear cylinder and such! I get lost somewhere in the RAM locations!

Can anyone of you help me? I can provide the .IDC file and the RomRaider definition.

Thank you in advance

__________________

For your DIY or Professional tuning needs be sure to check out
PVTech ECU Research & Development

«First  <  1 2 | Page of 2  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard