DIY PROMDo It Yourself PROM chip burning help. No PROM begging. No PROMs for sale. No commercial exchange. Not a referral service.
Welcome to ThirdGen.org!
Welcome to ThirdGen.org.
You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, at no cost, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, join the ThirdGen.org community today!
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).
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).
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?
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.
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.
exactly correct. But in tuning I would need the RPM to be recorded in the datalogs. Secondly, fuel @ 6400rpm will differ from fuel at 7000rpm, 7500rpm, 8000rpm, and 8500rpm....
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.
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.
Hmm... I'm not entirely sure I'd have enough codespace to introduce another VE table, and a PE AFR table. I'd probably have to completely remove the EGR subroutines or something similar.
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)
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.
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???
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
Last edited by JP86SS; 04-20-2006 at 01:03 PM.
Reason: Automerged Doublepost
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
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.
Hmmm.... ... ...
My brain hurts when you do stuff like that
Yeah, think how my brain feels!
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?
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.
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.
I think it is a value that relates the 6811's E clock frequency to rpm.
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 03:04 PM.
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
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..
As mentioned earlier, the Lotus Carlton (& ZR-1 Corvette) used a RPM/31.25 variable for extended range.
Thank you. I would need to use an RPM/35 value to get my rpm range into one byte. The problem - as I see it (please! correct me if I'm wrong!) - is that the stock 2d lookup tables, require 16 "argument" steps between table values... or rather they're assumed to be 16 steps apart. So using the RPM/25 for an example, 16*25 = 400 rpm, which is why many 2d tables start at 0, 400, 800, 1200...... etc. So, with an RPM/35 variable, I would have a 560rpm step in my table that starts at 6400... so it would be 6400, 6960, 7520, 8080, 8640, 9200...
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!
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)
So you put the resultant (16 bit) X on the stack, and Pull (8 bit) A and B off it? Since B is what is used in the RPM/25, would what's in the A register at that point be the MSB from the RPM/25 calculation? i.e. the byte that represents RPM values over 6375?
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)
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.
__________________ 00 S10 416 LS3 4L80E AWD - in progress
89 GTA 355 A4 sold
69 rS 383 A3 sold
68 SS 468 M4 sold
There's an error in the Fdiv comments I made.
The remainder is in accD.
Okay... I think you're right, I'm going to have to find a good website showing what psh/pul do, because I have a feeling the above is critical to my understanding...but I'm not there yet.
Thanks for the ideas, I've obviously got a lot of work ahead of me...
Are you going to be turning 6500-8000 RPMs in a 3rd gen?
No, I sold my thirdgen a few years back. This is for a northstar v8
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 10:37 AM.
Reason: Automerged Doublepost
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.
__________________ 00 S10 416 LS3 4L80E AWD - in progress
89 GTA 355 A4 sold
69 rS 383 A3 sold
68 SS 468 M4 sold
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.
There's an error in the Fdiv comments I made.
The remainder is in accD.
Okay, right... But they get overwritten by the pula and pulb after the quotient is put on the stack as X. I think. Right? Otherwise the RPM/25 would be the remainder that gets stored later.
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...
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.
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?
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.
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?
addition at $FDE7 (from my patch):
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
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?
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.
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.
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.
haha... well that was a pretty obscure way of pointing out the error... I didn't know instructions could take up different amounts of space...
Curious what specifically is worth changing over to 8D? (besides the BLM table)
Would it be possible to have some sort of compound function specified?
That's how I did it for 8D.
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....
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:
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
now points to this routine:
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
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.
because if I used the same routine, I would need a much larger table... I just wanted an 11 cell table, that starts at 6400 and ends when the rpm/37.5 does, around 9500.
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
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
# specifies a number, no # specifies a memory location, so since the RPM/37.5 value is at $00FA in RAM, that's listed correctly.
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.
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.
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...
This is from the AS6811 assembler.
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.
Quote:
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.
AS6811 won't let you use a $.
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.
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.
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.
__________________ 00 S10 416 LS3 4L80E AWD - in progress
89 GTA 355 A4 sold
69 rS 383 A3 sold
68 SS 468 M4 sold
Hmmm.... ... ...
