S95Sedan wrote on 2025-04-19, 21:46:

Did some tests on the same card but here it did nothing, no freezes. I suspect a lot of the issue are timing related and very hardware dependent.
What kind of system is the card in?

To be honest, this card currently runs on a modded X99 board with the help of dISAppointment v0.2.

It does have some minor issues apart from this one (freezing in DN2) but in most other, more common use cases, it runs perfectly fine.

I wonder if system TSR setup may also affect its functionality a bit, as I used my usual EMS-enabled config (using JEMMEX) here. Maybe I should test this with other params. I know that some games are quite sensitive about the TSRs being used in the system environment...

S95Sedan wrote on 2025-04-19, 21:46:

Yeah more of the buffer and dma16 initialization is left intact which probably helps with keeping hardware in check more.

Did some 6T mode timing tests aswell on some new chips (opposed to 12T for regular ones) and at double that speed it fully fixes (duke nukem 3d: atomic edition) stuttering at 44khz.
Still has timing issues though as it breaks the internal mpu401 port and prevents it from outputting audio.

I'm currently using STC90C58RD+ for the modded DSP FW on that card which can switch between 12T and 6T when flashing with its ISP tool. If you can adapt the FW to 6T timing (namely MPU401) I can test.

On the other hand, I also tested this with STC12C5A60S2, which is a modern, 1T-rated 8051 MCU.
Unlike 12T/6T MCUs its instruction cycles vary a lot. However, its timer remains 12T by default so MPU401 will continue working as usual there.

The tests were done on an older system before my current one, and the results back then were mixed. Some use cases such as Windows NT and Duke3D were broken while others fine. For that kind of MCU probably a lot more refactors needed. Additionally, for that MCU, internal XRAM (which will interfere with DSP operations) cannot be disabled via ISP and has to be disabled via code.

LSS10999 wrote on 2025-04-20, 03:58:

To be honest, this card currently runs on a modded X99 board with the help of dISAppointment v0.2. […]
Show full quote

S95Sedan wrote on 2025-04-19, 21:46:

Did some tests on the same card but here it did nothing, no freezes. I suspect a lot of the issue are timing related and very hardware dependent.
What kind of system is the card in?

To be honest, this card currently runs on a modded X99 board with the help of dISAppointment v0.2.

It does have some minor issues apart from this one (freezing in DN2) but in most other, more common use cases, it runs perfectly fine.

I wonder if system TSR setup may also affect its functionality a bit, as I used my usual EMS-enabled config (using JEMMEX) here. Maybe I should test this with other params. I know that some games are quite sensitive about the TSRs being used in the system environment...

S95Sedan wrote on 2025-04-19, 21:46:

Yeah more of the buffer and dma16 initialization is left intact which probably helps with keeping hardware in check more.

Did some 6T mode timing tests aswell on some new chips (opposed to 12T for regular ones) and at double that speed it fully fixes (duke nukem 3d: atomic edition) stuttering at 44khz.
Still has timing issues though as it breaks the internal mpu401 port and prevents it from outputting audio.

I'm currently using STC90C58RD+ for the modded DSP FW on that card which can switch between 12T and 6T when flashing with its ISP tool. If you can adapt the FW to 6T timing (namely MPU401) I can test.

On the other hand, I also tested this with STC12C5A60S2, which is a modern, 1T-rated 8051 MCU.
Unlike 12T/6T MCUs its instruction cycles vary a lot. However, its timer remains 12T by default so MPU401 will continue working as usual there.

The tests were done on an older system before my current one, and the results back then were mixed. Some use cases such as Windows NT and Duke3D were broken while others fine. For that kind of MCU probably a lot more refactors needed. Additionally, for that MCU, internal XRAM (which will interfere with DSP operations) cannot be disabled via ISP and has to be disabled via code.

Ah so its a non-standard setup. That might complicate things a bit more.
How does that compare vs the original firmware in terms of issues? Might have to do some tests for that in the future for that aswell, though i imagine if other cards work fine that should aswell.

The STC89C52RC is what i use , which i assume is fairly similair to the first one. Dont have a 1T chip currently but might pick one of those up aswell at some point.
The extra xram however does break things but thats expected as its not setup for that (from what i read its accessed in a certain way aswell for anything above 256bytes) but this chip can enable/disable either of them with just the programming settings.
Enabling 6T was done on the stock firmware, no additional changes made as of yet. But i havent looked into it much, possibly it are simple changes to restore mpu401 functionality with 6t enabled.

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have removed the mention of "removing X-Bus registers".

This time I experimented with 6T on my MCU (STC90C58RD+). To make MPU401 work in this timing only the timer values (TH1/TL1) need to be adjusted (from FCh to F8h) and no need to change anything else.

With this commit Sound Blaster sound (ADPCM) can actually be heard in DN2 (back then there were no sound at all with it).

However, the system would still freeze about 10 seconds after entering the game with Sound Blaster sound enabled, and the freeze does not appear specific to any sound effect so there might be other factors contributing to the symptom.

LSS10999 wrote on 2025-05-03, 13:47:

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have r […]
Show full quote

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have removed the mention of "removing X-Bus registers".

This time I experimented with 6T on my MCU (STC90C58RD+). To make MPU401 work in this timing only the timer values (TH1/TL1) need to be adjusted (from FCh to F8h) and no need to change anything else.

With this commit Sound Blaster sound (ADPCM) can actually be heard in DN2 (back then there were no sound at all with it).

However, the system would still freeze about 10 seconds after entering the game with Sound Blaster sound enabled, and the freeze does not appear specific to any sound effect so there might be other factors contributing to the symptom.

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed.

Yeah, 12t/6t switching is something i already documented in the version i have here but didn't add in the one uploaded, but changing init_timer1_byte_lo/init_timer1_byte_hi is all thats needed to be changed for 12t/6t. (It should have a note for it in the future)
Didn't want to focus on the 12t/6t too much though as some settings are constant in both modes, midi baudrate @ 31250 for example, upping that improves things but then its out of spec. But i still need to do more tests to pinpoint the exact cause of where the issue lies, midi_uart_init also seems to make things worse.

There was an error in one of the jumptables from what i seen which could possibly have been related as it manipulated both adpcm_state_reg and adpcm_mode_reg, but that should be fixed in the version below. Also changed it to autofill them so that should counter any problems in the future and make the code more flexible to changes.

Let me know if either one of these work better, or if they still have the same issues as i have no problems with any of my cards here. (12t stock settings, ver1 is closer to 413, ver2 has code which is cleaned up more and has alot of dma16 inits removed)

S95Sedan wrote on 2025-05-04, 22:48:

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed. […]
Show full quote

LSS10999 wrote on 2025-05-03, 13:47:

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have r […]
Show full quote

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have removed the mention of "removing X-Bus registers".

This time I experimented with 6T on my MCU (STC90C58RD+). To make MPU401 work in this timing only the timer values (TH1/TL1) need to be adjusted (from FCh to F8h) and no need to change anything else.

With this commit Sound Blaster sound (ADPCM) can actually be heard in DN2 (back then there were no sound at all with it).

However, the system would still freeze about 10 seconds after entering the game with Sound Blaster sound enabled, and the freeze does not appear specific to any sound effect so there might be other factors contributing to the symptom.

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed.

Yeah, 12t/6t switching is something i already documented in the version i have here but didn't add in the one uploaded, but changing init_timer1_byte_lo/init_timer1_byte_hi is all thats needed to be changed for 12t/6t. (It should have a note for it in the future)
Didn't want to focus on the 12t/6t too much though as some settings are constant in both modes, midi baudrate @ 31250 for example, upping that improves things but then its out of spec. But i still need to do more tests to pinpoint the exact cause of where the issue lies, midi_uart_init also seems to make things worse.

There was an error in one of the jumptables from what i seen which could possibly have been related as it manipulated both adpcm_state_reg and adpcm_mode_reg, but that should be fixed in the version below. Also changed it to autofill them so that should counter any problems in the future and make the code more flexible to changes.

Let me know if either one of these work better, or if they still have the same issues as i have no problems with any of my cards here. (12t stock settings, ver1 is closer to 413, ver2 has code which is cleaned up more and has alot of dma16 inits removed)

Is there any major change to the code (regarding ver1) since the current commit on GitHub?

I did a vbindiff with the hex assembled from the current commit and the ver1 you posted, there were only 2 bytes changed in 2 different places.

So far the issue is mainly about DN2's ADPCM playback (freeze) and I haven't encountered other issues at the moment.

LSS10999 wrote on 2025-05-05, 03:03:

Is there any major change to the code (regarding ver1) since the current commit on GitHub? […]
Show full quote

S95Sedan wrote on 2025-05-04, 22:48:

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed. […]
Show full quote

LSS10999 wrote on 2025-05-03, 13:47:

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have r […]
Show full quote

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have removed the mention of "removing X-Bus registers".

This time I experimented with 6T on my MCU (STC90C58RD+). To make MPU401 work in this timing only the timer values (TH1/TL1) need to be adjusted (from FCh to F8h) and no need to change anything else.

With this commit Sound Blaster sound (ADPCM) can actually be heard in DN2 (back then there were no sound at all with it).

However, the system would still freeze about 10 seconds after entering the game with Sound Blaster sound enabled, and the freeze does not appear specific to any sound effect so there might be other factors contributing to the symptom.

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed.

Yeah, 12t/6t switching is something i already documented in the version i have here but didn't add in the one uploaded, but changing init_timer1_byte_lo/init_timer1_byte_hi is all thats needed to be changed for 12t/6t. (It should have a note for it in the future)
Didn't want to focus on the 12t/6t too much though as some settings are constant in both modes, midi baudrate @ 31250 for example, upping that improves things but then its out of spec. But i still need to do more tests to pinpoint the exact cause of where the issue lies, midi_uart_init also seems to make things worse.

There was an error in one of the jumptables from what i seen which could possibly have been related as it manipulated both adpcm_state_reg and adpcm_mode_reg, but that should be fixed in the version below. Also changed it to autofill them so that should counter any problems in the future and make the code more flexible to changes.

Let me know if either one of these work better, or if they still have the same issues as i have no problems with any of my cards here. (12t stock settings, ver1 is closer to 413, ver2 has code which is cleaned up more and has alot of dma16 inits removed)

Is there any major change to the code (regarding ver1) since the current commit on GitHub?

I did a vbindiff with the hex assembled from the current commit and the ver1 you posted, there were only 2 bytes changed in 2 different places.

So far the issue is mainly about DN2's ADPCM playback (freeze) and I haven't encountered other issues at the moment.

No, only a small change in the jumptable to fix the incorrect offset.
It does however sets 2 registers for adpcm which could be the cause of the issues/freezing, thats why these 2 specific version to narrow down the problem. Both have the fix.

Its basically this part of the code, instead of jumping to the start of 'cmd_F0' wehn called which is offset 81h it used 7eh, so any command that calls it jumps to 'X1233' instead and then exits.

1X0a85:	lcall	X1233
2		ljmp	cmdg_f_exit
3
4cmd_F0:
5		mov		a,#5ah
6		lcall	X0a0e
7		lcall	X0a26
8		mov		adpcm_state_reg,#5
9		mov		adpcm_mode_reg,#0
10		mov		a,#60h
11		mov		r0,#4
12		movx	@r0,a
13		setb	ex0
14		ljmp	cmdg_f_exit

S95Sedan wrote on 2025-05-04, 22:48:

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed. […]
Show full quote

LSS10999 wrote on 2025-05-03, 13:47:

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have r […]
Show full quote

I just tested your most recent commit regarding the v4.17 custom FW. Haven't looked deeper but the documentation seems to have removed the mention of "removing X-Bus registers".

This time I experimented with 6T on my MCU (STC90C58RD+). To make MPU401 work in this timing only the timer values (TH1/TL1) need to be adjusted (from FCh to F8h) and no need to change anything else.

With this commit Sound Blaster sound (ADPCM) can actually be heard in DN2 (back then there were no sound at all with it).

However, the system would still freeze about 10 seconds after entering the game with Sound Blaster sound enabled, and the freeze does not appear specific to any sound effect so there might be other factors contributing to the symptom.

I brought it back more towards 413 by restoring some dma16 initialization parts, that's why the note was removed.

Yeah, 12t/6t switching is something i already documented in the version i have here but didn't add in the one uploaded, but changing init_timer1_byte_lo/init_timer1_byte_hi is all thats needed to be changed for 12t/6t. (It should have a note for it in the future)
Didn't want to focus on the 12t/6t too much though as some settings are constant in both modes, midi baudrate @ 31250 for example, upping that improves things but then its out of spec. But i still need to do more tests to pinpoint the exact cause of where the issue lies, midi_uart_init also seems to make things worse.

There was an error in one of the jumptables from what i seen which could possibly have been related as it manipulated both adpcm_state_reg and adpcm_mode_reg, but that should be fixed in the version below. Also changed it to autofill them so that should counter any problems in the future and make the code more flexible to changes.

Let me know if either one of these work better, or if they still have the same issues as i have no problems with any of my cards here. (12t stock settings, ver1 is closer to 413, ver2 has code which is cleaned up more and has alot of dma16 inits removed)

Just did a few more tests with DN2. It seems I can also reproduce the freeze on my system with maelgrum's earlier v4.13 fixes such as this one, though the freeze happens at a much later point on first level, usually after climbing up the first ladder, while going leftwards towards the second one.

With ver1 the freeze happens under similar circumstances with maelgrum's v4.13, while ver2 the freeze happened much earlier, even during the "target shooting" intro.

So ver1 is probably better for now, that the jumptable correction does fix things on the sound card (DSP) side but I suppose the freeze problem with DN2's ADPCM is not entirely sound card's fault...

LSS10999 wrote on 2025-05-05, 09:43:

Just did a few more tests with DN2. It seems I can also reproduce the freeze on my system with maelgrum's earlier v4.13 fixes such as this one, though the freeze happens at a much later point on first level, usually after climbing up the first ladder, while going leftwards towards the second one.

With ver1 the freeze happens under similar circumstances with maelgrum's v4.13, while ver2 the freeze happened much earlier, even during the "target shooting" intro.

So ver1 is probably better for now, that the jumptable correction does fix things on the sound card (DSP) side but I suppose the freeze problem with DN2's ADPCM is not entirely sound card's fault...

Allright, so its still there even with that.
Sounds more like a situation specific issue, maybe something due to having signal integrity issues? As it happens in every version.

Yeah ver1 is the one that's currently uploaded, can always remove the init stuff that's left in later.

S95Sedan wrote on 2025-05-06, 02:14:

Allright, so its still there even with that. Sounds more like a situation specific issue, maybe something due to having signal i […]
Show full quote

LSS10999 wrote on 2025-05-05, 09:43:

Just did a few more tests with DN2. It seems I can also reproduce the freeze on my system with maelgrum's earlier v4.13 fixes such as this one, though the freeze happens at a much later point on first level, usually after climbing up the first ladder, while going leftwards towards the second one.

With ver1 the freeze happens under similar circumstances with maelgrum's v4.13, while ver2 the freeze happened much earlier, even during the "target shooting" intro.

So ver1 is probably better for now, that the jumptable correction does fix things on the sound card (DSP) side but I suppose the freeze problem with DN2's ADPCM is not entirely sound card's fault...

Allright, so its still there even with that.
Sounds more like a situation specific issue, maybe something due to having signal integrity issues? As it happens in every version.

Yeah ver1 is the one that's currently uploaded, can always remove the init stuff that's left in later.

Not sure why DN2 would freeze the system under these circumstances.

The current system setup is stable enough AFAICT. A long time ago, when I just got dISAppointment working, the situation was much worse, with the sound card suddenly falling off the bus but other programs were more graceful -- sound would simply stop playing but will not freeze the entire system.

In one case I had a defective bridge chip that would suddenly stop working, and in another case I had a loose ISA connector that required effort to keep the card connected although it may still fall off intermittently, causing sound playback to suddenly stop but can be recovered by itself if the card is plugged firm enough into the slot.

Guess I really should proceed with patching the game to use PCM instead of ADPCM for further tests. If I still get freezes under that circumstance then whatever issues I'm still having are not DSP/ADPCM-related anymore, and that as of ver1 most known ADPCM-related issues can be considered fixed.

UPDATE: Just managed to apply the patches needed for playing DN2 using PCM sound instead of ADPCM. Played 3 levels and no freeze occurred during gameplay.

LSS10999 wrote on 2025-05-06, 03:22:

Not sure why DN2 would freeze the system under these circumstances. […]
Show full quote

S95Sedan wrote on 2025-05-06, 02:14:

Allright, so its still there even with that. Sounds more like a situation specific issue, maybe something due to having signal i […]
Show full quote

LSS10999 wrote on 2025-05-05, 09:43:

Just did a few more tests with DN2. It seems I can also reproduce the freeze on my system with maelgrum's earlier v4.13 fixes such as this one, though the freeze happens at a much later point on first level, usually after climbing up the first ladder, while going leftwards towards the second one.

With ver1 the freeze happens under similar circumstances with maelgrum's v4.13, while ver2 the freeze happened much earlier, even during the "target shooting" intro.

So ver1 is probably better for now, that the jumptable correction does fix things on the sound card (DSP) side but I suppose the freeze problem with DN2's ADPCM is not entirely sound card's fault...

Allright, so its still there even with that.
Sounds more like a situation specific issue, maybe something due to having signal integrity issues? As it happens in every version.

Yeah ver1 is the one that's currently uploaded, can always remove the init stuff that's left in later.

Not sure why DN2 would freeze the system under these circumstances.

The current system setup is stable enough AFAICT. A long time ago, when I just got dISAppointment working, the situation was much worse, with the sound card suddenly falling off the bus but other programs were more graceful -- sound would simply stop playing but will not freeze the entire system.

In one case I had a defective bridge chip that would suddenly stop working, and in another case I had a loose ISA connector that required effort to keep the card connected although it may still fall off intermittently, causing sound playback to suddenly stop but can be recovered by itself if the card is plugged firm enough into the slot.

Guess I really should proceed with patching the game to use PCM instead of ADPCM for further tests. If I still get freezes under that circumstance then whatever issues I'm still having are not DSP/ADPCM-related anymore, and that as of ver1 most known ADPCM-related issues can be considered fixed.

UPDATE: Just managed to apply the patches needed for playing DN2 using PCM sound instead of ADPCM. Played 3 levels and no freeze occurred during gameplay.

Good that at least the patch works.

Im working on getting some plcc breakout pcb's made to speed up testing a bit so when those are ordered ill add in the disappointment board aswell.
So hopefully the issue can be replicated at some point.

LSS10999 wrote on 2025-05-06, 03:22:

Not sure why DN2 would freeze the system under these circumstances. […]
Show full quote

Not sure why DN2 would freeze the system under these circumstances.

The current system setup is stable enough AFAICT. A long time ago, when I just got dISAppointment working, the situation was much worse, with the sound card suddenly falling off the bus but other programs were more graceful -- sound would simply stop playing but will not freeze the entire system.

In one case I had a defective bridge chip that would suddenly stop working, and in another case I had a loose ISA connector that required effort to keep the card connected although it may still fall off intermittently, causing sound playback to suddenly stop but can be recovered by itself if the card is plugged firm enough into the slot.

Guess I really should proceed with patching the game to use PCM instead of ADPCM for further tests. If I still get freezes under that circumstance then whatever issues I'm still having are not DSP/ADPCM-related anymore, and that as of ver1 most known ADPCM-related issues can be considered fixed.

UPDATE: Just managed to apply the patches needed for playing DN2 using PCM sound instead of ADPCM. Played 3 levels and no freeze occurred during gameplay.

There should be a newer version uploaded which i believe should fix duke2's hanging issues.
Already traced it back a while ago to some 4.16 functionality but implemented an additional dsp status check to see if dma is available so it doesn't put the game in an infinite loop. (therefor hanging)

S95Sedan wrote on 2025-06-01, 12:46:

There should be a newer version uploaded which i believe should fix duke2's hanging issues.
Already traced it back a while ago to some 4.16 functionality but implemented an additional dsp status check to see if dma is available so it doesn't put the game in an infinite loop. (therefor hanging)

I just tested the latest commit on that system using unpatched Duke2. Sadly the issue still remains. For now it hangs mostly while on the first floor of first level.

Considering my environment cannot be considered 100% reliable... I wonder if that game still hangs on others' cards with the latest commit, or perhaps we all have moved on with a patched game...

Is there any known problems for the last patched DSP firmware "v417-8k_1.0.bin" ver. 4.16 (4.17) with other softwares except this game Duke Nukem 2? If not, then why trying to fix the firmware instead of patching the game?

LSS10999 wrote on 2025-06-02, 11:20:

I just tested the latest commit on that system using unpatched Duke2. Sadly the issue still remains. For now it hangs mostly while on the first floor of first level.

Considering my environment cannot be considered 100% reliable... I wonder if that game still hangs on others' cards with the latest commit, or perhaps we all have moved on with a patched game...

Allright, will probably have a better look when i get my disappointment boards in, which are currently stuck in customs.

analog_programmer wrote on 2025-06-06, 08:15:

Is there any known problems for the last patched DSP firmware "v417-8k_1.0.bin" ver. 4.16 (4.17) with other softwares except this game Duke Nukem 2? If not, then why trying to fix the firmware instead of patching the game?

- Duke2 freezing in certain occasions.
- DMA Clicking (General SB16/32/AWE32 Issue present in all)
- MPU-Slowdown (General SB16/32/AWE32 Issue present in all) (due to code/8052 processing speed) (In Duke3d Atomic @ 44khz for example)

The 1.0 version is just working towards a stable base version with tidying up the codebase so the last 2 points can be fixed after that.

S95Sedan wrote on 2025-06-06, 19:25:

- DMA Clicking (General SB16/32/AWE32 Issue present in all)
- MPU-Slowdown (General SB16/32/AWE32 Issue present in all) (due to code/8052 processing speed) (In Duke3d Atomic @ 44khz for example)

The 1.0 version is just working towards a stable base version with tidying up the codebase so the last 2 points can be fixed after that.

Ok. If these two bugs are common for many applications and could be fixed, I think it is worth focusing more on them instead of trying to fix the specific problem with DN2 game.

DMA clicking can not be fixed in software

maxtherabbit wrote on 2025-06-07, 13:11:

DMA clicking can not be fixed in software

What is cause or more than one causes of DMA clicking? What is needed to fix this?

Cheers,