Tiido wrote on 2023-10-07, 09:11:

The UART is for MIDI which is 31250baud and that can be divided exactly from the 24MHz already present. For regular COM port stuff you do want a 11.0592 or some multiple of that.

That's good to know.

In 4.16 code - MIDI UART setup is the same, as in 4.13
So, timers in 4.16 clocked from 24 MHz

Question - can AWE64 V4.16 work with DOS games without ANY Creative utilities in autoexec.bat ?
I see a difference between V4.13 and V4.16 - 4.16 at reset _disables_ it internal IT1 interrupt
IT1 is interrupt at end of dma block

V4.16 has 2 new undocumented commands:
0xD7 - enable IT1
0xD2 - disable IT1
this commands is only way to control state of IT1, only 0xD7 can set it

So something from outside MUST send 0xD7 command, so card can work

Patched V4.16 - this IT1 behaviour is removed

Maelgrum wrote on 2023-10-07, 10:51:

Question - can AWE64 V4.16 work with DOS games without ANY Creative utilities in autoexec.bat ? I see a difference between V4.13 […]
Show full quote

Question - can AWE64 V4.16 work with DOS games without ANY Creative utilities in autoexec.bat ?
I see a difference between V4.13 and V4.16 - 4.16 at reset _disables_ it internal IT1 interrupt
IT1 is interrupt at end of dma block

V4.16 has 2 new undocumented commands:
0xD7 - enable IT1
0xD2 - disable IT1

So some external creative utility MUST send 0xD7 command, so card can work
Was it implemented as a way to force users run Creative utilities in autoexec ?.....

Yeah that 'setb it1' vs 'clr it1'was one of the few changes i noted aswell.
Gimme a sec to see if that changes anything in how the ct3900 operates and if it still hangs.

Edit; Doesnt seem to change things, see the attached screen.
Thats where it stays. When CSP.SYS is disabled it doesnt detect at all and gives a DIGN8002 error.

I see what V4.16 uses new x-bus register 0x18
It is set to 0, if sample rate < 45312, and set to 1 if >= 45312

And i see new undocumented command 0x43 (Set sample rate)
hmmm ... is it for setting 48000 khz ? )) interesting.

S95Sedan wrote on 2023-10-07, 11:13:

Edit; Doesnt seem to change things, see the attached screen.
Thats where it stays. When CSP.SYS is disabled it doesnt detect at all and gives a DIGN8002 error.

As 4.16 uses some new x-registers, it may be incompatible with some old Bus interface chips

And i clearly see what V4.16 has shorter execution time of 0x14 (single cycle DMA DAC) command.

Looks like they implemented some external trace features in x-port 0x05.
Bits 7,6,5 are used as indicators of execution time or event triggering (of interrupt handlers, commands, e.t.c)
So they can attach oscilloscope to some pins of Bus control chip and realtime monitor timings.
This is useful for debug, but bad idea to leave it in production code.
Consequences is:
1. Hanging note bug
2. Damged interrupt handlers
3. Slowdown of code execution (critical for Single cycle dma bug, as i see it)

Maelgrum wrote on 2023-10-07, 12:01:

Looks like they implemented some external trace features in x-port 0x05. Bits 7,6,5 are used as indicators of execution time or […]
Show full quote

Looks like they implemented some external trace features in x-port 0x05.
Bits 7,6,5 are used as indicators of execution time or event triggering (of interrupt handlers, commands, e.t.c)
So they can attach oscilloscope to some pins of Bus control chip and realtime monitor timings.
This is useful for debug, but bad idea to leave it in production code.
Consequences is:
1. Hanging note bug
2. Damged interrupt handlers
3. Slowdown of code execution (critical for Single cycle dma bug, as i see it)

All this stuff in 4.13;

1	mov	r0,#5
2	movx	a,@r0
3	setb	acc.x
4	movx	@r0,a
5	pop	acc
6	push	acc

Couldnt it all just be ripped out and possibly have a fully fixed 4.13.
(Thats assuming what broke the DMA aswell.)

S95Sedan wrote on 2023-10-07, 12:10:

All this stuff in 4.13; […]
Show full quote

Maelgrum wrote on 2023-10-07, 12:01:

Looks like they implemented some external trace features in x-port 0x05. Bits 7,6,5 are used as indicators of execution time or […]
Show full quote

Looks like they implemented some external trace features in x-port 0x05.
Bits 7,6,5 are used as indicators of execution time or event triggering (of interrupt handlers, commands, e.t.c)
So they can attach oscilloscope to some pins of Bus control chip and realtime monitor timings.
This is useful for debug, but bad idea to leave it in production code.
Consequences is:
1. Hanging note bug
2. Damged interrupt handlers
3. Slowdown of code execution (critical for Single cycle dma bug, as i see it)

All this stuff in 4.13;

Copy code to clipboard

1	mov	r0,#5
2	movx	a,@r0
3	setb	acc.x
4	movx	@r0,a
5	pop	acc
6	push	acc

Couldnt it all just be ripped out and possibly have a fully fixed 4.13. Thats assuming what broke the DMA aswell.

that's the plan ))
rip this stuff out, and insert in command loop dedicated processing of CMD 0x14

Maelgrum wrote on 2023-10-07, 12:14:

rip this stuff out, and insert in command loop dedicated processing of CMD 0x14

I guess you are aware of the "correct" way to use CMD 0x14, but I consider the classic playback command to be severely underdocumented on most "soundblaster guides". Of course, they all get the basics correct: You issue command 0x14 and then you send the length. The card starts playback at the rate programmed by command 0x40, and after the last byte has been played back, an interrupt is generated. You can do the same with command 0x1C ("auto init"), and in that case, the soundblaster card keeps playing back samples and resets the sample counter, so interrupts are generated periodically. That's what everyone knows...

The key point on the other hand is that the CMD 0x14 can be queued in a queue with depth 1. You can send another 0x14 command while the previous block is still worked on, and when the counter of the first block expired, another block is seamlessly started with the length given in the second command, allowing gapless chaining of blocks even without using the auto-init feature, and allowing a different block size on each chained block.

Furthermore, you can also queue a 0x14 command while an auto-init playback (0x1c) is still in progress. In that case, the current iteration of the auto-init command is finished, an IRQ is generated, and then a final block is played with the length given in the 0x14 command and then a second IRQ is generated and playback stops.

The same applies to the ADPCM playback commands in a similar manner.

Whatever you do to optimize "command 0x14" playback, make sure to not disrupt the "queued command" use-case.

mkarcher wrote on 2023-10-07, 12:36:

I guess you are aware of the "correct" way to use CMD 0x14, but I consider the classic playback command to be severely underdocu […]
Show full quote

Maelgrum wrote on 2023-10-07, 12:14:

rip this stuff out, and insert in command loop dedicated processing of CMD 0x14

I guess you are aware of the "correct" way to use CMD 0x14, but I consider the classic playback command to be severely underdocumented on most "soundblaster guides". Of course, they all get the basics correct: You issue command 0x14 and then you send the length. The card starts playback at the rate programmed by command 0x40, and after the last byte has been played back, an interrupt is generated. You can do the same with command 0x1C ("auto init"), and in that case, the soundblaster card keeps playing back samples and resets the sample counter, so interrupts are generated periodically. That's what everyone knows...

The key point on the other hand is that the CMD 0x14 can be queued in a queue with depth 1. You can send another 0x14 command while the previous block is still worked on, and when the counter of the first block expired, another block is seamlessly started with the length given in the second command, allowing gapless chaining of blocks even without using the auto-init feature, and allowing a different block size on each chained block.

Furthermore, you can also queue a 0x14 command while an auto-init playback (0x1c) is still in progress. In that case, the current iteration of the auto-init command is finished, an IRQ is generated, and then a final block is played with the length given in the 0x14 command and then a second IRQ is generated and playback stops.

The same applies to the ADPCM playback commands in a similar manner.

Whatever you do to optimize "command 0x14" playback, make sure to not disrupt the "queued command" use-case.

I only planned for faster 0x14 command dispatching (direct compare and jump), without long way of jumptables.
All logic will be same.
BTW, with this queue even old 'classic' V4.13 should play seamlessly, without SCDMA clicking bug. But this technique must be implemented in game.

Maelgrum wrote on 2023-10-07, 12:14:

S95Sedan wrote on 2023-10-07, 12:10:

All this stuff in 4.13; […]
Show full quote

Maelgrum wrote on 2023-10-07, 12:01:

Looks like they implemented some external trace features in x-port 0x05. Bits 7,6,5 are used as indicators of execution time or […]
Show full quote

Looks like they implemented some external trace features in x-port 0x05.
Bits 7,6,5 are used as indicators of execution time or event triggering (of interrupt handlers, commands, e.t.c)
So they can attach oscilloscope to some pins of Bus control chip and realtime monitor timings.
This is useful for debug, but bad idea to leave it in production code.
Consequences is:
1. Hanging note bug
2. Damged interrupt handlers
3. Slowdown of code execution (critical for Single cycle dma bug, as i see it)

All this stuff in 4.13;

Copy code to clipboard

1	mov	r0,#5
2	movx	a,@r0
3	setb	acc.x
4	movx	@r0,a
5	pop	acc
6	push	acc

Couldnt it all just be ripped out and possibly have a fully fixed 4.13. Thats assuming what broke the DMA aswell.

that's the plan ))
rip this stuff out, and insert in command loop dedicated processing of CMD 0x14

If it's as simple as stripping a few lines, how about a test build 😁

maxtherabbit wrote on 2023-10-07, 13:16:

Maelgrum wrote on 2023-10-07, 12:14:

S95Sedan wrote on 2023-10-07, 12:10:

All this stuff in 4.13; […]
Show full quote

All this stuff in 4.13;

Copy code to clipboard

1	mov	r0,#5
2	movx	a,@r0
3	setb	acc.x
4	movx	@r0,a
5	pop	acc
6	push	acc

Couldnt it all just be ripped out and possibly have a fully fixed 4.13. Thats assuming what broke the DMA aswell.

that's the plan ))
rip this stuff out, and insert in command loop dedicated processing of CMD 0x14

If it's as simple as stripping a few lines, how about a test build 😁

Just prepared build environment - keil c51 with srec_cat.
Then my sb16 autoparse utility must be patched to output jumptables for asm code.
Then test build verified so it gives same bin.
And then few lines can be stripped (in reality, many lines)

Maelgrum wrote on 2023-10-07, 12:54:

BTW, with this queue even old 'classic' V4.13 should play seamlessly, without SCDMA clicking bug. But this technique must be implemented in game.

And without this queue implemented in the game, we do not only need to look at latency in the DSP firmware, but also at interrupt latency on the host processor side. Interrupt latency is known to be "less than stellar" as soon as EMM386 is loaded, and furthermore, interrupts may be disabled on the host using CLI as well. Small gaps in the playback between blocks will happen on all kinds of SB cards if the game doesn't use queuing. I wonder whether the clicking is caused by the new Sigma/Delta-DAC technology on the SB16, which needs a constant clock to be able to output anything (except 0V), so interruptions of the DAC data stream may cause analog signal disruption.

Fixed a bug in ADPCM handling of V4.13

Instead of writing:
mov a,#0ffh
they wrote:
mov a,0ffh
that was a reason of some ADPCM modes not working with V4.04-V4.13
That bug was fixed in V4.16

Maelgrum wrote on 2023-10-07, 10:51:

Question - can AWE64 V4.16 work with DOS games without ANY Creative utilities in autoexec.bat ?

Yes, the SB16 portion of the AWE64 sound card works with any DOS games without CTCM if the necessary resources are set by the PnP BIOS.

AWEUTIL is still required for EMU8K initialization due to the FM synth output being routed to it.

Original V4.13 (without patches) assemble file.
Produced .bin is same as original .bin.

I've just realized based on the discussion earlier today about the 24MHz that I ordered wrong 8052 MCU part. So just to prevent anyone else making the same mistake, the 24MHz is marked on the chip for example:

AT89C52-24JI

but WRONG ones are:

AT89C52-20JC

AT89C52-16JC

which are respectively 20MHz and 16MHz parts. Same with Intel N87C52 - without anything else it's 12MHz and the 24MHz part is marked as "N87C52-24". Signetics /Philips/NXP and other do not include clearly the MHz in the marking and you need to consult with their datasheet, which Letters in the marking means it's 24MHz part.

[EDIT] All of the above are mainly OTP (One-Time-Programmable), which means you can use it only once and no longer update it in case there is new fix. So, I guess in that regards the best is:

AT89S52-24JU

because you can reprogram it up to 10 000 times.

[EDIT]
correction, it seems I confused AT89C52 with AT87C52, which is OTP, AT89C52 is re-programmable - thanks to @maxtherabbit :

maxtherabbit wrote on 2023-10-07, 18:41:

AT89C52-24JI/C is not OTP. You can reprogram it many times