640K!enough wrote on 2020-07-25, 20:35:

Is 4 MiB the correct amount you actually have installed on-board?

Indeed, it is. And yes, that was exactly what I meant to say with it, ModM always only shows 1MB (and didn't have native Interwave support, yet, as of the last version I had).
Iwinit and unisound did agree on 4MB on my board, but I have to admit, I never tried with 2x 512K.

MJay99 wrote on 2020-07-25, 20:43:

640K!enough wrote on 2020-07-25, 20:35:

Is 4 MiB the correct amount you actually have installed on-board?

Indeed, it is. And yes, that was exactly what I meant to say with it, ModM always only shows 1MB (and didn't have native Interwave support, yet, as of the last version I had).
Iwinit and unisound did agree on 4MB on my board, but I have to admit, I never tried with 2x 512K.

I think I also have 4Mib...? 😮

I thought I bought 512KiB chips, but reading the description now it says "1Mx16Bit", which would be 2MiB per chip, and hence 4MiB. Oh wow, what a pleasant surprise!

root42 wrote on 2020-07-25, 21:36:

I thought I bought 512KiB chips, but reading the description now it says "1Mx16Bit", which would be 2MiB per chip, and hence 4MiB. Oh wow, what a pleasant surprise!

If the photos you posted in June reflect what is still on your board, then they are indeed 2 MiB DRAM ICs, so a total of 4 MiB, as you just said. Therefore, it turns out that IWINIT and UNISOUND were right to begin with.

I don't like the feeling that I may have provided unjustified trouble reports, so I investigated the RDP issue further. On my system, at least, it wasn't unjustified at all, and I have some proof.

As currently implemented, UNISOUND changes the RDP regardless of the options used, even if you only ask for the list of cards. On my system, it seems to consistently set it to 263H. As previously mentioned, some vendor software does not like that. The photos I took were much more blurry than I had hoped, but they are still mostly legible. If you follow the progress of the experiment, you will see that I first use IWINIT to initialise the GUS PnP, then PLAY.EXE to play a MIDI file. Following that, I ask UNISOUND for the list of installed cards and try to play the same MIDI file again. PLAY.EXE reports that it can't find the same GUS PnP that it had just used a moment earlier. The only thing that had changed was the running of UNISOUND.

Then, I use a tool I wrote to fix the problem. It first tries to enumerate the ISA PnP cards in the system. Because the RDP is no longer correct, it gives garbage. It then issues a reset CSN command to all cards and puts them back in the wait-for-key state. That is one of the few ways to be able to issue a new RDP, which it does next, followed by going through the isolation protocol, so that the CSNs can be re-issued to the cards. Lastly, it tries enumerating the cards again, and this time it works as expected. PLAY.EXE is also able to find the card again, and the MIDI file plays normally. Photos follow:

I have also attached an archive containing the tool to fix the RDP, as well as the simple batch file that produced the output shown in the photos. If anyone wants to test and report their results, this might be useful in determining how many are affected (particularly those who had cards "disappear" after running UNISOUND). This is only really applies to systems with a Plug and Play BIOS, though systems without may have similar problems in certain cases.

EDIT: The InterWave drivers for Windows 3.1 also end up with severe indigestion on my system, first giving a blue screen with a "Card is busy." message, then giving a "VIWD.VXD not loaded." message box an annoying number of times. Running FIXRDP restores normal operation.

@640K!enough

Yes, you're right, I know the RDP may change with Unisound, it's a compromise I had to take one day. At first, Unisound was created without PnP BIOS in mind (486 or lower). After some versions (internal, months ago), I thought of adding some PnP BIOS detection, but I realized after testing with several different motherboards with PnP BIOS, that they implemented PnP differently (not 100% as the standard paper says) and I couldn't trust on them with the info they reported. This led into some problems (including erratic behaviour and hangups) and then tried without explicit PnP BIOS support. Just to be sure that it would be safe, I tried lots of software (vendor utils too) and didn't found one that caused problems. In fact, out from vendor INIT tools (that are supposedly not needed if you plan to use Unisound), other tools should not mess with PnP. So I had to decide: Specific PnP BIOS support or not (known problems vs potential problems I could not reproduce), so you see what I decided. In the 99% of the cases, it works fine. You found one case with issues, a player for the GUS (I'm wondering why a player need to deal with PnP???) so, after your tests I am thinking about this again. I think the best solution would be to add an eXtended command line option to Unisound to deal with this, to tell Unisound that it's running on system with PnP BIOS and then detect and use the current RDP. This way, being an optional switch, issues are reduced if the tool is run on a board with a problematic PnP BIOS implementation.

Currently, Unisound "scans" for RDP until a card is isolated, and then uses that RDP.

Anyway, after your tests, I'll make some extra little changes to the tool. To have a faster RDP scan, the tool starts at 0x263 and ends at 0x3B3, but I'll better change it to scan the whole space, starting from 0x203. That may help too.

One note about vendor tools: I analyzed dozens of them in the past and they'll are far from "respecting the rules". Some of them kills other PnP cards present in the system, some others send its own key (instead ogf the standard PnP key) indiscriminately to configure its cards (only one, not several from the same model), leaving the card in a state that couldn't be re-scanned with legit PnP tools, causing weird behaviours or hangups. Others update chip's microcode killing other PnP tools too. Even CTCU/CTCM are plagued with implementation bugs. I hope Unisound will be refined to minimize (or have zero) issues with all possible systems 😀

If you want to help, maybe you would cross a few PMs with me, if it's OK for you.

(I hope one day you would find at least one positive thing about this tool 😀)

There is nothing negative about this tool. Your support has been excellent! I thank you for your time and effort!

JazeFox wrote on 2020-07-28, 07:26:

(I hope one day you would find at least one positive thing about this tool 😀)

If all I did was tell you what wonderful work you're doing, how would the bugs get fixed? 🤔

That this works as well as it does is already quite interesting, but that doesn't mean that we shouldn't discuss ideas for improvement or work to figure out the bugs.

JazeFox wrote on 2020-07-28, 07:26:

If you want to help, maybe you would cross a few PMs with me, if it's OK for you.

I'm not quite sure what I can contribute, but if you think I can be useful, you know how to reach me.

JazeFox wrote on 2020-07-28, 07:26:

Anyway, after your tests, I'll make some extra little changes to the tool. To have a faster RDP scan, the tool starts at 0x263 and ends at 0x3B3, but I'll better change it to scan the whole space, starting from 0x203. That may help too.

Changes would definitely be warranted, though I'm not so sure that that is quite the right approach to start with. If you remember which systems used to cause problems, why not try the executable I attached above and see what it gives you. If it is at least able to determine a usable RDP, that may be a better starting point: scan for the PnP BIOS signature; if found, try to get the configuration structure and retrieve the RDP. Use that to scan for cards without any additional command-line options, but offer one to force an isolation scan from 203H and take the first usable port (which would be the default for non-PnP systems).

My concern is that, on my system, a scan that starts at 203H might be able to use 203H or 207H, but the PnP BIOS tends to use 20BH, so the problem would remain.

There is also the matter of configuration managers, and I am not familiar with their interface yet. Those should probably also be detected and used to the extent possible.

I have to say this tool is pretty amazing, I bought a 486 desktop the other day and the only sound card I had on hand was an Aztech 2320 based card which I'd never used before (didn't even know it worked). After trying many different drivers with it I only had success with Unisound.

Under Windows 3.1 I have the audio set up as a Sound Blaster 1.5 and wave audio works as expected but I can't work out how to get MIDI support working. Does this tool support MIDI for the AZT2320 or am I doing something wrong (or of course there is the possibility that MIDI doesn't work on the card, it has been in the loft for many years and I've never used this one before).

thevdm wrote on 2020-08-04, 06:49:

I have to say this tool is pretty amazing, I bought a 486 desktop the other day and the only sound card I had on hand was an Aztech 2320 based card which I'd never used before (didn't even know it worked). After trying many different drivers with it I only had success with Unisound.

Under Windows 3.1 I have the audio set up as a Sound Blaster 1.5 and wave audio works as expected but I can't work out how to get MIDI support working. Does this tool support MIDI for the AZT2320 or am I doing something wrong (or of course there is the possibility that MIDI doesn't work on the card, it has been in the loft for many years and I've never used this one before).

Do you mean MIDI as in the MPU401 functionality, or the ability to play MIDI files through the OPL synth? If you mean the second, you probably need to install a driver that does that.

Oetker wrote on 2020-08-04, 07:26:

Do you mean MIDI as in the MPU401 functionality, or the ability to play MIDI files through the OPL synth? If you mean the second, you probably need to install a driver that does that.

I was referring to playing MIDI files in Windows using the OPL chip. I will have a look into drivers to cover that after work, thank you.

Update: MIDI playback is working in Windows now, I used the OPL drivers listed here - Re: How to get the FM or OPL3 effect sound in the sound card?

Thank you again

Small update:

Tool updated to v0.75e

Changelog:

• Bugfix: AWE upgrade card CT1920 was misidentified as a regular AWE32.
• Added support for Roland Super MPU II PnP MIDI card initialization.
• Changed PnP detection process slightly. Now it is faster and more compatible with existing PnP management (like PnP BIOSes). PnP RD port is not overwritten if it was already set before running UNISOUND.
• Fixed bug that listed all cards detected as "Bad checksum" when /XXF was used under certain circumstances.
• Other minor cosmetic changes.

The download link is updated at the end of the first post as usual:
UNISOUND - Universal ISA PnP Sound Card Driver for DOS v0.81b

As you've added support for the Roland Super MPU II, doesn't it need a TSR? I always believed that it wasn't just about initialization, but also some resident thing in background... Btw, do you know if it supports the Intelligent Mode? Never seen any exact confirmation of that.

hard1k wrote on 2020-08-05, 16:29:

As you've added support for the Roland Super MPU II, doesn't it need a TSR? I always believed that it wasn't just about initialization, but also some resident thing in background... Btw, do you know if it supports the Intelligent Mode? Never seen any exact confirmation of that.

Unfortunately I can't answer your questions, because I don't own that card. I added support for it because it was requested by a user of the forum. We tested this version with his card and he said that it worked well without having to run SMPUENA.EXE, so I guess a TSR is not needed...

I did request support for it and tested it as well. There's no TSR at all. Official Roland's tool doesn't do anything other than PnP init either. It does support intelligent mode.

hah I always thought SMPUII was a windows card and it supported all modes only in windows since it loaded it's driver
nice to hear it only needs init to be usable!

You guys have just made me regret a lot that I sold my boxed SMPUII for cheap while thinking it was no good for DOS... 🙁
Time to hunt down another one though, I think.

hard1k wrote on 2020-08-05, 17:32:

You guys have just made me regret a lot that I sold my boxed SMPUII for cheap while thinking it was no good for DOS... 🙁
Time to hunt down another one though, I think.

Looking at the manual... it clearly states that it has intelligent mode... very interesting.

cyclone3d wrote on 2020-08-05, 18:00:

Looking at the manual... it clearly states that it has intelligent mode... very interesting.
Roland-Super-MPU-II-Owners-Manual.pdf

yes but the misconception was that it only supported it under windows - at least that's what I knew all these years

In Windows 9x you get two separate MIDI inputs and two outputs, so it can be connected to SC-88 series A and B inputs for 32 MIDI channels. In DOS second output mirrors first unfortunately.

keropi wrote on 2020-08-05, 18:11:

cyclone3d wrote on 2020-08-05, 18:00:

Looking at the manual... it clearly states that it has intelligent mode... very interesting.
Roland-Super-MPU-II-Owners-Manual.pdf

yes but the misconception was that it only supported it under windows - at least that's what I knew all these years

I didn't even know about the Super MPUII. Do a google search and unless you specifically search for it, it only comes up with the Super MPU-64.

Now I have something else to keep an eye out for... not that I need any more intelligent mode midi cards.