Eivind wrote on 2023-06-23, 05:39:

Huh, interesting about those integrated RDC components!
There is a file system compatibility warning under "Performance", but only for the A: drive. Picture below.
As for signs of fs corruption - haven't seen any! 😀 Happy to run tests, if you have anything specific in mind?

They mentioned (at least) two versions of the DX SOM. I would guess that the one we have been familiar with so far has the R1011 (curiously, sometimes listed as D1011 with the same IDs), and requires a dedicated driver. The other one mentioned can apparently use standard MS or PIIX drivers. I would now conclude that it is not a part licensed from Intel, but the R1012, like you have here. This leaves me to wonder: if the R1011 was affected by broken CRC hardware that resulted in FS corruption, has it been corrected on the R1012? Is this an all-new design or an evolution of the R1011?

Given that there were multiple versions of the DX, is there any evidence that an EX with R1011 exists? Do all of yours have the R1012?

In any case, there were a few reports of (different) problems with the R1012. I suspect you'll know soon enough if there is file system corruption, but if you want to specifically test for it, one way to start might be to repeatedly download a somewhat large file, writing it to disk, then checking the file's SHA256 (or SHA1) fingerprint to ensure that it matches.

I checked the one in the weecee has the device ID of PCI\VEN_17F3&DEV_1011

I'm assuming the device ID of this board and the tinyllama would be PCI\VEN_17F3&DEV_1012 then. will need to boot my tinyllama to check it.

640K!enough wrote on 2023-06-24, 02:16:

In this instance, he'll probably want to limit the possible configurations that are advertised, given that there are fewer resources available on the platform's restricted ISA implementation. If you give the Plug and Play sub-system too many choices, it's liable to choose a combination that you didn't expect, and on this platform, it may not be a usable one.

Exactly, I'm thinking I should limit the configurations to only one known to be working 100%, so no manual changing of resources in Windows would be necessary.
However, I'm facing a somewhat weird situation where I'm apparently not able to reprogram the eeprom using RESOURCE.EXE...

When the CS4237B is brand-new, I can program it using this command:
C:\>resource /f=0x120 /r=cs4237b.asm /e
using the asm file attached.
So, it looks like the chip initially responds to control commands sent to 0x120, right?
However, after this programming (and the cs chip works flawlessly btw, no issues), this same command doesn't work anymore. I'm getting "CONTROL NOT found".
Looking at the asm file, it would appear that the logical device 2 (control) is set to use either 0x538 or 0x120 - but none of these work in RESOURCE (with either A or alt+A).
When using UNSOUND in DOS, it spits out "CTR:120". In Win98, it's reported as 0x538.

I'm trying to understand what all this means - when is this control port actually used (besides reprogramming the eeprom)? When changing volume in Windows for example? That seems to work fine using port 0x538, but why doesn't it work in RESOURCE.EXE...? 😀

@640K!enough - you seem to know this stuff well, care to try and help me out?

Embarrassing... I resoldered the CS4237B just to make sure this wasn't a case of poor contacts.....and it was. RESOURCE can find the chip again at 0x120.
I'll try modifying the eeprom data and see where that gets me.

Eivind wrote on 2023-06-24, 11:07:

I'm trying to understand what all this means - when is this control port actually used (besides reprogramming the eeprom)? When changing volume in Windows for example? That seems to work fine using port 0x538, but why doesn't it work in RESOURCE.EXE...? 😀

The control port is used to check global chip status, for hardware-level configuration, uploading of firmware and similar functions. Mixer control is entirely on the WSS (or SB Pro) side of things.

Is there a particular reason you have the SPS bit set? Unless you're planning on doing digital audio I/O or using some sort of DSP functionality, there shouldn't be any need for it. Is your game port not wired for a second controller?

In either case, you might be better off working from an INI, rather than ASM, file. I don't remember if Crystal's tools will calculate the correct checksum when starting from an ASM file (when it has been modified), or if it will blindly trust the value that is there (even if invalid).

Personally, I'd be more inclined to integrate initialisation of the sound hardware into the board firmware. That would have the added benefit of allowing you to remove the EEPROM and support components altogether, shaving a few dollars off the total BOM.

640K!enough wrote on 2023-06-24, 20:29:

The control port is used to check global chip status, for hardware-level configuration, uploading of firmware and similar functi […]
Show full quote

The control port is used to check global chip status, for hardware-level configuration, uploading of firmware and similar functions. Mixer control is entirely on the WSS (or SB Pro) side of things.

Is there a particular reason you have the SPS bit set? Unless you're planning on doing digital audio I/O or using some sort of DSP functionality, there shouldn't be any need for it. Is your game port not wired for a second controller?

In either case, you might be better off working from an INI, rather than ASM, file. I don't remember if Crystal's tools will calculate the correct checksum when starting from an ASM file (when it has been modified), or if it will blindly trust the value that is there (even if invalid).

Personally, I'd be more inclined to integrate initialisation of the sound hardware into the board firmware. That would have the added benefit of allowing you to remove the EEPROM and support components altogether, shaving a few dollars off the total BOM.

SPS bit: nah, didn't even know what that was. I only took an ASM file I'd tested previously that worked well as a starting point.
I'm sure I'd be much better off working from an INI file - but I couldn't find any for the CS4237B, if you know of one, or better yet, have access to any kind of documentation about the INI format, please let me know! 😀

I managed to trim the fat off of my asm file by leaving only the options I wanted, so they're set as the defaults in windows. Had to figure out how the checksum works as well, that wasn't exactly well documented in the datasheet... Turns out, you take all bytes starting with the line that's commented in the asm file with "PnP version ...." and ending with the second-to-last byte. In other words, don't count the previous checksum byte. Sum all of those bytes, take the lower byte of that result and do a two's complement. That's the new checksum byte.
All of that said - I didn't experiment with flashing anything with the wrong checksum, in fear of having to desolder it.

I think your solution with initializing the CS chip from the board's BIOS is pretty elegant, I might look into that! As for costs, that eeprom is <10 cents, so it wouldn't exactly be the sole reason... 😉

Eivind wrote on 2023-06-24, 20:54:

I'm sure I'd be much better off working from an INI file - but I couldn't find any for the CS4237B, if you know of one, or better yet, have access to any kind of documentation about the INI format, please let me know! 😀

I'll see what I can find, hopefully over the next few days. EDIT: Actually, there are a few fairly well-documented samples in the driver bundle you linked earlier. Those, combined with the datasheet (and maybe a little help), should be enough to do what you need.

Eivind wrote on 2023-06-24, 20:54:

All of that said - I didn't experiment with flashing anything with the wrong checksum, in fear of having to desolder it.

Some care is needed in tinkering with the EEPROM content. If you program it with something sufficiently broken, the CS4237 will end up in what I call the "coma" state. In that condition, it won't initialise at all, using any known method, and won't do anything. Only removal and external re-programming of the EEPROM (or other creative solutions) will be able to get it back to a functional state, but at least it doesn't involve having to de-solder the CS4237 itself. Don't ask me how I know.

Also, be aware that the Crystal tool has certain bugs. When you create a new file, I would suggest first re-loading it into RESOURCE.EXE, then generating the final .BIN file to disk. Re-start RESOURCE.EXE, loading the .BIN, then display the contents and go over the critical parts yourself before programming them. This will avoid unpleasant surprises (see my comment above). 😠

Eivind wrote on 2023-06-24, 20:54:

I think your solution with initializing the CS chip from the board's BIOS is pretty elegant, I might look into that! As for costs, that eeprom is <10 cents, so it wouldn't exactly be the sole reason... 😉

I thought I remembered them being a little more expensive than that, but not needing the EEPROM and a few supporting components is really only the icing on the cake with such a solution. I would never over-estimate the advantages of not having to rely on a separate software initialisation step, and in some cases, having the resources pre-assigned will make things go more smoothly under Windows 9x, too, though I'm not sure how the Windows 3.x drivers would react to that (I haven't even tried them yet).

I'd take a stab at it myself, especially since I have basically all of the CS4237 side of the code written already, but these projects have a habit of wreaking havoc on the budget once you get started with them, and this board is looking particularly big and expensive (4-layer design?).

Duffman wrote on 2023-06-24, 04:49:

I'm assuming the device ID of this board and the tinyllama would be PCI\VEN_17F3&DEV_1012 then. will need to boot my tinyllama to check it.

This was posted just a short while ago, and that unit is 17F3:1012. How well it performs, and whether it suffers from any potentially performance-killing bugs, is still not known.

640K!enough wrote on 2023-06-25, 03:31:

I'll see what I can find, hopefully over the next few days. EDIT: Actually, there are a few fairly well-documented samples in the driver bundle you linked earlier. Those, combined with the datasheet (and maybe a little help), should be enough to do what you need.

Aha! Didn't notice that little "PNP37.INI" file in the "original" folder there. Looks like just what I was looking for. Will try working off that for sure, thanks!

640K!enough wrote on 2023-06-25, 03:31:

Some care is needed in tinkering with the EEPROM content. If you program it with something sufficiently broken, the CS4237 will end up in what I call the "coma" state. In that condition, it won't initialise at all, using any known method, and won't do anything. Only removal and external re-programming of the EEPROM (or other creative solutions) will be able to get it back to a functional state, but at least it doesn't involve having to de-solder the CS4237 itself. Don't ask me how I know.

Good to know! ...and yeah I won't ask! 😉

640K!enough wrote on 2023-06-25, 03:31:

Also, be aware that the Crystal tool has certain bugs. When you create a new file, I would suggest first re-loading it into RESOURCE.EXE, then generating the final .BIN file to disk. Re-start RESOURCE.EXE, loading the .BIN, then display the contents and go over the critical parts yourself before programming them. This will avoid unpleasant surprises (see my comment above). 😠

Also good tips, thanks!

640K!enough wrote on 2023-06-25, 03:31:

I thought I remembered them being a little more expensive than that, but not needing the EEPROM and a few supporting components is really only the icing on the cake with such a solution. I would never over-estimate the advantages of not having to rely on a separate software initialisation step, and in some cases, having the resources pre-assigned will make things go more smoothly under Windows 9x, too, though I'm not sure how the Windows 3.x drivers would react to that (I haven't even tried them yet).

Just so I get this right - am I right in understanding that you can initialize/configure the CS4237 completely and have it be in a 100% exact same state as if it was using an eeprom by programming it with the hostload procedure from my BIOS code during boot?
If that's the case, then it would actually seem like a nice solution - with no risk of "bricking" the eeprom. SeaBIOS programming is easy (pure C) and updating the BIOS on the SOM is fast and simple - and if the BIOS is accidentally bricked, it can easily be hw-programmed by a SOP-clip, no need to desolder anything.

640K!enough wrote on 2023-06-25, 03:31:

I'd take a stab at it myself, especially since I have basically all of the CS4237 side of the code written already, but these projects have a habit of wreaking havoc on the budget once you get started with them, and this board is looking particularly big and expensive (4-layer design?).

Making a new revision of the motherboard is something I'll do regardless - my current prototype has a bug with the PS/2 wiring which I wrote about a few posts back, and I'd like to improve a few other things as well.
It's a 4-layer board, and yes - it's fairly expensive, I think I'm paying around 500 USD for each prototype (really 5 boards, but I only need one for prototyping). 🤪

What kind of code do you have written? Assembly? I wouldn't mind taking a look, if you're willing to share. It does look like this is well documented in the datasheet though.

Last question - if I were to give the BIOS/hostload method a try, I'd like to basically erase the CS4237's eeprom first, or at least blank out its first two bytes - which according to the datasheet should make the CS abort reading the rest of it. Do you know if there exists any tools for erasing it? I guess I could try uploading a file with 0xFFFF as the first two bytes also, but don't know if that'll work...

Edit: I made a blank 256 byte file (filled with 0xFF), read it in RESOURCE.EXE and programmed it to the eeprom. The program didn't seem to mind writing whatever. Then I read it back and discovered that it'd sneakily inserted 0x55BB itself as the first two bytes and calculated the checksum. I hastily flashed a proper configuration back before turning off the computer.
So, that points to RESOURCE.EXE not being able to erase an eeprom, just corrupt it I guess... 🙁

To save some time, I'll just respond with a block of text, rather than carefully quoting everything again. Hopefully I won't forget anything.

Firstly, there is a tool I shared in the weeCee thread that can do exactly what you are looking for, called CLREEPRM.EXE. The post that introduces it is here. Since yours already has a valid configuration, you can just initialise with UNISOUND or CWDINIT, making sure that the control port is set at 538H, then run the utility. If it completes successfully, you'll have a CS4237 in its default state (which means that it will enumerate as a CS4236 as a software-compatible fail-safe mode). If it will co-operate, I would suggest verifying the EEPROM content with RESOURCE.EXE before re-booting, just to be sure.

That page also mentions my hostload tool, which you can feel free to experiment with before you start the actual BIOS-level experimentation, if you're interested. If you haven't seen it yet, there was a fairly good discussion of CS4237-related issues in that thread, starting on page 3 (EDIT: changed that; it's page 3, not 6). At various spots, I provide tools and sample .BIN files that may prove helpful.

At almost any point, before or after initialisation, you can upload new data to the CS4237 and have it respond accordingly. From its EEPROM-less CS4236 fallback mode, you can hostload a new hardware configuration and optionally go on to load the complete resource assignments without having to write code for Plug and Play enumeration and configuration. If you really want to run with my idea, you can follow that with signal routing and mixer set-up, all from a dedicated BIOS setting page, and have the chip completely ready for use before the bootstrap process even begins. With an amplifier on-board, you could even route system audio and PC speaker signals to the internal speaker.

The Crystal documentation is much better than some of their competitors were offering, but is far from perfect. If you rely on that alone, be prepared for more surprises. If you're interested, I can provide additional input, either here or privately, based on lessons learned the hard way. I can tell you from experience that there are things that work fantastically, that the documentation explicitly says can't be done, as well as other things that are claimed in the documentation that just don't happen/work.

When it comes to the CS4237, my code is 100% C, with some reliance on the old Borland C library. If you want to discuss, I am willing to share some of my code privately and/or collaborate on the effort, as long as it doesn't involve getting into the mounting costs that sometimes accompany such projects.

@640K!enough: Thanks, man! However, I can't get CLREEPRM.EXE to work - this is what I tried:
1. Programmed the eeprom with a working CS4237B configuration, control port set to 538h.
2. Rebooted, ran CWDINIT.EXE /V - observed that all looked ok, and control port was reported at 538h. RESOURCE.EXE was also reading the eeprom fine using control port 538h.
3. Ran CLREEPRM.EXE - got this output:

EEPROM reset successfully.
Page-write command set.

4. Ran RESOURCE.EXE again, read the eeprom, and it was unchanged (still the valid conf)

Could this be a timing issue when doing the actual programming? As in, maybe not sufficient delays between commands/bytes sent to the eeprom...?

Eivind wrote on 2023-06-26, 15:01:

Could this be a timing issue when doing the actual programming? As in, maybe not sufficient delays between commands/bytes sent to the eeprom...?

It could certainly be a timing problem. I originally wrote that in a big hurry, and somewhat sloppily, just to get one of my cards back in a workable state. It is lacking in refinement, but has consistently worked on the cards I usually work with (and on my one development machine for these things), and (apparently) on a few of these Vortex86-based machines, but I don't doubt that it can be broken rather easily. I have tried extending the delays, and making sure there is a delay between every write. Maybe see if the attached version works any better?

It might be useful to know which part you are using, exactly, for the EEPROM. Maybe a look through its timing diagrams will reveal a meaningful difference.

In a similar vein, can you try running HOSTLOAD with the default .BIN first, just to make sure that we are starting from the same card state? This shouldn't make a difference, but with certain EEPROM content, there have been some peculiar behaviours.

640K!enough wrote on 2023-06-26, 16:21:

It could certainly be a timing problem. I originally wrote that in a big hurry, and somewhat sloppily, just to get one of my cards back in a workable state. It is lacking in refinement, but has consistently worked on the cards I usually work with (and on my one development machine for these things), and (apparently) on a few of these Vortex86-based machines, but I don't doubt that it can be broken rather easily. I have tried extending the delays, and making sure there is a delay between every write. Maybe see if the attached version works any better?

It might be useful to know which part you are using, exactly, for the EEPROM. Maybe a look through its timing diagrams will reveal a meaningful difference.

In a similar vein, can you try running HOSTLOAD with the default .BIN first, just to make sure that we are starting from the same card state? This shouldn't make a difference, but with certain EEPROM content, there have been some peculiar behaviours.

Tried the new binary, same result, unfortunately. Also tried running HOSTLOAD first, and then CWDINIT before CLREE2. For good measure, I tried lowering the CPU clock speed as well - I dunno how the delay is implemented.
Nothing seemed to make any difference. 🙁

I'm using this eeprom part (the ZD24C08A variant).

I don't expect you to spend any great amount of time on this, btw. It's a tangential thing for me - I can really only desolder and lift the VCC leg of the eeprom, for instance - to get me into a state where the CS4237B can't read the eeprom, and I can experiment with hostload-ing configuration myself. 😀

Eivind wrote on 2023-06-26, 20:04:

I don't expect you to spend any great amount of time on this, btw. It's a tangential thing for me - I can really only desolder and lift the VCC leg of the eeprom, for instance - to get me into a state where the CS4237B can't read the eeprom, and I can experiment with hostload-ing configuration myself. 😀

You may not need it, but when I share something, I'd like for it to actually work when people try to use it. So, thanks for raising the issue. Up until this point, the original version had always worked consistently on my hardware, and others have also used it successfully. I can only guess that the EEPROMs on those boards were more forgiving than the Zetta unit you're using.

Because that issue was such an annoyance for me (since I couldn't re-produce it at all), I made one slight change that finally demonstrated inconsistent behaviour on my machine as well. The revised version (available here) seems to work consistently, and hopefully, nobody else has problems with it when they need it.

Because of these differences, I may end up having to build one of your designs for testing and experimentation, if I can ever spare the cash while the SOMs are still in production.

640K!enough wrote on 2023-06-28, 03:16:

You may not need it, but when I share something, I'd like for it to actually work when people try to use it. So, thanks for raising the issue. Up until this point, the original version had always worked consistently on my hardware, and others have also used it successfully. I can only guess that the EEPROMs on those boards were more forgiving than the Zetta unit you're using.

Because that issue was such an annoyance for me (since I couldn't re-produce it at all), I made one slight change that finally demonstrated inconsistent behaviour on my machine as well. The revised version (available here) seems to work consistently, and hopefully, nobody else has problems with it when they need it.

Because of these differences, I may end up having to build one of your designs for testing and experimentation, if I can ever spare the cash while the SOMs are still in production.

That last iteration worked! 😀
As icing on the cake, you might consider writing only 0xFFs to the whole eeprom, though. Looks like it wrote alternating 0xFFs and 0x00s to the first 16 bytes, and then left the rest.
I know it doesn't matter, the CS only cares about the first two bytes, but it would just be aesthetically pleasing to completely wipe the whole eeprom!

But thank you so much for your help! I added code to set up the configuration using the hostload method from my BIOS (had to add a tiny delay between each port write) - and that did the trick! Bye bye eeprom! 😉

Can we add the ESP Wifi Modem module here too for Dial-up experience?

ahmadexp wrote on 2023-07-02, 16:51:

Can we add the ESP Wifi Modem module here too for Dial-up experience?

Yes, I supposed we could - there should be room under the wavetable board. I hadn't had much feedback about the modem, so I assumed there wasn't that much interest... 😀
I'll add it as an option, could be used instead of the regular COM2 TTL port.

Eivind wrote on 2023-07-02, 17:59:

ahmadexp wrote on 2023-07-02, 16:51:

Can we add the ESP Wifi Modem module here too for Dial-up experience?

Yes, I supposed we could - there should be room under the wavetable board. I hadn't had much feedback about the modem, so I assumed there wasn't that much interest... 😀
I'll add it as an option, could be used instead of the regular COM2 TTL port.

I love the modem. It would be great if we can make Win98 to use it to do a Dialup connection.

Eivind wrote on 2023-06-28, 10:18:

That last iteration worked! 😀
As icing on the cake, you might consider writing only 0xFFs to the whole eeprom, though. Looks like it wrote alternating 0xFFs and 0x00s to the first 16 bytes, and then left the rest.
I know it doesn't matter, the CS only cares about the first two bytes, but it would just be aesthetically pleasing to completely wipe the whole eeprom!

Thanks for testing again. I'm glad to hear that it worked on the Zetta EEPROMs as well. It's good to finally have that cleared up, as I will be needing that code for other CS4237-related purposes shortly.

As for your other comments, I agree on all counts. What you are seeing is mostly the results of my testing, and since it also happens to serve the purpose of getting the CS4237 to accept it as an EEPROM that is invalid but present, I decided to share it as it. Even though it's not as elegant as what you described yet, it is still better than the version that didn't work consistently.

To finally expose the problems, I switched from page writes to byte writes. Unfortunately, with a single pattern, it still appeared to work often enough to be misleading. Finally, the alternating pattern showed that it was broken more often than not. Now that the results seem to be consistently successful, I can go back to page writes (faster, fewer command cycles), adopt a single byte value, and write the whole chip.

Eivind wrote on 2023-06-28, 10:18:

But thank you so much for your help! I added code to set up the configuration using the hostload method from my BIOS (had to add a tiny delay between each port write) - and that did the trick! Bye bye eeprom! 😉

I also found that delays were needed between I/O operations on the CS4237. If you don't have any, some operations tend not to complete (you end up "talking" to the chip when it's not ready), and you end up with the device in an unpredictable state. Since my software targets everything from an 80186 right through to the latest machines with ISA slots, it takes some care to get things working consistently on all hardware.

Are you just uploading the basic hardware configuration and resource map, or also configuring the part yourself at that stage? Did you embed a .BIN image? You may have figured this out already, but you probably want to avoid setting the PKD bit; your Windows installations will thank you.

640K!enough wrote on 2023-07-04, 21:33:

Now that the results seem to be consistently successful, I can go back to page writes (faster, fewer command cycles), adopt a single byte value, and write the whole chip.

That's awesome!

640K!enough wrote on 2023-07-04, 21:33:

Are you just uploading the basic hardware configuration and resource map, or also configuring the part yourself at that stage? Did you embed a .BIN image?

I made a modified configuration with only one "option" for each logical device - which made Windows select that one. No further need to tweak resource settings after driver install. For now, I just embedded the bytes directly in my BIOS code. I thought about making parts configurable from my BIOS setup menu, but I don't really know what good that would do - because of my specific hardware setup, I can only use IRQ 7 and DMA channel 1. I suppose there might be a use case where one would like to change the SB, Adlib or MPU-401 port addresses, but that seems like a stretch at this point.

640K!enough wrote on 2023-07-04, 21:33:

You may have figured this out already, but you probably want to avoid setting the PKD bit; your Windows installations will thank you.

Yeah, I definitely didn't set that bit! 👍