Yes, all the info that I have says it is a MC68HC11F1 GM variant.
I think you might be looking at the 4 cyl. MPFI code section of the mask. That application uses the GM DIS module which requires a crank position signal that is input to the PCM seperately from the DRP's. This is the next project after PFI, making DIS work on a V-8.

I have not actually gone through and gotten a handle on how EVERYTHING works, only small chunks here and there such as the Manifold tuning valve control, A/C clutch control, etc., stuff that can be easily modified to control other hardware and the PFI stuff I am still going through at a snails pace.
Yes, Edelbrock has been selling a port manifold setup for the '7060 as well as the '7747 and other TBI ECM/PCM's, all of which run on TBI injector firing strategies which is why many people complain of idling problems. I have several of the Edelbrock .bins and even the later ones for the PCM's which have PFI batch fire code in the mask use TBI strategies. Grumpy, I am aware of the post on the FSC board and I have the NETRES info to change the operating mode. I realize that Ken from HPTuners has done this already for the $0E mask, I am just trying to duplicate his efforts for the $0D and $31 masks and document it for the masses.

 

If Im not mistaken, its also used in the $0D while in crank to control the crank PW and transitioning AFR. In that, though, a status bit causes the cam sensor stuff to be skipped. One thing I wonder is what generates the interrupts to make it work. Is it maybe the crank signal and DRPs that do it?

 

Ok, so I got the new computer a few weeks ago, last week I picked up the red/blue pigtails that fit the 8625 and I had a spare (dead - IAC controls shot) 7747 ECM lying around on the shelf, so I desoldered the 7747 connector and made a 7747-->8625 adapter harness.

I also cut the chip off of the memcal and soldered in a Zif and installed the ostrich.

Saturday I went to install all this and *for reasons beyond me* my distributor decided to die.

So another trip to the junkyard, picked up another distributor and another module from a 4.3 Jimmy

Put the new dizzy in and re-timed the truck today, reconnected the injectors and the truck fired right up, whoo!

Now I gotta get datalogging working and figure out which 5.7 bin runs best. I've got a mastach serial aldl cable and was trying to use the 8625 .adl file someone posted up here and couldn't get it to work with tunerpro, gonna try datamaster when I get home from work tomorrow.

 

I started with BJRD. Datamaster is fantastic!

 

Ok, got datalogging working....


Come to find out a couple things:

1) Both Tunerpro and datamaster give errors if your yellow wire going to the aldl interpreter board is broken (Tx Data for those who care)

2) Datamaster will tell you that your aldl cable works and can't find an ecm if you have ALDL Pins A (Gnd) and E (data) connected, but not B (serial data enable). So, the 7747 needs A & E, but the 8625 needs A, B and E to communicate

3) Datalogging at ~8-10 frames/second is WAY SWEETER than a frame every ~1.1 seconds like the 7747 puts out.

Now I need to take some more pics, pay godaddy and get the info on my site up...

 

I've only ever had A and E connected, no probs... Have used it with both a Moates USB cable, and a Mastach 9 pin serial

 

Weird...I'm using a mastach 9 pin serial cable and couldn't get anything till I connected B, now that B is connected everything works peachy.

 

I was checking this out. Actually, only about 300-400 bytes are usable as the PROM is mapped on top of the rest of the addressed hardware. The rest where other things like memory, CPU regs, etc. would be is dead space. There is also something at where the internal EEPROM would reside, and some engineer comments/conversion params. or something to that effect out in the middle of nowhere in the PROM.

On the hack side, Ive been chugging away at it for an hour or so a day and Ive gotten about 15% of it done. Maybe if I dont come down with the worlds worst case of carpel tunnel (between this and work Im starting to have some problems), I might have it done by the fall. I figure by that time this heat wave will have finally broken so I can put another trans in the car and start using it again.

 

I don't know much about this lower level stuff, but i'm learning quickly...
The first 4k is all FF's if i remember correctly, can that be used for anything??

 

Might be wrong, but as far as I can tell, aside from whats at the location that the EEPROM would be at, the first 16K is nothing. After that, the actual calibration/code starts and runs to the end of the chip, with some 0's here and there. I would ASSume that the first 16K is non-addressable and the prom is disabled when these address are accessed. Above this, the prom is enabled and the code section is run. IOW, all that free space is in fact space you cant touch as the addresses are already taken by the RAM and hardware in the CPU.

 

Yes the first 16K is RAM, external hardware, and CPU regs and is not usable but there is two good size chunks of space that can be put to use. From the end of the calibration at 6B82 to the start of the algorithm at 7200, i.e. 6B83 to 71FF, is open and from FB49 to FF8F is also free. Combined, these two chunks are nearly 3K which is aproaching the size of the entire PROM in the early TBI ECM's. Sometime in the future I plan to put this space to good use. I feel you about the heat. Texas in the summer is like the northern states in the winter. The weather does not permit much time to get work done on projects outdoors.

 

Oh, ok, so theres more unused space then I thought. 3K could potentially hold more code and tables tehn the computer can execute with the existing code thats there.

 

duh... I thought you where talking about the space at the very start of the prom. Yes, as said above, this is addressable and unused.

 

Going through the spark minor loop and man, there is alot of cool stuff in this thing. They even have a proportional control routine meant for use with manual transmisisons. It uses the SA to control the rate that the rpms can change, probably to limit bucking when a manual is used. That should come in handy with the TKO.

Definatly underscores the need for us to go through this thing and pick it apart. The current hacs dont really even seem to scratch the surface.

 

You are a LOT better with the code than I am....

I will be very interested to see what you find when you get into the TCC stuff.. I kow there is an option in there to allow the PCM to to operate the TCC in a 700r4 (as opposed to the intended 4l60e), but I have been having trouble working out exactly what conditions it wants to lock it...
I have tried to follow the code, but it jumps evereywhere, and my knowledge of this stuff is limited...

 

The code is hard to follow. It literally does jump everywhere since most of it is driven by interrupts. Doesnt flow real nice like the older codes in the C3 ecms that flowed in one, uniform manner. In these, alot of the code can run at any time if an interrupt from a dist. ref. pulse, VSS pulse, etc. occures.

Im still nowhere near the code for the TCC so I have no idea, either...

 

Indeed, lots of interupts and even more subroutines. Every little function is covered by a subroutine. I wonder if it was due to a change in high level development programming languages and what we see is a difference in decompilers to the assembly. Just speculating, I could be f. o. s., but this PCM mask seems to resemble the later OBDII stuff more than the earlier TBI and TPI ECM masks.

 

Oh yeah, those subtroutines. Even better. Nothing like having to bounce all over the place while your trying to go through it

My impression on this is similar. It was done in a high level language while the earier stuff may have been done in assembly. The TBI ecms definatly where done in assembly. Not a drop was wasted in those computers. They used all the little tricks to save time. This one all the routines have a cookie cutter type of format, and there is alot of redundancy and some wasted time, and definatly some wasted prom space, but they seem to have more of that then they knew what to do with.

I was on an LS1 site trying to get some info and one thread was discussing adjustments to the line pressure and low and behold, the tables there where identicle to those in this PCM. My guess is that the last of the 8 bit PCMs probably served as the template for the later stuff. It sure is a departure from what they where using previously.

It brings up the possibility that a hac could be done for one of the later pcms, but it would be a real pain in the ***. The programmers reference manual for the 32 bit MPUs is like 700 pages long, and thats just for the instruction set only. That and motorola wasnt nice enough this time to give the machine code to go along with the pnemonics. Guess they dont like people reverse engineering their stuff.

 

Is it possible that the core of this thing runs at ~8 MHz and not the advertised ~2 MHz that the ref. manual claims? The hacs seem to scale per the MPU core speed. The origional C3 codes are ~7k lines, the 165 stuff is ~14k lines, the 730 is ~28 k lines, while the PCM stuff is ~48 k lines. Speed is definatly the limiting factor with these, and theres no way 50,000 lines can be run on a ~2 MHz budget.

Might just be me, but it seems GMs been slipping a little extra power under the hood of ther later stuff.

 

On the other hand, I know the free running counter runs at 131 kHz. Putting the speed at ~ 2 MHz with a divider of 16. The older tbi comuters could barely manage one minor loop and real time subroutine. Yet this one seems to manage 8x the work with only a 2x bump in power. Not only that but theres all the wildcard stuff like the reoccuring code run on every DRP. Thoughts?

 

really out in left field, but is it possible its some form of early HC12? Its got assloads of registers, a funky A/D, little blobs of machine code that the dis. doesnt recognize, and a stack pointer that points to the last addr. pushed, and not the next free address. Dont know if all that is proof of anything but...

 

I guess its just a HC11F going at 2 MHz. Teeth must have skin... I dont know how they got it all to fit.

 

After you started going off on how this and that blah blah blah (over my head) I thought to myself... different processor. That much I do know about assembly .

 

Basically with the tbi ecm you have a one pound bag of ****. With this one running at 2x the speed and using the same instruction set (roughly), you have about two pound bag. Thing that bothers me is that when I turned it upside down, 8 pounds of **** fell out. They do have a more sophisticated way of handling the execution of all the routines. There are the two main routines and then a series of clusters with the trans stuff and other misc. junk run at slower speeds. All of that may allow them to jam that extra 6 pounds in using the nooks and crannies. Although this is quite a feat IMO. :shrug: oh well.

 

There are TBI ECMs that run 80% faster (instructions per second) then the '8746 or '7747, yet run at the same clock speed.

RBob.

 

What enables the increase in processor speed? Is it running more instruction cycles per clock cycle? More pipe lines or whatever? Would be something useful to know...

 

nvm...

 

...

Edit: Still confused and dont know...

 

With the tbi ecm it appeared to be 1:1 for the execution in instructions vs. clock cycle. For example, 5 instructions, 5 clock cycles. Is it not the same for the HC11? They say it doesnt support pipelining like actual microprocessors. I know this is way out of the scope of an automotive message board but its still handy to know.

 

It takes more then 1 clock cycle to execute an instruction on the GMCM. A MULtiply is 10 clock cycles (CC), a LSLA is 2 CC, a LDAB takes anywhere from 2 to 5 CC dependent upon where the data is being loaded from and the mode.

The TBI ECM I mentioned above uses a different uproc then the GMCM, but is backwards instruction set compatible with it. It also has a 1 byte pipeline. Knocks a CC off nearly every instruction.

The other method of making a processor faster at the same clock speed is to reduce the CC required to execute an instruction. Intel went backwards in this regard when they designed the '386. What a dog that thing is. Lower clock speed 286's would clean it's clock

Intel finally got it right when they designed the '486. Using RISC techniques they reduced a majority of the instrunction set to 1 CC. Blistering fast.

RBob.

 

Im not a hardware guy so Im inadvertantly mixing things up in my post and being confusing... My bad.

Yes, Im aware that it takes a variable ammount of cycles to knock off an instruction, depending on the complexity of the instruction is. If I go into the moto ref manual and look up, say BRA, itll give the number of cycles to execute, which is three off the top of my head. Do these correspond to actual clock cycles? Like, is it three clock cycles? That was of my origional, but badly worded question.

 

I would assume it is yes. For my tbi ecm all that held true, and the time to execute was equal to the # of cycles advertised in the ref. manual.

I would assume that moto changed the architecture of this one in the PCM to help optimize performance by reducing the number of clock cycles that it would normally have taken to execute the instructions?

 

So you could theoretically write a program to calc the amount of time each main and sub routine takes to exec? Or is this built into some compilers already? I say this because one area of my fuzziness has always been the real world timing. I know things like the coolant temp are done on a lower frequency than the spark and fuel calculations but it would help to know exactly how long it does take.
Would taking the CC's required and then divide the proc speed by the CC's give me seconds?

 

Theres no real way of knowing exactly how long it will take to execute the code. You could probably estimate how long it takes by the longest possible route that could be taken. But there are also things like interrupts that can add time. IIRC, in this computer theres a flag thats used to determine when one of the loops overruns.

If the CPU uses the same number of cycles thats claimed in the manual, then you can see how long it probably takes by dividing the speed by the number of cycles. Thats the question I have now, do the instructions take as long as they say, or does it actually execute faster at the same speed?

 

Another update:

This uses real, honest to *** speed density! They use a blended MAT/CTS (or just CTS if MAT not available) temperature term to look up the air density at sea level and use the cyl. volume, VE, and kPa to estimate the mass of air in the cyliner, all in one swoop with a string of divisions and multiplies. Theyre sinning a bit by ignoring the dynamic effects of a wetflow system when tbi is in use but I guess it wasnt such a large error that it couldnt be corrected for by VE and OL AFR adjustments to get the desired results. None the less, its a huge improvement over the pile of dog **** that was in the ecms. Although with the UTBI code the ecms will soon enjoy these same features.

I guess i wont be using my MAF anymore With the utter, unadulterated garbage-density that was in the tbi ecm the MAF was a no-brainer, but with this its not so clear. The code there is good and it would be a nightmare to coordinate upwards of 12,000 interrupts/sec from the MAF with the other time-critical processes in there. The maf will be more accurate, but itll be alot of maze for the extra cheese.

 

Datalog the MAF. The user inputs will be displayed on the HUD screen, if you want me to add a MAF let me know and I'll do it. What would be ideal? Tell me how to calc voltage to gps and it'll be in the release. It won't be used for fuel but it'll be datalogged

 

I can, and may still datalog it through the freq. to voltage converter. To actually use it, though, would require pulse accumulation, which requires fighting the interrupt blocking A/D read-ins and internal hardware update routines.

If you wish to see how the read-in is done, download 8063_MAF.ASM from moates.net. I detailed how to read in the maf from the A/D, convert it to a high res 16 bit looked up term, filter it, and incorperate it into the fueling. Youll probably only need a 10th of that code as resolution isnt critical for a datalog value. All you really need is to read in the voltage and convert it to airflow with a table.

 

Well with all the ultimate TBI buzz lately, I thought I would update the group here,us P6 TBI freaks, with some progress on
the $0D projects I have been working on. I have been datalogging my LM-1 WB O2 via the datastream using TunerProRT for a while now and my TPI conversion using the embedded $0D PFI code is close. I have all the hardware installed except for the
hardest part, the fuel pump, and all the .bin modifications are done except for a few details. I also need to update my
ecu/xdf files and write the whole thing up. I hope to have it all done by thanksgiving as I have been really busy at work
and been on the road a lot lately.
As for datalogging the WB O2, I am using the "Linear EGR Pintle Position" input at pin B16 of the PCM for the 0-5V analog 2
output of the LM-1. Obviously I am not running an EGR and I have code 32 disabled as well as all EGR enable terms. Bits
1, "LINEAR EGR/ 0 = EVRV EGR" and 5, "USE L4780 TBL FOR %EGR (Backpressure EGR)" at L400D (AFR Mode Wd 3) must be set, bit 2 does not matter and bit 3 must not be set or the input will not be read. I left bit 4 on but it did not seem to matter.
The tables at L4700, "DESIRED EGR Vs. RPM & LOAD, (VAC or MAP)" and L4780, "FUEL REDUCTION PCT WITH EGR ON Vs. RPM & VAC", must also zero'ed or the WB O2 input will affect the fueling. I set up the LM-1 and .ads file in TunerProRt so the AFR will be displayed properly from 10 to 20 AFR. See attached images.
It works great and the EGR routines do not affect fueling. My next project will be to finish the PCM controlled electronic
fan control. I have the PCM fan control turning on an LED at this point and I have the relay control circuit designed as
well, see attached schematic. I will be using a 16" dual speed fan from a 3.8L Taurus that will be on in low speed all the
time and high speed will be enabled either via the PCM when temp is reached or when the A/C compressor is running. More
updates to follow. HTH

 

Thats cool that you got it to datalog. I wonder if theres another output available to use? If I where to use EGR, the linear one would probably be it, although it doesnt do well with carbon deposits.

As far as the fan goes, what year had the two speed units? That would be cool to be able to have more then just on-off. One thing Ive been leary of, through is running the fan all teh time, especially after I had a fire from that. I think theyre only good for a 1000 hours or so of use. After that, the commutator wipes out, the bushings wear, the brushes run out, and bad things happen.

 

Do you mean another input to use for datalogging the WB O2? I don't know of any unused A/D inputs other than the MAT input, but I plan to use a MAT on my TPI conversion. I suppose you could use the "Transmission Fluid Temp" input if you were not going to use an electronic tranny. I don't know how difficult it would be to make it work though. As for the fan, I don't know what year Taurus' have them. I bought it off Ebay. HTH

 

I dont think any of the temp inputs would work without deleting the pull up resistor. Hmmm... I know it has quite a few inputs, some of which arnt documented in the pinouts that are floating around, Ill have to look at the A/D stuff again and see if there is anything else available.

 

I have used the MAT input for WBo2, it does work

 

huh.

Most of the schematics ive seen for the RTD inputs (MAT/CTS/etc.) all have a pull up resistor hooked to +5 volts. The resistance of the RTD causes the voltage at the A/D input to vary. Im surprised the WB works. I would ahve expected it to hang around 5 volts, or at least skew the input from the WB.

 

I know there are other unused and undocumented A/D inputs but the Linear EGR Pintle Position input was a no brainer for me. It was already in the datastream in raw form, EGR is easy to disable, and I wasn't using it (I have deleted EGR in both my S-10 V-6 daily driver, which used a linear EGR and my C1500 which had a back pressure EGR). I also didn't have to modify any code to do it. This also makes it easy for other DIY'ers to do without a lot of hassle. Lastly, the temp inputs do have a pull up resistor but it is no big deal to remove it.

 

Ill probably use the linear EGR input, but I sort of hate using an input that I might want later. Parts of New Jersey (Trenton, Piscataway, Elizabeth, etc.) routinely posts the worst air quality numbers in the nation. Dont even need to measure to know this. Theres a huge turd brown colored dome of smog over the area. One day I fear Ill have to face Nazifornia type emmissions due to the plummeting air quality.

 

I have successfully passed the sniff test here in Dallas with a non functional EGR valve attached for the visual and a gutted cat. I just hook up the WB and adjust the injector constant to run it lean at 17.5:1 AFR or so for the dyno test which consists of 15 and 25 MPH readings. In the parking lot, I pop in the modded chip and get the test. When it is done, I pop the original PROM back in and drive home. Obviously I don't recommend trying this without a WB. It is not without risk, of which I assume none.

 

I passed the last sniffer at inspection w/o EGR as well. Didnt even know I was going to be actually inspected when I took it in.

 

I also did this as well this past weekend, and was a little shocked at the numbers. Blew a 17 (yes, seventeen) HC, and 0.07% CO (passing #s were 195 and 2% respectively). All this with no EGR, and a "not recommended for computer control" cam, though I do have a high flow cat. No special tune needed!

Teeleton

 

It is my experience that if you have a "tight" tune and run the engine lean in open loop, it is not too hard to pass a sniffer test. If the tune is just "close", you may or may not pass without a cat and EGR. Conversely, if everything is working as designed and you have all the emissions junk hooked up, you can pass in closed loop. JMHO

 

You can also pass in closed loop without the emissions junk if you modify the PID routine . I can "average" anywhere from a 12 to 16 afr.