Back again! I tested it yesterday, and right way i got this error:
(This was before @DerBaum provide the CT2959)
"readport 0x273
writing resource data for CT2959
reading resource data from card
resource readback is not the same - operation aborted.
"
I used the "Tronix's flash utility".
And about some minutes agora i perform again the same experiment with "CT2950.BIN", provided by DerBaum. And again, I got the same error:
"readport 0x273
writing resource data for CT2959
reading resource data from card
resource readback is not the same - operation aborted.
"
What the heck is going 😅???? Ok, there's something really weird going on with these cards, it will need a deeper analysis in both senses(hardware/software), this weird situation caught my attention a lot, really intriguing...Let me start a debate:
1 - First of all, I still didn't change my mind, I'm almost convinced that it's not a physical problem in the EEPROM, if not damaged this chip and others models has data retention of about 100 years. Generally it has a peak of 40 years, with 10 years guaranteed by the some manufacturers(If no incident happens that affect physical chip integrity this will easily overcome 30 years).
2 - I already was expecting the error come before flashing the EEPROM with the "CT2959.BIN", but of course, I had some hope that it could work. The reason that I thought it was: I said myself - This CT2959 must be a VIBRA card model disguised as a CT29XX non Vibra and might had fooled @Thermalwrong. And of course I was wrong😆, after I got the error I search for this card information, and I saw that it's almost a copy of the CT2950, it even has a mark label in the board "CT 2950", but the paper thicket was showing as "CT 2959"....Then I said again - There might be something in this card that make it different from the "CT2950", I don't know what is it but it has to be something different, maybe the " CT1749 (CT1749-DCQ) " with a different revision...But again, I got another punch when the DerBaum posted the file for the CT2950.BIN, I was also expecting for this, I didn't want ask for it again(the exactly dump model) because it would me make look like 'a newbie bothering people'. Then I checked it, and error again. Someone had to see my very disappointed face when it didn't work. After all this, I was able to raise a lot of speculation about what could be happening, I collected the maximum information of people that was facing similar problem with these cards, and this last "DerBaum's post" was very important to try to fit the pieces of this jigsaw. Ok, I'm not an expert in this topic, far from, I just want to here's my humble opinion of what could be happening with some card:
A) It's not an EEPROM fault as I mentioned before, instead it might be a problem related with the "CT1749-DCQ" chip. This chip is very important as this chip is the "Plug-and-Play ISA Bus interface chip", and I see that this chip is embarked in many other models like "CT3990". If it's a total failure in this chip, than it wouldn't even be recognized when plugged in the ISA slot, you wouldn't even be able to make a dump of your EEPROM with this chip bad. If it's a partial failure, like any bad behavior in any PIN, then this could be reason for the problem, the problem is that I couldn't find this chip datasheet to verify what PINs has the protocols trigged directly with the EEPROM.
B) An incompatibility during the process of flash the eeprom. The "Tronix's modified utility" is really great, I wouldn't even dare to disassembly such tool, but I was thinking to give a look on it and see if I could find any issue that could lead to error in some models(although I'm not very good at it). I thought like this because of number of people that could fix their cards with this tool with most of models are CT40XX and CT30XX. I just needed to know at least one successful case of someone that could fix it with a CT29XX model, and I saw that Tronix could verify this with a "CT2940", and this is very good signal that the tool works for bunch of models.
In the first post i saw here's, by the "Pabloz(R.I.P. SoundBlaster AWE32)": R.I.P. SoundBlaster AWE32. I perceived that he flashed a CT3670 EEPROM with a CT4502 DUMP:
"
C4502_C1.exe
readport 0x273
writing resource data for ct4502
reading resource data from card
resource readback is not the same operation aborted.
"
I want to believe that CT3670 and CT4502 are quite different, and this could be a reason for a fail in the process. Or I could be wrong and these two model have something in common..
And this brings me back again to the "CT2959" case, that Thermalwrong had indicated, this card is really identical to "CT2950", I search as many information as I could, both cards are related each other, same components position, same size...Only a ticket label informs that it's a 2959: "https://aukro.cz/retro-hw-zvukova-karta-creat … -isa-6994355833". The point here's that, even a DUMP file from "CT2959" could not be a good idea to flash in a "CT2950", on my case it failed. But could it fit nicely? Yes(more nice than flashing a CT3670 with a CT4502 dump), as they are very identical and apparently has same characteristics, but there might be something that make these two models different, and this small detail between a CT2950 and a CT2959 can generate an compatibility issue, this is really weird but it's a possibility.
C) But I didn't have check with the exactly model dump provided by "DerBaum"? Yes, and i'm grateful for provided the exactly dump model. However, as pointed DerBaum, you are not sure if this dump is ok is it that? But let's suppose it isn't, let's suppose the dump file is good...What could be the issue in addition to a dead EEPROM? The file dump can broken or for some motive there's an incompatibility, it's known that the CT2950 has also a version with "OPL3", when this yahama chip comes, many others are remove, this can bring incompatibility between a CQM and OPL3 during flashing process. Another point is that: Yes, I'm able to write information to the eeprom, and this can be important for two reason: 1 - This helps definitively to know if the chip is really bad or don't. How? Just wire some data bytes little by little, for example, a little snippet I took from the "CT2940", I don't encourage you do this with your card, even that it's not working, cause your card can still retain the firmware good and might be other problem beside this one(Unless you get exactly same error as I got), and perceived that I'm using only a piece information from another DUMP model. So I tried: "00000: 8c0e 2800 77d8 1006 0ab1 1010 1182 4300 6572 7461 7669 2065 4253 3631 5020 506e...(Don't make it too long, it is just to set some information)", and rewriting this content the EEPROM is able to accept it. Now, as I don't have another SB card to test this dangerous experiment, I can only speculate: "If that data I used as example has to be write in the EEPROM, that is, if you make a dump again and verify its content has '6572 7461 7669 2065 4253 3631 5020 506e' ", then the EEPROM is okay, otherwise if got only "FF...", even after a successful write, the EEPROM has really a fault and must be changed. Now in opposite: if "No, the EEPROM can't hold this information, it needs more additional information to have information retained", then when open a dump you will see "FF" and still the EEPROM can be working nicely. Yes, this is quite confuse I confess, but resuming, what I want to mean is that, the EEPROM may work with a retained piece information or not, I just don't know if it has to save or not, If you write any information to it, and the information is kept, and another person also write any piece information to is card , and did not keep, instead you got a "FF" value, then the person that the EEPROM couldn't retain the data will need to changed the EEPROM, there's not thing to do. On my case, as I said, I wrote some information in it and it could be write successful, I made a new DUMP, and no information was retained. Also, I don't know if it's the fact of using a tool and not an EEPROM programmer, but I believe it would give same result. And this can another punch, but this I won't take....
D)Just reinforcing a thing what was said in topic "C", if the DerBuam "CT2950.BIN" is not good, then of course the error will insist. But for what I have seen the file has a valid content. So, I believe this error is caused but a coincidence too 🤣, the file has any bad section that is preventing from make the right flash operation.
Ok now, what I will propose? As I said, I'm not an expert, all I did was just rise up some particular points, and it even came to my head a problem related with conflicts, but I could discard this one, as I had mentioned in the first poster, that my ISA Wiscom modem could be recognized in the system. Now my propose is to investigate what is going, at least to have a concrete idea of this real problem. I'd like to start it today, but unfortunately it's final semester in the faculty, and for about 2 weeks I will have lot exams. So, I'd like to let some more things that can sound meddlesome for a newbie, but I'd like to collect some information to make a deeper analyses after exam period:
A) If someone has this card or any other model, and the card has the same problem and also you know what you are doing, you can write some piece of data to your card by using "Tronix" tools, only a little bytes(use your dump card model if you don't feel comfortable adding random or any other piece of information). This will help you understand the EEPROM behavior and may be a powerful diagnose for EEPROM, once we know it "has to retain any kind of data", if yours don't, then change EEPROM . PLEASE, FOR GOD'S SAKE, DON'T DO THIS WITH YOUR WORKING CARD UNDER NO CIRCUMSTANCE!!! YOU WILL CERTAINLY LOSE IT IF DO THAT! And remember, if the data is retained my card EEPROM is bad and I got a final punch, if your card didn't maintain it, like an "FF", then the tool or EEPROM needs some more additional information to make a data retention.
B) OR EVEN Better, if someone know the answer for the A) then better, we don't need such procedure, I really don't know now the answer for this question, also If have another sound blaster card i would try this experiment of course, and this would avoid external experiment. So if someone has the answer: "Yes, the EEPROM has to maintain any data after you write it" or "NO, the EEPROM won't maintain any data until, it write with necessary and correct information."
C) Answering the point where DerBaum did about Creative and Yahama provide the documents...Really that make me laugh, "they told me that they only keep datasheets and stuff for x years and then get rid of everything", these guys should be more humble in answer, what is the problem in say that can't provide such documents, I'm sure they still have these file, sorry but I don't believe what they say😂. While Creative, I had contacted them yesterday, and they answer with non sense question, Like: "We don't have support for new systems SR.", when I just ask if it would be possible to provide the "CT2950.BIN" file...As you said the DerBaum, they will ignore you with nonsense answers. But it's okay, they have their motives don't give such documents. But I'm sure, many people might have these archive, maybe in repair forum stuff, or even, illegal market...
If someone here has any datasheet for any SB creative CHIPSET, like the "CT1749". The "CT1749" would be great, as this one is shipped in many SB card models.
D) Could some here identify the serial ID of the content and many other information, by the the content I took from the "CT2959.BIN". I use the "hexdump" in Linux:
"0000000 8c0e 2800 77d8 1006 0ab1 1010 1182 4300
0000010 6572 7461 7669 2065 4253 3631 5020 506e
0000020 0e15 008c 0031 0582 4100 6475 6f69 0031
0000030 2022 2a00 0802 202a 4712 2001 2002 0102
0000040 4710 3001 3003 0103 4702 8801 8803 0103
0000050 3104 2201 04a0 0b2a 2a08 12e0 0147 0220
0000060 0280 1020 0147 0300 0330 0230 0147 0388
0000070 0388 0401 0131 a022 2a04 080b e02a 4712
0000080 2001 8002 2002 4710 0001 3003 3003 3102
0000090 2202 04a0 0b2a 2a08 12e0 0147 0220 0280
00000a0 1020 0231 a022 2a04 080b 0147 0220 0280
00000b0 1020 0147 0300 0330 0230 0147 0388 0388
00000c0 0401 0231 a022 2a04 080b 0147 0220 0280
00000d0 1020 0147 0300 0330 0230 0231 a022 2a0c
00000e0 080b 0147 0220 0280 1020 1538 8c0e 1120
00000f0 1c00 d041 0006 0382 4900 4544 0031 0022
0000100 4704 6801 6801 0101 4708 6e01 6e03 0103
0000110 3102 2201 0800 0147 01e8 01e8 0801 0147
0000120 03ee 03ee 0201 0131 0022 479c 0001 f801
0000130 0801 4708 0001 fe03 0203 3102 2202 8000
0000140 0147 0170 0170 0801 0147 0376 0376 0101
0000150 1538 d041 ffff 8200 0008 6552 6573 7672
0000160 6465 0147 0100 03f8 0108 0e15 708c 0001
0000170 411c b0d0 822f 0004 6147 656d 0147 0200
0000180 0200 0801 b579 ffff ffff ffff ffff ffff
0000190 ffff ffff ffff ffff ffff ffff ffff ffff
*
0000200
"
I'd to know where is the (VENDOR ID), and what is the length of this string, as "ERROR BAD SERIAL ID CHECKSUM ( VENDOR ID ffffffff ) EXPECTED = 35 ACTUAL = ff".
E) Does any know use JTAG approach to analyze contents in memory? I never use such an approach, but I know is a powerful procedure.
F) FINALLY, This one is the craziest request, and of course you will do this if you have some experience in this kind of task. ONLY IF YOUR CARD IS NOT WORKING: AND AGAIN, DON'T THIS IN A WORKING CARD, YOU WILL CAUSE A SHORT CIRCUIT AND KILL YOUR EEPROM!
I want to compare the values in PIN 1 and PIN 3 with my card, if you have a multimeter, just place the ground in PIN5, and with red prober you measure the value in PIN1 and PIN3, PIN1 is "SC" and PIN3 is "DI", depending of your models SB, PIN's location can vary, you consult the datasheet for your EEPROM's model.
So, that's all I have to say for the moment, and many thanks again DerBaum and Thermalwrong for answering and provide files !!!
