> > note: SAAemu 0.60 is now available in Win32 version too. > > (I hope it will be included in the first Win32 release of SimCoupe. > > .....Who knows.....) > > I was waiting to hear back from you about it - is there anything I can try? > I'd be interested in seeing Dave's hq stuff in action, but I've not got > enough interface documentation to use the DLL you sent me a couple of weeks > ago. > > What's the sound latency like - is there much lag when playing games? > (crashes when run under NT so I'll try it tonight...) > > Si
I got Aley's SAA32.exe working under Windows NT by renaming the 'audio' subdirectory to 'saa32audio' And only the 'hq' driver works under NT (Aley's sound drivers access the hardware directly, resulting in 'attempting to execute privileged instruction' crashes if you try to use them). You will probably find that running Aley's player under NT eats up all the CPU time ... this is apparently due to the way Aley is updating the screen display all the time - try pressing ALT+SPACE in the Dos Box, and selecting 'Edit >' and then 'Mark' to disable updating the contents of the screen. I find that, when doing this, the CPU usage drops instantly to almost zero, with the occasionally peak to at most 30%. Under 95, doing the same trick also dramatically reduces the CPU usage ... I find (using WinTop) that by disabling the screen update, I have 70% or more idle CPU time, as opposed to only 5% otherwise! These figures apply (on my father's woefully underpowered 133) irrespective of the sound output mode selected. (HQ or Aley) I also find I cannot exit Aley's player if Caps Lock is on! Aley's earlier comment about me 'not wanting to release my code' was incorrect on two counts Firstly, this is not what I said. I had said that I did not want my code to be released with Aley's player until I was satisfied with the results. Secondly, I had mistakenly thought Aley to be using a much earlier version of my library than he actually was, and as a result informed him incorrectly that the current version, which superseded it some time ago, was incompatible. In fact, the version Aley is using is the newer version, and my more recent maintenance version is entirely compatible. What I can't seem to understand is where Aley's code is - how can other software interface with it? Aley has supplied a header file for his library, and the import library file saaemu.lib. He has also supplied a copy of my SAASound.dll (this contains only my SAA-1099 simulation functions and does not contain any of Aley's code). He has not supplied his own dll, however. Are we to assume that we must link our code to his saa32.exe ? I have discovered a couple of minor bugs in my emulation dll - there was an issue with envelopes not being triggered correctly under certain circumstances which has now been fixed (as far as I can tell) and there was also a bug in the mono mixing routines. As you can imagine, I envisaged that only my stereo routines would be used, so the mono mixer was just a sort of filler to ensure compatibility. Aley's SAA32 player seems to use ONLY my mono code, which is a little unfortunate (and also unfair) since the stereo routines sound better! Also, he uses my code in 8-bit mode rather than 16-bit mode. His reason is that my functions do not work in stereo or 16-bit modes, and that my data is 'incompatible with the windows API'. This is not actually the case, since I have been able to successfully use my routines in stereo and 16-bit modes - if I had not, how would I know if they were working or not? Until Aley is able to tell me specifically what's wrong, and until any errors in the above have been traced and fixed, there is no way I can fully appreciate Aley's player. I cannot find any bugs, and he seems unwilling to tell me what he has found. However, I will allow Aley to continue using my library, but I must insist that he tells me any bugs that he has found. My routines have also now been extended to add support for additional features. A volume boost option is planned for the next release (I notice that Aley's routines under Win95 are considerably 'louder' than mine). Aley suggested that I should add a 'channel mute override' option to my routines. Why? The original SAA-1099 did not have a 'channel mute override' option, so why should my code? If he wants to implement a channel mute override in his player, then he could just do something like the following: Let M be the mute bitmask as sent to register 20 or 21 (dec) on the SAA-1099 Let Y ba a user-defined channel mute override bitmask - for each bit set in Y, the corresponding channel of the SAA-1099 is muted, irrespective of the value of M Then, instead of naively calling a function that simulates the OUT 255,M function of the soundchip, after a corresponding OUT 511,20 or OUT 511,21 the function call should be OUT 255, (M & (~Y)) I leave it to Aley to implement this into his player. dave
