[cgrey8]

For those that haven't read the eectch98 document by Tom Cloud, here's what I'm referring to:

...The 8061 microcomputer chip features a CPU, 256 bytes of RAM, an A/D converter and independent co-processor circuitry to expedite digital signal I/O handling. There are 13 analog lines, 8 hi-speed digital inputs, 10 hi-speed digital outputs, 8 lo speed digital outputs and 2 bi-directional I/O lines, making a total of 41 I/O lines on the CPU chip. The A/D converter is a 13-channel, 10-bit successive approximation unit.

The internal 256 bytes of RAM in the 8061 can be referenced as bytes, words or double words,
allowing frequently used variables to be stored on-chip for faster access.
The two high speed co-processors on the 8061 (HSI and HSO) were implemented to reduce signal processing overhead on the CPU. An 11-deep FIFO for the high speed input (HSI) and a 12-slot content addressable memory (CAM) for the high speed output (HSO) are used. Operation of both HSI & HSO are synchronized with an internal master I/O timer which is clocked every 2.4 microseconds (15 MHz crystal).

The HSI looks for transitions on its input lines and records (1) the time, from the master I/O timer, and (2) the transition. It can be programmed to look at selected inputs for positive and negative transitions and can be programmed to generate an interrupt to the CPU
when the first entry is made into the FIFO or when the next entry would cause the FIFO to overflow.

The HSO can be programmed to generate transitions on any of its output lines at
specified times. HSO commands are stored in one of the twelve CAM registers, which
are 24 bits wide. Of the 24 bits in each register, 16 specify the time the action is to occur, and 8 specify the action(s). The CAM file rotates one position per state time, so it takes 12
state events for the holding buffer to access all 12 registers. Therefore the time resolution of the HSO unit is 12 state times or 2.4 microseconds if a 15 MHz crystal is used...

If you have the document, it also has some visual aides that show the FIFO buffers are a ring that is rotating between the inputs to the EEC.

What it doesn't explain for the HSI is:

• How does the EEC read these rotating HSI registers? Which memory address or addresses are used to represent the currently queued buffer?
• How does the EEC know which physical input value is currently queued up in the buffer to be read?
• Assuming the act of reading the memory-mapped address is what triggers the HSI buffer to transition to the next buffer position, what indication does the EEC have that the buffer is empty and that everything has been fetched from the buffer?

There are similar questions for the HSO:

• The EEC writes out a time and value for the HSO. But is the value an ON/OFF or is the value a duration to be ON? For instance, when the EEC is firing an injector and it needs to fire the injector for a specific duration of time. Does the EEC send a duration as the value or is the EEC literally turning the injector ON and sending another command to be executed X ms later to turn the injector OFF?
• How does the EEC know which HSO it is commanding when it sends info to the HSO? Is part of what the EEC is sending to the HSO which output channel to control? If so, what's the encoding for that?

I have to believe there are some people hard core enough to know these things. But I haven't seen a document or any place where details like this are spelled out.

[mpaton]

I've learned some of this stuff just by looking at the code. eg, on 8061, you'll see commands to turn injectors on, and separate ones to turn them off. 8065 is different; I haven't studied those enough yet.

I don't know if those who know don't want to share, maybe not. You can add to your list that most ECUs also use memory mapped input and outputs, both for talking to serial devices like UARTs or CARTs, but also for switched binary inputs and outputs.

Another big unmentioned mystery is that something in the processor initialization code must be setting up the processor to use certain interrupts. It's not enough that handlers exist for some interrupts and not others, something must tell it what interrupts are enabled. I've wondered if this might be the strange constant #$CBED that you see getting put in odd places.

Most 8065s have a timed software interrupt, later ones have 2, and the docs talk of 4 being designed. I've been looking for how these are set up, but no finds so far.

Maybe you can put this thread in EEC Geeks, and see if there's any hackers prepared to discuss this stuff.

Michael

For those that haven't read the eectch98 document by Tom Cloud, here's what I'm referring to:

...The 8061 microcomputer chip features a CPU, 256 bytes of RAM, an A/D converter and independent co-processor circuitry to expedite digital signal I/O handling. There are 13 analog lines, 8 hi-speed digital inputs, 10 hi-speed digital outputs, 8 lo speed digital outputs and 2 bi-directional I/O lines, making a total of 41 I/O lines on the CPU chip. The A/D converter is a 13-channel, 10-bit successive approximation unit.

The internal 256 bytes of RAM in the 8061 can be referenced as bytes, words or double words,
allowing frequently used variables to be stored on-chip for faster access.
The two high speed co-processors on the 8061 (HSI and HSO) were implemented to reduce signal processing overhead on the CPU. An 11-deep FIFO for the high speed input (HSI) and a 12-slot content addressable memory (CAM) for the high speed output (HSO) are used. Operation of both HSI & HSO are synchronized with an internal master I/O timer which is clocked every 2.4 microseconds (15 MHz crystal).

The HSI looks for transitions on its input lines and records (1) the time, from the master I/O timer, and (2) the transition. It can be programmed to look at selected inputs for positive and negative transitions and can be programmed to generate an interrupt to the CPU
when the first entry is made into the FIFO or when the next entry would cause the FIFO to overflow.

The HSO can be programmed to generate transitions on any of its output lines at
specified times. HSO commands are stored in one of the twelve CAM registers, which
are 24 bits wide. Of the 24 bits in each register, 16 specify the time the action is to occur, and 8 specify the action(s). The CAM file rotates one position per state time, so it takes 12
state events for the holding buffer to access all 12 registers. Therefore the time resolution of the HSO unit is 12 state times or 2.4 microseconds if a 15 MHz crystal is used...

If you have the document, it also has some visual aides that show the FIFO buffers are a ring that is rotating between the inputs to the EEC.

What it doesn't explain for the HSI is:

• How does the EEC read these rotating HSI registers? Which memory address or addresses are used to represent the currently queued buffer?
• How does the EEC know which physical input value is currently queued up in the buffer to be read?
• Assuming the act of reading the memory-mapped address is what triggers the HSI buffer to transition to the next buffer position, what indication does the EEC have that the buffer is empty and that everything has been fetched from the buffer?

There are similar questions for the HSO:

• The EEC writes out a time and value for the HSO. But is the value an ON/OFF or is the value a duration to be ON? For instance, when the EEC is firing an injector and it needs to fire the injector for a specific duration of time. Does the EEC send a duration as the value or is the EEC literally turning the injector ON and sending another command to be executed X ms later to turn the injector OFF?
• How does the EEC know which HSO it is commanding when it sends info to the HSO? Is part of what the EEC is sending to the HSO which output channel to control? If so, what's the encoding for that?

I have to believe there are some people hard core enough to know these things. But I haven't seen a document or any place where details like this are spelled out.

[cgrey8]

I've learned some of this stuff just by looking at the code. eg, on 8061, you'll see commands to turn injectors on, and separate ones to turn them off. 8065 is different; I haven't studied those enough yet...

If you figure it out, please post. I'm hoping that between all the people that have done extensive research on exactly how the 8061/8065 works that we can pool knowledge and all get a better understanding. At the very least, we can hear how others interpret the code and the behavior so we can either prove or disprove theories.

...I don't know if those who know don't want to share, maybe not. You can add to your list that most ECUs also use memory mapped input and outputs, both for talking to serial devices like UARTs or CARTs, but also for switched binary inputs and outputs...

Memory mapped I/O is much easier to work with most of the time as long as you know the rules...far easier than coordinating through the coprocessors. But coprocessors do allow for more parallelism and thus more processing being done with slower stuff.

...Another big unmentioned mystery is that something in the processor initialization code must be setting up the processor to use certain interrupts. It's not enough that handlers exist for some interrupts and not others, something must tell it what interrupts are enabled. I've wondered if this might be the strange constant #$CBED that you see getting put in odd places...

I never studied the startup portion of the code well enough to realize that there isn't code explicitly enabling/disabling the various interrupts. I know some processors handle interrupts differently. Some have memory mapped locations specific to certain interrupts for the ISRs to be placed. Others have a vector table of pointers to point to the ISRs. How does 8061 do it?

...Most 8065s have a timed software interrupt, later ones have 2, and the docs talk of 4 being designed. I've been looking for how these are set up, but no finds so far.

8061 doesn't have timer-based interrupts at all?

...Maybe you can put this thread in EEC Geeks, and see if there's any hackers prepared to discuss this stuff...

It is in the EECGeeks forum of this site. Is there some Internet website also dedicated to this kind of info that you are referring to?

[mpaton]

...Maybe you can put this thread in EEC Geeks, and see if there's any hackers prepared to discuss this stuff...

It is in the EECGeeks forum of this site. Is there some Internet website also dedicated to this kind of info that you are referring to?

No, I was just suggesting you move it, which I see you've done.

The 8061 bin I know best sets up one of the HSO channels to generate an interrupt every 417 clocks, which is pretty much a 1mS interrupt. the handlers work as you say, but I believe the interrupts need to be set up to happen if you want synchronous ones.

Memory mapped I/O may be simple, but the locations seem to vary a lot in different bins.

I',m not too sure of the value of a big writeup on this. What would you do with it? i don't think you could use it unless you already understood much of it already. Maybe if you can get critical mass of Sailorbob, frit, svojohn and others to all contribute to a discussion that woul dbe worthwhile. If you're not into serious disassembly though, I think the Cloud writeup is good enough.

Michael

[cgrey8]

This wouldn't be useful info for the casual tuner. This info would be intended for would-be people aspiring to be the next sailorbob, svojohn, or whomever. In addition, if anybody ever wanted to completely rewrite the EEC code, they would need to understand how all this worked in the stock tune in an effort to even begin a venture like that. That sounds like a stupid thing for anybody to ever do on the surface.

But one of the things I've been wondering about is the ability to demote the EEC's processor...literally turn it into a co-processor that does nothing but maintains and relays I/O to and from a J3 device, but does no control logic. All control logic would be done by a much more powerful processor running a real OS like uCOS, Fusion, or possibly even Linux. The realtime stuff communicating to the EEC would be done by VHDL/Verilog logic in an FPGA. This faster processor could have access to a SD-Flash card, communicate via wireless Ethernet, and have the control logic customizable to whatever it is the tuner wanted/needed.

Now talk about a daunting task, BUT if there is enough similarity between EECs that all you'd need to do is decipher what inputs and outputs were what/where, then you could support far more EECs as well as standardize how to tune each one...based on what I/O it has or what special needs the engine/trans has. Obviously as you start getting newer, the EEC does a lot more (maintains tranny control, handles PATS, updates the dash, controls fuel pump, monitors secondary HEGOs, monitors fuel tank pressure, speaks OBD-II, etc etc). But if you started simple with an A9L, this J3 device could on-the-fly instruct the 8061 to do whatever it needed. Without all the overhead of running control logic, the 8061 should have a lot more speed to handle 7000+RPMs. As the details of how to do this got more streamlined, then the control processor's sophistication and method of control would get more elaborate. And then more sophisticated EECs and engines could utilize this technology.

So why go to all this effort? There is so much crap in the Ford tunes that is either unnecessary or is done in such a backward-ass way that probably made sense for the problems Ford was trying to solve but are not that important to the average tuner. In fact, a LOT of the options just noise up the interface and confuse/intimidate people. Then add to this that there are hundreds of strategies out there. Someone has to create, debug, and maintain those if they are to work with tools like BE and the QH. And there's lots of redundant work done for each strategy. If different people do the work, each strategy is going to look different and have different comments in the comments fields. Point is, the maintenance of all the strategies is more than the aftermarket volunteers can realistically do and do well. It's amazing we got what we got. But if you really want standardization between the different strats AND you want some consistency in look, feel, and functionality, it would be nice if they were all running the same algorithms and controlling the same way. For instance, more needing to understand that GUFx defs don't have a borderline and MBT table, but CBAZA and newer do.

If the control logic only contained the things people cared about, then even the more sophisticated EECs get simpler and not quite so overwhelming for a newbie. Even older strats like GUFx intimidate people. Imagine how it must feel being a newbie and staring at a CRAJ0? Imagine how it'll feel 15 years from now when there are aftermarket tools for things like the new 5.0 which has 15 tables just to control the VCT aspect of the engine. Of course all the new Ford EECs don't have J3 ports, but the same issue of creation, debug, and maintenance still apply.

But to even begin the concept of a unified project like this, the details of how the EEC's processor is setup and executes the stock tune needs to be fully understood. And details about how these things vary across different EECs also needs to be well known so board support packages can be written for each of the variants.

Will a project like this ever get off the ground? It's doubtful. But without knowledge like what I'm talking about, it doesn't have a chance.

[mpaton]

This wouldn't be useful info for the casual tuner. This info would be intended for would-be people aspiring to be the next sailorbob, svojohn, or whomever. In addition, if anybody ever wanted to completely rewrite the EEC code, they would need to understand how all this worked in the stock tune in an effort to even begin a venture like that. That sounds like a stupid thing for anybody to ever do on the surface.

But one of the things I've been wondering about is the ability to demote the EEC's processor...literally turn it into a co-processor that does nothing but maintains and relays I/O to and from a J3 device, but does no control logic. All control logic would be done by a much more powerful processor running a real OS like uCOS, Fusion, or possibly even Linux. The realtime stuff communicating to the EEC would be done by VHDL/Verilog logic in an FPGA. This faster processor could have access to a SD-Flash card, communicate via wireless Ethernet, and have the control logic customizable to whatever it is the tuner wanted/needed.

Aside from the "running a real OS" part, I think you've described QH or Tweecer. They cause EEC to run out of the J3 devices memory, and they can change what's in that memory transparently. Not quite what you described, but I think that's way more suitable in terms of real world fail safe procedures. Have the EEC do its thing and let the other processor change it's direction now and again.

So why go to all this effort? There is so much crap in the Ford tunes that is either unnecessary or is done in such a backward-ass way that probably made sense for the problems Ford was trying to solve but are not that important to the average tuner. In fact, a LOT of the options just noise up the interface and confuse/intimidate people. Then add to this that there are hundreds of strategies out there. Someone has to create, debug, and maintain those if they are to work with tools like BE and the QH. And there's lots of redundant work done for each strategy. If different people do the work, each strategy is going to look different and have different comments in the comments fields. Point is, the maintenance of all the strategies is more than the aftermarket volunteers can realistically do and do well. It's amazing we got what we got. But if you really want standardization between the different strats AND you want some consistency in look, feel, and functionality, it would be nice if they were all running the same algorithms and controlling the same way. For instance, more needing to understand that GUFx defs don't have a borderline and MBT table, but CBAZA and newer do.

What crap are you talking about. I'm not sure I agree.

But to even begin the concept of a unified project like this, the details of how the EEC's processor is setup and executes the stock tune needs to be fully understood. And details about how these things vary across different EECs also needs to be well known so board support packages can be written for each of the variants.
Will a project like this ever get off the ground? It's doubtful. But without knowledge like what I'm talking about, it doesn't have a chance.

I think it has got off the ground, it's called MegaSquirt. I'm not sure why you'd want to do all you're suggesting all over again when that project is around.

Let's see if this attracts any interest from the other EEC Geeks.

Michael

[decipha]

Does anybody know exactly how the HSI and HSO work?

like the posi trac on a plymouth... IT JUST DOES

[cgrey8]

Aside from the "running a real OS" part, I think you've described QH or Tweecer. They cause EEC to run out of the J3 devices memory, and they can change what's in that memory transparently. Not quite what you described, but I think that's way more suitable in terms of real world fail safe procedures. Have the EEC do its thing and let the other processor change it's direction now and again.

The difference is the QH and TwEECer are just serving up the stock tune, with modified parameters. But the EEC is still calling all the shots, doing all the work, and maintaining every aspect of the execution. My idea would offload this to another processor. The only thing the EEC's processor would do is take instructions from a J3 device to process inputs and outputs. It wouldn't execute any control logic like spark tables, fuel control, emissions detection, etc.

What crap are you talking about. I'm not sure I agree.

Don't get me wrong, the def developers go to heroics to develop these defs. They have my highest admiration for their skill and efforts. But the amount of effort it takes to develop a new def is not a trivial task. I think sailorbob has developed some 7 or 8 defs (maybe more by now) and he said he's yet to make enough money off of them to legitimize the amount of time he's spent on them. I appreciate his efforts, but I understand that there's just little incentive for him to keep doing it. It's not like it is fun work, people aren't really willing to pay a fair price for them, and when they do, they tend to expect/demand a lot of support for their payment which is discouragement from selling them in and of itself.

My other point was the Ford code-bloat and needless complexity:

• The MBT and Borderline tables presumably were added by Ford to work with knock sensor controls. Knock sensors can trim-n-respond the commanded spark based on detected detonation. The MBT table limits how far the knock sensor can increase the spark. Once you go above MBT, you no longer increase in torque even if the engine isn't knocking. But why the borderline table which is a table that's supposed to represent when the engine detonates? And why the sealevel/Alt table if the knock sensor and MBT table can control the spark? I've learned what the reasons are behind each of these, but these are the kinds of questions newbies come up with and the reasons are not exactly obvious. Now the REAL reason for this particular rant is, WHY all those tables in CBAZA which is an application that doesn't even have a knock sensor?
• Why is there EDIS scalars and functions in the GUFx defs when none of the 89-93 Mustangs ever came stock with EDIS? Having that code there just confuses people.
• Why do GUFx EECs have knock sensor logic when no GUFx Mustang ever had a knock sensor?
• Why do GUFx EECs have PFE EGR logic when all GUFx Mustangs used Sonic EGR?

I'm sure I could come up with a few more examples, but I think you get what I'm talking about.

Each of these examples are explained when you understand that the code in GUFx and CBAZA are used by other EECs. You can't expect Ford to write from scratch every EEC strategy. But knowing that doesn't make it easier to understand from a newbie standpoint. What I'd like is some platform that only includes the things people plan to use, but is flexible to change based on upgrades/updates as people decide they want/need more control. BE tries to do a lot of this by giving def developers the ability to associate features to levels and the ability to hide Scalar/Functions/Tables based on other settings in the tune. But even that causes it's own set of problems and complicates the def file development.

I think it has got off the ground, it's called MegaSquirt. I'm not sure why you'd want to do all you're suggesting all over again when that project is around.

That's kind of the direction I'd like to see a project like this go towards...but to reuse Ford EEC.

Is MegaSquirt open source?

Can I change the control logic in a MegaSquirt to do whatever I want? Can I add tables at will? For instance, I'd kind of like to have multiple HEGO Bias tables. I'd like to have a HEGO Bias table for when the engine is cold and another for warm.

Does the MegaSquirt do SEFI?

Can the MegaSquirt do OBD-II? If so, can it be setup to fake out emission tests to make the test machine grant a PASS regardless of what the engine is really doing? This would be an attractive feature for people in states, like Ga, that don't roll 96-up vehicles, only connect to the OBD-II port and look for codes, look for CATs, and check the gas cap.

Can I communicate to a MegaSquirt via wireless technology?

Can I update MegaSquirt firmware and control algorithms by simply updating files on a flash card?

Can I datalog the MegaSquirt and pull a flash card and get the datalog off of it without actually connecting to it?

These are just a few of the things I'd like to see get into the open community. But yeah, MegaSquirt is the closest I know of to what I'd like to see in a next-generation tuner/datalogger.

like the posi trac on a plymouth... IT JUST DOES

Have you been watching Joe Dirt?

[Dale McPeters]

Chris,

What you are suggesting is not going to be an easy task at all......

Just the simple twin maf code that John Worthington helped me with a few years ago took me almost a year and half to implement....

If you want something that is easy to work with and has a lot of community support and processing power buy a mega squirt.

[decipha]

Am I the only one that is understanding what cgrey8 is saying?

megasquirt is speed density it is INFERIOR to the stock ford eec, if anyone says different i don't care i'll stand by my statement, it is also not open source, you can only change the values for the tables that are given, you can't go create your own tables.

what cgrey is trying to accomplish is simply using the eec as a basic I/O device to control the engines peripheral devices, injectors, maf, isc, act, ect, bap, map?, knock, etc..

what cgrey8 wants to accomplish is basically the ultimate tuner's dream. An open source operating system for the ford ecu. That way you can do ANYTHING you desire. Only one strategy, only one definition, in a way he is insuring the future of the ford ecu.

This thread is completely devoted to figuring out how the ford ecu handles inputs and outputs.

If anyone wants to post about MS being this and that this is not the place for it.

Sorry, cgrey8 I don't know diddily squat about how ford ecu's handle I/O.

[cgrey8]

Unfortunately such an undertaking like this would not be single-strategy. But it would be the next-best thing. Only the things you care about would be in the tune. And what's in the tune would be heavily based on what your I/O options are.

For every vehicle that has say knock sensor control, the options in the tune would be the same. However the knock detection profile under the hood would likely need to be specific from engine to engine (that's why Ford's earlier knock sensor strategies didn't do so hot).

For every vehicle that uses EDIS, all the options would be the same.

Fueling control (particularly transient fueling) would be the same.

Basic spark control would be the same regardless of TFI, EDIS, COP.

If you want/need OBD-II, you can have it. But what's said out the OBD-II would be in the tuner's control. Since you wouldn't use OBD-II for diagnostics and datalogging, it could be allowed to lie it's ass off about whatever. This device could even store the original stock BIN file so when it is requested via OBD-II, the stock BIN could be served up even though the stock BIN is not what's in control.

There is a lot of overlap in abilities. And while I agree on things like deciphering things like dual-MAF setups being difficult. This wouldn't be deciphering. This would be inventing. Although I 100% agree that it might be a good idea, during development, to at least have a good idea how Ford did it so an informed decision can be made about how to implement it. But my gut feeling on a dual MAF setup would be that you'd basically run each bank off of each MAF. As long as the MAFs fed into separate plenums like they do on a F150 intakes, then the reading on one MAF would have no bearing on how the other bank is controlled. 2 redundant 4-cylinder fueling systems and 1 ignition system. That may be a naive assumption to make as to how things can work. But that's exactly why forums like this exist. So ideas like that can be shared, debated, learned more about, yadda yadda. And besides a project like this wouldn't be to make money or get rich. It'd be something just to see if it can be done. Even IF I did get something like this going, I wouldn't mfg it myself. I'd probably hand it to someone like Craig Moates to market and sell the hardware (for a percentage). It would be supported via forums like this. Being open source, anybody could contribute, change it, or do whatever they wanted with it.

[Dale McPeters]

I will not comment on decipha's post as I have been doing this a long time and I know better....

Chris,

What you suggest can probably be done but IMHO the time involved and the final product cost may not be worth it in the long run. I have also seen what happens when projects start off as open source with a lot of different contributors...It has always ended up that a small majority of the contributors ends up making a small fortune on other peoples sleepless nights. That is not for me as I am getting too old for that and I need to spend time with my family before I kick the bucket......

On the subject of the dual maf setup. The actual assembly code was modified to run dual maf's. I used the AD channel for the EVP/EGR. And it was not split into two different banks to accomplish this.....
Now days it would be more for the cool factor than anything else. With the maf's that can be bought today there is no other reason to do it. I will see if I can find some of the code snip-its for you some time later and you can see what I am talking about....

With the after market stand-a-lone systems that are on the market these days like Mega Squirt, AEM, BS3, Fast-XFI, MOtec etc. etc. You have to take into account your time away from family and friends when taking on such a huge project as this....

And to me what you are describing and thinking about sounds just about like a PMS in stand-a-lone mode or an AEM EMS....

If you are really intent on under taking such a project as this I would talk to Craig and get his input on the hardware side first. Then I would contact someone like John Worthington and get his comments on the assembly code side of things. I assume that he his still doing this kind of thing on the side....

Any way those are my thoughts....

[cgrey8]

You are right about open source projects. They have their dark side which is there are the contributors and the moochers. By far the majority of the work will be on the development side, getting an architecture to do what I'm envisioning, and making it work with the EEC. I'm not looking to get rich off of a project like this. Although I do hope there is some benefit from it ASSUMING it comes to fruition. And like I said, I don't want to make or sell. I'd also need someone like Craig Moates to do the actual hardware design of which isn't likely to be open source/design.

However there's another side to this that I was a little reluctant to share and that is I was hoping I could come up with something in open source that would also work, in architecture, for something like my work is wanting to do. I work for an HVAC Controls company and we are in the blue-sky phase of deciding what we want our next generation product will be. I have my ideas as to what the firmware direction should go but no decisions have been made. If I could get a substantial open source codebase started, then my work would very likely support it, contribute to it, and use it in our future product. The proprietary stuff would have to be proprietary of course, but the Linux OS, SD-Flash, and wireless ethernet aspect, along with the control program execution engine could be open source based on an FPGA running an ARM or Altera NIOS processor. But even with just that, there's a MASSIVE amount more that would have to be done after-hours that I couldn't justify as work. But if my work beats me to the effort, some of the ideas I've got will be 100% proprietary and it could not be used for a project like this.

As for the I/O details, please do share anything you got that is relevant to how the EEC code interfaces to the I/O, whether it is HSI/HSO based or memory mapped. Any other specific details like associating Interrupts to specific inputs would also be useful info. In theory, the only assembly code that will need to be understood is how to "setup" the processor for execution. And then configure it for the most efficient relaying of I/O values to and from memory. If the EEC processor could just loop over and over doing nothing but the absolute bare minimum work, hopefully there'd be enough time to do more than what the stock tunes can do (I'm thinking in terms of A9L era, not modern day). It still scares the heck out of me when I think about what it'll take to develop things like tranny control, VCT, etc etc.

And again, I do have to be realistic that this has little actual chance of coming to life. But I want to research it as though that's not the case.

[decipha]

i met a guy recently that put two maf sensors on his fox mustang, due to having a split plenum or something where a single maf was not feasible, one maf physically fed one bank vice-versa

anyway he made this setup a few years back and made a little concoction that reads both mafv's and averages them out, then it gives an interpolated value to the signal return feeding the ecu.

he told me he's been driving the car like this for the past few years with no problems, he does want me to do a tune for him so hopefully soon i can get some pictures taken and post them

i know this is a little off-topic but found it kinda relevant to your dual maf idea

stay tuned i'll post back my findings as soon as i have something to update

[TripleBlackVert]

you probably already read this, but page 12 of the 27006102.pdf seems to have a pretty good writeup of the operation of the HSI.