Strange this came up same time I found 7.4L $42 superceded bin file went from $00 $96...
Printable View
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.
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?
Ok, gotcha. Basically you're hand-disassembling then, at least for the bytes that are different?Quote:
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.
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.
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)Quote:
I suppose I could cut pieces of the code up, disassemble them and paste it into the code
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.
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.
When you going to work on or teach us how to complete the LT1? Or 98 Vortec? Or better yet the 2002 12212156 OS? :innocent2:
I'll come to CA... ( oh man what did I say? :yikes: ) and make your truck run perfect if you work on those? :rockon:
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.
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.
LOLQuote:
I'll come to CA... ( oh man what did I say? :yikes: ) and make your truck run perfect if you work on those? http://www.gearhead-efi.com/Fuel-Inj.../rock%20on.gif
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.
There's a custom OS for the 0411 that will handle the boost. Never did paddle shifters?
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
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.Code: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
...
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.
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.Code: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
...
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.
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.
Code:_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
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.