I wanted to start this thread to hopefully replace the much
maligned previous thread that started this whole project off.
CURRENT SUMMARY
To summarize, yes, we are working on a non-EPROM conversion for the early (pre-1997) 3000GT platform. This would include the M37793 and M37798-based boards found in the '91-'96 3000GT ECUs. The M37782 processor found in the 1997 ECU would not be supported.
Here's a photo we posted back in May 2009 showing what this thing looks like.
This board physically installs much like our
1G DSM non-EPROM conversion board does. But the similarities end there. The technical side of this board is SOOO MUCH more complicated.
As of May 2009, we do have a semi-working prototype that does pass all our basic tests. Unfortunately, we have been absolutely swamped since then and have had exactly ZERO time to work on this. We're really sorry, but that's the reality of our situation.
We do plan to complete this project. We haven't dropped anything. We've just been completely unable to get back into it like we had hoped. We'll keep this thread updated as best we can when we get time to get back into it.
A LITTLE HISTORY
The early model 3000GT VR4 ECUs were all produced with the code programmed permanently into the processor. This meant that you were entirely unable to reprogram these ECUs yourself in any way. TechTom had a
non-EPROM conversion board a long time ago that sorta solved the problem but had several other issues.
Pulling the code out of the processor and putting it into EPROM space allowed you to make modification to this code and/or tables yourself. However, the TechTom approach cost a small fortune and they scrambled the code in the EPROM. In addition, they used two 8-bit EPROM chips instead of one so their job of simulating a 16-bit data bus to the Motorola 65816-style CPU was made easier.
So even if you descrambled the code (which really wasn't all that difficult to do), you were still forced to work with this dual EPROM image thing which make real-time emulation much more difficult and/or expensive to pull off.
This whole project started off with someone asking us if we'd consider doing a full port of our ECMLink application over to the 3000GT platform. We knew full well we would never have time to complete that, so we kindly declined. However, we felt that we could do a non-EPROM conversion board similar to the TechTom board but without all the crazy issues associated with it. We just didn't know (and still don't know) how long it was going to take to get something like that to market. But nobody else was answering the call and we felt the 3000GT platform needed a little love, so we took the project on.
WHAT'S OUR BOARD DO?
Our goal is to produce a non-EPROM conversion for the early 3000GT platform that would be compatible with the
Ostrich real-time EPROM emulator. This was not practical with the TechTom board for the reasons mentioned above.
By producing a non-EPROM conversion board for the 3000GT ECU that was compatible with the Ostrich, we would basically be opening that ECU up to modification like so many other (native EPROM) ECUs had been before it on other platforms. The users would simply need a definition file for their ECU and a couple off-the-shelf and/or free programmer/logger software packages and they'd be set.
The entire package would basically be:
- Non-EPROM conversion board
- Ostrich real-time emulator
- TunerPro or equivalent tuning package
- Definition file to feed into Tuner-Pro that defines the various tables and such that the user could edit.
- Logger and logging cable
Our primary job is to provide (1) above. We really did not want to get into (3), (4), and (5) but if we really had to, we'd probably do those too. At that point, we'd probably just offer complete tuning packages all wrapped up in one neat little bundle.
But the first step is getting (1) done. And that's where we're at now. We're trying to complete that first critical step. Without it, the rest has no place.
WHAT CAN YOU DO WITH THIS?
Well, that's a big question. The quick and easy answer is to change anything and everything the factory ECU has control over. That includes injector scaling, basic MAF compensation (to run an EVO8 MAF for example), fuel and timing control, etc., etc.
The problem is that you need to find where and how the factory ECU does stuff and then write the definition file for your tuning package. That's really not too hard and should be quick work for anyone with the real desire to do so. And once it's done, everyone can use the same definition files to do the same editing.
Doing stuff above and beyond what the factory does will require a bit more work. It's not always difficult work to implement new features (a launch stutter box, for example, is really only 10-20 bytes in length). The problem is in management of these modifications and in defining newer and more complicated modifications (full time speed density, for example).
We can provide the basic functionality (injector scaling, MAF compensation, etc.). But we really can't get into too many of these custom modifications. They get really complicated and timing consuming really quickly. And, honestly, we'd rather leave the entire definition side of things to the user community anyway.
3000GT EPROM conversion board
