Quote Originally Posted by Tom H View Post
1. GM has an unpopulated connector on both the TSide and ESide boards that I have mentioned. This permits an auxiliary computer to be connected to the system. The way it works is very tightly coupled with the software and hardware used. The auxiliary computer puts ram in a memory space that is not used by other chips on the boards. When attached it initializes a tag that software looks at to establish if there is this added computer. There is then a bunch of handshaking between the two software (aux and PCM). Once complete the aux is given a time slice (I don't remember the time or rep rate at the moment). This allows the aux to get in, read whatever and return the address space to the PCM CPU.
To give an idea of how large this was, the PCM code that runs it resides above the calibration (TSide ends at $4326) and below the operational code (TSide starts at $4E8A). So that's about 3000 bytes. For the ESide the size is similar. It includes canned routines to access TPU registers. I have some of this documented but it is quite difficult without seeing an example of the hardware used.

While I believe this is what GM used, there are other possibilities... The DLC can run at 40Kbps. That's not fast but the PCM can be set to monitor with repetition thus eliminating the request/reply sort of protocol.

For ALDL you are stuck with 8.192 kbps if comms is to take place with the other modules.

2. The architecture used is not compatible with DMA. There needs to be some sort of handshake with the bus master (CPU) for DMA to take over the bus. I believe this was never part of the design.

3. In the '97 PCM I think the fastest you will get is through the class 2 interface. Using a mode $2A, up to six PIDs can be requested. There is an option to repeat at up to 25ms intervals. To keep this up as you would when logging, you must send keep alive/device present messages $3F such that the operation doesn't time out.

-Tom
I’m coming back with a few more questions :

1. I clearly missed some of your notes regarding this topic in your previous threads, but I understand your explanation, very interesting. Too bad there is not more GM calibration documentation floating around like you can find for the early EECIV Fords. Maybe one of these development ecus will show up on ebay one day...

Over the weekend I came across an add on board for the LS1 ecu called "Real Time LS1" from a company in Australia which sounds similar to the interface you are describing. I may ask these guys if they ever offered (or considered offering) their interface for the LT1 as it would appear that they have been around for a while.

If the DLC can run at 40Kbps that sounds reasonable fast. Is this that standard protocol i.e. TECH2 class 2 interface at 4x, or would this involve some code modification in the ecu ? Also would this mode allow for specific memory addresses or PID’s or just those available in the TECH2 ?

2. Let me clarify my question as my terminology may have not been correct. I meant to ask is there a way to log directly the RAM memory addresses as opposed to the receiving the preset message packets intended for the TECH2. Steveo mentioned in his post on this thread that he trimmed down the message on the $EE to improve the data rate using his software, I imaging you can also replace some of the standard parameters in that message on the ECU side ?

3. If I understand correctly the scanning side of the LT1 should work the same as it would with a LS1A or LS1B. I went back through your posts on the 1997 F-Body ECM thread pg. 29 which go over the 2A mode as well as some other addressing modes. Assuming this ecu should communicate with the LS1 logger in Universal Patcher, then I need to do a bit more homework to understand how that software works, i.e. are the PID’s common for all LS1 computers and if so are they also common for the LT1 i.e. LS1 PID’s same as LT1 PID’s ? If not, I need to figure out how to find them.

To your last post, do you actually have that working on your bench? If so that’s pretty cool. A cruder way I suppose it could be done is using a pair of emulators like the Moates Ostrich at least for editing the ROMs.