Getting started w/ disassembly and commenting
05-26-2010, 04:18 PM
#1
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Getting started w/ disassembly and commenting
i've read through the source-code for dummies thread and picked up a little more knowledge from it than i had previously, but i still feel WAY behind the curve and like i've missed at least one major step somewhere. i'm attempting to use the little tutorial that techedge posted but i get to the point of "Indexed Call/Jump at $xxxx, may require a vector table" and instantly blank out. http://www.techedge.com.au/utils/dhc11tut.htm
i managed to get ahold of a BIN from a 95 Aurora(jumping off the deep end) and am trying without much success to get through the disassembly process. so i thought "i'll just go to something that has been thoroughly commented on before, like the 8D hack".
so i open up the techedge disassembler and basically repeat my actions except for obviously accounting for the differences that are present when dealing with the ANHT BIN compared to the Aurora 4.0 BIN.
i get to the point of looking in the DIS file for the referenced addresses, find them, then read this out of the tutorial: "The first indexed call is easy" and after that point i feel like someone dropped a brick on my head...
i've also read a bit from this doc:
http://www.hptuners.com/forum/showth...bling+obd1+bin
and get to roughly the same point before i start staring at the screen with my jaw open. i've also attempted this with the BUA BIN as well, and even though it's smaller, it's no less intimidating to me. i look and see roughly ~1800 bytes of calibration data and a WHOLE lot of insanity underneath it.
i've gotten ahold of the moto pink book and have read through the mnemonics section a few times and get the general idea of what the different commands do, but when i see them put into practice, i have NO idea how someone interprets a section of code into meaning "xxx table lookup subroutine"
i'd like to learn how to fish, rather than just having them being handed to me, ya know?
i managed to get ahold of a BIN from a 95 Aurora(jumping off the deep end) and am trying without much success to get through the disassembly process. so i thought "i'll just go to something that has been thoroughly commented on before, like the 8D hack".
so i open up the techedge disassembler and basically repeat my actions except for obviously accounting for the differences that are present when dealing with the ANHT BIN compared to the Aurora 4.0 BIN.
i get to the point of looking in the DIS file for the referenced addresses, find them, then read this out of the tutorial: "The first indexed call is easy" and after that point i feel like someone dropped a brick on my head...
i've also read a bit from this doc:
http://www.hptuners.com/forum/showth...bling+obd1+bin
and get to roughly the same point before i start staring at the screen with my jaw open. i've also attempted this with the BUA BIN as well, and even though it's smaller, it's no less intimidating to me. i look and see roughly ~1800 bytes of calibration data and a WHOLE lot of insanity underneath it.
i've gotten ahold of the moto pink book and have read through the mnemonics section a few times and get the general idea of what the different commands do, but when i see them put into practice, i have NO idea how someone interprets a section of code into meaning "xxx table lookup subroutine"
i'd like to learn how to fish, rather than just having them being handed to me, ya know?
05-28-2010, 11:03 PM
#2
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
For figuring addressing it is best to have the disassembler put the command and the command Opcode in its output.
Referencing the pink book to find the correct usage of each command by the opcode distiguishes the type of addressing used (at that time)
Commands can use different addressing, the opcode will tell exactly which and is a help sometimes.
Other than that I did not find the book any additional help. The chips used in the GM stuff just makes the std configurations confusing. Don't try to dig too deep at this point.
Indexing is just as you found it to be, hard to deal with. You must find the starting point to be able to index from it. That sometimes presents several possibilities every time you find one but there is no easy way but to try and document all of them and figure the entry point that loaded the register to be indexed from. Somewhere before the index call was a "LDX" with an address.
As far as future indexing, they still will start from the initial starting point until that register address is reloaded with a differnt one.
Begin by naming the ALDL output items and bits. Allot of things begin to be put into segments of code concerning them.
Next is to find the "Segment Table" that is the starting point list for all the routines in the code.
ScotSea gave me a good description of how the code segments run (for $8D may apply to the others as well)
The code runs like this:
Timing loop -> SUB0
Fuel loop -> SUB1
Timing loop ->SUB2
Fuel loop ->SUB3
Timing loop ->SUB4
Fuel loop ->SUB5
etc, until it gets to SUB15, then it starts all over again at:
Timing loop -> SUB0
The sub-loops are the other "segments" listed in the table. Try to get a name attached to each as soon as you can if you can figure what each relates to.
Here is the $8D segment table from AUJP and also shows how the locations are different in ANHT.
As you may know, the "Mask ID" keeps the calibration section the same but the code sections can differ.
FYI, This stuff will try your patience.
There are still several parts of the IAC control and shift light/TCC segments that I get a headache trying to follow.
The "staring at the screen with jaw open" is quite common here.
Sometimes you have to post up Q's to ask someone who has been through that particular section of code to get an answer to keep you moving forward.
HTH
Referencing the pink book to find the correct usage of each command by the opcode distiguishes the type of addressing used (at that time)
Commands can use different addressing, the opcode will tell exactly which and is a help sometimes.
Other than that I did not find the book any additional help. The chips used in the GM stuff just makes the std configurations confusing. Don't try to dig too deep at this point.
Indexing is just as you found it to be, hard to deal with. You must find the starting point to be able to index from it. That sometimes presents several possibilities every time you find one but there is no easy way but to try and document all of them and figure the entry point that loaded the register to be indexed from. Somewhere before the index call was a "LDX" with an address.
As far as future indexing, they still will start from the initial starting point until that register address is reloaded with a differnt one.
Begin by naming the ALDL output items and bits. Allot of things begin to be put into segments of code concerning them.
Next is to find the "Segment Table" that is the starting point list for all the routines in the code.
ScotSea gave me a good description of how the code segments run (for $8D may apply to the others as well)
The code runs like this:
Timing loop -> SUB0
Fuel loop -> SUB1
Timing loop ->SUB2
Fuel loop ->SUB3
Timing loop ->SUB4
Fuel loop ->SUB5
etc, until it gets to SUB15, then it starts all over again at:
Timing loop -> SUB0
The sub-loops are the other "segments" listed in the table. Try to get a name attached to each as soon as you can if you can figure what each relates to.
Here is the $8D segment table from AUJP and also shows how the locations are different in ANHT.
As you may know, the "Mask ID" keeps the calibration section the same but the code sections can differ.
Code:
TYPE 0x8D AUJP TYPE 0x32 ANHT ;------------------------------------------------------------------------------------------ ;LB6D8: .byte 0xCE,0x64 ; SEG 0, MAKE A/D BARO FROM MAP (Is 0xCE5C in ANHT) ; .byte 0xCE,0xC5 ; SEG 1, DESCRETE & PWM OUTPUT ROUTINE (Is 0xCEBD in ANHT) ; .byte 0xD1,0x29 ; SEG 2, OIL TEMP (Is 0xD121 in ANHT) ; .byte 0xD2,0x78 ; SEG 3, LOG RAM TO I^2U (Is 0xD270 in ANHT) ; .byte 0xD1,0x69 ; SEG 4, MISC 100 Msec ROUTINE (Is 0xD161 in ANHT) ; .byte 0xD2,0x85 ; SEG 5, A/C, C/L, TEST OF FAN (Is 0xD27D in ANHT) ; .byte 0xE4,0xC0 ; SEG 6, LOG RAM TO CPU, COOLANT, A/D CON (Is 0xE4B8 in ANHT) ; .byte 0xD5,0x14 ; SEG 7, LK UP COOL VAR'S (Is 0xD50C in ANHT) ; .byte 0xD5,0x64 ; SEG 8, ESC LOW OCTANE SPK MOD LOGIC (Is 0xD55C in ANHT) ; .byte 0xD5,0xCE ; SEG 9, AIR MANAGMENT (Is 0xD5C6 in ANHT) ; .byte 0xD6,0xC9 ; SEG A, KNOCK, MAT IAC VAR'S, ETC... (Is 0xD6C1 in ANHT) ; .byte 0xD8,0x1A ; SEG B, EGR (Is 0xD812 in ANHT) ; .byte 0xD8,0x85 ; SEG C, CCP (Is 0xD87D in ANHT) ; .byte 0xDA,0x04 ; SEG D, DIAGNOSTICS (Is 0xD9FC in ANHT) ; .byte 0xDE,0x51 ; SEG E, BATT VDC, TCC, CARS, E LITE (Is 0xDE49 in ANHT) ; .byte 0xE1,0xCE ; SEG F, AIR/FUEL MAJOR (Is 0xE1C6 in ANHT)
There are still several parts of the IAC control and shift light/TCC segments that I get a headache trying to follow.
The "staring at the screen with jaw open" is quite common here.
Sometimes you have to post up Q's to ask someone who has been through that particular section of code to get an answer to keep you moving forward.
HTH
05-29-2010, 12:49 AM
#3
Member
Join Date: Dec 2007
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Robert, are you trying to understand the vector table addressing, or trying to get to the next step in the disassembly? 2 different things in that tutorial. If you are trying to add the next command to the control file, use the B register value to add vectors. If you have it disassembled and are trying to understand what that code segment is doing, it goes something like this (I don't have the pink book in front of me, so this is from memory and I might get it a little mixed up, but it will be close)
"D1EA LD1EA ldaB L01BE" load the b register with the value found at L01BE
"D1ED cmpB #$0A" compare the B register with 10 (#0A)
"D1EF bhi LD235" if it is greater than 10 we are pointing past the end of the table so branch
"D1F1 bset L005E, #%00100000" not sure what this is doing other that setting a bit at 5E
"D1F4 bset L005D, #%00000100" and 5D
"D1F7 staB L01B9" save the B register at L0B9
"D1FA lslB" left shift register B (multiply by 2) this to to point to the next entry in the table
"D204 ldX #$D249" load the X register with the table address (its at D249)
"D207 aBX" add the B and X register together
"D208 ldX 0, X" load the X register with the address pointed to by the X register
"D20A call 0, X" call the routine at that address.
".... ..."
";"
"D39E LD39E ldY L01B2"
"D3A2 call 0, Y"
The address D249 is a table that contains 10 addresses of routines you will be calling, what that routine does is creates a pointer into the table to address the correct routine. And yes you will spend a lot of time pounding your head with bricks.
JP was a big help to me when I started trying to create a $0D source and I skipped the hard part that you are attempting and just modified an existing source file to reflect the bin I was interested in using. Good luck
"D1EA LD1EA ldaB L01BE" load the b register with the value found at L01BE
"D1ED cmpB #$0A" compare the B register with 10 (#0A)
"D1EF bhi LD235" if it is greater than 10 we are pointing past the end of the table so branch
"D1F1 bset L005E, #%00100000" not sure what this is doing other that setting a bit at 5E
"D1F4 bset L005D, #%00000100" and 5D
"D1F7 staB L01B9" save the B register at L0B9
"D1FA lslB" left shift register B (multiply by 2) this to to point to the next entry in the table
"D204 ldX #$D249" load the X register with the table address (its at D249)
"D207 aBX" add the B and X register together
"D208 ldX 0, X" load the X register with the address pointed to by the X register
"D20A call 0, X" call the routine at that address.
".... ..."
";"
"D39E LD39E ldY L01B2"
"D3A2 call 0, Y"
The address D249 is a table that contains 10 addresses of routines you will be calling, what that routine does is creates a pointer into the table to address the correct routine. And yes you will spend a lot of time pounding your head with bricks.
JP was a big help to me when I started trying to create a $0D source and I skipped the hard part that you are attempting and just modified an existing source file to reflect the bin I was interested in using. Good luck
Last edited by jim_in_dorris; 05-29-2010 at 12:57 AM.
05-29-2010, 12:54 AM
#4
Supreme Member
iTrader: (2)
Join Date: Feb 2009
Location: Delaware
Posts: 1,450
Likes: 0
Received 1 Like
on
1 Post
Car: Lots of 'em
Re: Getting started w/ disassembly and commenting
ScotSea gave me a good description of how the code segments run (for $8D may apply to the others as well)
The code runs like this:
Timing loop -> SUB0
Fuel loop -> SUB1
Timing loop ->SUB2
Fuel loop ->SUB3
Timing loop ->SUB4
Fuel loop ->SUB5
etc, until it gets to SUB15, then it starts all over again at:
Timing loop -> SUB0
The sub-loops are the other "segments" listed in the table. Try to get a name attached to each as soon as you can if you can figure what each relates to.
Here is the $8D segment table from AUJP and also shows how the locations are different in ANHT.
As you may know, the "Mask ID" keeps the calibration section the same but the code sections can differ.
Code:
TYPE 0x8D AUJP TYPE 0x32 ANHT ;------------------------------------------------------------------------------------------ ;LB6D8: .byte 0xCE,0x64 ; SEG 0, MAKE A/D BARO FROM MAP (Is 0xCE5C in ANHT) ; .byte 0xCE,0xC5 ; SEG 1, DESCRETE & PWM OUTPUT ROUTINE (Is 0xCEBD in ANHT) ; .byte 0xD1,0x29 ; SEG 2, OIL TEMP (Is 0xD121 in ANHT) ; .byte 0xD2,0x78 ; SEG 3, LOG RAM TO I^2U (Is 0xD270 in ANHT) ; .byte 0xD1,0x69 ; SEG 4, MISC 100 Msec ROUTINE (Is 0xD161 in ANHT) ; .byte 0xD2,0x85 ; SEG 5, A/C, C/L, TEST OF FAN (Is 0xD27D in ANHT) ; .byte 0xE4,0xC0 ; SEG 6, LOG RAM TO CPU, COOLANT, A/D CON (Is 0xE4B8 in ANHT) ; .byte 0xD5,0x14 ; SEG 7, LK UP COOL VAR'S (Is 0xD50C in ANHT) ; .byte 0xD5,0x64 ; SEG 8, ESC LOW OCTANE SPK MOD LOGIC (Is 0xD55C in ANHT) ; .byte 0xD5,0xCE ; SEG 9, AIR MANAGMENT (Is 0xD5C6 in ANHT) ; .byte 0xD6,0xC9 ; SEG A, KNOCK, MAT IAC VAR'S, ETC... (Is 0xD6C1 in ANHT) ; .byte 0xD8,0x1A ; SEG B, EGR (Is 0xD812 in ANHT) ; .byte 0xD8,0x85 ; SEG C, CCP (Is 0xD87D in ANHT) ; .byte 0xDA,0x04 ; SEG D, DIAGNOSTICS (Is 0xD9FC in ANHT) ; .byte 0xDE,0x51 ; SEG E, BATT VDC, TCC, CARS, E LITE (Is 0xDE49 in ANHT) ; .byte 0xE1,0xCE ; SEG F, AIR/FUEL MAJOR (Is 0xE1C6 in ANHT)
05-29-2010, 01:09 AM
#5
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
and
"D1F1 bset L005E, #%00100000"
"D1F4 bset L005D, #%00000100"
first impression: WTF? i understood everything up until this point, then wonder where the binary numbering came from or what it means.
"D208 ldX 0, X" load the X register with the address pointed to by the X register
"D20A call 0, X" call the routine at that address.
understood up until this point as well, then got confused by the 0... address 0?
i'm guessing this is one of those different addressing modes or something?i'm tempted to post the BIN and my control file thus far so someone can walk me through it... this is the type of stuff that needs to sink in a bit before i'll be able to actually understand it.
05-29-2010, 08:00 AM
#6
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,401
Likes: 0
Received 215 Likes
on
201 Posts
Car: check
Engine: check
Transmission: check
Re: Getting started w/ disassembly and commenting
In the pink book, the section on the CPU (section 6), subsection 4 (6.4) Addressing Modes. This will explain about the various addressing modes. Including indexed. Which is what you are seeing (LDAA 0, X).
X has been loaded with an address, with the 0 of the instruction being an offset of that address. So can use 1,X for the next byte, and 2,X for the byte after that one and so on.
Then subsection 5 (6.5) explains the various instructions and how they work.
BSET L005E, #%00100000
Sets bit 5 of the data in RAM location $5E. Instruction can also be written, and more correctly, as:
BSET L005E, #$20
Whatever you do, stay away from the techwall.com.au stuff, it'll make your brain rot.
RBob.
X has been loaded with an address, with the 0 of the instruction being an offset of that address. So can use 1,X for the next byte, and 2,X for the byte after that one and so on.
Then subsection 5 (6.5) explains the various instructions and how they work.
BSET L005E, #%00100000
Sets bit 5 of the data in RAM location $5E. Instruction can also be written, and more correctly, as:
BSET L005E, #$20
Whatever you do, stay away from the techwall.com.au stuff, it'll make your brain rot.
RBob.
05-29-2010, 11:23 PM
#7
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
The binary display is from the disassembler.
There "should" be a switch to allow you to see the values in hex (my preference).
The default for that one must be binary.
There "should" be a switch to allow you to see the values in hex (my preference).
The default for that one must be binary.
Trending Topics
06-08-2010, 05:27 AM
#8
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Re: Getting started w/ disassembly and commenting
You might want to have a look at the $0D hack that I made awhile back. Its not a car, but it is a PCM, is very well commented, and had the e-trans code in it. It will likely be quite different than your aurora, but it will add more info for you to look at and compare. Its posted here: https://www.thirdgen.org/forums/diy-...0d-source.html
If you can get ahold of the ALDL definitions, those will be your biggest asset. That is the usual way in to the PCMs source code when your hacking. One problem is, though, that the OBD 1/1.5 PCMs where not standardized like the OBD-2 ones. That means that if you dont have the ALDL stream definitions, your going to have a much harder time reversing it as you cant simply just look at the SAE docs to figure out what is what in the diag. datastream.
If you can get ahold of the ALDL definitions, those will be your biggest asset. That is the usual way in to the PCMs source code when your hacking. One problem is, though, that the OBD 1/1.5 PCMs where not standardized like the OBD-2 ones. That means that if you dont have the ALDL stream definitions, your going to have a much harder time reversing it as you cant simply just look at the SAE docs to figure out what is what in the diag. datastream.
06-08-2010, 12:16 PM
#9
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
You might want to have a look at the $0D hack that I made awhile back. Its not a car, but it is a PCM, is very well commented, and had the e-trans code in it. It will likely be quite different than your aurora, but it will add more info for you to look at and compare. Its posted here: https://www.thirdgen.org/forums/diy-...0d-source.html
If you can get ahold of the ALDL definitions, those will be your biggest asset. That is the usual way in to the PCMs source code when your hacking. One problem is, though, that the OBD 1/1.5 PCMs where not standardized like the OBD-2 ones. That means that if you dont have the ALDL stream definitions, your going to have a much harder time reversing it as you cant simply just look at the SAE docs to figure out what is what in the diag. datastream.
If you can get ahold of the ALDL definitions, those will be your biggest asset. That is the usual way in to the PCMs source code when your hacking. One problem is, though, that the OBD 1/1.5 PCMs where not standardized like the OBD-2 ones. That means that if you dont have the ALDL stream definitions, your going to have a much harder time reversing it as you cant simply just look at the SAE docs to figure out what is what in the diag. datastream.
i'll be sure to check that thread over, and maybe i can get started on this again, now that i'm not hopped up on vicodin due to a massive ingrown toenail.
06-25-2010, 11:37 PM
#10
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
well, thought i would update the thread...
this is something i cannot do. i try and i try, but i just cannot understand stuff that is this low of a level... i've looked at people's patches and stuff before, and all of the commands(opcodes?) make sense, but trying to start on my own, or even looking at an already commented disassembly and trying to recreate the steps necessary to determine what exactly is going on? it is out of my reach. i've done a LITTLE bit of higher level coding before, but this stuff makes my mind hurt something fierce...
so, for those of you that responded, thank you for the time and the effort, maybe it will help someone in the future...
and in case anyone wants to play with the 4.0Aurora BIN, here it is, maybe you'll get further than i did.
this is something i cannot do. i try and i try, but i just cannot understand stuff that is this low of a level... i've looked at people's patches and stuff before, and all of the commands(opcodes?) make sense, but trying to start on my own, or even looking at an already commented disassembly and trying to recreate the steps necessary to determine what exactly is going on? it is out of my reach. i've done a LITTLE bit of higher level coding before, but this stuff makes my mind hurt something fierce...
so, for those of you that responded, thank you for the time and the effort, maybe it will help someone in the future...
and in case anyone wants to play with the 4.0Aurora BIN, here it is, maybe you'll get further than i did.
07-15-2010, 10:46 PM
#11
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
well, i'm either persistant or don't know when to give up, i'll leave that for everyone else to decide...
i'm going through a $2E hack and making a XDF due to me possibly swapping to the 6397(IIRC) it runs on...
now i've gotten down to the datastream, but i've tried looking at instruction area of the document as necessary, i THINK i'm understanding more of it as i go on, but i got the urge to make a tiny change or two to help out with tuning later, like showing the target AFR or raw MAF in place of some of the less important values, like PROM ID and runtime. seems simple enough, just swap the RAM or PROM locations of the ones i don't want with the ones i do and change the logging definition to match.
here's one of my major sources of confusion: what the "L" does to anything...
here's an example:
now, i took a look at the ALDL list and it looks like 00B3 is used to "define" that the INT is used, not 00B2.
so, i'm just looking for confirmation that i have to use the "L" value when swapping stuff like this.
this is finally getting to be enjoyable.
i'm going through a $2E hack and making a XDF due to me possibly swapping to the 6397(IIRC) it runs on...
now i've gotten down to the datastream, but i've tried looking at instruction area of the document as necessary, i THINK i'm understanding more of it as i go on, but i got the urge to make a tiny change or two to help out with tuning later, like showing the target AFR or raw MAF in place of some of the less important values, like PROM ID and runtime. seems simple enough, just swap the RAM or PROM locations of the ones i don't want with the ones i do and change the logging definition to match.
here's one of my major sources of confusion: what the "L" does to anything...
here's an example:
Code:
00B2 L00B3 = 0x00B3 ;INTEGRATOR - ALDL LIST
00B4 L00B5 = 0x00B5 ;FAR MSB
00B5 L00B6 = 0x00B6 ;FAR LSB
;AFR = 65536/[40*(MSB*256+LSB)] Code:
934C 00B3 21 ;INTEGRATOR
this is finally getting to be enjoyable.
07-16-2010, 12:12 AM
#12
Member
Join Date: Dec 2007
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Robert, The "L" in this case refers to the fact that "L" means label. If you look in the pink book, all the labels have an "L" in front of them to let the assembler know that they are labels, not instructions. Most of the time, the label ie L00B3 is located at the memory location the label is refering to. That is to say L00B3 is located at memory location 0x00B3. This allows you to reference a memory location or more likely, to branch to that location.
Last edited by jim_in_dorris; 07-16-2010 at 12:16 AM.
07-16-2010, 06:11 PM
#13
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
I think I see your confusion.
Disregard the "address" indication in the variable declaration section. (top of the disassembly)
These are only relevant once you get to your actual calibration values (bin starting point)
This may be at $4000 in $6E or at $8000 in $8D code. Not sure where in that bin you have. Will be as soon as all the "=" declarations stop.
After that point then they should match the labels for position.
Your TP definition will be set in the header to offset to that position.
Then the locations increment from there.
"L00B3" is the name of the value at memory location 0x00B3 is good to know that is the value you want to display.
You will need to follow down the addressing on the left side until you find the location in the ALDL stream you want to replace.
Use that "address" in yout TP definition.
The header of the XDF will offset to the starting address and be in the same position.
Hope that makes sense to you (typing fast, have to cook dinner)
Jp
Disregard the "address" indication in the variable declaration section. (top of the disassembly)
These are only relevant once you get to your actual calibration values (bin starting point)
This may be at $4000 in $6E or at $8000 in $8D code. Not sure where in that bin you have. Will be as soon as all the "=" declarations stop.
After that point then they should match the labels for position.
Your TP definition will be set in the header to offset to that position.
Then the locations increment from there.
"L00B3" is the name of the value at memory location 0x00B3 is good to know that is the value you want to display.
You will need to follow down the addressing on the left side until you find the location in the ALDL stream you want to replace.
Use that "address" in yout TP definition.
The header of the XDF will offset to the starting address and be in the same position.
Hope that makes sense to you (typing fast, have to cook dinner)
Jp
Last edited by JP86SS; 07-16-2010 at 06:14 PM.
07-16-2010, 06:30 PM
#14
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
about as clear as mud...
"variable declaration section" ok, that's more or less RAM locations where the processor stores values when they're not in the accumulator/register/???, correct?
since i'm currently dealing with a 32KB BIN, which is what 8D is as well, i understand the $8000 portion, since everything before that isn't in the BIN at all, but it has something to do with the "working space" that the processor has and where things are in that space pretty much defines what they are, like locations from $0000 to $xxxx being onboard RAM, while stuff from $4000-$xxxx are something entirely different.
so, from the sounds of it the "locations" before $8000 aren't necessarily locations at all, but can just be representations instead?
"variable declaration section" ok, that's more or less RAM locations where the processor stores values when they're not in the accumulator/register/???, correct?
since i'm currently dealing with a 32KB BIN, which is what 8D is as well, i understand the $8000 portion, since everything before that isn't in the BIN at all, but it has something to do with the "working space" that the processor has and where things are in that space pretty much defines what they are, like locations from $0000 to $xxxx being onboard RAM, while stuff from $4000-$xxxx are something entirely different.
so, from the sounds of it the "locations" before $8000 aren't necessarily locations at all, but can just be representations instead?
07-16-2010, 09:33 PM
#15
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
They are actual locations but should be "called" using the label.
That's why I suggested to not use the direct address indicated by the disassembly. Its really the same thing only the label keeps you working with the defined variable and ignoring counting errors.
Like shown in this segment of code, The RAM addresses do match the physical locations. Once you know where the value you desire is being stored all is good.
Once you get to the actual calibration section of the bin you see the addresses start at the offset address ($8000 in this case)
From there you just need to find the ALDL stream location and substitute the variable address from RAM.
The datastream is at the end of the cal section in $8D, yours may be the similar.
The ALDL command begins like this. You may be able to find the beginning of it by finding the "0000" and then "F4"
There will be a bunch of word size items after that.
Here is a snippet from my ALDL
The code samples were taken from the assembler LST file that indicates line numbers as well as addresses. Ignore the column of line numbers of 1834 and up.
You can see how the addreess of the location is indicated with how to setup the TP definition.
HTH
Jp
That's why I suggested to not use the direct address indicated by the disassembly. Its really the same thing only the label keeps you working with the defined variable and ignoring counting errors.
Code:
5800 1834 L5800 = 0x5800 ; On board ROM subroutines (H.U.) ; CRef: 0xC901; DRef: 0xE4C0
5803 1835 L5803 = 0x5803 ; To HU for SPK ADV MOD Modification; CRef: 0xBB44
5806 1836 L5806 = 0x5806 ; DISP SA IF IM IS CONNECTED ; CRef: 0xBC75
5809 1837 L5809 = 0x5809 ; IAC FROM HUD ; CRef: 0xE70E
580C 1838 L580C = 0x580C ; HEADS UP CODE ; CRef: 0xD867
580F 1839 L580F = 0x580F ; HEADS UP CODE ; CRef: 0xD97E
5812 1840 L5812 = 0x5812 ; I^2U CODE ; CRef: 0xD27C
5B32 1841 L5B32 = 0x5B32 ; IM PRESENCE CHECK ; CRef: 0xE4C8
6000 1842 rtirtn= 0x6000 ; SWI ; CRef: 0xFFF0,0xFFF6
6000 1843 swirtn= 0x6000 ; SWI ; CRef: 0xFFF0,0xFFF6
1844
1845 ;*************************************************************************************************
1846 .area CAL1 (ABS)
8000 1847 .org 0x8000
1848 ;**************************************************************************************************
8000 10 29 1849 L8000: .byte 0x10,0x29 ;EPROM ID, VIEW AS HEX ; DRef: 0xECDC (S_V4, Was 0x02,0x3B)
1850 ; Use MSB = SL Version)
1851 ; Use LSB = JP Version)
8002 04 10 1852 L8002: .byte 0x04,0x10 ;DATE CODE, (04-03-10) ; DRef: 0xECE1 (S_V4, Was 0x0B,0x4A)
8004 4A 4A 1853 L8004: .byte 0x4A,0x4A ;SEQ NUM, ; DRef: 0xECE6 (S_V4, Was 0x05,0x70)
8006 13 6A 1854 L8006: .byte 0x13,0x6A ;CHECK SUM, ; DRef: 0xEC9A
8008 8D 1855 L8008: .byte 0x8D ;ECM ID BYTE, ; DRef: 0xB071
8009 00 1856 L8009: .byte 0x00 ;NUMBER OF CYLINDERS =8 ; DRef: 0xB7BF Once you get to the actual calibration section of the bin you see the addresses start at the offset address ($8000 in this case)
From there you just need to find the ALDL stream location and substitute the variable address from RAM.
The datastream is at the end of the cal section in $8D, yours may be the similar.
The ALDL command begins like this. You may be able to find the beginning of it by finding the "0000" and then "F4"
Code:
88C4 00 00 5310 L88C4: .word 0x0000 ; NEXT MSG ENTRY ADDRESS 88C6 F4 5311 .byte 0xF4 ; DEVICE ID 88C7 80 5312 .byte 0x80 ; MEM FLAG, OUTPUT IS ROM TABLE
Here is a snippet from my ALDL
Code:
5384 ;---------------------------------------------------
88DD 00 60 5385 .word 0x0060 ; 9. Startup COOLANT TEMP(.word 0x0060)
5386 ; Alternate Use ,EGT Counts (Pin F11, U6 Ch 2 input) Use 012A
5387 ; (DEG C + 40) * (256/192)
5388 ; (Deg C = (N * 0.75) -40)
5389 ; To change: Use Address L88DD 16 bit, 4 significant digits
5390 ;---------------------------------------------------
88DF 00 94 5391 .word 0x0094 ; 10. A/D TPS Counts
5392 ; Counts only , Volts = N *(5/255)
5393 ; Alternate Use: (Was Simulated NB from LC-1 0x01B9)
5394 ; To change: Use Address L88DF 16 bit, 4 significant digits
5395 ;---------------------------------------------------
88E1 00 58 5396 .word 0x0058 ; 11. RPM, RPM/25, (RPM = N * 25) You can see how the addreess of the location is indicated with how to setup the TP definition.
HTH
Jp
Last edited by JP86SS; 07-16-2010 at 09:38 PM.
07-17-2010, 05:40 PM
#16
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
shifting gears a bit due to learning more....
jumping back to the disassembling tutorial, i feel that i've been successful in a few places, but others aren't making sense... one example being that i now understand the purpose of vectors a little bit more.
in an A1 BIN, i've determined that there were 11 vectors listed at the end of file, then found another vector table at A519 using the "call" listed a few bytes above it. that had 16 "loops" and then a RTS command. so i entered that info in the control file and ran the disassembler again. this comes up
so i jump down around 901C and see this:
now, it comes out to an odd number of bytes, which confuses me since AFAIK, all of these values should be 2 bytes in length.
so i go and check the other "indexed call" at EDB1, which hasn't been touched yet. i find this monstrosity:
now, this one at least comes out to an even number of bytes, assuming that $39 on the end is a location, not the $39(RTS) code/opcode/command, whatever it is.
does that need to be defined in the control file as well? at this point, i haven't gotten any further, just occasionally looking at it, hoping it will click together while working on making the 2E hack into an XDF.
jumping back to the disassembling tutorial, i feel that i've been successful in a few places, but others aren't making sense... one example being that i now understand the purpose of vectors a little bit more.
in an A1 BIN, i've determined that there were 11 vectors listed at the end of file, then found another vector table at A519 using the "call" listed a few bytes above it. that had 16 "loops" and then a RTS command. so i entered that info in the control file and ran the disassembler again. this comes up
Code:
Input file: BFBD.bin
Input file BFBD.bin has 32768 bytes ($8000).
Code resides from $8000 to $FFFF ($8000 bytes).
** Symbol "hc11vec_03" is already Install at $6000 ("hc11vec_06" requested)
** Symbol "hc11vec_07" is already Install at $A000 ("hc11vec_08" requested)
** Symbol "hc11vec_07" is already Install at $A000 ("hc11vec_09" requested)
** Symbol "hc11vec_07" is already Install at $A000 ("hc11vec_10" requested)
Output file: BFBD.DIS
Indexed Call/Jump at $901C, may require a vector table.
Indexed Call/Jump at $A503, may require a vector table.
Entry point $5938 outside ROM image (ref. from PC = $A510).
Entry point $5109 outside ROM image (ref. from PC = $AE15).
Entry point $510C outside ROM image (ref. from PC = $AF1D).
Entry point $5103 outside ROM image (ref. from PC = $B157).
Entry point $510F outside ROM image (ref. from PC = $C045).
Entry point $5100 outside ROM image (ref. from PC = $C474).
Entry point $5118 outside ROM image (ref. from PC = $DF12).
Entry point $511B outside ROM image (ref. from PC = $E26C).
Entry point $5115 outside ROM image (ref. from PC = $E2E5).
Indexed Call/Jump at $EDB1, may require a vector table.
Entry point $5106 outside ROM image (ref. from PC = $F89F).
Entry point $5112 outside ROM image (ref. from PC = $F8B0).
Pass 1 found 2984 new entry points.
Pass 2 found 194 new entry points.
Pass 3 found 0 new entry points.
Total of 3 iteration(s) to find all code. Code:
9009 hc11vec_02: 9009 subA #$00 900B subA #$01 900D test 900E lslD 900F test 9010 tAP 9011 test 9012 tPA 9013 test 9014 incX 9015 test 9016 xorB 0, X 9018 andA 0, X 901A tst 0, X 901C jmp 0, X ; ; 901E db $62, $FF, $FF, $00, $50, $FF, $FF, $00, $F0, $00 9028 db $65, $00, $69, $00, $4D, $00, $63, $01, $03, $00 9032 db $8E, $00, $CE, $00, $CA, $00, $87, $00, $17, $00 903C db $C8, $00, $C9, $00, $1E, $00, $54, $00, $4F, $00 9046 db $E5, $00, $FB, $01, $48, $00, $6C, $00, $19, $01 9050 db $85, $00, $AD, $FF, $FF, $00, $B9, $00, $B6, $00 905A db $88, $FF, $FF, $01, $AE, $01, $D1, $00, $A8, $00 9064 db $AE, $00, $E1, $FF, $FF, $00, $15, $01, $81, $00 906E db $AF, $00, $C0, $00, $BF, $00, $2B, $00, $2C, $00 9078 db $2D, $00, $2E, $00, $36, $00, $27, $00, $01, $00 9082 db $38, $00, $39, $00, $43, $00, $00, $F4, $40, $41 908C db $01, $19, $01, $19, $00, $00, $F4, $40, $09, $01 9096 db $19, $01, $19, $00, $00, $F4, $00, $01, $01, $19 90A0 db $01, $19, $00, $00, $F4, $80, $02, $01, $19, $01 90AA db $19, $01, $12, $00, $00, $F4, $20, $00, $01, $19 90B4 db $01, $19, $00, $00, $F4, $20, $00, $01, $19, $01 90BE db $19, $00, $00, $F4, $00, $01, $01, $19, $01, $19 90C8 db $00, $00, $F4, $00, $01, $01, $19, $01, $19, $00 90D2 db $00, $F4, $00, $01, $01, $19, $01, $19, $00
so i go and check the other "indexed call" at EDB1, which hasn't been touched yet. i find this monstrosity:
Code:
ED88 LED88 ldaA 2, X ED8A staA L010A ED8D staB L0118 ED90 ldaB L010B ED93 beq LEDE8 ED95 bset L0003, #%00100000 ED98 bset L0002, #%00000100 ED9B ldaB L0119 ED9E staB L010C EDA1 lslB EDA2 ldX #$8F72 EDA5 aBX EDA6 ldX 9, X EDA8 stX L0108 EDAB ldX #$EDFC EDAE aBX EDAF ldX 0, X EDB1 call 0, X EDB3 ldX L0108 EDB6 brset 3, X, #%00100000, LEDE8 EDBA ldaB L4008 EDBD ldaA 2, X EDBF staA L400A EDC2 staA L0107 EDC5 ldaB #$01 EDC7 staB L0106 EDCA bset L0002, #%01000000 EDCD ldX #$00C0 EDD0 bset 0, X, #%00000001 EDD3 ldaA 0, X EDD5 ldX #$4002 EDD8 bclr 0, X, #%10000000 EDDB call LFD8C EDDE bset 0, X, #%10000000 EDE1 ldaA #$89 EDE3 staA L4007 EDE6 jr LEDFB ; EDE8 LEDE8 clrA EDE9 clrB EDEA stD L0108 EDED stD L0106 EDF0 bclr L0002, #%00100000 EDF3 bset L0003, #%00000100 EDF6 ldaA #$27 EDF8 staA L4007 EDFB LEDFB ret ; ; EDFC db $EE, $12, $EE, $19, $EE, $2B, $EE, $2C, $EE, $2D EE06 db $EE, $46, $EE, $B6, $EE, $B7, $EE, $DB, $EE, $DF EE10 db $EE, $E3, $15, $02, $01, $15, $03, $20, $39, $CE EE1A db $8F, $9A, $F6, $01, $1A, $C1, $01, $24, $02, $58 EE24 db $3A, $EE, $00, $FF, $01, $08, $39, $39, $39, $B6 EE2E db $01, $0B, $27, $13, $14, $03, $40, $FE, $01, $10 EE38 db $26, $0B, $CE, $01, $19, $E6, $00, $E7, $22, $08 EE42 db $4A, $26, $F8, $39, $13, $2B, $80, $06, $86, $55 EE4C db $B7, $01, $12, $39, $86, $AA, $B7, $01, $12, $CE EE56 db $40, $07, $1D, $00, $01, $BD, $F0, $3E, $CC, $D0 EE60 db $00, $FD, $3F, $DA, $BD, $DB, $D9, $FD, $3F, $D8 EE6A db $BD, $DB, $D9, $FD, $3F, $CC, $BD, $DC, $7D, $5F EE74 db $BD, $DC, $C5, $5F, $BD, $DD, $34, $B6, $40, $04 EE7E db $84, $FD, $BD, $DC, $F3, $3C, $CE, $40, $02, $1D EE88 db $00, $10, $15, $C0, $08, $1D, $00, $80, $96, $C0 EE92 db $BD, $FD, $8C, $1C, $00, $80, $38, $86, $FB, $BD EE9C db $F2, $39, $8E, $01, $FF, $14, $03, $80, $C6, $01 EEA6 db $18, $CE, $01, $12, $BD, $EF, $BD, $CE, $40, $07 EEB0 db $1D, $00, $F1, $7E, $EE, $E7, $39, $38, $15, $02 EEBA db $04, $CE, $8F, $2E, $F6, $01, $1A, $E1, $02, $27 EEC4 db $06, $EE, $00, $26, $F8, $20, $0D, $14, $03, $01 EECE db $BD, $EB, $1A, $13, $02, $40, $03, $7E, $ED, $FB EED8 db $7E, $ED, $E8, $14, $02, $01, $39, $15, $02, $01 EEE2 db $39, $14, $02, $02, $39, $86, $AA, $B7, $01, $12 EEEC db $97, $0C, $0F, $CC, $00, $00, $FD, $01, $17, $14 EEF6 db $03, $08, $8D, $02, $20, $F2, $CE, $40, $00, $86 EF00 db $04, $A7, $07, $EC, $08, $4F, $B7, $01, $07, $1C EF0A db $07, $02, $8D, $75, $81, $E0, $25, $F7, $B1, $8F EF14 db $6D, $27, $13, $8D, $6A, $80, $54, $B7, $01, $0B EF1E db $8D, $63, $7A, $01, $0B, $26, $F9, $5D, $26, $D4 EF28 db $20, $58, $8D, $57, $80, $56, $25, $CC, $B7, $01 EF32 db $0B, $8D, $4E, $81, $05, $26, $13, $8D, $48, $5D EF3C db $26, $BE, $14, $03, $80, $C6, $01, $18, $CE, $01 EF46 db $12, $BD, $EF, $BD, $20, $36, $81, $06, $26, $FE EF50 db $8D, $31, $B7, $01, $13, $7A, $01, $0B, $8D, $29 EF5A db $B7, $01, $14, $7A, $01, $0B, $18, $FE, $01, $13 EF64 db $18, $8C, $00, $10, $23, $92, $8D, $17, $18, $A7 EF6E db $00, $18, $08, $7A, $01, $0B, $26, $F4, $8D, $0B EF78 db $5D, $26, $81, $18, $FE, $01, $13, $18, $AD, $00 EF82 db $39, $BD, $F0, $3E, $FC, $01, $17, $1A, $83, $02 EF8C db $80, $22, $FE, $7D, $40, $05, $2A, $05, $14, $03 EF96 db $08, $20, $0E, $13, $03, $08, $0A, $CB, $01, $89 EFA0 db $00, $FD, $01, $17, $15, $03, $08, $1F, $08, $0E EFAA db $04, $38, $7E, $EE, $FC, $1F, $08, $20, $D0, $A6 EFB4 db $09, $16, $FB, $01, $07, $F7, $01, $07, $39, $CE EFBE db $00, $C0, $1C, $00, $01, $A6, $00, $CE, $40, $02 EFC8 db $1D, $00, $80, $BD, $FD, $8C, $1C, $00, $80, $CE EFD2 db $40, $00, $86, $08, $A7, $07, $4F, $B7, $01, $07 EFDC db $F7, $01, $0B, $B6, $8F, $6D, $8D, $48, $86, $56 EFE6 db $BB, $01, $0B, $8D, $41, $86, $06, $13, $03, $80 EFF0 db $05, $86, $05, $15, $03, $80, $8D, $34, $B6, $01 EFFA db $0B, $27, $0D, $4A, $B7, $01, $0B, $18, $A6, $00 F004 db $18, $08, $8D, $24, $20, $EE, $B6, $01, $07, $40 F00E db $8D, $1C, $1F, $08, $40, $FC, $1D, $07, $08, $CE F018 db $00, $C0, $1D, $00, $01, $A6, $00, $CE, $40, $02 F022 db $1D, $00, $80, $BD, $FD, $8C, $1C, $00, $80, $39 F02C db $36, $BD, $F0, $3E, $1F, $08, $80, $F9, $32, $A7 F036 db $0A, $BB, $01, $07, $B7, $01, $07, $39, $3C, $CC F040 db $FF, $00, $FD, $40, $0B, $CE, $40, $02, $96, $04 F04A db $88, $02, $1C, $00, $04, $BD, $FD, $8C, $96, $04 F054 db $BD, $FD, $8C, $1D, $00, $04, $38, $39
does that need to be defined in the control file as well? at this point, i haven't gotten any further, just occasionally looking at it, hoping it will click together while working on making the 2E hack into an XDF.
07-18-2010, 10:13 PM
#17
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
jmp 0, X
This is an index address usage.
The command states to "jump" to the 0 position from the last address stored in the X register.
Since "0" is the first, it would be the address last stored in the "current" X register.
Sometimes finding that out is easy by trailing backwards in the code sequence.
Sometimes its VERY difficult to determine because multiple branches could have stored different things.
The control file declarations are to locate "code" sections that could be considered "data" as tables etc.
Sometimes you over do the control file and the disassembler converts data tables into meaningless code. The sections could actually be data.
When the "test" comes up a bunch of times in a section, I get weary of it being actual code.
This is an index address usage.
The command states to "jump" to the 0 position from the last address stored in the X register.
Since "0" is the first, it would be the address last stored in the "current" X register.
Sometimes finding that out is easy by trailing backwards in the code sequence.
Sometimes its VERY difficult to determine because multiple branches could have stored different things.
The control file declarations are to locate "code" sections that could be considered "data" as tables etc.
Sometimes you over do the control file and the disassembler converts data tables into meaningless code. The sections could actually be data.
When the "test" comes up a bunch of times in a section, I get weary of it being actual code.
07-18-2010, 10:35 PM
#18
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Re: Getting started w/ disassembly and commenting
I think I'm doing this right..
Relating to the "EDB1"
Load X with EDFC (above)
... Call to subroutine # 0 from current X register
EDFC indicates the address containg the value of the subroutine.
Check location $1502 for a subroutine. (or this is the beginning of a code segment that BCLR 02, clear bit 02)
BCLR = opcode 15 so its hard to say with this section.
EDFC appears to be the zero point of the index to some subroutines.
"B" register could be the sequencer value containing the next routine to run.
Can someone else confirm I'm correct on that.
Thx.
Relating to the "EDB1"
Code:
EDAB ldX #$EDFC EDAE aBX (Add B to X) B = ????? EDAF ldX 0, X EDB1 call 0, X
... Call to subroutine # 0 from current X register
Code:
EDFC db $EE, $12, $EE, $19, $EE, $2B, $EE, $2C, $EE, $2D EE06 db $EE, $46, $EE, $B6, $EE, $B7, $EE, $DB, $EE, $DF EE10 db $EE, $E3, $15, $02, $01, $15, $03, $20, $39, $CE EE1A db $8F, $9A, $F6, $01, $1A, $C1, $01, $24, $02, $58 EE24 db $3A, $EE, $00, $FF, $01, $08, $39, $39, $39, $B6 EE2E db $01, $0B, $27, $13, $14, $03, $40, $FE, $01, $10 EE38 db $26, $0B, $CE, $01, $19, $E6, $00, $E7, $22, $08 EE42 db $4A, $26, $F8, $39, $13, $2B, $80, $06, $86, $55
Check location $1502 for a subroutine. (or this is the beginning of a code segment that BCLR 02, clear bit 02)
BCLR = opcode 15 so its hard to say with this section.
EDFC appears to be the zero point of the index to some subroutines.
"B" register could be the sequencer value containing the next routine to run.
Can someone else confirm I'm correct on that.
Thx.
Last edited by JP86SS; 07-18-2010 at 10:49 PM.
07-18-2010, 10:51 PM
#19
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
actually, that's exactly what i needed to hear: the location of $9009 is actually the first byte of the datastream(PROM ID byte 1, location 8000) in another A1 hack...
so, that means it's not actually "vector 2". so does that mean i chop out that location from the control file as a vector? and i'm assuming the 2 before it, vec 0 and vec 1?
with the hack i have to reference, it ends like this: some simple counting reveals the "vec 2" i found before to be at FFEC, which apparently is a "TI2VEC"?
i am making some progress trying to interpret how and why some things work. i took a look at the lean cruise algorithm in the ARUR BIN and compared it to the BFBD BIN i used to get my wife's GP running, and though it seems that the instructions were shifted by 2 places, it otherwise came out identical(in RAM locations as well), but for some reason, it was not showing an AFR other than 14.7:1 in the datastream, even though near the end of it, it stores the accumulator to the same RAM location that the datastream recieves... so that tells me it never got into lean cruise.
still a rough learning curve, but i think i'm getting there. some of the opcodes as described in hacks are difficult to understand without a good understanding of binary...
so, that means it's not actually "vector 2". so does that mean i chop out that location from the control file as a vector? and i'm assuming the 2 before it, vec 0 and vec 1?
with the hack i have to reference, it ends like this:
Code:
FFD6 SCIVEC: .word SCIRTN FFD8 SPIVEC: .word SCIRTN FFDA PAIEVE: .word SCIRTN FFDC PAOVEC: .word SCIRTN FFDE TOVFVE: .word SCIRTN FFE0 TI4O5V: .word SCIRTN FFE2 TO4VEC: .word SCIRTN FFE4 TO3VEC: .word SCIRTN FFE6 TO2VEC: .word SCIRTN FFE8 TO1VEC: .word SCIRTN FFEA TI3VEC: .word TI3RTN FFEC TI2VEC: .word TI2RTN FFEE TI1VEC: .word TI1RTN FFF0 RTIVEC: .word RTIRTN FFF2 IRQVEC: .word IRQRTN FFF4 XIRQVE: .word XIRQRT FFF6 SWIVEC: .word RTIRTN FFF8 ILOPVE: .word ILOPRT FFFA COPVEC: .word ILOPRT FFFC COMONV: .word ILOPRT FFFE RSTVEC: .word ILOPRT 0000 ; .end
i am making some progress trying to interpret how and why some things work. i took a look at the lean cruise algorithm in the ARUR BIN and compared it to the BFBD BIN i used to get my wife's GP running, and though it seems that the instructions were shifted by 2 places, it otherwise came out identical(in RAM locations as well), but for some reason, it was not showing an AFR other than 14.7:1 in the datastream, even though near the end of it, it stores the accumulator to the same RAM location that the datastream recieves... so that tells me it never got into lean cruise.
still a rough learning curve, but i think i'm getting there. some of the opcodes as described in hacks are difficult to understand without a good understanding of binary...
07-21-2010, 02:39 AM
#20
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Re: Getting started w/ disassembly and commenting
The "TI" and "TO" refer to timer input and timer output interrupt vectors. IOW, these are the places that the PCM will go to when it either recieves an edge of a pulse on an input, or the time for an output has been met.
The others are SWI=software interrupt, XIRQ=non-maskable interrupt request, IRQ=interrupt request, COP=Computer operating properly, ILOP=illegal operation (reset), SCI=serial communications interface, SPI=serial peripheral interface, and PA=pulse accumulator.
The ones that are usually important are the XIRQ, and SCI. These will usually have the dist. or crank reference pulse (XIRQ) and the ALDL data (SCI) functions assigned to them.
The others are SWI=software interrupt, XIRQ=non-maskable interrupt request, IRQ=interrupt request, COP=Computer operating properly, ILOP=illegal operation (reset), SCI=serial communications interface, SPI=serial peripheral interface, and PA=pulse accumulator.
The ones that are usually important are the XIRQ, and SCI. These will usually have the dist. or crank reference pulse (XIRQ) and the ALDL data (SCI) functions assigned to them.
07-21-2010, 11:32 AM
#21
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
i don't suppose they are generally in any soecific order?
(other than the reset vector being the last two bytes)
(other than the reset vector being the last two bytes)
07-21-2010, 10:27 PM
#22
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Re: Getting started w/ disassembly and commenting
The power-up, reset, and IRQ vectors are in a specific order. The order of which will be defined in the manual for the processor thats in use in your specific PCM. In this case, I assume that its an 68HC11. The processor has them at fixed locations so it knows where to go to fetch the address of the next instruction when an interrupt happens.
08-29-2010, 05:34 PM
#23
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
ok, life started getting in the way for a while but now i'm considering stepping in a different direction... would something like IDA Pro make life easier? i've tried playing with it before but didn't get very far. hell, the inital setup after choosing the processor family confuses me.
09-06-2010, 07:49 PM
#24
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
well, i seem to have come across one of the reasons why i wanted to get into all of this in the first place...
someone on the 60V6 board had the idea of using a 2.8V6 as a generator since the car it came out of was wrecked and the motor was still running great. now to minimize fuel consumption and to maximize efficiency, the motor needs to run at peak torque, which we've estimated to be from 3600-4000 RPM. now, since the target idle speeds have a scaler of 12.5 and use 8 bit values, that leaves a maximum of just under 3200 RPM, which is under ideal.
what kind of trickery would it take for the ECM to use the scaler of 25 as used in almost all other RPM related values? is it just swapping a few bytes, or is it much more complicated than i am thinking....?
someone on the 60V6 board had the idea of using a 2.8V6 as a generator since the car it came out of was wrecked and the motor was still running great. now to minimize fuel consumption and to maximize efficiency, the motor needs to run at peak torque, which we've estimated to be from 3600-4000 RPM. now, since the target idle speeds have a scaler of 12.5 and use 8 bit values, that leaves a maximum of just under 3200 RPM, which is under ideal.
what kind of trickery would it take for the ECM to use the scaler of 25 as used in almost all other RPM related values? is it just swapping a few bytes, or is it much more complicated than i am thinking....?
09-07-2010, 07:58 PM
#25
Member
Join Date: Dec 2007
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Robert, 2 ideas here, 1 would be to use a potentiometer for the TPS signal, and the other would be to just create a TPS constant set to a value that runs at the peak torque 50 or 60% maybe.
09-07-2010, 08:04 PM
#26
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
turns out the guy has some kind of governer that opens/closes the throttle as needed, so that's no longer important...
i'd still like to have some idea how to mess with scaling factors though... it's one of the big mysteries i have yet to figure out.
i'd still like to have some idea how to mess with scaling factors though... it's one of the big mysteries i have yet to figure out.
12-17-2010, 11:54 AM
#27
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
slight change in plans... after doing a lot more research on the early northstar PCMs, i come across a couple of interesting things that i'm not too excited about....
1: the ISC; i'm not a fan of these things, and from what i read, they're prone to failure as well.
2: dual 64KB PROMs in the same MEMCAL; i have yet to actually see one, but they sound like a REAL PITA to deal with since i really don't have the patience for UV-erased anything, and i only have the engine side from what i can tell, since i've found what look to be VE and spark tables, which is going to be related to another question very shortly. not to mention the sheer amount of time i would have to put into trying to hack the thing.
3: no other P6 hacks that are similar enough to have some kind of idea what i'm jumping into, though if i ever get into dealing with the 93-95 flash based 3100/3.4 PCMs, i'm sure they're at least somewhat similar considering they are both running dual P6 processors, though the V6 stuff uses a pair of 32KB PROMs.
so, unless i somehow find myself owning a 93-95 Eldorado/Seville, i highly doubt i'll be looking to go through and try to comment the code as much as has been done for certain other masks. on the other hand, i would like to pull some of the more basic tables(main spark, VE, coolant based spark correction, etc) out of this calibration so that i would have a much better starting point in doing something like running a northstar on the A1 or 8D mask, or should the 4T80E be retained, on something like the 0D, 31, 0E or any other of the VERY well-defined truck masks that used a -E tranny.
i have done some digging around with the engine BIN for a 95 aurora, i've found what looks to be a VE table, high RPM VE table, main spark table, high RPM spark table, and 2 other main/high RPM spark tables that are the same size, i assume for either EGR or low octane tables, based on other things i've seen from the era.
now, i have NO idea how to determine the labels for either axis, it's something i've never understood about the 6811, i've seen some motronic stuff that has the labels more or less spelled out and were extremely easy to understand, but i'm not quite sure how to determine what the MAP and RPM labels are for this. and from what i can tell, they aren't quite like the normal P4 tables i've seen that have 3 bytes before the table to tell the processor what parameter to compared them against and the lowest value of one of the parameters(also something i've never understood).
so, what i'm asking is, how do i determine the scaling of the 15 X 17 main ve table, 13 X 17 high RRPM ve table, 15 X 17 main spark table, and the 13 X 17 high rpm spark table? i figure if those can be figured out, anything else should be fairly similar to determine as well.
ideally, i'd also like to get into pulling some of the code that is specific to the N* PCM, like the function that shuts off 4 injectors when coolant is extremely low to help prevent overheating, though i know i would need a relatively well documented SFI PCM to stick it back into...
1: the ISC; i'm not a fan of these things, and from what i read, they're prone to failure as well.
2: dual 64KB PROMs in the same MEMCAL; i have yet to actually see one, but they sound like a REAL PITA to deal with since i really don't have the patience for UV-erased anything, and i only have the engine side from what i can tell, since i've found what look to be VE and spark tables, which is going to be related to another question very shortly. not to mention the sheer amount of time i would have to put into trying to hack the thing.
3: no other P6 hacks that are similar enough to have some kind of idea what i'm jumping into, though if i ever get into dealing with the 93-95 flash based 3100/3.4 PCMs, i'm sure they're at least somewhat similar considering they are both running dual P6 processors, though the V6 stuff uses a pair of 32KB PROMs.
so, unless i somehow find myself owning a 93-95 Eldorado/Seville, i highly doubt i'll be looking to go through and try to comment the code as much as has been done for certain other masks. on the other hand, i would like to pull some of the more basic tables(main spark, VE, coolant based spark correction, etc) out of this calibration so that i would have a much better starting point in doing something like running a northstar on the A1 or 8D mask, or should the 4T80E be retained, on something like the 0D, 31, 0E or any other of the VERY well-defined truck masks that used a -E tranny.
i have done some digging around with the engine BIN for a 95 aurora, i've found what looks to be a VE table, high RPM VE table, main spark table, high RPM spark table, and 2 other main/high RPM spark tables that are the same size, i assume for either EGR or low octane tables, based on other things i've seen from the era.
now, i have NO idea how to determine the labels for either axis, it's something i've never understood about the 6811, i've seen some motronic stuff that has the labels more or less spelled out and were extremely easy to understand, but i'm not quite sure how to determine what the MAP and RPM labels are for this. and from what i can tell, they aren't quite like the normal P4 tables i've seen that have 3 bytes before the table to tell the processor what parameter to compared them against and the lowest value of one of the parameters(also something i've never understood).
so, what i'm asking is, how do i determine the scaling of the 15 X 17 main ve table, 13 X 17 high RRPM ve table, 15 X 17 main spark table, and the 13 X 17 high rpm spark table? i figure if those can be figured out, anything else should be fairly similar to determine as well.
ideally, i'd also like to get into pulling some of the code that is specific to the N* PCM, like the function that shuts off 4 injectors when coolant is extremely low to help prevent overheating, though i know i would need a relatively well documented SFI PCM to stick it back into...
12-18-2010, 10:38 AM
#28
Member
Join Date: Feb 2002
Posts: 156
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
In order to find the scaling you have to work backwards from the tables to find how the variables are built. For example if you are looking at the low RPM spark table at 9092 then you can search for where it is called. That is found at C0A0 and backing up to C092 the instruction start by loading 01C4 to A, 9192 to X, and 02B2 to B. Then 02B2 is checked for zero. If it is not zero then the 3D routine is run. If it is then 02B1 is loaded to B, and 9092 is loaded to X before the 3D routine is run. Now you know what variables to look at. Also understand the answers should make sense. MAP will be between 20 and 100 in multiples of 5 or 10. RPM will be reasonable for the engine and in multiples that make sense.
HTH
John
HTH
John
12-20-2010, 02:47 PM
#29
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
actually, i found more or less the same results while looking at a hack from a member here for the 8D mask(i figured it was likely the most popular and understood mask that uses 2 VE tables). i basically came up with this:
table explanations?
ldab the normalized MAP value
ldaa the unfiltered RPM
cmpa to the upper value of the lower table
branch to the appropriate section
lower VE algorithm:
ldx the table
suba a value to offset(basically make the lower limit)
bcc to see if it goes under the table lower limit, otherwise
clra to set RPM to 0
lsla
lsla (multiply RPM by 2.... twice...)
cmpb to h80(128), checks to see if MAP is less than or equal to 60kPa(this determines what sections of the table have 5kPa gaps or 10kPa gaps)
bls (if less than) to a lookup routine, otherwise
lsrb (Shift acc. B one bit right, clear b7, set carry flag if b0 was previously set), rescales for 10kPa per point?
addb h40(64), makes upper table value?
upper VE algorithm:
ldx the upper VE table
suba h40(64), sets the minimum value of the table(or does it make the make the maximum?)
lsrb (shifts B(MAP) to divide by 2?)
cmpa hA0(160) to see if at 4000 RPM
bls (branch if lower than 4000) to lookup routine, otherwise
ldaa hA0(160) to limit RPM to 5600 (A0 is 4000, but the 1600 RPM offset earlier makes 5600)
bra to lookup
3d lookup of VE
jsr to 3D lookup routine, and when RTS
psha to save uncorrected VE to stack
table explanations?
ldab the normalized MAP value
ldaa the unfiltered RPM
cmpa to the upper value of the lower table
branch to the appropriate section
lower VE algorithm:
ldx the table
suba a value to offset(basically make the lower limit)
bcc to see if it goes under the table lower limit, otherwise
clra to set RPM to 0
lsla
lsla (multiply RPM by 2.... twice...)
cmpb to h80(128), checks to see if MAP is less than or equal to 60kPa(this determines what sections of the table have 5kPa gaps or 10kPa gaps)
bls (if less than) to a lookup routine, otherwise
lsrb (Shift acc. B one bit right, clear b7, set carry flag if b0 was previously set), rescales for 10kPa per point?
addb h40(64), makes upper table value?
upper VE algorithm:
ldx the upper VE table
suba h40(64), sets the minimum value of the table(or does it make the make the maximum?)
lsrb (shifts B(MAP) to divide by 2?)
cmpa hA0(160) to see if at 4000 RPM
bls (branch if lower than 4000) to lookup routine, otherwise
ldaa hA0(160) to limit RPM to 5600 (A0 is 4000, but the 1600 RPM offset earlier makes 5600)
bra to lookup
3d lookup of VE
jsr to 3D lookup routine, and when RTS
psha to save uncorrected VE to stack
01-03-2011, 03:53 PM
#30
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
ok, been making a lot of progress with the A1 mask...
and i'm actually running some custom code ATM, seems to be working well... then again, it's only comparing a bit i setup to allow for switching between the modified VE and spark tables i intend to work on...
this is what i have so far, but i am stuck again when it comes to "seperating" the sections of the tables where i want larger and smaller intervals...
now, for the "low" VE and spark tables, i'm looking to start them at 400RPM, then go to 2000RPM, in 100 RPM increments, and MAP from 20 to 100 in 5kPa increments, which brings the table to 17 X 17. now for the VE example above, i have "00 00 11" in the 3 bytes in front of the table that X gets pointed at, which from what i understand, means the column and row minimum values will get offset by 00 compared to what i do in the algorithm, and the 11 is hex for 17, meaning 17 columns per row(or rows per column? i guess it really doesn't matter since it's 17 X 17).
now, i've tried doing some examples by hand, but i get lost in a few places as to how the 3D lookup routine actually interprets a few things. but if someone could basically look at the code i posted above, see if i'm missing anything gigantic, that would help me greatly to getting the rest of this finished.
also, since the upper VE and spark tables i'm looking to deal with end at 7500RPM, the RPM X25 variable isn't going to cut it... i've found a location in the RAM and confirmed that it holds RPM X 1(as a 16-bit value), but i'm unsure as to wether FDIV or IDIV is appropriate... and which value should go into X compared to D... i was going to attempt a RPM X 31.25, but the math is already going fuzzy for me, so a RPM X 50 should work.
that's what i've come up with for some example as to how i understand it would work... plausible?
and last thing: the scaling on the upper table's RPM: from 2000-4500RPM, i'd like to see 250 RPM increments, and from 4500-7500, 500, more or less tweaking what i've seen in the DA masks. i assume it would be a good time to switch between the X 25 and X 50 variables at the same time that i am doing the switch between the 250 and 500 RPM increments, possibly to make the algorithm easier to follow as well...
i'll have to save this page as a HTML file, the amount of time i have when solid internet access is around compared to time i have to mess with the code is a pretty large gap.... maybe i'll be able to answer a few of my own questions while i'm at it.
and i'm actually running some custom code ATM, seems to be working well... then again, it's only comparing a bit i setup to allow for switching between the modified VE and spark tables i intend to work on...
this is what i have so far, but i am stuck again when it comes to "seperating" the sections of the tables where i want larger and smaller intervals...
Code:
9270: LDAA L9263 (bitmask 1) 9273: BITA $1 (check bit 0) 9275: BNE $08 (branch to do VE lookups) 9277: LDAA L0062 (otherwise, continue with A1) 9279: LDX L8848 (...) 927C: JMP LB858 (return to A1 code) 927F: LDAB L0057 (normalized MAP variable) 9281: LDAA L00C4 (RPM X 12.5) 9283: CMPA $A0 (compare to 2000 RPM)(160) 9285: BCC $0A (branch if above 2000 RPM) 9287: LDX L9EDC (start of low VE table) 928A: SUBA $20 (subtract 400 to set lower limit of table) 928C: BCC ?? (branch if didn't go under 400 RPM)(branch to address after high RPM code to do 3D lookup) 928E: CLRA (otherwise, clear A to force 400 RPM) 928F: BRA ?? (and branch to address after high RPM code to do 3D lookup) 9291: LDAA L0062 (RPM X 25) 9293: CMPA $B4 (compare to 4500 RPM) 9295: BCC ?? (branch if above 4500 RPM) 9297: LDX L9DB8 (start of high VE table) 929A: SUBA $50 (subtract 2000 to set lower limit of table)
now, i've tried doing some examples by hand, but i get lost in a few places as to how the 3D lookup routine actually interprets a few things. but if someone could basically look at the code i posted above, see if i'm missing anything gigantic, that would help me greatly to getting the rest of this finished.
also, since the upper VE and spark tables i'm looking to deal with end at 7500RPM, the RPM X25 variable isn't going to cut it... i've found a location in the RAM and confirmed that it holds RPM X 1(as a 16-bit value), but i'm unsure as to wether FDIV or IDIV is appropriate... and which value should go into X compared to D... i was going to attempt a RPM X 31.25, but the math is already going fuzzy for me, so a RPM X 50 should work.
Code:
LDX d50 ($32) LDD L18F (16-bit RPM X 1 value) IDIV math is performed, leaving quotient in X and remainder in D CPD d25 ($19) to see if X should be rounded up or not BCC if under d25, branch to the PSHX, otherwise INX to add 1 to X PSHX to store to stack PULA pull MSB of X(not used) PULA pull LSB of X(RPM X 50) STAA to an open RAM location(byte L0053 seems to be free)
and last thing: the scaling on the upper table's RPM: from 2000-4500RPM, i'd like to see 250 RPM increments, and from 4500-7500, 500, more or less tweaking what i've seen in the DA masks. i assume it would be a good time to switch between the X 25 and X 50 variables at the same time that i am doing the switch between the 250 and 500 RPM increments, possibly to make the algorithm easier to follow as well...
i'll have to save this page as a HTML file, the amount of time i have when solid internet access is around compared to time i have to mess with the code is a pretty large gap.... maybe i'll be able to answer a few of my own questions while i'm at it.
01-04-2011, 12:43 AM
#31
Member
Join Date: Feb 2002
Posts: 156
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Your table should use $10. The 17 places are 0-16.
You also have to go back to clock cycles to expand RPM. RPM by 25 is some multiple of clock cycles in the denominator and 307 in the numerator.
307 /(clock * x) x = 2 if I recall correctly.
RPM by 31.25 is 983 / (clock * x * 4) Here you are replacing 307 with 245.75 to create a different scale.
I would do what was done in the Northstar code and create two rpm variables. Then load high table in X and high RPM in B. Next check B for 0. If it is greater then branch to lookup. Otherwise load low table in X and low RPM in B and then look up.
HTH
John
You also have to go back to clock cycles to expand RPM. RPM by 25 is some multiple of clock cycles in the denominator and 307 in the numerator.
307 /(clock * x) x = 2 if I recall correctly.
RPM by 31.25 is 983 / (clock * x * 4) Here you are replacing 307 with 245.75 to create a different scale.
I would do what was done in the Northstar code and create two rpm variables. Then load high table in X and high RPM in B. Next check B for 0. If it is greater then branch to lookup. Otherwise load low table in X and low RPM in B and then look up.
HTH
John
01-11-2011, 12:31 PM
#32
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
ok....... i think i'm catching on....
what i was planning was to run the RPM X 25 in the upper table up until i jump between the 250 and 500 RPM intervals, though it seems like it would be a lot easier to run the higher RPM X xx in the entire table?
i'm still not 100% certain on how to create the different intervals in the table though... IIRC, it was something like doubling or halving the RPM variable(via something like ASLA?) if it was above the desired breakpoint in the table(4500 RPM in this instance, so assuming RPM X 50, d90($5A).
close?
what i was planning was to run the RPM X 25 in the upper table up until i jump between the 250 and 500 RPM intervals, though it seems like it would be a lot easier to run the higher RPM X xx in the entire table?
i'm still not 100% certain on how to create the different intervals in the table though... IIRC, it was something like doubling or halving the RPM variable(via something like ASLA?) if it was above the desired breakpoint in the table(4500 RPM in this instance, so assuming RPM X 50, d90($5A).
close?
01-13-2011, 12:01 AM
#33
Member
Join Date: Feb 2002
Posts: 156
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
The spark counter counts 65500 hz clock cycles. So for RPM/25 1 byte is 256 * 25 = 6400 RPM. Clock cycles per rotation at 6400 RPM = 65500/6400 RPM * 60 sec/min = 614 clock cycles per rev at 6400 RPM. There are 4 pulses per RPM for 8 cylinder logic so clock cycles per pulse = 614 / 4 = 153.5. Since this is not a whole number both clock cycles and the factor (153.5) are multiplied by 2. This give 307 clock factor / 307 clock cycles per pulse at 6400 rpm. So when the processor calculates RPM it is really calculating the fraction of 6400 RPM. Here 6400 * 307 / (2 * clock cycles). If you want to do RPM/50 you do the same math and find that the fraction is 12800 * 76.75 / clock cycles. To get a whole number you want to multiply by 4/4 to get 12800 * 307 / (4 * clock cycles). To do this you will add a second lslD to the sequence. This will mean that you no longer have RPM/25. Now you will have RPM/50. Everything downstream will need to be adjusted or you can store RPM/50 and then make RPM/25. This is probably best since you can then leave everything but the tables alone. But to do this you need to find two free bytes of RAM.
To create table RPM with different scales you will create the byte. The table RPM will follow what the byte represents so when you scale the byte you scale the table. If you start at 12800 max and scale by 2s then max RPM can be 6400, 3200, 1600. So for the lower byte you want to scale to something with good resolution. The 1600 looks good but wastes some leading bytes. Since you have RPM/50 in A and the remainder in B you can offset A and keep B easily. By subtracting 400 RPM from A then multiplying by 8 (three lslD) you get A from 400-2000 RPM. Put this in the first byte. For the second byte you want your max to be 7600 RPM. Start by subtracting 2000 RPM since you are tracking that in the low byte. Then divide out to get scale. RPM/25 gives 15 bytes from 2000 -7600. To expand to 17 you can use 2000-2800 by RPM/12.5 and 2800 - 7600 by RPM/25. To do this start by loading RPM/50 into D and subtracting 2000 RPM from A. Then compare A to 800 (2800 RPM). If it is less then multiply by 4 to get RPM /12.5. This will give 0 = 2000, $10 = 2200, $20 = 2400, $30 = 2600, and $40 = 2800. If A is greater than 800 (2800 RPM) then multiply by 2 and add $20 as an offset. This will give $40 = 2800 and $100 = 7600. So now your table RPM for the 17 bytes will automaticly be 2000, 2200, 2400, 2600, 2800, 3200, 3600, 4000, 4400, 4800, 5200, 5600, 6000, 6400, 6800, 7200, and 7600. This is in addition to the lower RPM byte of 400 - 2000 by steps of 100 RPM.
HTH
John
To create table RPM with different scales you will create the byte. The table RPM will follow what the byte represents so when you scale the byte you scale the table. If you start at 12800 max and scale by 2s then max RPM can be 6400, 3200, 1600. So for the lower byte you want to scale to something with good resolution. The 1600 looks good but wastes some leading bytes. Since you have RPM/50 in A and the remainder in B you can offset A and keep B easily. By subtracting 400 RPM from A then multiplying by 8 (three lslD) you get A from 400-2000 RPM. Put this in the first byte. For the second byte you want your max to be 7600 RPM. Start by subtracting 2000 RPM since you are tracking that in the low byte. Then divide out to get scale. RPM/25 gives 15 bytes from 2000 -7600. To expand to 17 you can use 2000-2800 by RPM/12.5 and 2800 - 7600 by RPM/25. To do this start by loading RPM/50 into D and subtracting 2000 RPM from A. Then compare A to 800 (2800 RPM). If it is less then multiply by 4 to get RPM /12.5. This will give 0 = 2000, $10 = 2200, $20 = 2400, $30 = 2600, and $40 = 2800. If A is greater than 800 (2800 RPM) then multiply by 2 and add $20 as an offset. This will give $40 = 2800 and $100 = 7600. So now your table RPM for the 17 bytes will automaticly be 2000, 2200, 2400, 2600, 2800, 3200, 3600, 4000, 4400, 4800, 5200, 5600, 6000, 6400, 6800, 7200, and 7600. This is in addition to the lower RPM byte of 400 - 2000 by steps of 100 RPM.
HTH
John
01-25-2011, 11:58 PM
#34
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
hmm....
any obvious reason why this isn't working?
also, i seem to have a sickness... low, mid and high RPM VE tables...
when i have that code selected via the bitmask, VE gets calc'd/stored as 100%.... i can't figure out why yet...
Code:
9270: LDAA L9263 (nAst1 bitmask 1) 9273: BITA $1 (check bit 0(VE option)) 9275: BNE $08(L927F) (branch to do nAst1 VE lookups if bit 0 is = 1) 9277: LDAA L0062 (otherwise, continue with A1) 9279: LDX L8848 (...) 927C: JMP LB858 (return to A1 code) 927F: LDAA L0062 (RPM X 25) 9281: CMPA $50 ((d80) compare RPM to 2000) 9283: BHI $0F(L9294) (branch to do comparison to 5200 RPM if over 2000) 9285: LDAA L00C4 (otherwise, load RPM X 12.5) 9287: LDAB L0057 (normalized MAP load) 9289: LDX L1EDC (low RPM VE table) 928C: SUBA $20 (subtract 400RPM to set lower limit of table) 928E: BCC $01(L928E) (branch if above 400RPM) 9290: CLRA (clear A to use minimum RPM value of table) 9291: ASLA (multiply RPM by 2 to cause 100RPM increments) 9292: BRA $0C (**TEMP!**) (branch to area under mid and high RPM code to do 3D lookup) 92A0: JMP LB8C5 (return to A1 stuff, specifically the 3D lookup and afterwards)
also, i seem to have a sickness... low, mid and high RPM VE tables...
when i have that code selected via the bitmask, VE gets calc'd/stored as 100%.... i can't figure out why yet...
01-26-2011, 08:08 AM
#35
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,401
Likes: 0
Received 215 Likes
on
201 Posts
Car: check
Engine: check
Transmission: check
Re: Getting started w/ disassembly and commenting
Need a # sign in front of table addresses when loading the address:
LDX L1EDC (low RPM VE table)
-to-
LDX #L1EDC (low RPM VE table)
The first instruction will load the value at that address.
The second one will load the address of the table. This is done for the look up routine.
RBob.
LDX L1EDC (low RPM VE table)
-to-
LDX #L1EDC (low RPM VE table)
The first instruction will load the value at that address.
The second one will load the address of the table. This is done for the look up routine.
RBob.
01-26-2011, 01:18 PM
#36
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
if i was using an assembler, yes, but i've been just pounding it all out in the tunerpro hex editor... which has been fun... i believe i have all of the addressing modes correct since i just compare whatever operation i'm doing to one that i know how it works in a factory calibration, see what the hex values are then copy/paste/adjust to whatever i'm doing at the moment...
also, i found at least 2 GIANT errors: LDX 1EDC is one of them... i was going off of the address i saw in TP, not realizing i'm dealing with a 32K BIN... so now that's fixed, to 9EDC, i also realized i never put the address in for the mid RPM table, that's also fixed(and the branch direction/distances have been modified to relect that as well...
however, the processor is still calculating 100% VE, and i'm still lost as to why it is doing so...
this is EVERYTHING i have so far... and no i haven't worked in the >5200RPM table, since the grand prix lives it's life far below that, i just wanted to get the 400-2000 and 2000-5200 functioning first.
now, in A1, it does the lookup of the base VE table and stores the value to L008A, then grabs the TPS A/D result, then goes to compare to see if it uses the main or idle VE table... which is why i have the TPS stuff near the top due to not wanting the base VE table in use since VE is only stored as an 8 bit variable anyway, which makes it kind of pointless...
anyways, the JMP at the end goes to a JSR that goes to the 3D lookup subroutine. then VE is pushed into the stack, some correction to VE due to EGR stuff is done and a value stored to L01A1, then the 3D lookup for the VE is pulled from stack, added to L008A and is capped to $FF(if necessary). then the VE modification from EGR is subtracted, and assuming it doesn't hit $00, it's then stored back to L008A...
from what i can tell, the modifications i've made SHOULD be functioning... ideas?
EDIT: also, i've been looking at some of the PWM output stuff... now, they're stored as a 16-bit value, and the LSB determines duty cycle, but the MSB determines cycling rate? i think i've seen B0xx mean 16Hz and D0 mean 32Hz? i've also seen DFxx, which i'm not quite sure what the F does....
also, i found at least 2 GIANT errors: LDX 1EDC is one of them... i was going off of the address i saw in TP, not realizing i'm dealing with a 32K BIN... so now that's fixed, to 9EDC, i also realized i never put the address in for the mid RPM table, that's also fixed(and the branch direction/distances have been modified to relect that as well...
however, the processor is still calculating 100% VE, and i'm still lost as to why it is doing so...
this is EVERYTHING i have so far... and no i haven't worked in the >5200RPM table, since the grand prix lives it's life far below that, i just wanted to get the 400-2000 and 2000-5200 functioning first.
Code:
A1: B853: LDAA L0062 for engine speed X 25 B855: LDX L8848 for Base VE Table change to: B853: JMP L9270 so nAst1 vs A1 code can be established should NOP(01) bytes B856-B857 so they can't be mistaken for anything. 9270: LDAA L9263 (nAst1 bitmask 1) 9273: BITA $1 (check bit 0(VE option)) 9275: BNE $08(L927F) (branch to do nAst1 VE lookups if bit 0 is = 1) 9277: LDAA L0062 (otherwise, continue with A1) 9279: LDX L8848 (...) 927C: JMP LB858 (return to A1 code) 927F: LDAA $50 (channel 5, TPS) 9281: JSR LF0D0 (A/D read) 9284: STAA L006D (TPS A/D) 9286: LDAA L0062 (RPM X 25) 9288: CMPA $50 ((d80) compare RPM to 2000) 928A: BHI $0F(L9294) (branch to do comparison to 5200 RPM if over 2000) 928C: LDAA L00C4 (otherwise, load RPM X 12.5) 928E: LDAB L0057 (normalized MAP load) 9290: LDX L9EDC (low RPM VE table) 9293: SUBA $20 (subtract 400RPM to set lower limit of table) 9295: BCC $01(L928E) (branch if above 400RPM) 9297: CLRA (clear A to use minimum RPM value of table) 9298: ASLA (multiply RPM by 2 to cause 100RPM increments) 9299: BRA $0F (**TEMP!**) (branch to area under mid and high RPM code to do 3D lookup) 929B: CMPA $D0 ((d208) compare RPM to 5200) 929D: BHI $0B (**TEMP!**) (branch to do high RPM stuff if higher) 929F: ASLA (multiply RPM by 2 to cause 200RPM increments) 92A0: SUBA $18 ((d24) subtract 1200RPM(due to X2) to set upper limit(6400-1200=5200)) 92A2: BCC $01(L929C) (branch if above 2000RPM) 92A4: CLRA (otherwise, clear A to use table minimum, 2000) 92A5: LDX L9DB8 (mid VE table) 92A8: BRA $00 (**TEMP!**) (then branch to do lookup stuff after the high RPM table) temp use until i can confirm functioning RPM X 50 value. 92AA: JMP LB8C5 (return to A1 stuff, specifically the 3D lookup and afterwards)
now, in A1, it does the lookup of the base VE table and stores the value to L008A, then grabs the TPS A/D result, then goes to compare to see if it uses the main or idle VE table... which is why i have the TPS stuff near the top due to not wanting the base VE table in use since VE is only stored as an 8 bit variable anyway, which makes it kind of pointless...
anyways, the JMP at the end goes to a JSR that goes to the 3D lookup subroutine. then VE is pushed into the stack, some correction to VE due to EGR stuff is done and a value stored to L01A1, then the 3D lookup for the VE is pulled from stack, added to L008A and is capped to $FF(if necessary). then the VE modification from EGR is subtracted, and assuming it doesn't hit $00, it's then stored back to L008A...
from what i can tell, the modifications i've made SHOULD be functioning... ideas?
EDIT: also, i've been looking at some of the PWM output stuff... now, they're stored as a 16-bit value, and the LSB determines duty cycle, but the MSB determines cycling rate? i think i've seen B0xx mean 16Hz and D0 mean 32Hz? i've also seen DFxx, which i'm not quite sure what the F does....
01-26-2011, 04:22 PM
#37
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,401
Likes: 0
Received 215 Likes
on
201 Posts
Car: check
Engine: check
Transmission: check
Re: Getting started w/ disassembly and commenting
Hand assembly is difficult. Having been down that road it isn't something that I would recommend.
Best bet is to set up a patch file. This is the changes/additions to the BIN. The patch file is in text and gets assembled. You can then either use the S19 or the listing output file to patch the actual BIN.
This makes sure that the assembly is correct. Can use AS11 which is a freebie. It won't do huge files, but easily does patch size files. Here is an example of a MPH fuel cut for the '7747 I released a few years ago.
RBob.
Best bet is to set up a patch file. This is the changes/additions to the BIN. The patch file is in text and gets assembled. You can then either use the S19 or the listing output file to patch the actual BIN.
This makes sure that the assembly is correct. Can use AS11 which is a freebie. It won't do huge files, but easily does patch size files. Here is an example of a MPH fuel cut for the '7747 I released a few years ago.
Code:
;----------------------------------------------------------------- ; ; Fuel cut routine for '747 ; ; 10/26/99 RBob. ; ; ; v1.00 Initial development ; v1.01 changes ; v1.02 Added fuel on if rpm < 1000, changed START location. ; ; ; Copyright 1999 RBob., All Rights Reserved. ; ;----------------------------------------------------------------- .AREA FC (ABS) ; ------------------------------------------------------- ; ; This location should be one less than the fuel on speed ; It is only required if using an automatic transmission. ; At speeds above this value, the TCC will not unlock. .ORG $D56E .DB 73 ; ------------------------------------------------------- ; ; This is the start of the actual code patch ; ; .ORG $D35A .ORG $D338 ; v 1.02 ; ------------------------------------------------------- START: LDAB #75 ; cut-out mph LDAA *$04 ; status BITA #$40 ; 1 == fuel on in effect BNE RICH0 ; bra if rich, fuel on LDAB #74 ; mph for fuel back on RICH0: CMPB *$34 ; filt vss BHI FUELON ; bra if trip mph > actual mph LDAB #40 ; 1000 rpm/25 CMPB *$1C ; rpm/25 BHI FUELON ; bra if trip rpm > actual rpm ANDA #~$40 ; clear on bit, fuel off STAA *$04 ; save status JMP LD9F6 ; jump to fuel off FUELON: ORAA #$40 ; set to fuel on, bit STAA *$04 ; save status LDAA *$00 ; replaced instruct's BITA #$10 ; replacement JMP LD9F4 ; do regular fuel ; ------------------------------ ; Location to jump back into the ; existing code for fuel on. ; ------------------------------ .ORG $D9F4 LD9F4: ; ------------------------------ ; Location to jump back into the ; existing code for fuel cut-off. ; ------------------------------ .ORG $D9F6 LD9F6: ; ------------------------------ ; Location to patch into the ; existing code and jump to ; our new code. ; ------------------------------ .ORG $D9F0 JMP START ; ------------------------------ ; These two are used to patch ; the egr tables used at $D324. ; Since all five are the same, I ; have limited the use to one. ; ; Note: It is your responsibility ; to verify that the ones in the ; bin you use are also the same. ; ------------------------------ .ORG $DCF6 LDCF6: CMPA #16 .ORG $DCFA LDCFA: LDAA #16 ;------------------------------- ; ; eof ;
RBob.
01-27-2011, 09:31 PM
#38
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
so i've noticed...
i actually made some progress today, but i'm not quite sure how... i copied the 8D tables/algorithm byte for byte and changed only the RAM locations of MAP and RPM to match A1, then the 3D lookup subroutine, but still got a 100% VE...
then i started removing some of the algorithm that was just wasting cycles, like a couple of VE compensation due to EGR tables that were never used by the factory... and then all of a sudden, i have a VE number that actually makes sense and corresponds to what was in the tables... so i'm not sure why it was fixed, but it is. so now i just need to add in the tables/code to run the bigger tables and troubleshoot that if necessary.
also, i'm not quite as savvy with those S19 files yet, though i have looked through some of yours, one from Z69 and i think another from John Pell... it seems fairly easy, though at the moment, i'm just trying to get it pounded out and then if it works as expected, go back and make things a bit easier to do in the future, should it be necessary, though there aren't that many A1 BINs that use the same algorithm sections as the BFBD BIN does. i've identified at least 3 revisions that were made and the BFxx series is the latest of them, seems like they were the best bet to deal with.
i have BIG plans for the A1 mask...
EDIT: also, 32V_DOHC mentioned that i can get from 400-2000RPM using the same variable, would i have to offset anything using the 3 leading bytes in front of the table or would that be done with the algorithm?
i actually made some progress today, but i'm not quite sure how... i copied the 8D tables/algorithm byte for byte and changed only the RAM locations of MAP and RPM to match A1, then the 3D lookup subroutine, but still got a 100% VE...
then i started removing some of the algorithm that was just wasting cycles, like a couple of VE compensation due to EGR tables that were never used by the factory... and then all of a sudden, i have a VE number that actually makes sense and corresponds to what was in the tables... so i'm not sure why it was fixed, but it is. so now i just need to add in the tables/code to run the bigger tables and troubleshoot that if necessary.
also, i'm not quite as savvy with those S19 files yet, though i have looked through some of yours, one from Z69 and i think another from John Pell... it seems fairly easy, though at the moment, i'm just trying to get it pounded out and then if it works as expected, go back and make things a bit easier to do in the future, should it be necessary, though there aren't that many A1 BINs that use the same algorithm sections as the BFBD BIN does. i've identified at least 3 revisions that were made and the BFxx series is the latest of them, seems like they were the best bet to deal with.
i have BIG plans for the A1 mask...
EDIT: also, 32V_DOHC mentioned that i can get from 400-2000RPM using the same variable, would i have to offset anything using the 3 leading bytes in front of the table or would that be done with the algorithm?
Last edited by Saar; 01-27-2011 at 09:52 PM.
02-01-2011, 09:44 AM
#39
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
Code:
9270: LDAA $50 channel 5, TPS JSR LF0D0 A/D read STAA L006D TPS A/D 9277: LDAB L0057 Normalized MAP LDAA L0064 RPM X 12.5 CMPA $A0 d160, 2000RPM(determine lower/mid table) BCC L928A branch if higher to do mid table 927F: LDX L9EDC Low VE table SUBA $20 d32, 400RPM(set table lower limit) BCC L9287 branch if didn't hit minimum CLRA otherwise, clear A to use min RPM value ASLA RPM X 2 to make 100 RPM intervals BRA L92A9 branch to do 3D lookup 928A: LDX L9DB8 Mid VE table SUBA $A0 d160, 2000RPM, set lower limit CMPA $50 d80, 3000RPM BCC L9295 branch if higher to do RPMX25 with offset BRA L92A9 otherwise, branch to do 3D lookup 9295: LDAA L0062 RPM X 25 SUBA $78 d120, subtract 3000RPM(makes RPM X25 +3000) ASLA multiply to cause 200RPM increments(RPMX12.5) CMPA $B0 d176, compare to 5200RPM BHI L92A0 branch if higher to do high RPM table BRA L92A9 otherwise, do 3D lookup 92A0: LDX L9C94 high RPM table LDAA L???? RPM X 50 SUBA $68 d104, subtract 5200RPM, set table min ASLA mult to make 400RPM increments(RPMX25 +5200) ASLA mult to make 200RPM increments(RPMX12.5 +5200) 92A9: JSR F76E 3D lookup subroutine STAA L008A 3D VE lookup JMP B918 back to A1, after VE and EGR stuff
so, 3 VE tables, 400-2000, 2000-5200 and 5200-8400... i'm excited to say the least. so, for everyone that has contributed, THANK YOU, i now have a new hobby to obsess over. and now that the VE tables are fuinctioning, it should be VERY quick and simple to adapt it so my main spark tables are identical.
02-11-2011, 01:34 PM
#40
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
LOL, whoops...
i forgot about putting in the offset to get the mid table to read correctly above 3000 RPM(luckily i was pretty weak on the throttle during the test. otherwise, when i fixed that, it was working great!
i'll be testing a RPM X 50 variable tomorrow from the looks of it. assuming it works correctly, i'll be seeing if i can work all of the algorithm in place of the original stuff to cut execution time down even further. once that all works, i can more or less port the VE code and get the spark tables...
i never thought some hex digits could be so exciting.
i forgot about putting in the offset to get the mid table to read correctly above 3000 RPM(luckily i was pretty weak on the throttle during the test. otherwise, when i fixed that, it was working great!
i'll be testing a RPM X 50 variable tomorrow from the looks of it. assuming it works correctly, i'll be seeing if i can work all of the algorithm in place of the original stuff to cut execution time down even further. once that all works, i can more or less port the VE code and get the spark tables...
i never thought some hex digits could be so exciting.
02-11-2011, 04:27 PM
#41
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Re: Getting started w/ disassembly and commenting
If your looking for a good assembler, I have the Mgtek one. Its a dos based 32-bit assembler, and will handle anything you can throw at it. I think itll do ok under vista and XP, but Ive never tried it in 7. Youll need to format your assembly to get it to work. That means tabbing over the code and using labels. The assembler expects the LHS of the document file with no tabs to be labels only, and will give an error if you leave a command in that column.
02-11-2011, 04:35 PM
#42
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
oh that sounds fun....
then again, since i already have this pounded out in hex and working correctly, all i would need to do is compare the functional BIN with a patched one.... any differences would show up pretty easily...
although, it's been fairly simple so far to do it all in hex, just somewhat time consuming.
then again, since i already have this pounded out in hex and working correctly, all i would need to do is compare the functional BIN with a patched one.... any differences would show up pretty easily...
although, it's been fairly simple so far to do it all in hex, just somewhat time consuming.
02-13-2011, 04:12 AM
#43
Supreme Member
iTrader: (2)
Join Date: Jan 2002
Location: Moorestown, NJ
Posts: 9,962
Likes: 0
Received 3 Likes
on
3 Posts
Car: 88 Camaro SC
Engine: SFI'd 350
Transmission: TKO 500
Axle/Gears: 9-bolt w/ 3.23's
Re: Getting started w/ disassembly and commenting
Its a lot faster to write it as assembly, and much less prone to error. In machine code, theres always teh possibilty of making a mistake with the addressing, which could cause the processor to load something completely different than what you want. The assembler will take care of all of that for you, and tell you if something cant be done, like a branch to a portion of code thats inaccessable (too far, on another device, etc). It also allows the use of inherent addressing, which means that you can write code that can be put anywhere by simply specifying the location (ORG) command at the top of the assembly. If your working on a large project, the assembler is a must.
02-13-2011, 02:19 PM
#44
Member
Join Date: Dec 2007
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Its a lot faster to write it as assembly, and much less prone to error. In machine code, theres always teh possibilty of making a mistake with the addressing, which could cause the processor to load something completely different than what you want. The assembler will take care of all of that for you, and tell you if something cant be done, like a branch to a portion of code thats inaccessable (too far, on another device, etc). It also allows the use of inherent addressing, which means that you can write code that can be put anywhere by simply specifying the location (ORG) command at the top of the assembly. If your working on a large project, the assembler is a must.
Dimented has it right, and another addressing problem is that you can use the hex editor to create a branch into the middle of an instruction. This crashes everything.
02-15-2011, 12:31 PM
#45
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
i can't argue against solid logic... i just don't want to fix what isn't broken...
for the moment, i've just been error-checking everything by loading the newest patched BINs into IDA and just doing the disassembly on where i have my code located to see if anything looks odd.
ugh... more rules and methods to try and remember.
for the moment, i've just been error-checking everything by loading the newest patched BINs into IDA and just doing the disassembly on where i have my code located to see if anything looks odd.
ugh... more rules and methods to try and remember.
02-18-2011, 11:12 AM
#46
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
odd... i have my current RPM X 1 value divided into 50 correctly(at least it matches the RPM X 25 value fairly accurately), and have it being stored to a RAM location and have that location being transmitted in the datastream...
but every couple of samples i seem to get a 0 in place of the actual value.... and then a sample later, it's back to normal, with no known pattern.
i have it happening every time the processor updates the RPM X 1 value, not sure what the frequency is yet, but that's when it happens. i may have it done on the fly and only when going into the RPM X 50 based tables to save clock cycles at lower RPM though...
i'm thinking i'm going to move it into other RAM locations, see if the same phenomenom occurs, if it doesn't, that would indicate that "free" RAM i found wasn't exactly free, was it?
i didn't notice any changes to the operation of the vehicle, though i'll have to go over the log more in depth later.
but every couple of samples i seem to get a 0 in place of the actual value.... and then a sample later, it's back to normal, with no known pattern.
i have it happening every time the processor updates the RPM X 1 value, not sure what the frequency is yet, but that's when it happens. i may have it done on the fly and only when going into the RPM X 50 based tables to save clock cycles at lower RPM though...
i'm thinking i'm going to move it into other RAM locations, see if the same phenomenom occurs, if it doesn't, that would indicate that "free" RAM i found wasn't exactly free, was it?
i didn't notice any changes to the operation of the vehicle, though i'll have to go over the log more in depth later.
02-18-2011, 01:10 PM
#47
Member
Join Date: Dec 2007
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
Re: Getting started w/ disassembly and commenting
Robert, years ago when I was programming interrupts in assembly language for a video process, I ran into a similar problem. I was running out of time in the update cycle. It may be that the RPM X 1 update with the added code takes too long to complete by just a small amount, most of the time it completes, but once in a while it doesn't have enough time. If this is happening before or after a critical interrupt, that may be your problem. As a test, try just this temporary fix. Remove the code you added, and just put a fixed value in the ram location (via a preloaded register or set it elsewhere) If it keeps getting set to zero at random intervals, then look for something else that might be modifying that location. What would be really nice to have for these ECM's would be an ICE (In Circuit Emulator) as you could then run the code and break on modifying that location.
02-18-2011, 06:36 PM
#48
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
thanks for the suggestion(i actually was expecting it to be something like that, time ran out situation), but it came too late...
it seems some other code was clearing the value(randomly, or due to ALDL sampling rates, appeared randomly), and 3 other "free" values until i came to L00B3, which i got a good ~60 seconds at least with no 0's during an idle test. i guess i'll need to dig through and see if GM did any unnecessary clearing of values via some accum D commands when it was unnecessary... that's the only thing i could think of.
it seems some other code was clearing the value(randomly, or due to ALDL sampling rates, appeared randomly), and 3 other "free" values until i came to L00B3, which i got a good ~60 seconds at least with no 0's during an idle test. i guess i'll need to dig through and see if GM did any unnecessary clearing of values via some accum D commands when it was unnecessary... that's the only thing i could think of.
02-23-2011, 01:27 PM
#49
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
ok, slow, steady progress on modifying code, getting a little more confident in my skills, noticed something interesting:
for some reason, GM never implimented any kind of air temp based correction to spark advance, something that has bitten me before since i can get a NICE tune worked out in the winter, but after a heat-soaked start in the summer, it can start picking up knock when the IATs are elevated into the 100+ *F range until i've been crusing at speed for quite some distance, which has always bothered me...
so, opinions on which variable i should base the table off of: measured IAT or the value the ECM is already creating for an estimated "intake runner" temp? or would it be intelligent to just insert a flag to allow for either?
and moving on to the N* stuff: i've been looking when i have time, but i cannot seem to find the ALDL stream in the engine half of the N* code, which is somewhat disappointing, especially when i don't have a BIN of the trans code, but i got to thinking, how exactly do the two processors communicate with each other, since they both seem to have at least a few things the other would have?
they do look to have some kind of circuits between each other, i almost want to say they could access each other's RAM, if that's possible? the P66 stuff is still out there for me.
and finally(for this post anyways), it looks that there is at least one free "reference" period based counter available to attach something like a cam or crank sensor to(in a Quad4 application, it was used for a 1X crank signal from the ICM), now, would a counter like this reset on every reference period? i was thinking about using it to reference cam position to better control cam phasing on the 3900 and 3500 engines, basically using it as a closed loop control to correct for any differences there are in cam position due to oil pressure fluctuations/sensor inaccuracy.
i was planning on doing this by referencing current RPM and time since last cam pulse, and if i'm thinking correctly, i may also need to know how much time has passed since the last 3X pulse, and that SHOULD give me what i'm looking for (how far the cam has rotated relative to TDC).
for some reason, GM never implimented any kind of air temp based correction to spark advance, something that has bitten me before since i can get a NICE tune worked out in the winter, but after a heat-soaked start in the summer, it can start picking up knock when the IATs are elevated into the 100+ *F range until i've been crusing at speed for quite some distance, which has always bothered me...
so, opinions on which variable i should base the table off of: measured IAT or the value the ECM is already creating for an estimated "intake runner" temp? or would it be intelligent to just insert a flag to allow for either?
and moving on to the N* stuff: i've been looking when i have time, but i cannot seem to find the ALDL stream in the engine half of the N* code, which is somewhat disappointing, especially when i don't have a BIN of the trans code, but i got to thinking, how exactly do the two processors communicate with each other, since they both seem to have at least a few things the other would have?
they do look to have some kind of circuits between each other, i almost want to say they could access each other's RAM, if that's possible? the P66 stuff is still out there for me.
and finally(for this post anyways), it looks that there is at least one free "reference" period based counter available to attach something like a cam or crank sensor to(in a Quad4 application, it was used for a 1X crank signal from the ICM), now, would a counter like this reset on every reference period? i was thinking about using it to reference cam position to better control cam phasing on the 3900 and 3500 engines, basically using it as a closed loop control to correct for any differences there are in cam position due to oil pressure fluctuations/sensor inaccuracy.
i was planning on doing this by referencing current RPM and time since last cam pulse, and if i'm thinking correctly, i may also need to know how much time has passed since the last 3X pulse, and that SHOULD give me what i'm looking for (how far the cam has rotated relative to TDC).
03-11-2011, 01:27 PM
#50
Senior Member
Thread Starter
Join Date: Nov 2006
Location: Camden, MI
Posts: 672
Likes: 0
Received 1 Like
on
1 Post
Car: 1985 IROC-Z28
Engine: LB9
Transmission: 700R4
Axle/Gears: 3.73
Re: Getting started w/ disassembly and commenting
update: i officially released nAst1 v1.00 on the 60degreeV6 boards, for the moment all it has is the 400-8400RPM fuel and spark tables, a couple of unnecessary tables and constants removed and has been tested on a bench and seems to be working as intended... came across a question as well from another member, had to explain the differences between single and double fire fueling, since i mentioned that in the BINs i released, i had had single fire fueling disabled via constants since i wasn't sure if i wanted it completely gone even though i had decent results when running around in the wife's car to do some real world testing.
https://www.thirdgen.org/forums/v6/5...ngle-fire.html
now, i read a bit into RBob's post, what exactly is up with the 2.8/3.1 stuff? and is that refering to the older masks only? some of the GM documentation seems to imply that in $A1 there is double and single fire...
and if A1 does have the goofy firing scheme, it seems i'm going to have to play around with even more code since in single fire(or at least what i've been calling single fire) fueling is based off of Alpha-N for some reason....
i could do something as simple as have the ECM run through it's normal double-fire code, then just double the resulting pulsewidth to get good results in single fire, right?
https://www.thirdgen.org/forums/v6/5...ngle-fire.html
now, i read a bit into RBob's post, what exactly is up with the 2.8/3.1 stuff? and is that refering to the older masks only? some of the GM documentation seems to imply that in $A1 there is double and single fire...
and if A1 does have the goofy firing scheme, it seems i'm going to have to play around with even more code since in single fire(or at least what i've been calling single fire) fueling is based off of Alpha-N for some reason....
i could do something as simple as have the ECM run through it's normal double-fire code, then just double the resulting pulsewidth to get good results in single fire, right?