(discrete) V4.16 looks like it has some valid data in 0x1800-0x1FFF area, but it is has not.
Data in 0x18XX is the same as in 0x19XX and so on. it is just copy of valid ROM from lower region - some address decoding artefact.
So it is 6k ROM.

Maelgrum wrote on 2023-10-04, 16:29:

(discrete) V4.16 looks like it has some valid data in 0x1800-0x1FFF area, but it is has not.
Data in 0x18XX is the same as in 0x19XX and so on. it is just copy of valid ROM from lower region - some address decoding artefact.
So it is 6k ROM.

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

maxtherabbit wrote on 2023-10-04, 16:08:

Run DOTT again with music disabled please

Heres a direct audio output.

S95Sedan wrote on 2023-10-04, 16:32:

Cant get it to work on a ct3900, hangs on csp detection booting up, maybe it possibly needs the last 2kb?

No, last 2k is never used.
But 4.16 looks more compact - maybe ASP/CSP commands are cutted ? this needs to be researched.
Main question is - has 4.16 any benefits ?
IMHO, This DOTT audio sounds OK.

Maelgrum wrote on 2023-10-04, 16:40:

No, last 2k is never used. But 4.16 looks more compact - maybe ASP/CSP commands are cutted ? this needs to be researched. Main q […]
Show full quote

No, last 2k is never used.
But 4.16 looks more compact - maybe ASP/CSP commands are cutted ? this needs to be researched.
Main question is - has 4.16 any benefits ?
IMHO, This DOTT audio sounds OK.

Possibly, maybe they just fixed the bug that was present and the removed the asp code as its not used/was worked on being removed in their software anyway. But yeah need some more investigating.
Added 4.13 aswell so its easier to compare, sounds pretty similair to me.

S95Sedan wrote on 2023-10-04, 16:32:

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 […]
Show full quote

Maelgrum wrote on 2023-10-04, 16:29:

(discrete) V4.16 looks like it has some valid data in 0x1800-0x1FFF area, but it is has not.
Data in 0x18XX is the same as in 0x19XX and so on. it is just copy of valid ROM from lower region - some address decoding artefact.
So it is 6k ROM.

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

maxtherabbit wrote on 2023-10-04, 16:08:

Run DOTT again with music disabled please

Heres a direct audio output.

Thanks. I can't heat the clicks in either sample so either it was fixed in one of the 4.13 patches or (more likely) my car audio just isn't conveying it.

Which 4.13 patch version was this recorded on?

I dumped CT3670 (SB32 that is really AWE64) and CT4390 (AWE64 Gold).

Both are the same: CRC32 (6k): 986E5CB9 (known)

maxtherabbit wrote on 2023-10-04, 16:53:

Thanks. I can't heat the clicks in either sample so either it was fixed in one of the 4.13 patches or (more likely) my car audio just isn't conveying it.

Which 4.13 patch version was this recorded on?

Possibly.
The one which has the hanging note bug fixed, think it was named patch3 initially.

Well I've tested patch 3 before myself and confirmed it definitely still clicks

Cleaned up some of my stuff and added them all together.
This should be all the known firmware versions for now.
(Earlier patches before the 4.13 bugfix not included)

For completion's sake, I have now uploaded the CT4520 firmware. Dumped with the latest version of SB16DUMP even though the CRC is known.

S95Sedan wrote on 2023-10-04, 17:18:

This should be all the known firmware versions for now.

you're missing one - the 8K version of V4.16 dumped from "CT4520" CRC32: B15514EF - it's different than any other V4.16 dumped so far (from CT4180, CT3670 and CT4390). [EDIT] see above - it seems we were writing at the same time with @Gmlb256

also, IMHO name like "ct1741_v416" is not appropriate, because there is no CT1741 chip on any of those V4.16 cards.

mattw wrote on 2023-10-04, 17:23:

S95Sedan wrote on 2023-10-04, 17:18:

This should be all the known firmware versions for now.

you're missing one - the 8K version of V4.16 dumped from "CT4520" CRC32: B15514EF - it's different than any other V4.16 dumped so far (from CT4180, CT3670 and CT4390).

This 8k dumps is standard 6k integrated with upper 2k mirrored from lower ROM))
So any bytes over 6k are artifacts of decoding logic, be it mirrorred image, or fixed padding.

mattw wrote on 2023-10-04, 17:23:

S95Sedan wrote on 2023-10-04, 17:18:

This should be all the known firmware versions for now.

you're missing one - the 8K version of V4.16 dumped from "CT4520" CRC32: B15514EF - it's different than any other V4.16 dumped so far (from CT4180, CT3670 and CT4390). [EDIT] see above - it seems we were writing at the same time with @Gmlb256

also, IMHO name like "ct1741_v416" is not appropriate, because there is no CT1741 chip on any of those V4.16 cards.

Should be fixed now, also had 2 mixed up from what it looked like.
8903 is the chip i believe?

S95Sedan wrote on 2023-10-04, 17:35:

8903 is the chip i believe?

the chip is different on almost every card, as it's no longer separate (discrete) 8052 MCU. so, for example, on my CT4180 card the chip is CT2511 (v416-6k_986e5cb9), on CT3670 it's CT8903 (v416-6k_986e5cb9) and on CT4520 it's CT8920 (v416-8k_b15514ef).

Maelgrum wrote on 2023-10-04, 17:31:

This 8k dumps is standard 6k integrated with upper 2k mirrored from lower ROM))
So any bytes over 6k are artifacts of decoding logic, be it mirrorred image, or fixed padding.

as usual, when I say "different" I mean as byte-sequence, not as functionality. so, yeah, technically it is the same.

mattw wrote on 2023-10-04, 17:49:

the chip is different on almost every card, as it's no longer separate (discrete) 8052 MCU. so, for example, on my CT4180 card the chip is CT2511 (v416-6k_986e5cb9), on CT3670 it's CT8903 (v416-6k_986e5cb9) and on CT4520 it's CT8920 (v416-8k_b15514ef).
as usual, when I say "different" I mean as byte-sequence, not as functionality. so, yeah, technically it is the same.

Yeah, removed the chip indicators as its not really relevant.

mattw wrote on 2023-10-04, 17:49:

the chip is different on almost every card, as it's no longer separate (discrete) 8052 MCU. so, for example, on my CT4180 card t […]
Show full quote

S95Sedan wrote on 2023-10-04, 17:35:

8903 is the chip i believe?

the chip is different on almost every card, as it's no longer separate (discrete) 8052 MCU. so, for example, on my CT4180 card the chip is CT2511 (v416-6k_986e5cb9), on CT3670 it's CT8903 (v416-6k_986e5cb9) and on CT4520 it's CT8920 (v416-8k_b15514ef).

Maelgrum wrote on 2023-10-04, 17:31:

This 8k dumps is standard 6k integrated with upper 2k mirrored from lower ROM))
So any bytes over 6k are artifacts of decoding logic, be it mirrorred image, or fixed padding.

as usual, when I say "different" I mean as byte-sequence, not as functionality. so, yeah, technically it is the same.

Can we view 4.16 as integrated 6k ROM with different types of padding - fixed or mirrored?
What do you think?

Maelgrum wrote on 2023-10-04, 18:09:

Can we view 4.16 as integrated 6k ROM with different types of padding - fixed or mirrored?
What do you think?

I think so, based on your analysis that those 2K in CT4520 card dump are unused garbage data result from "some address decoding artifact" ('mirrored' padding), because all other V4.16 dumps so far (CT4180, CT3670 and CT4390) even use "FC" for those 2K as padding, i.e. the same 'fixed' padding as one of the 2 integrated versions of V4.13 (which differ only in padding "FF" vs "FC").

mattw wrote on 2023-10-04, 18:14:

I think so, based on your analysis that those 2K in CT4520 card dump are unused garbage data result from "some address decoding artifact" ('mirrored' padding), because all other V4.16 dumps so far (CT4180, CT3670 and CT4390) even use "FC" for those 2K as padding, i.e. the same 'fixed' padding as one of the 2 integrated versions of V4.13 (which differ only in padding "FF" vs "FC").

Every firmware seems to end at the same sequence.

1D9 E2 E9 F0 F5 F9 FC FE FF FE

All fitting within 6k where 4.13 uses the maximum.

14.04 = 1577
24.05 = 1635
34.11 = 17E2
44.13 = 1800
54.16 = 17E2

Well, it appears the DMA cracking is due to hardware flaw, not to firmware problem. There were many SB cards which PCBs were patched with wires and SMD capacitors, I wonder if these were not fighting the cracking problem. On the other hand 4.16 can be analyzed for its interrupt handlers that were blamed in previous versions to be buggy and causing hanging notes bugs.

sbcrack stage 2 for 4.12