mattw wrote on 2023-10-02, 19:49:

DerBaum wrote on 2023-10-02, 19:41:

CT3600
crc32Hash: c263fd4b

hmm, only 1 byte is different compared to Ct2940, but both cards use the same CT2502 and what is the significance of that different single byte? could it be, that's some bug in V0.03? we need @Maelgrum opinion on this. [EDIT] or maybe it is silicon degradation and one single bit flipped with age?!

What is address of this different byte?

Maelgrum wrote on 2023-10-02, 19:57:

mattw wrote on 2023-10-02, 19:49:

DerBaum wrote on 2023-10-02, 19:41:

CT3600
crc32Hash: c263fd4b

hmm, only 1 byte is different compared to Ct2940, but both cards use the same CT2502 and what is the significance of that different single byte? could it be, that's some bug in V0.03? we need @Maelgrum opinion on this. [EDIT] or maybe it is silicon degradation and one single bit flipped with age?!

What is address of this different byte?

172c, its after the code ends though from what i can see. 00 instead of 80

mattw wrote on 2023-10-02, 19:49:

DerBaum wrote on 2023-10-02, 19:41:

CT3600
crc32Hash: c263fd4b

hmm, only 1 byte is different compared to Ct2940, but both cards use the same CT2502 and what is the significance of that different single byte? could it be, that's some bug in V0.03? we need @Maelgrum opinion on this. [EDIT] or maybe it is silicon degradation and one single bit flipped with age?!

ct2940 has a real opl and on ct3600 and ct 2950 it is not present.
I dont know how they decide to use the opl or the creative emulation. maybe in software by a setting a byte. But it also can be done on the hardware side to disable CQM when the OPL is present.

Maelgrum wrote on 2023-10-02, 19:57:

What is address of this different byte?

0000172C: 0x80 in any other Dump we made on any other card and 0x00 only in this dump.

mattw wrote on 2023-10-02, 20:00:

Maelgrum wrote on 2023-10-02, 19:57:

What is address of this different byte?

0000172C: 0x80 in any other Dump we made on any other card and 0x00 only in this dump.

i will dump it again to be sure it wasnt a fluke (was the ct3600 the card in question?)

DerBaum wrote on 2023-10-02, 20:02:

i will dump it again to be sure it wasnt a fluke

yes, maybe use the older version : it will take 25 minutes, but let's see if it's not the speed and new algo, that causes the card to do that.

Btw, I have a idea about Variant B and C.
4.13 fw used only 6k of ROM.
Top 2k is filled with some artifacts from early development stages - old ASP testing fw, and some sampled sines.
In discrete '52 this all stuff programmed.
But on integrated DSP, they just don't implement top 2k of ROM at all! It's unused, why spend chip area for unused ROM.
So in dumps from integrated '52, top 2k is not from ROM, but from floating bus.
So it is 0xff, 0xfc or whatever))

mattw wrote on 2023-10-02, 20:00:

Maelgrum wrote on 2023-10-02, 19:57:

What is address of this different byte?

0000172C: 0x80 in any other Dump we made on any other card and 0x00 only in this dump.

Ok, I will look into it.

Maelgrum wrote on 2023-10-02, 20:07:

Btw, I have a idea about Variant B and C. 4.13 fw used only 6k of ROM. Top 2k is filled with some artifacts from early develop […]
Show full quote

Btw, I have a idea about Variant B and C.
4.13 fw used only 6k of ROM.
Top 2k is filled with some artifacts from early development stages - old ASP testing fw, and some sampled sines.
In discrete '52 this all stuff programmed.
But on integrated DSP, they just don't implement top 2k of ROM at all! It's unused, why spend chip area for unused ROM.
So in dumps from integrated '52, top 2k is not from ROM, but from floating bus.
So it is 0xff, 0xfc or whatever))

it sounds absolutely plausible and beyond that - it's most likely the case. I was thinking it's ASP related, because the cards with discrete xx52 all have ASP - at least my cards I have - on some of the cards the ASP is not populated, but it has empty slot for it - I guess upgrade kit was sold to buy it and put in the empty slot.

mattw wrote on 2023-10-02, 20:04:

DerBaum wrote on 2023-10-02, 20:02:

i will dump it again to be sure it wasnt a fluke

yes, maybe use the older version : it will take 25 minutes, but let's see if it's not the speed and new algo, that causes the card to do that.

did a 0.03 dump again . its the same as before. will try 0.02 now

mattw wrote on 2023-10-02, 20:13:

it sounds absolutely plausible and beyond that - it's most likely the case. I was thinking it's ASP related, because the cards with discrete xx52 all have ASP - at my cards, on some of my cards the ASP is not populated, but it has empty slot for it - I guess upgrade kit was sold to buy it and put in the empty slot.

All production code for ASP is in lower 6k, in top 2k is UNUSED at all old testing fw.

DerBaum wrote on 2023-10-02, 20:15:

did a 0.03 dump again . its the same as before. will try 0.02 now

if it's not intentional, i.e. that byte changed by Creative for some reason we still don't know, it really could be silicon degradation, but let's see if the slow dump will lead to the same flipped byte.

DerBaum wrote on 2023-10-02, 20:15:

mattw wrote on 2023-10-02, 20:04:

DerBaum wrote on 2023-10-02, 20:02:

i will dump it again to be sure it wasnt a fluke

yes, maybe use the older version : it will take 25 minutes, but let's see if it's not the speed and new algo, that causes the card to do that.

did a 0.03 dump again . its the same as before. will try 0.02 now

If 0.02 gives same result - it's most likely one damaged bit ( from old age?)

Maelgrum wrote on 2023-10-02, 20:20:

DerBaum wrote on 2023-10-02, 20:15:

mattw wrote on 2023-10-02, 20:04:

yes, maybe use the older version : it will take 25 minutes, but let's see if it's not the speed and new algo, that causes the card to do that.

did a 0.03 dump again . its the same as before. will try 0.02 now

If 0.02 gives same result - it's most likely one damaged bit ( from old age?)

also on 0.02 172c is 0x80 on my ct3600

DerBaum wrote on 2023-10-02, 20:40:

also on 0.02 172c is 0x80 on my ct3600

very strange, maybe @Maelgrum can figure what that byte is supposed to do based on the 8051 assembler code, but currently I think we're talking about slightly faulty chip, in which that bit flipped due to aging process.

[EDIT] wait a minute, maybe, I misread, is it 0x80 or 0x00, because it's 0x00 in your older dump with v0.03 and that the strange/bad case? if now it's 0x80 then the v0.02 dump is good.

mattw wrote on 2023-10-02, 20:49:

DerBaum wrote on 2023-10-02, 20:40:

also on 0.02 172c is 0x80 on my ct3600

very strange, maybe @Maelgrum can figure what that byte is supposed to do based on the 8051 assembler code, but currently I think we're talking about slightly faulty chip, in which that bit flipped due to aging process.

i have a second ct3600. but its new in box and still has its foil. for a second i really thought i could test that, but i got the second card (wich i tested) to not have to unbox the nice one 😁

DerBaum wrote on 2023-10-02, 20:40:

also on 0.02 172c is 0x80 on my ct3600

please, re-confirm, because at least I am totally confused now - offset 0x172c value 0x80 is OK, offset 0x172c value 0x00 is the strange case. So, if you got value 0x80 for offset 0x172c with v0.02 that means maybe problem with v0.03. at least I, really got lost, because now you're talking for 2nd CT3600 card as well?!

mattw wrote on 2023-10-02, 21:02:

DerBaum wrote on 2023-10-02, 20:40:

also on 0.02 172c is 0x80 on my ct3600

please, re-confirm, because at least I am totally confused now - offset 0x172c value 0x80 is OK, offset 0x172c value 0x00 is the strange case. So, if you got value 0x80 for offset 0x172c with v0.02 that means maybe problem with v0.03. at least I, really got lost, because now you're talking for 2nd CT3600 card as well?!

i will do a dump with 0.02 and 0.03 again of my ct3600. ( i think i got confused and looked for the wrong value on 172c)

I have not unboxed the second ct3600, and i will probably not do that. Its my only Soundblaster in its original packaging that is still sealed in foil. I can not convince my self to open it.. even for science. i would rather buy another ct3600 to confirm that 😁

Checked this dump from DerBaum.
This dump has at location 0x172C value 0x00 (in known 4.13 it was 0x80).
This byte is inside ASP old testing fw, this fw is inaccesible in any way and unused.
Can it be intentional ? hmmm, dont know. It looks like a rom fault, not like intentional change.
Effect on work of SB - completely NONE.

DerBaum wrote on 2023-10-02, 21:14:

I have not unboxed the second ct3600, and i will probably not do that. Its my only Soundblaster in its original packaging that is still sealed in foil. I can not convince my self to open it.. even for science. i would rather buy another ct3600 to confirm that 😁

absolutely, keep the sealed one sealed, just take your time and do new dumps with the other card - maybe do not analyze them just upload them here - one with v0.02 and one with v0.03. thanks!

Maelgrum wrote on 2023-10-02, 21:18:

Can it be intentional ? hmmm, dont know. It looks like a rom fault, not like intentional change.
Effect on work of SB - completely NONE.

that's kind of cool and good luck - even the chip might slightly fail - it still continue to work properly.