Kahenraz wrote on 2025-03-05, 12:55:

I'm curious if this is something that happens on other cards with the CS4237 or if it's something endemic to the Orpheus?

this is not a possibility at all, the connections that matter to PnP/ISA/host are the same with every CS4237 card, there is only 1 way you can interface the chip to the system

Vynix wrote on 2025-02-27, 11:25:

[…]
Show full quote

• Orphinit prints out stuff until "using configuration file..." then the whole screen blanks out and the keyboard becomes unresponsive
• IWINIT.bat doesn't print out anything, it just directly crashes before I can see anything pop up on the screen.
• Thus far, I was only able to get Orphinit to work once and that was when the system complained about a memory parity error and prompted me to press a key to turn down NMIs, doing so allowed Orphinit to initialize the card without crashing (!) but since then, I wasn't able to repro this.

So far, that doesn't really offer any hints that we can use to figure out what is going on, or when/how/why. One thing that occurred to me recently is that I should have asked you to try running ORPHINIT as usual, but without the card installed. It would also be useful to edit the batch file for InterWave initialisation, changing the line that invokes IWINIT to IWINIT -v9 (note that due to a bug in IWINIT, the v must be lowercase, or it will be ignored). Please be sure to re-boot between trying ORPHINIT and IWINIT.

When Gravis cards were still current, supported products, it wasn't uncommon to read about certain boards having hardware-level incompatibilities, due to the way a particular design handled the NMI line (or didn't connect it at all). Although this shouldn't be happening so early, and especially not when a different card is being initialised, it could be something to keep in mind. Also, look through your setup options. Do you have any options for parity checking, and are they enabled? If so, are you sure all of the memory you have installed supports parity-checking? Does anything change if you disable parity-checking?

Another thing to look at is how your parallel port is configured. It shouldn't be an issue, but if a non-standard port implementation is configured at I/O address 278H, there is some chance that it could interfere with the ISA PnP protocol. If that is the case, try moving it to 378H and/or setting it to the old standard output-only mode, and see if that changes anything.

640K!enough wrote on 2025-03-06, 06:12:

So far, that doesn't really offer any hints that we can use to figure out what is going on, or when/how/why. One thing that occurred to me recently is that I should have asked you to try running ORPHINIT as usual, but without the card installed. It would also be useful to edit the batch file for InterWave initialisation, changing the line that invokes IWINIT to IWINIT -v9 (note that due to a bug in IWINIT, the v must be lowercase, or it will be ignored). Please be sure to re-boot between trying ORPHINIT and IWINIT.

When Gravis cards were still current, supported products, it wasn't uncommon to read about certain boards having hardware-level incompatibilities, due to the way a particular design handled the NMI line (or didn't connect it at all). Although this shouldn't be happening so early, and especially not when a different card is being initialised, it could be something to keep in mind. Also, look through your setup options. Do you have any options for parity checking, and are they enabled? If so, are you sure all of the memory you have installed supports parity-checking? Does anything change if you disable parity-checking?

Another thing to look at is how your parallel port is configured. It shouldn't be an issue, but if a non-standard port implementation is configured at I/O address 278H, there is some chance that it could interfere with the ISA PnP protocol. If that is the case, try moving it to 378H and/or setting it to the old standard output-only mode, and see if that changes anything.

Right, so first things first, yes I tried running Orphinit without any cards installed, which resulted in it printing this out (using the /vd switch):

The LPT port is disabled (at least the BIOS says so) alas, that BIOS lacks any options related to parity checking that I can see:

I'm not 100% sure if the SIMMs that came with the machine support parity but since one pair has 9 chips and the other 3, I'm guessing yes?

Trying Ultrasnd.bat right now, let me get the results..

Tried IWINIT a second time, with the -v9 switch (I copied the ULTRASND.BAT file and added the switch in the copy file, Ultradbg.bat), I caught it writing "Can't open message file" then it does the same as Orphinit, that is crash and hang the whole system, had to film the screen in slow mo then go frame by frame to see it given how fast it happens.

Same thing without the v9 switch 😒

Vynix wrote on 2025-03-07, 08:05:

Right, so first things first, yes I tried running Orphinit without any cards installed, which resulted in it printing this out (using the /vd switch)

Okay, so that tells us something, even if it's not a complete explanation. Without the hardware being present, ORPHINIT does apparently run (that one time, at least). Also, the probing for the PnP BIOS signature, and the rest of the protocol are not solely responsible for the problem. The software does as much as it can without finding the hardware, and exits cleanly. If you can spare the time, it may be worth trying it a few times, just to see if you get the same result every time.

One thing that this also shows is that there is another PnP card present. It may be worth paying particular attention to the order of running the tools. ORPHINIT and IWINIT do not remain resident. If that network card's tools remain resident, there is some possibility that it expects its resource assignments to remain constant, and running other tools afterwards may be problematic. It may make sense to specifically run the tools for the network card after all sound initialisation tools, to see if that helps.

From what you've shown, nothing jumps out as being obviously problematic, with one possible exception: you have the setting "AT Bus Turbo Mode" enabled. The InterWave, in particular, has some fairly stringent timing requirements, and this may cause them to be violated. Too little delay (or running the bus above about 8MHz) can cause unpredictable results; this was even mentioned in a few places in old Gravis support documents. Too many delays can also cause some problems, including distortion during playback. So, it may be worth trying again, with that setting disabled. If that doesn't show any improvement, then I am out of ideas for now.

"TCM5094" is the 3COM 3c509's EISA ID. Yes, ISA cards can have them and I know for a fact that you can force the 509s to be solely configured by the EISA tools instead of manually or via ISA PnP. Try removing the 3Com card if you haven't already and seeing if the Orpheus card works. If it does, run 3C5X9CFG.EXE and force the 3Com card into non-PnP mode and manually assign it resources and see if that fixes things. By default, the 3Com cards like to grab 300h which will very likely clash with the Crystal MPU (if setup) or the PC MIDI MPU if jumpered for 300h. Also see this, as it MIGHT be a problem for other PnP config tools: https://github.com/hackerb9/3C509B-nestor?tab … levant-bios-bug

Also expect weird RAM issues if using an unmatched set of 30pin SIMMs. 486 machines need a matched set of 4x30pin SIMMs and I wouldn't be surprised that setup is throwing parity errors. Those Phoenix BIOSes are terrible as well. You can't install more then 16MB of RAM if BIOS shadowing is enabled (which it should otherwise things are really slow)!

640K!enough wrote on 2025-03-07, 20:51:

Okay, so that tells us something, even if it's not a complete explanation. Without the hardware being present, ORPHINIT does apparently run (that one time, at least). Also, the probing for the PnP BIOS signature, and the rest of the protocol are not solely responsible for the problem. The software does as much as it can without finding the hardware, and exits cleanly. If you can spare the time, it may be worth trying it a few times, just to see if you get the same result every time.

One thing that this also shows is that there is another PnP card present. It may be worth paying particular attention to the order of running the tools. ORPHINIT and IWINIT do not remain resident. If that network card's tools remain resident, there is some possibility that it expects its resource assignments to remain constant, and running other tools afterwards may be problematic. It may make sense to specifically run the tools for the network card after all sound initialisation tools, to see if that helps.

From what you've shown, nothing jumps out as being obviously problematic, with one possible exception: you have the setting "AT Bus Turbo Mode" enabled. The InterWave, in particular, has some fairly stringent timing requirements, and this may cause them to be violated. Too little delay (or running the bus above about 8MHz) can cause unpredictable results; this was even mentioned in a few places in old Gravis support documents. Too many delays can also cause some problems, including distortion during playback. So, it may be worth trying again, with that setting disabled. If that doesn't show any improvement, then I am out of ideas for now.

To my knowledge, the only NIC related thing I have loaded is the packet driver (3c5x9pd), I haven't touched anything else with the 3com.

I've went ahead and ran Orphinit from a pure DOS boot disk, without any cards present besides the VGA card:

@NJRoadFan
I tried earlier without the 3com inserted, it didn't change much, HOWEVER while Orphinit still crashed (and blanked the screen) the keyboard was still responding, I could press num lock/caps lock and the corresponding lights would turn on and off. I admit I saw that page before but didn't look at it fully, lemme give it a read..

Regarding the memory parity error thing, it was a one-off, it went away after I shuffled around the pairs, although I'm going to eventually swap all the modules for identical ones.. I believe all four are 4MB modules.. Ran a couple of rounds of Memtest and they all passed with flying colors though I still don't blindly trust those modules.

Also yeah, that Phoenix BIOS is just... a royal PITA, trust me, if I could find a MR-BIOS for this board I would swap it in a heartbeat and never look back.

Also try disabling the onboard parallel port if you haven't already. LGR's review mentioned that he couldn't get the card running in a system due to a troublesome multi I/O card. Don't hold your breath for a MR-BIOS as this board likely has a custom memory controller. This board is very similar to the Micronics EISA/VLB board I had with the stupid Phoenix BIOS with the 16MB limit when shadowing was enabled. That board also used a partial implementation of the Intel 82359DT EISA chipset with a custom memory controller. It also had the same onboard DP8473V multi I/O chip, albeit configured by jumpers.

I've left the LPT port disabled (don't plan on using it ever) along with COM2 already, so that can't be that.

However after disabling PnP on the NIC, I get this from Orphinit:

I've gone ahead and reconfigured the card to use a different address too (was previously at 300H):

Well, I'm afraid this is didn't change anything 🙁

AT bus turbo mode is set to disabled, I disabled COM1/COM2/LPT1, I set the NIC to be manually configured and gave it a different port..

Heck, I even did the same tests as before on a boot disk (without anything loaded), no change at all.

I'm still confused on one point though.. When I remove the Orpheus and run ORPHINIT, it still says there's an unidentified card present at the ports it uses, I have no idea if there's truly a "ghost card" in this system or if it's what Orphinit normally prints out when there's no card present..

Try toggling "Plug and Play Compatibility". You would think that what you want is for it to be disabled, but enabling it fixed issues with resource conflicts with my Orpheus II that occurred, even though I was certain that there weren't any at far as all configurable options.

Re: Orpheus II soundcard thread *** LT board now available ***

I managed to solve the issues with the the Crystal chip, wavetable header, and MPU-401 in DOS by setting "PNP OS Installed" to "Yes" in the BIOS. I think that it was assigning the Ultrasound resources that the Crystal chip was trying to use.

I had a lot of trouble juggling all of the resources on my motherboard to get everything working, but it definitely all came down to a configuration issue. The Orpheus II is very resource-heavy card and is always going to be a challenge to configure properly no matter what. Consider yourself lucky if it works perfectly the first time.

I had a lot of "problems" getting my card to work, but every one of them ended up being a configuration problem is resource conflict; completely user error.

Good luck!

The board in question does NOT have a PnP BIOS.

So I've been troubleshooting an issue on my P5A system using the Orpheus II (first revision).

Setup:
ASUS P5A rev1.04 (1011.005 Beta)
AMD K6-III+ 500Mhz (600 is unstable)
256MB SDRAM
32MB Riva TNT2 AGP
Orpheus II
Win98se/DOS7

Symptoms:
After initializing the card, Commander Keen 4, 5 and 6 can't see the OPL3 on port 388 while other games don't have a problem.
If I don't initialize the GUS portion of the card then the problem goes away!

I have tried changing the order of initialization (GUS first) and it worked ONCE where everything was set up and the Keens worked. After a restart it's back to not working.

Subsequent tests and restarts produce annoyingly random results. It just worked again.

For IRQs and ports, see screenshots.

Vynix wrote on 2025-03-09, 09:50:

I'm still confused on one point though.. When I remove the Orpheus and run ORPHINIT, it still says there's an unidentified card present at the ports it uses, I have no idea if there's truly a "ghost card" in this system or if it's what Orphinit normally prints out when there's no card present..

That one is actually simple to answer. If there are no Crystal devices in the system, this is what you will see when nothing is found. ORPHINIT makes one last attempt to find the device via another method, but does not carefully distinguish between nothing found and wrong device or chip revision present. While not clear, this is harmless in your case.

I am still deciding whether to correct the behaviour or remove support for it entirely. It's not related to the rest of the trouble, which is still a bit of a mystery at the moment.

IcySon55 wrote on 2025-03-09, 21:03:

Symptoms: After initializing the card, Commander Keen 4, 5 and 6 can't see the OPL3 on port 388 while other games don't have a p […]
Show full quote

Symptoms:
After initializing the card, Commander Keen 4, 5 and 6 can't see the OPL3 on port 388 while other games don't have a problem.
If I don't initialize the GUS portion of the card then the problem goes away!

I have tried changing the order of initialization (GUS first) and it worked ONCE where everything was set up and the Keens worked. After a restart it's back to not working.

Subsequent tests and restarts produce annoyingly random results. It just worked again.

The first thing to consider is that you should generally be using ORPHEUS.BAT, instead of invoking ORPHINIT directly, unless you have a specific reason to avoid this. It will intelligently handle the BLASTER and ULTRA16 environment variables for you, ensuring that they match the resources actually assigned. This has nothing to do with the solution to your problem so far, but is something that you might like to correct.

I have an initial hypothesis about the cause of your problem, but more details would be helpful. Please include both the INI file that you use for ORPHINIT, as well as IW.INI from your InterWave directory (which looks like it should be C:\ULTRASND).

640K!enough wrote on 2025-03-09, 21:50:

The first thing to consider is that you should generally be using ORPHEUS.BAT, instead of invoking ORPHINIT directly, unless you have a specific reason to avoid this. It will intelligently handle the BLASTER and ULTRA16 environment variables for you, ensuring that they match the resources actually assigned. This has nothing to do with the solution to your problem so far, but is something that you might like to correct.

I have an initial hypothesis about the cause of your problem, but more details would be helpful. Please include both the INI file that you use for ORPHINIT, as well as IW.INI from your InterWave directory (which looks like it should be C:\ULTRASND).

I believe I haven't customized these two and have simply extracted them from their ZIPs to C:\Drivers (Orpheus) and C:\Ultrasnd (v.4 preinstalled package)

So far, testing with OPRHEUS.BAT (GUS still initializes first) has produced good results in two consecutive tests... followed by it not working once again. No change as you suspected.

IcySon55 wrote on 2025-03-09, 21:03:

So I've been troubleshooting an issue on my P5A system using the Orpheus II (first revision).
[...]

there is a report for the P5A regarding the 98SE crystal driver but perhaps it has some connection to DOS, have you seen it?

13. I have an ASUS P5A motherboard and win9x CS4237 drivers do not work, I get a message about CWDAUDIO.DRV on boot
2
3The solution to this problem is to DISABLE the "PCI DELAY TRANSACTION" option in BIOS, then Crystal windows drivers will load fine.
4It is unsure what causes this conflict on this motherboard (and possible other motherboards) , could be the installed hardware combo, BIOS
5revision or some other voodoo - but if you face a similar issue give the option a try.

keropi wrote on 2025-03-10, 06:53:

there is a report for the P5A regarding the 98SE crystal driver but perhaps it has some connection to DOS, have you seen it? […]
Show full quote

there is a report for the P5A regarding the 98SE crystal driver but perhaps it has some connection to DOS, have you seen it?

Copy code to clipboard

13. I have an ASUS P5A motherboard and win9x CS4237 drivers do not work, I get a message about CWDAUDIO.DRV on boot
2
3The solution to this problem is to DISABLE the "PCI DELAY TRANSACTION" option in BIOS, then Crystal windows drivers will load fine.
4It is unsure what causes this conflict on this motherboard (and possible other motherboards) , could be the installed hardware combo, BIOS
5revision or some other voodoo - but if you face a similar issue give the option a try.

I have seen this actually, yes. I recall enabling delayed transaction once before and it makes the system completely unusable with all sorts of crashes. In Windows I'm not having any (sound) issues at all actually! It is of course disabled.

I'm mainly suffering with horrible AGP support on Alladin V chipset which results in GPU incompatibility, video corruption and of course all manner of crashes. So far the Riva TNT2 is the most stable albeit not very fast for what I'm playing right now, but it has a memory issue where certain pixels will occasionally corrupt their colors in a very obvious pattern. One of the memory chips must be marginal.

IcySon55 wrote on 2025-03-10, 04:37:

So far, testing with OPRHEUS.BAT (GUS still initializes first) has produced good results in two consecutive tests... followed by it not working once again. No change as you suspected.

One problem with some old titles is that their timing routines depended on processors not exceeding some performance limit. Once faster systems became available, they either didn't work at all, or were unpredictable. I have noticed just that with some of the Keen titles, even with no other audio hardware present. So, it may be a good idea to leave the InterWave portion uninitialised, and do some repeated testing to make sure that it really works consistently when you don't run IWINIT. That isn't intended to be a "solution", just another data point to consider.

Even with the older GF1-based Gravis cards, there were some reports of similar behaviour. It may be related to the emulation features of the card, which I think may be partially active, even when not explicitly assigned resources. IWINIT may have been designed with the assumption that people would always want such features to be available, and may have configured the hardware accordingly. I will have to look into these details at some point, but I am not sure how soon that will be. One other thing to try would be to initialise the InterWave with UNISOUND instead of IWINIT, and test again. It may do a better job of making sure that unwanted features are not stubbornly activated, but that is something that only JazeFox would be able to tell us for sure. Again, that is not a solution (assuming there is one to be found), just more supporting data.

I will be looking into this in greater detail, but probably not as soon as you would like.

I have a P5A based machine I can do some testing in. Thing has been rock solid in the past even though it is running an Intel i740 AGP card!