JP86SS

iTrader: (1)

I've got it assembling and it compares good!
Now I'm beginning line by line comparing to the ANHT hac to feel my way through the sequence of events and data locations.
The "jumping" around is still difficult for me to follow but I'm getting better at it. The multi-dimensional table lookups I especially need to get a grip on.
I am using the new version, thanks for that.
Comparing the dis or lis file with the hac and my ecu file is really helping me to see things at the end of the tunnel.
(Gee, I hope that's not a train! )

Good things to learn!

D's89IROCZ

Hay alll ....I realllllly need to know what bin file I have . I am not totally getting it ...... the guy need to know what bin to upload on to my prominator .

1989 5.0l 5 speed ( stock ...new setup in my sig ) but I wanted to start with a stock bin ...and go from there



PLEASE HELP ME .... I got to pages of where bins are stored ....I get to 6e ....then I open it to find a list of stuff that makes no sense ( yet)


PLEASE help I am kinda stuck here ...and dont have time to learn it all right now . I just need to know what to get ????!!!!!

JP84Z430HP

Please check out the stick's at the top, and use the for such questions. This thread is for advanced editing of the instructions that the ECM uses, compared to the basic tuning that you sound to be starting. Once you get to the point that you want to know every little bit about what the ECM is doing, this is the thread, but for most that are looking to tune their setup, this will be well over their heads, and they know what mask ID they're running.

The mask ID for what you're running would be $6E, and APYS is the closest I could come to what you might need for a BCC for what you need.

MTPFI-MAF

You can also use the 1989 Trans Am ANZA. It is for a 5.0l 5-speed, and is available Here. http://www.supportfitness.com/mark/t...wnloadBins.htm

D's89IROCZ

Sorry , I did a search .... finally posted . But thanx for the answer . I appreciate it .

JP86SS

iTrader: (1)

I wanted to put this up here to a.) keep this alive and well, b.) to explain how the bits in a word are manipulated in code.
It has taken me a "Bit" of time to figure out the actual one I want to work with so for the newbies can pick this up quicker than I did.

When manipulating bits there are "SET" and "CLR"
The syntax for the line is :
L0000: BSET L0022, #$01 Turns on bit 0 at the address 0022

To turn off a bit, the command BCLR is used instead of BSET.
The bit addresses are as follows:

bit 0 = #$01
bit 1 = #$02
#$03 =bit 0 and bit 1
bit 2 = #$04
bit 3 = #$08
bit 4 = #$10
bit 5 = #$20
bit 6 = #$40
#$60 = bit 5 and bit 6
bit 7 = #$80

The checking of bits acts on the same type of code, for example:

L0123 : BRCLR L0022,#$02, L1111

This line performs the following:
BRCLR = Branch if clear, looking at address L0022, bit number 1
If this bit is "Not" set then the code goes to L1111 (the TRUE argument) and continues.
If the bit "is" set, then the code performs an "else" and continues with the next line of code below this one.

This concept of operation was pretty foreign to me and I thought someone could benifit from the explaination.
Please correct me if I've mistated anything.
Edit: Wanted to note that the #$01 can also be seen as #0x01
The 0x indicates its HEX. The disassemblies show it that way.
JP

Cobra289

Thanks JP86SS for sharing your knowledge.
I am not there but your information is copied and saved at a good place.

I agree with you that we need to keep this thread alive.
Is not the time to make and official request for and “Sticky”
Do we need to ask to “Traxion”?

Regards,
Cobra289

RBob

iTrader: (1)

Traxion, who's that? (yes, I know who he is, just not a current mod). Been Stickied, on the Source Code thread.

To add a bit to the discussion. The instructions that operate on bit mapped data will also operate on multiple bits.

Changing this:

L0123 : BRCLR L0022,#$02, L1111

To this:

L0123 : BRCLR L0022,#$06, L1111

Will cause the CPU to check that both bits, b1 & b2 are clear before branching.

Same as the BSET & BCLR instructions:

L0000: BSET L0022, #$03 Turns on (sets) bit 0 and b1 at the address 0022

L0000: BCLR L0022, #$60 Turns off (clears) bit 5 and b6 at the address 0022

RBob.

Cobra289

Thanks RBob.
Sorry for the mistake
Regards,
Cobra289

JP86SS

iTrader: (1)

Thanks RBob for pointing that out.
I didn't see the combination addresses there.
I edited for the two you pointed out and will go back and fill in the middles.

TheGreatJ

Filling in the middles will make that post HUGE. I don't know much about code, and have yet to disassemble anything, but I understand hex quite well and this is something that makes sense to me.

For instance #$C9 will check/set/clear bits 7, 6, 3, and 0. #$DE will check 7, 6, 4, 3, 2, and 1, and #$FF will check all 8 bits. All 256 combinations can be checked using the same method.....convert the hex byte (i.e. C9) to binary (11001001) and the bits that are set are the ones that will be checked/set/cleared by the command (7, 6, 3, and 0.)

JP86SS

iTrader: (1)

Ok, maybe just adding a few more will do the trick
My hex really sucks, but bringing it back to binary makes much more sense to me that way and is easier to see what's up.

Mangus

Help with hex:
http://tunerpro.markmansur.com/tutor...tandingHex.htm

I really should expand it to cover binary too (binary = bits), since its the exact same concept except by 2's instead of 10's (decimal) or 16's (hex).

JP86SS

iTrader: (1)

Thanks Mark, I actually have that printed in my binder next to me.
I've been wrapped in binary and octal for so long, dewey's are just normal to see, hex just freaks out that part of my brain.

JP84Z430HP

This is a bit beyond the scope of what has been going on in this thread, but the following thread is a good one to have referenced here:

https://www.thirdgen.org/techbb2/sho...hreadid=267446

It discusses how some of the inouts of the 1227730 and 749 are read. I'm sure this is similar to how most of the P4 ECM's work, with just a different implementation.

I also shines some light on the possibility of the source code being modified to eliminate having to repin some of the stuff to switch between masks....

JP86SS

iTrader: (1)

I thought it would be good to put a link to this info here.
It's a post about the F2a source that is missing from the ANHT hac.
https://www.thirdgen.org/techbb2/sho...=MISSING+TABLE

Grumpy

When trying to disasseble a .bin, I'm getting this:
.byte 0x01,0x03,0x14,0x86,0x30,0x14,0x21,0x01
.byte 0x7F,0x00,0x1E,0x12,0x14,0x01,0x06,0x14
.byte 0x14,0x01,0xBD,0xF7,0x5A,0x20,0x38,0x4F
.byte 0x15,0x21,0x01,0x97,0xFA,0x96,0xFB,0x1F
.byte 0x01,0x80,0x32,0xD6,0x95,0xE1,0x2C,0x22
.byte 0x2C,0x12,0x22,0x80,0x0B,0x13,0x11,0x0E
.byte 0x02,0x20,0x28,0x4C,0xA1,0x2D,0x23,0x21
.byte 0x1F,0x0B,0x80,0x03,0x14,0x86,0x30,0x14
.byte 0x22,0x80,0x7F,0x00,0x1E,0x12,0x15,0x80
.byte 0x06,0x14,0x15,0x80,0xBD,0xF7,0x5A,0xE6
.byte 0x2B,0xD7,0x96,0x20,0x06,0x4F,0x15,0x22


Instead of something like this:

INC L0207
LDAA L0207
CMPA L88F9
BLS LC337
BCLR L0075,#$80 ; 2 MW2 (MINOR LOOP MODE WORD 2)
LDD #$FFFF
STD L00C4
JSR LF631
BRA LC337

This appears after trying to disassemble it,

Initializing...
Reading Control File...
Load Address: 0x0000
1 Entry Points:
0x0000
Source File: 5BA.BIN
Destination File: 5BA.DIS
0 Labels Defined:
Reading Opcodes File...308 opcodes read.
Reading Source File...File Size: 0x8000
Compiling Indirect Branch Table as specified in Control File...

Pass 1 - Finding Code, Data, and Labels...
LFFB2
*** Warning: Branch Ref: 0xFFB2 is outside of Loaded Source File.

Pass 2 - Disassembling to Output File...

*** Warning: Branch Ref: 0xFFB2 is outside of Loaded Source File.

; This control file is called 5B.txt
;
input 5B.bin ;this is the binary input file
output 5B.DIS ;this is the disassembly source/listing file
;load 8000
;label ffd6 scivect
;label ffd8 spivect
;label ffda paievect
;label ffdc paovect
;label ffde tovfvect
;label ffe0 ti4o5vect
;label ffe2 to4vect
;label ffe4 to3vect
;label ffe6 to2vect
;label ffe8 to1vect
;label ffea ti3vect
;label ffec ti2vect
;label fff0 rtivect
;label fff2 irqvect
;label fff4 xirqvect
;label fff6 swivect
;label fff8 ilopvect
;label fffa copvect
;label fffc cmonvect
;label fffe rstvect

and I've tried both with andwith out the ; label lines

What am I missing?

Cobra289

Have you have try the new one?
http://www.dewtronics.com/pub/m6811d...1DIS_v1p20.exe
This will give you a refference information as a comented output, is it "Data" or is it "Code" check my previous post.
From there you can conclude and put entry or remove entry.
It can be just a lump that you need to clean up and convert to Code.

PS
No much time those day's, I am working on a new wiring loom for the Cobra

Regards,
Cobra289

Grumpy

OK, got the new one..

By playing around some I've managed to get some of it disassemblied. But I'm still kind of lost.

some the addresses at the end are the vectors.

Then we have label, indirect, and entry.

After reading the .doc 10x I still don't get what they're looking for, OK, where it reenters the code.
BRA L90C0

I tried a number of different entry locations, and it always pukes there.

When the code stops like at that line, what *entry* location do you use to get past it?.


cmpb #0x09
bhi L9091
orab #0xE0
L908B: cmpa #0x09
bhi L9091
oraa #0xE0
L9091: rts
test
idiv
lsrd
tap
inx
sba
brset *L0014,#0x16,L90B4
bra L90C0
.byte 0x24,0x26,0x28,0x30,0x32,0x34,0x36,0x38
.byte 0x40,0x42,0x44,0x46,0x48,0x50,0x52,0x54
.byte 0x56,0x58,0x60,0x62,0x64,0x66
L90B4: lsl 0x70,x
.byte 0x72,0x74,0x76,0x78,0x80,0x82,0x84,0x86
.byte 0x88,0x90
L90C0: sbca *L0094
ldaa *L0098
L90C4: psha
pshx
pshx
pshb
psha
tsx
ldaa 0x03,x
mul

AlexJH

I don't understand what it is doing here:

What do you see at location 90B4 in the bin?

A byte of 0x72 does not correspond to a valid opcode (in a regular 68HC11), which should follow the LSL instruction.

So I'm thinking that the LSL INDEXED instruction (machine code 0x68) at L90B4 is not actually an instruction, but a data byte.

Anyone else follow my logic?

Going back further, I don't think that the

brset *L0014,#0x16,L90B4

instruction is correct to jump to $90B4.

Sorry I don't have a fix, I'm not very experienced with disassemblers.

Cobra289

One of the easy things to work with is the option "addresses" whet you set this "ON" in your “txt” (Control file) file you will get at the left every address for every line so you can use it for an "entry" so you don’t need to calculate the address of the line that you want to put as an entry

But don't forget at the end when you are satisfied of the result to remove this option because other ways it will never re-assemble correctly.
And other point of consideration is to remove all the labels and indirect and work only with entry’s to get the code.
In that case you need to go more extensive with the entry’s but in the new version I have read that it was no limit with the amount of entry’s.

This id the last one I did used for a $6e bin.
So I did remove the last label’s and indirects from your list (for some reason?).
If you see “?” marks on your “dis” then you have put and entry to much, remove the entry and the question mark will be gone.

I hope this help.
Cobra289

Cobra289

Just from the "DOC" file from the disassembler.
------------------------
Unlike the typical “disassemble everything” method of the traditional disassembler, the code-seeking disassembler actively seeks out and disassembles sections that it sees as code while leaving the rest tagged as data. This is achieved by giving the disassembler one or more initial entry addresses into the code. From these entry points, the disassembler continues to follow through the code as it hits jumps, branches, and returns. In the end, you should have a perfect separation of code and data. There are some complications to this. For example, what happens on a jump instruction that uses a register to obtain the address of the branch, such as is common with a jump table? The disassembler has no way of knowing exactly what the content of the register is, so it is forced to label the jump instruction as an “undetermined branch”. Such tables have to be located by the user and added as additional entry points for the disassembler. Also, suppose you don’t enter all possible entry points – the result will be a file with chunks of code interpreted incorrectly as data. And there are cases where there are unused bits of code that never get executed – those will remain tagged as data. But overall, the code-seeking disassembler is far superior to its traditional counter-part and in many cases, with little user intervention, can produce a perfect separation of code and data, which greatly facilitates the reverse-engineering and/or hacking of the target code.
------------------------

Grumpy

I have a .asm that I've gotten to assemble, when I generate a .bin from it thou, it doesn't match the original .bin.....

I see an entry of 68 at L90B4.

9098:1214 1616 [ 6] BRSET L0014,#$16,L90B4

It should be 1214 1618

909C:201F (90BD) [ 3] BRA L90C0
909E:2423 (90C3) [ 3] BCC L90C6
90A0:282E (90D0) [ 3] BVC L90D2
90A2:32 [ 4] PULA
90A3:34 [ 3] DES
90A4:36 [ 3] PSHA
90A5:38 [ 5] PULX
90A6:40 [ 2] NEGA

then there should be an entry of 42, here

90A7:44 [ 2] LSRA
90A8:46 [ 2] RORA
90A9:48 [ 2] ASLA
90AA:50 [ 2] NEGB

Grumpy

Adding a *FCB$42* took care of that one error.
but the 1214 1618, is a 1214 1617

AlexJH

That number that was a 16, became a 17, and should be an 18 is the number of bytes past the BRSET instruction that the PC will branch to.

Try changing this line: BRSET L0014,#$16,L90B4

Into this:

BRSET L0014,#$16,L90B6

AlexJH

Waittasec, it still looks like that is one big data table, look at how the numbers go:

The brset instruction is 0x12, so it's going from 0x12, increasing by 2.

The BRA instruction is 0x20, and 0x22 past that is L90C0.

The LSL instruction is 0x68.

SBCA is 0x92, LDAA is 0x96.

That pattern is too regular for me for it to be code!

----------------------------------

brset *L0014,#0x16,L90B4
bra L90C0
.byte 0x24,0x26,0x28,0x30,0x32,0x34,0x36,0x38
.byte 0x40,0x42,0x44,0x46,0x48,0x50,0x52,0x54
.byte 0x56,0x58,0x60,0x62,0x64,0x66
L90B4: lsl 0x70,x
.byte 0x72,0x74,0x76,0x78,0x80,0x82,0x84,0x86
.byte 0x88,0x90
L90C0: sbca *L0094
ldaa *L0098

----------------------------------

Edit: For those of you wondering where I'm getting these numbers, I'm looking them up on an opcode map:
http://home.earthlink.net/~tdickens/...pcode_map.html

Ie have a look at the table in position 1, 2. That corresponds to the BRSET instruction.

Grumpy

This is getting nuts.........
Line 5431 needs to be 2830 instead of 2831.
Does this area of code make any sense?.


5424 9097:10 [ 2] SBA
5425
5426 9098:1214 1618 [ 6] BRSET L0014,#$16,L90B4
5428 909C:2022 (90C0) [ 3] BRA L90C0
5430 909E:2426 (90C6) [ 3] BCC L90C6
5431 90A0:2831 (90D3) [ 3] BVC L90D2
5432 90A2:32 [ 4] PULA
5433 90A3:34 [ 3] DES
5434 90A4:36 [ 3] PSHA
5435 90A5:38 [ 5] PULX
5436 90A6:40 [ 2] NEGA
5437 90A7.42 FCB $42 ;
5438 90A8:44 [ 2] LSRA
5439 90A9:46 [ 2] RORA
5440 90AA:48 [ 2] ASLA
5441 90AB:50 [ 2] NEGB
5442 90AC.52 FCB $52 ;
5443 90AD:54 [ 2] LSRB
5444 90AE:56 [ 2] RORB
5445 90AF:58 [ 2] ASLB
5446 90B0:6062 [ 6] NEG $0062,X
5447 90B2:6466 [ 6] LSR $0066,X
5448 90B4:6870 [ 6] L90B4: ASL $0070,X
5450 90B6.72 FCB $72 ;
5451 90B7:7476 78 [ 6] LSR L7678
5452 90BA:8082 [ 2] SUBA #$0082
5453 90BC:8486 [ 2] ANDA #$0086
5454 90BE:8890 [ 2] EORA #$0090
5455 90C0:9294 [ 3] L90C0: SBCA L0094
5456 90C2:9698 [ 3] LDAA L0098
5457 90C4:36 [ 3] L90C4: PSHA
5458 90C5:3C [ 4] PSHX
5459 90C6:3C [ 4] L90C6: PSHX
5460 90C7:37 [ 3] PSHB
5461 90C8:36 [ 3] PSHA
5462 90C9:30 [ 3] TSX
5463 90CA:A603 [ 4] LDAA $0003,X
5464 90CC:3D [10] MUL
5465 90CD:8900 [ 2] ADCA #$0000
5466 90CF:A705 [ 4] STAA $0005,X
5467 90D1:EC01 [ 5] LDD $0001,X
5468 90D3:3D [10] L90D2: MUL
5469 90D4:EB05 [ 4] ADDB $0005,X

RBob

iTrader: (1)

This isn't code, it may be data, it may also be dead space. Don't bother trying to disassemble it.

That's the beauty of it, if it doesn't make sense as code, then it most likely isn't.

As an example here is a snippet of disassembled 'code':

No way is this code. It is a data table of some nature, -or-, even a dead area that is not even in use. It may just be whatever was in the host computers memory at the time of assembly. If there isn't a defined value for a location then the bin ends up with whatever is in the computers memory at time of assembly.

For that matter it could be part of an Word document

RBob.

JP86SS

iTrader: (1)

I found that I was "over doing" the entries to fix "chunks" like that that did turn out to be data tables.
The problem was that when I added ENTRY or indirect, some of the data inadvertently changed to code that pointed somewhere else and changed that data into code as well. Made thing confusing to say the least.
I backed off and restated my entry table until I could prove they were data or code.
Another option in the disassembler is "spit".
This may help to see tables of data from code as well.
It trys to make everything code. Some parts just come out bad, indicating a possible table location.
Lots of trial and error but I finally got my AUJP to come apart and go back together.

1 note: The interrupts at the bottom MAY come out as "FCB"
They need to be FDB to compile correctly. This was using a different assembler than the one Cobra made available.
But I got it assembled Ok that way.

What bin are you working on?

Z69

Just a little something I do to see what's going on. Most of the hacs will tell you what bits are being manipulated, but this acutally will show you.

Say you see something like this in the code your hacking.

If you put $14 into you windows calculator and convert it to binary you'll get 10100.
Counting from the right is bit 0 to bit 4.
So b2 & b4 are being set.
Looking in the pink book, it says only binary values of one will change the bit. So the zero's in 10100 will not affect b0,b1,b3.

Now I need to find the time to dissassemble something and catch up with you guys. At least I have all of your work to look at if I get stuck. Thanks guys.

AlexJH

Pretty soon you've be able to do the calcs in your head.

Also, have a look at the AND, ORA, EOR instructions to see how they do bit masking operations to the Accumulators and Index registers.

Z69

I had a hard time figuring out the indirect's for the control file when I did aujp.
I didn't just want to copy the available list.
All I could find for sure was the last 9.
They are in the anht hac as well as the diy-org p4 stuff. I'm unsure of what else even needs them. My compare came out good. I added only two .org commands to get rid of a bunch of the 00's starting at 8988. Biggest time waster was using too many entrys. I used entries for all the clumps. The cut and paste for the comments are going to take forever though. Not to mention all the labels...

So how do you know when you need and indirect for a constant? Like 7FEE

JP86SS

iTrader: (1)

I was under the impression that you need "indirect" and "entry" to indicate to the disassembler that the code is "jumped" to the pointed to location from an indexed register. The description above from Cobra289's "Doc" exerp makes the most sense of it.
I'm not sure of your reference to 7FEE, that looks like a memory location to obtain a value during execution. There should not be any "Code" there. The AUJP starts at $8000 for the execution code.
I'm doing the AUJP now and it does take close to forever to patch in the text. I haven't bothered with the lables yet until I know for sure they are correct by tracing through the actual code.
The ANHT has several issues with it and they don't always line up with AUJP. I still have an issue with an extra $FF at location this is the description I've put in my file
"Went back over the extra $FF error at L834B table.
; the value does exist in my AUJP (not a cut paste mistake)
; (went all the way back to original file to confirm)
; The actual values in my HAC are now moved from L8358 to L8357
; Then the data values line up with the ANHT hac descriptions.
; There is still a missing address at L835C (nothing there)
; This could be the key to the issue if I get through the
; actual calculations to see what is being used through the code.
; Everything would shift back into place between L834B and L835D.

I hope that makes sense to you.
If you want a copy of my cal section (all but the upper VE is totaly commented) I can send it to you.
I didn't want to post it on Craig's site until I was sure if there is an error or not.
If you are doing AUJP, you "may" see the same thing, I hope so and maybe we can figure it out.
Jp

JP86SS

iTrader: (1)

Must have been a typo on that 7FEE,

LFFEE: FDB $88,$CD ; FOR ALDL TESTING
FDB rtirtn ;$6000 SWI ; Branch Outside Loaded Source(s)
FDB irqrtn ;$B204 ; IRQ1
FDB xirqrtn ;$E3ED ; IRQ, NOT USED
FDB swirtn ;$6000 ; ILLEGAL OP CODE ; Branch Outside Loaded Source(s)
FDB iloprtn ; ILLEGAL ADDRESS
coprtn: FDB $B0,$00 ; COP TIMED OUT
cmonrtn: FDB $B0,$00 ; CLOCK FAILED
FDB $B0,$00 ; HOT RESTART

That's what I have down there.

Z69

FFEE-$8000
The M6811dis.doc uses those addresses as an example for required indirect listings in the control file. I just thought that there were more than the 8 required that I did. I noticed some none zero values just above my vectors tonight when I review the .dis again. I did entries for all the lumps to differentiate them from the vector stuff in the control file. I need to read Cobra289's directions again. I just used some abbrev. cut/paste directions I made to do it. I just did the 8 indirects that I new where to find the addresses for. I figured that the errors would lead me to the rest. Basically I wanted to see how to disassemble a bin w/o a hac as an assist.

I did notice a $0001 offset to the code in aujp. Thought it was me being hex challenged....Or just a typo in the anht hac.

I've noticed some areas missing from the anht hac. They are not all blanks. The 800 rpm idle limit that Traxion talks about for the S_aujp is one area. You'll note that the anht hac has a lot of org listings. Only needed if your deleting areas from the .dis file and want it to assemble. Or you want to add things to the blank areas and ensure the orginal code/data doesn't move. Might want to do a anht to aujp bin compare to see what I mean. I used the Super 8dm2 ecu.

JP86SS

iTrader: (1)

I found the code editor that came with my THRSimm11 program.
It is a stand alone editor that is pretty nice to work with.
Its called "SciTE" and has Windows and other operating system support.
Has a big list of reconized code language structure stuff built in.
Might want to give it a try. (has colors, OOooohhhh, Ahhhhhh)

http://scintilla.sourceforge.net/SciTE.html
and its free

JP86SS

iTrader: (1)

Back from the archives with more to add
Now that I've got the original hac file to assemble its time to make it relocatable.

I wanted to keep the code question stuff out of the Great $8D list thread so I brought it back here.

From the other thread:
The key to making the source work is to not have any hard coded addresses. This statement is the same as above but with the table address hard coded:

How can you distingush between the above instruction that is pointing to an address (value IN the address will be loaded to X)
and
something like
"LDX #$3FC0 " ???

I realize the 3FC0 is an address but it could also represent 16,320 decimal value in a calculation.
The distinction is not clear in my mind.
Several places indicate LDX of value #$0000
These could be the minor loop counter value OR a value of zero to clear an address in the next opcode.

Can anybody provide some insight there?
TIA

RBob

iTrader: (1)

The key is to know how the value being loaded is going to be used. The easy to break one (LDX #$81FD) is the address of a table. So as the tables move around so does the address of that table.

If the value being loaded is to be used as data, then no label (EQU in the case of a data value) is required. Nice to have an EQU but not needed.

To go one step further (to really confuse the issue), in P4's the address of $3FC0 is the DRP counter. This is a ECM hardware location and won't be moving. Still, it's nice to have a chart such as this at the beginning of the code (short version):
In this manner the label L3FC0 can be used when referring to the DRP counter.:
Although it isn't a requirement:
When I do hac's values that are used as data typically get hardcoded. That is using the #$nnnn or #nnn (decimal) form. And to take it a step further, if it is a double value I'll use 4 or 5 digits to show that. And if a single byte value I will use at most 3 digits (if in decimal) or 2 digits if in hex.

First one in decimal and the second in hex, both double operations.

This is just something that helps the reader of the code to easier see what is going on.

RBob.

yager

few questions.

1) Anyone have a working control file for a 8746 $61 ? I'm not 100% sure from searching what code bases everyone is using. I don't know from user names who's running what.. (not yet)

edit: ok after additional repeated reading of the instructions it seems my errors might be 'normal' from the indirect jumps, but im still workign on this...

edit2: im still confused... on this...

2) This question is in reference to doing code work AND tuning. (NOT doing simple patch stuff.. )

How are you saving your tune information between each reassemble, assuming there was modified code?

Is the process somting like this?

- Make code changes (reassemble etc)
- Do some tuning.
- Do you cut past your newly tuned tables into your 'old' code base (hack) That you just assembled with? (to keep it updated).
- Then have to go update your TunerPro definition to reflect these possible changes of table locations?
- more tuning
- more code
- repeat

Im sure its better to not mix the two processes. and maybe im over thinking the ammount of actual coding being done out there and its not a big deal for a 1-2 times a year thing... But it still seems like it could be a real manual process to keep tabs on where your tables were/are if your attempting to do some serious recoding..


Possibly a simple perl script to update the TP definition to reflect the new locations.. (shhh... i know were not soposed to edit them manually)

or
Possibly in a future release of TunerPro there could be a new button/feature to search your commented hack possibly using your relitive location IDs and do the update.

Im not to this point yet just ponder this stuff on my daily commute to/from work...

JP86SS

iTrader: (1)

You only need to work on the definition in TP if you have a hard coded value that you want to adjust and you have made a code change.
The Table values etc are in the calibration section. That doesn't move (or shouldn't be moved)
Adding new items to the end of the calibration or sliding them into an already open slot is the best way to keep things in place.
Copying in "new" table data to your hac file is the only way to keep your commented file up to date.
I wish there was an easier way but not currently. I cut out the tables and keep them in separate text files then edit them as needed. That way you can cut/paste versions as needed when you start over.
Keeping a "virgin" stock file will make it easier to do a text compare and see what your current changes are.

escort_ford84

From what source can i get labels from for my control file. I see this "Motorola pink book" but i cant find it. The APYP labels do not work.

Z69

M68HC11RM.pdf is what your looking for.
Not that you need it for your labels.
You have a misunderstanding as to what is being done by the software.
Go back and read your other post and see what I wrote.

A label is simply a variable used to designate a specific address by the assembler once it starts compiling the text file. It can be most anything. ie X: x: Lxxx: Start: End: Jump to patch: etc..... The actual address can move as things are added or removed from the asm file. So it can be confusing to use an address based label such as L8402:. But it's a label so L8402: doesn't have to be at location $8402 on the chip. That's when the list file comes into play. If you want to know where the value of L8402: is at in the bin you have to go to the list file and see what actual address it ended up at.

Your getting labels confused with something else....hint hint
You only need one to get started.
You may have to read this thread again. IIRC what you need may only be specifically mentioned once and isn't obvious by it's useage in the post. And that is in regards to the 8d bins used. When trying to do a bin from another mask.
You have to understand where the ecm knows to look on power up.

I can't remember where I saw a posted list of these addresses. It was either Ludis or DIY_EFI I think. But you don't have to find that page to do this. From what I could tell, I was the only person that looked into doing this w/o using an existing hac to get the addresses needed. That's in reference to this thread.

Now if you want L8402: to be at $8402. The you put Org 8402 on the line above it. That's how you "pin" code or data to a specific location in the bin.

escort_ford84

Strange, ive been sitting here all day racking my brains out trying to figure out how to get the m6811 disassembler to disassemble my bin. There has to be some kind of reference to that. Simply "pulling" a control file from underneath isnt possible. Ive tried. I downloaded CATS disassembler and ran my bin through it and in about .25 seconds its all there. There is ONE thing i dont have to make the m6811 dis. to work, and thats a reference manual for the labels. Using the APYP control file, i disassembled the APYP and it came out fine. It would be a dream come true if that were the ECU i was using. I think the measly little price for CATS products is well worth investment.

This is what i see in that PDF.....

your Control File should include an "input" statement and an "output" statement to specify
source and destination files, respectively. And, it should include at least one entry point, in some form, for
the code disassembly. If no entry points are specified in the Control File from either "entry" statements or
"indirect" statements, the load address of the file is assumed to be an entry point.

i did not include an entry point.


that *.dis file it makes has nothing discernible in it.

Z69

well, a whole bunch of us did it.....for free.
Myself along with the others in this thread had never dis'd a bin until this thread.

escort_ford84

Well, disassebling something thats already been disassembled is easy, ive done that already. disassebling something that hasnt has yet to be done, if ya think about it. here is my control file and my disassebled file, along with the disassembled file from CATS disassembler. I have attached my files. A.txt being my control file, a.bin being my bin file, a(CATS).scr being the CATS disassembled of the same bin file. Note, there is a problem. the 2 files dont match, one is readable, the other isnt. Ive been at this at least a year, this isnt new to me. I did exactally what the PDF told me to do, and still, no good.

escort_ford84

SCREW IT NEW DAM! THREAD. Its easier to sift threw post of a certain thing than to wallow throw pools of them of poeple doing what has already been done before.

escort_ford84

Im not sure, but this thread must be old, i feel ive opened up a can of worms that was long forgoten or has been taken care of by later technology. I have yet to "see" this m6811 disassembler do anything that it hasnt done already. But, i believe i am beyond the disassembly point since CATS cross Disassembler did it for me, in hopes that there is some kind of reference i can apply to this disassembled information. Still, i believe there is something missing, something that no one has mentioned yet. So far, garbage.
Z69, so far to me, it looks like youve disassembled once again (165 ecu) that has already been disassembled, thats nuthing new so far, what youve done was followed someone elses disassembly, you and i have done the same thing. lets move on

Cobra289

You took my attention “Ford Escort” not because what you are trying to do, is interesting, but because of you “Behavior”
You are telling here to “well respectable people” (not me) that they do the easy way.
At the same time you ask them to help, because according to you it should be the hard way.

I have found in my life that “Knowledge shared with others will result in progress”
But at the end of the day it is “DIY” and after that you can “share it”

“dimented24x7” has point you for the next:
You found that your ID is $03
You also found that PROM Addr is: $3000 (PROM offset: $3000)
http://www.cruzers.com/~ludis/idxref.html

At the same page you can compare with the value of the ID $6E that is $C000

So the question is:
Why you put at your text file “load C000” if you know that your algorithmic start at “3000”?
Would not be the right way “load 3000”?
(This was mentioned at the thread for Dummies “You need to put there the correct “org.” of your bin”) it is just details!

This is just and small thing to point, that has been done via the easy way.

I hope that this help you to find the next step!

Please don’t make a mess with all the threads! And think if it took others “years” to solve their problems, why should be your problem solved in a couple of days?
Respect them, the people that want to share it, hope that a day you will share with others too.

Regards,
Cobra289

Z69

Well said Karel.

As far as I did it the "easy way"...
Here's a few quotes of myself from this thread. -and I said I wouldn't quote myself online!!!!
And just to prove to myself that I had it figured out.
I went and dis'd the $58 afterward w/o looking at a hac!

Like I said in other posts - you need to know what the ecm does on a power up. It doesn't matter what the mask is because an ecm may run several different masks. And as I said in another post- you need the rom data to make a c3 work. It doesn't matter how many times you read this stuff. You have to go DIY at some point. Whether it's a C3 bin or a P4 bin.
Understanding what's going on is what takes the time. Otherwise you could simply copy the indirects & first entry from a different mask and start working through it.
You have to remember. When we did this there wasn't a public 8D bin that would assemble. Only C3 & 165 bins. This thread lead to a relocatable aujp bin being made public. Once you get this all figured out you'll understand what a big time saver that is. Well actually you already can see that... I currently have vehicles that run on $6E, $8D, and $OD masks. I wouldn't even think of doing that if it wasn't for the fact that all 3 have commented relocatable assemblies posted. The AUJP hac took over 165 hrs to cut and paste the comments and fix obvious to an amatuer errors. Think on that for a while along with your "take the easy way" comment. -and we are still fixing comment errors a few years later-

M6811 works just fine in XP or 98SE. Or DOS 6.22. It's just a matter of getting your OS to work with M6811. I did the $58 on a 266 running 98SE with 64m of ram. Took less than an hour since I'd already done two 8d bins as practice to perfect my methodology of finding the clumps. Having a good text editor is a big time saver in this hobby. So is picking out the obvious as well as not so obvious hints that people will give you. You could be getting "silence" instead. I throw my "fits" offline and then try to ask the question a different way. Or simply put that issue on the back burner until I have sufficient knowledge to solve that problem. It took JP and I over a year to figure out the I/O control. And what little help we got left us sitting at the keyboard going "huh????" It eventually clicked. And we immediately fell into a ram access issue that took us another 6 months to figure out.

giszo

I am using the DHC11 disassembler and looking at the code seeing a lot of "JR" instructions but could not figure out what it is as the reference manual does not have this kind of instruction.

Is this the JSR instruction?