Welcome to the SR20 Community Forum - The Dash.
Register
SR20 forum logo

Thread: b14 launch control

+ Reply To Thread
Posts: 11-20 of 71
2009-08-21 04:35:20
#11
1M861 is the "ECU ID" (aka ROM_LABEL) for the bin from a '96 200SX manual trans B14-SR20DE OBD2 ECU. The part no. for it is JA18-G03-B47 (from http://www.jimwolftechnology.com/wolfpdf/ECU-ID.PDF). It's the bin Calum and I are planning to modify/implement with TunerCode firmware for the Calum RTV2, RTV1 and basic board support for B14's. E5CA and E5CC are absolute CPU relative addresses in hex. I prefer to reference addresses as CPU relative because they are the same regardless of the size of the bin file. 1M861 uses a 48k bin starting at 0x4000, however some bins are dumped into 64k bin files. If I specify an address as an offset into a bin file, then I must also know the size of the bin file. That's why all bin addresses should be specified as absolute CPU relative addresses. That way, regardless of the size of your bin file, you know the address being referenced.

If you have dumped your bin starting at 0x4000 through 0xFFFF into a 48k bin, then 0xE5CA is at offset 0xA5CA in the 48k bin file. If you dumped from 0 through 0xFFFF, then 0xE5CA is at offset 0xE5CA in the 64k bin file. The address of these bin locations also depends on what editor/tuning software you're using and how you have it set up. TunerPro allows you to specify an offset to apply to all addresses specified in an XDF. Since I don't know how everyone has their XDF set up, I can't specify an XDF address either. That's why I always specify addresses as CPU relative (and suggest everyone adopt it as a standard). CPU relative is the address the CPU (the microprocessor chip in the ECU) actually uses to address a value. It is absolute and independent of the size of the bin file and the offset specified in an XDF, ADR, or other bin editor definition file.

For example, if you use TunerPro and the "Bin Size" in your "XDF Header" is C000 (48k) and your "Base Offset" is 0000, then you would create new XDF constants at A5CA and A5CC respectively for these values. If your "Bin Size" is 10000 (64k) and your "Base Offset" is 0000, then you would create new XDF constants at E5CA and E5CC respectively for these values. If your "Bin Size" is 10000 (64k) and your "Base Offset" is 4000, then you would create new XDF constants at A5CA and A5CC respectively for these values.

So we don't have to spell out all of the possible combinations of bin file size and relative offset to identify the address of a value in a bin (as in the previous paragraph), we should always use the CPU relative address, which is constant and as I said, independent of bin size and bin editor.

Dave
2009-08-21 05:35:57
#12
Wow that's confusing... what if we just got the xdf and bin from you? like sent our current bin. Could you just set it up for the launch control and so we can adjust the rpm?
2009-08-21 15:45:51
#13
I can adjust launch rpm, rpm historesis and cut off speed on mine

How do I post xdfs?
2009-08-21 17:58:31
#14
Originally Posted by gtswrx
I can adjust launch rpm, rpm historesis and cut off speed on mine

How do I post xdfs?


You must be using Calum's B14 bin with his modification for launch control. The entries for those parameters in your XDF will not work with a stock bin.

Dave
2009-08-21 22:52:51
#15
Where do we get the bin modified for launch control?? I think most of us on this thread have veered away from stock bins anyways, unless I'm misunderstanding what you mean by "stock."

Also quick question, why is it that when someone emails me a bin it shows the file as an attachment of 48k but after downloading and saving as: it shows 64k? never made sense to me.
2009-08-21 22:56:13
#16
Originally Posted by dfddfd2
1M861 is the "ECU ID" (aka ROM_LABEL) for the bin from a '96 200SX manual trans B14-SR20DE OBD2 ECU. The part no. for it is JA18-G03-B47 (from http://www.jimwolftechnology.com/wolfpdf/ECU-ID.PDF). It's the bin Calum and I are planning to modify/implement with TunerCode firmware for the Calum RTV2, RTV1 and basic board support for B14's. E5CA and E5CC are absolute CPU relative addresses in hex. I prefer to reference addresses as CPU relative because they are the same regardless of the size of the bin file. 1M861 uses a 48k bin starting at 0x4000, however some bins are dumped into 64k bin files. If I specify an address as an offset into a bin file, then I must also know the size of the bin file. That's why all bin addresses should be specified as absolute CPU relative addresses. That way, regardless of the size of your bin file, you know the address being referenced.

If you have dumped your bin starting at 0x4000 through 0xFFFF into a 48k bin, then 0xE5CA is at offset 0xA5CA in the 48k bin file. If you dumped from 0 through 0xFFFF, then 0xE5CA is at offset 0xE5CA in the 64k bin file. The address of these bin locations also depends on what editor/tuning software you're using and how you have it set up. TunerPro allows you to specify an offset to apply to all addresses specified in an XDF. Since I don't know how everyone has their XDF set up, I can't specify an XDF address either. That's why I always specify addresses as CPU relative (and suggest everyone adopt it as a standard). CPU relative is the address the CPU (the microprocessor chip in the ECU) actually uses to address a value. It is absolute and independent of the size of the bin file and the offset specified in an XDF, ADR, or other bin editor definition file.

For example, if you use TunerPro and the "Bin Size" in your "XDF Header" is C000 (48k) and your "Base Offset" is 0000, then you would create new XDF constants at A5CA and A5CC respectively for these values. If your "Bin Size" is 10000 (64k) and your "Base Offset" is 0000, then you would create new XDF constants at E5CA and E5CC respectively for these values. If your "Bin Size" is 10000 (64k) and your "Base Offset" is 4000, then you would create new XDF constants at A5CA and A5CC respectively for these values.

So we don't have to spell out all of the possible combinations of bin file size and relative offset to identify the address of a value in a bin (as in the previous paragraph), we should always use the CPU relative address, which is constant and as I said, independent of bin size and bin editor.

Dave


can't post up any screenshots could you, with this description...pictures are worth a thousand words.
2009-08-21 22:56:16
#17
Originally Posted by LikeTheMovies
Wow that's confusing... what if we just got the xdf and bin from you? like sent our current bin. Could you just set it up for the launch control and so we can adjust the rpm?


Originally Posted by nsusammyeb
can't post up any screenshots could you, with this description...pictures are worth a thousand words.


I'm working on an answer to your questions and will have something for everyone tomorrow.

Cheers,
Dave
2009-08-21 23:11:39
#18
Originally Posted by nsusammyeb
Where do we get the bin modified for launch control?? I think most of us on this thread have veered away from stock bins anyways, unless I'm misunderstanding what you mean by "stock."


Calum posted a B14 LC (Launch Control) bin some time ago, however I don't know if it works or not.

When I say stock bin, I mean one with stock, original, unmodified code (programming). When you modify, or tune, a bin with TunerPro or NIStune, or some other bin editor, you are only changing the constants and tables that the code uses. You're not changing the programming.

Originally Posted by nsusammyeb
Also quick question, why is it that when someone emails me a bin it shows the file as an attachment of 48k but after downloading and saving as: it shows 64k? never made sense to me.


My guess is that the bin is zipped, or compressed somehow before being downloaded.

Cheers,
Dave
2009-08-22 00:44:53
#19
Originally Posted by dfddfd2
Calum posted a B14 LC (Launch Control) bin some time ago, however I don't know if it works or not.

When I say stock bin, I mean one with stock, original, unmodified code (programming). When you modify, or tune, a bin with TunerPro or NIStune, or some other bin editor, you are only changing the constants and tables that the code uses. You're not changing the programming.

Cheers,
Dave


Word was that calum's original bin for the b14 lc didn't work but the b13 did.

Starting to make a little sense though, I need to learn a little more about xdf's and adr's i guess.
2009-08-22 17:41:34
#20
I created a couple of XDFs for the launch control parameters, one for 64k bins and another for 48k bins.

B14_P10_LC_Stock_ 64k_bin_TPV4.xdf
B14_P10_LC_Stock_ 48k_bin_TPV4.xdf

They should work for most 94-98 OBD2 SR20DE B14 or P10 bins. Click on the link above for your bin size to download. These XDFs contain only the two parameters described above, but if you know how to use the XDF editor, you can add them to the XDF you use now to avoid switching back and forth. The TPV4 in the file name stands for TunerPro version 4.

I have no way to actually test this, so let me know how it works. Please include your bin ROM_LABEL (ex: 1M861) when posting.

Cheers,
Dave
+ Reply To Thread
  • [Type to search users.]
  • Quick Reply
    Thread Information
    There are currently ? users browsing this thread. (? members & ? guests)
    StubUserName

    Back to top