$8D new bit status definition
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by vernw
Either choice is fine - but choice number two seems simpler and possibly easier.
Originally Posted by vernw
Is there some way to cause the light to stay on some minimum amount of time when knock occurs? Like maybe 2 or 3 seconds minimum? Or user configurable period? Also, just a question, but will this be supplying a ground signal to the LED or power?
2) The min. time will be user configurable.
3) The F5 pin will supply a ground. You would wire the light just like the SES (check engine) light is wired.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
If it doesn't matter to you, a solid light for KS total failure would be nice to have.
The rest of it sounds great too! THANKS!!!
The rest of it sounds great too! THANKS!!!
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
For the light option, a digital output would be better suited (and would leave the PWM open)
A2, OUT D, RELAY 2, U10-19, 5-U16-2, 002F,b1 is the on/off
F3,OUT D, A/C Cl, U2-49, 6-U19-5, 002F, b2 is the on/off
(727 Pin A13) is F3 as well.
A2, OUT D, RELAY 2, U10-19, 5-U16-2, 002F,b1 is the on/off
F3,OUT D, A/C Cl, U2-49, 6-U19-5, 002F, b2 is the on/off
(727 Pin A13) is F3 as well.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Originally Posted by junkcltr
I tested the knock LED code last night. I had some problems with the bin JPSS sent. It would not light the LED...
I had the logic reversed !The code is actually OFF when you turn it on.
Set location L898E to $00
Then it will work.
Just ran it again in the sim and it looks good as long as the PWM cooperates.
Can only run the segment,
still can't see if something else is using 0034 or 0035 by way of indexing.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
In a round about discussion a while back, F5 was picked so stock smog legal cars could use it. Most people wouldn't miss CAGS so it was open.
And already wired up on some cars too!
Relay 2 was left open for N20 soleniod control. These could easily be swapped for PWM control of either once we find our error on F5.
JP and I are about at the end of our smog equipment compatible code mods anyway. So the emissions code will likely get commented out this winter.
Might release that as a base asm after we discuss it first.....
As far as code ownership goes. I didn't take it as Tim owning the aujp code mods. Especially since we dis'd the bins, and didn't put that part out anyway. Not that you need to dis them to find the mods...
But the S_AUJP idea/name was his idea. Granted he has no legal right to it. So to continue with that name etc, we asked if he minded. Wouldn't have stopped us and he knows that.
Would have just picked a different name and confused people and had a harder time getting beta testers. Which you'll find is more difficult than you'd think.
As far as code posting of someone else's code, well we'd be shooting ourselves in the foot if we did that. JP and I had several discussions on this. And finally came into agreement after we both aired our various reasons out on the different additions we've made. For a while partial release of some of the mods was discussed and the xdf and ads files got tied up in the discussion too. The xdf and ads was just about exclusively off line though so most don't know what has been done there. So it was decided that anyone that participates in our little learning experience would retain full control of their source. They can decide if it is for personal use or what if any release of the info can be made.
And for the most part, none of us really have time to mess with releasing other peoples stuff anyway.
Note, the $60 was done this way also. But the behind the scene's author(s) were kept secret also. And any mod releases were controlled too. Reminds me of Apple.... So I always forward emails about code I didn't write to the author and let them deal with it. The hard part was not accidently releasing something while working on the stock code comments.
And you'll note JP & I both offer tips on how to do something if someone is obviously trying to do their own code mods in assembly. As others have done for us on and offline. (Thanks btw)
Too much rambling, where was I going????
And already wired up on some cars too!
Relay 2 was left open for N20 soleniod control. These could easily be swapped for PWM control of either once we find our error on F5.
JP and I are about at the end of our smog equipment compatible code mods anyway. So the emissions code will likely get commented out this winter.
Might release that as a base asm after we discuss it first.....
As far as code ownership goes. I didn't take it as Tim owning the aujp code mods. Especially since we dis'd the bins, and didn't put that part out anyway. Not that you need to dis them to find the mods...
But the S_AUJP idea/name was his idea. Granted he has no legal right to it. So to continue with that name etc, we asked if he minded. Wouldn't have stopped us and he knows that.
Would have just picked a different name and confused people and had a harder time getting beta testers. Which you'll find is more difficult than you'd think.
As far as code posting of someone else's code, well we'd be shooting ourselves in the foot if we did that. JP and I had several discussions on this. And finally came into agreement after we both aired our various reasons out on the different additions we've made. For a while partial release of some of the mods was discussed and the xdf and ads files got tied up in the discussion too. The xdf and ads was just about exclusively off line though so most don't know what has been done there. So it was decided that anyone that participates in our little learning experience would retain full control of their source. They can decide if it is for personal use or what if any release of the info can be made.
And for the most part, none of us really have time to mess with releasing other peoples stuff anyway.
Note, the $60 was done this way also. But the behind the scene's author(s) were kept secret also. And any mod releases were controlled too. Reminds me of Apple.... So I always forward emails about code I didn't write to the author and let them deal with it. The hard part was not accidently releasing something while working on the stock code comments.
And you'll note JP & I both offer tips on how to do something if someone is obviously trying to do their own code mods in assembly. As others have done for us on and offline. (Thanks btw)
Too much rambling, where was I going????
Last edited by Z69; Jun 29, 2006 at 10:53 PM.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
AFA KL choices go, my version had even less features than choice 2.....
How did you get 6.25ms??? or is that where you stuck your routine?
The shift light delay counter I stuck in one of the segments came out very close to $A=1 second for a 25 second limit IIRC.
The biggest problem I've had so far is people saying "my car doesn't run right after I started using this bin" or "this doesn't work"....and the base bin isn't the problem! My patience is closer to Traxs' then RBobs'. That's one reason I'm beta testing V4 a lot. And why you will rarely see my publically post anything about a problem I'm having with X freeware etc....
Oh, and getting others to particpate.
And afa starting with a stock aujp asm. That's why JP posted the relocatable aujp code. So others could start out that much farther down the path and hopefully pass on their mods or things they find about the stock code along the way.
How did you get 6.25ms??? or is that where you stuck your routine?
The shift light delay counter I stuck in one of the segments came out very close to $A=1 second for a 25 second limit IIRC.
The biggest problem I've had so far is people saying "my car doesn't run right after I started using this bin" or "this doesn't work"....and the base bin isn't the problem! My patience is closer to Traxs' then RBobs'. That's one reason I'm beta testing V4 a lot. And why you will rarely see my publically post anything about a problem I'm having with X freeware etc....
Oh, and getting others to particpate.
And afa starting with a stock aujp asm. That's why JP posted the relocatable aujp code. So others could start out that much farther down the path and hopefully pass on their mods or things they find about the stock code along the way.
Last edited by Z69; Jun 29, 2006 at 10:54 PM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
I had the logic reversed !The code is actually OFF when you turn it on.
Set location L898E to $00
Then it will work.
Just ran it again in the sim and it looks good as long as the PWM cooperates.
Can only run the segment,
still can't see if something else is using 0034 or 0035 by way of indexing.
Bad news first. I didn't get this post earlier and played with it for while but couldn't get it to work. I will do the byte swap and test again tomorrow.
Good news. I have my knock LED/Light routine working. It uses no RAM in the ECM or NVRAM module. No RAM use what so ever. It uses Pin F5 as the output for the LED/Light. It is clean code in that it doesn't mess with any of the factory RAM bytes. It uses on CAL area byte.
I tested and tested and tested it some more. I even went as far as simulating an instantenous knock with code so that I was certain the LED/Light ON times were correct for 1 single knock bit set. In reality this can't occur with a real knock sensor & engine. I did that because a real knock sensor sets the knock bit for quite a bit of time.
That is, real knock will happen for 10s of milli-seconds and longer. I was simulating a knock that lasted less than 1 milli-second. Here are the user options for the knock LED routine I wrote.
Code:
;; CONTROL BYTE INFO: ;; bit 3 1 = LED/Light ON for 1 second when engine knock present ;; 0 = LED/Light ON for 3 seconds when engine knock present ;; bit 2 1 = LED/Light Full ON when engine knock is present ;; 0 = LED/Light Blink when engine knock is present ;; bit 1 1 = enable LED/Light when knock sensor failure (LED/Light is ON if knock sesnor is failing) ;; 0 = DO NOT turn on LED/Light when knock sensor fails ;; bit 0 1 = enable LED/Light when engine knock present ;; 0 = DO NOT turn on LED/Light when engine knock is present KCTLWD: .byte 0x0B ; KNOCK code control byte, xxxx_1011
I am going to test the code some more and pretty it up before sending the source code to JP86SS tomorrow. It is full of good comments on how it works. He is free to put it in any bin that he is assembling.
EDIT: Thinking about it now, I should make the defaults work out that it comes out to a value of 0x0F. It would be easier on the end user. I think I will change that tomorrow before testing more and sending to JP86SS.
Last edited by junkcltr; Jun 30, 2006 at 01:48 AM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by Z69
AFA KL choices go, my version had even less features than choice 2.....
Originally Posted by Z69
How did you get 6.25ms??? or is that where you stuck your routine?
Originally Posted by Z69
The shift light delay counter I stuck in one of the segments came out very close to $A=1 second for a 25 second limit IIRC.
Originally Posted by Z69
The biggest problem I've had so far is people saying "my car doesn't run right after I started using this bin" or "this doesn't work"....and the base bin isn't the problem!
Originally Posted by Z69
And afa starting with a stock aujp asm. That's why JP posted the relocatable aujp code. So others could start out that much farther down the path and hopefully pass on their mods or things they find about the stock code along the way.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
I had the logic reversed !The code is actually OFF when you turn it on.
Set location L898E to $00
Then it will work.
Just ran it again in the sim and it looks good as long as the PWM cooperates.
Can only run the segment,
still can't see if something else is using 0034 or 0035 by way of indexing.
I did a little playing around with 0x0034 and 0x0035 and they do not seem to be used. Don't quote me on that though. I need to do way more thorough testing to be sure that a piece of code that I wasn't touching uses them.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
J - that new code for the KL sounds fantastic. Good choices on the timers and options for it, too. Sounds great, I can hardly wait to try it!
The shift light delay timer SL was talking about has to do with an option I requested off-line with him. If you make much of any change diffy gears wise, you get the factory shift light coming on when you're in top gear and cruising down the highway. Scott had added a settable shift light RPM to V4 which works great, but if you try to use it like GM did and set it for "normal" (not WOT) driving conditions then you get the light around 65 or 70 MPH (at least I do with my 4.11 rear). So the shift light timer was a user config setting to specify a max period of time the factory shift light would stay on.
Hope that makes sense the way I said it.
My personal opinion (for what that's worth) as a guy who's been running Scott's code for months now using the manual tranny stuff, is it's very stable.
I like Scott's idea of the NOS control, and JP's status bits to show when AE (map vs. TPS?), PE, etc. are invoked would be great for tuning assistance. I'd love to see all of these in V4, but as a software (UNIX and hence a little C) systems guy, I know how "feature creep" can sideline and/or seriously delay a project. Personally, the only other feature I could foresee getting much use might be dual WB data logging capability, but even that is probably limited to just a few users.
What else needs to be done, and what else can I do to help or test code for you guys so you can start thinking about releasing it? Sounds like you may have a whole host of folks wanting this new release and it's enhanced features. Which just goes to show what a great job you're all doing!
The shift light delay timer SL was talking about has to do with an option I requested off-line with him. If you make much of any change diffy gears wise, you get the factory shift light coming on when you're in top gear and cruising down the highway. Scott had added a settable shift light RPM to V4 which works great, but if you try to use it like GM did and set it for "normal" (not WOT) driving conditions then you get the light around 65 or 70 MPH (at least I do with my 4.11 rear). So the shift light timer was a user config setting to specify a max period of time the factory shift light would stay on.
Hope that makes sense the way I said it.
My personal opinion (for what that's worth) as a guy who's been running Scott's code for months now using the manual tranny stuff, is it's very stable.
I like Scott's idea of the NOS control, and JP's status bits to show when AE (map vs. TPS?), PE, etc. are invoked would be great for tuning assistance. I'd love to see all of these in V4, but as a software (UNIX and hence a little C) systems guy, I know how "feature creep" can sideline and/or seriously delay a project. Personally, the only other feature I could foresee getting much use might be dual WB data logging capability, but even that is probably limited to just a few users.
What else needs to be done, and what else can I do to help or test code for you guys so you can start thinking about releasing it? Sounds like you may have a whole host of folks wanting this new release and it's enhanced features. Which just goes to show what a great job you're all doing!
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Thats good news that we can drive the F5 pin.
The bit display routine just needs a home for the ram location and its an easy display to the error word 5 spot in the ALDL.
Checked real hard last night and still could not find any usage on the 0052-0056 area.
Seems open but ScotSea had mentioned it is used.
I did another test bin myself that I want to try tonight that used location 0054.Only bit 0 is used
Hopefully that will pan out because patching that in to an existing bin can be done easily.
(no EQU needed)
Also left the top two open for Knock light control if desired.
The bit display routine just needs a home for the ram location and its an easy display to the error word 5 spot in the ALDL.
Checked real hard last night and still could not find any usage on the 0052-0056 area.
Seems open but ScotSea had mentioned it is used.
I did another test bin myself that I want to try tonight that used location 0054.Only bit 0 is used
Code:
L0054 = 0x0054 ; My new Status Word
; These bits are set if the corresponding bit is set
; Used as placeholder for Datastream output
;-------------------------------------------------------------
; b7, 1 = Knock detected, Light sequence Dwell Latch
; b6, 1 = Last pass Knock Sensor Failure was active, Continuous Indication
; b5, 1 = In TPS AE Limit EXT ON (status of 0045, b6)
; b4, 1 = MAP AE Done 1st time (status of 0045, b1)
;
; b3, 1 = In MAP AE (status of 0045, b3)
; b2, 1 = In TPS AE (status of 0045, b7)
; b1, 1 = PE Engaged (status of 0046, b5)
; b0, 1 CHECKED FOR PRIOR ERROR 51 ???
(In Original AUJP Code) DRef: 0xDA69
; (no EQU needed)
Also left the top two open for Knock light control if desired.
Last edited by JP86SS; Jun 30, 2006 at 11:50 AM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by vernw
J - that new code for the KL sounds fantastic. Good choices on the timers and options for it, too. Sounds great, I can hardly wait to try it!
Lastly, I sent the complete source code of the routine and where it was called from in the stock code. He can change where it is called from if he choses. Anyway, he has everything to compile it in the bin he and Z69 are creating.
Originally Posted by vernw
The shift light delay timer SL was talking about has to do with an option I requested off-line with him. If you make much of any change diffy gears wise, you get the factory shift light coming on when you're in top gear and cruising down the highway. Scott had added a settable shift light RPM to V4 which works great, but if you try to use it like GM did and set it for "normal" (not WOT) driving conditions then you get the light around 65 or 70 MPH (at least I do with my 4.11 rear). So the shift light timer was a user config setting to specify a max period of time the factory shift light would stay on.
Hope that makes sense the way I said it.
Hope that makes sense the way I said it.
Originally Posted by vernw
I like Scott's idea of the NOS control, and JP's status bits to show when AE (map vs. TPS?), PE, etc. are invoked would be great for tuning assistance. I'd love to see all of these in V4, but as a software (UNIX and hence a little C) systems guy, I know how "feature creep" can sideline and/or seriously delay a project. Personally, the only other feature I could foresee getting much use might be dual WB data logging capability, but even that is probably limited to just a few users.
What is the current thought for N20 control (sorry, haven't been keeping track of the $8D)? A simple TPS and RPM window for N20 full on/off?
Ha ha, feature creep. Yeah it happens and the end result is usually the end user doesn't understand how to use the thing because it got to complicated. Sometimes we all go overboard. I tried to limit the Knock LED/Light so that it is simple for the end user......only four bits to play with. If people want more adjustability then it can be modified later on, but I think most will like it the way it works now. Always open to suggestions though.
AE........you would be surprised how much it is active when driving around.
Originally Posted by vernw
What else needs to be done, and what else can I do to help or test code for you guys so you can start thinking about releasing it? Sounds like you may have a whole host of folks wanting this new release and it's enhanced features. Which just goes to show what a great job you're all doing!
Also, I am still curious how you guys take you existing CAL data and insert it with the new CODE and new CAL data. I had to write a C program that takes my existing CAL that works in the car and concatenates my new CAL and CODE to the original CAL data. The program takes a CAL filename and CODE filename and spits out a new bin with the CAL from one file and some of the CAL and CODE from the other file. I can make the CAL address as a user input so that when new CAL data is added, the address can be adjusted.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Thats good news that we can drive the F5 pin.
The bit display routine just needs a home for the ram location and its an easy display to the error word 5 spot in the ALDL.
Checked real hard last night and still could not find any usage on the 0052-0056 area.
Seems open but ScotSea had mentioned it is used.
I did another test bin myself that I want to try tonight that used location 0054.Only bit 0 is used
Hopefully that will pan out because patching that in to an existing bin can be done easily.
(no EQU needed)
Also left the top two open for Knock light control if desired.
The bit display routine just needs a home for the ram location and its an easy display to the error word 5 spot in the ALDL.
Checked real hard last night and still could not find any usage on the 0052-0056 area.
Seems open but ScotSea had mentioned it is used.
I did another test bin myself that I want to try tonight that used location 0054.Only bit 0 is used
Hopefully that will pan out because patching that in to an existing bin can be done easily.
(no EQU needed)
Also left the top two open for Knock light control if desired.
I sent the test results to you for the knock bin you sent to me a few days ago. I tested all bit settings for the knock control word. Yeah, the F5 pin works well. You have one bit setting that turns it FULL ON. See the test results that I sent you.
If you use the knock code that I wrote. Please give the users the KNOCK CONTROL WORD settings so they can put them in their XDF. Also give them the comments in the code section about how to connect the LED or Light Bulb and how to test that they wired the LED properly.
*** If using an LED, you need to test you wired it properly. It will not light up if it is not wired properly. It is how LED works and has nothing to do with the knock routine operation. The LED will not blow-up stuff if wired improperly, it will just NEVER light up no matter how the knock enable bits are set. ***
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
That all sounds great, and thanks!
As for the NOS control, Scott was working that end. As far as I'm concerned, a simple on/off RPM window when exceeding a certain TPS would be great. The KISS principle again - LOL - helps on the Feature Creep we were talking about.
As for transferring my calibration data to new bin versions...
I've been doing it manually using TP RT. Takes a while to cut and paste all that, even using the comparison feature in TP RT. Your program sounds like it should be a lot quicker for you than my method LOL. Might be something else to consider sharing when this things gets released?
As for the NOS control, Scott was working that end. As far as I'm concerned, a simple on/off RPM window when exceeding a certain TPS would be great. The KISS principle again - LOL - helps on the Feature Creep we were talking about.
As for transferring my calibration data to new bin versions...
I've been doing it manually using TP RT. Takes a while to cut and paste all that, even using the comparison feature in TP RT. Your program sounds like it should be a lot quicker for you than my method LOL. Might be something else to consider sharing when this things gets released?
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by vernw
That all sounds great, and thanks!
Originally Posted by vernw
As for the NOS control, Scott was working that end. As far as I'm concerned, a simple on/off RPM window when exceeding a certain TPS would be great. The KISS principle again - LOL - helps on the Feature Creep we were talking about.
Originally Posted by vernw
I've been doing it manually using TP RT. Takes a while to cut and paste all that, even using the comparison feature in TP RT. Your program sounds like it should be a lot quicker for you than my method LOL. Might be something else to consider sharing when this things gets released?
I will look at the code tonight and make it so the CAL end / CODE start address is in input.
It will look something like this at the MS-DOS (MSYS...for unix guys) prompt:
merge_bins.exe 0x89FF bin_with_cal.bin bin_with_code.bin new_bin.bin
That example would take all the bytes from 0x0000 to 0x89FF from the bin_with_cal.bin, and the bytes from 0x8A00 to 0x7FFF from the bin_with_code.bin and make a new file called new_bin.bin with the bytes from each file. It then does the GM 16-bit checksum on the new_bin.bin and stores it at the CAL area checksum location of the new_bin.bin file. No need to open TP. You burn the file directly to EEPROM or send to the emulator.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Originally Posted by junkcltr
Yikes! That takes a lot of time and is very error prone.
Not too bad using TP though.
Setup the difference tool with the two bins.
Open the current "new" bin for editing.
Setup the compare file using the bin that has the values you want.
Just run the difference tool and select the items one by one.
Click "copy from compare" and its done in about 10-15 mins.
Still longer than a dozen keystrokes but doesn't give any errors by copying directly from the source file.
The file does have the bit routine installed so you can check it out.
Maybe you can see why the PE bit goes on/off during full throttle periods.
Was setup with the bit word at 0034.
Outputs in the datastream at error word 5 (position 7 in the stream)
You're right that people would be suprised how often AE is active.
Milage can suffer from this by over doing it easily.
J, you got mail too.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Yes it does
Not too bad using TP though.
Setup the difference tool with the two bins.
Open the current "new" bin for editing.
Setup the compare file using the bin that has the values you want.
Just run the difference tool and select the items one by one.
Click "copy from compare" and its done in about 10-15 mins.
Still longer than a dozen keystrokes but doesn't give any errors by copying directly from the source file.
Not too bad using TP though.
Setup the difference tool with the two bins.
Open the current "new" bin for editing.
Setup the compare file using the bin that has the values you want.
Just run the difference tool and select the items one by one.
Click "copy from compare" and its done in about 10-15 mins.
Still longer than a dozen keystrokes but doesn't give any errors by copying directly from the source file.
Originally Posted by JP86SS
The file does have the bit routine installed so you can check it out.
Maybe you can see why the PE bit goes on/off during full throttle periods.
Was setup with the bit word at 0034.
Outputs in the datastream at error word 5 (position 7 in the stream)
Maybe you can see why the PE bit goes on/off during full throttle periods.
Was setup with the bit word at 0034.
Outputs in the datastream at error word 5 (position 7 in the stream)
Originally Posted by JP86SS
You're right that people would be suprised how often AE is active.
Milage can suffer from this by over doing it easily.
Milage can suffer from this by over doing it easily.
Supreme Member
Joined: Jul 1999
Posts: 2,844
Likes: 4
From: Maryland
Car: 2005 Subaru STI
Engine: 153ci of Turbo Power!
Transmission: 6-Speed
You guys definitely need to create a S_AUJP_v4!!!
I love the changes you guys are working on. Please don't let the S_AUJP project fall along the wayside. Having one starting image with so many normal changes and so many desired code changes is incredibly helpful. No approval needed from me anymore! Just roll with it
The S_AUJP code is a stock AUJP image with the changes noted in the text file. Only some very small hardcode changes and EVERYTHING is documented. I was very good about that so that the project could be carried forward without starting with a fresh base map.
Tim
I love the changes you guys are working on. Please don't let the S_AUJP project fall along the wayside. Having one starting image with so many normal changes and so many desired code changes is incredibly helpful. No approval needed from me anymore! Just roll with it
The S_AUJP code is a stock AUJP image with the changes noted in the text file. Only some very small hardcode changes and EVERYTHING is documented. I was very good about that so that the project could be carried forward without starting with a fresh base map.
Tim
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I have to go back and look at the orginal S_AUJP mods in detail. I was running it before the $58 and it worked great.
JP86SS,
I sent you some source code and all the info you need for reading the MUXed A/D device (U6). Are you planning on using the inputs for N2O control inputs? Maybe oil temp? Anyway, if just reading an on/off switch, then device U13 is better for doing that.
JP86SS,
I sent you some source code and all the info you need for reading the MUXed A/D device (U6). Are you planning on using the inputs for N2O control inputs? Maybe oil temp? Anyway, if just reading an on/off switch, then device U13 is better for doing that.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
I'm looking forward to testing these new mods, the KL/KS stuff as well as those status bits. Sounds great! I'm willing to try out the merge tool as well, sounds like a big time saver plus much less error prone.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Originally Posted by junkcltr
I have to go back and look at the orginal S_AUJP mods in detail. I was running it before the $58 and it worked great.
JP86SS,
I sent you some source code and all the info you need for reading the MUXed A/D device (U6). Are you planning on using the inputs for N2O control inputs? Maybe oil temp? Anyway, if just reading an on/off switch, then device U13 is better for doing that.
I sent you some source code and all the info you need for reading the MUXed A/D device (U6). Are you planning on using the inputs for N2O control inputs? Maybe oil temp? Anyway, if just reading an on/off switch, then device U13 is better for doing that.
I'll take a look at it tonight.
Was on Ch 4 for an input using the "Simulated" NB from the LC-1.
Wanted to "try" and use the CL o2 tables for shifted AFR in CL.
The sim tracks the OEM NB pretty good but has a few concerns with using it. Ie; mV difference from OE NB (at least in my current logs/ADS setup) warm up, and failure voltage setings need to be looked at for possible problems.
Thanks for reminding me Vern,
J, can you send over that batch file for the cal transfers?
After doing it 10 times yesterday, it does get old
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Cal transfers
Found that ultra edit works pretty good for that.
Copy everything in the cal section and paste.
Took longer to find the files that to make the cal change.
Copy everything in the cal section and paste.
Took longer to find the files that to make the cal change.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
Cal merge- It is a bear when doing a merge to an MT bin cal.
Lots of stuff different. Then you have all the stuff the tester has tweaked also. Then all the S_aujp cal tweaks. I only do it once, just before I send it out to the tester. And only if they've shown to be error prone when doing it themselves. We still need to tweak the asm format to make pasting easier from a dis'd test bin. But for doing just code testing, your merge program would speed things up greatly.
For the end of the cal data on a stock aujp bin, $8989 is the last byte.
All of our stuff was just added on after it. The xdf mod's needed to keep track would be nuts otherwise. I did use some of the stock cal area for the shift light code. It was already for that so I didn't want to add more new cal data. It won't break anything if it's set wrong.
Dos Prompt- XP allows you to arrow over to the exact individual letter you want to change and then overwrite it. F3 works the same as with doskey w/o out having to load it. I haven't done any asm on my 98SE machine for 6mo or more.
N2O- as soon as you do the simple stuff for just controlling an output for solenoid control. People chime in with wanting a dry setup.
Since I already added a second bit selectable PE table. It's not much effort to add the fueling code for a dry setup. Finding a tester willing is another story. I still need to do all the work to figure out a base setting for the table to allow a round a 150 shot. Which is actually the hold up for me.
An input qual would be nice I guess. But there are a lot of preference variables.
It's not really needed on a wet setup I think. Just TPS and RPM would be the simplest method and allow people to do whatever else they want external just like they normally do now. Just need a manual arm switch as usual in the sol. ckt.. I think the V4 thread had some input on the n20 stuff IIRC. Or maybe the great idea list thread. Maybe overrev protection too.
F5 has been the hold up for the most part on V4 anyway.
Here's what I had running in the 0053 area in the asm.
It's been a while, but IIRC, I had 0056 bit 7 blinking at me when it should have been solid. I also could see the blink in the 0055 kl off timer value. But I suspected it was a v4.13 display problem. 128d kept blinking in the value too which is bit 7. I was out of time at that point.
All I did was swap the stock F5 code to look at the 0056 bit 7 state to control the DC using the stock values/code. Then added code to control 0056 bit 7 state to indicate knock. Well, rpm above set point for bench testing.
Lots of stuff different. Then you have all the stuff the tester has tweaked also. Then all the S_aujp cal tweaks. I only do it once, just before I send it out to the tester. And only if they've shown to be error prone when doing it themselves. We still need to tweak the asm format to make pasting easier from a dis'd test bin. But for doing just code testing, your merge program would speed things up greatly.
For the end of the cal data on a stock aujp bin, $8989 is the last byte.
All of our stuff was just added on after it. The xdf mod's needed to keep track would be nuts otherwise. I did use some of the stock cal area for the shift light code. It was already for that so I didn't want to add more new cal data. It won't break anything if it's set wrong.
Dos Prompt- XP allows you to arrow over to the exact individual letter you want to change and then overwrite it. F3 works the same as with doskey w/o out having to load it. I haven't done any asm on my 98SE machine for 6mo or more.
N2O- as soon as you do the simple stuff for just controlling an output for solenoid control. People chime in with wanting a dry setup.
Since I already added a second bit selectable PE table. It's not much effort to add the fueling code for a dry setup. Finding a tester willing is another story. I still need to do all the work to figure out a base setting for the table to allow a round a 150 shot. Which is actually the hold up for me.
An input qual would be nice I guess. But there are a lot of preference variables.
It's not really needed on a wet setup I think. Just TPS and RPM would be the simplest method and allow people to do whatever else they want external just like they normally do now. Just need a manual arm switch as usual in the sol. ckt.. I think the V4 thread had some input on the n20 stuff IIRC. Or maybe the great idea list thread. Maybe overrev protection too.
F5 has been the hold up for the most part on V4 anyway.
Here's what I had running in the 0053 area in the asm.
Code:
L0050 = 0x0050 ; DRef: 0xCED0,0xD164,0xD166,0xD9DC
L0054 = 0x0054 ; DRef: 0xDA69
L0055 = 0x0055 ; Knock light stay on timer, z=off
;---------------------------------------------------------------------------
L0056 = 0x0056 ; New Options Mode Word
;---------------------------------------------------------------------------
; b7, 1 Turn Knock light on (F5) Code will ck bit and set DC for 3FCC
; b6, 1
; b5, 1
; b4, 1
;
; b3, 1
; b2, 1
; b1, 1
; b0, 1 All I did was swap the stock F5 code to look at the 0056 bit 7 state to control the DC using the stock values/code. Then added code to control 0056 bit 7 state to indicate knock. Well, rpm above set point for bench testing.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Been trying out this location for the display bit holder.
Only the b0 is used for an error check. Squeezed the other bits in and seems to be doing fine there.Was fearing the location might set of the SES but it did not even after driving with it running.
Its a stock EQU in the code so it can be patched in if someone wants to.
The additional EQUs have been giving me fits when trying to make a patch work.
figured to leave the code enabled all the time and get rid of the selection.
You can monitor the light status or a failure from a log too.
Still tweaking
Only the b0 is used for an error check. Squeezed the other bits in and seems to be doing fine there.Was fearing the location might set of the SES but it did not even after driving with it running.
Its a stock EQU in the code so it can be patched in if someone wants to.
The additional EQUs have been giving me fits when trying to make a patch work.
Code:
L0054 = 0x0054 ; My new Status Word
; These bits are set if the corresponding bit is set
; Used as placeholder for Datastream output
;---------------------------------------------------------------------------
; b7, 1 = Knock detected, Light sequence Dwell Latch
; b6, 1 = Last pass Knock Sensor Failure was active, Continuous Indication
; b5, 1 = In TPS AE Limit EXT ON (status of 0045, b6) 53,7
; b4, 1 = MAP AE Done 1st time (status of 0045, b1) 53,7
;
; b3, 1 = In MAP AE (status of 0045, b3) 53,7
; b2, 1 = In TPS AE (status of 0045, b7) 53,7
; b1, 1 = PE Engaged (status of 0046, b5) 53,7
; b0, 1 CHECKED FOR PRIOR ERROR 51 ??? (In Original AUJP Code) DRef: 0xDA69
; You can monitor the light status or a failure from a log too.
Still tweaking
Last edited by JP86SS; Jul 5, 2006 at 11:42 PM.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
Originally Posted by JP86SS
Its a stock EQU in the code so it can be patched in if someone wants to.The additional EQUs have been giving me fits when trying to make a patch work.
Do it the same way I did L0149 for an in car bin.
Or is it the sim giving you fits? It wouldn't be too hard to wire wrap up a test bench. But I'd prefer to have Junks' now that I've heard about it.
I remember seeing that 0054 space now. I didn't want to take the time to see if it was all free. Lots of undefined bits in the hac.
I still need to have a look at your ae status patch.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
I'll ship that stuff over to ya.
Junkcltr has no problem with incorporating his KL code into the S_AUJP project. I just want to see that part done and working (Keeping Vern a happy tester )
I can continue to play with the variable setup as time permits.
I've actually stopped using the simulator until I get a response from the creator. There are strange results from BNE and BEQ being used. Very inconsistent results that I can't explain.
Hopefully there is an explaination so I can continue to use it.
Junkcltr has no problem with incorporating his KL code into the S_AUJP project. I just want to see that part done and working (Keeping Vern a happy tester
)I can continue to play with the variable setup as time permits.
I've actually stopped using the simulator until I get a response from the creator. There are strange results from BNE and BEQ being used. Very inconsistent results that I can't explain.
Code:
Start: NOP ; START OF LIGHT ROUTINE LDAA L898E ; Word where the control bit is stored BITA #$02 ; bit to check (Run the routine if set) BNE EXIT ; BR IF code IS NOT Enabled (exit the routine) This branch does NOT occur if the bit is set in the Control word when running the simulator. Will branch with the bit cleared. LDAA L898E ; Check If "ByPass" is Enabled BITA #$01 ; bit to check BNE DOLIGHT ; No "ByPass" Performed, Do Normal Routine This branch DOES occur if the bit is set in the Control word when running the simulator. Will not BR if the bit is cleared.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Wow, where to begin?
I keep the stock CAL area where it is orginally and add tables after it. I also mess with the ALDL output words at the end of the stock CAL. My code section starts at 0x9000.
Suppose the end user has a stock $8D bin and wants to run the new S_AUJP code. They would first grab the S_AUJP bin and edit the tables that they want. Now they have a working S_AUJP bin with the mods TRAXION did in the original CAL section. Now, a new S_AUJP_vX bin is released (the new tables & code are after the original CAL section). The end user gets the new S_AUJP_vX bin and sets the address to the end of their original $8D CAL section before the ALDL more word definitions (the bin release person gives them the address). The end user runs the merge with their original S_AUJP as the CAL file and the new S_AUJP_vX file as the CODE section. A new bin is created with the orig CAL section and the new ALDL CAL & CODE section. That way all new CAL tables are included in the new bin. Overall, the user first has to edit the spark & VE of the S_AUJP file for their car before updating to a new S_AUJP_vX.
It allows the user to use their existing S_AUJP CAL section with the new S_AUJP_vX ALDL CAL, new CAL tables, and CODE. The new CAL tables should have harmless values in them.
N2O control: A dry shot will take some thought on the fueling equation. Adding a BPW multiplier isn't that bad. The details need to be well thought out though. Yes, testers will be hard to come by. I have been working out the equations for a dry setup. It isn't simple at all. For one, the PWM frequency and ON/OFF time is solenoid dependant if you try to acheive the highest resolution. It is easy to over-drive a solenoid and solenoid opening/closing time changes with pressure from the N2O. It has to be tested with an active N2O system or another gas at that pressure. Lots of testing on the actual ECM PWM driver freqs need to be done. I know I am not at that point yet. I have an idea, but I need to fab some hardware to get real measurements.
Unused addresses: The ECM uses addresses 0x0054 and 0x0055. Your data will mess things up. JP86SS, I think your use of 0x0054 causes the TPS error - Code 22 that I saw on the bench.
Simulators: I use Wookie sometimes. It seems to work OK for testing small sections of code. You can't beat real-time function graphing with TP monitor windows though. For example, you just wrote a new WBO2 2D look up table and want to plot out the equation/transfer function. Change a few ALDL mode words, download the bin, connect the ALDL, turn a few pots and watch the input A/D counts vs. the equation output value. If making a new 3D table vs. MAP vs. RPM (with better resolution of MAP and RPM than stock) you just mess with MAP and RPM and watch it jump to table locations.
My bench uses a MegaStimulator ($40 from www.diyautotune.com....fast shipping). It has one extra through hole PCB for extra LEDS and a few 10K pots. One switch panel for fuel pump, Batt power, and IGN power. Two power input leads are connected. One with battery leads for injector and/or solenoid testing. One lead for function code testing that connects to a 1 AMP, 12 volt wall-wart transformer ($20). I leave the cover off of the ECM for probing if things are not working like I think they should.
Not saying you need a bench, but it does help. Also, the NVRAM module helps because it is NVRAM. I have some code that logs events to it to see if something occurs that I can't see in the code. Later on I dump the NVRAM out of the ALDL and check the values. The NVRAM allows you to not worry about using ECM RAM that could get stepped on. BTW, I am thinking of removing some of the HUD stuff to free ECM RAM and see if I can squeeze my mods into all ECM RAM later on.
I keep the stock CAL area where it is orginally and add tables after it. I also mess with the ALDL output words at the end of the stock CAL. My code section starts at 0x9000.
Suppose the end user has a stock $8D bin and wants to run the new S_AUJP code. They would first grab the S_AUJP bin and edit the tables that they want. Now they have a working S_AUJP bin with the mods TRAXION did in the original CAL section. Now, a new S_AUJP_vX bin is released (the new tables & code are after the original CAL section). The end user gets the new S_AUJP_vX bin and sets the address to the end of their original $8D CAL section before the ALDL more word definitions (the bin release person gives them the address). The end user runs the merge with their original S_AUJP as the CAL file and the new S_AUJP_vX file as the CODE section. A new bin is created with the orig CAL section and the new ALDL CAL & CODE section. That way all new CAL tables are included in the new bin. Overall, the user first has to edit the spark & VE of the S_AUJP file for their car before updating to a new S_AUJP_vX.
It allows the user to use their existing S_AUJP CAL section with the new S_AUJP_vX ALDL CAL, new CAL tables, and CODE. The new CAL tables should have harmless values in them.
N2O control: A dry shot will take some thought on the fueling equation. Adding a BPW multiplier isn't that bad. The details need to be well thought out though. Yes, testers will be hard to come by. I have been working out the equations for a dry setup. It isn't simple at all. For one, the PWM frequency and ON/OFF time is solenoid dependant if you try to acheive the highest resolution. It is easy to over-drive a solenoid and solenoid opening/closing time changes with pressure from the N2O. It has to be tested with an active N2O system or another gas at that pressure. Lots of testing on the actual ECM PWM driver freqs need to be done. I know I am not at that point yet. I have an idea, but I need to fab some hardware to get real measurements.
Unused addresses: The ECM uses addresses 0x0054 and 0x0055. Your data will mess things up. JP86SS, I think your use of 0x0054 causes the TPS error - Code 22 that I saw on the bench.
Simulators: I use Wookie sometimes. It seems to work OK for testing small sections of code. You can't beat real-time function graphing with TP monitor windows though. For example, you just wrote a new WBO2 2D look up table and want to plot out the equation/transfer function. Change a few ALDL mode words, download the bin, connect the ALDL, turn a few pots and watch the input A/D counts vs. the equation output value. If making a new 3D table vs. MAP vs. RPM (with better resolution of MAP and RPM than stock) you just mess with MAP and RPM and watch it jump to table locations.
My bench uses a MegaStimulator ($40 from www.diyautotune.com....fast shipping). It has one extra through hole PCB for extra LEDS and a few 10K pots. One switch panel for fuel pump, Batt power, and IGN power. Two power input leads are connected. One with battery leads for injector and/or solenoid testing. One lead for function code testing that connects to a 1 AMP, 12 volt wall-wart transformer ($20). I leave the cover off of the ECM for probing if things are not working like I think they should.
Not saying you need a bench, but it does help. Also, the NVRAM module helps because it is NVRAM. I have some code that logs events to it to see if something occurs that I can't see in the code. Later on I dump the NVRAM out of the ALDL and check the values. The NVRAM allows you to not worry about using ECM RAM that could get stepped on. BTW, I am thinking of removing some of the HUD stuff to free ECM RAM and see if I can squeeze my mods into all ECM RAM later on.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
I've actually stopped using the simulator until I get a response from the creator. There are strange results from BNE and BEQ being used. Very inconsistent results that I can't explain.
Hopefully there is an explaination so I can continue to use it.
Code:
Start: NOP ; START OF LIGHT ROUTINE LDAA L898E ; Word where the control bit is stored BITA #$02 ; bit to check (Run the routine if set) BNE EXIT ; BR IF code IS NOT Enabled (exit the routine) This branch does NOT occur if the bit is set in the Control word when running the simulator. Will branch with the bit cleared. LDAA L898E ; Check If "ByPass" is Enabled BITA #$01 ; bit to check BNE DOLIGHT ; No "ByPass" Performed, Do Normal Routine This branch DOES occur if the bit is set in the Control word when running the simulator. Will not BR if the bit is cleared.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
JP86SS,
You should probably also look at the ".lst" file created by the assembler and check that it interpreted the instruction correctly. Yo can search the file for the BNE DOLIGHTstring.
I was thinking about the merge file and how it could be used for people starting out with a stock $8D bin or any version of the S_AUJP. If I had a control file that listed which addresses to change in the stock CAL area it would search for those addresses and replace with the data from the new S_AUJP bin. All of TRAXION's mod could be used that way and a user would not have to any work what so ever when going to the S_AUJP. It would still do a block copy of the new S_AUJP CODE and S_AUJP ALDL CAL area. The updated (search & replace) original CAL data would be used along with the S_AUJP CODE and ALDL CAL data for the new that it outputs. I will write something up tonight and see how it works.
The control file would contain strings like (addressing is relative to the start of the bin = 0x0000):
0x00EE
0x01FA
0x0200 - 0x02FF
How does that sound?
You should probably also look at the ".lst" file created by the assembler and check that it interpreted the instruction correctly. Yo can search the file for the BNE DOLIGHTstring.
I was thinking about the merge file and how it could be used for people starting out with a stock $8D bin or any version of the S_AUJP. If I had a control file that listed which addresses to change in the stock CAL area it would search for those addresses and replace with the data from the new S_AUJP bin. All of TRAXION's mod could be used that way and a user would not have to any work what so ever when going to the S_AUJP. It would still do a block copy of the new S_AUJP CODE and S_AUJP ALDL CAL area. The updated (search & replace) original CAL data would be used along with the S_AUJP CODE and ALDL CAL data for the new that it outputs. I will write something up tonight and see how it works.
The control file would contain strings like (addressing is relative to the start of the bin = 0x0000):
0x00EE
0x01FA
0x0200 - 0x02FF
How does that sound?
Last edited by junkcltr; Jul 6, 2006 at 07:41 AM.
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Originally Posted by junkcltr
Unused addresses: The ECM uses addresses 0x0054 and 0x0055. Your data will mess things up. JP86SS, I think your use of 0x0054 causes the TPS error - Code 22 that I saw on the bench.
I didn't see the error when using the 54. Only the last bit is used from all my extensive searching. Will look again anyway.
Maybe it would be best to make that a cal defined variable location so it can be easily moved by name. Something else to try.
I did try the single line command for the bit check but the assembler kept throwing it out due to to large of a jump for the read. Something along those lines. So I went to individual loading of the addy and the bit check.
Did find out in discussions that the "BitA" will clear the register so you have to reload the word after each check.
Didn't remember to check the LST and see if it was the same opcode.
Good idea.
I like the command line transfer idea.
Will help migrate to the "S" bin much easier if the user already has cal data for thier car already.
Will be a large list if you intend to get everything from the current users bin though.
would it be easier to do a full copy of the cal section$0000-$899F (leaves room for adders) and then go back and do a code change for the S_mods?Those are already defined and we know where they are.
Could do a confirm replace on each if desired.
To me it seems like it could get ugly when you want to retain your IAC settings from the current bin and the S_AUJP settings will override them.
Maybe its not even a concern but something to think about.
Jp
Oh yea, I really need to build a bench
Its 1/2 way through the planning stages yet.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Trying to keep me happy, eh? Don't be too concerned, I can be patient! This is all sounding way too good for me to try and rush it.
As for the NOS stuff, I might be able to help you out there as well. I'm not too sure a kit I have access to is a "dry" kit or not. It's the NEX kit designed for the LT1. It manipulates the fuel via their control box and a vacuum line to the AFPR. So it isn't really injecting the fuel like a wet kit would, but it's not entirely a dry kit in that it's not letting the ECM totally manage the fuel either. I might have some acces to a TPI dry kit as well....
As for the NOS stuff, I might be able to help you out there as well. I'm not too sure a kit I have access to is a "dry" kit or not. It's the NEX kit designed for the LT1. It manipulates the fuel via their control box and a vacuum line to the AFPR. So it isn't really injecting the fuel like a wet kit would, but it's not entirely a dry kit in that it's not letting the ECM totally manage the fuel either. I might have some acces to a TPI dry kit as well....
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Damn computers!
I didn't see the error when using the 54. Only the last bit is used from all my extensive searching. Will look again anyway.
Maybe it would be best to make that a cal defined variable location so it can be easily moved by name. Something else to try.
I did try the single line command for the bit check but the assembler kept throwing it out due to to large of a jump for the read. Something along those lines. So I went to individual loading of the addy and the bit check.
Did find out in discussions that the "BitA" will clear the register so you have to reload the word after each check.
Didn't remember to check the LST and see if it was the same opcode.
Good idea.
I like the command line transfer idea.
Will help migrate to the "S" bin much easier if the user already has cal data for thier car already.
Will be a large list if you intend to get everything from the current users bin though.
would it be easier to do a full copy of the cal section$0000-$899F (leaves room for adders) and then go back and do a code change for the S_mods?Those are already defined and we know where they are.
Could do a confirm replace on each if desired.
To me it seems like it could get ugly when you want to retain your IAC settings from the current bin and the S_AUJP settings will override them.
Maybe its not even a concern but something to think about.
Jp
Oh yea, I really need to build a bench
Its 1/2 way through the planning stages yet.
I didn't see the error when using the 54. Only the last bit is used from all my extensive searching. Will look again anyway.
Maybe it would be best to make that a cal defined variable location so it can be easily moved by name. Something else to try.
I did try the single line command for the bit check but the assembler kept throwing it out due to to large of a jump for the read. Something along those lines. So I went to individual loading of the addy and the bit check.
Did find out in discussions that the "BitA" will clear the register so you have to reload the word after each check.
Didn't remember to check the LST and see if it was the same opcode.
Good idea.
I like the command line transfer idea.
Will help migrate to the "S" bin much easier if the user already has cal data for thier car already.
Will be a large list if you intend to get everything from the current users bin though.
would it be easier to do a full copy of the cal section$0000-$899F (leaves room for adders) and then go back and do a code change for the S_mods?Those are already defined and we know where they are.
Could do a confirm replace on each if desired.
To me it seems like it could get ugly when you want to retain your IAC settings from the current bin and the S_AUJP settings will override them.
Maybe its not even a concern but something to think about.
Jp
Oh yea, I really need to build a bench
Its 1/2 way through the planning stages yet.
It sounds like you are trying to do a branch that is farther than +/-127 bytes. Check the BNE offset value is within the range in the ".lst" file.
You are confused about the merge operations. First the original CAL data is copied to a memory variable, then the new S_AUJP code is copied to a memory variable. They are "cat"ed to create a new bin. Then the CONTROL file is read to get addresses to grab CAL data from the S_AUJP and insert (overwrite) the original CAL data in the NEW bin file at the addresses in the control file (there isn't that many mods to the orig S_AUJP in the original CAL area). I will draw a pictorial diagram so it is more easily understood.
Confirm on replace? It makes the batch mode into a non-batch mode. I won't make a "confirm" feature. The user should double check the addresses before running the file. Why would the end user want a confirm when he specified which addresses to replace? No, not ugly because the control file specifies which addresses to uses from the S_AUJP to replace the stock CAL data. If you don't want something replaced, then don't insert an address into the CONTROL file.
Either the end user could go in and manually do a cut & copy of the items they want or just specify them in the CONTROL file. So, if they don't want the new IAC settings, then they don't specify the address.
Originally Posted by JP86SS
Damn computers!
I didn't see the error when using the 54. Only the last bit is used from all my extensive searching. Will look again anyway.
I didn't see the error when using the 54. Only the last bit is used from all my extensive searching. Will look again anyway.
Originally Posted by JP86SS
Did find out in discussions that the "BitA" will clear the register so you have to reload the word after each check.
Scot
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
"control file" , check 
52-56 no use, check
BR too long, check
BNE, BEQ, BitA command review needed,
52-56 no use, check
BR too long, check
BNE, BEQ, BitA command review needed,
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
Originally Posted by ScotSea
You need to just stop using the area of RAM from $0052 to $0056. The ECM uses those locations, and you WILL get unpredictable results trying to use those locations.
Scot
Scot
Now we're trying to find where/why it's used so we don't make that mistake again. And so we can try to free it up if possible. We're just way far down on the knowledge ladder compared to you. I bench tested enough to determine it wasn't my code that was messing up. Just something stepping on my ram address. I passed my info on to JP and switched to more pressing concerns like moving 2k miles.
JP- you don't have a link for the pink book on your desktop????
I haven't researched which method is better Brset or Bitx.
I did a quick scan when I thought of it, but saw that both methods were done stock. Don't recall if there is a cycle time diff.
For the dry setup, I wasn't going to try and make it progressive. Just on or off. From the little bit of info I've got from people. They've just max'd out the PE table for a 100 shot and strip only use. 100 hp of n2o is always 100hp of n20 excluding bottle pressure flucuations etc. So a fixed ratio of fuel to be added is all that's needed for a simple dry setup. Just swap the bin, run a calc to set the adder for the desired hp,stab a nozzle in the CAI and your good to go.....
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by Z69
Now we're trying to find where/why it's used so we don't make that mistake again. And so we can try to free it up if possible.
Originally Posted by Z69
JP- you don't have a link for the pink book on your desktop????
Originally Posted by Z69
I haven't researched which method is better Brset or Bitx.
I did a quick scan when I thought of it, but saw that both methods were done stock. Don't recall if there is a cycle time diff.
I did a quick scan when I thought of it, but saw that both methods were done stock. Don't recall if there is a cycle time diff.
Originally Posted by Z69
For the dry setup, I wasn't going to try and make it progressive. Just on or off. From the little bit of info I've got from people. They've just max'd out the PE table for a 100 shot and strip only use. 100 hp of n2o is always 100hp of n20 excluding bottle pressure flucuations etc. So a fixed ratio of fuel to be added is all that's needed for a simple dry setup. Just swap the bin, run a calc to set the adder for the desired hp,stab a nozzle in the CAI and your good to go.....
For N20, one of the A/D inputs (DxxIN) could be used as an input (switch to ground) to alert the ECM that N2O is ready for use. When the ECM sees the system ready, RPM and TPS are within the N2O window, maybe VSS within a window, AND NO TPS or RPM faults, then enable the new VE/BPW multiplier to be done to the BPW. If doing PWM N2O, then the VE multiplier vs. RPM vs. MAP would work great for squirting before most systems can squirt.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
M68HC11RM.pdf was what I thought of as the pink book.
Got a link for your ref? I hate digging on the Freescale site.
Brset- that would explain it, aggravating what I forget when I don't get to do any code for months at a time. I went and looked at some of my stuff.
I did it right. Just don't remember why I did it that way....getting it pointed out to me online usually makes me remember it though...
N20- that's why I was looking at the simple on off feature first.
You'd need a delay for the fuel adder in a dry setup.
Got a link for your ref? I hate digging on the Freescale site.
Brset- that would explain it, aggravating what I forget when I don't get to do any code for months at a time. I went and looked at some of my stuff.
I did it right. Just don't remember why I did it that way....getting it pointed out to me online usually makes me remember it though...
N20- that's why I was looking at the simple on off feature first.
You'd need a delay for the fuel adder in a dry setup.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I don't have a link for it. I downloaded it way back when it was the motorola site. You could try a search for that filename on the new site. I use the 68HC11RM also. That has good instruction info but is more detailed and spread out.
N2O full on requires a set amount of fuel so I guess a straight adder would be best for that. PWM N2O would be better off with the look up table. I have been keeping an eye out for some used N2O stuff to build a dry setup for testing. I don't think the full on N2O code would require any ECM RAM. The input DxxIN needs to be tested for switch bounce though (probably).
N2O full on requires a set amount of fuel so I guess a straight adder would be best for that. PWM N2O would be better off with the look up table. I have been keeping an eye out for some used N2O stuff to build a dry setup for testing. I don't think the full on N2O code would require any ECM RAM. The input DxxIN needs to be tested for switch bounce though (probably).
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
I've got an 'extra' tpi dry set up since I'm going to use the NEX LT-1 vacuum modifying system. Let me know if you want to try and work out some kind of trade or barter deal for it (we can take that offline - either e-mail or PM is fine with me). Do you want a complete system (bottle, TPI plate, lines, solenoid, etc.)? That's what I've got, a Compucar kit if I remember correctly, but could be NOS. I'll have to check......
Originally Posted by junkcltr
I have debug code that logs 0x0051 to 0x0056 to NVRAM while the ECM is running. I have yet to see 0x0051 and 0x0056 change from a value of zero. The others do change. I am curious how Scott found that 0x0056 changes. I tried all kinds of stuff to get it to change, but it still hasn't changed yet.
Code:
*
*
DoErrorHandler LDY #ErrMask5 ;
CLRA ; Start at '00'
LDX #$0005 ;
*
ErrHandler000 ORAA $51,X ; H0056, H0055, H0054, H0053, H0052
DEX ; OR in temp handler regs
BNE ErrHandler000 ; Loop back to do all locs
*
TSTA ; Check for any errors
BNE ErrHandler030 ; Skip if present errors
* Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
got the book (multiple copies in fact), other help files, programs to display the control bit regs and still have to ask questions
Thanks,
I see that now Scott & Scot. Is that only used in mode 4?
Might be why J' didn't see it move.
Only using 51 at this point anyway but will need to comment that section better for reference (and to see what its doing)
Did I mention I hate indexed addressing?
We could make the value #0x0004 and start the routine at 50.
Error word 5 is not used in AUJP.
would make it run from 55-52 in that case.
Need to look at it more if we really need the space.
Thanks,
I see that now Scott & Scot. Is that only used in mode 4?
Might be why J' didn't see it move.
Only using 51 at this point anyway but will need to comment that section better for reference (and to see what its doing)
Did I mention I hate indexed addressing?
We could make the value #0x0004 and start the routine at 50.
Error word 5 is not used in AUJP.
would make it run from 55-52 in that case.
Need to look at it more if we really need the space.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by vernw
I've got an 'extra' tpi dry set up since I'm going to use the NEX LT-1 vacuum modifying system. Let me know if you want to try and work out some kind of trade or barter deal for it (we can take that offline - either e-mail or PM is fine with me). Do you want a complete system (bottle, TPI plate, lines, solenoid, etc.)? That's what I've got, a Compucar kit if I remember correctly, but could be NOS. I'll have to check......
For example, suppose you have 24#/hr injectors and the FMU boosts the pressure to 70psi (24 #/hr looks like 30#/hr) . The injector BPWs stay the same as N/A w/o N2O. Suppose at 3000 RPM, you make 200HP with a 52% injector DC. When you hit the N2O at 3000 RPM, the FMU boosts pressure and the injectors now look like 30#/hr and at the 52% DC can provied enough fuel for 255HP. Yeah, 45HP too lean.
So the idea is too bump up the fuel pressure more to make it OK at 3000 RPM, but then it is too rich at 5600 RPM. End result, you need a fuel adder table for the FMU fuel fed N2O system. With a straight big set of injectors, you need a fuel adder. With big injectors and PWM N20, you need a BPW multiplier or adder.
Overall, a BPW multiplier and/or adder table vs. RPM would give the best tunability. I think the ECM alert input (DxxIN) will need some decent filtering (stock LAG filter with a decent coef) for the switch debounce feature so that means at least one RAM location is needed.
Thanks for the offer on the system. I have my mind set on a 15lb or 20lb bottle, either an NX or Racetested solenoid, and a jet at the solenoid. I am going to piece together a system. I am in no rush to build it so I have been searching for deals. I mainly want to get a solenoid first to start coding/testing so see how fast I can PWM it.
Thank you ScotSea. That is the code that modifies that RAM area. I will have to comment that because of the use of the ldx to do it.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Bummer - sounds like I may have a trojan horse NOS kit, so how do they sell them like that if they don't work correctly? What a crummy set of circumstances.....
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
It's not that bad. I was told that they usually up the fuel pressure enough so that it is fine at low RPM and rich at high RPMs. In your case, you would benefit from a BPW adder/subtactor table. It isn't a big deal. I just wanted to make you aware of it so you can tune accordingly.
Supreme Member
Joined: Sep 2003
Posts: 1,409
Likes: 1
From: Texas
I have debug code that logs 0x0051 to 0x0056 to NVRAM while the ECM is running. I have yet to see 0x0051 and 0x0056 change from a value of zero. The others do change. I am curious how Scott found that 0x0056 changes. I tried all kinds of stuff to get it to change, but it still hasn't changed yet.
And having the value go to zero would cause a problem, and you'd never see it if it was already zero. I don't recall if there was a problem with 0056.
Mask5, error handler??? I've haven't looked in that area of the code much.
I'll have a look when I get time and see about changing $51 to $4B or $4C or whatever.
edit: ok $4C might not work
Here's most of the relavent code from AUJP
Code:
;-------------------------
; DO Non Vol RAM CK SUM
;-------------------------
jsr LE4B1 ; GO DO Non Vol RAM CKSUM (Is LE4A9 in ANHT)
std *L0017 ; Non Vol ERROR WORD CHECK SUM
bset *L0042,#0x01 ; SET CHECK ENGINE LIGHT ON BIT
bra LDA95 ; Branch To... (Goes to LDA8D in ANHT)
LDA7A: brclr *L0037,#0x80,LDA86 ; BR IF NOT b7, 1 = ENGINE RUNNING(Goes to LDA7E in ANHT); CRef: 0xDA65,0xDA69
; ... else
jsr LDC0D ; Jump To... (Goes to LDC05 in ANHT)
jsr LDB7E ; Jump To... (Goes to LDB76 in ANHT)
bra LDA95 ; Branch To...(Goes to LDA8D in ANHT)
snip----
LDB7E: ldy #L824D ; ERROR WD 5 MASK, 0000 0000 , ERR 65 & 66 ; CRef: 0xDA81
clra ;
ldx #0x0005 ; VAL = 5d, or 0101 b
LDB86: oraa 0x51,x ; ; CRef: 0xDB89
dex ;
bne LDB86 ; BR IF N/Z
; .... else
tsta ; Subtract 0x00 from A, set condition codes
bne LDBAE ; BR IF NOT EQUAL ZERO (Goes to LDBA6 in ANHT)
; .... else
ldx #0x0005 ; VAL = 5d, or 0101 b
LDB91: ldaa 0x4C,x ; ; CRef: 0xDB9B
anda 0x00,y ;
staa 0x51,x ;
dey ;
dex ;
bne LDB91 ; BR IF NOT EQUAL ZERO (Goes to LDB89
in ANHT) I'd suspected something was forcing the ram value to zero intermittantly based on the way my logs looked.
Now to figure out what's going on there.
Last edited by Z69; Jul 9, 2006 at 12:42 AM.
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Just a quick update. The merge_bin tool is still being worked. The control file thing has turned into a monster. I have been working on parsing the string for comments, valid addresses, junk addresses, etc.
I am hoping to have it done in another week.......sorry......the new garage toy has been keeping me busy.
I am hoping to have it done in another week.......sorry......the new garage toy has been keeping me busy.
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Sounds great, sorry this turned out to be a lot more difficult than originally estimated....
Thread Starter
Joined: Apr 2004
Posts: 3,180
Likes: 3
From: Browns Town
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
Not your fault, Don't feel bad.
It's just a hobby, I'm just glad I don't do this for a living!
It'd be mac-n-cheese every night
It's just a hobby, I'm just glad I don't do this for a living!
It'd be mac-n-cheese every night
Supreme Member
iTrader: (2)
Joined: Jul 2003
Posts: 3,205
Likes: 0
From: Dallas, TX area
Car: 91 Formula WS6 (Black, T-Tops)
Engine: 383 MiniRam (529 HP, 519 TQ - DD2K)
Transmission: Built '97 T56, Pro 5.0, CF-DF
Axle/Gears: 4.11 posi Ford 9"
Ha-Ha - I'd be lucky to even get that!!!!!
Supreme Member
iTrader: (1)
Joined: Jan 2002
Posts: 4,432
Likes: 1
From: garage
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Not your fault, Don't feel bad.
It's just a hobby, I'm just glad I don't do this for a living!
It'd be mac-n-cheese every night
It's just a hobby, I'm just glad I don't do this for a living!
It'd be mac-n-cheese every night
The merge_bin tool is just about ready. I have to do more documenting so that others can understand what it does. I think a few concrete examples should explain how it works. When a new S_AUJP_Vx is released, a merge_control.txt file will go with it. The tool will merge the users existing CAL data with the new S_AUJP_Vx CODE. Then the user can specify which of the S_AUJP_Vx CAL data will replace their existing CAL data. So the control file will list which S_AUJP_Vx CAL data mods the end user can add to their bin. They would just go in and uncomment the S_AUJP_Vx mods that they want done. Or the default would be to add all the new S_AUJP_Vx CAL data and the end user comments out the ones that they do not want done.
In general, do most users want the S_AUJP_Vx CAL data? Or do they want to keep most of their existing CAL data?