not exactly the right thread for this but flashhack and eehack are written with modern QT libraries and XP is 20 years old. QT no longer supports XP, so neither do i. you will find most software...

modified in what way?

i am just reading about bootstrap mode and it's really interesting, i think i can help get this working.... and might be way easier than i thought

is this correct?

- ground MODB to enter...

just out of curiosity, is there any way to bootstrap the chip over the regular ttl serial pin that aldl uses? or is it a different pin entirely

in other words can you upload the bootstrap program...

yeah you cant apply vpp from the eside at all
back to my original thought
bootstrap the dead side with the entire kernel then just let flashhack do its normal thing over aldl. no need to bootstrap...

it just seems like i've done a lot of work that would assist and save you time. if you get this thing booted up and communicating with my slightly customized kernel, we can kick it out of bootstrap...

really nice work so far, just trying to figure out how it works,

i would have assumed you could just bootstrap it with the existing flash kernel and then once it's booted, just run a flash...

yeah, completing a sequence for the tester is pretty much why it's there. before sending any mode 6 requests, the tester is supposed to send a mode 5 request, and the ECM either replies 05 AA or...

oh, yeah! that's a good point! in my case while running the kernel, i always know what that first byte of a routine or subroutine is since i uploaded all of them. i can easily abuse this to save 2...

i do agree and observed it crashes although it's nice to have a theory why

in practice sending a 7E jump only incurs 3 extra bytes of overhead, so that's what i ended up doing in flashhack
...

yep, or in other words just to tell the tester 'wait until next message'

in practice, the only code that seems to use it is the erase routine (being the only code that could potentially run long...

i've experimented with overwriting a region before (somewhat by accident, when my block mapping had a bug) and i agree that it does effectively AND, which is handy if you're writing a bunch of blocks...

thanks so much for doing that, that's very detailed. definitely fills in a lot of blanks that i never understood before.

if we need to standardize we should try to stick with what is already in use if possible, that way tunercat/jet dst bins will also work with whatever we do instead of having to convert between...

i don't have a car
from memory it sets that obd-ii code called random misfire

i dont know if the DTC is separate from the misfire detection code flashing the check engine light...it does both

the crank sensor on these engines is only there to feed the OBD-ii misfire detection requirement. it compares the cam and crank angles i suppose and if they're too far off it figures there's a...

i'd be doing some disassembly at this point.. you have a lot of input now to label some things, and track those back to identify the code responsible for them. there are lots of things you wont be...

we have often suspected this is possible

would love for someone to try or get more details/theories on how

i just got what i think is a 'bricked' 1996 ecm so i'm going to try to bring it back to life and help a bit with this research too.

i'd start here and try to find what that Tom H fella has done

http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7677-1997-F-Body-ECM&p=78791#post78791

so i've never seen an XDF specifically but i swear i did see someone had damn completed a disassembly on here. i never plan to tune one myself so i wont be much help with the XDF but i do plan to...