stamasd wrote on 2016-08-28, 21:23:Hm interesting. I was browsing stuff today and it looks like someone has decapped a DSP v4.05 already and there are high-resolut […]
Show full quote
Hm interesting. I was browsing stuff today and it looks like someone has decapped a DSP v4.05 already and there are high-resolution pictures of it available. It uses mask ROM so theoretically you can extract the microcode just by visually decoding the bit pattern from the file.
http://siliconpr0n.org/archive/doku.php?id=na … ive_tech:ct1741
http://siliconpr0n.org/map/creative_tech/ct17 … 741_rom_20x.jpg
Also I found a script to automate the process a bit
http://adamsblog.aperturelabs.com/2013/01/fun … asked-roms.html
https://github.com/ApertureLabsLtd/rompar
I may give it a go... though the high-rez image of the ROM array seems to be a bit truncated towards the left (or bottom, as it appears it's rotated 90 degrees clockwise) so I may not get a full readout.
(edit) scratch this, it's more than a bit truncated, it's missing about half of the ROM area. No go.
There is a lower resolution picture of the whole chip but it's too blurry to read the bits.
Has anyone tried extracting data from that image?
I strongly suspect the full ROM is a 16K rom and its truncated because the other half is empty (The 80C54 is a 16K rom variant of the 80C52).
Estimating the bit count the high-rez image seems to have 24 * 24 * 2 * 8 = 9216 bytes of content, which is exactly 9KB. This would account for the expected 8KB of ROM plus 1KB of manufacturing/testmode rom (The Snark Barker rom extraction video mentions a 512 byte mystery test mode rom area for the SB2.0 rom, which is also just 4KB, so both would be doubled here).
AFAICS the main issues are
1) image quality for rompar:
- uneven lighting and some very blurry areas where the stitching didn't work well? (lighting can probably be fixed in gimp/photoshop)
- rompar seems to need very straight lines, there seems to be some warping in the image where the rompar grid then doesn't match well anymore (could maybe just cut it up into sections and rompar those individually)
2) mystery rom layout. 24 x 24, two halves? I'd have expected power-of two row and column counts, with 24 x 24 probably some slicing and dicing is going on...
See also the attached annotated image, I think its easy to see the row/column select lines (annotated red/blue) and the data path for reading a byte, which all go onto a single bus (also nicely visible in the lowres full-chip image, which has 8 data lines coming out of the rom in that area). I think the bit order is flipped in alternating slices.
There's also a common ababbaba pattern for the row select.
Lets call these two mirrored 8x8 bit blocks. (4 column and 2 row selects per block, 8 bit read at a time). Overall I see 24x24 of these in the upper half and another 24x24 in the lower half, thus the 9216 bytes mentioned above.
Also, going to the opposite end of the rom image, there are 4x2 of the 8x8 blocks that are mostly all 0xff or 0x00. These can give a clue about the block read order I think, I suspect these are the end of either the normal rom or the manufacturing rom (which would be mostly 0xff or 0x00 followed by some final data bytes). These 4x2 blocks are interspersed with 4 of the in the top area and another 4 in the bottom area.
