$8D new bit status definition
05-27-2006, 03:46 PM
#1
Supreme Member
Thread Starter
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
$8D new bit status definition
I am trying to use word 7 of the datastream to indicate some functions that are not currently displayed so then I can see the reactions of PE and AE as they occur on the logs.
To do this I want to grab the following bits:
0045 b7 : In TPS AE
0045 b6 : TPS AE Limit EXT on (not sure what that does yet)
0045 b3 : In MAP AE
0045 b1 : MAP AE done 1st time
or intead of b1 make it:
0046 b5 : In PE
Would probably do both anyway.
Having a brain fart on how to do this effectively.
I figure to grab each of these bits I'll need to set aside an open memory location word (not 0008, that would set the errors) and then do a check on each of the bits and write the status into the new word. Change the datstream to reflect the new word location.
This just seems to be the long way around in getting the bits changed in the new word.
Is there a way to do a transfer of the status by masking the words in less cycles?
Must be a better way than doing a bunch of BRSET or BRCLR's. Makes lots of code lines.
Code:
;----------------------------
.word 0x0008 ; 7 MALFUNCTION WORD 5
;
; b7, 1= ERROR 64, Not used
; b6, 1= ERROR 65, Not used
; b5, 1= ERROR 66, Not used
; b4, 1= ERROR , Not used
;
; b3, 1= ERROR , Not used
; b2, 1= ERROR , Not used
; b1, 1= ERROR , Not used
; b0, 1= ERROR , Not used
;--------------------------- 0045 b7 : In TPS AE
0045 b6 : TPS AE Limit EXT on (not sure what that does yet)
0045 b3 : In MAP AE
0045 b1 : MAP AE done 1st time
or intead of b1 make it:
0046 b5 : In PE
Would probably do both anyway.
Having a brain fart on how to do this effectively.
I figure to grab each of these bits I'll need to set aside an open memory location word (not 0008, that would set the errors) and then do a check on each of the bits and write the status into the new word. Change the datstream to reflect the new word location.
This just seems to be the long way around in getting the bits changed in the new word.
Is there a way to do a transfer of the status by masking the words in less cycles?
Must be a better way than doing a bunch of BRSET or BRCLR's. Makes lots of code lines.
05-27-2006, 11:10 PM
#2
Supreme Member
Thread Starter
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
I did it this way...
OK, don't hit "TAB" when posting!! 
Last edited by JP86SS; 05-27-2006 at 11:32 PM.
05-27-2006, 11:10 PM
#3
Supreme Member
Thread Starter
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
I did it this way...
Just seems like there should be an easier way 
Code:
; ADDED Bit checking update routine to obtain
; Status of AE and PE to output them in the
; ALDL DataStream (word 7, now location 0053)
startpoint: BRA CHK457 ; Entry to the DATAWORD bit update routine
CHK457: BRCLR *L0045,#0x80,CLR457 ; Check if in TPS AE
; (status of 0045, b7)
BSET *L0053,#0x80 ; SET bit 7 In New DATAWORD
BRA CHK456 ; GOTO NEXT
CLR457: BCLR *L0053,#0x80 ; CLR bit 7 In New DATAWORD
CHK456: BRCLR *L0045,#0x40,CLR456 ; Check if TPS AE Limit EXT ON is Set
; (status of 0045, b6)
BSET *L0053,#0x40 ; SET bit 6 In New DATAWORD
BRA CHK453 ; GOTO NEXT
CLR456: BCLR *L0053,#0x40 ; CLR bit 6 In New DATAWORD
CHK453: BRCLR *L0045,#0x08,CLR453 ; Check if in MAP AE
; (status of 0045, b3)
BSET *L0053,#0x20 ; SET bit 5 In New DATAWORD
BRA CHK461 ; GOTO NEXT
CLR453: BCLR *L0053,#0x20 ; CLR bit 5 In New DATAWORD
CHK451: BRCLR *L0046,#0x02,CLR451 ; Check if MAP AE Done 1st Time
; (status of 0045, b1)
BSET *L0053,#0x10 ; SET bit 4 In New DATAWORD
BRA CHK461 ; GOTO NEXT
CLR451: BCLR *L0053,#0x10 ; CLR bit 4 In New DATAWORD
CHK461: BRCLR *L0046,#0x20,CLR461 ; Check if In PE
; (status of 0046, b5)
BSET *L0053,#0x08 ; SET bit 3 In New DATAWORD
BRA CHKOUT ; GOTO NEXT/EXIT
CLR461: BCLR *L0053,#0x08 ; CLR bit 3 In New DATAWORD
CHKOUT: NOP ; RESUME "Startpoint" Last edited by JP86SS; 05-27-2006 at 11:43 PM.
05-27-2006, 11:10 PM
#4
Supreme Member
Thread Starter
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
I did it this way...
; Put this in place of the word 7 definition in the Mode 1 output
Code:
;-------------------------------------
.word 0x0053 ; 7. New DATAWORD for AE and PE Status
; (Was 0x0008 MALFUNCTION WORD 5)
;
; b7, 1= In TPS AE
; b6, 1= TPS AE Limiting EXT ON
; b5, 1= In MAP AE
; b4, 1= MAP AE Done 1st Time
;
; b3, 1= In PE
; b2, 1= (Not used)
; b1, 1= (Not used)
; b0, 1= (Not used)
;---------------------------------------- Last edited by JP86SS; 05-27-2006 at 11:23 PM.
05-27-2006, 11:30 PM
#5
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
It all depends on the polarity of the bits being set. If the default is zero then I just clear the register first and then set bits as required.
I think in the example you have you could have done a "clr reg_z" first. Then when doing the checks only set the bits.
I think in the example you have you could have done a "clr reg_z" first. Then when doing the checks only set the bits.
05-27-2006, 11:36 PM
#6
Supreme Member
Thread Starter
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
That would get rid of about half the code.
The example above comes out to 63 cycles if nothing was set, 78 if all were set.
New way yeilds 39 cycles if nothing was set, 66 if all are set.
Thanks,
Jp
The example above comes out to 63 cycles if nothing was set, 78 if all were set.
New way yeilds 39 cycles if nothing was set, 66 if all are set.
Thanks,
Jp
Last edited by JP86SS; 05-28-2006 at 12:07 AM.
05-28-2006, 12:08 AM
#7
Supreme Member
Thread Starter
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
New Code
Code:
start: CLR *L0053 ; Entry to the DATAWORD bit update routine
; ADDED Bit checking update routine to obtain
; Status of AE and PE to output them in the
; ALDL DataStream (word 7, now location 0053)
CHK457: BRCLR *L0045,#0x80,CHK456 ; Check if in TPS AE
; (status of 0045, b7)
BSET *L0053,#0x80 ; SET bit 7 In New DATAWORD
CHK456: BRCLR *L0045,#0x40,CHK453 ; Check if TPS AE Limit EXT ON is Set
; (status of 0045, b6)
BSET *L0053,#0x40 ; SET bit 6 In New DATAWORD
CHK453: BRCLR *L0045,#0x08,CHK451 ; Check if in MAP AE
; (status of 0045, b3)
BSET *L0053,#0x20 ; SET bit 5 In New DATAWORD
CHK451: BRCLR *L0046,#0x02,CHK461 ; Check if MAP AE Done 1st Time
; (status of 0045, b1)
BSET *L0053,#0x10 ; SET bit 4 In New DATAWORD
CHK461: BRCLR *L0046,#0x20,CHKOUT ; Check if In PE
; (status of 0046, b5)
BSET *L0053,#0x08 ; SET bit 3 In New DATAWORD
CHKOUT: NOP ; RESUME "start" Could be RTS if needed. Last edited by JP86SS; 06-24-2006 at 02:36 PM.
Trending Topics
05-29-2006, 12:42 PM
#9
Supreme Member
Thread Starter
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
Works good
Been running it for two days now.
Let me know I was hitting MAP AE while idling.
My new cam is a bit lopey and idles around 50-55 Kpa.
Just going over some logs of it in action now
Inserted it into the Oil temp routing (Seg 2) and re-assembled.
Not sure how to patch this into a stock bin so others can play with it too.
Have to see where I can jump it in at. Probably the same spot but I don't know if the JSR will be too far.
Want to put it far enough out so other patches (WB & Ext VE) are not compromised.
Let me know I was hitting MAP AE while idling.
My new cam is a bit lopey and idles around 50-55 Kpa.
Just going over some logs of it in action now
Inserted it into the Oil temp routing (Seg 2) and re-assembled.
Not sure how to patch this into a stock bin so others can play with it too.
Have to see where I can jump it in at. Probably the same spot but I don't know if the JSR will be too far.
Want to put it far enough out so other patches (WB & Ext VE) are not compromised.
05-29-2006, 07:18 PM
#10
Junior Member
iTrader: (2)
Join Date: Jun 2001
Location: Sayre, PA
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
Code:
start: CLR *L0053 ; Entry to the DATAWORD bit update routine ... CHKOUT: NOP ; RESUME "start"
Scot
05-29-2006, 10:06 PM
#11
Supreme Member
Thread Starter
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
Since I was putting this into one of the slower routines, Is there the possibility of exceeding or missing the fast loop interrupt by doing that?
Still not fully up on the sequencing of the loops.
Does the fast interrupt always re-execute the spark/fuel and then return to the other (last) loops?
Still not fully up on the sequencing of the loops.
Does the fast interrupt always re-execute the spark/fuel and then return to the other (last) loops?
05-30-2006, 02:55 AM
#12
Supreme Member
iTrader: (2)
Join Date: Jul 2003
Location: Dallas, TX area
Posts: 3,205
Likes: 0
Received 0 Likes
on
0 Posts
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"
Cool stuff JP, would be interested in trying some of this myself (as well as the KL we keep talking about) 
05-30-2006, 11:16 AM
#13
Supreme Member
Thread Starter
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
I hear ya 
Its the A.D.D. kicking in again.
Got basic driving movement feeling good now.
Once I see some knock counts climbing, It'll be done
One thing I did find was that the 727 used the same "dual quad" output for the TCC.
Going to look at that code and see why it works there and not on the 730.
Its the A.D.D. kicking in again.
Got basic driving movement feeling good now.
Once I see some knock counts climbing, It'll be done
One thing I did find was that the 727 used the same "dual quad" output for the TCC.
Going to look at that code and see why it works there and not on the 730.
05-30-2006, 07:36 PM
#14
Junior Member
iTrader: (2)
Join Date: Jun 2001
Location: Sayre, PA
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
Since I was putting this into one of the slower routines, Is there the possibility of exceeding or missing the fast loop interrupt by doing that?
Originally Posted by JP86SS
Still not fully up on the sequencing of the loops.
Does the fast interrupt always re-execute the spark/fuel and then return to the other (last) loops?
Does the fast interrupt always re-execute the spark/fuel and then return to the other (last) loops?
If you were to get an ALDL interrupt, it would go service the interrupt, and when done, it would then return back to the point where it got interrupted from. Just think of it as a shoulder tap, with someone saying "Go do this right now.", and then you're done, you go back and say "Now where was I?", and pick up where you left off.
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
Scot
05-31-2006, 12:01 AM
#15
Supreme Member
Thread Starter
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
Thanks for reply ScotSea, I was under the impression that the fuel and timing loops were done on a timed interrupt and not so much on a linear basis.
Re-running at every occurrance of a timed interrupt to keep the operation at a constant speed/update rate. Maybe I'm all wet on my understanding of it.
I understand the linearity of it when looking at the code, the interrupts just keep me guessing as to when/where the sequence goes. (or does it?)
Does the SUB complete before the fuel or timing is re-run or does an interrupt just make the jump back to the F/T routines? (and then go back and finish the SUB that was started)
If you could add or clarify how that operates, That would be great.
TIA
Re-running at every occurrance of a timed interrupt to keep the operation at a constant speed/update rate. Maybe I'm all wet on my understanding of it.
I understand the linearity of it when looking at the code, the interrupts just keep me guessing as to when/where the sequence goes. (or does it?)
Does the SUB complete before the fuel or timing is re-run or does an interrupt just make the jump back to the F/T routines? (and then go back and finish the SUB that was started)
If you could add or clarify how that operates, That would be great.
TIA
05-31-2006, 04:26 AM
#16
Junior Member
iTrader: (2)
Join Date: Jun 2001
Location: Sayre, PA
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
[QUOTE=JP86SS]Thanks for reply ScotSea, I was under the impression that the fuel and timing loops were done on a timed interrupt and not so much on a linear basis.
[/QUOTE
It does run based on a periodic interrupt.
It is set up to complete the fuel and timing loops and the SUBs that follow before the next periodic interrupt occurs. When adding code, you can overrun the cycle time allowed, if you add too much.
I set up some timers to keep track of the time left after the loops are all done, and it is just wating for the next periodic interrupt. That way I know if there is any tme left to do things.
Scot
[/QUOTE
It does run based on a periodic interrupt.
Originally Posted by JP86SS
Re-running at every occurrance of a timed interrupt to keep the operation at a constant speed/update rate. Maybe I'm all wet on my understanding of it.
I understand the linearity of it when looking at the code, the interrupts just keep me guessing as to when/where the sequence goes. (or does it?)
Does the SUB complete before the fuel or timing is re-run or does an interrupt just make the jump back to the F/T routines? (and then go back and finish the SUB that was started)
If you could add or clarify how that operates, That would be great.
TIA
I understand the linearity of it when looking at the code, the interrupts just keep me guessing as to when/where the sequence goes. (or does it?)
Does the SUB complete before the fuel or timing is re-run or does an interrupt just make the jump back to the F/T routines? (and then go back and finish the SUB that was started)
If you could add or clarify how that operates, That would be great.
TIA
I set up some timers to keep track of the time left after the loops are all done, and it is just wating for the next periodic interrupt. That way I know if there is any tme left to do things.
Scot
05-31-2006, 11:20 AM
#17
Supreme Member
Thread Starter
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
Excellent info.
So I gather the flag for 6.25 ms has been exceeded is the indicator of that.
Lots more to think about now.
06-23-2006, 05:35 PM
#18
Supreme Member
Thread Starter
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
ScotSea
I set up some timers to keep track of the time left after the loops are all done, and it is just wating for the next periodic interrupt. That way I know if there is any tme left to do things.
Scot
I set up some timers to keep track of the time left after the loops are all done, and it is just wating for the next periodic interrupt. That way I know if there is any tme left to do things.
Scot
I think I'm hitting the limit in the routine I'm using.
Even with the SEI... I get intermittant readings that I know are false.
PE drops out every other scan on the ALDL but if I look at just that bit it does not "seem" to be changing at the points I see in the logs.
Can you splain how you did the timers to know if you've exceeded the limit?
Would be nice to how much time is available in each routine.
TIA
06-23-2006, 06:22 PM
#19
Junior Member
iTrader: (2)
Join Date: Jun 2001
Location: Sayre, PA
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
OK,
I think I'm hitting the limit in the routine I'm using.
I think I'm hitting the limit in the routine I'm using.
Whoops, make that L0053 to L0034.
Scot
06-23-2006, 11:24 PM
#20
Supreme Member
Thread Starter
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
I'll try some alternates tomorrow (hopefully)
I have more code than just the bit status routine running in different segments so I'm am getting concerned. I haven't been planning where I put things and all of the readings of on/off transitions are occurring in several different routines.
WB "Should" be reading correctly but gets kind of the same high/low readings then what seems to be a good one thrown in the middle every few scans. Need to look closer at my logs again and confirm it along with a meter on the WB output.
34-35 are used for WB, 001C or D looks good though.
I'll move the routines to different locations also (or just go back to base code and add them one by one) and see if there is a change in the response. Haven't tried that yet.
Lots to play with.
Thanks,
John
I have more code than just the bit status routine running in different segments so I'm am getting concerned. I haven't been planning where I put things and all of the readings of on/off transitions are occurring in several different routines.
WB "Should" be reading correctly but gets kind of the same high/low readings then what seems to be a good one thrown in the middle every few scans. Need to look closer at my logs again and confirm it along with a meter on the WB output.
34-35 are used for WB, 001C or D looks good though.
I'll move the routines to different locations also (or just go back to base code and add them one by one) and see if there is a change in the response. Haven't tried that yet.
Lots to play with.
Thanks,
John
06-24-2006, 07:40 AM
#22
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Excellent info.
So I gather the flag for 6.25 ms has been exceeded is the indicator of that.
Lots more to think about now.
clr_x
loop: inc_x
mul ; delay
mul ; delay
stx mem_loc
cmpx CAL_COUNT
bne loop
One other thing. How are you guys inserting your CAL data with a fresh bin compile? I wrote a small C program that takes in two files and spits out one new file. It takes in a 32K bin to use the CAL data and a 32K bin to use the code data. It combines the CAL data and CODE data to make a new 32K bin. It also computes the checksum and stores it to the new bin so you don't have to open up the bin in a bin editing tool. You can just write it to EEPROM directly. It reports the checksum also to the DOS prompt. Send me a PM if you are interested in trying it.
EDIT: I like the MonteCarSlow NVRAM module. You will never have to worry about using memory locations again. It is easily the best hardware I bought for messing with ECMs. You might want to check if he has made more of them.
Last edited by junkcltr; 06-24-2006 at 07:48 AM.
06-24-2006, 02:24 PM
#23
Supreme Member
Thread Starter
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
Z' , 0053 is the "dataword" that I created to hold these bits for outputting to the ALDL. (See above)
The flipping in 56 was the knock light routine (still needs to be checked out better)
Will shoot you the file I'm playing with now. (not the MT one)
Also will shoot you an updated comment 02 of the MT.
Haven't put my NVRAM module in yet
That would make things easier.
Right now I'm changing the asm with my cal and assembling.
Eventually with the module I was going to just change the $8' to $2 and keep going that way. Your way sounds like it does save allot of time.
The flipping in 56 was the knock light routine (still needs to be checked out better)
Will shoot you the file I'm playing with now. (not the MT one)
Also will shoot you an updated comment 02 of the MT.
Haven't put my NVRAM module in yet
That would make things easier.
Right now I'm changing the asm with my cal and assembling.
Eventually with the module I was going to just change the $8' to $2 and keep going that way. Your way sounds like it does save allot of time.
06-24-2006, 08:14 PM
#24
Junior Member
iTrader: (2)
Join Date: Jun 2001
Location: Sayre, PA
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
I'll try some alternates tomorrow (hopefully)
I have more code than just the bit status routine running in different segments so I'm am getting concerned. I haven't been planning where I put things and all of the readings of on/off transitions are occurring in several different routines.
WB "Should" be reading correctly but gets kind of the same high/low readings then what seems to be a good one thrown in the middle every few scans. Need to look closer at my logs again and confirm it along with a meter on the WB output.
34-35 are used for WB, 001C or D looks good though.
I'll move the routines to different locations also (or just go back to base code and add them one by one) and see if there is a change in the response. Haven't tried that yet.
Lots to play with.
Thanks,
John
I have more code than just the bit status routine running in different segments so I'm am getting concerned. I haven't been planning where I put things and all of the readings of on/off transitions are occurring in several different routines.
WB "Should" be reading correctly but gets kind of the same high/low readings then what seems to be a good one thrown in the middle every few scans. Need to look closer at my logs again and confirm it along with a meter on the WB output.
34-35 are used for WB, 001C or D looks good though.
I'll move the routines to different locations also (or just go back to base code and add them one by one) and see if there is a change in the response. Haven't tried that yet.
Lots to play with.
Thanks,
John
Easiest though is to add that 2k SRAM that is not populated in the 730. I added a battery backed SRAM to that area, and moved the VE tables over to the RAM. Then just used the O2 feedback to correct the VE tables. Also used an LT1 MAF and stored the airflow data there for each VE point. Also stored the SD calculated airflow and the MAF airflow/SD Airflow ratio for each VE point, along with the calculated air temp used for the SD air temp density lookup.
Don't use the 0052 to 0056 area of RAM either. Those locs are used by the program. There is a popular WB patch that tries to use that area, and the CEL stays on because of it.
Scot
06-24-2006, 11:22 PM
#25
Supreme Member
Thread Starter
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
Crap, both of those areas are in use by all of my code. (Thanks for the info)
Been wondering where the BLM was stored. That big open space that "looked" unused was too tempting to pass by.
Man do I want to pick your brain right now shoot me a PM pleeeeze.
I'm not a good hardware guy, can you provide info how you did the 2k adder?
Didn't even know that was an option until you mentioned it. Part no# of the mem and a bit of instruction maybe...Got some searching to do.
Would like to do all this without the NVRAM board so it could be put out for stock patches but its looking inevitable to use now.
Really wanted to improve the operation in a way that all can use it too.
Doing the NVRAM board (that I do have) will get my needs handled to make this work but makes all the code unusable by anyone without it.
Was trying to keep the new stuff within the realm of the stock hardware if at all possible (turns out it may not be due to memory space is just not looking good)
Just looking to bridge the gap so anyone willing to do some hardcore changes and invest the time can benefit and possibly provide feedback to expand/enhance from there, just to have a bin out there that allows the use of the features we've come up with. (Z'69 and I)
Anyway, looks like its up to about 300 at the wheels.
I still need to get my CAI to stop hitting the fan , and try to find out what happened to the A/C belt again (Its gone for the third time now)
Does anyone have any code that can save money on belts?
Been wondering where the BLM was stored. That big open space that "looked" unused was too tempting to pass by.
Man do I want to pick your brain right now
shoot me a PM pleeeeze.I'm not a good hardware guy, can you provide info how you did the 2k adder?
Didn't even know that was an option until you mentioned it. Part no# of the mem and a bit of instruction maybe...Got some searching to do.
Would like to do all this without the NVRAM board so it could be put out for stock patches but its looking inevitable to use now.
Really wanted to improve the operation in a way that all can use it too.
Doing the NVRAM board (that I do have) will get my needs handled to make this work but makes all the code unusable by anyone without it.
Was trying to keep the new stuff within the realm of the stock hardware if at all possible (turns out it may not be due to memory space is just not looking good)
Just looking to bridge the gap so anyone willing to do some hardcore changes and invest the time can benefit and possibly provide feedback to expand/enhance from there, just to have a bin out there that allows the use of the features we've come up with. (Z'69 and I)
Anyway, looks like its up to about 300 at the wheels.
I still need to get my CAI to stop hitting the fan
, and try to find out what happened to the A/C belt again (Its gone for the third time now)Does anyone have any code that can save money on belts?
06-25-2006, 10:13 PM
#26
I thought I checked 0052-0056 for use...hmmmm
I knew about the blm area, I thought we'd marked that....????
I guess I'll need to work on shortening the stack sooner than expected.
Least till the 2k gets worked out.
Belt throwing is usually due to alignment issues or the wrong belt.
I knew about the blm area, I thought we'd marked that....????
I guess I'll need to work on shortening the stack sooner than expected.
Least till the 2k gets worked out.
Belt throwing is usually due to alignment issues or the wrong belt.
06-26-2006, 10:58 AM
#27
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Been running it for two days now.
Let me know I was hitting MAP AE while idling.
My new cam is a bit lopey and idles around 50-55 Kpa.
Let me know I was hitting MAP AE while idling.
My new cam is a bit lopey and idles around 50-55 Kpa.
The difference is used in the MAP delta vs TPS table. The AUJP has it set to trigger AE when the diff. is greater than 3.13 KPA. You can see the difference by multiplying .313 to the 0x00A9 value. Then set the table value according to that for 0% TPS. Or you could play with the filter coef.........you would be surprised how often AE is enabled.
Also, AE can not be enabled when the MAP sensor reads 99.5 KPA or above. I thought that was kind of interesting. That is bad bad for boost applications. A real pain in the butt to fix up to.....it took hours to figure out how to fix it.
Originally Posted by JP86SS
Inserted it into the Oil temp routing (Seg 2) and re-assembled.
Not sure how to patch this into a stock bin so others can play with it too.
Have to see where I can jump it in at. Probably the same spot but I don't know if the JSR will be too far.
Want to put it far enough out so other patches (WB & Ext VE) are not compromised.
Not sure how to patch this into a stock bin so others can play with it too.
Have to see where I can jump it in at. Probably the same spot but I don't know if the JSR will be too far.
Want to put it far enough out so other patches (WB & Ext VE) are not compromised.
That is the way I do it and insert code where ever I want. I always put new tables after the original CAL tables/data.
I can understand having trouble with branch statements but not with jump statements.
06-26-2006, 11:04 AM
#28
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
OK,
I think I'm hitting the limit in the routine I'm using.
Even with the SEI... I get intermittant readings that I know are false.
PE drops out every other scan on the ALDL but if I look at just that bit it does not "seem" to be changing at the points I see in the logs.
I think I'm hitting the limit in the routine I'm using.
Even with the SEI... I get intermittant readings that I know are false.
PE drops out every other scan on the ALDL but if I look at just that bit it does not "seem" to be changing at the points I see in the logs.
If you really want an accurate reading, then use your NVSRAM module. Write the byte/word to a new memory location each time it is updated. Then read out the NVRAM using MonteCarSlow's tools. This allows you to get 4K samples of the real value. Doing it with ALDL logging will give you an idea what is going on but it sounds like you want a more accurate result.
06-26-2006, 11:13 AM
#29
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Right now I'm changing the asm with my cal and assembling.
Eventually with the module I was going to just change the $8' to $2 and keep going that way. Your way sounds like it does save allot of time.
Eventually with the module I was going to just change the $8' to $2 and keep going that way. Your way sounds like it does save allot of time.
Why wait on the NVRAM module. 1) you get extra memory space for memory variables (used by new code). 2) you can update the CAL reliably in a matter of 10s of seconds.
For the bench setup and writing new code, I use the emulator to have access to the entire 32K for the code updates. In the car I always use a ZIF & EEPROM or just straight EEPROM w/o the ZIF.
06-26-2006, 11:21 AM
#30
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by Z69
What is using L0053? There is no reference to L0053 in the dis file???
I've also seen some bit flipping at 0056h.
I've also seen some bit flipping at 0056h.
What mask are all of you talking about? AUJP?
Sometimes you won't see a mem location used directly (just like the segment jump table).
Example, ldx #0x0050
staa #0x06,x ; store to address 0x0056
Notice there is only a reference to 0x0050 and none to 0x0056 even though 0x0056 is actually used in this example.
I have found that the stock AUJP seems to use 0x0053.
06-26-2006, 11:30 AM
#31
Supreme Member
Thread Starter
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
Originally Posted by junkcltr
You are trying to look at a variable at different times. It is the sampling rate of the ALDL not in sync with the update rate of the variable.
The bit is being cleared and then reset to display in my routine so it should still be set each time it is run but that is not the case.
I could just be compromising the whole thing by the locations I used.
Actually suprised that I haven't had more problems because of using the BLM area.
I stopped doing stacked bins until I could find out why evry 20-30 seconds the fuel would just shut off and then come back on. I think the BLM memory issue has something to do with it. That doesn't occurr on the 29C256 single burn versions. Only the stacked ones did it.
Not even trying to figure that out, just going to fix things and move on.
Z' be careful with the stack. IIRC there is a check to see if the last addy is zero for stack overflow error checking. Need to confirm that though.
(yes, AUJP is the base I'm working from)
Mainly worked from the variable list in the memory section to locate unused memory.
Did I mention I hate indexed addressing!
Last edited by JP86SS; 06-26-2006 at 11:36 AM.
06-26-2006, 12:11 PM
#32
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
I understand the update rate of the ALDL is no where near that of the actual bit but if I'm in PE for 5-6 seconds the indication should be constant.
The bit is being cleared and then reset to display in my routine so it should still be set each time it is run but that is not the case.
I could just be compromising the whole thing by the locations I used.
Actually suprised that I haven't had more problems because of using the BLM area.
I stopped doing stacked bins until I could find out why evry 20-30 seconds the fuel would just shut off and then come back on. I think the BLM memory issue has something to do with it. That doesn't occurr on the 29C256 single burn versions. Only the stacked ones did it.
Not even trying to figure that out, just going to fix things and move on.
Z' be careful with the stack. IIRC there is a check to see if the last addy is zero for stack overflow error checking. Need to confirm that though.
(yes, AUJP is the base I'm working from)
Mainly worked from the variable list in the memory section to locate unused memory.
Did I mention I hate indexed addressing!
The bit is being cleared and then reset to display in my routine so it should still be set each time it is run but that is not the case.
I could just be compromising the whole thing by the locations I used.
Actually suprised that I haven't had more problems because of using the BLM area.
I stopped doing stacked bins until I could find out why evry 20-30 seconds the fuel would just shut off and then come back on. I think the BLM memory issue has something to do with it. That doesn't occurr on the 29C256 single burn versions. Only the stacked ones did it.
Not even trying to figure that out, just going to fix things and move on.
Z' be careful with the stack. IIRC there is a check to see if the last addy is zero for stack overflow error checking. Need to confirm that though.
(yes, AUJP is the base I'm working from)
Mainly worked from the variable list in the memory section to locate unused memory.
Did I mention I hate indexed addressing!
stacked bins having problems? One thing to watch for is that the segment table is jumped to using indexing. So the addresses are hard coded and when you add in new code it changes the addresses and the segment jump table is all messed up.
Did you use labels for the jump table (remove the hard coded addresses)?
You can actually have this messed up and the ECM seems to be working fine.
Using the stack memory is fine if you modify the code for a shorter stack. It is a trade-off though because I tend to use the stack a lot with new routines. I try to limit the use so that it doesn' t get to deep.
You can't really just use the memory that isn't used directly. Indexing is a good way of doing things. It just needs to be documented.
** I am surprised you are not trying to use memory locations like 0x00A7, 0x00AA, etc. These values are not really used by the ECM, but are messed with because of some of the functions that are called. For example, 0x00A6 is the MAP_ACCEL value and is a single byte. The problem is that when it is filtered, the routine messes with the 0x00A7 value. So if you tried to use 0x00A7 it would get corrupted even though it doesn't appear to be used in the stock code.
Cool. I have been using the AUJP also. I added a sub-mask, and revision words to keep things straight.
06-26-2006, 06:24 PM
#33
Supreme Member
Thread Starter
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
Originally Posted by junkcltr
Did you use labels for the jump table (remove the hard coded addresses)?
Cool. I have been using the AUJP also. I added a sub-mask, and revision words to keep things straight.
Cool. I have been using the AUJP also. I added a sub-mask, and revision words to keep things straight.
"Sub-mask"???
I see what you mean by finding those "odd" values that aren't needed and using the space. Several cal tables could be changed to a hardcoded value since they are all set to the same value. Would free up some time as well by not doing the lookups. Was going to get to that later when I reach "emmisions removal state". That may come earlier so I can use the variables.
Spent some time today going over the indexed values.
Searching on ",x" shows marks them all instantly (at least the X register indexed ones).
That IAC routine will take a bit of time (longer than my lunch hour anyway)
I thought you were knee deep in $58 ?
06-26-2006, 06:38 PM
#34
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Yep, labels used.
"Sub-mask"???
I see what you mean by finding those "odd" values that aren't needed and using the space. Several cal tables could be changed to a hardcoded value since they are all set to the same value. Would free up some time as well by not doing the lookups. Was going to get to that later when I reach "emmisions removal state". That may come earlier so I can use the variables.
Spent some time today going over the indexed values.
Searching on ",x" shows marks them all instantly (at least the X register indexed ones).
That IAC routine will take a bit of time (longer than my lunch hour anyway)
I thought you were knee deep in $58 ?
"Sub-mask"???
I see what you mean by finding those "odd" values that aren't needed and using the space. Several cal tables could be changed to a hardcoded value since they are all set to the same value. Would free up some time as well by not doing the lookups. Was going to get to that later when I reach "emmisions removal state". That may come earlier so I can use the variables.
Spent some time today going over the indexed values.
Searching on ",x" shows marks them all instantly (at least the X register indexed ones).
That IAC routine will take a bit of time (longer than my lunch hour anyway)
I thought you were knee deep in $58 ?
Yes the "odd" values are essentially wasted. I am going to look at the LAG Filter and multiply routines to see if a push to the stack for the "odd" (the LSByte) value and a pull afterwards. The Fxn only uses the "odd" area for scratch memory. If this was changed then a bunch of RAM would be available.
Emissions removal? I wouldn't remove anything. I have added a bunch of code and some tables and I still have over 3K bytes of the stock 32K area left open.
I was knee deep in the $58....wrote a bunch of new stuff for it and I am still running it in the car. I did some $58 fuel mode testing a few weekends ago and the results were "it sucks". I have been working the AUJP since then adding code and commenting. The flow of the $8D is so much better. Easier to read and follow.
I will continue to run the modified $58 and try the $8D when I think it is ready. Just benching the $8D right now and finding the "quirks" it had from the factory.
06-26-2006, 11:57 PM
#35
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
It turns out that the 0x00A7 value or any other LAG filtered value LSByte can not be used. The LAG filter does filter the entire 16bit value. It messes the filter value if you try to use the LSByte.
06-27-2006, 01:55 PM
#36
Supreme Member
iTrader: (2)
Join Date: Jul 2003
Location: Dallas, TX area
Posts: 3,205
Likes: 0
Received 0 Likes
on
0 Posts
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"
It sounds like you guys have gone way over what this old phat phart's pea brain can comprehend!
I was just going to suggest that the 3 of you I know are working on new $8D code (JP, SL, and junkcltr) all get together and unify what you're all doing for the S_AUJP v4 Scott has been working on (and I've been testing on the road for him). Plus get the blasted KL to work, John (nudge - nudge - LOL)
AND - Maybe have the capability to data log a second WB as well?
Sorry - just running off the mouth, Back to you regularly scheduled guru chat...
I was just going to suggest that the 3 of you I know are working on new $8D code (JP, SL, and junkcltr) all get together and unify what you're all doing for the S_AUJP v4 Scott has been working on (and I've been testing on the road for him). Plus get the blasted KL to work, John (nudge - nudge - LOL)
AND - Maybe have the capability to data log a second WB as well?
Sorry - just running off the mouth, Back to you regularly scheduled guru chat...
06-27-2006, 02:23 PM
#37
Senior Member
Join Date: Mar 2000
Location: Red Bud, Illinois
Posts: 669
Likes: 0
Received 0 Likes
on
0 Posts
Car: 1989 IROC-Z
Engine: 383
Transmission: Pro-Built 700R4 2400 ACT Stall
Axle/Gears: 2.77 Borg Warner 9-Bolt
I agree vern, the knock light would be kinda nice.... I was looking forward to that and scott told me it didn't work. I've always wondered how hard it would be to incorporate actual WB closed loop. I remember a post from a while back but i don't know whatever became of it...
Off i go, guess i kinda hijacked the thread a little. heh. sorry.
I've always wondered how hard it would be to incorporate actual WB closed loop. I remember a post from a while back but i don't know whatever became of it... Off i go, guess i kinda hijacked the thread a little. heh. sorry.
Last edited by branz28; 06-27-2006 at 02:29 PM.
06-27-2006, 05:05 PM
#38
Supreme Member
Thread Starter
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
Beat ya to it Vern.
Was going to send a file over to J tonight and have him test that F5.
His bench is setup and can be used. (Really need to build one too)
I just need to assemble a stock file with "Just" the knock light so there won't be any issues with the adders I've put in.
I'm confident the code works because I've run it through my simulator dozens of times.
The memory addresses and that dual quad output are the issue.
The address I used could be the reason the light blinks. Same issue I see with the PE bit display.
Don't worry about going off track here, Its gone that way buy itself but allot of good info is coming from it.
Ps, I'm already reading the STD NB for control, sim NB for data along with the WB for data so reading two shouldn't be too far way either. (now if I can get them to cooperate with the rest of it...)
----------
Also need to watch for other 16 bit math used with an 8 bit value too.
Was going to send a file over to J tonight and have him test that F5.
His bench is setup and can be used. (Really need to build one too)
I just need to assemble a stock file with "Just" the knock light so there won't be any issues with the adders I've put in.
I'm confident the code works because I've run it through my simulator dozens of times.
The memory addresses and that dual quad output are the issue.
The address I used could be the reason the light blinks. Same issue I see with the PE bit display.
Don't worry about going off track here, Its gone that way buy itself but allot of good info is coming from it.
Ps, I'm already reading the STD NB for control, sim NB for data along with the WB for data so reading two shouldn't be too far way either. (now if I can get them to cooperate with the rest of it...)
----------
Originally Posted by junkcltr
It turns out that the 0x00A7 value or any other LAG filtered value LSByte can not be used. The LAG filter does filter the entire 16bit value. It messes the filter value if you try to use the LSByte.
Last edited by JP86SS; 06-27-2006 at 05:24 PM. Reason: Automerged Doublepost
06-27-2006, 10:02 PM
#39
Supreme Member
Thread Starter
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
OK, test bin is out there
Moved bit display to 0034 along with KL control bits, KL timer to 35.
Lets see how that works.
If this pans out, will be able to prove the functionality of both routines then go back to find open areas in memory to place them along so it can co-exist with WB patches and other adders.
Removed all other patches and non "S v2" code to not obstruct the testing.
Lets see how that works.
If this pans out, will be able to prove the functionality of both routines then go back to find open areas in memory to place them along so it can co-exist with WB patches and other adders.
Removed all other patches and non "S v2" code to not obstruct the testing.
06-28-2006, 12:18 AM
#40
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
I just got the file. I will spin it up tomorrow and see if it works. I think I tested the 0x3FCC PWM with the $58 code. I will check my comments to see what the bit settings are.
I will first try the "failed" mode because it does the least amount of code by changing the bits at 0x898E. I will go from there.
You said the file is an SAUJP version ??. Is there source for it? If there is I will look through it so that I can keep other functions in mind when I use up RAM and code/cal space for the stuff I am working on. I try to minimize the amount of RAM I have been using so that later I might be able to squeeze it into a stock ECM.
Also, if your bin doesn't work. I can change the mem location to my NVRAM locations as a means of debugging. The only way to do that is with source code though. It looks like we use the same assembler. I wouldn't have to modify anything unless it doesn't work. I will see how it goes tomorrow night and go from there.
That is quite a bit of code to test all at once. I usually do it in baby steps and add in temp variables to send stuff out to the ALDL port to see where I am at.
I will first try the "failed" mode because it does the least amount of code by changing the bits at 0x898E. I will go from there.
You said the file is an SAUJP version ??. Is there source for it? If there is I will look through it so that I can keep other functions in mind when I use up RAM and code/cal space for the stuff I am working on. I try to minimize the amount of RAM I have been using so that later I might be able to squeeze it into a stock ECM.
Also, if your bin doesn't work. I can change the mem location to my NVRAM locations as a means of debugging. The only way to do that is with source code though. It looks like we use the same assembler. I wouldn't have to modify anything unless it doesn't work. I will see how it goes tomorrow night and go from there.
That is quite a bit of code to test all at once. I usually do it in baby steps and add in temp variables to send stuff out to the ALDL port to see where I am at.
06-28-2006, 06:45 AM
#41
Supreme Member
Thread Starter
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
Originally Posted by junkcltr
You said the file is an SAUJP version ??. Is there source for it?
Yes!
There is not as much to test as it may appear.
Variables are not many:
1.) Timer value for setting the decrement interval
2.) Decrement value amount.
The config is already set to check for failed sensor and then run the KL code.
The code "was" simulated and worked fine, just the addresses of open memory not good.
Biggest issue (if I didn't booger it up) was that and the PWM output.
Just seemed to flash like the PE bit was doing in the bit status routine.
By adding all of the changes to the new addys, things should be better.
06-28-2006, 10:42 AM
#42
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Biggest issue (if I didn't booger it up) was that and the PWM output.
Just seemed to flash like the PE bit was doing in the bit status routine.
By adding all of the changes to the new addys, things should be better.
Where is the source available?
I sent you something. Read the comments. You have some place where bugs could occur and it has something to do with the PWM regs. The comments show where things could be removed and what could go wrong.
Yeah, after looking at it there wasn't that much functionality, but there is a lot of branching and that is what confused me. A lot of it could be removed.
Looks good though. I will try it later today.
06-28-2006, 12:06 PM
#43
Supreme Member
Thread Starter
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
Originally Posted by junkcltr
Where is the source available?
Haven't brought it to the surface until now.
Have one made with $2000 for the NVRAM already tested by Ernst and ready to go as well. (havn't been sitting on my thumbs all this time
)These have been the base files we are using to implement several new features leading up to the S_AUJP v4 (or what ever it ends up being called)
For those watching, Its not a dead project
, just takes time.
06-28-2006, 10:35 PM
#44
Tim said it was ok for us to continue with the S_aujp line.
When I did some testing on the bench with some closer to stock code for F5.
The bits flipped like we've been saying, but the Reg never seemed to actually
get the DFFF stored in it for some reason. I used most all of the stock F5 setting code I think. Just changed the qual bit to 0053 or 0056. I forget which.
I used an rpm qual instead of the KS for testing of the reg control.
And stuck the bits in the aldl. You could see the bits flip 1 & 0 continuously
in the aldl even though the rpm was always above the setpoint.
I thought it was an aldl display issue with the TP 4.13.
I was out of time so sent that version out for beta testing w/o a functional KL code. I still want to do a N20 control code. But not till this is resolved.
When I did some testing on the bench with some closer to stock code for F5.
The bits flipped like we've been saying, but the Reg never seemed to actually
get the DFFF stored in it for some reason. I used most all of the stock F5 setting code I think. Just changed the qual bit to 0053 or 0056. I forget which.
I used an rpm qual instead of the KS for testing of the reg control.
And stuck the bits in the aldl. You could see the bits flip 1 & 0 continuously
in the aldl even though the rpm was always above the setpoint.
I thought it was an aldl display issue with the TP 4.13.
I was out of time so sent that version out for beta testing w/o a functional KL code. I still want to do a N20 control code. But not till this is resolved.
06-29-2006, 08:42 AM
#45
Supreme Member
iTrader: (2)
Join Date: Jul 2003
Location: Dallas, TX area
Posts: 3,205
Likes: 0
Received 0 Likes
on
0 Posts
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"
Ooooooo - N2O control - like activation within a configurable RPM window? And maybe spark retard amounts when activated? Now that would be really nice!!! Save me from buying an RPM switch....
06-29-2006, 09:04 AM
#46
Member
iTrader: (1)
Join Date: Jan 2004
Location: Ventura, Ca
Posts: 319
Likes: 0
Received 0 Likes
on
0 Posts
Car: 69 Camaro
Engine: LS1 converted to LS6
Transmission: 4L70
Axle/Gears: 12bolt 3:42
Guys let me know if you want me to do some testing for you. I have been busy with my new toy as of late. I am ready to start getting back into getting my tune right...
06-29-2006, 10:48 AM
#47
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by Z69
Tim said it was ok for us to continue with the S_aujp line.
When I did some testing on the bench with some closer to stock code for F5.
The bits flipped like we've been saying, but the Reg never seemed to actually
get the DFFF stored in it for some reason. I used most all of the stock F5 setting code I think. Just changed the qual bit to 0053 or 0056. I forget which.
I used an rpm qual instead of the KS for testing of the reg control.
And stuck the bits in the aldl. You could see the bits flip 1 & 0 continuously
in the aldl even though the rpm was always above the setpoint.
I thought it was an aldl display issue with the TP 4.13.
I was out of time so sent that version out for beta testing w/o a functional KL code. I still want to do a N20 control code. But not till this is resolved.
When I did some testing on the bench with some closer to stock code for F5.
The bits flipped like we've been saying, but the Reg never seemed to actually
get the DFFF stored in it for some reason. I used most all of the stock F5 setting code I think. Just changed the qual bit to 0053 or 0056. I forget which.
I used an rpm qual instead of the KS for testing of the reg control.
And stuck the bits in the aldl. You could see the bits flip 1 & 0 continuously
in the aldl even though the rpm was always above the setpoint.
I thought it was an aldl display issue with the TP 4.13.
I was out of time so sent that version out for beta testing w/o a functional KL code. I still want to do a N20 control code. But not till this is resolved.
*This is huge* because I have not seen any documentation come with a patch saying it is uses CODE SPACE X to Y and RAM SPACE/VARIABLES, A,B,C. Ya just get a "patch"....and some of them are a mess to begin with.
Anyway, I am kind of doing my own thing with the AUJP......read hard-headed. Besides, that way I don't have to have people complain to me about posting that their code doesn't work properly. I think TRAXION, JPSS, and Z69 have done some tremendous work on the AUJP and it is great to see them keep chipping away at it. I would love to bench test and help with code stuff where ever I can....BUT if anyone starts to claim "ownership" of the BIN.....I will be out of it without a blink of an eye. Claiming ownership kills creativity and shows that the learning cycle is dead for the "owner".
Ranting complete, now on to real stuff. I tested the knock LED code last night. I had some problems with the bin JPSS sent. It would not light the LED. So, I did a cut & paste of his code into my working source code.
I did some debugging this way. I still couldn't get the code to operate properly. Tonight will be more debugging on that code.
I also read what the code was trying to do and wrote a new knock sensor LED routine that will trigger the knock light when knock is present or a knock sensor failure occurs (the behaviour that JPSS was doing). It doesn't use any RAM. I really don't see the need to used RAM (hint, the PWM reg is RAM itself). I tested the code and it works properly, but I would like to make a few tweaks for the lighting of the LED (keep it on longer).
THE BIG QUESTION for the knock LED/LIGHT behaviour (for the end users):
How do you want it to work?
Choice 1: (how the JPSS code operates)
Flag in the CAL area to enable the knock light code
Flag in the CAL area to enable the knock light to be on when a knock sensor failure occurs. If the flag is not set, then the light will not come on for a knock sensor failure.
Light/blink knock sensor LED/Bulb when engine knock occurs if knock code enabled
Choice 2:
Flag in the CAL area to enable the knock light code
Light/blink knock sensor LED/Bulb when engine knock occurs OR knock sensor failure if knock code enabled
JPSS stuff was written to do Choice 1. I prefer Choice 2. What does everyone else want??? Keep in mind knock occurs for short time frames mostly, so if the user wanted a blinking LED for engine knock then a blinking LED will appear to be just on (and not blinking).
Anyway, more testing on JPSS code tonight and try to clean up the knock sensor LED/Bulb routine I wrote. I will send it to JPSS when it is finished.
One other thing.....and that is the use of pin F5. The code I am working on uses that for something else. The PWM regs are very valuable (think soleniod control...as in water injection, N2O controller-real PWM, wastegate controller). My personal choice would be to use one of the regular binary outputs that are buffered by a O/C driver and keep Pin F5 for better things.
Anyway, that is what I am doing. It is something to think about for what you are doing with the S_AUJP.
I think JPSS and Z69 do some great work. The thing that keeps the S_AUJP alive is their dedication and most importantly to listen to others and not think they know it all.....like some others around here tend to do. We all learn together.
06-29-2006, 11:07 AM
#48
Supreme Member
iTrader: (1)
Join Date: Jan 2002
Location: garage
Posts: 4,432
Likes: 0
Received 1 Like
on
1 Post
Engine: 3xx ci tubo
Transmission: 4L60E & 4L80E
Originally Posted by JP86SS
Have one made with $2000 for the NVRAM already tested by Ernst and ready to go as well.
If you want to see some debug info for your code. I reserve memory addresses 0x2000-0x2000F for debug info when I code my stuff. I then assign ALDL data byte 17 as 0x2000, data byte 18 as 0x2001, data byte 19 as 0x2002, and data byte 20 as 0x2003.
So, use 0x2004 for the TIMER value and 0x2005 as the CURRENT_STATE value (previous knock stuff).
I can run it and report the debug info to you. Side note, writing a value of 0xDFFF to 0x3FCC turns the LED full on. Writing a value of 0xD000 to ox3FCC turns the LED full off. Watch out for the CARS write to 0x3FCC...it can make the LED do different stuff. Also, the stock knock failure bit and engine knock are set as expected in the stock code.
06-29-2006, 11:28 AM
#49
Supreme Member
Thread Starter
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
Originally Posted by junkcltr
I have to be honest here. I am not a big fan of using someone elses code as a base. For the stuff I am working on I started with a completely stock AUJP
with all of the mods to the calibration from the S_AUJP.
Very few hard code changes but there are a few and do not interact with many std functions.
They are ALL commented and located easily (even the table entries)
Originally Posted by junkcltr
....BUT if anyone starts to claim "ownership" of the BIN.....I will be out of it without a blink of an eye. Claiming ownership kills creativity and shows that the learning cycle is dead for the "owner".
... We all learn together.
... We all learn together.
, Ownership was not my motivation. Many have contributed to get it this far. Am just a bit leary on the someone screwing this up by being the new "chip provider" on e-bay with the code.Will be too easy if the source is out there. Not poking at anybody that does sell there, but you know what I mean.
Bins are one thing, someone who works it out and does the legwork will get the information they need. Source has its own issues when code from many different people is involved. Not sure how to handle that myself. (not really wanting to be the arbitrator on it either)
I can just see the problem coming in the future.
Back on track...
The PWM was used for the variable intensity of the LED.
A simple light will suffice to just make a "Knock Light"
I was being creative by allowing variable intensity and duration for each knock count that was registered.
This gives you a better indication of "constant" knock Vs a couple quick counts on a gear shift or something.
It was just my take on doing it, there are simpler ways.
Glad to hear that "F5" can work. Anything in particulat that I didn't do when commanding it to turn on/off ?
Scott and I have been coordinating on mem usage for the very reason you mentioned. I think we both feel that I/O is so interchangable that if we wanted to move something later it would not be too difficult to do.
coordination is needed so all the ideas can be used together if desired.
----------
Originally Posted by junkcltr
Watch out for the CARS write to 0x3FCC...it can make the LED do different stuff.
It was the write to the CARS light.
Only change needed in the stock code that write to that output.
Last edited by JP86SS; 06-29-2006 at 11:31 AM. Reason: Automerged Doublepost
06-29-2006, 11:32 AM
#50
Supreme Member
iTrader: (2)
Join Date: Jul 2003
Location: Dallas, TX area
Posts: 3,205
Likes: 0
Received 0 Likes
on
0 Posts
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"
Originally Posted by junkcltr
I also read what the code was trying to do and wrote a new knock sensor LED routine that will trigger the knock light when knock is present or a knock sensor failure occurs (the behaviour that JPSS was doing). It doesn't use any RAM. I really don't see the need to used RAM (hint, the PWM reg is RAM itself). I tested the code and it works properly, but I would like to make a few tweaks for the lighting of the LED (keep it on longer).
THE BIG QUESTION for the knock LED/LIGHT behaviour (for the end users):
How do you want it to work?
Choice 1: (how the JPSS code operates)
Flag in the CAL area to enable the knock light code
Flag in the CAL area to enable the knock light to be on when a knock sensor failure occurs. If the flag is not set, then the light will not come on for a knock sensor failure.
Light/blink knock sensor LED/Bulb when engine knock occurs if knock code enabled
Choice 2:
Flag in the CAL area to enable the knock light code
Light/blink knock sensor LED/Bulb when engine knock occurs OR knock sensor failure if knock code enabled
THE BIG QUESTION for the knock LED/LIGHT behaviour (for the end users):
How do you want it to work?
Choice 1: (how the JPSS code operates)
Flag in the CAL area to enable the knock light code
Flag in the CAL area to enable the knock light to be on when a knock sensor failure occurs. If the flag is not set, then the light will not come on for a knock sensor failure.
Light/blink knock sensor LED/Bulb when engine knock occurs if knock code enabled
Choice 2:
Flag in the CAL area to enable the knock light code
Light/blink knock sensor LED/Bulb when engine knock occurs OR knock sensor failure if knock code enabled
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?
Thanks for your help on this! And I agree, JP and Scott have been doing a fantastic job with the S_AUJP v4 effort!!! I've been Scott's primary field tester for several months on the code (since he incorporated the manual tranny stuff, and during some of the WB set up as well).
- Vern