rasteri wrote on 2021-06-23, 21:34:

Mu0n wrote on 2021-06-23, 19:43:

Possibly, the guy local to me (who uses boards printed from the same batch as mine, we shared) definitely uses better technique in soldering and cleaning since he's an electronics professional... His boards work in sb/adlib /midi

Did you also share a parts order? I just ask because I'm always ordering the wrong components values, e.g. on my first batch I ordered 16MHz crystals instead of 16.9344MHz, could something like that have happened?

I shared the same mouser list, which we verified over the course of a few days. The only real mistake was the Ethernet connector, but he ordered the right ones for his order and got me extras.

The only component which is sketchy is the pull-up resistor in the eeprom area. I ordered a 6.8kOhm when your diagram calls for a 4.7 kOhm (and the Orpheus guys prefer a 3.3 kOhm) . That may or may not play in eeprom reading and writing, but right now I'm squarely working on my sketchy midi signals. I'll edit down a close-up video shot of the top row and bottom (isa) of The cs4237B's legs and upload it a bit later.

weedeewee wrote on 2021-06-23, 21:09:

anyway, the janky wire reprogramming should work just fine, just verify the contents after you've programmed it.
Good luck !

Yes, it did work a week or 2 ago. The very first thing I did after writing the bin file was to verify it against the bin file and it said no error (I posted the shot). I can do it again but it's such a pain to solder things mid air, especially the first leg. I can certainly do it again, but I'd try it with the old one again, not my 2nd fresh one.

What do you recommend to erase it? Use the programmer built in erase function or send over the maximum capacity in all FF's?

Mu0n wrote on 2021-06-23, 22:00:

What do you recommend to erase it? Use the programmer built in erase function or send over the maximum capacity in all FF's?

They're probably the same 😀
choose whichever you feel like.

rasteri wrote on 2021-06-23, 21:34:

Did you also share a parts order? I just ask because I'm always ordering the wrong components values, e.g. on my first batch I ordered 16MHz crystals instead of 16.9344MHz, could something like that have happened?

Uh...you still list 16.000 MHz in your BOM list over at circuitmaker:
https://circuitmaker.com/Components/Details/D … 0B-7AAC12E64CD7

This is what we ordered:
https://www.mouser.ca/ProductDetail/815-ABLS-16.0M-T

So that would be it? It would explain the midi note timing issues, but wow, it affects almost nothing else? What a quirky issue... If it's this.

The datasheet mentions:

.MCLK - Wavetable Master Clock, Output This pin is multiplexed with the XD5 external data bus pin. When use as MCLK, this output […]
Show full quote

.MCLK - Wavetable Master Clock, Output
This pin is multiplexed with the XD5 external data bus pin. When use as MCLK, this output
supplies the 16.9344 MHz master clock that controls all the timing on the CS9236. This pin
should be connected to the MCLK5I input pin on the CS9236. MCLK can be disabled in
software using the DMCLK bit in C8 in the Control logical device space. DMCLK provides a
partial software power-down mode for the CS9236.

and I find this:

(about 16.9344 MHz) "Used in CD-DA systems and CD-ROM drives; allows integer division to 44.1 kHz (384×44.1 kHz), 22.05 kHz, and 11.025 kHz. UART clock allows integer division to common baud rates up to 7,200(x16x147) or 14,400(x8x147). 6x 2.8224 MHz (DSD64 bitrate). Frequencies also used are 11.2896 MHz, 22.5972 MHz, 33.8688 MHz and 45.1584 MHz."

Oh well then.

Here we go, in VIDEO FORM, an inspection of the soldered CS4237B-KQ with a few passes of pins 51-75 and one of pins 1-25. This is machine #2, where I did it more confidently, but it still exhibits MIDI OUT erratic behavior, same as machine #1.

Witness my terrible soldering
https://www.youtube.com/watch?v=U9jYVwj2VDA

(the video is meant to be paused whenever the image and zoom stabilizes)

Mu0n wrote on 2021-06-24, 00:45:

So that would be it? It would explain the midi note timing issues, but wow, it affects almost nothing else? What a quirky issue... If it's this.

Yes, that'll be it haha 😀 I made the same mistake on the first rev of my PC104 soundcard.

The BOM says 16mhz because that's the closest value in Circuitmaker's parts library, I changed the value to 16.9344 in Circuitmaker but I guess if you export the BOM from the website it doesn't carry over that value. If you look at the BOM or schematic in the Circuitmaker application itself it says 16.9344MHz.

Better get yourself a 16.9344MHz crystal. This is almost certainly what's causing all your problems. The EEPROM was likely always fine I guess...

When I release the final gerbers I'll include a fully verified BOM like I did with the PC104 soundcard.

Mu0n wrote on 2021-06-22, 20:24:

Is it possible to get a dos program to wipe out the eeprom? Did you, 640K!enough write hostload? Could it be modified to blank out a size specified rom

The attached file is not a modified HOSTLOAD, but an all-new utility. You must still run HOSTLOAD first to initialise the card and assign an address to the control port. Then, run this tool to clear the first page of the EEPROM. That should get the card in a state that allows you to re-write the EEPROM via RESOURCE.EXE.

I am somewhat busy at the moment, but will have more comments for this thread later.

EDIT: This is an updated/fixed version of the tool, uploaded 2023-06-27. The control port address must now be specified as a command line parameter. Those having problems with the CS4237 can try using HOSTLOAD.EXE (introduced here) with the default resource (.BIN) file to perform the initial set-up of the chip, in which case, the control port base address will be set to 538H.

rasteri wrote on 2021-06-22, 13:50:

It seems that, at least on my configuration, hostload will only work if there is already a somewhat valid EEPROM attached. Is that expected behavior? If not, is there anything hardware-wise that could cause hostload not to work but EEPROM to be fine? I have attached the draft schematic just in case you wanna take a look.

In my experience, needing an EEPROM to be present for the hostload procedure to work is absolutely not expected behaviour, and would defeat the purpose of that initialisation option. I don't have time, at the moment, to go through the datasheet and schematic to see if anything stands out, but will try to take a look when I have more time to spare.

I can, however, confirm that with no EEPROM present at all and the pull-up for SDA removed, the same version of the executable as posted here can successfully get the board into a state from which it can be initialised with UNISOUND. There appears to be a bug in UNISOUND that causes it to be unable to enable the digital output from that state, but my separate tools manage that just fine, as well. Once initialised, all major functionality works as expected.

Mu0n wrote on 2021-06-24, 00:45:

Uh...you still list 16.000 MHz in your BOM list over at circuitmaker: https://circuitmaker.com/Components/Details/D … 0B-7AAC12E […]
Show full quote

Uh...you still list 16.000 MHz in your BOM list over at circuitmaker:
https://circuitmaker.com/Components/Details/D … 0B-7AAC12E64CD7

This is what we ordered:
https://www.mouser.ca/ProductDetail/815-ABLS-16.0M-T

So that would be it? It would explain the midi note timing issues, but wow, it affects almost nothing else? What a quirky issue... If it's this.

If that is the case, it can be the source of major problems. The MIDI transfer rate is likely to be wrong, and that can cause all sorts of unusual behaviour. Furthermore, the sample rate is likely to be affected, likely resulting in sounds not playing back at the correct frequencies. Definitely get that sorted before we try to look for other sources of problems. That doesn't mean that the right crystal and EEPROM contents will solve all of your problems, but it would be a good starting point.

Depending on which province you're in, there are likely local sources for the crystal, and you can probably pick up a few extra resistors to try other values for SDA while you're there.

Yeah, already on that. My shipment of 16.9344 is arriving on Wednesday, as well as new 1206 package resistors in 2.2 kOhm (what my specific eeprom doc asks for), 3.3 kOhm as you suggested and 4.7 kOhm as per rasteri's design doc. I had 6.8 because of a reading mistake or because that's what was included at the time I forked the project on the website.

I got replacment eeprom (same as before) and some that are similar to your suggestions ( https://www.mouser.ca/ProductDetail/Microchip … aBWz0O7Rw%3D%3D ) however the precise eeprom that was suggested is not in stock in both digikey and mouser, with months of lead time. Crossing my fingers that all I've got will be enough.

Edit - also huge thanks for the clearing utility. I hope that didn't require too much work, but I bet it'll be useful to other people as well In the close or distant future.

Hostload works perfectly on my Vortex86SX motherboard and PC/104 CS4237 soundcard.

As there's basically no difference between the PC104 board and my carrier board for the Vortex86DX SoM, I'm beginning to wonder if there's something weird about the DX variant when it comes to ISA. At least it seems to work fine with an EEPROM.

rasteri wrote on 2021-06-29, 15:10:

Hostload works perfectly on my Vortex86SX motherboard and PC/104 CS4237 soundcard.

As there's basically no difference between the PC104 board and my carrier board for the Vortex86DX SoM, I'm beginning to wonder if there's something weird about the DX variant when it comes to ISA. At least it seems to work fine with an EEPROM.

It is possible that the timing of the ISA bus is different on the two boards (SX versus DX), and it may help if I add some extra delays between I/O operations. I haven't checked in the last few days, but I think the delays were either short or non-existent when I originally wrote that tool. I really only wrote that for myself, and had no undefined behaviour, since I already have the I/O recovery time set near its maximum, and, practically, that has a similar effect. Can you increase the I/O recovery time on that machine? Does it make any difference?

I received my stuff earlier than expected and insta-soldered my new crystal

Things that work:

-megamid in midi mode right off the bat
-duke3d setup tests with midi waveblaster music
-duke3d itself after removing smartdrive from autoexec.bat (still crashes upon leaving the game but meh, that's minor and unrelated to everything else)
-reading the eeprom contents once more (in machine #1 with the IC installed)
-using clreeprm.exe

Still don't work:
-writing to eeprom while onboard

Things that still don't work but they're separate vortex86dx problems:
-dune 1 runs too fast and still does no sound

Massive thanks for all help provided!

Mu0n wrote on 2021-06-29, 21:11:

Things that work: ... -using clreeprm.exe […]
Show full quote

Things that work:
...
-using clreeprm.exe

Still don't work:
-writing to eeprom while onboard

Do I understand that to mean that CLREEPRM worked, while you were still unable to write the entire contents with RESOURCE.EXE? Was this without changing anything about the configuration? If that's the case, it should be a fairly simple matter to modify the existing CLREEPRM code to read a BIN file (generated by RESOURCE.EXE) and write those bytes to the EEPROM, rather than just zeros. The protocol is the same, whether I write 00 or some other byte.

640K!enough wrote on 2021-06-29, 17:53:

Can you increase the I/O recovery time on that machine? Does it make any difference?

That doesn't seem to work either, unfortunately. I've fiddled with all the other PnP/PCI/ISA settings I can in the BIOS and nothing makes a difference.

TBH at this point it's pretty academic, I figure everyone who builds this project will just add an EEPROM.

Mu0n wrote on 2021-06-29, 21:11:

Things that still don't work but they're separate vortex86dx problems:
-dune 1 runs too fast and still does no sound

You tried disabling L1/L2 cache and altering the CPU clock divider in the BIOS?

rasteri wrote on 2021-06-30, 13:17:

Mu0n wrote on 2021-06-29, 21:11:

Things that still don't work but they're separate vortex86dx problems:
-dune 1 runs too fast and still does no sound

You tried disabling L1/L2 cache and altering the CPU clock divider in the BIOS?

I fixed it once I checked what install.exe did and did not do. I had a dune.bat which had the wrong command line parameters and install.exe was modifying another batch file altogether. There was also a '386' parameter that makes it use 386 opcodes, which I removed. Dividing the CPU was what I was using before to reign in the speed. It's all good and sorted now.
In some parts of the fm synth music (it's one rare game where I vastly prefer it to sound canvas or mt-32 midi), you encounter the sound quality issues in scratchiness while for some other instruments, it's pretty good. I'll play with sound levels a bit but I can perfectly live with it.

24AA16-T/SN used (it has plenty of room to spare)
https://www.mouser.ca/ProductDetail/Microchip … fxoCT8MQAvD_BwE

3.3 kOhm for pull-up

all installed on machine #2

I initially wrote it with XGecu Pro v11.00 for good measure to have something on it, but then RESOURCE.EXE *finally* worked as it should and complained about invalid format. After I rewrote it with this thread's good CS4237.BIN, all works, without invoking the /o (override) switch of cwdinit.exe.

Mu0n wrote on 2021-06-30, 18:42:

After I rewrote it with this thread's good CS4237.BIN, all works, without invoking the /o (override) switch of cwdinit.exe.

Are you sure you used the right file? Unless I'm mistaken, the BIN files I uploaded were only for hostload init; they lack the necessary header for EEPROM use. You may want to double-check that, and use one of the ASM or INI files provided.

The /o switch is usually required for DOS use, as the resources assigned by the PnP BIOS are sometimes not suitable for all DOS-based software. The only time it isn't so important is if there is no PnP BIOS, or it doesn't assign resources to that card, for whatever reason (PnP OS set to Yes, no resources available, etc.).

Have you finally removed HOSTLOAD from your AUTOEXEC.BAT? Once you have a valid EEPROM, it is no longer needed.

640K!enough wrote on 2021-06-30, 19:00:

Are you sure you used the right file? Unless I'm mistaken, the BIN files I uploaded were only for hostload init; they lack the […]
Show full quote

Mu0n wrote on 2021-06-30, 18:42:

After I rewrote it with this thread's good CS4237.BIN, all works, without invoking the /o (override) switch of cwdinit.exe.

Are you sure you used the right file? Unless I'm mistaken, the BIN files I uploaded were only for hostload init; they lack the necessary header for EEPROM use. You may want to double-check that, and use one of the ASM or INI files provided.

The /o switch is usually required for DOS use, as the resources assigned by the PnP BIOS are sometimes not suitable for all DOS-based software. The only time it isn't so important is if there is no PnP BIOS, or it doesn't assign resources to that card, for whatever reason (PnP OS set to Yes, no resources available, etc.).

Have you finally removed HOSTLOAD from your AUTOEXEC.BAT? Once you have a valid EEPROM, it is no longer needed.

I used CS4237B.ASM (291 bytes) after I realized I shouldn't use the CS4237.BIN (287 bytes) file.

I removed hostload from autoexec.bat. Using /o or not with cwdinit.exe doesn't prevent anything from working completely.

The BIOS allows PCI PnP to be enabled/disabled, nothing about ISA PnP.

I'm using SET BLASTER for good measure in case games look for it.

And Machine #1, tried something slightly different:

-Desoldered the old 24LC04B
-Soldered the new 24AA116T but kept it completely empty as new
-Kept the old 6.8 kOhm.

I couldn't find a control at address 0x538 with bypassed config.sys and thus no hostload. so I desoldered the 6.8 kOhm and soldered a 3.3 kOhm, same thing (so 6.8 kOhm has a chance of being fine)

I then got the eeprom going with a hostload, found control at address 0x120, could successfully write cs4237b.asm and now control is at 0x538 and the eeprom runs fine, sound is fine, no hostload necessary after all that in autoexec.bat, ofc.

Next: replace the broken microsd card read in machine #1 (I had removed the spring and tiny tracking metal rod since it was never clicking in). If I'm a perfectionist, I could try to find the sweet spot in solder amount in machine #2 for its reader, since I have to struggle to get the card in and out a bit. You really have to get almost no solder on the sides where it's held by ground pads and possibly almost nothing in the back pads as well.

edit - bonus with a properly written EEPROM

Win98se sound works! finally.

Onto the wonderful (ugh) world of MS-DOS 6.22 network capability installation.

I'm following this page: http://www.dmp.com.tw/tech/vortex86dx/
DOS NDIS driver: pci-ndis.zip

and this page:
https://www.legroom.net/howto/msdos

I'm stuck fairly early in the process: with MS Network Client v3.0 (which I've extracted to a temporary install folder), it simply will refuse to take my path to the NDIS driver taken from the first link. It complains it can't find any driver. I've tried a few others (including one from RealTek's website (NDIS2 for dos: https://www.realtek.com/en/component/zoo/cate … et-pci-software)