Which brings up? If not through AD then what is correct conversion?
Printable View
Which brings up? If not through AD then what is correct conversion?
with 0D, you won't necessarily have any problems, since you can change the value it's compared against in a patch, that's assuming any is compared against raw A/D counts.
That's the big question Jim? Which ones use it as AD count 1k and what does not? The ones I mentioned are most important and with the EGR now found as commented 1k and correct maybe it will give you an idea what to look for. I'm just perplexed at why so many different conversions? Something is wrong?
I'll attach the ADSU3.asm marked as -V1. I made a couple changes marked after the comment with ***. Those have correct temps to this conversion, which is almost spot on in areas needed, worst I found was 3 degrees off. Bottom of scale and top of scale a little more so but does not matter, if you get to top or bottom you are forcing on or off. I'm not complaining, the work was incredible for something said that could not be done. Just giving you my results of conversion test, to hex and decimal shown in assembly. Since these will all work together I think what is shown in TP with this conversion is what should be shown in assembly? Or we would need to make a new 156 count to celcius chart for complete accuracy which I think is overkill at this point?
Then there's some marked *Question* or ***Question*. It is not all conclusive, just a few done, as I said I started having more questions then answers. If you can figure out what is AD 1k and what isn't and what is what, I'll test them?
Someday I'd like to get back to learning dissasembly, but what I'm learning now will go forward. It's great you guys are part of the team, I'm trying to do the other end, I'd never have got this far without you guys! With my computer issues (my best laptop dead, my spare mailed out to tune job, a rebuilder in mail, using a 12 year old XP desktop), learning the scripts of the site for search and other mods, I've just put off dissasembly and following the algortym till later so I can still have time to do what I like, tune cars and dial these files in!
Sorry to hear about all the computer problems, I would probably go nuts. I DL'd the v1 file, will start looking at it this weekend after I tape this weeks lectures for class and put in time in the online class I am taking. A couple of hours of work, then I get time to play. I would really like to get tuning my truck, but I think that as worn out as it is, nothing much will help. If I figure out it's occasional hicup, I will be happy until I finally get a new motor for it. (not much budget right now). Gotta go split this weeks wood first, the wife doesn't like it when we run out of wood LOL.
:laugh:
You know I'd help find the hicup... but I'm guessing the ol gal is drunk from the ethanol? Didn't have that when these were built... :nono: Start a thread if you want.
Computers are not that big an issue, just bad timing and of course when I'm broke... I got a clean low hour Panasonic CF-74 for vehicles, would probably have saved my nice HP 17 inch desktop replacement laptop as it's been worked hard for 3+ years now. Has hit dashboard and ended on floor 3 times when I hit the brakes. I think the hard drive is just been overheated so many times from sitting on the seat, fan on bottom... The CF-74 needs no vents from bottom... semi rugged and a bonus still has a serial port. Plus it was cheap... $157... 2Mhz system up to 4GB ram. Dam SSD hard drive was almost as much...
I think it probably is a valve issue, but I need to log it to see. I can't find my inverter for my laptop right now, so no logging.
Mechanical vacuum gauge is pretty good for seeing that if it's intake, gauge will shake.
Yeah, I just have to dig it out and plug it in. I think I loaned it to my son so he could use it at work. I have a "stumble" in drive when I stop at a light, it usually does it once hard, then it isn't as noticable after that. I will start a new post as soon as I can start to work on it.
Mark, for $42 I believe there are only two different conversions used for CTS. One uses the "standard" GM equation and the other uses the lookup table. The lookup table is contained in ROM space outside the eprom addresses so any variables which reference this space are table based values. L0025 and L00E3 are lookup based so anything comparing a temp to these variables will use the table conversion. Here's an example from ASDZ:
Here's another:Code:DB11: LDAA L00E3 ; COOL TEMP
DB13: CMPA LD2A7 ; -40c OPN LP DECEL THRESH
DB16: BHI LDB34 ;
Start by searching for all the L00E3 references.Code:DB93: LDB93 LDAB L00E3 ; START UP COOL
DB95: CMPB LD2C8 ; TEMP THRSH FOR COLD START
; 10 C, (50f) (A/D 1K PU)
DB98: BHI LDB9E ;
Now, no values in the disassembly should be based on the formula we're using here. The formula is a way to make a close guess as to the lookup table values for the tuning software. The lookup table produces the correct value, not the formula. The better answer is to include a note in TP saying the number given is a an estimate but the lookup table can be used if better accuracy is desired. Every degree C difference is 1.8 deg difference F so it might be important to be able to compute the right values. Also, by not changing the disassembly we can modify the XDF (and other software) if we happen to get the "correct" formula figured out without the need to redo all the disassemblies.
1P2M,
I wasn't going to change the disassembly, only comments. The idea is to clarify which way the code is getting the temp to make looking at the hack make sense. I have figured out the places where the table lookups are. I just want to make sure that the comments are accurate. I have found several that were incorrect, and when I modified the $42-Hac to make working ASDU and ASDX assemblys, I might have made some comments incorrect. I understand that the purpose of the equation that was derived here was to make calculations in the XDF match the data from the data stream, I want to make the comments better so that people creating the XDF files know what to expect.
Well we have one now for the lookup. What is conversion for the other or how to figure it out? My last test showed decimal equivalent to hex of 64d ended up being 64C, that may have been just luck...Quote:
Mark, for $42 I believe there are only two different conversions used for CTS. One uses the "standard" GM equation and the other uses the lookup table.
2 is good! I've found at least 7 different conversions in the XDF. None of them were the lookup. Looks like someone did some testing to find when it was switched from enabled to disabled temp in C and made one up to get close, problem is some are not close, then comment says enable at this temp, so you adjust to disable and all you did was turn it on sooner!
I understand the dissasembly should not be changed but comments are humans interpretations and need correction. That said most of this stuff is very accurate, these temps are horrible and after all this work I can see why. The accuracy can be noted in XDF, it would help understand when entering Closed Loop is not spot on as what you adjusted to... but dam if you get the wrong conversion and one is inverse like we have been dealing with here, your turning things on instead of off! Or later instead of sooner?
Back to EGR!
Looks like what we accomplished here is spot on! :thumbsup:
Further testing is in order which brings up my need for knowledge. Now I know if I ask you guys would just tell me... but I'm at a point in assembly I'd like a lesson instead. It's EGR related so I kept it here.
How to trace bits or data on and off? So we have EGR fueling and spark compensation, there has to be a way to tell when it is on and off? Can this bit be added to data stream in place of something?
I see where some of this may be happening?
Useing EGR for an example. How to find where data could be? In this case just EGR on or off, but overall how to find data that could be used? Somewhere 1project2many had an address for VE, I did not have time to follow up but this is another example of data that could be very benifitial if it were in data stream.Code:;---------------------------------------------
LDCE1 STAA L00A3 ; BLM, BIN
STAB L00A2 ; BLM
;
LDAA >$D2B4 ; BPW const for EGR off,
LDAB >$D2B6 ; EGR on filter coef
;
TST $0006 ;
BPL LDD07 ; BR IF EGR OFF
LDAA L00BE ; AIR FLOW, (gms/sec)
LDAB #197 ;
MUL ;
ASLD ;
CMPA #80 ; AIR FLOW LMT
BLS LDCFC ;
LDAA #80 ; LIMIT AIR FLOW
;---------------------------------------------
; Lk Up EGR COMP TABLE FOR AIR FLOW IN Gms/sec
;
; TBL IS GMS/SEC vs PCT EGR
; BL = N * 1461.5
;---------------------------------------------
LDCFC LDAB L007F ; AIR FLOW FOR EGR
LDX #$D324 ; EGR COMP TABLE FOR AIR FLOW IN
JSR $FB67 ; 3D LOOK UP ?
;---------------------------------------------
LDAB >$D2B5 ; EGR off filter coef
LDD07 LDX L00A7 ; EGR CORRECTION
JSR $FB12 ; LAG FILTER ROUTINE
;---------------------------------------------
STD L00A7 ; EGR CORRECTION
;
ASLB ;
ADCA #0 ;
PSHA ;
;---------------------------------------------
in this instance, look at TST $0006 ;
what's happening here is that byte 0006(in RAM) is being checked for a couple of different statuses. in this case, BPL(branch if plus) comes up immediately afterwards. BPL causes a branch if the byte being tested against had caused the N bit in the status register to be clear. for the N bit to be set, 0006 would have had to have it's bit 7 be set.
so, it breaks down to:
check byte 6 for it's bit 7 status
if bit 7 was clear(meaning EGR is off), branch
now, TST followed by BPL would normally only be used for signed values(not bitmasks), but it worked here since bit 7 was being tested against. with a signed value, bit 7 determines if dealing with a positive or negative number.
You can replace the promid in the ALDL routine with the value you want to monitor. For a bit that's changing watch the value to see if it changes. When bit 7 changes you'll see big differences. It's either $80 or 128, depending on whether you see scanid as decimal or hex.