Looking for DME BIN files

[Tom]

Thanks John -- I have enough BINs to go on now and am knee deep in tuning my chip -- pretty much done at this point. I plan to do a little write up to help other newbies like myself. I'll have to take a much closer look at your KLR work. Did you happen to do a TunerPro XDF file for the KLR? And/or have any tips for over-riding its overboost protection? I'm using an electronic boost controller, so can use the stock KLR chip, but for the sake of completeness that was on my list to figure out...

[johnb]

Thanks John -- I have enough BINs to go on now and am knee deep in tuning my chip -- pretty much done at this point. I plan to do a little write up to help other newbies like myself. I'll have to take a much closer look at your KLR work. Did you happen to do a TunerPro XDF file for the KLR? And/or have any tips for over-riding its overboost protection? I'm using an electronic boost controller, so can use the stock KLR chip, but for the sake of completeness that was on my list to figure out...

I never created an XDF, no - it was always more of an educational thing than a tuning project for me, so my notes are heavy on nerdy implementation details and light on practical tuning info.

I'm not familiar with TunerPro but I can probably help. I'll take look at the one that was uploaded and see if I can verify the locations they're using. I'm assuming it's mostly a question of identifying where the maps start and end?

My memory is a bit hazy on the overboost protection but iirc that's probably why the aftermarket chip just maxed out the map values. It has an rpm/throttle map for target boost and if you exceed that for a while it goes into limp mode (which doesn't affect you if you're using some other boost control). It'll still continue to provide knock protection no matter what.

[Tom]

Thanks John -- I have enough BINs to go on now and am knee deep in tuning my chip -- pretty much done at this point. I plan to do a little write up to help other newbies like myself. I'll have to take a much closer look at your KLR work. Did you happen to do a TunerPro XDF file for the KLR? And/or have any tips for over-riding its overboost protection? I'm using an electronic boost controller, so can use the stock KLR chip, but for the sake of completeness that was on my list to figure out...

I never created an XDF, no - it was always more of an educational thing than a tuning project for me, so my notes are heavy on nerdy implementation details and light on practical tuning info.

I'm not familiar with TunerPro but I can probably help. I'll take look at the one that was uploaded and see if I can verify the locations they're using. I'm assuming it's mostly a question of identifying where the maps start and end?

My memory is a bit hazy on the overboost protection but iirc that's probably why the aftermarket chip just maxed out the map values. It has an rpm/throttle map for target boost and if you exceed that for a while it goes into limp mode (which doesn't affect you if you're using some other boost control). It'll still continue to provide knock protection no matter what.

That would be awesome. I'm not too worried about an actual XDF file, just confirming the locations for the over boost table, and confirming that maxing them out (or increasing them) will effectively eliminate that function. The DME has its own table -- like a dozen or so values for max load per rpm -- for its overboost protection, and maxing out the values in that table effectively eliminates it. If the KLR is equally simple, it would be easy enough to do that with a simple hex editor.

[johnb]

I have an outline section on my site indicating where everything interesting is located: https://jhnbyrn.github.io/951-KLR-PAGES ... _code.html

In the attached image you can see what Dinan did for the boost map (left) vs stock 89T (right) (this target boost map is at 0xC00 - 0xC7F)

But now that I'm refreshing my memory, the I think the KLR will throw a blink code if you are too far under the target boost curve too. This DInan chip has also modified the open loop CV map presumably to help hit that target (this map is from 0xB00 - 0xB7F).

The closed loop control will always adjust the CV duty cycle to try and achieve the target boost but it's only for fine-tuning - the open loop map is the baseline that's intended to get you very close on the first attempt. So it makes sense to modify both together. That said, I'm not sure how far you can get with this before you hit the limits of the stock hardware. I know the MAP sensor is limited to something pretty close to the stock boost.

[johnb]

I had a look at the xdf file that someone posted earlier for the KLR. It has locations for the CV open loop map and target boost map that I can confirm are definitely correct (0xB00 and 0xC00 respectively).

I have a breakdown of the rpm ranges used in these maps here: https://jhnbyrn.github.io/951-KLR-PAGES/rpm_axis.html

Those 2 maps are 2-axis maps - RPM and throttle position.

The xdf also correctly identifies the location of a one-axis (rpm only) map for wide-open throttle angles for 8 different RPM ranges (this map is one of 12 rpm-only maps that I wrote about in some detail here: https://jhnbyrn.github.io/951-KLR-PAGES ... tants.html). Maybe they experimented with different WOT angles for different RPMs but then in the end they set them all to the same value (I forget the exact angle but it's in the DME Test Plan document. Anyway if you did want to change it you'd need to update all 8 values here.

There's some stuff in the file about Dinan mods that I haven't had time to look into.

When it comes to defeating overboost protection, maxing out all the cells in the map does create the possibility that you'll hit the "boost too low" error for lower rpms. I honestly have no clue why they considered this a condition that required limp mode, but there you go. I suppose turbos and electronic control were all kind of new at the time and they didn't have everything figured out. Maybe the best solution is to leave the maps alone and just remove the logic that triggers the error code from either over or underboost. I'd have to do a little digging to refresh my memory on that but if anyone is interested I can do it.

[Tom]

I had a look at the xdf file that someone posted earlier for the KLR. It has locations for the CV open loop map and target boost map that I can confirm are definitely correct (0xB00 and 0xC00 respectively).

I have a breakdown of the rpm ranges used in these maps here: https://jhnbyrn.github.io/951-KLR-PAGES/rpm_axis.html

Those 2 maps are 2-axis maps - RPM and throttle position.

The xdf also correctly identifies the location of a one-axis (rpm only) map for wide-open throttle angles for 8 different RPM ranges (this map is one of 12 rpm-only maps that I wrote about in some detail here: https://jhnbyrn.github.io/951-KLR-PAGES ... tants.html). Maybe they experimented with different WOT angles for different RPMs but then in the end they set them all to the same value (I forget the exact angle but it's in the DME Test Plan document. Anyway if you did want to change it you'd need to update all 8 values here.

There's some stuff in the file about Dinan mods that I haven't had time to look into.

When it comes to defeating overboost protection, maxing out all the cells in the map does create the possibility that you'll hit the "boost too low" error for lower rpms. I honestly have no clue why they considered this a condition that required limp mode, but there you go. I suppose turbos and electronic control were all kind of new at the time and they didn't have everything figured out. Maybe the best solution is to leave the maps alone and just remove the logic that triggers the error code from either over or underboost. I'd have to do a little digging to refresh my memory on that but if anyone is interested I can do it.

If you had an interest in doing that (remove the logic that triggers the error code), that would be awesome. My emerging goal with all of this is to put out a tuning guide that fills in some of the gaps with the current info that's out there, but also offers a few off-the-shelf performance BINs people can download and use for free. With the exception of Vitesse, I get the sense that many performance chips currently available are mostly just re-hashed versions of public domain info (e.g., max out overboost maps, add a little fuel to the WOT maps, scale it for 3 bar FPR if needed, add a little timing, and that's pretty much it). I fully support companies like APE, Dinan, and Vitesse that do their own R&D and then build that time and effort into their pricing, but I cringe a bit at the thought of people charging hundreds to burn a chip with the basic maps available all over the internet...

[johnb]

OK so I spent some time reading the code and refreshing my memory and I see an easy way to do this. In the PID routine, a boost error value is calculated and stored (i.e. target boost - actual boost). In addition to being used for the PID logic, it's also used later to check for over/underboost conditions.

We can just replace the boost error value used in the error checking routine with 0, so that the error will always be zero, but everything else will function exactly as before.

I'll post a more detailed explanation later, for future reference. But right now the hard part is: how will we test it? When I was working on this stuff before, I set up a bench test with some signal generation, a mityvac, scope etc. and I was able to trigger the under and overboost error conditions on demand. I never heard of anyone actually seeing them in the wild, probably because DME overboost kicks in first, and anyone who has disabled that has probably also disabled KLR boost control.

I can dig out that setup and test it all on the bench again. First I'm still remembering which tools I used to assemble my BINs in the past, and how I tested them. I know I created a crude adapter that allowed me to use a modern flash chip, but I also bought a few legit salvaged Intel EPROMs that are an exact match for the one used in the KLR.

Stay tuned!

[Tom]

Hmm... if we maxed out the DME BIN's overboost table-- to defeat it entirely -- we could induce the KLR error code on a real car with a stock KLR chip, and then confirm you've eliminated the error with your new edits. Now, the only issue is where we can find a car that still uses the cycling valve to control boost, and that's owned by an EE all set up to burn chips. @whalenlg would seem to fit that description to a T. If burning the chips is a pain, just post the BINs. I have my Amazon burner all set up sitting next to my keyboard, and plenty of EPROMs courtesy of nearby Jameco electronics.

[johnb]

OK here goes. Stock 1987 KLR bin file with over/underboost error handling removed (I think) is attached.

I'll post some screenshots of what I'm doing here for the sake of documentation for anyone who's interested. I'll put something more comprehensive on my KLR site later, or here if anyone wants.

First here's the most relevant bit of the original code but with my comments to explain what's going on

Screenshot_2025-08-31_21-13-05.png (203.75 KiB) Viewed 2395 times

Now I can't assemble it from that version because I have added those hex addresses in the column on the left to help me keep track of things. Here's the original on the left and the change I'm making on the right:

Screenshot_2025-08-31_21-29-31.png (36.06 KiB) Viewed 2395 times

So instead of loading the boost error (that was calculated elsewhere in the PID routine) into the accumulator, I'm just setting the accumulator to zero. So the error routine now thinks the boost error is zero. It gets loaded twice so I changed both.

Double checking the assembled BIN file to make sure my change is what I expected:

Screenshot_2025-08-31_21-28-53.png (35.44 KiB) Viewed 2395 times

That 27h is indeed the opcode for "clr a".

If anyone is in a position to test this that would be really helpful. Obviously the usual use at your own risk must apply but I can tell you I didn't make any other changes, and I'm very confident that this change does only what we discussed in the lat few posts, for what it's worth.

[Tom]

OK here goes. Stock 1987 KLR bin file with over/underboost error handling removed (I think) is attached.

I'll post some screenshots of what I'm doing here for the sake of documentation for anyone who's interested. I'll put something more comprehensive on my KLR site later, or here if anyone wants.

First here's the most relevant bit of the original code but with my comments to explain what's going on


Screenshot_2025-08-31_21-13-05.png


Now I can't assemble it from that version because I have added those hex addresses in the column on the left to help me keep track of things. Here's the original on the left and the change I'm making on the right:


Screenshot_2025-08-31_21-29-31.png


So instead of loading the boost error (that was calculated elsewhere in the PID routine) into the accumulator, I'm just setting the accumulator to zero. So the error routine now thinks the boost error is zero. It gets loaded twice so I changed both.

Double checking the assembled BIN file to make sure my change is what I expected:


Screenshot_2025-08-31_21-28-53.png


That 27h is indeed the opcode for "clr a".

If anyone is in a position to test this that would be really helpful. Obviously the usual use at your own risk must apply but I can tell you I didn't make any other changes, and I'm very confident that this change does only what we discussed in the lat few posts, for what it's worth.

You are awesome! For anyone with a stock car who is willing to test this, I'll gladly send you a Carpokes-special DME chip and a KLR chip with this image. We'd just need to find a way to bump boost up while still using the cycling valve -- such as a restrictor in the boost bolt.