Anyone here max'd out their RPM capability?
04-18-2006, 12:39 PM
#1
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Anyone here max'd out their RPM capability?
?
I believe the 8D uses the same RPM/25 scalar that all the other code uses. The problem is that it's stored in a single byte, so your maximum value of 255 is about 6375 rpm.
Does anyone have a fix for this apparent code limitation?
I was thinking of rewriting the RPM/25 function to make it rpm/35. This would probably goof up all the tables, so new axes would have to be written in the binary definition (I assume).
Has it been done before?
I believe the 8D uses the same RPM/25 scalar that all the other code uses. The problem is that it's stored in a single byte, so your maximum value of 255 is about 6375 rpm.
Does anyone have a fix for this apparent code limitation?
I was thinking of rewriting the RPM/25 function to make it rpm/35. This would probably goof up all the tables, so new axes would have to be written in the binary definition (I assume).
Has it been done before?
04-18-2006, 01:11 PM
#2
TGO Supporter
Join Date: Aug 2001
Location: NJ/PA
Posts: 1,008
Likes: 0
Received 0 Likes
on
0 Posts
Car: Yes
Engine: Many
Transmission: Quite a few
hey, i saw your messages at the gm-ecm page, sounds like a neat project, I'd like to get some more info regarding the DIS, if you don't mind. PM me if you get a chance. My main questions involve the signed min and max spark advance limits you are using.
as for your question about the RPM limit, I beleive that Rbob has some information about the maximium rpm, and I believe there exists a patch to modify exactly what you are asking, modifying the divide constant to get better range (worse resolution, however).
try searching for rbob, and rpm limit. maybe this post:
https://www.thirdgen.org/forums/diy-...ight=rpm+limit
I'll take a look as well.
as for your question about the RPM limit, I beleive that Rbob has some information about the maximium rpm, and I believe there exists a patch to modify exactly what you are asking, modifying the divide constant to get better range (worse resolution, however).
try searching for rbob, and rpm limit. maybe this post:
https://www.thirdgen.org/forums/diy-...ight=rpm+limit
I'll take a look as well.
04-18-2006, 06:21 PM
#3
Supreme Member
Join Date: Jun 2000
Location: In reality
Posts: 7,554
Likes: 0
Received 1 Like
on
1 Post
Car: An Ol Buick
Engine: Vsick
Transmission: Janis Tranny Yank Converter
Originally Posted by ryan.h
I believe the 8D uses the same RPM/25 scalar that all the other code uses. The problem is that it's stored in a single byte, so your maximum value of 255 is about 6375 rpm.
Does anyone have a fix for this apparent code limitation?
Does anyone have a fix for this apparent code limitation?
04-18-2006, 06:42 PM
#4
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Grumpy
Just because the scanners can't read over the 6375 doesn't mean the ecm isn't working just fine. A scope and ecm bench would be one way to answer for yourself what the answer is.
If I can kill 8 birds with one stone...
I found a thread:
https://www.thirdgen.org/forums/diy-...m-25-calc.html
It's greek to me though, I guess I don't understand this part:
Code:
LDD #0307 ;val= 15 * (512/25) or 153.6 * 2 FDIV ;calc RPM/25 w/256th's in LSB by ;division with remainder in LSB ;result is X=D/X
04-18-2006, 07:24 PM
#5
GM has already done it with the Lotus bin.
They added a 3rd rpm calc to the code.
Don't recall where I found the Lotus hac at.
That FDIV makes it easy to find in the hac.
Just add the tables scaled as needed and re address the code to use them.
Much less work. Patch your bin or start with the aujp relocatable hac.
S_AUJP_V4 has a bit selectable 8k rpm PE table.
But with working 6 days a week and getting ready to move.
I've had no time to get V4 tested on an A4 car. I added some MT code and need to ensure that the AT IAC code is still ok. It was easier for me to test it than figure out why GM added it to the MT bins.
I have 2 guys with enough motor to test 8k ve bins. They're just waiting on me.
They added a 3rd rpm calc to the code.
Don't recall where I found the Lotus hac at.
That FDIV makes it easy to find in the hac.
Just add the tables scaled as needed and re address the code to use them.
Much less work. Patch your bin or start with the aujp relocatable hac.
S_AUJP_V4 has a bit selectable 8k rpm PE table.
But with working 6 days a week and getting ready to move.
I've had no time to get V4 tested on an A4 car. I added some MT code and need to ensure that the AT IAC code is still ok. It was easier for me to test it than figure out why GM added it to the MT bins.
I have 2 guys with enough motor to test 8k ve bins. They're just waiting on me.
04-18-2006, 07:55 PM
#6
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Z69
GM has already done it with the Lotus bin.
They added a 3rd rpm calc to the code.
Don't recall where I found the Lotus hac at.
That FDIV makes it easy to find in the hac.
Just add the tables scaled as needed and re address the code to use them.
Much less work. Patch your bin or start with the aujp relocatable hac.
S_AUJP_V4 has a bit selectable 8k rpm PE table.
But with working 6 days a week and getting ready to move.
I've had no time to get V4 tested on an A4 car. I added some MT code and need to ensure that the AT IAC code is still ok. It was easier for me to test it than figure out why GM added it to the MT bins.
I have 2 guys with enough motor to test 8k ve bins. They're just waiting on me.
They added a 3rd rpm calc to the code.
Don't recall where I found the Lotus hac at.
That FDIV makes it easy to find in the hac.
Just add the tables scaled as needed and re address the code to use them.
Much less work. Patch your bin or start with the aujp relocatable hac.
S_AUJP_V4 has a bit selectable 8k rpm PE table.
But with working 6 days a week and getting ready to move.
I've had no time to get V4 tested on an A4 car. I added some MT code and need to ensure that the AT IAC code is still ok. It was easier for me to test it than figure out why GM added it to the MT bins.
I have 2 guys with enough motor to test 8k ve bins. They're just waiting on me.
Is this what you did with the S_aujp_v4?
Now to me, it seems like it would be less work to change one divider over creating new tables and figuring out how to add them into the old fuel routines. But then I don't understand the consequences of changing the RPM/25 scalar to RPM/35 (for example)
04-18-2006, 08:06 PM
#7
Do a search in the hac on the ram location used for RPM/25.
....
That is how many things you will have to verify/fix when you change the scale. Not to mention, GM didn't do it that way......
8D has plenty of room for more tables w/o re doing old ones.
When you redo old ones, you have to fix the xdf and add place holders to keep things farther down lined up. Lots of work. Been covered in several posts I was part of.
V4 has lots of added stuff.
If your working with a c3, your stuck.... Just have to go with an EBL setup.
But the 165 & 730 compatible bins have lots of room for stuff.
....
That is how many things you will have to verify/fix when you change the scale. Not to mention, GM didn't do it that way......
8D has plenty of room for more tables w/o re doing old ones.
When you redo old ones, you have to fix the xdf and add place holders to keep things farther down lined up. Lots of work. Been covered in several posts I was part of.
V4 has lots of added stuff.
If your working with a c3, your stuck.... Just have to go with an EBL setup.
But the 165 & 730 compatible bins have lots of room for stuff.
Trending Topics
04-18-2006, 08:42 PM
#8
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
where can I find the V4 to look at? (I don't care if it works or not because I'm using the $a1 codemask)
btw, I assume going with the new extended rpm tables, I would have to create some new engine speed value in RAM, like RPM/40 to use with the tables...
btw, I assume going with the new extended rpm tables, I would have to create some new engine speed value in RAM, like RPM/40 to use with the tables...
Last edited by ryan.h; 04-18-2006 at 08:50 PM.
04-19-2006, 05:15 PM
#9
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Can someone 'splain to me how the RPM/25 gets calculated?
I read the thread above multiple times, but it's not sinking in. As I understand it, 15.26usec pulses are counted between firings, and stored in a timer called the DRP.
For a V8, the RPM can be calculated by dividing 983040 by the counts. In otherwords, there are 164 counts between firings on a v8 running 6000rpm. How in the world do you take the number 307 divided by the (DRP counts times 2) to equal RPM/25???
I read the thread above multiple times, but it's not sinking in. As I understand it, 15.26usec pulses are counted between firings, and stored in a timer called the DRP.
For a V8, the RPM can be calculated by dividing 983040 by the counts. In otherwords, there are 164 counts between firings on a v8 running 6000rpm. How in the world do you take the number 307 divided by the (DRP counts times 2) to equal RPM/25???
04-19-2006, 07:43 PM
#10
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Its not actualy the calculated value that uses that.
That is to obtain a representation OF the RPM in a 8 bit format (256 steps)
the std output is 6400/25 = 256 steps = 25 rpm per bit
so the output can be used as the scale factor for tables.
* Can't do this *****
If you wanted to see up to 9000 rpm you could do
10,000 / 256 = 39.0625 = 256 rpm per bit.
your resolution would be crappy but you would see the number you want.
Its just a resolution game.
* can't do this*****
The base value is still only calculated to 6400
That is to obtain a representation OF the RPM in a 8 bit format (256 steps)
the std output is 6400/25 = 256 steps = 25 rpm per bit
so the output can be used as the scale factor for tables.
* Can't do this *****
If you wanted to see up to 9000 rpm you could do
10,000 / 256 = 39.0625 = 256 rpm per bit.
your resolution would be crappy but you would see the number you want.
Its just a resolution game.
* can't do this*****
The base value is still only calculated to 6400
Last edited by JP86SS; 04-20-2006 at 12:03 PM. Reason: Automerged Doublepost
04-19-2006, 08:12 PM
#11
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
yes but it's calculated by the below formula.
The bold part is how rpm/25 gets calculated. I don't understand how the number 307 comes in. As I understand it, the DRP counts x 2 gets divided into 307. How does that work?
If RPM = 983040/DRP counts, then:
RPM/25 = 39321.6/DRP counts
right? How do you go from 39,321.6 to 307? That's my question.
Code:
LDD L00B3 ; get DRP period from FDB L00B3 ASLD ;mult by 2 PSHB PSHA ;move D to the stack Pulx ;put val on stack in x or move D to x LDD #307 ; put 307d in D which is scale to 25 rpm per bit Fdiv ; divide 307 by (DRP * 2) with result in X PSHX ; put RPM/25 on stack Pula Pulb ; move x to d ;limit to 6375 STAA L0058 ; and store at L0058
If RPM = 983040/DRP counts, then:
RPM/25 = 39321.6/DRP counts
right? How do you go from 39,321.6 to 307? That's my question.
04-19-2006, 08:23 PM
#12
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Hmmm.... ... ...My brain hurts when you do stuff like that
04-19-2006, 10:53 PM
#13
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
Hmmm.... ... ...My brain hurts when you do stuff like that
I guess as a second question, how would you go about creating an "offset" RPM value? I figured using the original lookup routines, that the 16 step interpolation would create 600rpm steps in my table with the rpm/35 arguement, (which isn't ideal) so... How would I create an RPM variable that starts at 6400, with rpm/25 as the resolution?
04-20-2006, 11:46 AM
#14
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
I see what you are talking about now, edited that last post I did.
As a best guess I am figuring the 512 is the 2 byte representation of the RPM (2 8 bit registers) divided by the scaling desired.
The 15 ?
Maybe the counter requires 15 pulses to confirm the timing of the counts.
As a best guess I am figuring the 512 is the 2 byte representation of the RPM (2 8 bit registers) divided by the scaling desired.
The 15 ?
Maybe the counter requires 15 pulses to confirm the timing of the counts.
04-20-2006, 01:11 PM
#15
Member
Join Date: Jun 2001
Location: Eh?
Posts: 391
Likes: 0
Received 0 Likes
on
0 Posts
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Originally Posted by ryan.h
I don't understand how the number 307 comes in. As I understand it, the DRP counts x 2 gets divided into 307. How does that work?
If RPM = 983040/DRP counts, then:
RPM/25 = 39321.6/DRP counts
right? How do you go from 39,321.6 to 307? That's my question.
If RPM = 983040/DRP counts, then:
RPM/25 = 39321.6/DRP counts
right? How do you go from 39,321.6 to 307? That's my question.
2,097,000Hz is the ECM's E clock frequency, the DRP counter runs at E / 32. 1/65531.25 bits gives you a time value for DRP. I'll let you figure the rest out with those hints.
Last edited by MonteCarSlow; 04-20-2006 at 02:04 PM.
04-20-2006, 06:25 PM
#16
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
ohhkay..... I understand now. For clarification/confirmation...
voila! It's been a long week. 
Now, any ideas on how to create an offset RPM variable that starts at 6400? I'm still unfamiliar with registers and assembly math.
wait... okay, what about spreading the RPM/25 over 2 bytes... and.... subtracting 256? ...and storing that in a single byte? Would that work?
So, the stock routine takes the DRP in the D register, multiplies it by 2, then something happens:
I don't know what that does, but the comments say that it gets transfered to the X register.
Then the number 307 is loaded into D, an FDIV command takes D, divides it by X (307/DRP*2). That gets stored back in X, and other things happen before being put into RAM.
So what if I modified and inserted a new formula, 154/(DRP counts * 2), and... okay I just lost my train of thought.
If all this is done in 16 bit arithmetic... then the 16 bit result should be somewhere... let me look..
Code:
RPM = 983040/(DRP counts).
RPM/25 = 39321.6/(DRP counts)
RPM/25 = 39321.6 * 2 / (DRP counts * 2)
= 78643.2/(DRP counts * 2)
So, resolution, would be:
RPM/25 * (1/256) = 78643.2/(DRP counts * 2) * (1/256)
RPM/25/256 = 307/(DRP counts * 2) Now, any ideas on how to create an offset RPM variable that starts at 6400? I'm still unfamiliar with registers and assembly math.
wait... okay, what about spreading the RPM/25 over 2 bytes... and.... subtracting 256? ...and storing that in a single byte? Would that work?
So, the stock routine takes the DRP in the D register, multiplies it by 2, then something happens:
Code:
pshb psha pulx
Then the number 307 is loaded into D, an FDIV command takes D, divides it by X (307/DRP*2). That gets stored back in X, and other things happen before being put into RAM.
So what if I modified and inserted a new formula, 154/(DRP counts * 2), and... okay I just lost my train of thought.
If all this is done in 16 bit arithmetic... then the 16 bit result should be somewhere... let me look..
Last edited by ryan.h; 04-20-2006 at 06:44 PM.
04-20-2006, 06:52 PM
#17
Junior Member
Join Date: Jul 2002
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
As mentioned earlier, the Lotus Carlton (& ZR-1 Corvette) used a RPM/31.25 variable for extended range.
Here is the calculation from the code:
Todd
Here is the calculation from the code:
Code:
****************************************************** ** COMPUTE NTRPMZ ****************************************************** PULX DUMP Q FROM STACK (Q=(153.6/NEWREFPER*2)*256 PULX FETCH NEWREFPER * 2 FROM STACK LDD #4*15*512/125 NUMERATOR = (4*(15*512))/(31.25*4) FDIV PSHX PULA PULB ADDD #$0080 ROUNDING BCC *+4 LDAA #$00FF STAA NTRPMZ NTRPMZ SCALED 1 BIT = 31.25 RPM
04-20-2006, 07:02 PM
#18
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by tpep
As mentioned earlier, the Lotus Carlton (& ZR-1 Corvette) used a RPM/31.25 variable for extended range.
with an RPM/25 variable, I could have:
6400, 6800, 7200, 7600, 8000, 8400, 8800, 9200...
I would have 2 more cells, which would come in handy big time!
04-20-2006, 10:03 PM
#19
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Code:
FDIV ;calc RPM/25 w/256th's in LSB by ;division with remainder in LSB ;result is X=D/X ;SNIP- bunch of code for hi & lo range Qals and limited rpm stored at L0057 ; not relavent to topic PSHX ;Put value from fdiv in x reg on the stack PULA ;Pull RPM/25 off of stack or PULB ;put X in D (which is actually A&B) PSHB ;put back on stack for later use PSHA ;in RPM/12.5 calc ADDD #128 ;Round off by adding 128 to LSB (B reg)
and IF so, could i take that whole mess in X off the stack, subtract 255 (6375 rpm) from it, and save it into ram as an offset RPM value that starts at 6400?
(and put it back on the stack so nothing gets confused)
Last edited by ryan.h; 04-20-2006 at 10:13 PM.
04-21-2006, 06:30 AM
#20
There's an error in the Fdiv comments I made.
The remainder is in accD.
I suppose an offset might work.
But that is a new path you've chosen to explore. There are pro's & cons to every method.
The factory method works....
You'll note that it's 983040/(DRP*2)
RPM is the measure of the time (# of clock cycles) between DRP's.
So the higher the rpm, the lower the # of cycles. Or the lower the DRP period.
The Fdiv calc is 307/(DRP per*2).
Do a little math on some samples #'s and you'll see how it all works.
You'll also note that GM used RPM/12.5 and RPM/25.
There's a trend there worth exploring.
VE2 doesn't start at 0. How'd they do that?
Notice how the kpa scale changes on the VE table. How'd they do that?
You might want to look at AUJPVE3.zip for some more ideas.
And you'll need to figure out how the 3d l/u works too.
You can spend hrs playing with the table scalings if your picky about clock cycles and byte useage.
More time spent in the hacs and learning asm commands will clear things up. You need to understand what's going on with the pul and psh commands. You have to watch for the regs getting swapped.
S_AUJP_V4 is not available yet. And won't be released as source. Only as a bin.
RPM/25* 1/256= doesn't work
I don't even pretend to understand that 256/512 scale stuff.
I just make the code spit out the answer I want.
The remainder is in accD.
I suppose an offset might work.
But that is a new path you've chosen to explore. There are pro's & cons to every method.
The factory method works....
You'll note that it's 983040/(DRP*2)
RPM is the measure of the time (# of clock cycles) between DRP's.
So the higher the rpm, the lower the # of cycles. Or the lower the DRP period.
The Fdiv calc is 307/(DRP per*2).
Do a little math on some samples #'s and you'll see how it all works.
You'll also note that GM used RPM/12.5 and RPM/25.
There's a trend there worth exploring.
VE2 doesn't start at 0. How'd they do that?
Notice how the kpa scale changes on the VE table. How'd they do that?
You might want to look at AUJPVE3.zip for some more ideas.
And you'll need to figure out how the 3d l/u works too.
You can spend hrs playing with the table scalings if your picky about clock cycles and byte useage.
More time spent in the hacs and learning asm commands will clear things up. You need to understand what's going on with the pul and psh commands. You have to watch for the regs getting swapped.
S_AUJP_V4 is not available yet. And won't be released as source. Only as a bin.
RPM/25* 1/256= doesn't work
I don't even pretend to understand that 256/512 scale stuff.
I just make the code spit out the answer I want.
Last edited by Z69; 04-21-2006 at 06:42 AM.
04-21-2006, 09:04 AM
#22
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Z69
There's an error in the Fdiv comments I made.
The remainder is in accD.
The remainder is in accD.
Thanks for the ideas, I've obviously got a lot of work ahead of me...
I would like it a lot if this post:
https://www.thirdgen.org/forums/diy-...roduction.html
had more of an explanation of how the tables are looked up. For instance, can I have a table with just 3 cells?
----------
Originally Posted by xjcamaro89
Are you going to be turning 6500-8000 RPMs in a 3rd gen?
All I need are new springs and I can rev to 7500 safely on the stock bottom end. new rods would put me at 8500... I wouldn't mind hearing what that sounds like...
Last edited by ryan.h; 04-21-2006 at 09:37 AM. Reason: Automerged Doublepost
04-21-2006, 09:34 AM
#23
Member
Join Date: Jun 2001
Location: Eh?
Posts: 391
Likes: 0
Received 0 Likes
on
0 Posts
Car: 1988 Monte Carlo SS
Engine: 5.7L TPI
Transmission: T5
Axle/Gears: 3.73
Originally Posted by ryan.h
No, I sold my thirdgen a few years back. This is for a northstar v8
04-21-2006, 03:03 PM
#25
There's plenty of info on source code up in the stickies to get you started.
Lots of links to good stuff we found when some of us were starting out a few yrs ago. Might try some searching on screen names too. You can't spoon feed assembly.
You just have to put the time in like the rest of us did.
Lots of links to good stuff we found when some of us were starting out a few yrs ago. Might try some searching on screen names too. You can't spoon feed assembly.
You just have to put the time in like the rest of us did.
Last edited by Z69; 04-21-2006 at 03:06 PM.
04-21-2006, 08:24 PM
#26
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Alrighty, what I've discovered is I can use the 37.5rpm/bit scale and still have a 300rpm cell resolution in the tables.
Basically it involves subtracting 6400 from the RPM/37.5, and multiplying it by 2 (LSL). Then I'd be using a range of 0d to 170d of the 255 full scale... each bit would resolve 18.6rpm. The x16 interpolation scheme would make a 300rpm separation between cells. So, 6400,6700,7000... which works perfect. I can use the 2D lookup with line count to create an 11 line VE extension table, which ends at 9400rpm. I can do the same to a PE extension table.
Basically it involves subtracting 6400 from the RPM/37.5, and multiplying it by 2 (LSL). Then I'd be using a range of 0d to 170d of the 255 full scale... each bit would resolve 18.6rpm. The x16 interpolation scheme would make a 300rpm separation between cells. So, 6400,6700,7000... which works perfect. I can use the 2D lookup with line count to create an 11 line VE extension table, which ends at 9400rpm. I can do the same to a PE extension table.
04-21-2006, 09:54 PM
#27
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Z69
There's an error in the Fdiv comments I made.
The remainder is in accD.
The remainder is in accD.
04-22-2006, 09:45 AM
#29
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
You mean when not in PE? Same way it does it now... Takes the last value off the 3D VE table (4000 rpm, whatever MAP), and adds that to the 2D VE table... which originally only goes to 6400, but will be extended with the PE AFR table.
It would also be nice to extend the 3D VE table to 6400 or so, but one step at a time...
It would also be nice to extend the 3D VE table to 6400 or so, but one step at a time...
04-22-2006, 10:00 AM
#30
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,432
Likes: 0
Received 225 Likes
on
211 Posts
Car: check
Engine: check
Transmission: check
Originally Posted by ryan.h
It would also be nice to extend the 3D VE table to 6400 or so, but one step at a time...
RBob.
04-22-2006, 10:34 AM
#32
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,432
Likes: 0
Received 225 Likes
on
211 Posts
Car: check
Engine: check
Transmission: check
Originally Posted by ryan.h
...for the $8D... what about my $A1? 
j/k... I've got that patch now, and it's probably a simple copy/paste/change addresses kind of deal.
j/k... I've got that patch now, and it's probably a simple copy/paste/change addresses kind of deal.
RBob.
04-22-2006, 10:57 AM
#33
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Well originally it was due to using DIS, but now it's mainly because I have already tuned it. The only difference between 8D and A1 that would be beneficial to me, as I understand it, would be the BLM cell table. That's not too large of a deal to me.
04-22-2006, 01:56 PM
#34
Supreme Member
Join Date: Jul 1999
Location: Baton Rouge, LA, USA
Posts: 1,577
Likes: 0
Received 0 Likes
on
0 Posts
Car: 87 T/A
Engine: 441 SBC 12.5:1 0.680" Lift
Transmission: T-56
Axle/Gears: 4.10 TruTrac Moser 9"
Would it be possible to have some sort of compound function specified? That way you could have good resolution at the lower RPM as well as extended range up top. I did something like that with TPS, and it worked out fine.
Something like if RPM < 3000, you follow a steeper relationship. If RPM >= 3000, you follow a shallower freq -vs- scalar curve. Then you'd end up with the best of both worlds?
Something like if RPM < 3000, you follow a steeper relationship. If RPM >= 3000, you follow a shallower freq -vs- scalar curve. Then you'd end up with the best of both worlds?
04-22-2006, 04:58 PM
#35
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Maybe.. But I'm doing it this way because it's easy. And I like easy.
I spent an hour today trying to figure out why the computer was crashing. The only thing I loaded was the new RPM/37.5 function... Then it hit me like a ton of bricks - CHECKSUM!
So I load up the ALDL link and my freq generator program on the laptop, and see if it works. It doesn't, but it's close. For some reason, the RPM/37.5 shows exactly 1/2 of the RPM/25. I haven't figured out why yet, it's probably something I'm overlooking (don't forget I'm a n00b). If you guys want to browse my code...
This is the stock routine... comments may not be correct, they are my own.
addition at $FDE7 (from my patch):
L00FA was a RAM spot only used once in an EGR routine. Since I shut off the EGR, I changed the EGR routine's storage there into a NOP and a LDAA $10...
Anything glaring? Is it safe to turn that LDD into a JSR?
I spent an hour today trying to figure out why the computer was crashing. The only thing I loaded was the new RPM/37.5 function... Then it hit me like a ton of bricks - CHECKSUM!
So I load up the ALDL link and my freq generator program on the laptop, and see if it works. It doesn't, but it's close. For some reason, the RPM/37.5 shows exactly 1/2 of the RPM/25. I haven't figured out why yet, it's probably something I'm overlooking (don't forget I'm a n00b). If you guys want to browse my code...
This is the stock routine... comments may not be correct, they are my own.
Code:
A6DA ldd L3FC0 ;LOAD DRP PERIOD A6DD std *L0050 ;STORE A6DF ldx #0x0050 ;RELOAD A6E2 ldaa L8009 ;NUMBER OF CYLINDERS A6E5 beq LA6EC ;BRANCH IF = ZERO (V8), ELSE A6E7 jsr LF880 ;8 x 16 multiply A6EA std *L0050 ;STORE REF PERIOD A6EC LA6EC:ldd *L0050 changed to: JSR FDE7 A6EE lsld ;multiply by 2 A6EF pshb ; Push B to stack A6F0 psha ; Push A to stack A6F1 pulx ; Pull X from stack (A&B) A6F2 cli A6F3 ldd #0x0133 ;load 307 into D register A6F6 fdiv ; D/X A6F7 pshx ;Store quotient in X stack A6F8 pula ; Pull MSB from stack A6F9 pulb ; Pull LSB from stack A6FA cmpa #0x60 ;compare to 2400 rpm A6FC bcs LA707 ;branch if less than A6FE addd #0x4080 A701 bcc LA70E A703 ldaa #0xFF A705 bra LA70E A707 LA707:lsld A708 subd #0x1F80 A70B bcc LA70E A70D clra A70E LA70E:staa *L00C5 ;Scaled RPM/25?
Code:
ORG $FDE7 ;location of free EPROM memory LFDE7: LDD $3FC0 ; get DRP period from 3FC0 LSLD ;mult by 2 PSHB PSHA ;move D to the stack PULX ;put val on stack in x or move D to x LDD #205 ; put 205d in D which is scale to 37.5 rpm per bit FDIV ; divide 205 by (DRP * 2) with result in X PSHX ; put RPM/37.5 on stack PULA PULB ; move x to d ADDD #$0080 ;round BCC return ;BRANCH IF OVERFLOW, ELSE: LDAA #$FF return: STAA $00FA ; and store at L00FA LDD $0050 ;Do original LDD L0050 rts ;return to original sub
Anything glaring? Is it safe to turn that LDD into a JSR?
04-22-2006, 06:05 PM
#36
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,432
Likes: 0
Received 225 Likes
on
211 Posts
Car: check
Engine: check
Transmission: check
Need to look at a listing. This should help:
RBob.
Code:
LA6E5: 27 05 BEQ LA6EC ; LA6E7: BD F8 80 JSR LF880 ; LA6EA: DD 50 STD L0050 ; drp ref LA6EC: DC 50 LDD L0050 ; drp ref LA6EE: 05 LSLD ; LA6EF: 37 PSHB ;
04-22-2006, 06:24 PM
#37
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
You need to look at a listing, or I need to look at a listing? :P
http://home.cc.umanitoba.ca/~umfreed...iles2/ARUR.txt
There's one, different binary, same code.
If you're implying that L0050 is the "real" DRP period, it's not... Or at least when I switched from $3FC0 to $0050 it was still showing 1/2 the correct value.
Although, now that I think about it, I wonder if it's not the RPM/37.5 that's reading half, but the RPM/25 that's reading double.... I need to confirm the results by comparing to the original binary... one sec.
Yep, somehow I skewed the RPM/25 to double what it should be. Now how did I do that?
HA! figured it out... JSR takes up 3 bytes instead of the 2 the original LDD did. So it "erased" the ASLD that came right afterwards.
http://home.cc.umanitoba.ca/~umfreed...iles2/ARUR.txt
There's one, different binary, same code.
If you're implying that L0050 is the "real" DRP period, it's not... Or at least when I switched from $3FC0 to $0050 it was still showing 1/2 the correct value.
Although, now that I think about it, I wonder if it's not the RPM/37.5 that's reading half, but the RPM/25 that's reading double.... I need to confirm the results by comparing to the original binary... one sec.
Yep, somehow I skewed the RPM/25 to double what it should be. Now how did I do that?
HA! figured it out... JSR takes up 3 bytes instead of the 2 the original LDD did. So it "erased" the ASLD that came right afterwards.
Last edited by ryan.h; 04-22-2006 at 07:27 PM.
04-22-2006, 07:35 PM
#38
Moderator
iTrader: (1)
Join Date: Mar 2002
Location: Chasing Electrons
Posts: 18,432
Likes: 0
Received 225 Likes
on
211 Posts
Car: check
Engine: check
Transmission: check
Not implying the L0050 is the DRP count. As it is the DRP count normalized to an 8 cylinder engine. The portion of the listing I posted shows the error. Which you have figured out. One item I will mention 1 more time (and no more): I recommend that you change to the $8D code, it is worth it.
RBob.
RBob.
04-22-2006, 08:15 PM
#39
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by RBob
Not implying the L0050 is the DRP count. As it is the DRP count normalized to an 8 cylinder engine. The portion of the listing I posted shows the error. Which you have figured out. One item I will mention 1 more time (and no more): I recommend that you change to the $8D code, it is worth it.
RBob.
RBob.
Curious what specifically is worth changing over to 8D? (besides the BLM table)
04-23-2006, 03:32 AM
#40
Originally Posted by Craig Moates
Would it be possible to have some sort of compound function specified?
It seemed easiest to use all stock to 6000 rpm.
Then use a new rpm scale for 6000 to 8000.
I also added a VE3 to make it easier to tranfer from a stock or VE2 patched bin.
The relocatable 8D hac made this much easier than a patch.
And I'm not the only person working on 8D code either....
04-23-2006, 01:07 PM
#41
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Well, now anytime I enter PE, the desired AFR drops to 0 and the BPW maxes out to 300 mS. To be honest, I'm not entirely sure I'm doing the 2d lookup correctly. From my patch:
The original 2d PE AFR lookup JSR:
now points to this routine:
The original 2d PE AFR lookup JSR:
Code:
LDAA L0062 ;rpm/25 C3F8: CE 8B 13 LDX #$8B13 ;PE AFR table C3FB: BD FE 1C JSR LF751 now-> LFE1C C3FE: 97 E4 STAA L00E4
Code:
newPE: CMPA #$00FF ;compare RPM to 6375 BLS AFRlk ;Branch if less than 6375, else: LDAA $00FA ;load RPM/37.5 SUBA #$00AA ;subtract 6375 from RPM ASLA ;multiply by 2 to gain dynamic range LDX PEAFR ;load extended PE AFR table JSR $F746 ;lookup new PE AFR (line count 2d) BRA home ;done. AFRlk: LDX $8B13 ;load original PE AFR table JSR $F751 ;orig 2d PE AFR lookup home: rts ;------------------------------------------------ ; New PE AFR table: ;AFR = value in decimal/10 ORG $FF27 ;extended base VE PEAFR: FCB #$0A ;number values -1 FCB #110 ;6400 rpm FCB #110 ;6700 rpm FCB #110 ;7000 rpm FCB #110 ;7300 rpm FCB #110 ;7600 rpm FCB #110 ;7900 rpm FCB #110 ;8200 rpm FCB #110 ;8500 rpm FCB #110 ;8800 rpm FCB #110 ;9100 rpm FCB #110 ;9400 rpm
04-23-2006, 01:24 PM
#42
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
Seems to me the lookups should be the same. Only load a different table.
Not really following all of your addresses but it just hit me that way.
Not sure why you have 2 different lookup routines.
Not really following all of your addresses but it just hit me that way.
Not sure why you have 2 different lookup routines.
04-23-2006, 02:01 PM
#44
Supreme Member
iTrader: (1)
Join Date: Apr 2004
Location: Browns Town
Posts: 3,178
Likes: 0
Received 3 Likes
on
3 Posts
Car: 86 Monte SS (730,$8D,G3,AP,4K,S_V4)
Engine: 406 Hyd Roller 236/242
Transmission: 700R4 HomeBrew, 2.4K stall
Axle/Gears: 3:73 Posi, 7.5 Soon to break
I see on the 11 cells.
Could it be the LDAA for the higher rpm value.
Are you subtracting the 6375 from an 8 bit value?
Not sure how to confirm, the opcode for the LDAA is specified correctly
96 (8 bit) and B6 (16 bit) data.
As you know, the docs suck for things like that.
Do you need the # in front of the $00FA ?
Otherwise you are loading a value of 250 (d)
either that or my syntax is killing me today :0
Could it be the LDAA for the higher rpm value.
Are you subtracting the 6375 from an 8 bit value?
Not sure how to confirm, the opcode for the LDAA is specified correctly
96 (8 bit) and B6 (16 bit) data.
As you know, the docs suck for things like that.
Do you need the # in front of the $00FA ?
Otherwise you are loading a value of 250 (d)
either that or my syntax is killing me today :0
Last edited by JP86SS; 04-23-2006 at 02:05 PM.
04-23-2006, 02:45 PM
#45
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by JP86SS
I see on the 11 cells.
Could it be the LDAA for the higher rpm value.
Are you subtracting the 6375 from an 8 bit value?
Not sure how to confirm, the opcode for the LDAA is specified correctly
96 (8 bit) and B6 (16 bit) data.
As you know, the docs suck for things like that.
Do you need the # in front of the $00FA ?
Otherwise you are loading a value of 250 (d)
either that or my syntax is killing me today :0
Could it be the LDAA for the higher rpm value.
Are you subtracting the 6375 from an 8 bit value?
Not sure how to confirm, the opcode for the LDAA is specified correctly
96 (8 bit) and B6 (16 bit) data.
As you know, the docs suck for things like that.
Do you need the # in front of the $00FA ?
Otherwise you are loading a value of 250 (d)
either that or my syntax is killing me today :0
04-23-2006, 10:30 PM
#46
Can't be specific on syntax since I don't know what assembler your using.
That said, $00FA should have something indicating implicit (I forget the term) addressing to use $FA not $00FA in the code. Or does your asm do it automatically? I also see a mix of 0x00 and $00 useage. Does your assembler support that?
Also, I've never tried using a break point that wasn't an integer result when divided by the rpm/xxx scalar.
I haven't messed with the 2D tables much so I'm not familar with the l/u routine difference. But I used the same 2D l/u for both PE tables. Stock & the Extended.
That said, $00FA should have something indicating implicit (I forget the term) addressing to use $FA not $00FA in the code. Or does your asm do it automatically? I also see a mix of 0x00 and $00 useage. Does your assembler support that?
Also, I've never tried using a break point that wasn't an integer result when divided by the rpm/xxx scalar.
I haven't messed with the 2D tables much so I'm not familar with the l/u routine difference. But I used the same 2D l/u for both PE tables. Stock & the Extended.
04-24-2006, 09:47 AM
#47
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
I'm using AS11... I thought that's what everyone uses?
On the $00FA vs $FA, why would they not be the same? Or am I telling the assembler that it's a 16 bit number? (does it matter?) That could be something to investigate...
On the 0x00 vx $00, I have no idea what you're talking about. AS11 won't let me use 0x00 I don't think, if you see anything above that uses that, it's probably from the disassembler.
On the $00FA vs $FA, why would they not be the same? Or am I telling the assembler that it's a 16 bit number? (does it matter?) That could be something to investigate...
On the 0x00 vx $00, I have no idea what you're talking about. AS11 won't let me use 0x00 I don't think, if you see anything above that uses that, it's probably from the disassembler.
04-24-2006, 10:30 AM
#48
Originally Posted by ryan.h
I'm using AS11... I thought that's what everyone uses?
On the $00FA vs $FA, why would they not be the same? Or am I telling the assembler that it's a 16 bit number? (does it matter?) That could be something to investigate...
On the $00FA vs $FA, why would they not be the same? Or am I telling the assembler that it's a 16 bit number? (does it matter?) That could be something to investigate...
Note the differences.
Code:
B83A B7 01 49 ST_RPM: staa L0149 B81C 97 59 LB80B: staa *L0059
Eventually you'll run into a patch that AS11 can't do.
I went to ASHC11 when that happened to me.
There are a few hacs around that use ASHC11.
The "Source code for Dummies" thread up in the stickies has info on what several of us are using for an assembler and why.
These are all free btw.
On the 0x00 vx $00, I have no idea what you're talking about. AS11 won't let me use 0x00 I don't think, if you see anything above that uses that, it's probably from the disassembler.
I went and looked through some of my early patches that used AS11.
That asm does a lot of things automatically for you. You need to read up on this stuff. There can be unintended consequences if the address mode is incorrect. I once loaded the PC into RegX and then used RegX for the address for a LDxx cmd.
I was suprised it worked at all. The aldl output for the eventual Staa looked like a counter.....
I think I found a help file for AS11 on the Freescale site.
04-26-2006, 05:11 PM
#49
Member
Thread Starter
iTrader: (2)
Join Date: Jun 2002
Posts: 248
Likes: 0
Received 0 Likes
on
0 Posts
Well, that's the problem. In comparing the "LDX" command for the table lookup I did, vs the original lookup, they are different in hex.
My instruction:
"LDX data16
Bytes: 3
Cycles: 5
Encoding: FE dataHI dataLO
Operation: X ¬ (data16)"
Original instruction:
"LDX #data16
Bytes: 3
Cycles: 3
Encoding: CE dataHI dataLO
Operation: X ¬ data16"
I was able to change the instruction to the needed version by LDX #$xxxx.... but rather than just fixing it, I'd like to know what I'm doing.
The AS11 help file didn't help at all. But, it appears as though everything is working as expected, although I still have to do some more testing to confirm.
My instruction:
"LDX data16
Bytes: 3
Cycles: 5
Encoding: FE dataHI dataLO
Operation: X ¬ (data16)"
Original instruction:
"LDX #data16
Bytes: 3
Cycles: 3
Encoding: CE dataHI dataLO
Operation: X ¬ data16"
I was able to change the instruction to the needed version by LDX #$xxxx.... but rather than just fixing it, I'd like to know what I'm doing.
The AS11 help file didn't help at all. But, it appears as though everything is working as expected, although I still have to do some more testing to confirm.
04-27-2006, 12:30 PM
#50
See my post above about address mode.
You also need to understand the X reg.
It can be confusing.
You might also try searching.
That & following the links in the source code for dummies thread will get you going nicely. Several of us are only a few years down that exact path.
I think the pink book explains addressing mode in it somewhere.
I have a cheat sheet so I don't recall exactly what I read to figure it out.
And I have several books I read since I didn't understand binary, hex etc when I started. And yes those books did put me asleep frequently.
Usually sooner than later.
You also need to understand the X reg.
It can be confusing.
You might also try searching.
That & following the links in the source code for dummies thread will get you going nicely. Several of us are only a few years down that exact path.
I think the pink book explains addressing mode in it somewhere.
I have a cheat sheet so I don't recall exactly what I read to figure it out.
And I have several books I read since I didn't understand binary, hex etc when I started. And yes those books did put me asleep frequently.
Usually sooner than later.