Announcement

Collapse
No announcement yet.

nAst1: Progress and Concepts Thread

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • caffeine
    replied
    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.

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • caffeine
    replied
    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.

    Leave a comment:


  • robertisaar
    replied
    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?

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • ericjon262
    replied
    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...

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • brian89gp
    replied
    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.
    Last edited by brian89gp; 08-12-2013, 10:22 AM.

    Leave a comment:


  • robertisaar
    replied
    Originally posted by 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.

    Leave a comment:


  • robertisaar
    replied
    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.

    Leave a comment:


  • TurboGTU
    replied
    Most palms diagnostic interfaces worked off the serial port. The USB on the palm was just to sync. A good interface would be ALDL to Bluetooth . So now most devices are covered even some Palms.

    Leave a comment:


  • pocket-rocket
    replied
    That would be nice.

    All android phones (to my knowledge) have usb ports on them. Wasn't there a setup for palm for interfacing with ecms years ago?

    Sent from my HTC One X using Tapatalk 2

    Leave a comment:


  • caffeine
    replied
    I've thought it would be cool to write an android app to interface with the ALDL and use a tablet as a gauge cluster with whatever gauges you want.

    Leave a comment:

Working...
X