From: me@yyzkevin.com   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)