Help locating Ghidra code that performs parameter substitution for function pointer variables.

[Wall-AF]

I have a variable of type mixMessage * *32 which is an iindirect pointer to a function WORD mixMessage(int wDevID, WORD wMsg, WORD , DWORD dwParam1, DWORD dwParam2, DWORD , ulong ), however I'm trying to find where in Ghidra's code the parameters are assigned there stack locations. Can anyone advise (@caheckman, @emteere ...)?

In the past I've added code to stack function parameters from left-to-right (PASCAL calling convention - used in 1990's Windows applications), but I've noticed recently that Ghidra seems to be ignoring my updates. I'm assuming that in cases of using function pointer variables (see example below) code other than that in the PrototypeModel class is being used!

      eVar2 = (**ppfnMixMessage)(CONCAT22(uVar3 & 0xff,0x801),
                                 CONCAT22(nStructSize,(int)((ulong)pMixCaps >> 0x10)),
                                 (long)pMixCaps << 0x10,0,0,0,0);

I can see that dispite the prototype parameter saying 3 times 2-bytes followed by 4 times 4-bytes using my calling convention, Ghidra is using 4 times 4-bytes followed by 3 times 2-bytes. (I've verified this by reversing the parameters and changing the calling convention.)

[Wall-AF]

There's also an issue when the pointer in mixMessage is increased to match the number of bytes actually used to represent it. So when the definition is mixMessage *32 *32 Ghidra produces:
eVar2 = (**ppfnMixMessage)());
completely ignoring the parameters altogether!

FYI, I've since discovered that the datatype is actually an array of 4 structs, each 8-bytes and located in the data segment. The structure is:

typedef struct tag_MMMXR_Data {
    mixMessage *32 pfnMixMessage;
    int nResult;
    HDRVR hdrvr;
} MMMXR_Data;

It is referenced by this assembly:
1000:02c9 ff 9f 10 00 020 CALLF DS:[BX + 0x10]
which, when I add the manual reference to the first structure (MMMXR_Data_0x_t) in the assembly becomes
1000:02c9 ff 9f 10 00 020 CALLF DS:[BX + g_MMMXR_Data]
however there's no change to the C Ghidra produces! This still looks like:
pMMXDat = (MMMXR_Data_0x8_t *)((nLoc >> 8) * 8 + 0x10);
instead of something akin to:
pMMXDat = &g_MMMXR_Data[nLoc];

Clearly something's awry here!