Hello!
Soon Windows9x drivers will be added.

KuroHouou wrote on 2023-01-19, 18:02:

[...]
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)

the OPL3 will be detected as an "Yamaha OPL2/OPL3" and it will be available as an output device (maybe it gets detected as Adlib Gold too, it's just naming scheme though, I can't remember exactly atm)
will do some testing over the weekend to make sure stuff work and will upload a set of drivers on the LT site but it would be the same as what is available now , just in a single package
as always the usual 9x driver shenanigans might apply and a fresh install might be needed depending the driver history of the system used...

Great, ill wait on updated Windows drivers then. Will test everything out in DOS for now 😀

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

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

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

Sadly none that I know about

keropi wrote on 2023-01-19, 19:54:

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

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

Sadly none that I know about

I see. So, to use Orpheus II LT in Windows 3.x will the Crystal drivers that we used for Orpheus I be used? And in this case, will the jumper modified to select OPL3 in the DOS environment be restored to the position prior to the release of the new OrphINIT?
Sorry for so many questions 😄

igna78 wrote on 2023-01-20, 09:43:

I see. So, to use Orpheus II LT in Windows 3.x will the Crystal drivers that we used for Orpheus I be used? And in this case, will the jumper modified to select OPL3 in the DOS environment be restored to the position prior to the release of the new OrphINIT?
Sorry for so many questions 😄

Crystal drivers for 3x will activate the internal CSFM block so the jumper will become irrelevant to the card and can be left in whatever position
the fact that win3x drivers even exist it's a miracle, sure they are not anything special but it's better than nothing

I use FreeDOS. I'm getting this when I run ORPHINIT with JEMM. With EMM386 (or nothing) it works fine.

UNISOUND works so I'll use that for the time being, but I wanted to let you know.

commander_spuds wrote on 2023-06-01, 22:29:

I use FreeDOS. I'm getting this when I run ORPHINIT with JEMM. With EMM386 (or nothing) it works fine.
4032-3024-max.jpg
UNISOUND works so I'll use that for the time being, but I wanted to let you know.

This is certainly peculiar; I only had time to test briefly, but that hasn't been my experience at all. The last time we had a similar report, it ended up being due to a corrupt copy of ORPHINIT.

If you can confirm that that isn't the case, can you include a little more detail about your hardware configuration, as well as ORPHEUS.INI, FDCONFIG.SYS, etc.? Which generation of Orpheus card are you using? Particularly interesting would be the output of ORPHINIT /vd, which might offer a slightly better idea of what was going on at the time.

I've just started playing with my OrpheusII, and I'm getting "Unidentified chip found; quitting.".
Using default .ini file. This is a non-PnP system. Only other card installed is a 3com 3c509 (Etherlink III); I can try to change its IRQ and port (currently 10 and 300), but doubt that will make a difference..?

ltning wrote on 2023-06-10, 22:49:

I've just started playing with my OrpheusII, and I'm getting "Unidentified chip found; quitting.".
Using default .ini file. This is a non-PnP system. Only other card installed is a 3com 3c509 (Etherlink III); I can try to change its IRQ and port (currently 10 and 300), but doubt that will make a difference..?

Something strange appears to be happening here. If you don't mind a little bit of collaborative, back-and-forth trouble-shooting, we should be able to get the issue(s) sorted. Just to confirm, we are dealing with Orpheus II, rather than Orpheus II LT, correct?

You mentioned that your ORPHEUS.INI is the default file. Did you make sure to set the cardType correctly? Please double-check this, as it is still mandatory, for now, to get the card working correctly.

To get a better idea of what we're dealing with, there are two things that would help:

1. A more complete description of your hardware configuration.
2. The full debug-level output from ORPHINIT. The easiest way is to issue the command ORPHINIT /vd > ORPHINIT.TXT then post the resulting ORPHINIT.TXT file.

Hey, thanks! Happy to ping-pong :) But I'm not physically at the machine until later today. If you're on IRC or Discord or the fediverse or something, we could do "real-time" ping-pong if you'd like.

640K!enough wrote on 2023-06-11, 03:38:

Something strange appears to be happening here. If you don't mind a little bit of collaborative, back-and-forth trouble-shooting, we should be able to get the issue(s) sorted. Just to confirm, we are dealing with Orpheus II, rather than Orpheus II LT, correct?

Yep, this is the full Orpheus II.

640K!enough wrote on 2023-06-11, 03:38:

You mentioned that your ORPHEUS.INI is the default file. Did you make sure to set the cardType correctly? Please double-check this, as it is still mandatory, for now, to get the card working correctly.

I started out with version 0.54, then upgraded to 0.57 and tried with both my old (slightly modified, volume settings and WSS IRQ only) and the new (straight from the ZIP) .INI files. Both versions, and both INI file variations, produced the same result.
And yes, the cardType is set correctly in the 0.57 .INI by default.

640K!enough wrote on 2023-06-11, 03:38:

To get a better idea of what we're dealing with, there are two things that would help:

• A more complete description of your hardware configuration.

So the motherboard is something similar to a TK TK83305-4N-D-03. I say similar because it's not a perfect match for
https://theretroweb.com/motherboards/s/tk-tk83305-4n-d-03
but either way BIOSes and such are interchangable between a lot of these boards. I'm using the AMI BIOS from TRW.

CPU is a TI 486DLC-40. Cyrix 3x87 FPU. Chipset has 8KB built-in L2 cache. ISA bus speed set to CPUCLK/5 (so <40MHz), and plenty of cache read/write wait states configured (to make sure this is not an issue). 32MB 60ns RAM.

Other hardware:
- 3c509, IRQ10, I/O 300, 8KB XTIDE at C800H
- UMC HDD/FDD/IO: IRQ14+15 HDD, FDD, EPP and one serial port enabled with standard config
- ATI Mach64 2MB DRAM

640K!enough wrote on 2023-06-11, 03:38:

• The full debug-level output from ORPHINIT. The easiest way is to issue the command ORPHINIT /vd > ORPHINIT.TXT then post the resulting ORPHINIT.TXT file.

I can get you that later, when I'm at the keyboard :)

640K!enough wrote on 2023-06-11, 03:38:

• The full debug-level output from ORPHINIT. The easiest way is to issue the command ORPHINIT /vd > ORPHINIT.TXT then post the resulting ORPHINIT.TXT file.

Attached.
Without a baseline I don't know how this should look (I'll test my other card in another machine in a bit), but one thing caught my eye:

1PNP_isolate_all_cards() begin.
21e560001                CSN:  1 Isolation result:  0
300000000                CSN:  1 Isolation result:  4

Is it possible the PnP code in the chip/on the card eeprom is bad?

Completely unrelated: The newline after the version number seems to be weird - less(1) shows it as <E1> control character. If this is the same thing that UNISOUND does, it explains why it's so hard to capture and parse the output in DOS. I have a bunch of BAT files that capture the output using FIND, but it often finds(duh) two lines when there should be only one - because it doesn't recognise the linebreak..

/Eirik

So the card works in a different machine - I guess this is hardware-dependent then. That's a bummer :(

Also FYI the Ctrl port of 120 as seen in the log is because I forgot to change it back to the default after experimenting with something I found earlier in this thread (or on a different orpheus/orphinit thread). The result is the same with the defaults.

I've also put the second card into this machine after confirming it works in the 286; it behaves the same way as the first one.

What to do, what to do..?

for what it's worth I have found so far 2 generic motherboards that do not work at all with PnP soundcards:
- a 286/16 board using the HT/16 chipset
- a 386sx board using some ALI chipset (IIRC)

both refuse to work correctly with CS4237/ALS100/CMI8330 either with old cards or the new ones we make - unisound/orphinit/original drivers nothing helps
symptoms range from complete non-working sound or portions of it working (you only get FM or MPU)
I have spent much time especially on the 286 system in order to find out why the cards fail, replaced many components on it just to be sure but ultimately it was wasted time and I have no idea why this happens...

The 286 on which it *works* is a C&T SCAT board, 12MHz CPU.
The 386/486 on which it *fails* is linked in my post above.

If I have to rip that machine apart again now and replace the motherboard I'm going to be more than a little bit annoyed (but not at you, obviously) :D

IMHO this is a blessing in disguise 🤣
that MX chipset with it's 8kb of internal cache is kinda bleh - had one at some point in the past
128kb full power cache system is needed 🤣 🤣 🤣

keropi wrote on 2023-06-11, 18:46:

IMHO this is a blessing in disguise LOL
that MX chipset with it's 8kb of internal cache is kinda bleh - had one at some point in the past
128kb full power cache system is needed LOL LOL LOL

If I could find a board like that which likes my TI CPU and manages to enable the internal and external cache without introducing crashing bugs ..
Also I've spent so much time on this project and this is precisely the board I wanted, so there I am :-(

Interesting tidbit I found when installing the Intel ISA configuration Utility:
After configuring things (as expected it only finds the InterWave), during boot I see it complaining like this:

1WARNING: Bad Resource Data Checksum (VendorID 100561E) expected=F8 actual=0

This seems to be the Gravis ID, just reversed byte order. Not sure if it matters for any reason, but there you go. Not helping with the ESS issue, I guess :(

/Eirik

Tried on a different 386 board now - FOREX/UMC based. Debug output attached; this time it seems like it can see the ESS - but not in the PnP card list, and after trying a couple of times it gives up.
Interesting times :)

Something is definitely very strange. At least the most recent machine seems to be somewhat able to communicate with the CS4237, in that it assigns the basic resources, then can identify the chip revision. So, I would suggest using a tool I shared in another thread, that will clear the first page of the EEPROM connected to the CS4237. Basically, you first run ORPHINIT as you have been, making sure that the control port is configured for 538H. Look for the line that correctly identifies the chip revision. Only if you see that, proceed to use this tool to try clearing the first page of the EEPROM. If you can, post the output from that tool.

If it runs successfully, re-boot and try ORPHINIT again. We are not necessarily expecting it to work yet, but we again want the full debug-level output, in particular the list of Plug and Play devices. If that works and the device list looks a little more sane, we should be able to write the correct content again.