ranga83 wrote:4tad is a 2 bank eecv. Unique australian bin. Dereks says the files are 88kb. However the files i have got from an IDS are 112kb.
The first bank holds the calibration id and ford copyright along with the ram addresses afaik. The 2nd bank has the code and parameters.
ranga83 wrote:There is no information in bank 1 other than the copyright and calibration id. Located at 0x19f00 and bank 8 starts at 0x22000
Pym wrote:Interruption vectors tell it is a 8065, but if you look at code, it is clearly not, it is a late 8061.
Pym wrote:I will do something to manage it
ranga83 wrote:the 4tad is the first aussie eecv 104pin ecu. the next model car went back to the 60pin ecu but was still "eecv" .
The 4TAD ecu is an eec-v, it is just not using the 8065 in memory expansion mode.Pym wrote:this is an EEC IV 8065 pilot, relabeled EEC V.
sailorbob wrote:The 4TAD ecu is an eec-v, it is just not using the 8065 in memory expansion mode.
Can the text output file name be saved in the s6x file so that the text file is tied to a binary file.
Free selection of a new S6x File
Another minor feature request, the called/jumped from address next to or near the subroutine is handy in the output file.
I realise it could get messy when called/jumped from multiple places. Maybe a line/s directly below the SubName and before code line/s.
[d00], [c80], d006, ... addresses
Ok, I see Calibration Init. It would be nice to see the R and its value in the tree somewhere.
4TAD and other 8065 2 banks with fake Bank 1
Pym wrote:Can the text output file name be saved in the s6x file so that the text file is tied to a binary file.
=> No valid proposal for now, except managing an history of used files
Waiting ...
jsa wrote:Hmm, yes, the one strategy multiple binaries conundrum. I do not see how to save to a Strategy_Name_I_choose.s6x. Always seems to save to Name_of_Bin.s6x.
With a 1_Startegy_All_Bins.s6x, multiple text file entries could be the solution.
GHAJ0 > CARD > CARD_Some_Name.txt
GHAJ0 > ANTI > ANTI_Some_Name.txt
Pym wrote:jsa wrote:Another minor feature request, the called/jumped from address next to or near the subroutine is handy in the output file.
I realise it could get messy when called/jumped from multiple places. Maybe a line/s directly below the SubName and before code line/s.
=> No valid proposal for now, except an Html output with Hyperlinks (but who will work on it ?)
The 8065 defaults to ROM bank 8 on power up and reset. Calibrations that have data in other banks use the Memory Bank Select Register at 0xn0011 to redirect the addressing and set this register as one of the first things done in the code.Pym wrote:Calibration elements in Bank 8 (pointers are accessed by default on Bank 1 on all 8065 binaries)
sailorbob wrote:The 8065 defaults to ROM bank 8 on power up and reset. Calibrations that have data in other banks use the Memory Bank Select Register at 0xn0011 to redirect the addressing and set this register as one of the first things done in the code.
decipha wrote:i think hes referring to bank 1 not needing a banksel for loading data
jsa wrote:Not valid or missed?
Did you see this? Validity issues?
HTML just adds a layer of unnecessary complexity.
In register 0xn0011 the lower nibble determines the ROM bank to use for data reads (program flow is controlled by the ROMBNK instruction). I believe the upper nibble may indicate which RAM bank the stack is located in.Pym wrote: never paid attention at "b1,11,11" operation. If it had been "b1,01,11", probably.
sailorbob wrote:In register 0xn0011 the lower nibble determines the ROM bank to use for data reads (program flow is controlled by the ROMBNK instruction). I believe the upper nibble may indicate which RAM bank the stack is located in.
Pym wrote:Html is the best solution to display or hide information on demand,
but I see no one here, wanting to work on a disassembly outside a text editor,
at least this is the case for me.
Pym wrote:Call 1000(); is still not managed, I do not understand it.
bcc1: a3,01,00,0d,14 ldw R14,[d00] R14 = CC_PRESENT; # Called from L2085
bcc6: 99,2a,15 cmpb R15,2a # [RD00]=0x2A=Engineering Console Present
bcc9: d7,3b jne bd06 if (R15 != 2a) goto bd06; # Console Not Present goto LBCEC
bccb: 3c,24,1e jb B4,R24,bcec if (B4_R24) goto bcec; # Bit4 of R24 Set 1 at L2082. L2085 Calls LBCC1
bcce: 38,0a,1b jb B0,Ra,bcec if (B0_IO_STATUS) goto bcec; # HSO PORT CAM or OUTPUT HOLD BUFFER FULL goto LBCEC
bcd1: 47,01,0e,20,06,7c ad3w R7c,R6,[200e] R7c = IO_TIMER + CC_EXE_TIME;
bcd7: d7,02 jne bcdb if (IO_TIMER == CC_EXE_TIME) {
bcd9: 07,7c incw R7c R7c++; }
bcdb: a0,7c,0e ldw Re,R7c HSO_TIME = R7c;
bcde: b1,0f,0d ldb Rd,f HSO_CMD = f;
bce1: c9,ec,bc push bcec push(bcec); # Push 0xBCEC on to stack
bce4: ad,04,30 ldzbw R30,4 R30 = (uns)4; # Load Word R30 with Byte 0x04
bce7: cb,31,b4,bc push [R30+bcb4] push([R30+bcb4]); # Push on to stack BCB4+4=BCB8=E006
bceb: f0 ret return; # Return to L2088 otherwise LE006 for Engineering Console present
bcec: a3,01,80,0c,14 ldw R14,[c80] R14 = [c80]; # Jump from LBCC9 if console not present or Jump from LBCCB if B4 R24 Set 1
bcf1: ad,04,30 ldzbw R30,4 R30 = (uns)4; # Load Word R30 with Byte 0x04
bcf4: a3,31,a8,bc,42 ldw R42,[R30+bca8] R42 = [R30+bca8]; # R42=4+BCA8=BCAC=1000
bcf9: c6,42,00 stb 0,[R42] [R42] = 0; # Store 0x00 into address 1000
bcfc: 36,14,07 jnb B6,R14,bd06 if (!B6_R14) goto bd06; # B6 of [c80] clear 0 so goto LBD06
# Default [c80] at startup likely to be 0x00
bcff: a3,31,ae,bc,14 ldw R14,[R30+bcae] R14 = [R30+bcae]; # B6 of [c80] Set 1 so R14=1200
bd04: 20,04 sjmp bd0a goto bd0a;
bd06: a1,22,20,14 ldw R14,2022 R14 = 2022 ; # From LBCFC. R14=2022=C000
bd0a: 3c,24,01 jb B4,R24,bd0e if (B4_R24) goto bd0e; # B4 R24 Set 1 at L2082. L2085 Calls LBCC1
bd0d: fb ei enable ints; # B4 R24 Clear 0 so enable interupts
bd0e: a1,f0,00,18 ldw R18,f0 R18 = f0; # Jump from BD0A
bd12: b3,01,20,20,1a ldb R1a,[2020] R1a = [2020];
bd17: a2,15,1c ldw R1c,[R14++] R1c = [R14++];
bd1a: c2,19,1c stw R1c,[R18++] [R18++] = R1c;
bd1d: e0,1a,f7 djnz R1a,bd17 R1a--;
if (R1a != 0) goto bd17;
bd20: 3c,24,34 jb B4,R24,bd57 if (B4_R24) goto bd57; # B4 R24 Set 1 at L2082. L2085 Calls LBCC1
bd23: a3,01,00,0d,14 ldw R14,[d00] R14 = CC_PRESENT; # Check for console again
bd28: 99,3b,15 cmpb R15,3b # Checked against 0x2a at LBCC6 now against 0x3b ??????
bd2b: d7,03 jne bd30 if (R15 != 3b) goto bd30; # Console not "3b"
bd2d: ef,d0,52 call 1000 1000(); # Console is "3b". At LBCF9 1000()=0x00.
# What has console done with 1000() or
# what does Call do with 0X0000
sailorbob wrote: Address 0x1000 is the 'lansdale_tester_entry' which I'm guessing is another development device or test device (there's reference to it in the LHBH1 strategy document).
motorhead1991 wrote:Another neat feature would be to be able to export a SAD dir, so the two stay in sync as coexisting programs.
4321: 57 byte # Bin 1010111
4321: 57 byte # O/P Hi, No Int, Ch7
jsa wrote:I have a couple more feature requests;
Hex to Binary value output option for the listing file
- Code: Select all
4321: 57 byte # Bin 1010111
Or take it 1 step further, HSO for example
- Code: Select all
4321: 57 byte # O/P Hi, No Int, Ch7
Default name for elements with the location address as the suffix rather than sequential numbers. Sub2000 rather than Sub0001.
8 4959: 71,fd,e7 an2b Re7,fd Re7 &= fd;
8 495c: 21,86 sjmp 4ae4 goto Sub0114;
Sub0100:
8 495e: 28,24 scall 4984 Sub0101();
8 4960: d7,03 jne 4965 if (%P2% != %P1%) goto 4965;
decipha wrote:any chance of an update to this?
I can post my rzasa disassembly and current rzasa xdf. If you could use that as a master template it should have every PID just about mapped out. I even included parameters in my rzasa xdf at the bottom that arent part of rzasa but are used in older strategies to make it easier.
I even have a ~ on parameters in rzasa that change equation in older strats too. I use rzasa as my master template for every def I make so I always keep RZASA as complete as possible as a master database of all ford PIDs. It just makes it easier for me so I dont have to keep track of everything.
also any chance of you doing code matching in the disassembly? using rzasa as a base 95% of the code is identical between most 4 bank eec-v's, it would save me thousands of hours going through each one. If the disassembler could match the code and apply the pid names based on the known names in the rzasa disassembly it would make it completely automated.
Also another big thing, if it exports the PIDs in the xdf file in order by memory address, that would save a bunch of time and confusion not to mention make it better organized and easier to fix problems.
How do you handle parameters that are nested in code vs base+offset look ups?
Return to Programming & Coding
Users browsing this forum: No registered users and 1 guest