Marmes wrote on 2022-02-07, 00:24:

On asus P2B-L With 128mb ram , Via C3 nehemiah at 1.2Ghz, Asus V7700 Orpheus and Argus I get Unable to reset Sound Blaster DSP.

Based on the output, there is definitely something a little strange going on here. I suspect it is at least partly related to the hardware-assisted SB/Ad Lib emulation features of the InterWave, and we can investigate that in a little more detail later, if you are interested. However, there is still other strangeness that I think we should address first. To begin with, a few questions:

1. Does your system have a "Plug and Play OS Installed" (or similar) setting in the BIOS setup? What is the current setting?
2. When this happens, do you run IWINIT (or UNISOUND) before ORPHINIT?
3. If you are using IWINIT, what does your IW.INI look like? If UNISOUND, what are your BLASTER environment variable and UNISOUND command-line options?
4. Is your Orpheus hardware configuration data the standard version, or the version with Plug and Play support disabled (used for Dell BIOS problems)?
5. Did you write the full resource map to the ARGUS EEPROM? Is it an unmodified GRAVNOCD.ROM?
6. Do you have any other memory-resident software running?

Marmes wrote on 2022-02-07, 00:24:

Edit: If I remove Argus all works fine.

If it's not too much trouble, can you post the output from the same machine when ARGUS is not installed?

EDIT: Also, what happens if you try CWDINIT instead of ORPHINIT (when ARGUS is still installed)?

Hello!
1- On bios I have non PNP OS (I have MSDOS 7.1 installed)
2- I don't run IWINIT or Unisound. Fresh install.
3-
4-Configuration is Standard version
5-Unmodified gravnocd.rom
6-Only memory managers
After work I will test with no Argus and post output. Will also try cwdinit (with and without Argus).

Thanks!

Well
I got home and did some tests. It's a motherboard problem for sure.
In Asus p2B-L with config stated on my previous post:
-Only with Orpheus
All works fine.
download/file.php?mode=view&id=130020
-With Orpheus and Argus using CWDINIT
Orpheus is not detected. In fact not even alone in the system orpheus is not detected with CWDINI.

In Tyan S1590
Both cards run happily together with orphinit.

My suspicion is this: it's a combination of two issues; the first is a bit of an unusual Plug and Play implementation on the P2B-L, and the second is that the InterWave and Orpheus are conflicting. If you're satisfied with your result, there is no need to continue trouble-shooting (you can stop reading here, if you're already bored or too busy). If you want to keep digging, there are a few things you can try, testing with ORPHINIT after each change; we'll get to the suggestions shortly.

I say that it appears to have an unusual PnP implementation because, while it does include ARGUS in its BIOS enumeration, it apparently ignores Orpheus altogether; it doesn't even give it a device number (CSN). It may think that ARGUS is too much of a resource hog, but there are still viable resource assignments that it could have used (just not the standard/optimal choices). Also, when software does its own isolation, some mechanism seems to be reverting the process, which is making initialisation more problematic. This is the only time I have seen this.

By default, when unmodified GRAVNOCD.ROM is used, the SB emulation resources are requested for InterWave. On your system, this appears to result in ARGUS getting 220H, so if you try to use 220H for SB Pro mode on Orpheus, a conflict results, which likely explains the inability to complete a DSP reset.

So, things you can try:

1. For this first test only, change the ARGUS EEPROM device ID to ARV0001. This will cause Orpheus to come before ARGUS during isolation; see if that improves the situation. Restore the original ID before continuing, so the rest of the tests won't have an artificial advantage. In theory, this should make CWDINIT usable, too.
2. Set "Plug and Play OS Installed" to Yes, then reserve the resources you will need for Orpheus and ARGUS (set IRQs and DMA channels to "Legacy ISA" or similar).
3. Run PNPCFG.EXE from the GUS PnP/InterWave installation and disable all non-essential features, in particular the Sound Blaster emulation. This won't prevent you from using them; it will just not assign resources at start-up, preventing the InterWave from hogging 220H and 388H.
4. Configure Orpheus to use an SB I/O address other than 220H (and maybe OPL3 address other than 388H). This should work, even if ARGUS is still installed with default EEPROM.
5. Ensure that you have the most recent BIOS revision for the P2B-L installed.

If you're actually interested, some or all of those should produce interesting results.

All of this is to say that I don't think this is related to a bug in ORPHINIT. I have noticed a bit of odd behaviour recently, that may indicate a timing problem; possibly a difference in behaviour between the Rev. C/D chips and the Rev. E versions. I still have to investigate to see what is going on there, and how to work around it, if necessary.

I had to set PnP OS to "YES" on one Abit board or things wouldn't work on my sound card + its software. Letting BIOS do PnP stuff made some other stuff not work too so I normally always set it to "YES" so that BIOS will leave the PnP things alone and reserve the resources I know I will need so that PCI things etc. won't get them.

well
I installed MSDOS6.22
I did what Tiido told. It worked!
I set Asus P2B-L bios to:
PNP OS - Yes
Reserved what I wanted for ISA cards.
All worked fine!
DSP made reset sucessfully.
Now All works fine!
Will Install MSDOS7.1 and test it.

Edit:MSDOS7.1 works just fine!
All good in the end.
This motherboard doesn't work as usually others do.

Marmes wrote on 2022-02-08, 09:41:

Edit:MSDOS7.1 works just fine!
All good in the end.
This motherboard doesn't work as usually others do.

Did you happen to notice in the verbose output if it is still having the same trouble finding the Orpheus card? Does CWDINIT now work properly also?

With 0.54b straight from the zip my system throws a FILE NOT FOUND about every other boot when calling orpheus.bat. Apparently orphinit.exe is exiting with an errorlevel of 1 but no orphenv.bat is being created.

sduensin wrote on 2022-07-17, 00:28:

With 0.54b straight from the zip my system throws a FILE NOT FOUND about every other boot when calling orpheus.bat. Apparently orphinit.exe is exiting with an errorlevel of 1 but no orphenv.bat is being created.

That's an interesting problem, especially if you're saying it only happens sometimes. Please try the attached version, and report what the error message says. Hopefully that will give us some idea about what is going on.

The new version is still a work-in-progress, so is probably not of much interest to anyone else. It does take noticeably longer, so please be patient.

EDIT: It is worth pointing out that this version does not include Orpheus II support of any kind.

Hello and thanks for your work @640K!enough !

Machine used: Pine PT-429 Socket 3 Motherboard with 486dx50 and 16MB.
Orpheus card paired with one Texelec SAAYM works flawlessly.

One little deception about the SPDIF output with min-digital selected, all the panning in OPL3 games (Doom, Hexen, etc..) or OPL3 songs with a tracker or sbvgm utility are gone 🙁 Also, i might be wrong but the fm sound is different a bit muffled and or slightly distorted. Is this the SRS settings cause ?
It's working with the analogue settings but, it's not really a true digital to spdif (correct me if i'm wrong). Before i get the Orpheus card, i was using the CT3910's SPDIF output for my recordings, i was hoping to achieve the same thing with the Orpheus.
Anyway, i'm still very happy with it, the audio output is clean (compared to the CT3910) and better than my Audiotrix Pro.

Thanks for your input.

DjLc wrote on 2022-08-09, 16:18:

Machine used: Pine PT-429 Socket 3 Motherboard with 486dx50 and 16MB.
Orpheus card paired with one Texelec SAAYM works flawlessly.

Thanks for mentioning your configuration. It's always nice to know about the configurations that work well, as well as those that cause problems.

DjLc wrote on 2022-08-09, 16:18:

One little deception about the SPDIF output with min-digital selected, all the panning in OPL3 games (Doom, Hexen, etc..) or OPL3 songs with a tracker or sbvgm utility are gone slightly frowning face Also, i might be wrong but the fm sound is different a bit muffled and or slightly distorted. Is this the SRS settings cause ?

Yes, the min-digital configuration requires the use of SRS, which completely ruins the sort of stereo placement that we know from the DOS world. The idea is that the algorithm tries to re-create the usual/expected placement of sounds during a live performance. This can be interesting with some types of content, but for the typical DOS game, tracker music, or sound effects with stereo placement, the desired effect is lost.

I have an idea for an upcoming version of ORPHINIT that makes creative use of some features of the CS4237 to give you what you want: a clean, purely-digital bitstream for OPL3 and PCM audio with no SRS or analogue noise. I can't tell you when that release will be ready, but be sure to watch this thread for details.

DjLc wrote on 2022-08-09, 16:18:

It's working with the analogue settings but, it's not really a true digital to spdif (correct me if i'm wrong).

This is correct; as the name implies, all sound sources go through the on-chip analogue stage, before passing through the ADC and going to the digital output. It was an unfortunate compromise that had to be made to ensure that absolutely all sources are available in all modes; it makes things simpler for users who want things to work without having to constantly worry about the configuration they are using for a particular title. I can't get around that problem, but I will offer more options for those who want to make use of them.

The Audiotrix Pro is a nice card. I'm still angry with myself for not buying one when I had the chance.

640K!enough wrote on 2022-08-10, 05:48:

I have an idea for an upcoming version of ORPHINIT that makes creative use of some features of the CS4237 to give you what you want: a clean, purely-digital bitstream for OPL3 and PCM audio with no SRS or analogue noise. I can't tell you when that release will be ready, but be sure to watch this thread for details.

Thanks for your feedback ! I'll wait for this release, take your time !

DjLc wrote on 2022-08-10, 10:56:

Thanks for your feedback ! I'll wait for this release, take your time !

I did some quick testing, and, unfortunately, the chip didn't agree with me. The new configuration didn't give better results, as I still had silence on the FM side if SRS wasn't enabled. So, different configuration, same results. I will keep looking, but I can't deliver on that feature yet.

Heyho! I setup my PC with an Oprheus-card and some midi-devices and I'd like to be able to deactivate the wavetable via software so I can decide per game whether to use the wavetable or an external midi-device (but without silencing the soundblaster and adlib-sounds). I use oprhinit 054b and tinkered with the settings and I'd like to ask whether my conclusions are correct. So far I only tested that with one game - Monkey Island 2 with the patch to enable mt32 plus soundblaster-sfx. So what I think I figured is: In sb-mode there's currently no option to silence the wavetable. In wss-mode I can set WTHeaderVol to mute;31 and that can work but also games can tinker with that setting, maybe? When I set the WTHeaderVol and start Monkey2 in pure mt32-mode, it's silent. But when I start it in the mt32+soundblaster-mode, the wavetable is back in action.

RobDangerous wrote on 2022-09-18, 22:17:

Heyho! I setup my PC with an Oprheus-card and some midi-devices and I'd like to be able to deactivate the wavetable via software so I can decide per game whether to use the wavetable or an external midi-device (but without silencing the soundblaster and adlib-sounds). I use oprhinit 054b and tinkered with the settings and I'd like to ask whether my conclusions are correct. So far I only tested that with one game - Monkey Island 2 with the patch to enable mt32 plus soundblaster-sfx. So what I think I figured is: In sb-mode there's currently no option to silence the wavetable. In wss-mode I can set WTHeaderVol to mute;31 and that can work but also games can tinker with that setting, maybe? When I set the WTHeaderVol and start Monkey2 in pure mt32-mode, it's silent. But when I start it in the mt32+soundblaster-mode, the wavetable is back in action.

Welcome! Firstly, please accept my apology for the delay; I've had a bit of a real-life situation taking up most of my time lately, so haven't been around this forum very often.

There are a few different aspects to the problem you're describing. The key details are:

1. Some DOS software is notorious for fiddling with the mixer levels, regardless of what you try to set before launching a particular title, so that may be part of it.
2. WSS mode is generally more friendly when it comes to mixer values and flexibility. There seems to be less fiddling with mixer values at start-up, compared to titles with only Sound Blaster support.
3. Whatever you set in WSS mode, mixer values are reset to SB defaults when the chip switches into Sound Blaster-compatibility mode.
4. Crystal was constrained by the primitive nature of the Sound Blaster Pro mixer. In Sound Blaster-compatibility mode, the wavetable header volume is controlled by (and kept at the level of) the FM synth mixer value; that is to say, SB-FMVol. Currently, you cannot mute one without muting the other, and if the software resets the SB mixer as part of its start-up routine, then your settings will still be lost.

Hopefully that clarifies the situation a little.

There is a possible solution to this, which I will be testing while adding support for Orpheus II. With my current situation, and the fact that we will likely have a few internal testing releases before we declare the upcoming version ready for release, it may be a little while before it is available for download.

Thanks a lot 640K!enough, that helps me to understand the situation and knowing that the wavetable-volume equals the fm-volume in sb-mode is very useful. And no worries, we are talking about games from 30 years ago, there's no hurry with any of this. Nonetheless looking forward to any software-updates and the Orpheus II of course 😀

We've spent an unreasonable amount of time chasing gremlins over the past number of months, but I think we're finally ready for this: please allow me to present ORPHINIT v0.57ß, now with preliminary support for Orpheus II LT. This primarily targets those with "early edition" Orpheus II LT boards, but there are a number of bug fixes and other improvements that make it a worthwhile upgrade for all Orpheus owners. As always, please share any comments, problem reports or other feedback.

The most visible difference is the cardType setting, mostly of interest to those with the aforementioned "early edition" boards. However, every INI file must be updated to include that line (even for original Orpheus owners), or you are likely to get no sound at all. This is very likely to be a temporary measure, but is necessary for now.

This is a wonderful surprise!
Thank you very much and have you a nice day as you give me, whit this surprise, a nice day! 😁

thanks for sharing this 640K!enough and for all the hard work put into Orphinit!!!
it really is a pro-work on the CS4237 , way surpassing what Crystal themselves created back in the day for DOS usage

note for the owners of the OprheusII-LT board :
please remember to move this jumper to the position shown so that you enable "oprheusII opl3 mode" and ofcourse set the card type to "OrpheusII"

upcoming OprheusII(LT) boards won't have this jumper since it's not needed because of the new public Orphinit release 😀

keropi wrote on 2023-01-19, 10:14:

thanks for sharing this 640K!enough and for all the hard work put into Orphinit!!! it really is a pro-work on the CS4237 , way s […]
Show full quote

thanks for sharing this 640K!enough and for all the hard work put into Orphinit!!!
it really is a pro-work on the CS4237 , way surpassing what Crystal themselves created back in the day for DOS usage

note for the owners of the OprheusII-LT board :
please remember to move this jumper to the position shown so that you enable "oprheusII opl3 mode" and ofcourse set the card type to "OrpheusII"

upcoming OprheusII(LT) boards won't have this jumper since it's not needed because of the new public Orphinit release 😀

Is there anything needed to be done in Windows or will it automatically switch to using OPL3 now (after we move the jump and change the card type to OrpheusII of course). Am I supposed to disable anything?

This is what my system device manager looks like in Windows 98SE, hasn't really changed any since flipping the jumper or running orphinit with the new version.. Just wonder if I am missing something?