[mpaton]

ender11 - From your binary, this is what my auto disassembler produced, with no guide instructions at all.

And just for comparison purposes, here's what mine produced in a couple of my idle hours. The coding convention style is obviously not usual US Ford, and I'll admit to being careless with some of the function names, so they may be incorrect. I didn't find the ROLAV functions, nor the HSO table nor the error code list before running out of time. But I'm sure they are there.

[tvrfan]

mpaton - that's a great listing - especially if it's automatically produced.

I see I have some serious competition !! I'm not going to talk anymore !!! (joking)

We obviously had pretty much the same ideas. I added the 'C' like code with naming etc, because I personally found it easier to understand the subroutines and arithmetic used. The binary scaling takes a bit of time to get your head around too....

your tables and functions are better than mine I see. That was going to be my next iteration.

onward and upward !!

[mpaton]

mpaton - that's a great listing - especially if it's automatically produced.

I see I have some serious competition !! I'm not going to talk anymore !!! (joking)

We obviously had pretty much the same ideas. I added the 'C' like code with naming etc, because I personally found it easier to understand the subroutines and arithmetic used. The binary scaling takes a bit of time to get your head around too....

your tables and functions are better than mine I see. That was going to be my next iteration.

onward and upward !!

No, mine does nothing without a dir file. I think we had the same goals all right, code and data visualization, but I about tripled the number of available directives for common constructs. I also prefer looking at hex numbers, so presentation in decimal was low on the priority list, although post processing the assembly output would likely be my way of doing that. A chance to improve my perl skills I expect.

I worked on aircraft flight simulators around 1978 using binary scaling, so it wasn't so strange.

The basics of that listing took about 20 mins. Mostly it's a matter of recognizing what should be there, and partly a matter of having disassembler directives that can remove the tedium of, for example identifying the functions and tables. However my algorithms for doing that are quite conservative, as I abhor false positives. So I did have to add about 7 function/table directives.

To do that completely automatically in most bins requires a fairly deep understanding of how the processor works, which I wasn't averse to learning, but it took a while.

[sailorbob]

The 8065 has 4 register banks, or more accurately, internal memory regions which can be mapped in a way as to be addressable as registers. These are the address ranges:
0x000-0x0FF, 0x100-0x1FF, 0x200-0x2FF, 0x300-0x3FF.

I've never been sure whether the upper two address ranges are registers or just ram residing in the 8065.

Additionally, I believe it is the SFR at 0x0A, bit 4 which enables this selection of any ROM Banks at all.

I think bit 4 is used for enabling the expansion ram memory (0x1E000 – 0x1FFFF).

When the redirected code execution encounters the RET instruction for the return address of the original bank code it causes a return to the original bank.

I disagree.

The ret instruction does NOT cause any bank manipulation. That can only be done by means of the SFR (Special Function Register) 0x11, or by the PSW.

The POPP instruction before the RET instruction is used to cause the return to the original bank.

I disagree. It does not default to any bank at all, which is why you will see the initialization code set up a bank, which will indeed usually be bank 1, presumably according to Ford coding conventions.

If your assertion that the SFR at 0x0011 is correct about it only being for rom bank selection then this would be true. However, this brings us back to wondering what bits 4 to 7 of this SFR are used for though.

I have seen some of these bins, and while they do not make use of all the Ford coding conventions usually seen on US bins, I do not believe the underlying 8065 processor is any different.

May be this would suggest that the 8065 always defaults to bank 8 when reading a rom address when considering the above.

[tvrfan]

[edited] No, mine does nothing without a dir file...... I also prefer looking at hex numbers ...
A chance to improve my perl skills I expect....
I worked on aircraft flight simulators around 1978 using binary scaling, so it wasn't so strange.
To do that completely automatically in most bins requires a fairly deep understanding of how the processor works, which I wasn't averse to learning, but it took a while.

I *love* perl. It's concise, and regular expressions are simply gorgeous. On the other hand it obfuscates too easily and can be dangerous without care. I wrote a stack of stuff for database management under UNIX, it's much easier than shell script. I've done a lot of 'C' , perl, shell script on the side (and older languages), but really I'm a DBA/data architect for my sins. Got into this becuase I was intrigued how Ford (and GM) coded their boxes. Also doing some stuff on a Holden Commodore (-> Buick V6 3.8 engine)

Anyway - my tool produced that first listing without any .dir file. It starts at 0x2000 and tracks jumps and subr calls to work out where the next code segment is, and on the way tracks data accesses by instructions. It also looks at 'specials' like pushw to try to decide if there's a 'task list' of subroutine addresses. It also has a 'signature' map to try to pick out the table routine and the word and byte 'functions' (as call them) typically used for scaling. It then tracks what addresses are set up for each marked subr call. It's pretty good now, but still is some way from perfect. I agree it's VERY hard to eliminate false positives whilst still getting all the real data out.

[tvrfan]

ender11 - here is a part updated listing, with tables etc tidied up, and some names added where I'm (reasonably) sure what they do.

I was able to cheat by using my 'AA' code to find some of the table functions, and then to be able to tell what AD channel the VAFs, temp sensors are. I see the subroutine for doing timers is the same except for the first timing divsion, so your CPU probably runs at a different speed, which I'll do the maths on later....more to do yet.

I reckon I have the main ignition timing tables, need to check how they are used, but probably one is cold running one is hot, or may be standard petrol and premium (that's typically what the US ones do)

I'll add some comments too.

[ender11]

ender11 - here is a part updated listing, with tables etc tidied up, and some names added where I'm (reasonably) sure what they do.

I was able to cheat by using my 'AA' code to find some of the table functions, and then to be able to tell what AD channel the VAFs, temp sensors are. I see the subroutine for doing timers is the same except for the first timing divsion, so your CPU probably runs at a different speed, which I'll do the maths on later....more to do yet.

I reckon I have the main ignition timing tables, need to check how they are used, but probably one is cold running one is hot, or may be standard petrol and premium (that's typically what the US ones do)

I'll add some comments too.

nice! I'll check crystal frequency tomorrow. the box shouln't have "standart" or "premium" tables, it must work on 95 octane fuel (it's what called "82 octane" in us, afaik). it also have two inputs for setting spark retard of 3 and 6 degrees. and one input for increasing idle rpm. I'm going to receive .bin from the same engine, but with speed density inj setup. It may be interesting to compare them.
anyway, it's wery interesting project. have you thought on introducing some "unitary" (text) format to describe procedures?

[mpaton]

Additionally, I believe it is the SFR at 0x0A, bit 4 which enables this selection of any ROM Banks at all.

I think bit 4 is used for enabling the expansion ram memory (0x1E000 – 0x1FFFF).

That is possible, but I have seen this bit set on 2 bank 8065 bins which do not use RAM in that range. Additionally, my small experience with processor design makes me think it unlikely that the 8065 restricts memory in that range to a single bank.

When the redirected code execution encounters the RET instruction for the return address of the original bank code it causes a return to the original bank.

I disagree.

The ret instruction does NOT cause any bank manipulation. That can only be done by means of the SFR (Special Function Register) 0x11, or by the PSW.

The POPP instruction before the RET instruction is used to cause the return to the original bank.

The statement about the POPP I do agree with; it manipulated the PSW. What I was disagreeing with was your earlier statement above that it was the RET instruction that caused the bank switch.

I have seen some of these bins, and while they do not make use of all the Ford coding conventions usually seen on US bins, I do not believe the underlying 8065 processor is any different.

May be this would suggest that the 8065 always defaults to bank 8 when reading a rom address when considering the above.

I believe it probably does.

[sailorbob]

I looked at an output substitution control routine last night that uses the SRF at 0x0011 along with the PSW contents and it does appear that the SFR is for rom bank selection. Bits 11-14 of the SFR hold the rom bank number of the routine that called the OSC routine and this gets used to set the SFR so that in-line data can be pulled from the calling routine.

[tvrfan]

nice! I'll check crystal frequency tomorrow. the box shouln't have "standart" or "premium" tables, it must work on 95 octane fuel (it's what called "82 octane" in us, afaik). it also have two inputs for setting spark retard of 3 and 6 degrees. and one input for increasing idle rpm. I'm going to receive .bin from the same engine, but with speed density inj setup. It may be interesting to compare them.
anyway, it's wery interesting project. have you thought on introducing some "unitary" (text) format to describe procedures?

I have a comment mechanism for the text - I haven't commented much as yet, but all suggestions welcome, It's still a work in progress....have a look at the AA for much more description - some of your subroutines do the same job. Speed density for same or similar engine would be very interesting to compare.

By the way, discovered from the Timer routine that your c2b code has the ability to run at 7.5 Mhz or 12 Mhz, which explains some of the number fiddling with RPM. It also appears to be able to run a 4 cyl or a 6 cyl engine (set by individual bits in the ROM). The spark tables I reckon are now HOT and COLD, and the code interpolates between them (which is what my AA box does too), but the later code seems more sophistcated. No suprise there.

I am still looking at this code - it interests me anyway as it's effectively a later version of my box's code.

Spotted the grounded wires input (which is same as AA as well) but it seems to be set to 4 and 6 degrees, not 3 and 6. Thanks for the info on idle speed too.

-- and I haven't forgotten the 8065 discussion, I'm just listening right now....

[ender11]

have a look at the AA for much more description - some of your subroutines do the same job. Speed density for same or similar engine would be very interesting to compare.

By the way, discovered from the Timer routine that your c2b code has the ability to run at 7.5 Mhz or 12 Mhz, which explains some of the number fiddling with RPM. It also appears to be able to run a 4 cyl or a 6 cyl engine (set by individual bits in the ROM). The spark tables I reckon are now HOT and COLD, and the code interpolates between them (which is what my AA box does too), but the later code seems more sophistcated. No suprise there.

I am still looking at this code - it interests me anyway as it's effectively a later version of my box's code.

Spotted the grounded wires input (which is same as AA as well) but it seems to be set to 4 and 6 degrees, not 3 and 6. Thanks for the info on idle speed too.

-- and I haven't forgotten the 8065 discussion, I'm just listening right now....

Yes, I've seen your AA listing -- a real masterpiece!
Opened my box today, it is 7.5MHz quartz inside.
that's my mistake for 3 and 6 degrees. manual says 4 and 6.
I also made som photos of the inside of the box:
http://www.redom.ru/img/gallery/10803/125574.JPG
http://www.redom.ru/img/gallery/10803/125571.JPG
It's schematics is close to vm-111 module, which is teared apart and reversed here:
http://ford-club.org.ua/board/index.php ... 1060339444
what is interesting to me, it looks like ROM chip has also a functionalty of the input port: notice solder pads close to rom. it is for solder wires or come kind of switch, I beleive.
I wonder what it is for? to switch BAP sensor, EGR, what else?
and, tvrfan, can you please pm me your e-mail?

[tvrfan]

the label on my box says "EEC-IV VM110 85GB-12A650-AA" and then "AA BLUE" in bigger letters..
in case anyone has any other useful info (like hardware schematics etc)

[tvrfan]

well, I've already discovered an improvement over my old 'AA' box carried out in the 'C2B', and as a long time programmer/developer comparing the two are are fascinating already.....

Listing attached of where I'm up to - not had much chance to go through in detail, will spend some more time soon.

I see that the injection output routine in the C2B has been changed and tidied up, but what strikes me is -
The AA code, when engine over the rev limit simply stops all outputs to injectors - but c2a shows that it's actually possible that AA box can leave one or both injector banks ON, (very bad !!) whereas the C2a keeps sending OFF commands, which is much safer. The C2A doesn't seem to have a hard rev limit either, as a timer is involved...