EEC V file conversion

[BOOSTEDEVERYTHING]

Another possible bug? 81F1C is not a valid address, so I assume line 8f7dc is disassembled incorrectly?

Code: Select all

8f7d7: 99,f2,34           cmpb  R34,f2           
8f7da: d7,03              jne   8f7df            if (TMP1L = f2)  {
8f7dc: ef,3d,27           call  81f1c            81f1c (); } } }
8f7df: 71,ef,90           an2b  R90,ef           RAMINIT_Flg = 0;
8f7e2: f0                 ret                    return;

[jsa]

81F1C ...is not a valid address?

Code: Select all

8f7dc: ef,3d,27           call  81f1c            81f1c (); } } }

Search the three manuals for console and look at the allocation of RAM addresses in those and the handbook.

1F1C is a console address. Once a connected console is confirmed, code in the console address space is executed.

Insufficient information in your post to determine anything else.

It gets 'interesting' in FM20M06, which is an unusual multi bank strategy.

Code: Select all

83530: b3,01,1c,1f,34     ldb   R34,[R0+1f1c]    R34 = [11f1c];
83535: 99,f2,34           cmpb  R34,f2           
83538: d7,03              jne   8353d            if (R34 = f2)  {
8353a: ef,df,e9           call  81f1c            81f1c (); } } }

[BOOSTEDEVERYTHING]

Ok. I’ll give it a look. I guess that makes sense that that subroutine would point to the console at some point.

[tvrfan]

Have a look in the Ford handbook (via https://github.com/OpenEEC-Project/Usef ... C_handbook) Near the end, (section H) there are a set of memory maps. You can see there are several 'reserved' address and ranges of addresses defined for cal console and related stuff.

Unfortunately, the code listings don't always show the same addresses being called/checked for cal_console and special chips, so I haven't built them into SAD. The details differ a little too. The good news is that the overall address range of 0x1800 to 0x1ffff DOES seem to apply to all bins, and especially 0x1f00 to 0x1fff, how the banks map onto these isn't clear either (jsa above), some seem to call bank 8, some call bank 1 (?). So if you spot something around those addresses (ignoring the bank), it's probably a plug-in console.

What we can work out is that the cal console announces it's there in one address, and then ROM in the cal console itself is CALLed as if it was just another subroutine. This allows extra functions in the cal console to be run by the CPU, and gives cal console full access to everything the CPU can see. It also seems to be a standard technique in all bins.

You can see the special add-on chips (page H4) also have different address range options too. I think these turn up in bank 1, but not sure...

Hope that helps !!

[jsa]

I reckon the cmpb 34,f2 is looking to see if opcode F2 PUSHP, typical start of a sub, is at 1f1c, and if true call it.

[tvrfan]

could be true - earlier bins tend to check a flag somewhere else, but checking for PUSHP at call address is just as good I reckon.

[jsa]

Thinking about the EEC-IV boxes, the ones I have don't have connections for BS0 & BS3 lines. So the console may not care about banks at all. Depends on what updates were made to the console hardware as the years rolled by.

[BOOSTEDEVERYTHING]

So….is the quarterhorse basically being used by the pcm as a Cal Console?

[decipha]

not rly, cal console uses the on board eeprom and loads alternate calibration values by rerouted the pointers to do so

the qh is more of a debugger emulating the entire binary

eec4 doesnt have banks its all bank 8 basically

[jsa]

Yeah, EEC-IV didn't have bank switching...did they bother updating the console to monitor bank select lines though when multibank EEC-V was introduced? I suspect not, at least initially anyway.

I think a nice enhancement could be made to the QH if it were can bus capable and used the console memory space for external can bus sensors. Lots of 3rd party can bus sensors, actuators and gauges available that could be quite useful. QH++ could read and write on a user can bus using console memory space and serve a little user code as well.