hi,
im looking for a XDF for the E34 525 TDS auto
I have original roms and a non-working re-mapped rom read from a tuned chip (maybe some cksum missing or for manual transmission).
the bosch number is 0 281 001 295 on the ECM, it has two 256 chips and they are number 2 537 355 404 and 2 537 355 405
I have a ECM 2K1 driver as well, but dont know how i could convert it to xdf...
any help greatly appreciated.
cheers,
simon
looking for XDF for DDE 0 281 001 295
Moderators: robertisaar, dex
actually i figured it out, just mimicked the map addresses etc from ECM by looking at the bottom of the screen 
I still get a no-start condition on my car. injector light on and transmission light shows up.
I used ST M27C512 150 ns roms to replace the stock 27C256 200 ns ones.
I stacked/doubled the roms before burning so that the bin is in there twice and checked by reading back from rom. all verifies out fine.
is it possible the DDE can not read from the M27C512 roms ? they should be pin compatible to the 27C256 right ?
And with doubling/stacking the image in the rom, the address line should not matter, atleast i thought.
I FF'd out the supposed checksum offsets by ECM, as in the original stock ROM's they were also FF FF. Maybe this is my mistake, but then again, why would the checksum only be present if tables are modified ? I would be expecting a checksum always then....
I still get a no-start condition on my car. injector light on and transmission light shows up.
I used ST M27C512 150 ns roms to replace the stock 27C256 200 ns ones.
I stacked/doubled the roms before burning so that the bin is in there twice and checked by reading back from rom. all verifies out fine.
is it possible the DDE can not read from the M27C512 roms ? they should be pin compatible to the 27C256 right ?
And with doubling/stacking the image in the rom, the address line should not matter, atleast i thought.
I FF'd out the supposed checksum offsets by ECM, as in the original stock ROM's they were also FF FF. Maybe this is my mistake, but then again, why would the checksum only be present if tables are modified ? I would be expecting a checksum always then....
is there anyone who could help me with this ?
The Checksum that would be required is supposedly "type 54" in ECM, OLS270 in WinOLS and "E41" in Race2K.
I couldnt figure it out yet for replication.
This is the so called diesel DDE2 / DME, some opel variants use it too.
Race calls it "Early EDC DIL".
I can supply working stock ROM's for analysis.
Would a good approach be to use Hit window feature of ostrich while loading stock rom ? I think checksum must be something which is checked as soon as posweron for verficiation, right ?
ECM lists checksum offsets 7D00 but that doesnt seem correct as stock rom is FF'd in this offset.
i would be more than happy to post XDF to share once its done....
The Checksum that would be required is supposedly "type 54" in ECM, OLS270 in WinOLS and "E41" in Race2K.
I couldnt figure it out yet for replication.
This is the so called diesel DDE2 / DME, some opel variants use it too.
Race calls it "Early EDC DIL".
I can supply working stock ROM's for analysis.
Would a good approach be to use Hit window feature of ostrich while loading stock rom ? I think checksum must be something which is checked as soon as posweron for verficiation, right ?
ECM lists checksum offsets 7D00 but that doesnt seem correct as stock rom is FF'd in this offset.
i would be more than happy to post XDF to share once its done....
ok i figured out more some more about the the checksum with some help from someone who has a calculator in ols for it.
the checksum is 1 byte and in the final byte of rom and it takes into account 0x0000-0x7FFE
however still not sure on the actual checksum calculation.
a rom filled with 00's checks out as checksum 00, a rom filled with FF checks out wiht checksum FF.
if i increase a value in normal rom by 1, checksum decrements by 1 or 2, depending on what row I am in.
looks like this
position 1= decrement by 2, position 2= decrement by 1, position 3=2, 4=1,5=2,6=1,7=2,8=1,=9=2,A=1,B=2,C=1,D=2,E=1,F=2
any clues if this is just an outcome of a math algorithm that im not seeing here ?
looks like a poor mans parity
once i got it figured out id be more than happy to post a DLL for this, if access to a SDK or similar is possible.
cheers,
simon
the checksum is 1 byte and in the final byte of rom and it takes into account 0x0000-0x7FFE
however still not sure on the actual checksum calculation.
a rom filled with 00's checks out as checksum 00, a rom filled with FF checks out wiht checksum FF.
if i increase a value in normal rom by 1, checksum decrements by 1 or 2, depending on what row I am in.
looks like this
position 1= decrement by 2, position 2= decrement by 1, position 3=2, 4=1,5=2,6=1,7=2,8=1,=9=2,A=1,B=2,C=1,D=2,E=1,F=2
any clues if this is just an outcome of a math algorithm that im not seeing here ?
looks like a poor mans parity
once i got it figured out id be more than happy to post a DLL for this, if access to a SDK or similar is possible.
cheers,
simon
well turns out i was mistaken. it was easier than i thought once i looked at it in detail. i just hacked it together. stay tuned for a plugin dll.
<?php
$filename = "filename.bin";
$handle = fopen($filename, "r");
$size=filesize($filename)-1;
$cksum=0x00;
for ($i=1; $i<=$size; $i++){
$contents=intval(bin2hex(fread($handle, 1)),16);
for ($x=1; $x<=$contents; $x++)
{
$cksum--;
if ($cksum==-1){$cksum=255;}
}
}
fclose($handle);
$ckoutput=sprintf("%02s", dechex($cksum));
echo "CHECKSUM".$ckoutput."\n";
?>
<?php
$filename = "filename.bin";
$handle = fopen($filename, "r");
$size=filesize($filename)-1;
$cksum=0x00;
for ($i=1; $i<=$size; $i++){
$contents=intval(bin2hex(fread($handle, 1)),16);
for ($x=1; $x<=$contents; $x++)
{
$cksum--;
if ($cksum==-1){$cksum=255;}
}
}
fclose($handle);
$ckoutput=sprintf("%02s", dechex($cksum));
echo "CHECKSUM".$ckoutput."\n";
?>