xxx51 is an 8051 chip, used for dsp 2.xx and 3.xx (smaller in size, 4kb instead of 8kb)
xxx52 is 8052, which is what the 4.xx version uses.
georgel wrote on 2023-09-26, 21:47:Would you please tell if the DOS MIDI emulation is working normally with AWEUTIL in DOS with the modded FW?
This or anything specific?
S95Sedan wrote on 2023-09-26, 22:31:xxx51 is an 8051 chip, used for dsp 2.xx and 3.xx (smaller in size, 4kb instead of 8kb) xxx52 is 8052, which is what the 4.xx ve […]
xxx51 is an 8051 chip, used for dsp 2.xx and 3.xx (smaller in size, 4kb instead of 8kb)
xxx52 is 8052, which is what the 4.xx version uses.georgel wrote on 2023-09-26, 21:47:Would you please tell if the DOS MIDI emulation is working normally with AWEUTIL in DOS with the modded FW?
This or anything specific?
Thank you! This. Does it indeed play MIDI ?
Maelgrum wrote on 2023-09-26, 22:22:'51 chips with 4k rom cannot work with 4.xx fw.
You need '52.
I suspect what even modern variants of '52 can be used.
S95Sedan wrote on 2023-09-26, 22:31:xxx51 is an 8051 chip, used for dsp 2.xx and 3.xx (smaller in size, 4kb instead of 8kb)
xxx52 is 8052, which is what the 4.xx version uses.
Thank you both for giving those clarifications. I guess the safest is then :
maxtherabbit wrote on 2023-09-26, 22:29:AT89C52 is known to work, I'd recommend sticking with that
[EDIT] not that I recommend it as it's totally untested by anyone here, but probably what is on the attached picture is the Signetics 8052 part.
[EDIT2] "P87C52" with Signetics-logo is more rare and more expensive, but "Philips P87C52", i.e. after their acquisition by Philips, is very cheap and well-available in Europe. So, if it's compatible - then it would be very viable option.
georgel wrote on 2023-09-26, 22:34:Thank you! This, does it indeed play MIDI ?
Yeah, it does give an NMI error but i think that might be due to my mainboard. Which i can ignore with F1 and continue.
S95Sedan wrote on 2023-09-26, 22:47:it does give an NMI error
could it be some different pin-assignment of the Micro-controller between different card models - I mean for example "V4.13" is it exactly the same code on every board with such DSP version or could it be they are slightly different in terms of Micro-controller pin-assignments according to the PCB layout?
mattw wrote on 2023-09-26, 23:50:S95Sedan wrote on 2023-09-26, 22:47:it does give an NMI error
could it be some different pin-assignment of the Micro-controller between different card models - I mean for example "V4.13" is it exactly the same code on every board with such DSP version or could it be they are slightly different in terms of Micro-controller pin-assignments according to the PCB layout?
We have no dumps to compare ((
My current view on this subject - all V4. 13 are same. But it needs to be proven.
One way to prove - is to write software dumper (if it's possible), and then compare dumps from different cards.
Maelgrum wrote on 2023-09-27, 00:32:it needs to be proven.
One way to prove - is to write software dumper (if it's possible), and then compare dumps from different cards.
I presume hardware dump is very complicated to be made - I don't know how those dumps here were made, but in the past I found picture(s) of the setup used by @TubeTimeUS to dump CT1351 V202 , wrote about it here:
Re: Sound Bank rom dumps - how are made?
and it was literally insane as complexity.
So, let's hope software approach is possible.
I don't know how relevant it is, but I remember - very vaguely now, because it was over 10 years ago that I read a book (don't even remember the name of it) about 8051 assembler in which with some magic self-modifying code it was possible to dump the whole firmware, but you still need an entry point - maybe it's some famous attack on 8051, I don't know. In any way back then I tried it and it was working and it was working even on very modern device, because I tried it on PCI-Express controller with build-in 8051 controller (actually it was PCIe sound card with 8051 controller inside the PCIe chip for handling the HDA commands and I was able to dump the 8051 firmware with that attack in software). So, if you think it's relevant and you don't know the attack - let me know, I will search old HDDs, etc if I can find the book and the attack.
S95Sedan wrote on 2023-09-26, 22:47:georgel wrote on 2023-09-26, 22:34:Thank you! This, does it indeed play MIDI ?
Yeah, it does give an NMI error but i think that might be due to my mainboard. Which i can ignore with F1 and continue.
I recall seeing NMI error on a working, vanilla AWE64 Gold as well. I wonder if Creative intentionally triggered such an error to verify if NMI is working as intended. I ignored and MIDI worked.
Maelgrum wrote on 2023-09-26, 22:22:'51 chips with 4k rom cannot work with 4.xx fw.
You need '52.
I suspect what even modern variants of '52 can be used.
I'm not sure but maybe any 8051 MCU with at least 8K flash, standard timings (12T) and a matching pinout should do. I'm currently looking at a few ISP-capable MCUs (PLCC44-packaged) that I got a long time ago...
Some more modern 8051 MCUs operate at enhanced timings like 1T/2T. While not a problem for internal computing processes, it can be a problem with bit-banged I/O (with external devices) where strict timings (delays) are required. Not sure how many I/O interactions does the Creative DSP firmware have and how the necessary delays were implemented...
LSS10999 wrote on 2023-09-27, 00:59:I'm not sure but maybe any 8051 MCU with at least 8K flash, standard timings (12T) and a matching pinout should do.
4.xx code uses 8052 features - extra 128 bytes of ram. So MCU needs to be '52 compatible.
And 12T cycle is preferable, although may be 6T can work - it depends on timing constraints of bus control chip.
ISP is sweet, but needs fw and software support.
May be it's easier to just externally program and swap socketed MCU?))
LSS10999 wrote on 2023-09-27, 00:59:Some more modern 8051 MCUs operate at enhanced timings like 1T/2T. While not a problem for internal computing processes, it can be a problem with bit-banged I/O (with external devices) where strict timings (delays) are required. Not sure how many I/O interactions does the Creative DSP firmware have and how the necessary delays were implemented...
Some embedded delays via NOPs are present in 4.xx.
Maelgrum wrote on 2023-09-27, 01:48:LSS10999 wrote on 2023-09-27, 00:59:Some more modern 8051 MCUs operate at enhanced timings like 1T/2T. While not a problem for internal computing processes, it can be a problem with bit-banged I/O (with external devices) where strict timings (delays) are required. Not sure how many I/O interactions does the Creative DSP firmware have and how the necessary delays were implemented...
Some embedded delays via NOPs are present in 4.xx.
Yeah. Raw NOP delays can be problematic if using a MCU with different timing than the firmware was coded against, so it's best to stick with 12T MCUs for now.
LSS10999 wrote on 2023-09-27, 02:48:Yeah. Raw NOP delays can be problematic if using a MCU with different timing than the firmware was coded against, so it's best to stick with 12T MCUs for now.
I can not understand a reasons behind this delays,
It's only inserted then read/write done to sb data port.
Looks like 'data ready' bit in DSP is set by front edge of ISA WR signal, instead of back edge.
Some error in hardware design of early SB16, what propagated in fw code? Don't know))
S95Sedan wrote on 2023-09-26, 22:47:georgel wrote on 2023-09-26, 22:34:Thank you! This, does it indeed play MIDI ?
Yeah, it does give an NMI error but i think that might be due to my mainboard. Which i can ignore with F1 and continue.
I guess the same should happen with the original chip...
Maelgrum wrote on 2023-09-27, 03:16:I can not understand a reasons behind this delays, It's only inserted then read/write done to sb data port. Looks like 'data re […]
I can not understand a reasons behind this delays,
It's only inserted then read/write done to sb data port.
Looks like 'data ready' bit in DSP is set by front edge of ISA WR signal, instead of back edge.
Some error in hardware design of early SB16, what propagated in fw code? Don't know))
I haven't actually seen the DSP code so I'm not sure... Usually there's no need to perform delays if everything is performed inside the MCU (calculations and such).
Delay is mainly used when the MCU (DSP) needs to interact with external devices connected using certain buses which specify the necessary timings on the wires for each step needed in a successful interaction.
I think NOP is the smallest unit a processor can perform delays, and one would usually need to write and calibrate a routine for a near accurate 1ms delay and start from there. For that, the input clock as well as the cycles per instruction (such as 12T) needs to be taken into consideration.
mattw wrote on 2023-09-27, 00:57:I don't know how relevant it is, but I remember - very vaguely now, because it was over 10 years ago that I read a book (don't even remember the name of it) about 8051 assembler in which with some magic self-modifying code it was possible to dump the whole firmware, but you still need an entry point - maybe it's some famous attack on 8051, I don't know. In any way back then I tried it and it was working and it was working even on very modern device, because I tried it on PCI-Express controller with build-in 8051 controller (actually it was PCIe sound card with 8051 controller inside the PCIe chip for handling the HDA commands and I was able to dump the 8051 firmware with that attack in software). So, if you think it's relevant and you don't know the attack - let me know, I will search old HDDs, etc if I can find the book and the attack.
I have in mind following methods of reading ROM:
1. Read via ROM programmer (simple way) (Can be disabled by lock bit)
2. Fake execution from external memory via controlling EA, adress, data e.t.c lines by external didicated hardware, to give to MCU prepared instruction sequence to read ROM and output it somewhere. (Can be disabled by lock bit)
3. If execution from external memory is enabled, but reading internal ROM by MOVC from extrnal memory is disabled by lock bit, attack can be made by preparing DPTR and calling to some code in internal memory to read code memory and output it somewhere.
4. If some or all lock bits are set, attack can be made to change lock bit settings via clock/power glitch.
And sometimes, lock bits are not set at all, allowing all reading methods.
If you have information about some other method, it is very interesting.
But i look forward to software method, it is only method possible to read 4.16 (except for decapping and chip analyzing)
mattw wrote on 2023-09-26, 23:50:could it be some different pin-assignment of the Micro-controller between different card models - I mean for example "V4.13" is it exactly the same code on every board with such DSP version or could it be they are slightly different in terms of Micro-controller pin-assignments according to the PCB layout?
Not gonna be the case.
I'm fairly certain they used off-the-shelf 8052 chips before they had them custom made, one of the early CT1730 cards i own even has a sanded down dsp top with a sticker put on.
(Notice the top left of the chip, which has a lower corner. Custom made chips have texture to it aswell.)
Interesting facts:
In SB16, samplerate is set by one byte (which stored at memory location 0x37 and x-bus register 0x09). Lets call is SR.
Output frequency will be SR * 46615120 / (256 * 1024).
Only 3 frequency can be exactly set with SR - it is 44100, 22050 and 11025 (with SR equal to 248, 124 and 62).
Another set of usable frequencies is 8000, 16000, 24000, 32000, 40000. Not exact, but error is low.
For all other frequencies error is high.
By using of command 0x40 you cannot set 44100, but can set 22050 and 11025.
Max samplerate (for SR = 0xFF) is 45345
Maelgrum wrote on 2023-09-27, 18:08:Interesting facts:
I had some time to analyze DSP 4.13 function FA that writes a byte to any address in MCS51 RAM. I must disappoint you that after the actual write at program address 0B44 MOV @R0,A this function returns to the main loop around program address 053D only via jumps and not using any RET instruction therefore it is not possible to divert program execution by modifying the stack.
georgel wrote on 2023-09-29, 19:58:Maelgrum wrote on 2023-09-27, 18:08:Interesting facts:
I had some time to reverse DSP 4.13 function FA that writes a byte to any address in MCS51 RAM. I must disappoint you that after the actual write at program address 0B44 MOV @R0,A this function returns to the main loop around program address 053D only via jumps and not using any RET instruction therefore it is not possible to divert program execution by modifying the stack.
Look at my post describing technique.
Attack path is via MPU Uart receiving routine.
It has memory write to arbitrary location and RET.
Maelgrum wrote on 2023-09-29, 20:14:Look at my post describing technique. AAttack path is via MPU Uart receiving routine. It has memory write to arbitrary locatio […]
georgel wrote on 2023-09-29, 19:58:Maelgrum wrote on 2023-09-27, 18:08:Interesting facts:
I had some time to reverse DSP 4.13 function FA that writes a byte to any address in MCS51 RAM. I must disappoint you that after the actual write at program address 0B44 MOV @R0,A this function returns to the main loop around program address 053D only via jumps and not using any RET instruction therefore it is not possible to divert program execution by modifying the stack.
Look at my post describing technique.
AAttack path is via MPU Uart receiving routine.
It has memory write to arbitrary location and RET.
Which SB function number is that? Why would it need to write to any location?