I've been playing around for some time now with my Fiero's ECM, trying to create a scantool program for use on a laptop. One of the things that was causing me head-aches was trying to decipher the bit-stream coming from the ECM. I had found several websites that explained it, but for some reason my ECM was giving a different stream than I found on these websites. It took me a while to figure out what was "wrong". The cable I made for reading the ECM was actually shorting two pins... When I corrected this, I got the expected stream. Happy I finally was able to read some basic data, I left it at that and continued working on my program.About three weeks ago, I was working on some new features for my digital dash, and was experimenting with a new processor chip from Atmel, the AT95S776T. It's a four pin processor that uses some very smart tricks to generate parallel data over just two lines One pin is used as a "free-floating oscillator" (FFO), the other to send the actual data. The idea is that the oscillator signals byte-ends. While high, you simply "record" the data pin. A high/low transition signals the byte end. Compare the previous recorded data with the current data, do some bit shifting against a CRC and you have a full 16-bit word. If you look at the data pin, you will notice that you have a lot less transitions than you would have with ordinary data-lines (like I2C or RS232). It looks weird on a scope (you are so used to seeing transistions per bit sent) but it makes perfect sense.
Now this is where it starts to get interesting.
While I was reading the datasheet for this processor, I found a table that displayed a typical free-floating block of data. And I recognized it instantly: it was identical to what I was getting earlier from my ECM! I immediately got myself a spare ECM and started experimenting. I shorted the two pins I had accidently shorted before and started looking for the oscillator pin. Turned out there indeed was a pin (marked N/C in the official datasheet) that was behaving like an FFO!!!
I quickly wrote a little program that would display the FFO data. Most of the data I got was similar to "normal" ECM data, but I also got twelve new parameters and I couldn't figure out what it was.
Fortunately, FFO-data transmissions are bi-directional (you simply force the oscillator low during a chip-reset) and I started feeding the ECM with random values for these 12 parameters. The chip kept running so it was actually accepting them! Since this ECM was sitting on my desk, I had no idea how my ECM in my car would respond. Needless to say that the next day, I was taking out the center console of my car... 
The first time I sent random values to my ECM, nothing notably happened, other then some weird fluctuations during idle. Only later that day I realised this old chip couldn't handle 16-bit words (duh!) so I started sending 7-bit bytes instead. And I can only say I'm still completely and utterly amazed after finding out what these parameters did... There are still 5 parameters that don't seem to do much, but those remaining 7... Oh my gawd! Let me sum up a few differences I've noticed in the last few days with the new settings:
- 0-60: 7.9s constantly (previously 9.2s)
- Topspeed: 132mph (previously around 120)
- Max RPM now 6600 (couldn't get it past 5500 before)
I need to get my car dyno'ed soon! And the best part is: This mod can be done in about 30 minutes! (you need a laptop)
I need to run some more tests (don't want angry forum-members with blown engines) but as soon as I'm done, I'll release full documentation on how to do this mod!!!
, but it sounds interesting.