After doing a search, and learning that rewiting the source code would be required to add rows and coloumns for higher RPM ranges in the puter's tables, I noticed that the one major post about this was over a year ago. So my question becomes, has anyone made any significant headway into diassembling the code and rewriting it so that those who have engines with higher than stock RPM ranges can have better engine managment?

 

It's hard to share information anymore without having some ******* selling the info or making a profit off of it. R&D is very touchy, companies don't give it out for free let alone somebody that didn't make a profit themselves!
I think the diy-wideband project has something to do with it. Also the people selling eproms all over the web is another. Why do you think it took me so long before I posted my first rendition of the 8746.ecu file.
I have a few friends that are EE's and they are very good with the 68HC11. They actually took a class in it so it shouldn't be long before some cool stuff comes out for the 8746/7747 ecm's.
Again, how pissed off would you be if you released a LOT of information that you spend months on and then somebody goes behind your back and starts selling that information as a "kit." or magical wonder prom that solves all.

 

Yep, it wold definitely bite. So sure does make it hard for a non computer expert to work on expanding the possibilities of electronic engine management tho. I would need a personal tutor in the subject, or otherwise go back to school for this kinda stuff. The writing of .bins for PROMs is one thing, but source code would be another entirely for someone like me.

 

ve tables could use some help above a given speed for sure. spark however need not bother. at some point the burn times vs timming becomes a deminishing return.

the best way to fix the problem is to change the table argument if you have an ECM that has a low speed and high speed VE table setup ex $8d. the just move the TPS threshold for the upper table up a bit and set the srgument to end up a bit higher in the revs and fill in the blanks.

Silly rabit tricks are for kids.

 

You should hang out here more often. Not even that old:

https://www.thirdgen.org/techbb2/sho...hreadid=173706

RBob.

 

RBob,

Now that it has come time for me to start thinking engine, I am definitely hangning here more. The tough part to overcome is making practical sense of the nearly greek one can read here. At this point, my EFI system consists entirely of a jumble of wires in a rubbermaid bin. Hard to experiment with things like that, but trying to make sense of the writings here I am definitely doing.

Funstick: Stick to more layman's terms and I'll probably get what you're saying. I need some relative definitions for 'arguments' WRT tables in the programming, and of course how moving the TPS 'threshold' will change things. Masks, their labels, and what they do are still baffling me at this point.

Engine managment will have to tend to a 6500 RPM NA motor, with power goals of no less than 525ft lbs/525hp.

As of right now, it looks as though I'll run a 7730 ECM, and I'm definitely leaning towards running a romulator rather than burning flash proms - it sounds like so much more fun. A WB02 looks like a very nice thing to have. I think I know what tools I need but damifno how to use them.

RBob, your code patch looks neat, but its purely chinese to me eyes. Now if you can describe what I'm reading when I see the code, it would be very helpful. I read the patch method demo, I think.


WTF is that?


HUH?

I'd probably get and idea on what all this means if I knew what FCB means.


Just so you see where I am. Many thanks for the replies and the input, you're selflessness is not unappreciated. :hail:

 

FCB stands for "form constant byte." I just learned that tonight after my EE teammates told me.
Bob, these guys are helping me source code WB input and expand tables, even control the fan. They have limited use of the actual processor but they know how to read the code without your comments , that impressed me. I'm going to try and get a hold of you this week when I figure out the next time I'll be in NJ. I'd like to stop in and show you an engine that doesn't detonate. It ended up being a bias constant that I had set to zero but forgoten to set the table to zero's, hence the 10-20 degrees of timing out of the blue.

 

JP, even thoguh I posted the patch everything you said in your first post of this thread is true. Yes, stop on by. . was it the TCC locked SA retard table that got you?

RBob.

 

The S19_PAT is an DOS executeable utility program. It takes an S19 file and applies it to a bin. An S19 file is a text file that has the code/data from an assembled source file.

Seach the net for the Motorola program AS11, with it usually comes a small text file that decribes the various assembler directives (such as FCB, FDB. . ).

RBob.

 

Yeah, it was the TCC bias. I was just reading all of the code one day and...
<code>
;
; sub off SA bias's
;

LE7B8: F0 D0 0D SUBB LD00D ; 57, 20 deg, coolant comp bias
LE7BB: 82 00 SBCA #0 ;
LE7BD: F0 D0 0E SUBB LD00E ; 57, 20 deg, tcc locked bias
LE7C0: 82 00 SBCA #0 ;
LE7C2: F0 D0 28 SUBB LD028 ; 57, 20 deg, main SA bias
LE7C5: 82 00 SBCA #0 ;
LE7C7: DD 49 STD L0049 ; SA
;
</code>