$42 hack and hiway lean cruise patch

[EagleMark]

Blast it, is just erased my post before I saved it, here goes again, maybe a little more coherent. If the bin has a $96 at $0FFF, then the second half of the instruction is on the next chip at $1000. If the bin has $00 at $0FFF, the the entire next instruction is on the next chip. I would be very careful about setting $0FFF to $00 in a bin unless I knew for sure that $1000 had the entire instruction.

Strange this came up same time I found 7.4L $42 superceded bin file went from $00 $96...

[jim_in_dorris]

I am using asm11 for an assembler, I don't disassemble anything, I just use the bin and the asm source. If I have an already commented disassembly for a mask, I can make it match any bin in the mask. Yes it's work, but if you use a hex editor to do a compare, you can compare the bin created by the hac to the bin you want to create the source for and find the differences. Then just manually enter the differences into the source code.

[shimniok]

I am using asm11 for an assembler, I don't disassemble anything, I just use the bin and the asm source.

Ok, I follow. Where does the asm source come from? Someone else must've disassembled, I guess?

Do we know what microcontroller/microprocessor is used by the "C3" ECM? I thought it was a variant of 6803. Does it have special opcodes and if so, do we have documentation for those?

If I have an already commented disassembly for a mask, I can make it match any bin in the mask. Yes it's work, but if you use a hex editor to do a compare, you can compare the bin created by the hac to the bin you want to create the source for and find the differences. Then just manually enter the differences into the source code.

Ok, gotcha. Basically you're hand-disassembling then, at least for the bytes that are different?

[jim_in_dorris]

Yes, the microprocessor used is a variant of the 68HC11, that's why the asm11 assembler. I don't really hand disassemble, because on $42 code, the changes to the bin are almost entirely just calibrations, ie, spark tables, and the like. I just replace the values in the tables. I suppose I could cut pieces of the code up, disassemble them and paste it into the code, but most of the tables aren't very big, and it would take about the same amount of time. The 350 bins were actually fairly close to each other, I am finding that the calibration for a 305 is very different, and almost all the calibration up to the start of the actual code is different. It means that I will probably spend a lot of time on the comments. I want to end up with an accurate 305 disassembly, as there doesn't seem to be many of them around. Someday I will have enough money to finish building my 350, but until then I will be running the 305 I have now which seems to just want to keep going.
When I finish the 305 asm file, I will probably go back to the ASDU and ASDX asm files and correct all the comments from what we have learned up until now. I know that Mark will appreciate that.

[EagleMark]

When I finish the 305 asm file, I will probably go back to the ASDU and ASDX asm files and correct all the comments from what we have learned up until now. I know that Mark will appreciate that.

Good comments sure would take a lot of time off my descriptions I work on in the mask/XDF and how it actually effects an engine!

[shimniok]

I suppose I could cut pieces of the code up, disassemble them and paste it into the code

Oh, actually that's what I thought you were doing. I get it now -- the hacked bins are actually bins someone already hacked and you're reverse engineering what changed in source (e.g. lots of data and maybe some code was disabled or something)

So here's an interesting thought that hit me last night. If the "C3" ECM used a 6801, 6803, 6809, etc., it doesn't really matter. As long as the chosen disassembler (HC11) could produce valid assembly code that could then be fed back through a corresponding assembler (HC11) to reproduce the original bytes, the process works. Except that the disassembled source code wouldn't match what GM originally wrote. I suspect it works because the 68xx family use the same format for opcodes and operands. One probably couldn't use, say, an x86 disassembler and assembler because the format for opcodes and operands is completely different.

Tunercat's website suggests the early ECMs (pre P4) used a 6801. (http://www.tunercat.com/disasm_desc/disasm_desc.html) so I am curious to see what the output of their disassembly looks like and how different it is from the disasm11 output. Perhaps 6801 and 68HC11 opcodes are mostly similar.

[jim_in_dorris]

A lot of different disassemblers were used by the people who hacked the GM ecms. The end result was the same, a HAC source that could be turned into a source file with a little work. I can't claim any particular achievement in what I do, the people who created the orignial hacks deserve the credit. I am just trying to make my life a little easier by building those hacks into usable asm files with good comments. I have about 4 months of solid work commenting a $0D asm provided me by someone else. If I can do the same for others, it is only fair. I hope to have completed the $42 asm files by summer, if work doesn't get too hectic. Then I will start back on the $0D hack with the knowledge I have gained from this.

[EagleMark]

When you going to work on or teach us how to complete the LT1? Or 98 Vortec? Or better yet the 2002 12212156 OS?

I'll come to CA... ( oh man what did I say? ) and make your truck run perfect if you work on those?

BTW I've only found three 1k pup coolant temps in $42 so far and that conversion the guys made is spot on. Also got the others done and just about as spot on with standard CTS conversion! Testing them real time in vehicle! Man are all the temps in dis assembly comments off... maybe next week or so I'll have them all tested and give you the notes for your comments. The $42 XDF final version is close to being done... I'm going through descriptions so they read in English to a GearHead and he knows what to do with each parameter.

[jim_in_dorris]

Mark, I really look forward to your notes. The 305 calibrations are way different, so I will have to work on almost all the comments.

I'll come to CA... ( oh man what did I say? ) and make your truck run perfect if you work on those?

LOL

I haven't even got to that stuff yet, I really want to understand what I am working on right now. Later I think I might want to switch to the 411 code stuff, my wife's 2002 blazer could use the transplant. I think I could make a trip to Idaho for that. Do you think that a 411 ecm could handle a typhoon/cyclone "clone" with a paddle shifted 4l80E? That's what I want in my street rod. I just have to start on that project before I die of old age.

[EagleMark]

There's a custom OS for the 0411 that will handle the boost. Never did paddle shifters?

[shimniok]

I threw together my own 6801 disassembler in Perl, so I could (a) illustrate why I was confused by the posted ASM files (b) have more control over disassembly.

Here's the original ASDU1.asm file

        ORG $0617 
        LDAA    #03      ; LD D w/ $0301 
        LDAB    #01      ; 
        JSR     $FBCE    ; TO CPU 
        LDAA    $000F    ;    
        ANDA    #8       ; MASK FOR b3, AC ON 
        TST     $D007     ; 0010 0100, 3rd AFR OPT WD 
        BMI     LD62C     ; 
        LDAB    $0005    ; 
        ANDB    #$80    ; 1000 0000 
        ABA
LD62C   LDAB    $0010
...

Because the bin wasn't disassembled with the correct load address of $D000, location $000F and $0005 referenced above *seem* to reference parameters in the bin. In actuality, those parameters sit at $D000F not $000F and $D0005 not $0005. Anyone who looks at these ASM files will likely be confused until they learn about the proper load address issue. Makes it very difficult to understand how the code works.

Here's the result of my disassembly. For direct mode addressing, I am using the label Dnn where nn is 00 thru FF (since direct mode can only address $0000 thru $00FF). The disassembler calculates the address for relative mode addressing (jumps/branches) and creates the appropriate label, Lnnnn. Extended mode addressing also gets an Lnnnn.

       ORG $D617

       LDAA  #$03
       LDAB  #$01
       JSR   LFBCE
       LDAA  D0F        ; Load accum A using direct mode from location 0x000F
       ANDA  #$08
       TST   LD007      ; Testing against $D007 (parameter in this bin), since the bin loads into $D000-$DFFF
       BMI   LD62C      ; Relative mode, calculates to $D62C
       LDAB  D05        ; Load accum B using direct mode from location 0x0005
       ANDB  #$80
       ABA

LD62C: LDAB  D10
...

At some point I will revise the disassembler to label variables with Vnnnn and then any instruction that references data (e.g., LDAA) will use Vnnnn instead of Lnnnn.

[jim_in_dorris]

That is cool, after you disassemble it, can you reassemble it back to the original binary? It would sure save time converting HAC files into asm files. Figuring out what resides on the prom vs what is processor accessed RAM is also fun when trying to disassemble.

[shimniok]

I haven't tried reassembling, yet but I think there's a good chance I can get it to disassemble into something that reassembles into the exact bin file. I haven't dealt with the parameters (data) area yet, either. I probably have to do that before I can assemble.

I've added a feature for configuring variable labels. I've set up the bin parameters with descriptive variable names. Sure helps figure out what the code is doing quicker this way. Hopefully after a bit more work, and once I get my hands on the ROM image, I'll be able to get a better sense of how the code works.

_Ld89f: ldaa  D20
        suba  D1f
        bcs   _Ld8aa
        cmpa  DFCO_DisableRPM
        bhi   _Ld8b5
_Ld8aa: bitb  #$48
        bne   _Ld8e2
        ldaa  D32
        cmpa  DFCO_DisableMap
        bls   _Ld8d0
_Ld8b5: ldaa  Da0
        beq   _Ld8cb
        ldd   D96
        addd  DFCO_ExitPulse
        bcc   _Ld8c3
        ldd   #$7fff
_Ld8c3: std   D96
        ldaa  D0d
        oraa  #$80
        staa  D0d
_Ld8cb: clr   _L00a0
        bra   _Ld937
_Ld8d0: ldaa  D26
        ldab  D08
        cmpa  DFCO_MapEnter
        bcs   _Ld8e2
        bitb  #$08
        beq   _Ld937
        cmpa  DFCO_MapExit
        bcc   _Ld937

[jim_in_dorris]

The reason I like to use the hacks is that they are all commented already, you don't have to try to figure out what is going on in a particular section of code, somebody already did that for you. Fully commented code is worth it's weight in gold to a programmer.