nAst1: Progress and Concepts Thread

[robertisaar]

oh, i guess i should update a bit: have some odd behavior pop up when the fuel accumulation subroutine goes into effect... which is odd, since it's nearly identical to the distance accumulation routine. causes the ECM to go into an endless reset when it tries to accumulate fuel used.

once i get that worked out, the rest of it should be fine, it's the only issue i've run into so far.

[robertisaar]

the 1227730 based ECMs have a lot of inputs(most of which are useful without any internal modifications), but outputs always run kind of short. i wonder if i should be doing something weird like attaching some hardware to the address and data lines and watch for writes to some key addresses to control more outputs? actually..... that doesn't sound too crazy?

some thoughts i had on the gearhead-efi forum.....

am i talking out my ass, or does this sound reasonable? i mean, all of the signals necessary are present on the edgecard connector, so no extremely fine-tuned soldering skills would be necessary like would be if attaching wiring to the PLCC packaged chips.

of course, i would have to develop code for the "sniff and scratch" processor/output manager, but it actually wouldn't be all that different than what RBob did with the EBL, just instead of dealing with more inputs, it deals with more outputs.

[brian89gp]

Sounds reasonable.

I seem to remember someone doing something similar by mapping more I/O to some of the empty address space. Thinking it was for the C3 and they either used chips taken from an extra C3 or the industry equilivent models.

[robertisaar]

Rbob doesn't seem to have any issues with the "sniff" portion of his setup for the EBL, i'll just have to study what i can from there.

if i get REALLY creative.... could do some pretty advanced things with it rather than just PWM and discrete outputs.

[robertisaar]

since no one has asked....

the really creative applications? not only could SFI injection on any realistic number of injectors be done, but coil per cylinder ignition could also be utilized. and beyond that, direct injection.....

actual processing time "cost" for each of these is VERY minimal too.... for stuff like this, just need to determine a couple of 16-bit values, being "how long does this signal need to be active" and "how long from now should the signal start being active". store both values to "RAM" (or even actual RAM, since there is an abundance of it with the 9396) and then the add-on hardware does the rest.

[ericjon262]

I don't really know how it would work, but it sounds cool. I'm going to try and start figuring out the obd2 coding a little more, right now though, I just don't have enough time...

[robertisaar]

researching some applications to import them into nAst1, find out that 6D, 88, 8F and A1 all try to store and recall information in the 1800-1FFF block of SRAM that the 1227727 and 1227730 ECMs didn't get.... 46 and 55 don't.

so running those masks in an ECM that does have the SRAM added will likely cause it to run differently. it's usually small things that aren't that significant to the proper operation of the engine(and transmission), but sometimes they are. i've seen some EGR functions stored there at the very least. i think i'll document what all A1 stores there to get an idea of how badly GM might have goofed this up starting in 1988 and running until 1994.

[robertisaar]

in A1, starting at 1E13(earlier stuff starts around 1813):

1E13: byte written to FMD2, which isn't present on any 7727, 7730 or even 9396. is present on a 7749 though. so, output buffer.
1E14: 16 bit word, also written to FMD2.

both of those are in an unused subroutine, so GM left them in the code for whatever reason.

1E1A: 16 bit word, factory alpha-n calculated airflow stored here. never pulled, but is stored.
1E1C: total number of IAC steps added due to fan loads(and likely A/C and power steering). only stored.
1E1D: learned EGR 0 position(EVRV EGR). this is both stored to AND read from.... so EVRV without the extra RAM won't function properly.
1E1E-1E23 are actually all EVRV related values that are read from...
1E24-1E27: copy of current DTCs set. don't appear to be read from, so only for informational purposes.
1E28-1E29: used with the "clear codes when grounding diagnostic terminal" option. looks like they are counters, used to setup a minimum time with the ALDL B pin connected to ground to cause DTCs to be cleared.

1E2D-1E38 are used with the F31 transmission option. both stored and loaded.



that sums up all of the bytes used in the SRAM block... so, EVRV, 4T60E control and being able to clear DTCs by grounding the ALDL B pin are all going to function oddly, if at all, when used in a normal 7727 or 7730.

[robertisaar]

and because i'm a masochist apparently, converting the 9396's onboard SRAM to be NVRAM(powered by the vehicle's battery, so disconnecting the ECM or battery entirely will clear it), one should expect to see around up to 15mA more draw, with 5mA typical. this is with assumptions based off of similar SRAM chips with access times of 150nS, which are probably around what these were.

that doesn't seem too bad?

[caffeine]

What about porting this to a 94-95 P66 PCM to get more updates and support SFI, etc... I understand than the processors use basically a superset of the P4 instruction set and there would be more room for code as well.

I admit flash tuning is slower than emulation by quite a bit but IMO it beats burning chips and winflash only costs $20; less than a chip adapter , and less than a burner or emulator.

[robertisaar]

considered it... and may. i've been on a quest to find the ultimate 6811 powered PCM lately, going so far as to see what the australian guys used(they had 6811 powered stuff up until ~2001 in certain vehicles).

for better or worse, it does appear that the north american market did get the best units that i know of. especially when it comes to dual 6811 units. the list of potentials that i have amassed so far:

93-95 3100/3.4RWD PCM(dual 32KB as-is, but dual 64KB may be possible, i need another one to take apart though)
93-95 northstar (dual 64KB, non-flash, single MEMCAL)
94-95 LT1 (dual 64KB)
96-97 LT1 (dual 96KB? seem to use memory paging to get above the 64KB addressing limit of the 6811)
96-99 northstar (dual 96KB, same as above)

since the P6 are really just 6811F1 units, they're already documented quite well from motorola/freescale, which is a nice advantage compared to what the DIY GM ECM community has had to rough out since 1986. i'd like to just start off with a unit setup for 8 cylinder operation for when it's needed too.

the P4 and P6 do have some noticable differences though, ones that would make importing quite a pain. vectors are setup WAY differently, SPI comms between the two halves of the PCM, I/O ports are in completely different locations....

if i were to start playing significantly with them(i did already patch a few things for the 93-95 3100 code), i would go fully custom with the code. or at least, it wouldn't resemble a noticable portion of what nAst1 started as, i'd likely reuse useful code segments.

i need to look into it still, but it wouldn't be out of the realm of possibility to replace(at least temporarily) the flash PROMs with NVRAM and be able to update the calibrations over ALDL.

[caffeine]

Interesting. Do you already have a disassembly of the P66 V6 code? How difficult to patch in your extended VE tables and convert it to use a 2-bar MAP sensor?
There seems to be more interest in these PCMs now that Tunercats has released support for them.

[robertisaar]

of course, it took tunercat around a year after madtuner and i actually got it all functional... oh well.

yes, the code is disassembled, the engine side is highly understood, some sections of the transmission side... less so. i'm not used to looking at certain aspects of 4L60E code. there is also absolutely no room for additional code on the trans side. literally down to 30 or less bytes with no code mods.

extended VE..... possibly tricky. the P66 V6 PCM actually uses a decent main VE table(0-6400 in 400RPM increments, 15-50 MAP in 5kPa, 50-100 in 10kPa), but it's also 16-bit instead of 8. i could convert into a 17X17 0-6400, 20-100 table easily, then have the simple 2D retard table and fuel multiplier table for anything up to a 3BAR from nAst1. doing the 3 table setup is only slightly more complicated.

[brian89gp]

If there is a huge time investment required regardless of the PCM, would make sense to do the work on the *best* PCM. If you got the chops to do it (this is a compliment, not many people do).

Too bad the 93-95 N* is not a weatherproof version. Its got most of everythign else
MEMCAL
-easy NVRAM
-large selection of knock sensor filters
8 injector drivers and SFI code to drive them
Already a DIS ignition setup
Fairly cheap and available on ebay
Don't they have both MAP and MAF already?

[robertisaar]

the 93-95 seem to have issues randomly dying... or at least that is the impression i got from the cadillacforums. it also doesn't have an IAC drive, the 93-95 use a variable duty cycle "popper" to slightly open a second throttle plate from the looks of it. MAP only. i think the filter is actually setup a bit different from the typical units though. i have one here to reference, i just need to dig it up.

i'm thinking 96-99 NS MIGHT be the best route, but i need to do more research. it does have the limitation of using the weird knock filter. not really sure what to do about that. i imagine some interesting tricks could be employed to make a DIY knock filter(maybe even a GM one, just adapted) that would reside externally from the PCM and then just ground the knock sensor circuit whenever knock is detected. should cause knock to be detected easily. the issue is making the DIY portion of it not require an engineering degree.