3P's TCCS Disassembly/Analysis
- Thread starter 3p141592654
- Start date
I've recently received the chipped JZA70 ECU. The mines board is based on 74xx series of ICs:
The board is being reversed:
Also, I've found some rare ECU from ST205 Celica with EEPROMed version of MCUs:
The 4-bit Fujitsu (detonation DSP) MCU was decapped. I'm waiting for an access to a good scope to read out the maskrom.
And the last news: the Toshiba MCU after decapping. Microscope photoes are pending.
The board is being reversed:
Also, I've found some rare ECU from ST205 Celica with EEPROMed version of MCUs:
The 4-bit Fujitsu (detonation DSP) MCU was decapped. I'm waiting for an access to a good scope to read out the maskrom.
And the last news: the Toshiba MCU after decapping. Microscope photoes are pending.
Attachments
Last edited:
Is there going to be another run of parts needed to program the stock TCCS system?
Otherwise I will be picking up a MS3Pro Ultimate Standalone shortly.
My build should be progressing quickly as spring comes around.
Trying to find out if the programmable TCCS system is going to happen or not.
Otherwise I will be picking up a MS3Pro Ultimate Standalone shortly.
My build should be progressing quickly as spring comes around.
Trying to find out if the programmable TCCS system is going to happen or not.
I’m really interested in this as well. I have an 87 7M-GTE 5spd that I’d like to run a 57mm CT and stock injectors or RC 550’s. I have a 1UZ AFM housing I could use as well if necessary. I’d love to have a tuning option like this more similar to Accessport or DSMLink.
Sometimes I rethink this. I want to remove some of the safety margin with heat. In addition to the 550s and Boss Jr with the 1UZFE meter. My car also idles and drives like normal, but I don't have the screw all the way out like some do.
Wow @3p141592654 just dipping a toe in this... would it be too much to ask for an overall synopsis of the project and 2022 status update?
Some awesome work from what I have seen with a quick peak-
Some awesome work from what I have seen with a quick peak-
There are a couple of beta testers out there using the ECU. What that pointed out was that we were not ready for this to be a product yet. I've been working on improving the documentation and software delivery but still need to implement a solution to get past the current load variable maxing out at 133% of stock fuel cut.
Well... if/when you get it worked out, put me down on the interested parties list, I would definitely be a customer.
@3p141592654 thanks for linking me on supra forums. I read the first 3 and last 3 pages of this thread and will continue to read more. From what I have read, I would also like to purchase a unit when they are ready. I can do some cad design/drawing work if you are trying to get enclosures made (printed/machined). I have already done a couple 3d printed parts for my mk3 like cup holder redesigns and door lock covers. Not looking to make money as my day job is adequate.
Hi 3P, I'm curious, why not implement some scaling if you cannot bypass this number? Or defeating the stock fuel cut, and adding something else to to provide a cut later.
No reason except time and effort 
Its all in assembler so changing things is not easy, but certainly possible. It is my plan for some time to do it. Defeating fuel cut is trivial, but if you max out the load variable then the injector duration will hit a hard stop while air flow continues to increase. A recipe for a blown engine.
Its all in assembler so changing things is not easy, but certainly possible. It is my plan for some time to do it. Defeating fuel cut is trivial, but if you max out the load variable then the injector duration will hit a hard stop while air flow continues to increase. A recipe for a blown engine.
keeping an old thread alive, i've been starting work on a Ghidra processor model/decompiler.
from the TASM assembler used. i've really got my doubts as to the opcode 0x31 being a JSR to a ( what i'm calling zero page ) address ie JSR $0066 being encoded into 2 bytes only.
its second byte, is listed as $*, and thats normally fine for vars, as it would likely be RAM, rather than code. and its not a short JSR, as that is handled by BSR ( 0x61 ).
So has anyone got the ability to write a little test code, and confirm it really jumps to the addresses in the first 256 bytes of memory ?
Darryl
from the TASM assembler used. i've really got my doubts as to the opcode 0x31 being a JSR to a ( what i'm calling zero page ) address ie JSR $0066 being encoded into 2 bytes only.
its second byte, is listed as $*, and thats normally fine for vars, as it would likely be RAM, rather than code. and its not a short JSR, as that is handled by BSR ( 0x61 ).
So has anyone got the ability to write a little test code, and confirm it really jumps to the addresses in the first 256 bytes of memory ?
Darryl
Last edited:
Hi all, please ignore if not useful. I'm on the verge of launching a project to re-write the entire 7M-GTE ECU in Simulink - the coding language every major OEM uses for real-time machines nowadays; such as ECUs for road and racing cars. My aim is to create a testing harness which can stimulate the ECU with every condition known to man, to read out the plethora of maps specified in this post. I believe someone highlighted there are 20 map variations, depending on coolant temperature, for instance. I have a long list of ideas on this, but in short, my aim is to facilitate a replacement ECU, which enables things like CAN, OBDII, configurable digital dashes and all the other niceties which come with modern ECUs.
This thread has been an absolute pleasure to read - so I just wanted to recognise everybody's contributions on this project. It is truly incredible.
This thread has been an absolute pleasure to read - so I just wanted to recognise everybody's contributions on this project. It is truly incredible.