Looks like only change was the input cap, shouldn't make a difference.

The default BIOS settings work for me, I assume your SoM has the same BIOS as me.

There looks to be a slightly concerning blob of solder between C6 and C31?

Also perhaps clean flux from around crystal, sometimes they can be finicky.

I guess double check your SoM soldering on the ISA lines as you say.

EDIT : oh and actually, you said your voltage was like 4.7 - try getting it closer to 5v. Use a different supply or cable. Possibly the crystal chip doesn't like the lower voltage.

C6 and c31 are not continuous.

I was using a front desktop PC USB 2 port for power to get 4.7 V. After using a dedicated wall socket adapter (5 v, 1A), I'm getting 4.93 V and... still no cigar.

I'll be the proud owner of a hot air gun and more crystal chips within 5-6 days....

Another problem to solve: rework the ps2 splitter cable I got (I have such bad luck with adapter cables). Do you happen to have the exact pinout needed? Even the keyboard plugged into the keyboard split will not be recognized.

Mu0n wrote on 2021-06-08, 17:55:

Another problem to solve: rework the ps2 splitter cable I got (I have such bad luck with adapter cables). Do you happen to have the exact pinout needed? Even the keyboard plugged into the keyboard split will not be recognized.

The pinout is in the schematic on Circuitmaker. Some splitters have the mouse and keyboard inputs switched from my design. Try plugging the keyboard into the mouse input and vice versa.

Good luck with the hot air rework, hopefully that fixes it.

Got my new CS4237B-KQ chips, soldered one of them much faster than the first attempts. I checked for continuity between each pad and top of leg (good) and no continuity between adjacant legs (good).

Good news: I've gotten farther than ever before for my sound chip detection
Bad news: only the PC speaker works (soft volume) so far
More good news: the joystick port works!

I'm wadling in a driver swamp. I don't exactly know what to use between the many options found at:
http://www.vogonsdrivers.com/getfile.php?fileid=925

Here are some screenshots of some diagnostics I'm getting:

only using unisound did not work. Maybe I've screwed up the EEPROM burning (despite verifying after burning and getting a confirmation), maybe I've screwed it up by software.

I'm getting PC speaker music out of planet x3, pc speaker output for channel 1 out of some midi files in midpak, but nothing else I've tried works (adlib jukebox, sb16 diagnose.exe, warcraft 1).

Question 1: exactly which driver has to be used out of http://www.vogonsdrivers.com/getfile.php?fileid=925 (or from elsewhere) under DOS?
Question 2: same, but for win98se
Question 3: is there really no tweaking to do in the bios first?

My SOM is only solidly inserted into my pcb mating pins. The screws that came with the SOM are not long enough to go through it and also through the PCB. I'd need some kind of risers, but I haven't kept these things from my 386 and pentium 1 days. I also tried to shop for M3.5 (3.5 mm diameter) screws at a local hardware store, but they only mostly stock imperial screws and only have a few options for metric ones (M4 is the smallest diameter). There is a very small chance some SOM pins are not making contact (INT pins for the ISA side), but since everything else is working, I'm pushing to get a software solution at the moment.

I'm not familiar with this particular project, but have some familiarity with the CS4237. They can be quite picky about their EEPROM content, sometimes to the point where a sufficiently corrupt EEPROM will cause the chip to enter a “coma” state, in which it won’t enumerate or initialise properly under any circumstances. So, to start with, what did you program into the EEPROM, and what did you use to get it there? Secondly, if you run this tool under DOS, what output do you see? This won’t do anything useful for you yet, but it will tell us if the CS4237 can be found as part of the usual Plug-and-Play protocol.

640K!enough wrote on 2021-06-18, 05:27:

I'm not familiar with this particular project, but have some familiarity with the CS4237. They can be quite picky about their EEPROM content, sometimes to the point where a sufficiently corrupt EEPROM will cause the chip to enter a “coma” state, in which it won’t enumerate or initialise properly under any circumstances. So, to start with, what did you program into the EEPROM, and what did you use to get it there? Secondly, if you run this tool under DOS, what output do you see? This won’t do anything useful for you yet, but it will tell us if the CS4237 can be found as part of the usual Plug-and-Play protocol.

To program it, I used this project's instigator's (rasteri) ROM file, which he used successfully in 2 projects already. I programmed it using my TL866II plus with XGpro v10.15. I did not have a clamp so I went full janky style, as described in this post:
Re: Tiny Vortex86-based DOS gaming PC - weeCee

Using this command under autoexec.bat:

cs4232c /v /o /ccs4232.ini

(/v is verbose, /o overrides the Eeprom, /c declares which ini file to use)

I get this:

So far, the drivers I've messed with the most is found at: http://vogonsdrivers.com/getfile.php?fileid=925
and it's under version: CWD-v180-1997 dos-latest

Interesting. Made some headway with resource.exe, found in a discussion specifically for the cs4237 on vogons, here: Crystal 4237 soundcard: looking for NOPNP36.BAT to disable PnP in eeprom

Here's my process (using the contents of cs4237.zip)
resource.exe
A to control logical device address, attempt to use 0x538. Sometimes it works, sometimes it forces me to use 0x120
E for eeprom read
P for screen dump

Uh oh, here's what I get:

I'll attempt to write back the correct bin file using resource.exe, but I have low hopes. I feel uneasy desoldering this tiny thing, soldering back wires and reprogramming it. Anyway, it should not even matter since there are overriding options.

Do I have a 2nd dud chip in a row? Talk about unlucky.

There is no evidence, so far, to suggest that the chip is defective. If what you're showing is correct, then the EEPROM is either not soldered correctly, or is (mostly) blank. This is much better than it being corrupted. For now, please try the attached tools.

The first thing to do is use a more recent version of the Crystal software (or UNISOUND). From the archive you linked before, the software in the v286 directory should work for you. So, let's start gradually. You will have to compensate for the blank EEPROM before you can successfully initialise the chip. Extract the attached archive into an empty directory. Then:

1. Run FIXRDP again and post the output.
2. Change to the directory containing the attached tools, and run HOSTLOAD.EXE. Take a photo and post the output.
3. Run FIXRDP one more time, take photo, post output.
4. Now, if you see the ID as CSC7537 on the last line of the FIXRDP output, the chip should be in the correct state.
5. Change to the directory where you installed the newer Crystal tools, make sure CWDAUDIO.INI reflects the desired configuration, then run "CWDINIT /o /v" (without the quotes).
6. If that looks like it worked, run "CWDMIX /d" (again, no quotes).
7. Test the card with the old Ad Lib TEST.EXE and other tools, to see if you get sound.

If all of that appears to have worked, you are ready to try re-writing the EEPROM. Re-boot, then repeat steps 1 through 4 above. Now, use RESOURCE.EXE to write the EEPROM. The attached archive contains a file called CS4237B.ASM, which should contain a usable EEPROM configuration. Use "RESOURCE /r=CS4237B.ASM /e", take a photo and post the results. If that worked, you should have your sound problems solved. Re-boot one more time, run FIXRDP and post the output to prove that everything worked. If it did, when you boot to DOS, you only need "CWDINIT /v /o", and to set the mixer values as you wish. Also, if the EEPROM writing was successful, you can also use UNISOUND.

640K!enough wrote on 2021-06-18, 16:28:

[*]Run FIXRDP again and post the output.

640K!enough wrote on 2021-06-18, 16:28:

[*]Change to the directory containing the attached tools, and run HOSTLOAD.EXE. Take a photo and post the output.

I've attached the output as a text file

640K!enough wrote on 2021-06-18, 16:28:

[*]Run FIXRDP one more time, take photo, post output.

640K!enough wrote on 2021-06-18, 16:28:

[*]Now, if you see the ID as CSC7537 on the last line of the FIXRDP output, the chip should be in the correct state.
[*]Change to the directory where you installed the newer Crystal tools, make sure CWDAUDIO.INI reflects the desired configuration, then run "CWDINIT /o /v" (without the quotes).
[*]If that looks like it worked, run "CWDMIX /d" (again, no quotes).

640K!enough wrote on 2021-06-18, 16:28:

[*]Test the card with the old Ad Lib TEST.EXE and other tools, to see if you get sound.

Nope (and planet x3 doesn't output sound either when I select adlib). pc speaker sound still works (I mention this because the sound chip mixes whatever the system-on-module gives it as square wave beeper sound into its single audio output).

640K!enough wrote on 2021-06-18, 16:28:

Use "RESOURCE /r=CS4237B.ASM /e", take a photo and post the results.

Even if adlib output isn't working, I tried the above and I get:

I'm also noticing using resource.exe normally tells me the same eeprom not found errors with the E command, even if I load the control logical device first

A command yields: (0x538) Control Logical Device Address:
CS4237B CONTROL Found
E command yields: EEPROM not found
F command yields:
----
Override values found from driver
----

CS4237A (4):
Looking for CTRLbase at 0x538
CS4237B ID Found
CS4237B Firmware Version Number [1C1] = 193

i command loads up the internal codec IC data
and P command seems to output it right. It's bigger than before, so I've made progress there I guess!

I don't know if this is a dumb suggestion but why not use the FLASH package from Orpheus website?
just alter in the INI you will use the "GlobalConfigBits = " line to include IFM and change the name string... it should write the eeprom and tell you if it's all good ( flash.com is just a batch file that uses RESOURCE.EXE)
at least you will know that the eprom data are not weird - since it works on Orpheus - and you can maybe focus on some other area?

From that, we know that the chip is not entirely defective. It shows that the hostload process worked, and you ended up with the correct plug-and-play ID. From there, instead try running UNISOUND, post the output, and check for sound again. If not, repeat with CWDINIT, and post that output as well.

It is worth pointing out that the hostload process is not permanent, and must be repeated after every boot.

EDIT: Now that keropi brings that up, the data I used for HOSTLOAD was missing the IFM setting. I will fix that and be back in a few minutes.

These should do the trick. With the updated files, replace those in the HOSTLOAD package, and try again.

keropi wrote on 2021-06-18, 18:41:

I don't know if this is a dumb suggestion but why not use the FLASH package from Orpheus website?

That depends whether the chip will have (or allow) the control port to be configured directly, without first having the correct hardware configuration data. It might work, since it has a valid PnP ID, but I wouldn't bet on it. Anyhow, there would be no harm in trying that as well.

640k!enough, keropi, OMG, I really, really appreciate your magical, on-point help. It freaking works. The corrected bin file did the trick in hostload!

adlib\test: sweet, sweet cheesy music outpours
planet x3 in adlib: works
sb16\diagnose: error
softmpu runs and says: mpu-401 detected at port 330, but also Error: Sound Blaster not detected at port 220 IRQ 5

sound blaster sound effects seem to not work yet everywhere I look.

Mu0n wrote on 2021-06-18, 19:33:

640k!enough, keropi, OMG, I really, really appreciate your magical, on-point help. It freaking works. The corrected bin file did the trick in hostload!

That means the chip is at least partially functional. Did you try writing the new ASM file to the EEPROM? What was the result? Using UNISOUND may help get it set up for SB compatibility more easily, and take care of the mixer.

If SB functionality continues not working, it may be a soldering problem, or that the module is not seated/held in place well enough.

This is such a awesome project to follow. What I really love is how this community worked together a got the sound working.

640K!enough wrote on 2021-06-18, 19:37:

That means the chip is at least partially functional. Did you try writing the new ASM file to the EEPROM? What was the result? Using UNISOUND may help get it set up for SB compatibility more easily, and take care of the mixer.

If SB functionality continues not working, it may be a soldering problem, or that the module is not seated/held in place well enough.

resource /r=cs4237b.asm /e

Reading data from CS4237B.ASM
EEPROM not found

unisound does not complain but has no positive effect on the state of things.

so the issue is the eeprom? maybe that chip you used is not good for the 1997 CS4237?
is BRA14E00.INC present in the current directory so resource.exe finds it?

keropi wrote on 2021-06-18, 20:34:

so the issue is the eeprom? maybe that chip you used is not good for the 1997 CS4237?
is BRA14E00.INC present in the current directory so resource.exe finds it?

The chip is fine. It was used in rasteri's earlier PC-104 custom designed (by him) sound card (which used the same audio chip as well) and this current project I'm trying to replicate. It seems to be within the guidelines of resource.exe's documentation in terms of size.

https://www.mouser.ca/ProductDetail/579-24LC04BSN

I'll try with bra14e00.inc. I also used the Orpheus flash utility but it complains about the eeprom too. I did not always get eeprom errors - earlier posts from me in this thread has me succesfully getting something of a read from it.

edit -

the BRA14E00.INC file was present in my orpheus folder. It does not prevent an EEPROM error.
I tried swapping out my system-on-module (since I'm building 2 total) while also cleaning any dirt particle (there were a few) between its pins, but nothing has changed. I'll try to reflow the EEPROM pins next, it doesn't sit perfectly flat and relies on big blobs. pins 1-4 are all GND anyway (continuity was tested), so it could either be the chip itself, or the last 4 pins (although pin 6 is also GND and was contiguous with the others),

I reflowed the eeprom pins. I can read it again! but I can't write.
this mimicks what rasteri experienced in his 2 projects. He used the TL866ii programmer like I did originally!

The error I'm getting is:

Reading data from CS4237.BIN
ERROR: Unable to write EEPROM
EEPROM not programmed

I'm still wondering if I should put something in R10 (right now it's unpopulated) or short its pins to put it high and if it would help the writing process
it connects to the CS4237B to its SCL pin 16.

This would make pin 6 (7th of 😎 on the EEPROM labeled 'SCL' go to 5V instead of...floating? However, earlier I was reading a thread where you, keropi, talk about pin7 being set to GND to disable write protection! Re: Crystal 4237 soundcard: looking for NOPNP36.BAT to disable PnP in eeprom
so maybe....a bodge wire is in order?

I think I'll receive a special clamp to help reprogram it by Tuesday, I'll try then I guess.

EDIT: WHAAA

sound blaster sound works...somewhat now.

crystal drivers v180 in cwdiag, everything passes and I can FINALLY play a test sound and it works
sb16/diagnose still doesn't work
dune accepts my setup sound card but plays nothing
starcontrol 2 loads with sb digitized music (but crashed when saving)

next step is obviously...DOOM and everything id software.