How do I see if the revision is shown? I can't see anything obvious, even on the one that gives *some* data..

The one that gives some data has a line on the log that reads:
CS4237B, rev E found.

This is the latest chip revision available

ltning wrote on 2023-06-12, 14:52:

How do I see if the revision is shown? I can't see anything obvious, even on the one that gives *some* data..

The line that keropi mentioned is exactly what we're looking for. If it can get to that point, it means that the chip has been assigned basic resources, we can check the chip status, and also correctly read the ID registers. In general, this is a good starting point.

Sorry it took me a while, the test bench was busy with another project of mine :-/

1EEPROM reset successfully.
2Page-write command sent.

The output of subsequent orphinit /vd is *exactly* the same as the one I posted earlier (forex), byte-for-byte, confirmed using FC (DOS file compare).

What now? :)

Tested on a different MX-chipset board (which is the same chipset I have in the first machine I reported about). It inits, but only after one or two SLAM attempts. Typically it needs two the first time after boot, and only one afterwards (or after a warm boot). This is with a 386DX CPU; the other board has a 486DLC (but same socket).

Log attached.
/Eirik

ltning wrote on 2023-06-19, 18:37:

Tested on a different MX-chipset board (which is the same chipset I have in the first machine I reported about). It inits, but only after one or two SLAM attempts. Typically it needs two the first time after boot, and only one afterwards (or after a warm boot). This is with a 386DX CPU; the other board has a 486DLC (but same socket).

I think some of this is starting to make a little bit of sense, but I still have to make sure I understand the details of what you've been testing. So, please confirm the details for me:

1. You ran the EEPROM clearing tool on the FOREX/UMC machine, and it still produces exactly the same output.
2. What is the configuration of the above-mentioned machine?
3. You then moved the same card to another MX-chipset machine, this time with a 386DX, and it is now behaving mostly as expected (more on this in a moment).
4. Between the MX-chipset machines, is the configuration exactly the same, right down to bus speed, ISA clock and timing configuration, as well as BIOS options, except that one has a 386DX and the other a 486DLC?

Part of the reason that we are seeing the behaviour that you observed on the 386DX-based MX-chipset machine is that we just cleared the critical part of the EEPROM. If your other card still has the original EEPROM content intact, you should see exactly the correct behaviour with that card, if installed in the 386DX-MX-machine. We can restore the proper content later, so that won't be a permanent problem for you, but having the two cards configured differently may end up being useful in testing, so it may be a good idea to leave it as is for now.

If we can't make any satisfactory progress on this issue, and you really want to use the card in one of those machines, I should be able to put together some alternate init tools for you to test. So, if nothing else, that should get the card working in those machines, and the changes would eventually have to be integrated into ORPHINIT. However, that feels like a bit of a dirty, last-resort solution. Now the burning question is: what is different about those machines that causes it to break, and can we fix it at the software level, so that it works as designed (without additional kludgey changes)?

igna78 wrote on 2023-01-19, 19:29:

A question: is there a driver OPL3 for Windows 3.x ?

Yes, the Voyetra SuperSAPI! driver. Unlike the generic Microsoft driver, it uses 4-op instrument patches and takes full advantage of the OPL3 vs. the generic Microsoft one.

Ok thanks a lot..the name of this driver is not new to me: could it be that I encountered it at the time of Sound Blaster 16 and Windows 3.11?

It was 1993 and for Christmas my dad gave me an IBM PS/1 mod. 2133
It was my first DOS/Windows PC, it was 486SX based, 2MB RAM, CL-5424 video card with 512k memory, floppy and 85MB HHD.
Gradually I upgraded the PC with Sound Blaster 16 + Creative MPC2 CD-ROM and up to 10MB of RAM.

I remember that it came bundled with MS-DOS 6.0 and Windows 3.11. When I installed the Sound Blater 16 under Windows if I'm not mistaken, the Voyetra SuperSAPI driver was installed.

Depending on the driver revision, Creative used the SuperSAPI driver in their SB16 software bundles. Circa 1993 would be about right, the bundle that came with that mosaic puzzle game generally had the driver.

Heyo. So, I just got my Orpheus II LT in the mail just yesterday and I've been having a ball with it. Just one issue to report regarding ORPHINIT that I think should be quite important, if it hasn't been mentioned already.

The mixer settings don't seem to work. The volume is fixed at a higher level, making it extremely loud with no way to change it. I've tried different settings under the ORPHEUS.INI file with no effect. The only way I was able to adjust the mixer under software was to use UNISOUND and that worked. Though, the only downside to that was that I couldn't use the external Yamaha OPL3 on the Orpheus II LT.

DoomGuy II wrote on 2023-07-09, 13:44:

The mixer settings don't seem to work. The volume is fixed at a higher level, making it extremely loud with no way to change it.

Please describe the situation in more detail, namely:

1. Post your existing ORPHEUS.INI.
2. Run ORPHINIT /vd > ORPHINIT.LOG and post the resulting ORPHINIT.LOG.
3. Which software, specifically, are you trying to run?

The most likely cause is that your ORPHEUS.INI includes the setting mode=sb, while you are still trying to set volume levels in the mixer section, which is only for WSS mode. When initialising into SB mode, you are forced to use the more primitive SB Pro mixer, which has separate settings in the sb-mode section (usually toward the end of the file). Perhaps this should be more clearly documented. If you weren't already doing that, please try. If that still doesn't work, then there may be a problem.

Another thing of which you should be aware is that the volume registers are reset if you run WSS-compatible software, then go back to running SB software. The only "solution" there is to re-initialise into SB mode with your preferred mixer settings.

640K!enough wrote on 2023-07-10, 02:35:

The most likely cause is that your ORPHEUS.INI includes the setting mode=sb, while you are still trying to set volume levels in the mixer section, which is only for WSS mode. When initialising into SB mode, you are forced to use the more primitive SB Pro mixer, which has separate settings in the sb-mode section (usually toward the end of the file). Perhaps this should be more clearly documented.

Yeah... I was about to say. I actually did find out about the 'sb-mode' mixer settings in the ORPHEUS.INI file a bit later on when fiddling with the config file. Now I feel kinda stupid because I was actually playing around with the "PCMVol" and "FMVol" settings when trying to adjust the volume. Didn't even pay attention to the 'mode' setting that I scrolled through either.

So, I did some testing making sure I'm adjusting the sb-mode mixer settings and it is indeed working. Yeah, it was kinda confusing for me at first, but I was able to configure it accordingly. Granted, the 'SB-PCMVol' and 'SB-FMVol' settings do nothing. Only the master volume works in this case. Though, I haven't tried the other SB volume settings to see if they are affected as well.

EDIT: Actually did some testing with Xargon in combination with MIDIto, which is a program that allows me to lock SB mixer settings, and I was able to adjust the volume for PCM and FM synth. Was testing DOOM before this. It was probably ignoring the mixer settings in ORPHINIT and instead uses its own as obviously noted by its adjustable volume sliders under the options menu. But aside from that, everything seems to be working now.

DoomGuy II wrote on 2023-07-10, 14:53:

So, I did some testing making sure I'm adjusting the sb-mode mixer settings and it is indeed working. Yeah, it was kinda confusing for me at first, but I was able to configure it accordingly. Granted, the 'SB-PCMVol' and 'SB-FMVol' settings do nothing. Only the master volume works in this case.

I will have to disagree with the claim that there are any non-functional SB Pro mixer features (other than the ability to control the low-pass filter, which is not implemented). This has been fairly extensively tested, and each of them is fully functional, including PCM and FM volume control. Now if software performs a mixer reset or changes the values, that doesn't mean that ORPHINIT hasn't done its job, nor that the features don't work as documented.

DoomGuy II wrote on 2023-07-10, 14:53:

EDIT: Actually did some testing with Xargon in combination with MIDIto, which is a program that allows me to lock SB mixer settings, and I was able to adjust the volume for PCM and FM synth. Was testing DOOM before this. It was probably ignoring the mixer settings in ORPHINIT and instead uses its own as obviously noted by its adjustable volume sliders under the options menu. But aside from that, everything seems to be working now.

DOOM is one of those disrespectful designs; it maximises the volume settings (particularly PCM), and appears to manage the volume level in software, as part of its audio rendering routines. This makes some amount of sense, since the SB Pro mixer is rather crude, and other cards without a mixer are also supported. It looks like they decided on a one-size-fits-all approach to audio processing, as further evidenced by the way they used the UltraSound.

Would it be possible to disable the wavetable port through ORPHINIT?

I recently got WP32 McCake for my Orpheus and happened to notice some games that used to work just fine had gone completely silent, but if I disable the wavetable port with P0 variable with UNISOUND they start to work fine again. I've noticed this happening only with freeware games that don't have any kind of setup program where you could specify your sound card, so I guess the way they sniff out the sound card automatically craps out if a wavetable card is installed for whatever reason.

I can work around this using UNISOUND, but it would be more convenient for me to have this functionality also in ORPHINIT.

Sombrero wrote on 2023-07-20, 15:26:

Would it be possible to disable the wavetable port through ORPHINIT?

I recently got WP32 McCake for my Orpheus and happened to notice some games that used to work just fine had gone completely silent, but if I disable the wavetable port with P0 variable [...]

yes it is possible to do this by editing this section on ORPHEUS.INI to look like this:

1; This controls the on-chip Crystal MPU-401-compatible UART.
2; This tool has NO control over the PCMIDI device, which is configured
3; with on-board jumpers.
4MPUBase=disabled
5MPUIRQ=disabled

then CS4237 MPU device is disabled and works the same as P0 variable
you can create multiple INIs and have orphinit use them on demand

keropi wrote on 2023-07-20, 17:03:

yes it is possible to do this by editing this section on ORPHEUS.INI to look like this: […]
Show full quote

Sombrero wrote on 2023-07-20, 15:26:

Would it be possible to disable the wavetable port through ORPHINIT?

I recently got WP32 McCake for my Orpheus and happened to notice some games that used to work just fine had gone completely silent, but if I disable the wavetable port with P0 variable [...]

yes it is possible to do this by editing this section on ORPHEUS.INI to look like this:

Copy code to clipboard

1; This controls the on-chip Crystal MPU-401-compatible UART.
2; This tool has NO control over the PCMIDI device, which is configured
3; with on-board jumpers.
4MPUBase=disabled
5MPUIRQ=disabled

then CS4237 MPU device is disabled and works the same as P0 variable
you can create multiple INIs and have orphinit use them on demand

Right, I forgot to mention I've got PCMIDI on the board and I've disabled the Crystal MPU completely with EEPROM. I've also kept those settings on the .ini as default disabled. Kinda forgot the card even had two ways to use the wavetable.

I hope also PCMIDI can be disabled somehow with ORPHINIT since UNISOUND can do it too?

PCMIDI cannot be disabled, it can exist either in ports 300 or 330 with a selected IRQ
ORPHINIT/UNISOUND do not affect or control PCMIDI in any way - so if unisound works with P0 then PCMIDI is irrelevant to the situation

Unisound follows what's in autoexec.bat I think.

Sombrero wrote on 2023-07-20, 17:41:

Right, I forgot to mention I've got PCMIDI on the board and I've disabled the Crystal MPU completely with EEPROM. I've also kept those settings on the .ini as default disabled. Kinda forgot the card even had two ways to use the wavetable.

I hope also PCMIDI can be disabled somehow with ORPHINIT since UNISOUND can do it too?

At the risk of repeating some of what has already been mentioned, there are a few points to consider:

• No software can configure the resources used by the PCMIDI portion of the card; not UNISOUND, not ORPHINIT, not the BIOS, not Windows. It is configured by the on-board jumpers only, and disabled is not one of the available options.
• ORPHINIT does not read the EEPROM beyond device ID and serial number; none of the remaining data are processed at all. If you tell it to configure the Crystal MPU module, it will do it, regardless of EEPROM content or potential conflicts. The way it is implemented, avoiding resource conflicts is your responsibility.
• If you are using an Orpheus II, you need to be sure that no resources are assigned to the InterWave MPU-401 emulation. If you've installed it the way keropi suggests, this would be in IW.INI. I don't know if UNISOUND handles this aspect of the configuration; if that's what you're using to configure the InterWave, please consult its documentation.
• No EEPROM images have been provided to disable the Crystal MPU-401 features for Orpheus II, as far as I'm aware. What did you use?
• Is this a strictly pure DOS environment, or are you mixing DOS/Windows? If you're under Windows, why are you still using ORPHINIT or UNISOUND?

Based on your description so far, something doesn't add up. If you want us to be able to figure out what's going on, please include your current ORPHEUS.INI, IW.INI and/or UNISOUND environment variables and command lines (for all cards), describe your complete configuration, and provide pictures of the jumpers on the Orpheus (II) card.

all OrpheusII cards have the "emulation assistance" InterWave devices disabled in firmware , so no mpu401/sb are available on the GUS side of things
And there is no "crystal mpu disabled" firmware for OrpheusII since it's not really needed with the way orphinit and unisound work.
If someone really needs a csmpu-disabled firmware you can ask for one but so far noone had any issues or need for it.
Sure the occasional resource issue happens with OrpheusII that is basically 3in1 design but the support requests are far less than what I anticipated - which is a good thing 😀