DIY PROMDo It Yourself PROM chip burning help. No PROM begging. No PROMs for sale. No commercial exchange. Not a referral service.
Welcome to ThirdGen.org!
Welcome to ThirdGen.org.
You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, at no cost, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, join the ThirdGen.org community today!
I've got it assembling and it compares good!
Now I'm beginning line by line comparing to the ANHT hac to feel my way through the sequence of events and data locations.
The "jumping" around is still difficult for me to follow but I'm getting better at it. The multi-dimensional table lookups I especially need to get a grip on.
I am using the new version, thanks for that.
Comparing the dis or lis file with the hac and my ecu file is really helping me to see things at the end of the tunnel.
(Gee, I hope that's not a train! )
Good things to learn!
This ad is not displayed to registered members. Register your free account today and become a member on ThirdGen!
Sponsored Links
Registered users do not see this ad. Click here to register for free!
Hay alll ....I realllllly need to know what bin file I have . I am not totally getting it ...... the guy need to know what bin to upload on to my prominator .
1989 5.0l 5 speed ( stock ...new setup in my sig ) but I wanted to start with a stock bin ...and go from there
PLEASE HELP ME .... I got to pages of where bins are stored ....I get to 6e ....then I open it to find a list of stuff that makes no sense ( yet)
PLEASE help I am kinda stuck here ...and dont have time to learn it all right now . I just need to know what to get ????!!!!!
__________________ PROJECT UGLY DUCKLING
1989 10:1 353 L98Edlebrock base and runners ( really ported)ZZ4cam ,1 3/4 SLP shorties 083 heads ...cleaned up andstuded w/1.52 rr , LT4 valve springs and retainers and a 3 angle valve job
suspension mods (Hotchkis LCA's PH bar, KYB shocks and struts)
T-5 3.73
T-62 turbo to be installed next ...Exhaust clip ...gota let it load.... http://media.putfile.com/My-exhaust-clip
Originally posted by D's89IROCZ Hay alll ....I realllllly need to know what bin file I have . I am not totally getting it ...... the guy need to know what bin to upload on to my prominator .
1989 5.0l 5 speed ( stock ...new setup in my sig ) but I wanted to start with a stock bin ...and go from there
PLEASE HELP ME .... I got to pages of where bins are stored ....I get to 6e ....then I open it to find a list of stuff that makes no sense ( yet)
PLEASE help I am kinda stuck here ...and dont have time to learn it all right now . I just need to know what to get ????!!!!!
Please check out the stick's at the top, and use the for such questions. This thread is for advanced editing of the instructions that the ECM uses, compared to the basic tuning that you sound to be starting. Once you get to the point that you want to know every little bit about what the ECM is doing, this is the thread, but for most that are looking to tune their setup, this will be well over their heads, and they know what mask ID they're running.
The mask ID for what you're running would be $6E, and APYS is the closest I could come to what you might need for a BCC for what you need.
I wanted to put this up here to a.) keep this alive and well, b.) to explain how the bits in a word are manipulated in code.
It has taken me a "Bit" of time to figure out the actual one I want to work with so for the newbies can pick this up quicker than I did.
When manipulating bits there are "SET" and "CLR"
The syntax for the line is :
L0000: BSET L0022, #$01 Turns on bit 0 at the address 0022
To turn off a bit, the command BCLR is used instead of BSET.
The bit addresses are as follows:
bit 0 = #$01
bit 1 = #$02
#$03 =bit 0 and bit 1
bit 2 = #$04
bit 3 = #$08
bit 4 = #$10
bit 5 = #$20
bit 6 = #$40
#$60 = bit 5 and bit 6
bit 7 = #$80
The checking of bits acts on the same type of code, for example:
L0123 : BRCLR L0022,#$02, L1111
This line performs the following:
BRCLR = Branch if clear, looking at address L0022, bit number 1
If this bit is "Not" set then the code goes to L1111 (the TRUE argument) and continues.
If the bit "is" set, then the code performs an "else" and continues with the next line of code below this one.
This concept of operation was pretty foreign to me and I thought someone could benifit from the explaination.
Please correct me if I've mistated anything.
Edit: Wanted to note that the #$01 can also be seen as #0x01
The 0x indicates its HEX. The disassemblies show it that way.
JP
Thanks RBob for pointing that out.
I didn't see the combination addresses there.
I edited for the two you pointed out and will go back and fill in the middles.
Filling in the middles will make that post HUGE. I don't know much about code, and have yet to disassemble anything, but I understand hex quite well and this is something that makes sense to me.
For instance #$C9 will check/set/clear bits 7, 6, 3, and 0. #$DE will check 7, 6, 4, 3, 2, and 1, and #$FF will check all 8 bits. All 256 combinations can be checked using the same method.....convert the hex byte (i.e. C9) to binary (11001001) and the bits that are set are the ones that will be checked/set/cleared by the command (7, 6, 3, and 0.)
Ok, maybe just adding a few more will do the trick
My hex really sucks, but bringing it back to binary makes much more sense to me that way and is easier to see what's up.
Originally posted by JP86SS Ok, maybe just adding a few more will do the trick
My hex really sucks, but bringing it back to binary makes much more sense to me that way and is easier to see what's up.
Thanks Mark, I actually have that printed in my binder next to me.
I've been wrapped in binary and octal for so long, dewey's are just normal to see, hex just freaks out that part of my brain.
It discusses how some of the inouts of the 1227730 and 749 are read. I'm sure this is similar to how most of the P4 ECM's work, with just a different implementation.
I also shines some light on the possibility of the source code being modified to eliminate having to repin some of the stuff to switch between masks....
Have you have try the new one? http://www.dewtronics.com/pub/m6811d...1DIS_v1p20.exe
This will give you a refference information as a comented output, is it "Data" or is it "Code" check my previous post.
From there you can conclude and put entry or remove entry.
It can be just a lump that you need to clean up and convert to Code.
PS
No much time those day's, I am working on a new wiring loom for the Cobra
One of the easy things to work with is the option "addresses" whet you set this "ON" in your “txt” (Control file) file you will get at the left every address for every line so you can use it for an "entry" so you don’t need to calculate the address of the line that you want to put as an entry
But don't forget at the end when you are satisfied of the result to remove this option because other ways it will never re-assemble correctly.
And other point of consideration is to remove all the labels and indirect and work only with entry’s to get the code.
In that case you need to go more extensive with the entry’s but in the new version I have read that it was no limit with the amount of entry’s.
Just from the "DOC" file from the disassembler.
------------------------
Unlike the typical “disassemble everything” method of the traditional disassembler, the code-seeking disassembler actively seeks out and disassembles sections that it sees as code while leaving the rest tagged as data. This is achieved by giving the disassembler one or more initial entry addresses into the code. From these entry points, the disassembler continues to follow through the code as it hits jumps, branches, and returns. In the end, you should have a perfect separation of code and data. There are some complications to this. For example, what happens on a jump instruction that uses a register to obtain the address of the branch, such as is common with a jump table? The disassembler has no way of knowing exactly what the content of the register is, so it is forced to label the jump instruction as an “undetermined branch”. Such tables have to be located by the user and added as additional entry points for the disassembler. Also, suppose you don’t enter all possible entry points – the result will be a file with chunks of code interpreted incorrectly as data. And there are cases where there are unused bits of code that never get executed – those will remain tagged as data. But overall, the code-seeking disassembler is far superior to its traditional counter-part and in many cases, with little user intervention, can produce a perfect separation of code and data, which greatly facilitates the reverse-engineering and/or hacking of the target code.
------------------------
What do you see at location 90B4 in the bin?
A byte of 0x72 does not correspond to a valid opcode (in a regular 68HC11), which should follow the LSL instruction.
So I'm thinking that the LSL INDEXED instruction (machine code 0x68) at L90B4 is not actually an instruction, but a data byte.
Anyone else follow my logic?
Going back further, I don't think that the
brset *L0014,#0x16,L90B4
instruction is correct to jump to $90B4.
Sorry I don't have a fix, I'm not very experienced with disassemblers.
I have a .asm that I've gotten to assemble, when I generate a .bin from it thou, it doesn't match the original .bin.....
No way is this code. It is a data table of some nature, -or-, even a dead area that is not even in use. It may just be whatever was in the host computers memory at the time of assembly. If there isn't a defined value for a location then the bin ends up with whatever is in the computers memory at time of assembly.
For that matter it could be part of an Word document
I found that I was "over doing" the entries to fix "chunks" like that that did turn out to be data tables.
The problem was that when I added ENTRY or indirect, some of the data inadvertently changed to code that pointed somewhere else and changed that data into code as well. Made thing confusing to say the least.
I backed off and restated my entry table until I could prove they were data or code.
Another option in the disassembler is "spit".
This may help to see tables of data from code as well.
It trys to make everything code. Some parts just come out bad, indicating a possible table location.
Lots of trial and error but I finally got my AUJP to come apart and go back together.
1 note: The interrupts at the bottom MAY come out as "FCB"
They need to be FDB to compile correctly. This was using a different assembler than the one Cobra made available.
But I got it assembled Ok that way.
Just a little something I do to see what's going on. Most of the hacs will tell you what bits are being manipulated, but this acutally will show you.
Say you see something like this in the code your hacking.
Code:
BSET L0045,#$14
If you put $14 into you windows calculator and convert it to binary you'll get 10100.
Counting from the right is bit 0 to bit 4.
So b2 & b4 are being set.
Looking in the pink book, it says only binary values of one will change the bit. So the zero's in 10100 will not affect b0,b1,b3.
Now I need to find the time to dissassemble something and catch up with you guys. At least I have all of your work to look at if I get stuck. Thanks guys.
Originally posted by Z69 Just a little something I do to see what's going on. Most of the hacs will tell you what bits are being manipulated, but this acutally will show you.
Say you see something like this in the code your hacking.
Code:
BSET L0045,#$14
If you put $14 into you windows calculator and convert it to binary you'll get 10100.
Counting from the right is bit 0 to bit 4.
So b2 & b4 are being set.
Looking in the pink book, it says only binary values of one will change the bit. So the zero's in 10100 will not affect b0,b1,b3.
Pretty soon you've be able to do the calcs in your head.
Also, have a look at the AND, ORA, EOR instructions to see how they do bit masking operations to the Accumulators and Index registers.
I had a hard time figuring out the indirect's for the control file when I did aujp.
I didn't just want to copy the available list.
All I could find for sure was the last 9.
They are in the anht hac as well as the diy-org p4 stuff. I'm unsure of what else even needs them. My compare came out good. I added only two .org commands to get rid of a bunch of the 00's starting at 8988. Biggest time waster was using too many entrys. I used entries for all the clumps. The cut and paste for the comments are going to take forever though. Not to mention all the labels...
So how do you know when you need and indirect for a constant? Like 7FEE
I was under the impression that you need "indirect" and "entry" to indicate to the disassembler that the code is "jumped" to the pointed to location from an indexed register. The description above from Cobra289's "Doc" exerp makes the most sense of it.
I'm not sure of your reference to 7FEE, that looks like a memory location to obtain a value during execution. There should not be any "Code" there. The AUJP starts at $8000 for the execution code.
I'm doing the AUJP now and it does take close to forever to patch in the text. I haven't bothered with the lables yet until I know for sure they are correct by tracing through the actual code.
The ANHT has several issues with it and they don't always line up with AUJP. I still have an issue with an extra $FF at location this is the description I've put in my file
"Went back over the extra $FF error at L834B table.
; the value does exist in my AUJP (not a cut paste mistake)
; (went all the way back to original file to confirm)
; The actual values in my HAC are now moved from L8358 to L8357
; Then the data values line up with the ANHT hac descriptions.
; There is still a missing address at L835C (nothing there)
; This could be the key to the issue if I get through the
; actual calculations to see what is being used through the code.
; Everything would shift back into place between L834B and L835D.
I hope that makes sense to you.
If you want a copy of my cal section (all but the upper VE is totaly commented) I can send it to you.
I didn't want to post it on Craig's site until I was sure if there is an error or not.
If you are doing AUJP, you "may" see the same thing, I hope so and maybe we can figure it out.
Jp
FFEE-$8000
The M6811dis.doc uses those addresses as an example for required indirect listings in the control file. I just thought that there were more than the 8 required that I did. I noticed some none zero values just above my vectors tonight when I review the .dis again. I did entries for all the lumps to differentiate them from the vector stuff in the control file. I need to read Cobra289's directions again. I just used some abbrev. cut/paste directions I made to do it. I just did the 8 indirects that I new where to find the addresses for. I figured that the errors would lead me to the rest. Basically I wanted to see how to disassemble a bin w/o a hac as an assist.
I did notice a $0001 offset to the code in aujp. Thought it was me being hex challenged....Or just a typo in the anht hac.
I've noticed some areas missing from the anht hac. They are not all blanks. The 800 rpm idle limit that Traxion talks about for the S_aujp is one area. You'll note that the anht hac has a lot of org listings. Only needed if your deleting areas from the .dis file and want it to assemble. Or you want to add things to the blank areas and ensure the orginal code/data doesn't move. Might want to do a anht to aujp bin compare to see what I mean. I used the Super 8dm2 ecu.
I found the code editor that came with my THRSimm11 program.
It is a stand alone editor that is pretty nice to work with.
Its called "SciTE" and has Windows and other operating system support.
Has a big list of reconized code language structure stuff built in.
Might want to give it a try. (has colors, OOooohhhh, Ahhhhhh)
Back from the archives with more to add
Now that I've got the original hac file to assemble its time to make it relocatable.
I wanted to keep the code question stuff out of the Great $8D list thread so I brought it back here.
From the other thread:
The key to making the source work is to not have any hard coded addresses. This statement is the same as above but with the table address hard coded:
How can you distingush between the above instruction that is pointing to an address (value IN the address will be loaded to X)
and
something like
"LDX #$3FC0 " ???
I realize the 3FC0 is an address but it could also represent 16,320 decimal value in a calculation.
The distinction is not clear in my mind.
Several places indicate LDX of value #$0000
These could be the minor loop counter value OR a value of zero to clear an address in the next opcode.
Originally posted by JP86SS Back from the archives with more to add
Now that I've got the original hac file to assemble its time to make it relocatable.
I wanted to keep the code question stuff out of the Great $8D list thread so I brought it back here.
From the other thread:
The key to making the source work is to not have any hard coded addresses. This statement is the same as above but with the table address hard coded:
How can you distingush between the above instruction that is pointing to an address (value IN the address will be loaded to X)
and
something like
"LDX #$3FC0 " ???
I realize the 3FC0 is an address but it could also represent 16,320 decimal value in a calculation.
The distinction is not clear in my mind.
Several places indicate LDX of value #$0000
These could be the minor loop counter value OR a value of zero to clear an address in the next opcode.
Can anybody provide some insight there?
TIA
The key is to know how the value being loaded is going to be used. The easy to break one (LDX #$81FD) is the address of a table. So as the tables move around so does the address of that table.
If the value being loaded is to be used as data, then no label (EQU in the case of a data value) is required. Nice to have an EQU but not needed.
To go one step further (to really confuse the issue), in P4's the address of $3FC0 is the DRP counter. This is a ECM hardware location and won't be moving. Still, it's nice to have a chart such as this at the beginning of the code (short version):
When I do hac's values that are used as data typically get hardcoded. That is using the #$nnnn or #nnn (decimal) form. And to take it a step further, if it is a double value I'll use 4 or 5 digits to show that. And if a single byte value I will use at most 3 digits (if in decimal) or 2 digits if in hex.
Code:
;
LDD #0307 ;
ADDD #$4080 ;
First one in decimal and the second in hex, both double operations.
This is just something that helps the reader of the code to easier see what is going on.
1) Anyone have a working control file for a 8746 $61 ? I'm not 100% sure from searching what code bases everyone is using. I don't know from user names who's running what.. (not yet)
edit: ok after additional repeated reading of the instructions it seems my errors might be 'normal' from the indirect jumps, but im still workign on this...
edit2: im still confused... on this...
2) This question is in reference to doing code work AND tuning. (NOT doing simple patch stuff.. )
How are you saving your tune information between each reassemble, assuming there was modified code?
Is the process somting like this?
- Make code changes (reassemble etc)
- Do some tuning.
- Do you cut past your newly tuned tables into your 'old' code base (hack) That you just assembled with? (to keep it updated).
- Then have to go update your TunerPro definition to reflect these possible changes of table locations?
- more tuning
- more code
- repeat
Im sure its better to not mix the two processes. and maybe im over thinking the ammount of actual coding being done out there and its not a big deal for a 1-2 times a year thing... But it still seems like it could be a real manual process to keep tabs on where your tables were/are if your attempting to do some serious recoding..
Possibly a simple perl script to update the TP definition to reflect the new locations.. (shhh... i know were not soposed to edit them manually)
or
Possibly in a future release of TunerPro there could be a new button/feature to search your commented hack possibly using your relitive location IDs and do the update.
Im not to this point yet just ponder this stuff on my daily commute to/from work...
You only need to work on the definition in TP if you have a hard coded value that you want to adjust and you have made a code change.
The Table values etc are in the calibration section. That doesn't move (or shouldn't be moved)
Adding new items to the end of the calibration or sliding them into an already open slot is the best way to keep things in place.
Copying in "new" table data to your hac file is the only way to keep your commented file up to date.
I wish there was an easier way but not currently. I cut out the tables and keep them in separate text files then edit them as needed. That way you can cut/paste versions as needed when you start over.
Keeping a "virgin" stock file will make it easier to do a text compare and see what your current changes are.
Re: Source code for dummies....Ask questions here!
M68HC11RM.pdf is what your looking for.
Not that you need it for your labels.
You have a misunderstanding as to what is being done by the software.
Go back and read your other post and see what I wrote.
A label is simply a variable used to designate a specific address by the assembler once it starts compiling the text file. It can be most anything. ie X: x: Lxxx: Start: End: Jump to patch: etc..... The actual address can move as things are added or removed from the asm file. So it can be confusing to use an address based label such as L8402:. But it's a label so L8402: doesn't have to be at location $8402 on the chip. That's when the list file comes into play. If you want to know where the value of L8402: is at in the bin you have to go to the list file and see what actual address it ended up at.
Your getting labels confused with something else....hint hint
You only need one to get started.
You may have to read this thread again. IIRC what you need may only be specifically mentioned once and isn't obvious by it's useage in the post. And that is in regards to the 8d bins used. When trying to do a bin from another mask.
You have to understand where the ecm knows to look on power up.
I can't remember where I saw a posted list of these addresses. It was either Ludis or DIY_EFI I think. But you don't have to find that page to do this. From what I could tell, I was the only person that looked into doing this w/o using an existing hac to get the addresses needed. That's in reference to this thread.
Now if you want L8402: to be at $8402. The you put Org 8402 on the line above it. That's how you "pin" code or data to a specific location in the bin.
Re: Source code for dummies....Ask questions here!
Strange, ive been sitting here all day racking my brains out trying to figure out how to get the m6811 disassembler to disassemble my bin. There has to be some kind of reference to that. Simply "pulling" a control file from underneath isnt possible. Ive tried. I downloaded CATS disassembler and ran my bin through it and in about .25 seconds its all there. There is ONE thing i dont have to make the m6811 dis. to work, and thats a reference manual for the labels. Using the APYP control file, i disassembled the APYP and it came out fine. It would be a dream come true if that were the ECU i was using. I think the measly little price for CATS products is well worth investment.
This is what i see in that PDF.....
your Control File should include an "input" statement and an "output" statement to specify
source and destination files, respectively. And, it should include at least one entry point, in some form, for
the code disassembly. If no entry points are specified in the Control File from either "entry" statements or
"indirect" statements, the load address of the file is assumed to be an entry point.
i did not include an entry point.
that *.dis file it makes has nothing discernible in it.
Last edited by escort_ford84; 06-11-2007 at 01:42 AM.
Re: Source code for dummies....Ask questions here!
Well, disassebling something thats already been disassembled is easy, ive done that already. disassebling something that hasnt has yet to be done, if ya think about it. here is my control file and my disassebled file, along with the disassembled file from CATS disassembler. I have attached my files. A.txt being my control file, a.bin being my bin file, a(CATS).scr being the CATS disassembled of the same bin file. Note, there is a problem. the 2 files dont match, one is readable, the other isnt. Ive been at this at least a year, this isnt new to me. I did exactally what the PDF told me to do, and still, no good.
Re: Source code for dummies....Ask questions here!
SCREW IT NEW DAM! THREAD. Its easier to sift threw post of a certain thing than to wallow throw pools of them of poeple doing what has already been done before.
Re: Source code for dummies....Ask questions here!
Im not sure, but this thread must be old, i feel ive opened up a can of worms that was long forgoten or has been taken care of by later technology. I have yet to "see" this m6811 disassembler do anything that it hasnt done already. But, i believe i am beyond the disassembly point since CATS cross Disassembler did it for me, in hopes that there is some kind of reference i can apply to this disassembled information. Still, i believe there is something missing, something that no one has mentioned yet. So far, garbage.
Z69, so far to me, it looks like youve disassembled once again (165 ecu) that has already been disassembled, thats nuthing new so far, what youve done was followed someone elses disassembly, you and i have done the same thing. lets move on
Last edited by escort_ford84; 06-11-2007 at 03:29 AM.
Re: Source code for dummies....Ask questions here!
You took my attention “Ford Escort” not because what you are trying to do, is interesting, but because of you “Behavior”
You are telling here to “well respectable people” (not me) that they do the easy way.
At the same time you ask them to help, because according to you it should be the hard way.
I have found in my life that “Knowledge shared with others will result in progress”
But at the end of the day it is “DIY” and after that you can “share it”
“dimented24x7” has point you for the next:
Quote:
That CFI ECM is as stone age as it gets, so its not really worth the effort to try and reverse it just to be able to get some tuning defs.
At the same page you can compare with the value of the ID $6E that is $C000
So the question is:
Why you put at your text file “load C000” if you know that your algorithmic start at “3000”?
Would not be the right way “load 3000”?
(This was mentioned at the thread for Dummies “You need to put there the correct “org.” of your bin”) it is just details!
This is just and small thing to point, that has been done via the easy way.
I hope that this help you to find the next step!
Please don’t make a mess with all the threads! And think if it took others “years” to solve their problems, why should be your problem solved in a couple of days?
Respect them, the people that want to share it, hope that a day you will share with others too.
Re: Source code for dummies....Ask questions here!
Well said Karel.
As far as I did it the "easy way"...
Here's a few quotes of myself from this thread. -and I said I wouldn't quote myself online!!!!
Quote:
I had a hard time figuring out the indirect's for the control file when I did aujp.
I didn't just want to copy the available list.
All I could find for sure was the last 9.
They are in the anht hac as well as the diy-org p4 stuff. I'm unsure of what else even needs them. My compare came out good. I added only two .org commands to get rid of a bunch of the 00's starting at 8988. Biggest time waster was using too many entrys. I used entries for all the clumps. The cut and paste for the comments are going to take forever though. Not to mention all the labels...
Quote:
I just did the 8 indirects that I new where to find the addresses for. I figured that the errors would lead me to the rest. Basically I wanted to see how to disassemble a bin w/o a hac as an assist.
And just to prove to myself that I had it figured out.
I went and dis'd the $58 afterward w/o looking at a hac!
Like I said in other posts - you need to know what the ecm does on a power up. It doesn't matter what the mask is because an ecm may run several different masks. And as I said in another post- you need the rom data to make a c3 work. It doesn't matter how many times you read this stuff. You have to go DIY at some point. Whether it's a C3 bin or a P4 bin.
Understanding what's going on is what takes the time. Otherwise you could simply copy the indirects & first entry from a different mask and start working through it.
You have to remember. When we did this there wasn't a public 8D bin that would assemble. Only C3 & 165 bins. This thread lead to a relocatable aujp bin being made public. Once you get this all figured out you'll understand what a big time saver that is. Well actually you already can see that... I currently have vehicles that run on $6E, $8D, and $OD masks. I wouldn't even think of doing that if it wasn't for the fact that all 3 have commented relocatable assemblies posted. The AUJP hac took over 165 hrs to cut and paste the comments and fix obvious to an amatuer errors. Think on that for a while along with your "take the easy way" comment. -and we are still fixing comment errors a few years later-
M6811 works just fine in XP or 98SE. Or DOS 6.22. It's just a matter of getting your OS to work with M6811. I did the $58 on a 266 running 98SE with 64m of ram. Took less than an hour since I'd already done two 8d bins as practice to perfect my methodology of finding the clumps. Having a good text editor is a big time saver in this hobby. So is picking out the obvious as well as not so obvious hints that people will give you. You could be getting "silence" instead. I throw my "fits" offline and then try to ask the question a different way. Or simply put that issue on the back burner until I have sufficient knowledge to solve that problem. It took JP and I over a year to figure out the I/O control. And what little help we got left us sitting at the keyboard going "huh????" It eventually clicked. And we immediately fell into a ram access issue that took us another 6 months to figure out.
) 
for such questions. This thread is for advanced editing of the instructions that the ECM uses, compared to the basic tuning that you sound to be starting. Once you get to the point that you want to know every little bit about what the ECM is doing, this is the thread, but for most that are looking to tune their setup, this will be well over their heads, and they know what mask ID they're running. 
