if it gets incompletely written while being changed (updated? rewritten on power-up?) it will render the card invisible.
yeah, that is what makes most sense, i.e. that there was (common) case when the EEPROM gets corrupted, and their technical support was forced to release the EEPROM tool in order to recover it.
2. Anybody knows - can DOSbox ouput all commands sent to SB in some log ?
don't know if any of those will be of help to you, but just to mentioned them:
* you can try '86box' (instead DOSbox), you can build your own version of it from source - it builds really easy even in Windows, using 'MSYS2' building environment, then you can use their 'pclog' function to add debug messages for what you're interested in, I used it to debug some problems (with XGA driver):
* I am attaching the source code of the old VSB (Virtual Sound Blaster) emulator written by the Russian Andrew Zabolotny like 30 years ago. I doubt it contains anything unknown at this point, but it's still fascinating piece of software - if nothing else - make a mirror and archive it here.
Another patch can be made for V4.13.
Idea is this:
Complete rewrite execution of command 0x14, by using same codepath as in cmd 0xC0. Enable FIFO.
Looks interesting
Found this: https://www.gamedev.net/tutorials/programming … laster-16-r444/
The FIFO is used to eliminate inconsistencies in the sample period when the sound card is not able to get DMA when it needs it. With FIFO disabled, the card attempts DMA at precisely the instant that it needs a sample. If another device with a higher priority is accessing DMA, the sound card waits for the sample and the sampling rate may be decreased. The FIFO allows the DMA sample period to be more erratic without affecting the audio quality. The FIFO is cleared whenever a command is sent to the DSP. In Single-cycle mode, the DSP is constantly being reprogrammed. The FIFO may still contain data which has not been output when it cleared. To avoid this problem, the FIFO should be turned off for single-cycle mode. When in auto-initialized mode, the DSP is never reprogrammed. The FIFO can be left on and sound quality will be improved.
Cant get it to work on a ct3900, hangs on csp detection booting up, maybe it possibly needs the last 2kb?
Edit; On further look it seems shifted upwards, copyright at 413 starts at 175D and 416 is 162B
Were you able to get it working with the CSP driver disabled? I'm starting to wonder if the 4.16 doesn't work with the CT1747 bus interface.
diagnose doesn't find my CT2230 with the 8k 4.16 FW - should I have burned the 6k image instead?
8k 4.16 - is 6k 4.16 with some junk in upper 2k.
If 8k not working - then 6k will be not working.
4.16 is shorter then 4.13 - something is cutted.
4.13 patch 3/4 is superior to 4.16 - hanging note fixed and CSP/ASP is working.
In Interrupt handler routine they dont push/pop psw, but should have do so.
But they do push dpl, push dph and pop dpl,pop dph - but dptr is not used at all (int1 handler)
Dont do what needed, but do what not needed.
Unconditional jump to RET, in time critical handler - why not ? ))
Load register by value #08. And few lines below lets load it again by value #08 - looks like protection against high energy cosmic rays.
Optimization of time critical pieces of code ... what is that ? Lets do a multiple calls to few lines long routines instead.
etc ... etc ... etc ...
Thinking about Single cycle DMA bug ...
What happens inside SB after each command 0x14 (Single cycle DMA) ?
1. It must process Int 1 interrupt handler (end of block interrupt)
2. It must process new 0x14 command
But it is slow !
How much DSP cycles we have ? ( 1 cycle = minimum command execution time = 12 OSC clocks )
For 8000 sampling rate, we have 2000000/8000 = 250 cycles
For 11025 = 2000000/11025 = 180 cycles
But 180 cycles is not 180 DSP operations, as some operations can take 2 cycles
Current implementation of interrupt handlers and command processing is very inefficient.
Maybe if execution path of command 0x14 processing, and execution of its end of block interrupt is optimized for minimization of execution time,
Single cycle clicks will be minimized
Last edited by Maelgrum on 2023-10-06, 05:36. Edited 3 times in total.
Maelgrumwrote on 2023-10-05, 21:19:This merging is not reliable - it contains some invalid definitions , like:
m 24 autoinit_16bit ; 24h.2 x
this is not true ) […] Show full quote
This merging is not reliable - it contains some invalid definitions , like:
m 24 autoinit_16bit ; 24h.2 x
this is not true ))
So it is better to analyze code, what was true in DSP 2.0, is not in DSP 4.xx
It definately needs some work but its surprising how many similairities it has to the 2.02 one though.
Cant get it to work on a ct3900, hangs on csp detection booting up, maybe it possibly needs the last 2kb?
Edit; On further look it seems shifted upwards, copyright at 413 starts at 175D and 416 is 162B
Were you able to get it working with the CSP driver disabled? I'm starting to wonder if the 4.16 doesn't work with the CT1747 bus interface.
Yeah, i used a ct1740 as the ct3900 would hang on/after loading csp.sys.
This is what i used; (my config is a bit more complicated, as i have a selection menu for all my cards, but i think thats the important stuff)
So i did a execution trace of interrupt handler = its ~94 cycle
execution trace of command 0x14 execution path is ~174 cycle
In total it is 268 cycles - even in most optimistic case - we out of bounds (> 250)
S95Sedanwrote on 2023-10-06, 05:29:It definately needs some work but its surprising how many similairities it has to the 2.02 one though. […] Show full quote
Maelgrumwrote on 2023-10-05, 21:19:This merging is not reliable - it contains some invalid definitions , like:
m 24 autoinit_16bit ; 24h.2 x
this is not true ) […] Show full quote
This merging is not reliable - it contains some invalid definitions , like:
m 24 autoinit_16bit ; 24h.2 x
this is not true ))
So it is better to analyze code, what was true in DSP 2.0, is not in DSP 4.xx
It definately needs some work but its surprising how many similairities it has to the 2.02 one though.
Cant get it to work on a ct3900, hangs on csp detection booting up, maybe it possibly needs the last 2kb?
Edit; On further look it seems shifted upwards, copyright at 413 starts at 175D and 416 is 162B
Were you able to get it working with the CSP driver disabled? I'm starting to wonder if the 4.16 doesn't work with the CT1747 bus interface.
Yeah, i used a ct1740 as the ct3900 would hang on/after loading csp.sys.
This is what i used; (my config is a bit more complicated, as i have a selection menu for all my cards, but i think thats the important stuff)
based on the reports here that CSP.SYS fails to load on AWE32 when the MCU is flashed with V4.16, I think best guess is the ASP code is removed from the V4.16 DSP - looking at 86box AWE32/ASP emulation code:
1case 0x01: /* asp_data_len???? */ 2case 0x03: /* ASP status */ 3case 0x04: /* ASP set mode register */ 4case 0x05: /* ASP set codec parameter */ 5case 0x08: /* ASP get version */ 6case 0x0E: /* ASP set register */ 7case 0x0F: /* ASP get register */
also, in "Reverse engineering the SB16 ASP/CSP" thread here:
I meant were you able to get the CT3900 specifically to work with 4.16 if you simply don't load CSP.SYS
Not sure, dont know if i did as i mostly wanted to confirm if the firmware was actually good. So switched to a ct1740 quite fast, also to see if the dma stuff was still there.