https://www.ebay.com/itm/175787923554

looks very professional

No wavetable [yet]

richard smice wrote:
> https://www.ebay.com/itm/175787923554
>
> looks very professional
>

> > looks very professional

The guy who makes them is in the MCA Facebook group.

Many games supported Sound Blaster, yes, but sadly doesn't mean that the MCA bus was supported.

If games is your goal stick with a clone and avoid the disappointment...

what exactly does it mean for a game to support the microchannel bus?

if it supported soundblaster, generally speaking how would it be different to the game on isa vs mca.

On Wednesday, 28 June 2023 at 08:55:57 UTC-4, Ryan Alswede wrote:
> > > looks very professional
>
> The guy who makes them is in the MCA Facebook group.
>
> Many games supported Sound Blaster, yes, but sadly doesn't mean that the MCA bus was supported.
>
> If games is your goal stick with a clone and avoid the disappointment...

Game software were coded and built directly against an ISA bus Sound Blaster so all the ISR (interrupt service routines) DMA (direct memory access) processes are designed for that bus architecture UNLESS the game writer wrote the methods to handle MCA bus architecture the sound cards will fail to produce results in a PS/2.

I had the white clone snarky board you see on eBay before returning it and tried the following games and software:
Simcity (1989) - no sound
Raptor Call of the Shadows - only could get some sound when set to Adlib. Sound Blaster settings, game would not start.
Star Trek Final Unity - PS/2 (Model 90 Pentium60 / Model 77 486DX2) machines would crash/lock up with any Sound Blaster settings, Sound Blaster detection in setup would do the same.
Duke Nukem 3D - No sound.
Duke Nukem 3D Atomic Edition - Had sound, no problems
Windows 98 - Auto detects and installs MS Win 95 driver fine and plays Windows Sounds ok.
Windows NT 4.0 - has popping noise on start and end of Windows Sounds using MS Sound Blaster Driver for NT.

I also own a Sound Piper 16 which uses an ESS688F Sound Blaster compatible chipset. In DOS games above it fairs the same even though the ESS688F ISA version is celebrated in the DOS game world.

If you saw Louis' other post about Sound Blaster/MCV, even they admit that their Sound Blaster software doesn't work on MCA and you have to update to MCA versions of their utilities.

"CAUSE: It is due to the hardware differences in interrupt handling
between the AT bus machine and the Micro Channel machine. Therefore,
Sound Blaster program which is designed for AT bus cannot be used on
PS/2* machine directly"

Interesting, I was not aware compatibility was so poor, I have a snarkbarker mca back when it was released, I had not had a chance to try it out for games. I just dropped in one of my systems and sure enough nothing would work, stack overflow etc due to isr getting called repeatedly.

I made a small modification to the snarkbarker and wrote a quick tsr to operate as the irq police and I can now play my few test games unmodified i.e.. doom... I will have to try some more and see if it is practical solution to games that misbehave. I've been looking at this for all of 1 day so surely I am unaware of most of what is out there to deal with this already.

I have been working on and off on a pcmcia soundblaster compatible card, generally speaking the only one that ever existed was the ibm 3d sound. Through that adventure I have had some exposure to level vs edge interrupts as found on pc cards, so I applied a few of my tricks.

On Thursday, 29 June 2023 at 09:00:59 UTC-4, Ryan Alswede wrote:
> Game software were coded and built directly against an ISA bus Sound Blaster so all the ISR (interrupt service routines) DMA (direct memory access) processes are designed for that bus architecture UNLESS the game writer wrote the methods to handle MCA bus architecture the sound cards will fail to produce results in a PS/2.
>
> I had the white clone snarky board you see on eBay before returning it and tried the following games and software:
> Simcity (1989) - no sound
> Raptor Call of the Shadows - only could get some sound when set to Adlib. Sound Blaster settings, game would not start.
> Star Trek Final Unity - PS/2 (Model 90 Pentium60 / Model 77 486DX2) machines would crash/lock up with any Sound Blaster settings, Sound Blaster detection in setup would do the same.
> Duke Nukem 3D - No sound.
> Duke Nukem 3D Atomic Edition - Had sound, no problems
> Windows 98 - Auto detects and installs MS Win 95 driver fine and plays Windows Sounds ok.
> Windows NT 4.0 - has popping noise on start and end of Windows Sounds using MS Sound Blaster Driver for NT.
>
> I also own a Sound Piper 16 which uses an ESS688F Sound Blaster compatible chipset. In DOS games above it fairs the same even though the ESS688F ISA version is celebrated in the DOS game world.
>
> If you saw Louis' other post about Sound Blaster/MCV, even they admit that their Sound Blaster software doesn't work on MCA and you have to update to MCA versions of their utilities.
>
> "CAUSE: It is due to the hardware differences in interrupt handling
> between the AT bus machine and the Micro Channel machine. Therefore,
> Sound Blaster program which is designed for AT bus cannot be used on
> PS/2* machine directly"

Kevin Moonlight wrote:
> stack overflow etc due to isr getting called repeatedly.

That's uber cringe, like a psycho ex calling repeatedly...

Care to expound on the relentless calling?

Have you ever used SoftIce on Windows 95/98 by chance? (Working on an unrelated project)

> stack overflow etc due to isr getting called repeatedly.
Yes on Model 90 I've filled up the System Log several times in doing game testing. IRQ not serviced errors.

> I made a small modification to the snarkbarker and wrote a quick tsr to operate as the irq police and I can now play my few test games unmodified i.e. doom..
DOS Box has sound blaster code with fixes they've done for compatibly in their emulator, maybe could be applied to the card as well.
https://github.com/dosbox-staging/dosbox-staging/blob/main/src/hardware/sblaster.cpp

I think the card could be so much more with software improvements but texelec admitted they don't know software.

The particular issue with the games I tested that failed, inside of their interrupt handler they were not clearing the interrupt flag on the soundblaster card before returning. On the ISA systems that did not matter, your handler just does not get called again until you clear that flag somewhere else in your code to deassert the irq line and then have it go up again so there is a new edge. With MCA being level based the second you return you are just called again and again if irq line is still high.

So my TSR for all intensive purposes simply ensures that anytime there is an interrupt from the Snark Barker, once the assigned handler is finished I read the soundblaster status port to make sure the interrupt flag is cleared and I also make sure the pic end of interrupt was set just in case. This was not entirely straight forward as these games are not polite and do not seem to check for the existing handler to chain/call after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.

I’ve also now learned that even adlib is not well supported. Even though the Snark should be asserting the chrdy signal for every fm request which I thought got you a minimum of 300ns on all systems. I shall hookup a logic analyzer later to see what is happening for my own understanding I don’t expect to have much to offer here, it would seem the Yamaha chip is just too slow for some systems.

On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
> Kevin Moonlight wrote:
> > stack overflow etc due to isr getting called repeatedly.
> That's uber cringe, like a psycho ex calling repeatedly...
>
> Care to expound on the relentless calling?

MCA Interrupt Procedures
https://www.ardent-tool.com/tech/MCA_Interrupt_Procedures.html

Unfortunately, I don't ken the interrupt circuitry well enough to make
this klar.

Plus, you are describing the failure of the software to handle clearing
the level assertion instead of the one and done ISA edge trigger stuff.

If I can findt a decent description of ISA edge triggered software, I
could compare it to the MCA Interrupt handling...

I'm a doctor, Jim! Not an EE!

Kevin Moonlight wrote:
> The particular issue with the games I tested that failed, inside of their interrupt handler they were not clearing the interrupt flag on the soundblaster card before returning. On the ISA systems that did not matter, your handler just does not get called again until you clear that flag somewhere else in your code to deassert the irq line and then have it go up again so there is a new edge. With MCA being level based the second you return you are just called again and again if irq line is still high.
>
> So my TSR for all intensive purposes simply ensures that anytime there is an interrupt from the Snark Barker, once the assigned handler is finished I read the soundblaster status port to make sure the interrupt flag is cleared and I also make sure the pic end of interrupt was set just in case. This was not entirely straight forward as these games are not polite and do not seem to check for the existing handler to chain/call after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.
>
> I’ve also now learned that even adlib is not well supported. Even though the Snark should be asserting the chrdy signal for every fm request which I thought got you a minimum of 300ns on all systems. I shall hookup a logic analyzer later to see what is happening for my own understanding I don’t expect to have much to offer here, it would seem the Yamaha chip is just too slow for some systems.
>
> On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
>> Kevin Moonlight wrote:
>>> stack overflow etc due to isr getting called repeatedly.
>> That's uber cringe, like a psycho ex calling repeatedly...
>>
>> Care to expound on the relentless calling?

Level-Sensitive Interrupts
http://ps-2.kev009.com/ohland/Interrupts/Level-Sensitive_Interrupts.html

Louis Ohland wrote:
> MCA Interrupt Procedures
> https://www.ardent-tool.com/tech/MCA_Interrupt_Procedures.html
>
> Unfortunately, I don't ken the interrupt circuitry well enough to make
> this klar.
>
> Plus, you are describing the failure of the software to handle clearing
> the level assertion instead of the one and done ISA edge trigger stuff.
>
> If I can findt a decent description of ISA edge triggered software, I
> could compare it to the MCA Interrupt handling...
>
> I'm a doctor, Jim! Not an EE!
>
> Kevin Moonlight wrote:
>> The particular issue with the games I tested that failed,     inside
>> of their interrupt handler they were not clearing the interrupt flag
>> on the soundblaster card before returning.   On the ISA systems that
>> did not matter,   your handler just does not get called again until
>> you clear that flag somewhere else in your code to deassert the  irq
>> line and then have it go up again so there is a new edge.  With MCA
>> being level based the second you return you are just called again and
>> again if irq line is still high.
>>
>> So my TSR for all intensive purposes simply ensures that anytime there
>> is an interrupt from the Snark Barker,  once the assigned handler is
>> finished I read the  soundblaster status port to make sure the
>> interrupt flag is cleared and I also make sure the pic end of
>> interrupt was set just in case.   This was not entirely straight
>> forward as these games are not polite and do not seem to check for the
>> existing handler to  chain/call after.  Some games may have
>> intentionally not been clearing the interrupt flag for some other
>> reason,  these will not be happy.  This is all just  experimentation
>> in fun at this point.  quite a hack.
>>
>> I’ve also now learned that even adlib is not well supported.     Even
>> though the Snark should be  asserting the chrdy signal for every fm
>> request which I thought got you a minimum of 300ns on all systems.
>> I shall hookup a logic analyzer later  to see what is happening for my
>> own understanding I don’t expect to have much to offer here, it would
>> seem the Yamaha chip is just too slow for some systems.
>>
>> On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
>>> Kevin Moonlight wrote:
>>>> stack overflow etc due to isr getting called repeatedly.
>>> That's uber cringe, like a psycho ex calling repeatedly...
>>>
>>> Care to expound on the relentless calling?

https://www.airsupplylab.com/embedded-info/43-emb-software-architecture/177-emd-software-interrupts.html

Louis Ohland wrote:
> Level-Sensitive Interrupts
> http://ps-2.kev009.com/ohland/Interrupts/Level-Sensitive_Interrupts.html
>
> Louis Ohland wrote:
>> MCA Interrupt Procedures
>> https://www.ardent-tool.com/tech/MCA_Interrupt_Procedures.html
>>
>> Unfortunately, I don't ken the interrupt circuitry well enough to make
>> this klar.
>>
>> Plus, you are describing the failure of the software to handle
>> clearing the level assertion instead of the one and done ISA edge
>> trigger stuff.
>>
>> If I can findt a decent description of ISA edge triggered software, I
>> could compare it to the MCA Interrupt handling...
>>
>> I'm a doctor, Jim! Not an EE!
>>
>> Kevin Moonlight wrote:
>>> The particular issue with the games I tested that failed,     inside
>>> of their interrupt handler they were not clearing the interrupt flag
>>> on the soundblaster card before returning.   On the ISA systems that
>>> did not matter,   your handler just does not get called again until
>>> you clear that flag somewhere else in your code to deassert the  irq
>>> line and then have it go up again so there is a new edge.  With MCA
>>> being level based the second you return you are just called again and
>>> again if irq line is still high.
>>>
>>> So my TSR for all intensive purposes simply ensures that anytime
>>> there is an interrupt from the Snark Barker,  once the assigned
>>> handler is finished I read the  soundblaster status port to make sure
>>> the interrupt flag is cleared and I also make sure the pic end of
>>> interrupt was set just in case.   This was not entirely straight
>>> forward as these games are not polite and do not seem to check for
>>> the existing handler to  chain/call after.  Some games may have
>>> intentionally not been clearing the interrupt flag for some other
>>> reason,  these will not be happy.  This is all just  experimentation
>>> in fun at this point.  quite a hack.
>>>
>>> I’ve also now learned that even adlib is not well supported.     Even
>>> though the Snark should be  asserting the chrdy signal for every fm
>>> request which I thought got you a minimum of 300ns on all systems. I
>>> shall hookup a logic analyzer later  to see what is happening for my
>>> own understanding I don’t expect to have much to offer here, it would
>>> seem the Yamaha chip is just too slow for some systems.
>>>
>>> On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
>>>> Kevin Moonlight wrote:
>>>>> stack overflow etc due to isr getting called repeatedly.
>>>> That's uber cringe, like a psycho ex calling repeatedly...
>>>>
>>>> Care to expound on the relentless calling?

I don't see it as a circuitry issue. The majority of issues would seem to be not clearing the interrupt flipply-floppy on the card prior to exiting the ISR, which on ISA means nothing will happen next, whereas MCA means you are going to be right back into your ISR. Even the games that do handle this properly would likely be unfriendly to the interrupt sharing, and that would be an issue I could not see overcoming easily, so for any hope to use soundblaster on microchannel, having a dedicated irq for the card would be good... i think.

I know videos are not received well here... i got some questions, I am still trying to explain what I am doing here. still not entirely sure it is useful or not, need to make a small list of games that people wanted to play but could never get to work with the snarkbarker, and see if I could get them working with my method or not..

https://www.youtube.com/watch?v=1PjLtKcPYI0

On Saturday, 1 July 2023 at 12:59:26 UTC-4, Louis Ohland wrote:
> MCA Interrupt Procedures
> https://www.ardent-tool.com/tech/MCA_Interrupt_Procedures.html
>
> Unfortunately, I don't ken the interrupt circuitry well enough to make
> this klar.
>
> Plus, you are describing the failure of the software to handle clearing
> the level assertion instead of the one and done ISA edge trigger stuff.
>
> If I can findt a decent description of ISA edge triggered software, I
> could compare it to the MCA Interrupt handling...
>
> I'm a doctor, Jim! Not an EE!
> Kevin Moonlight wrote:
> > The particular issue with the games I tested that failed, inside of their interrupt handler they were not clearing the interrupt flag on the soundblaster card before returning. On the ISA systems that did not matter, your handler just does not get called again until you clear that flag somewhere else in your code to deassert the irq line and then have it go up again so there is a new edge. With MCA being level based the second you return you are just called again and again if irq line is still high.
> >
> > So my TSR for all intensive purposes simply ensures that anytime there is an interrupt from the Snark Barker, once the assigned handler is finished I read the soundblaster status port to make sure the interrupt flag is cleared and I also make sure the pic end of interrupt was set just in case. This was not entirely straight forward as these games are not polite and do not seem to check for the existing handler to chain/call after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.
> >
> > I’ve also now learned that even adlib is not well supported. Even though the Snark should be asserting the chrdy signal for every fm request which I thought got you a minimum of 300ns on all systems. I shall hookup a logic analyzer later to see what is happening for my own understanding I don’t expect to have much to offer here, it would seem the Yamaha chip is just too slow for some systems.
> >
> > On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
> >> Kevin Moonlight wrote:
> >>> stack overflow etc due to isr getting called repeatedly.
> >> That's uber cringe, like a psycho ex calling repeatedly...
> >>
> >> Care to expound on the relentless calling?

Kevin, I agree the SB ISR's handling of the level triggered interrupt is
the issue.

Until now, there hasn't been a discussion of the differences between the
PC and PS/2 methods, and leaving the request uncancelled is very likely
the issue.

But I cannot explain it clearly. The two pages are what I got [sort of].

Your masterful and erudite explanation is eagerly anticipated.

Is there a weg to SIMMply test the sound card's ISRs for proper handling
of the ISR? Not to fix it [at this point], but at least identify the
problem?

Kevin Moonlight wrote:
> I don't see it as a circuitry issue. The majority of issues would seem to be not clearing the interrupt flipply-floppy on the card prior to exiting the ISR, which on ISA means nothing will happen next, whereas MCA means you are going to be right back into your ISR. Even the games that do handle this properly would likely be unfriendly to the interrupt sharing, and that would be an issue I could not see overcoming easily, so for any hope to use soundblaster on microchannel, having a dedicated irq for the card would be good... i think.
>
> I know videos are not received well here... i got some questions, I am still trying to explain what I am doing here. still not entirely sure it is useful or not, need to make a small list of games that people wanted to play but could never get to work with the snarkbarker, and see if I could get them working with my method or not..
>
> https://www.youtube.com/watch?v=1PjLtKcPYI0
>
> On Saturday, 1 July 2023 at 12:59:26 UTC-4, Louis Ohland wrote:
>> MCA Interrupt Procedures
>> https://www.ardent-tool.com/tech/MCA_Interrupt_Procedures.html
>>
>> Unfortunately, I don't ken the interrupt circuitry well enough to make
>> this klar.
>>
>> Plus, you are describing the failure of the software to handle clearing
>> the level assertion instead of the one and done ISA edge trigger stuff.
>>
>> If I can findt a decent description of ISA edge triggered software, I
>> could compare it to the MCA Interrupt handling...
>>
>> I'm a doctor, Jim! Not an EE!
>> Kevin Moonlight wrote:
>>> The particular issue with the games I tested that failed, inside of their interrupt handler they were not clearing the interrupt flag on the soundblaster card before returning. On the ISA systems that did not matter, your handler just does not get called again until you clear that flag somewhere else in your code to deassert the irq line and then have it go up again so there is a new edge. With MCA being level based the second you return you are just called again and again if irq line is still high.
>>>
>>> So my TSR for all intensive purposes simply ensures that anytime there is an interrupt from the Snark Barker, once the assigned handler is finished I read the soundblaster status port to make sure the interrupt flag is cleared and I also make sure the pic end of interrupt was set just in case. This was not entirely straight forward as these games are not polite and do not seem to check for the existing handler to chain/call after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.
>>>
>>> I’ve also now learned that even adlib is not well supported. Even though the Snark should be asserting the chrdy signal for every fm request which I thought got you a minimum of 300ns on all systems. I shall hookup a logic analyzer later to see what is happening for my own understanding I don’t expect to have much to offer here, it would seem the Yamaha chip is just too slow for some systems.
>>>
>>> On Saturday, 1 July 2023 at 06:23:26 UTC-4, Louis Ohland wrote:
>>>> Kevin Moonlight wrote:
>>>>> stack overflow etc due to isr getting called repeatedly.
>>>> That's uber cringe, like a psycho ex calling repeatedly...
>>>>
>>>> Care to expound on the relentless calling?

Kevin, videos usually don't have detailed documentation. They are
interesting, but they do have limits.

I have an idea of what you are trying, but I can't explain it. That
bothers me.

Louis Ohland wrote:
> I know videos are not received well here... i got some questions, I am
> still trying to explain what I am doing here.

>> after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.

Try Duke Nukem 3D basic version with your TSR work around for fun. Atomic edition works. Basic 3D does not.

Located here if you don't already have a copy.
https://archive.org/details/duke-3-d

on the topic of duke3d, I have not been able to get any version to crash including the one listed above. I would not say this is conclusive of anything, but it is perhaps potentially maybe might be could be promising... still need to test on some other machines, of which working I have the 50Z with IBM 486 Planar, and the PCServer 500 S/390 which I can pop out to try the soundcard in.

The adlib distortion/jibberish was really bothering me, something so simple having issues. I started trying to understand a bit more. I was measuring the channel ready signal and I would often see what to me were unexpected transitions as I currently understand that every slot has its own channel ready signal, and the system logically or's them together to drive a common channel ready return. I saw the various historic discussions mentioning system speed etc, programs not having delays, the JP5 (channel ready) and it all ending at the :solution: being creatives CQM chip that always responds quickly.

in any case, I thought perhaps asserting the channel ready only briefly was not enough as the default extended cycle varies per system. so I made some changes converting the ready signal to a latch and clearing it some clock cycles later... and then initially I thought it was magic I was hearing near perfect adlib audio, but then I heard a glitch here and there and while 1000% improved something was not right.

I was seeing propagation delays between my test signals I could not explain and then while looking at the hardware I noticed something. My board is all populated with 74HCT family chips. While by itself this would not have jumped out at me, the note from TubeTime is concerning:

"Logic chips are all specified as AHCT, but ALS or ACT may also be used. Do not use LS or HCT devices, particularly for U2, since Micro Channel is a much faster bus than ISA and this logic is not quite fast enough to meet the timing margins. "

So I may be using a unpredictable wildcard here for my testing, I will need to see if this part substitution may be contributing to the adlib issues.. why adlib and not soundblaster? I suppose the dsp commands are by design very slow due to the "inbox/outbox" and status register topology, and during audio playback with DMA this presumably has some differences causing it to not fall victim to a potentially timing tolerance issue of these out of spec chips. no sure.

Another user on the facebook group mentioned the same adlib symptom on some systems, i've asked them where they got the board and when it was made, I may follow up and ask what family the logic chips are. maybe it means nothing.

On Saturday, 1 July 2023 at 22:03:29 UTC-4, Ryan Alswede wrote:
> >> after. Some games may have intentionally not been clearing the interrupt flag for some other reason, these will not be happy. This is all just experimentation in fun at this point. quite a hack.
> Try Duke Nukem 3D basic version with your TSR work around for fun. Atomic edition works. Basic 3D does not.
>
> Located here if you don't already have a copy.
> https://archive.org/details/duke-3-d

> on the topic of duke3d, I have not been able to get any version to crash including the one listed above.
The older version would just not make sound. Did not crash.

See if you can play Raptor Call of the Shadows then. It talks about PS/2 in the readme so there maybe hope. Adlib was the only thing it would do for FX sounds.

DMA is a whole another animal. You have the following to deal with in MCA. These settings were interesting to play with when I was working with the Ultimedia 7-6 card driver.

-Adapters can do burst-mode where it can have complete control of the DMA channel for up to 12mSec.

-MicroChannel Fairness feature, when 'Fairness' is disabled, the adapter will compete for every arbitration phase and will obtain more than its fair share of channel usage but allows for smoother audio play back."

Ryan is correct, but another weg to put it is that in order for an
adapter to BURST, it -MUST- support Fairness, more precisely, be able to
turn Fairness Off.

MCA - DMA Transfer Procedure
https://www.ardent-tool.com/tech/MCA_Data_Transfer_Procedures_DMA.html

It would probably be helpful to buff up the arbitration material, such
that it is...

I am konfuzed with the memory refresh material.

The earlier systems with single path IMHO would be more limited on the
refresh, but the later dual path [90/95] could refresh during ARB/GNT
phase. I am confused. In addition, there is a quick refresh used during
POST, and the longer one used during normal operation. Again, I have NO
documentation..

IBM has the refresh included with a basic transfer, but there ain't much.

Ryan Alswede wrote:
>
>> on the topic of duke3d, I have not been able to get any version to crash including the one listed above.
> The older version would just not make sound. Did not crash.
>
> See if you can play Raptor Call of the Shadows then. It talks about PS/2 in the readme so there maybe hope. Adlib was the only thing it would do for FX sounds.
>
> DMA is a whole another animal. You have the following to deal with in MCA. These settings were interesting to play with when I was working with the Ultimedia 7-6 card driver.
>
> -Adapters can do burst-mode where it can have complete control of the DMA channel for up to 12mSec.
>
> -MicroChannel Fairness feature, when 'Fairness' is disabled, the adapter will compete for every arbitration phase and will obtain more than its fair share of channel usage but allows for smoother audio play back."
>
>
>
>
>

Raptor Call of the Shadows works good with my TSR but crashes without, I had tested that one at the start given it had been recommended to me as a problem game to test on my PCMCIA project.

While I understand the existence of the differences of microchannel vs ISA, and those require significant differences when designing hardware, but I had always thought from the perspective of a DOS program that is not attempting to do anything special, interactions with i/o, memory, interrupts, DMA should pretty much be no different.

I would say this is certainly true for i/o access, from the perspective of a dos program there is nothing different here. The speed could vary if you were attempting to use it for timing delays (reading ports etc) but on ISA the bus speed can vary wildly from system to system, you can have unfriendly neighbors making heavy use of iochrdy etc, so varied speed was something to be expected.

In the case of interrupts I would also say it is the same between the two systems. You just hook the interrupt as usual, and you get called when the interrupt is fired, and you clear/send the EOI to the PIC controllers at the end of your routine. If you are going to be sharing an interrupt this is a bit more special case, but this is seen outside of microchannel and if you are doing thing properly you would check with your hardware in your routine to see if you had requested the interrupt, and if not call the routine that you had replaced when you hooked in... more or less. the programs that fail on MCA here (so far at least) are simply because they were perhaps a bit sloppy, and not clearing their request for an interrupt during their handler, which yes on ISA they can get away with because nothing can happen. (again this exists in pcmcia world too).

On the topic of DMA, not that I am so familiar with the others, but this I would be least familiar with. but from the perspective of simple dos software attempting to setup simple transfer, I expect to configure the DMA controller and page register as usual, and that is it the hardware has to deal with the rest? i still have some reading to do here.

On Sunday, 2 July 2023 at 08:15:11 UTC-4, Ryan Alswede wrote:
> > on the topic of duke3d, I have not been able to get any version to crash including the one listed above.
> The older version would just not make sound. Did not crash.
>
> See if you can play Raptor Call of the Shadows then. It talks about PS/2 in the readme so there maybe hope. Adlib was the only thing it would do for FX sounds.
>
> DMA is a whole another animal. You have the following to deal with in MCA.. These settings were interesting to play with when I was working with the Ultimedia 7-6 card driver.
>
> -Adapters can do burst-mode where it can have complete control of the DMA channel for up to 12mSec.
>
> -MicroChannel Fairness feature, when 'Fairness' is disabled, the adapter will compete for every arbitration phase and will obtain more than its fair share of channel usage but allows for smoother audio play back."

On Sunday, July 2, 2023 at 6:42:10 PM UTC-5, Kevin Moonlight wrote:
> Raptor Call of the Shadows works good with my TSR but crashes without.

Excellent work. I forwarded your video to texelec. Maybe they can make their cards better as well.

>DOS program that is not attempting to do anything special
Ah but even DOS uses device drivers specific hardware on specific machines. In this case the device driver is built into the game and was tailored for ISA even if they were sloppy it worked with ISA.

So the adlib/opl2 audio issues have been keeping me up at night. The system I am testing on (5502-L Planar) has a basic cycle time of 200ns and an extended synchronous time of 325ns. I confirmed that the CD_CHRDY line is being driven appropriately during OPL2 reads/writes to be a synchronous cycle.

I had my mind set that this must just be too fast, so I revised the SnarkBarker to do asyncronous extended cycles for the OPL2 access, and I made the time configurable in another register so I could play around.

After extending the cycle just a little bit (50ns or so) doom,duke3d etc were able to play the OPL perfectly, but TYRIAN was still a total mess. In just pure messing around I went well past the 3.0us limit to 5.0us and at this point TYRIAN played perfectly and this is when I accepted that the issue was not directly the cycle time.

In the case of TYRIAN, what I noticed is that it would write to the sub-address 388h and then it would do 8 reads to 40h and then it would write to the data to 389h and then it would read 40h 10 more times. I would need to look closer to be sure I am not missing something, but it certainly appears to just do reads to the timer and not really care about the values, not actually configuring the timer or doing anything , and on a PC it would expect those reads to take 500ns or whatever it may be, but on my test system the basic cycle time being 200ns those 8-10 delay i/o reads are happening much faster and not giving enough time for the OPL to do its thing. Me extending the cycle to 5us is just indirectly slowing things down and giving it a chance.

in the case of doom, it does not do this but it still seems as though it also is expecting a certain cycle time as part of its delay between writting to the sub-address and data to the OPL.

So...... my remaining thoughts

1. Given that 200ns basic transfer is fairly common, why are there not more complaints about game compatibility with OPL2?
2. Expanding on #1, is there less complaints because the Texelec card is the market leader in this mini-market, and they use an OPL3 that does not need this big delay between writes?
3. what decides the basic and syncronous cycle times on a planar, is there any way to hack around with this in modifying planar adfs or some other magic? strictly in the bios? logic baked into PAL chips?

On Monday, 3 July 2023 at 09:21:25 UTC-4, Ryan Alswede wrote:
> On Sunday, July 2, 2023 at 6:42:10 PM UTC-5, Kevin Moonlight wrote:
> > Raptor Call of the Shadows works good with my TSR but crashes without.
>
> Excellent work. I forwarded your video to texelec. Maybe they can make their cards better as well.
> >DOS program that is not attempting to do anything special
> Ah but even DOS uses device drivers specific hardware on specific machines. In this case the device driver is built into the game and was tailored for ISA even if they were sloppy it worked with ISA.

>> 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.

https://www.ardent-tool.com/PS55/5550/486.html#RL_Planar

Shouldn't that be 5520-L? Looked through the PS/55 pages, no 5502 model.

https://www.ardent-tool.com/PS55/5550/Planar_5502-L_Photo_Top.jpg

Kevin Moonlight wrote:
> (5502-L Planar

Those 8 reads and 10 reads, can't you do a no op? Cut out the read
register access.

Kevin Moonlight wrote:
> In the case of TYRIAN, what I noticed is that it would write to the sub-address 388h and then it would do 8 reads to 40h and then it would write to the data to 389h and then it would read 40h 10 more times. I would need to look closer to be sure I am not missing something, but it certainly appears to just do reads to the timer and not really care about the values, not actually configuring the timer or doing anything , and on a PC it would expect those reads to take 500ns or whatever it may be, but on my test system the basic cycle time being 200ns those 8-10 delay i/o reads are happening much faster and not giving enough time for the OPL to do its thing. Me extending the cycle to 5us is just indirectly slowing things down and giving it a chance.