I have been looking at a few different parts lately, so am sometimes confused. It looks like this EEPROM only needs a resistor for SDA (Crystal calls for 3.3kΩ for R9). EDIT: So, to clarify, R10 should not require a pull-up, and I'm not sure the CS4237 would like that too much. Certainly, don't bridge it with a solder blob or bodge wire.

You are also using a 512 byte part, so there is no room to include the firmware patches in the EEPROM. The files you got from the Orpheus site won't work as they are, but the ASM file I provided should give you what you need, as soon as the EEPROM is consistently accessible.

Now that I re-read your post, it looks like you were trying to write the BIN file to the EEPROM. That will never give the results you want (even if it managed to write it), as it is a file only meant for the hostload procedure. You need to use CS4237B.ASM. They are based on the same data, but one is meant for the EEPROM, and the BIN file can only be used for hostload init.

EDIT: In terms of the write-protect pin, it should already be held low. Just to be sure, you can check for continuity between pin 1 and pin 7 (both should be connected to ground).

Mu0n wrote on 2021-06-18, 23:27:

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?

Pretty sure R10 should be the same value as R9.
Shorting it to 5v would be a 'bad idea'tm since it would stop the clock line from working properly, and considering it's a pull-up resistor would cause any device that tries to pull the line down to signal a low state to be subjected to the max amount of current the 5v line could deliver since there would be no resistor limiting the current .

I hope this might help:

I have removed all non-relevant parts and this allows for a write-able eeprom setup .
The eeprom we use is the ATMEL AT24C16C-SSHM-T (the C is important as it indicates a 5v compatible part)

also a recommendation, try to have thicker tracks on next pcb revision as these look too thin judging from the pics

Good catch in the 5V eeprom.

Pin7 is already low per the design (I was reading the pin order wrong in a previous post). So we have competing advice for R10 (populate or not).

I won't do a board revision (no more money to invest in this) but it's something for rasteri to ponder before he releases his official Gerber files on circuitmaker.

So, I'm very happy that adlib and SB works in most games I try out now (DOOM, duke3d) while some others need work (Dune 1). Naturally, I go right into another wall, trying to use the S2 Dreamblaster from Serdashop. I've never owned or used a waveblaster product before. I also have a mt-32 and sc-88st that I use to great success on my real 486 dx2/66.

From what I understand, I need to use SEt BLASTER=A220 I5 D1 T4 P330 buy I'm not sure about the T setting (can the cs4237B act as a SB pro 2.0 or just regular SB pro), but AFAIK, the sb16 and awe32 were the ones with waveblaster and the documentation for the CS don't mention them as cards it can act as, however it does explicitly mention the waveblaster interface, which gets a cloned signal for midi just like the gameport does.

So, setting duke3d as waveblaster for music will output something... A few scarce notes from what sounds like the right instruments, but it's about one note per 8 seconds. DOOM behaves the same way.

I've tried all combinations of running it as yesterday s working setup, adding in unisound, adding SoftMPU /mpu:330 /sb:220 /irq:5 or adding both, doesn't change anything in the waveblaster's behavior.
I also tried both my mt32 and sc-88st using my custom cable which works great on the 486 and the exact same scarce note behavior happens.

Mu0n wrote on 2021-06-19, 15:28:

Pin7 is already low per the design (I was reading the pin order wrong in a previous post). So we have competing advice for R10 (populate or not).

reading the datasheets helps, and normally I2C signal & clock lines have a pull up resistor, size dependent on the amount of devices connected to the i2c bus.

I won't do a board revision (no more money to invest in this) but it's something for rasteri to ponder before he releases his official Gerber files on circuitmaker.

So, I'm very happy that adlib and SB works in most games I try out now (DOOM, duke3d) while some others need work (Dune 1). Naturally, I go right into another wall, trying to use the S2 Dreamblaster from Serdashop. I've never owned or used a waveblaster product before. I also have a mt-32 and sc-88st that I use to great success on my real 486 dx2/66.

from what I get from the waveblaster pinout, is that you need a way for the audio to return and a way for the data to go to the waveblaster part, which seems to be two pins for output and one pin for midi input. add power and ground.

this is what needed for the WT header to work:

it is pretty self-explanatory I think , maybe the only thing to keep in mind is that the CS4237 MIDOUT (pin60) connects to WT Header MIDI-IN (pin4)
and for the S2 to work you only need 5v

ps.
BRST is the !BRESET signal from pin15 of CS4237
ML and MR is the audio outputs, you connect them to RLINE and LLINE pins (labels used are relevant to our Orpheus design but hopefully easy to understand what they are)

I'm pretty confident the design for the wavetable is already good on the PCB. I'll dig in more for proper config.sys and autoexec.bat, the lines specifically needed to properly run a wave table. One SET line I'll try the the SET SYNTH env variable that's normally used for awe32 SB wave tables, maybe it's required here (I'm in unknown territory)

(the wavetable is in the top right corner, midi out is shared with the DB15 gameport as shown in the picture)

odd pins from 1 to 25: yes to GND with 13 being NC

even side:
2: yes to NC
4: yes to pin60: MIDI_OUT of the CS4237B and to pin 12 of the gameport
6: yes to 5V
8: yes to NC
10: yes to 5V
12: yes to NC
14: yes to 5V
16: yes to NC
18: NC
20: goes to a 6.8kOhm which forks to another 6.8kOhm to GND and a 10 uF to pin 86 (RLINE) of the CS
22: NC
24: same deal as pin 20, but to pin 87 (LLINE) of the CS
26: goes to pin 15 (BRESET) of the CS

Since it can affect the CS4237 in quite a number of ways, I would first tend to the EEPROM issues, and worry about the rest afterwards. For starters, try 3.3 kΩ for R9, with R10 unpopulated. If you're still not getting anywhere, try re-flowing the related pins on the CS4237. Frankly, the bulk of these problems could be soldering-related. Since keropi has shown the working, consistently reliable layout for the EEPROM, and you're using a similar EEPROM whose datasheet doesn't call for a pull-up resistor on SCL, you have a good example from which to work. When the EEPROM is consistently usable, move on to other things.

For your MIDI/WT header problems, start with simpler DOS playback software, like MegaMID. For these purposes, no IRQ is required. Unless you are using UNISOUND, the P part of the BLASTER environment variable is mostly unnecessary, and isn't likely to help. The same is true of any other such variables. This will not solve your problem. To start with, why not post your CWDAUDIO.INI (if using CWDINIT) or environment variables (if using UNISOUND), as well as the output from the initialisation steps (verbose output preferred)? If using CWDINIT, also be sure to run "CWDMIX /d" after initialisation, but before trying to play back any audio. Also, T4 is correct for the BLASTER environment variable with the CS4237.

See how that goes, then we can think about the rest.

As far as I can tell, the CS4237 drives the SCL pin push-pull so it doesn't need a pullup resistor. Certainly none of the CS4237-based soundcards I reverse engineered had a pullup on the SCL pin, and all the boards I've built work just fine without R10. The SDA is driven open-drain so it needs a pullup on R9.

If the EEPROM is written properly then Unisound will detect and initialize the card without needing to have your BLASTER environment variable set.

BTW Muon, if you reach a dead-end with this board then I'm more than happy to take a look at it for you free of charge, I feel bad that you've spent so much time on this haha. DM me if you want.

EDIT : Or I could send you a pre-programmed EEPROM if you like?

keropi wrote on 2021-06-19, 07:24:

also a recommendation, try to have thicker tracks on next pcb revision as these look too thin judging from the pics

The power traces are 25mil but most other stuff is 6mil. Do you think it's neccesary to go up to 8mil, given the traces are low-current?

rasteri wrote on 2021-06-20, 15:43:

keropi wrote on 2021-06-19, 07:24:

also a recommendation, try to have thicker tracks on next pcb revision as these look too thin judging from the pics

The power traces are 25mil but most other stuff is 6mil. Do you think it's neccesary to go up to 8mil, given the traces are low-current?

Traces are too thin I would use 8 to 10 mil.
10 mil to CS4237 is fine.
that's the only diference I see. What's the brand of 24c16?
Also For audio I would use thicker traces.
In fact all those 6 mil I would convert to 10mil. you can do it with no problems.

Cheers!

640K!enough wrote on 2021-06-20, 02:29:

Since it can affect the CS4237 in quite a number of ways, I would first tend to the EEPROM issues, and worry about the rest afterwards. For starters, try 3.3 kΩ for R9, with R10 unpopulated. ... When the EEPROM is consistently usable, move on to other things.

Since these would involve ordering from mouser and waiting 1-2 days shipping + stinging shipping cost since I don't go over $100 in my order, I'll put this solution down the list for now. Also, according to the CS4237B datasheet on page 8 "Minimum time relates to no EEPROM present" (this quote is about the total read time of the EEPROM) and page 17 "If the first two bytes aren’t correct, the E2PROM is assumed not to exist and a "hostload" procedure must be used to load the internal RAM." - meaning for me, in terms of practicality and speed, I could just desolder the chip altogether and continue my testing without it. However, since it's involved during bootup and driver initiation, I don't see why it would directly impact MIDI playback which is the problem at hand.

Oh, and I reflowed these pins for good measure (no change at all):

640K!enough wrote on 2021-06-20, 02:29:

For your MIDI/WT header problems, start with simpler DOS playback software, like MegaMID. For these purposes, no IRQ is required. Unless you are using UNISOUND, the P part of the BLASTER environment variable is mostly unnecessary, and isn't likely to help. The same is true of any other such variables. This will not solve your problem. To start with, why not post your CWDAUDIO.INI (if using CWDINIT) or environment variables (if using UNISOUND), as well as the output from the initialisation steps (verbose output preferred)? If using CWDINIT, also be sure to run "CWDMIX /d" after initialisation, but before trying to play back any audio. Also, T4 is correct for the BLASTER environment variable with the CS4237.

I tried out megamid and it seems even both more straightforward to use and with more options than what I've used in the past: MIDPAK. There are definite MIDI signals reaching my devices. Instead of just describing it, I recorded both the DreamBlaster S2 and my Roland SC-88ST using an audio cable to my modern desktop's line in, recorded in mono in audacity. I played DEMO0001 in megamid and trimmed the recording around the time it started making sound (ie not at the beginning exactly). The output is not identical every time, it's very much random.

(my next post will have many outputs you're asking for)

I have a hankering for intercepting the MIDI out signal and interpreting it with an arduino, if it's possible (I imagine the arduino is fast enough to interpret every signal) and checking out how garbled it is - maybe it can shed some light.

rasteri wrote on 2021-06-20, 14:57:

BTW Muon, if you reach a dead-end with this board then I'm more than happy to take a look at it for you free of charge, I feel bad that you've spent so much time on this haha. DM me if you want.

EDIT : Or I could send you a pre-programmed EEPROM if you like?

That's very generous of you. This hunt is a game for me, which I very much enjoy. I love learning through adversity. It gives me as much fun as going through the Sierra collection or playing the games I couldn't back in the day because my 386 with SB16 and no SVGA was holding me back. I'm not there yet. The EEPROM offer is tempting, but I feel like I'm so close and shipping would be stupid since you live in the UK and I in Canada.

I just want you to confirm you've been able to use your Dreamblaster S2 in your later design without issue and much configuration fuss, iirc, you don't actually show it playing back in your videos (unless I missed it in your PC-104 build which I've watched less often).

Let's start with the basics:

autoexec.bat

1cd host
2c:\host\hostload
3call c:\cry286\cwd.bat
4C:\CRY286\CWDMIX /M=15,15 /W=15,15 /L=1,1 /X=1 /F=15,15 /C=1,1 /I=C
5cd..
6call c:\softmpu\soft.bat
7LH /L:0;1,45456 /S C:\DOS\SMARTDRV.EXE /X
8@ECHO OFF
9PROMPT $p$g
10PATH C:\DOS
11SET TEMP=C:\DOS
12SET BLASTER=A220 I5 T4 H5 D1 P330

config.sys is:

DEVICE=C:\DOS\HIMEM.SYS /testmem:off DEVICEHIGH=C:\DOS\EMM386.EXE NOEMS 4096 BUFFERS=15,0 FILES=40 DOS=HIGH,UMB LASTDRIVE=G FCBS […]
Show full quote

DEVICE=C:\DOS\HIMEM.SYS /testmem:off
DEVICEHIGH=C:\DOS\EMM386.EXE NOEMS 4096
BUFFERS=15,0
FILES=40
DOS=HIGH,UMB
LASTDRIVE=G
FCBS=4,0
DOS=HIGH
DEVICEHIGH /L:2,12048 =C:\DOS\SETVER.EXE

cwd.bat just contains the line: c:\cry286\cwdinit.exe /v /o

cwdinit.exe's verbose output:

1CrystalWare(tm) Audio Initialization Utility, Version 2.841x
2Copyright(c) 1997 Crystal Semiconductor Corp. All Rights Reserved.
3
4  *  Testing for SIS IOCHRDY chipset.
5  *  Found PCI BIOS.
6  *  Found C:\CRY286\CWDAUDIO.ini.
7  *  Making sure Crystal chip is in wait for key state.
8  *  Plug N Play BIOS Detected.
9  *  Override Plug N Play Configuration.
10  *  Sending Key
11     WSS: I/O =  534,  IRQ =   5,  DMA0 =  1,  DMA1 =  0.
12     OPL3: I/O =  388,  IRQ = Disabled.
13     SBpro: I/O =  220.
14     Joystick: I/O =  200.
15     Control: I/O =  538,  IRQ = Disabled.
16     MPU-401: I/O =  330,  IRQ =   9.
17     Logical device 4 disabled.
18     Logical device 5 disabled.
19  *  Card is Configured.
20  *  Modifying blaster environment variable.
21  *  Loading Minicode
22  *  Downloading Firmware Code, Version 17.
23  *  Both Crystals and DMA timing on.
24  *  Updating driver settings.

soft.bat just contains the line: c:\softmpu\softmpu /sb:220 /irq:5 /mpu:330

softmpu's output is:

1ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
2³SoftMPU 1.91 þ Software MPU-401 Emulator³
3³                                        ³
4³Copyright (C) 2013-2014  bjt, elianda   ³
5³Copyright (C) 2002-2013  The DOSBox Team³
6ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
7û MPU-401 detected at port 330
8û Sound Blaster (DSP 3.02) detected at port 220 IRQ 5 
9
10 SoftMPU active at port 330 IRQ 5 

cwdinit.ini is:

[PNP] WssIO=534 WssInt=5 WssDmaPlay=1 WssDmaCapture=0 SbIO=220 OplIO=388 OplInt=Disabled […]
Show full quote

[PNP]
WssIO=534
WssInt=5
WssDmaPlay=1
WssDmaCapture=0
SbIO=220
OplIO=388
OplInt=Disabled

GameIO=200

4232IO=538
4232Int=Disabled

MPU401IO=330
MPU401Int=9

CDIO=Disabled
CDInt=Disabled
CDDma=Disabled

[IniUpdate]
;SysIniFile=C:\windows\system.ini

;SoundBlasterIRQ=[sndsys.drv],SoundBlasterIRQ
SoundBlasterAddr=[sndsys.drv],OldMSDOSGameIOAddress
;SoundBlasterDMA=[sndsys.drv],SoundBlasterDMA

;UsePnP=[sndsys.drv],UsePnP

;WSSIRQ=[sndsys.drv],Interrupt
;WSSAddr=[sndsys.drv],IOAddress
;WSSPlayDMA=[sndsys.drv],DMADAC
;WSSCaptDMA=[sndsys.drv],DMAADC
;
;MPU401IRQ=[mpu401.drv],int
;MPU401Addr=[mpu401.drv],port

;Opl3Addr=[opl3.drv],portFM
; For now keep this disabled
;Opl3IRQ=[opl3.drv],Int
;JoystickAddr=[sndsys.drv],Joystick

Next post, I show what I used for burning the eeprom vs what's been given to me by 640K!enough earlier in the thread, dissassembled by resource.exe

Using resource.exe, I first loaded the .bin file that was succesfully used by rasteri in his PC-104 sound card project, which he also used on this weecee board. He used the same eeprom programmer I have. I loaded that bin file, then disassembled it.

I then loaded 640K!enough's cs4237b.asm file provided in a zip archive earlier in this thread, and disassembled it.

Warning, image heavy post. I had no easy way to capture resource.exe's output, so I filmed it and took screenshots to show side by side comparison.

of course, if I load the control at 0x538 (A command) and read what's on the physical EEPROM itself, I get back rasteri's version exactly since it's what I burned on it originally.

I found an easier way to get midi data out of my vortex86dx machine - I just plug its DB15 -> Serdashop DB15MIDI -> usb midi interface 1x1 -> MidiView (https://hautetechnique.com/midi/midiview/)

I can't output and save the whole list of midi events (it keeps a big number of last events, not all) but it looks....normal? There's as many midi commands as you'd expect from a full playback of demo0001.mid, here's a first screen of it.

Meanwhile, on my real 486DX2/66, SoftMPU launches a sequence of many lines (as opposed to just one for my Vortex86DX...is that a sign?)

Here's DEMO0001.mid playing on the 486:

Mu0n wrote on 2021-06-21, 14:39:

I just want you to confirm you've been able to use your Dreamblaster S2 in your later design without issue and much configuration fuss, iirc, you don't actually show it playing back in your videos (unless I missed it in your PC-104 build which I've watched less often).

Yes the dreamblaster works perfectly in my newer revision, and there aren't any real differences between that revision and yours. Certainly nothing that would affect the MIDI. (I hope!)

I understand the hunt being the fun part of this process 😀 The offer is always open though if you change your mind.

It's interesting - your MIDI logs look like you're only getting NOTE OFF commands. I wonder what could cause that - software or hardware?

I'm going to try the same tests on my weecee and see if I get the same problem when try programming the EEPROM in-circuit instead of using my TL866. I never got HOSTLOAD to work but admittedly I didn't try very hard.

The BIN file I provided was actually dumped from a CS4237-based card I got off ebay, I didn't realise that Orpheus provided a flash package or I'd have recommended using it instead. For the next revision I'll put a 24-16 EEPROM on the BOM instead of the 24-04, then you could use the Orpheus flash package. They both have the same pinout so it will be a like-for-like swap.

So I've tried a few of the things in this thread on my known-good board and I have some findings. Sorry if I missed anything, I rushed to try all this before I had to leave.

Firstly, I can't get the CS4237B.asm 640K!enough provided to write to my EEPROM using resource.exe ("unable to write EEPROM"). The write protect pin is definitely grounded so I don't know why. It certainly reads the eeprom just fine. I eventually got this to work, I think it was either a dry solder joint or me not following 640k!enough's instructions properly

If I remove the eeprom from my board, I can't get the hostload process to work. It seems to initialize but then the soundblaster audio doesn't work, and softMPU won't initialize. It sometimes even crashes.

I've tried programming the BIN file that 640K!enough provided directly to the EEPROM using my TL866 (after adding the init bytes 55 BB 01 1F to the start), and I get similar problems as with the hostload process. I also got this to work, again it may have been a soldering or competence issue.

The ONLY way I can get audio to work on my board is to write the BIN file I originally provided directly to the eeprom using my TL866. When I do that, everything works fine.

Mu0n, I think you're going to have to bite the bullet and desolder the EEPROM to check it really did write properly. If the EEPROM really does contain the correct data then I'm totally confused.

Part of the problem is that, per Crystal's own tools, that original file is not quite valid. The hardware configuration part seems acceptable, and the PnP part should work, but the size is definitely incorrect. It is unclear how the part will react to that, as actual behaviour varies significantly from the claims made in the datasheet. The remainder should be firmware patch data, but I didn't even spot the right device identifier in there. It may be that you got lucky and the chip just ignored it. The fact that it was identifying as a CS4236 seems to indicate that that is the case (you didn't mention that that had changed, so I assume it is still the case).

Also, SoftMPU is not required for this usage. As I am not familiar with it, I cannot tell whether the configuration being used is valid, but it looks strange. It may be worth trying without the added, unnecessary software for the time being.

Lastly, the ASM file being compared is not the most recent one posted, as the IFM bit is still missing. I didn't compare byte-by-byte, but the rest looks mostly right.

So, if one of you wants to post the original BIN used, I will generate a version that can be used with the HOSTLOAD tool, just to satisfy your suspicions. We'll see if that makes any difference. However, if that is the "only" way to get sound out of it, that implies (to me) that something is wrong somewhere.

in the CS4237B.ASM file, shouldn't this line:

DB 0084H ; GCB1: IFM SPS
(which is 1000 0100)

be changed to:

DB 008CH ; GCB1: IFM SPS WTEN
(which is 1000 1100)

as per:

Already tried the change, no cigar.

Another wild idea, let's say one of the 3 filter caps(1 nF, 100 nF, 1 uF) is faulty and makes the supply a little noisy, would that interfere enough with midi signal edges? I have no direct evidence of this but there's a chance one could be replaced. I will know more if I build my 2nd unit and that one works fine.

here's the bin (renamed) from rasteri's PC-104 sound card video