From finger jujitsu, I'd think MCA will do Basic, synch, extended
transfers based on the negotiation that the adapter does with the DMA
[?] controller.

It might be the only weg you'll get variances is on the built-in
functions [like CD_CHRDY or whatever]. It might be the variances are
hardwired into the adapter and planar/sysboard.

You might not be able to break out of the system, but a deeper
understanding will help you abuse the system...

Kevin Moonlight wrote:
> 3. what decides the basic and syncronous cycle times on a planar,

https://www.ardent-tool.com/tech/MCA_Data_Transfer_Procedures_Basic.html

MCA - Basic Transfer Procedure
Default Cycle (≥200 ns)
Synchronous Extended Cycle (≥300 ns)
Asynchronous Extended Cycle (≥300 ns)

Louis Ohland wrote:
> Kevin Moonlight wrote:
>> 3.  what decides the  basic and  syncronous cycle times on a planar,

Whether a default, a synchronous-extended, or an asynchronous-extended
cycle is performed depends on how a slave uses CD CHRDY.

A default cycle occurs when a slave does not drive CD CHRDY inactive.

A synchronous-extended cycle occurs when a slave drives CD CHRDY
inactive, then releases CD CHRDY synchronously within the specified time
after the leading edge of -CMD. The slave provides the read data within
the specified time from -CMD active.

An asynchronous-extended cycle occurs when a slave drives the CD
CHRDY inactive, then releases CD CHRDY asynchronously.

Louis Ohland wrote:
> https://www.ardent-tool.com/tech/MCA_Data_Transfer_Procedures_Basic.html
>
> MCA - Basic Transfer Procedure
>    Default Cycle (≥200 ns)
>    Synchronous Extended Cycle (≥300 ns)
>    Asynchronous Extended Cycle (≥300 ns)
>
> Louis Ohland wrote:
>> Kevin Moonlight wrote:
>>> 3.  what decides the  basic and  syncronous cycle times on a planar,

I believe Texelec is currently very deep in Command X16 land. If anything I come up with / stumble onto actually has any value I am sure it will make it into the various cards. My OPL hackification is purely a reprogram of the CPLD. My interrupt hackification does currently have one tiny easy bodge wire. If you use a yellow one it is approved by IBM corporate.

On Friday, 7 July 2023 at 09:17:47 UTC-4, Ryan Alswede wrote:
> >> Texelec card is the market leader
> Are you in talks with Texelec to add these fixes to their card? All of the above is for not if it can't get into a "production" card for people to use.
>
> Would be in interested in having one of their cards again if it can actually play Raptor and maybe others with your work around.

Something similar like your TSR could have been done before.
I was just fiddling with my ChipChat, which is SB compatible and generally a similar ISA-to-MCA conversion, when I noted that DOOM crashes at startup with the known stack overflow.
Then on the Install Disk 1 I found DOSMIXER.EXE and DOSMIXER.DOC, which suggests:
"DOSMIXER -M15 -F10 -W15 -I0 -G
same as previous example, Except also sets up the sound card
for the "special game" setting.

Some DOS games require the sound card to be initialized to a
special state. If you encounter any issues running a DOS
game run the "DOSMIXER" with the "-G" option. Games like
"DOOM" and "HERETIC" require this setting. Games such as
"Rise of the Triad" do not. For the games that require the
"-G" option, we suggest you put the DOSMIXER statement in
a batch file to run the particular game."

After running DOSMIXER -G, DOOM starts fine.
OPL3 sound (internal FM synth) is still distorted due to the other thing you found out, but the external wavetable is just fine.
I didn't look into DOSMIXER.EXE through the disassembler goggles, but it might do something similar and was probably forgotten about.

For Raptor though, it does not clear the startup issues, the SB remains "undetected".

On Monday, 17 July 2023 at 08:55:10 UTC-4, Christian Holzapfel wrote:
> Something similar like your TSR could have been done before.
> I was just fiddling with my ChipChat, which is SB compatible and generally a similar ISA-to-MCA conversion, when I noted that DOOM crashes at startup with the known stack overflow.
> Then on the Install Disk 1 I found DOSMIXER.EXE and DOSMIXER.DOC, which suggests:
> "DOSMIXER -M15 -F10 -W15 -I0 -G
> same as previous example, Except also sets up the sound card
> for the "special game" setting.
>
> Some DOS games require the sound card to be initialized to a
> special state. If you encounter any issues running a DOS
> game run the "DOSMIXER" with the "-G" option. Games like
> "DOOM" and "HERETIC" require this setting. Games such as
> "Rise of the Triad" do not. For the games that require the
> "-G" option, we suggest you put the DOSMIXER statement in
> a batch file to run the particular game."
>
> After running DOSMIXER -G, DOOM starts fine.
> OPL3 sound (internal FM synth) is still distorted due to the other thing you found out, but the external wavetable is just fine.
> I didn't look into DOSMIXER.EXE through the disassembler goggles, but it might do something similar and was probably forgotten about.
>
> For Raptor though, it does not clear the startup issues, the SB remains "undetected".

Certainly interesting. I am not sure it is a TSR? It sounds like it may be updating configuration registers on the card. I would have to look at the ESS1688 datasheets more closely and see if this is related to their extended or compatibility modes. Just scanning it quickly was interesting to see the topic of a fifo and interrupt on half full/empty signal, a solution I arrived at on an early prototype of my PCMCIA SoundBlaster that has to emulate DMA in a way compatible with games, given that PCMCIA (mostly) has no DMA signals.

Put it on my list to check out dosmixer see if it is just setting registers within ESS1688 or staying resident and doing some magic.