640K!enough wrote on 2021-06-21, 18:39:

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.

in the first post with hostload (Re: Tiny Vortex86-based DOS gaming PC - weeCee) this line was used:

1  DB      00CH                    ; GCB1: WTEN SPS

which you then corrected in this post (Re: Tiny Vortex86-based DOS gaming PC - weeCee) to this line:

1  DB      084H                    ; GCB1: IFM SPS

but I posit it should be this instead:

1 DB      08CH                    ; GCB1: IFM SPS WTEN

there's also a reference to WTEN elsewhere in the documentation, as part of byte C8 (CS9236 Wavetable Control C8)

is that something that must be deal with in the ASM file as well, or is it an control byte that happens as per midi operations

edit - I guess WTEN is not super useful in this project, seeing as XD7-XD5 are connected to nothing..

A revised version of rasteri's bin file is attached. I removed the EEPROM header (first four bytes) and stripped the part that is supposed to be firmware patch data. The rest is entirely his file, byte-for-byte. To use this, simply add it to your hostload directory, and invoke it with "HOSTLOAD rasteri.bin".

The firmware part shouldn't make any difference, since you are using CWDINIT, and it will upload the most recent firmware that was available for the part at the time of release.

This design has no use for the serial port or related WTEN bit. In either case, we should find out if any of those were the culprit once you try the hostload procedure with rasteri's configuration data. Also note that I tried the procedure that I am describing with the attached bin, and it does work.

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

A revised version of rasteri's bin file is attached. I removed the EEPROM header (first four bytes) and stripped the part that is supposed to be firmware patch data. The rest is entirely his file, byte-for-byte. To use this, simply add it to your hostload directory, and invoke it with "HOSTLOAD rasteri.bin".

I'm sorry, I think I might have wasted your time - just for kicks I tried re-writing your CS4237.BIN file (with the first four bytes added) using my TL866 and it worked this time for some reason. I guess I must have messed up the first time.

But, still, I can't get hostload to work with either your .BIN or the headerless version of mine. When I say "not work" I mean soundblaster audio doesn't work and softMPU won't initialize, Adlib and MIDI do work though (and I'm not getting any weird note corruption bugs like Mu0n).

Also still can't get resource.exe to write to the EEPROM. Mu0n, did you ever successfully do an EEPROM write from resource.exe? I can't remember you saying.

Nope, My guess is that the eeprom does not play well with the bigger changes from low to high when it expects to go to around 2. 5 V tops in regular operation mode.

Mu0n wrote on 2021-06-21, 20:49:

Nope, My guess is that the eeprom does not play well with the bigger changes from low to high when it expects to go to around 2. 5 V tops in regular operation mode.

Are you referring to Keropi's warning about the AT24C16? We're using the 24LC04B which should be fine with 5v.

Still I only used it because it's what was on the cheap soundcard I reverse-engineered, perhaps the CS4237 isn't fully compatible with it. I should have some other random I2C EEPROMS somewhere

Oh hey, never mind. I managed to get the EEPROM to write after all. I think I had a dry solder joint, I must have desoldered-resoldered this EEPROM 10 times today 😀

But yeah that works just fine for SB/Adlib/MIDI. Still can't get hostload to work though, I'll keep trying stuff.

What...

I'll film my eeprom in super close up shot tonight and would appreciate if anyone can tell me if it can be vastly improved.

Did I damage a capacitor near my eeprom? That could mess with the startup of a writing command...

rasteri wrote on 2021-06-21, 20:42:

I'm sorry, I think I might have wasted your time - just for kicks I tried re-writing your CS4237.BIN file (with the first four bytes added) using my TL866 and it worked this time for some reason. I guess I must have messed up the first time.

At least that does confirm that the files I have been providing are valid. I try to test these things before sharing them, so there are very few reasons that they should fail to work. Design differences can account for some of that possibility, but the remainder would likely come down to assembly or configuration.

rasteri wrote on 2021-06-21, 21:15:

Are you referring to Keropi's warning about the AT24C16? We're using the 24LC04B which should be fine with 5v.

Although a little small, given how inexpensive they are, that part should work fine with the CS4237, as long as it has stable power, a proper pull-up on SDA and everything is cleanly soldered in place. The pull-up could be responsible for problems, if it is having enough of an effect on the rise time of SDA with respect to SCL.

rasteri wrote on 2021-06-21, 21:38:

Still can't get hostload to work though, I'll keep trying stuff.

This is a bit of a strange thing to read. Assuming the contents of your EEPROM still correspond to CS4237B.ASM, can you download UNISOUND and try a quick test?

1. Immediately following boot (don't run CWDINIT or anything else), run "UNISOUND /cl" and check the ID and description for the card.
2. Run HOSTLOAD with RASTERI.BIN.
3. Again run "UNISOUND /cl". Does the ID and description now correspond to the ID from your original EEPROM? If not, something in the hostload process itself failed.

640K!enough wrote on 2021-06-22, 02:40:

[…]
Show full quote

1. Immediately following boot (don't run CWDINIT or anything else), run "UNISOUND /cl" and check the ID and description for the card.
2. Run HOSTLOAD with RASTERI.BIN.
3. Again run "UNISOUND /cl". Does the ID and description now correspond to the ID from your original EEPROM? If not, something in the hostload process itself failed.

When I do this, the ID changes from "CS4237B" (your ROM) to "AW35/Pro (Resource R2.2-D7)" (my ROM).

When I then run cwdinit/cwdmix or unisound, SB/MIDI/Adlib all work in this configuration, although the synth volume is reduced somewhat compared to your ROM even when I manually turn the mixer up (I guess that must be a setting in my ROM) - so hostload is definitely uploading something to the CS4237.

If I try to do a hostload with a blank EEPROM (or no EEPROM at all), unisound and fixRDP report changes as expected, and CWDinit/unisound initialize exactly as if there was an EEPROM present - except Soundblaster stops working. MIDI/Adlib are unaffected, although the MPU-401 IRQ (9) shows as "fail" in CWDIAG. (EDIT : Soundblaster IRQ 5 shows as fail too, even though port 220 and DMA 1 show as "pass"... I guess the problem is IRQ?)

Once I (re)write either your or my ROM to the EEPROM, either by using my TL866 or RESOURCE.EXE, Soundblaster starts working again - either using hostload or without.

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.

Oh, and I found the reason I couldn't write to the EEPROM before - it turns out the BIN file I provided somehow stops RESOURCE.EXE writing to the EEPROM. I guess probably because the length is incorrect. Flashing stuff on top of your BIN/ASM file works fine, but the moment I flash my BIN file (or the same BIN converted to ASM for RESOURCE.EXE) to the EEPROM it stops any future writes from working.

Mu0n, I guess my BIN file is just hopelessly broken, so I think you'd be better off just erasing the 24LC04 and writing 640K!enough's ASM file using RESOURCE.EXE.

Roger that on the eeprom info, thanks.

Get a load of this. On a whim, I decided to hastily build (not too hastily) my 2nd unit but with minimal functionality, meaning: no usb port, no ethernet no gameport. I didn't solder the eeprom subcircuit at all and didn't include the PC speaker subcircuit (tied to MIN on the CS4237B) . I did solder the wavetable header of course because I'm obsessed with making this thing work.

After 2 hours lost on a PS/2 jack soldered on the wrong side (this one required braid, hot gun, more solder, attempt at conducting heat with a medium gage copper wire to the big pins all at once, more braid, learning to use a cheap solder sucker pump for the first time after never taking a liking to it before, and finally, gentle pressure and very determined hot air...), the system boots! Hooray!

Tests:

Planet x3: adlib sound works!
Cry v250 cwdiag (still not using that version, but its diag tool is very useful) reports the same as rasteri when he has no eeprom: SB irq 5 fails, DMA works, Fm music works.
Megamid accepts the MPU port and..... Plays EXACTLY as my other computer, meaning, random slow notes gibberish. This gives a higher likelihood that the solution is sound chip setup related. I'm not even using its Rom, this can only mean the host load process is missing something in the ini file or there's a hardware step that can't be omitted for MPU sound.

Someone local to me has also built his first unit and he reports SB sound and Fm music working, I pressed him for midi but his answer left me with some doubts. He may or may not have read this thread and if he did, I'm not sure which advice he picked up. I'll contact him again to compare notes.

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

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

I would just desolder the EEPROM and blank it in your programmer - you have a heat gun right? I've desoldered my EEPROM probably 15 times now while testing various things in this thread haha 😀

rasteri wrote on 2021-06-23, 11:22:

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

I would just desolder the EEPROM and blank it in your programmer - you have a heat gun right? I've desoldered my EEPROM probably 15 times now while testing various things in this thread haha 😀

Desoldering is no longer dreaded by me thanks to the heat gun, but it's the lack of programmer adapter. It's taking its sweet time by mail atm. The projection tells me it'll be here on July 2nd. No more of that awful spider jank. (btw check your DMs)

I knew it wasn't the problem at all (since my SC88st is also plagued by weird notes), but I tried out the S2 on my Vibra Ct2940 in my 486 and it works well.

Next up, Mu0n's exposed soldering technique fully zoomed in, vulnerable to the critics on the world stage!
It is possible I'm not completely covering the legs with solder, but it would have to simultaneously emit garbage in midi out but also allow perfect multimeter continuity tests without issue.
Another potential reason is leftover hardened no-clean flux (which I'm now learning it's hated as much as RoHS solder...) that I can't get out 100% between the Qfp legs. The immediate neighbors are JAB2 (joystick button, used in machine #1 but not at all in #2) and midi in which is connected to filtered 5V..

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

I knew it wasn't the problem at all (since my SC88st is also plagued by weird notes), but I tried out the S2 on my Vibra Ct2940 […]
Show full quote

I knew it wasn't the problem at all (since my SC88st is also plagued by weird notes), but I tried out the S2 on my Vibra Ct2940 in my 486 and it works well.

Next up, Mu0n's exposed soldering technique fully zoomed in, vulnerable to the critics on the world stage!
It is possible I'm not completely covering the legs with solder, but it would have to simultaneously emit garbage in midi out but also allow perfect multimeter continuity tests without issue.
Another potential reason is leftover hardened no-clean flux (which I'm now learning it's hated as much as RoHS solder...) that I can't get out 100% between the Qfp legs. The immediate neighbors are JAB2 (joystick button, used in machine #1 but not at all in #2) and midi in which is connected to nothing in machine #2

To be honest it's much more likely to be just the EEPROM is corrupted than your soldering - your post here seems to indicate that it didn't completely write - Re: Tiny Vortex86-based DOS gaming PC - weeCee

rasteri wrote on 2021-06-23, 19:29:

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

I knew it wasn't the problem at all (since my SC88st is also plagued by weird notes), but I tried out the S2 on my Vibra Ct2940 […]
Show full quote

I knew it wasn't the problem at all (since my SC88st is also plagued by weird notes), but I tried out the S2 on my Vibra Ct2940 in my 486 and it works well.

Next up, Mu0n's exposed soldering technique fully zoomed in, vulnerable to the critics on the world stage!
It is possible I'm not completely covering the legs with solder, but it would have to simultaneously emit garbage in midi out but also allow perfect multimeter continuity tests without issue.
Another potential reason is leftover hardened no-clean flux (which I'm now learning it's hated as much as RoHS solder...) that I can't get out 100% between the Qfp legs. The immediate neighbors are JAB2 (joystick button, used in machine #1 but not at all in #2) and midi in which is connected to nothing in machine #2

To be honest it's much more likely to be just the EEPROM is corrupted than your soldering - your post here seems to indicate that it didn't completely write - Re: Tiny Vortex86-based DOS gaming PC - weeCee

See, this is why I have a 2nd machine with no soldered eeprom at all going, to eliminate any problem related to that part.

My machine #2 should behave exactly like yours yesterday before you added your own eeprom. I've seen you use light application of flux from a pen in your videos, while I have a no-clean flux from a syringe.

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

Mu0n ,

If you got a couple of resistors, transistors, an old parallel port printer cable, you can bodge your own i²C programmer.
https://scienceprog.com/i2c-eprom-programmer/

I used it once to read out an xbox eeprom.

weedeewee wrote on 2021-06-23, 19:58:

Mu0n , […]
Show full quote

Mu0n ,

If you got a couple of resistors, transistors, an old parallel port printer cable, you can bodge your own i²C programmer.
https://scienceprog.com/i2c-eprom-programmer/

I used it once to read out an xbox eeprom.

I have a TL866ii Plus programmer that works fine - I programmed some replacement Mac Plus ROMs succesfully and the eeprom in this project just fine. What I lack is an adapter for SOIC-8 chips so that it can connect to the 40 pin ZIF socket. I soldered janky wires (back on page 2? I posted pics) and it worked. One attempt to read it was giving the impression it was badly written, but another attempt showed the correct data after reflowing the pins on the eeprom. I have this clamp incoming to my house on July 2nd, which will make any burning effort way easier.

Those can be used to clamp on the chip on board but ...
many persons that have tried to use this to reprogram their motherboard bios will have noticed,
that the power line that powers the eeprom is also shared to the rest of the board and most programmers will not work with such a load on their power supply.
They're not that easy to program the chip off board either.

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

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?