DSP-1 emulation
Moderator: ZSNES Mods
DSP-1 emulation
What is the current status?
Last thing I heard was someone trying to use a microscope to read the actual program rom from the DSP1...
Did anyone scuessfully read the DSP1 program rom in any usable way?
What is the dsp1data.bin file I see floating around (e.g. in the MAME nss.zip file)?
Is what is available in the public official builds of zsnes/snes9x the latest on DSP1? Would CVS or unofficial builds of either emulator have more recent code?
Last thing I heard was someone trying to use a microscope to read the actual program rom from the DSP1...
Did anyone scuessfully read the DSP1 program rom in any usable way?
What is the dsp1data.bin file I see floating around (e.g. in the MAME nss.zip file)?
Is what is available in the public official builds of zsnes/snes9x the latest on DSP1? Would CVS or unofficial builds of either emulator have more recent code?
basically an australian guy named Overload had online a research page that listed the functions. He and a few others tried to simulate the output, treating the DSP-1, 1A, 1B, as a black box.
John Weidman, Neviksti, Overload are listed as the source code contributors. A lot of their public development talk was on the snes9x message board.
Overload's page disappears and reappears from the Web, I wish I had saved the damn thing when it appeared again like two weeks ago only to disappear.
it is archived (long uri, sorry), but no pictures.
http://web.archive.org/web/200306230426 ... /dsp1.html
Basically the rom you speak of, if it is the DSP-1 ROM image and not some other "dsp", is the dumped memory contents of the DATA rom. There was a way to read out the data rom, but to this day there is no way to read out the program.
These guys largely succeeded in simulating what the fixed point calculations did, and the DSP-1 (and 1A and 1B) is basically done. Not perfect, but damn near perfect. (I believe Raster Data Calculation still has issues but is only noticable with the hanglider).
What you see in CVS is probably their latest and greatest and has been so for a year, I don't mean to speak for these guys but I think each of them have all moved on to something else.
John Weidman, Neviksti, Overload are listed as the source code contributors. A lot of their public development talk was on the snes9x message board.
Overload's page disappears and reappears from the Web, I wish I had saved the damn thing when it appeared again like two weeks ago only to disappear.
it is archived (long uri, sorry), but no pictures.
http://web.archive.org/web/200306230426 ... /dsp1.html
Basically the rom you speak of, if it is the DSP-1 ROM image and not some other "dsp", is the dumped memory contents of the DATA rom. There was a way to read out the data rom, but to this day there is no way to read out the program.
These guys largely succeeded in simulating what the fixed point calculations did, and the DSP-1 (and 1A and 1B) is basically done. Not perfect, but damn near perfect. (I believe Raster Data Calculation still has issues but is only noticable with the hanglider).
What you see in CVS is probably their latest and greatest and has been so for a year, I don't mean to speak for these guys but I think each of them have all moved on to something else.
There is this thread on fruity site (CR):
http://www.fruity site (CR).com/viewtopic.php?t=3848&start=80
About people reading the contents of various chips containing embedded roms & such, one of which was the DSP-1 chip I believe.
How far they got with it I dont know (no idea if they are even working on it anymore).
As for DSP1 emulation, the most current official releases of both snes9x and zsnes have a major graphical glitch in Suzuka 8 Hours. As does the latest WIP version from here http://snes9x.ipherswipsite.com/.
Is there a more recent version (of either emulator but preferably zsnes) or code in a CVS server somewhere that fixes this glitch? (if necessary I can take a screenshot of the glitch)
http://www.fruity site (CR).com/viewtopic.php?t=3848&start=80
About people reading the contents of various chips containing embedded roms & such, one of which was the DSP-1 chip I believe.
How far they got with it I dont know (no idea if they are even working on it anymore).
As for DSP1 emulation, the most current official releases of both snes9x and zsnes have a major graphical glitch in Suzuka 8 Hours. As does the latest WIP version from here http://snes9x.ipherswipsite.com/.
Is there a more recent version (of either emulator but preferably zsnes) or code in a CVS server somewhere that fixes this glitch? (if necessary I can take a screenshot of the glitch)
http://users.tpg.com.au/advlink/dsp/whicker wrote:Overload's page disappears and reappears from the Web, I wish I had saved the damn thing when it appeared again like two weeks ago only to disappear.
Raster Data Calculation is complete. Only object projection is incorrect.whicker wrote: These guys largely succeeded in simulating what the fixed point calculations did, and the DSP-1 (and 1A and 1B) is basically done. Not perfect, but damn near perfect. (I believe Raster Data Calculation still has issues but is only noticable with the hanglider).
Exactly, I'm living abroad and i don't have access to any of the equipment used to reverse engineer the hardware. We are all too busy with life to work on the dsp project.whicker wrote:What you see in CVS is probably their latest and greatest and has been so for a year, I don't mean to speak for these guys but I think each of them have all moved on to something else.
Neviksti was unable to read the dsp-1 program rom under a SEM.jonwil wrote:There is this thread on fruity site (CR):
http://www.fruity site (CR).com/viewtopic.php?t=3848&start=80
About people reading the contents of various chips containing embedded roms & such, one of which was the DSP-1 chip I believe.
How far they got with it I dont know (no idea if they are even working on it anymore).
The last version of snes9x should have fixed the glitch with Suzuka 8 Hours. There is a screenshot of what it should look like on my dsp home page. As far as i know zsnes doesn't contain any of the projection updates. That includes parameter and raster commands.jonwil wrote:As for DSP1 emulation, the most current official releases of both snes9x and zsnes have a major graphical glitch in Suzuka 8 Hours. As does the latest WIP version from here http://snes9x.ipherswipsite.com/.
Is there a more recent version (of either emulator but preferably zsnes) or code in a CVS server somewhere that fixes this glitch? (if necessary I can take a screenshot of the glitch)
-
- "Your thread will be crushed."
- Posts: 1236
- Joined: Wed Jul 28, 2004 1:49 am
- Location: Not in Winnipeg
- Contact:
-
- Locksmith of Hyrule
- Posts: 3634
- Joined: Sun Aug 08, 2004 7:49 am
- Location: 255.255.255.255
- Contact:
yeah it just takes you to their forums.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
NSRT here.
-
- "Your thread will be crushed."
- Posts: 1236
- Joined: Wed Jul 28, 2004 1:49 am
- Location: Not in Winnipeg
- Contact:
I'd still like to continue work on the reading the ROMs "visually". Integrated Circuits are really beautiful under the microscope. It doesn't take much time, so it is a fun hobby.
There are several ways to store information in a ROM. Unfortunately, one of the most common methods is the only one I can't figure out how to read yet. There is supposed to be a simple chemical reaction that "stains" the ROM bits so that you can read them. Someone found a paper (pictures and all) that briefly mentioned how to do this for the ROM type we can't figure out. Unfortunately I can't get it to work.
I have however succeeded in staining and reading the ROM from a SNES CIC and a NES CIC. As well as a Gameboy CPU (which didn't require any staining at all).
Anyway, I'm starting to think that paper may just have had a mistake in it. If so, this whole thing could be solved by someone patient enough to google around and find out what procedure / etchant I am supposed to use to read NAND "implantation" ROMs.
This is the paper that started it all:
http://www.usenix.org/publications/libr ... ling_html/
(It claims you need to use a Dash etchant ... which there are many recipes for, and procedures. I've tried many and nothing works yet.)
So, if you can google, and you have patience ... you probably can help.
It's all about guessing the right keywords.
Let me know if you find anything interesting.
There are several ways to store information in a ROM. Unfortunately, one of the most common methods is the only one I can't figure out how to read yet. There is supposed to be a simple chemical reaction that "stains" the ROM bits so that you can read them. Someone found a paper (pictures and all) that briefly mentioned how to do this for the ROM type we can't figure out. Unfortunately I can't get it to work.
I have however succeeded in staining and reading the ROM from a SNES CIC and a NES CIC. As well as a Gameboy CPU (which didn't require any staining at all).
Anyway, I'm starting to think that paper may just have had a mistake in it. If so, this whole thing could be solved by someone patient enough to google around and find out what procedure / etchant I am supposed to use to read NAND "implantation" ROMs.
This is the paper that started it all:
http://www.usenix.org/publications/libr ... ling_html/
(It claims you need to use a Dash etchant ... which there are many recipes for, and procedures. I've tried many and nothing works yet.)
So, if you can google, and you have patience ... you probably can help.
It's all about guessing the right keywords.
Let me know if you find anything interesting.
Have you tried doing this for the N64 PIF boot ROM? It's something that is needed.neviksti wrote:I'd still like to continue work on the reading the ROMs "visually". Integrated Circuits are really beautiful under the microscope. It doesn't take much time, so it is a fun hobby.
There are several ways to store information in a ROM. Unfortunately, one of the most common methods is the only one I can't figure out how to read yet. There is supposed to be a simple chemical reaction that "stains" the ROM bits so that you can read them. Someone found a paper (pictures and all) that briefly mentioned how to do this for the ROM type we can't figure out. Unfortunately I can't get it to work.
I have however succeeded in staining and reading the ROM from a SNES CIC and a NES CIC. As well as a Gameboy CPU (which didn't require any staining at all).
Anyway, I'm starting to think that paper may just have had a mistake in it. If so, this whole thing could be solved by someone patient enough to google around and find out what procedure / etchant I am supposed to use to read NAND "implantation" ROMs.
This is the paper that started it all:
http://www.usenix.org/publications/libr ... ling_html/
(It claims you need to use a Dash etchant ... which there are many recipes for, and procedures. I've tried many and nothing works yet.)
So, if you can google, and you have patience ... you probably can help.
It's all about guessing the right keywords.
Let me know if you find anything interesting.
If I remember right there is a small IC on the N64 motherboard labeled NUS-PIF that has a tiny amount of ROM that configures some registers and maybe some other stuff.neviksti wrote:No, I haven't tried that.Reznor007 wrote:Have you tried doing this for the N64 PIF boot ROM? It's something that is needed.
I don't know anything about the N64 system. But if you tell me what you want and where I can find it, I'll look into it.
Well, if I have to get and destroy an entire N64 console, I'm not really curious enough to pay for that myself. If you come across any N64 emulator/developer hobbyists that are really interested in this, I'd be willing to look into it if they sent me the chip (heck, maybe they have a dead N64 they can pull it from).
Also, while we're on the topic, I'd be interested in comparing the different SNES CIC chips. Does anyone have a broken (or crappy/cheap) PAL game that I could buy off of them? I'd be willing to buy a few.
==============================
And to really get back on topic (for those just arriving):
Please note that someone with patience and googling skills may be able to solve the DSP rom reading problem. It should be possible (we found one paper that even showed pictures of what we want) but we can't get enough specifics and everything has failed for that kind of ROM as to date. Anyone interested in helping?
Also, while we're on the topic, I'd be interested in comparing the different SNES CIC chips. Does anyone have a broken (or crappy/cheap) PAL game that I could buy off of them? I'd be willing to buy a few.
==============================
And to really get back on topic (for those just arriving):
Please note that someone with patience and googling skills may be able to solve the DSP rom reading problem. It should be possible (we found one paper that even showed pictures of what we want) but we can't get enough specifics and everything has failed for that kind of ROM as to date. Anyone interested in helping?
http://www.mameworld.net/vlinde/neviksti wrote:Well, if I have to get and destroy an entire N64 console, I'm not really curious enough to pay for that myself. If you come across any N64 emulator/developer hobbyists that are really interested in this, I'd be willing to look into it if they sent me the chip (heck, maybe they have a dead N64 they can pull it from).
Also, while we're on the topic, I'd be interested in comparing the different SNES CIC chips. Does anyone have a broken (or crappy/cheap) PAL game that I could buy off of them? I'd be willing to buy a few.
==============================
And to really get back on topic (for those just arriving):
Please note that someone with patience and googling skills may be able to solve the DSP rom reading problem. It should be possible (we found one paper that even showed pictures of what we want) but we can't get enough specifics and everything has failed for that kind of ROM as to date. Anyone interested in helping?
I'm sure he'd be interested in having a proper dump of it. He's made a simulated version for MAME, but of course the real thing is needed.
At least with N64 you can find used consoles at Gamestop for $20 US usually

I'm sorry if I'm just blind, but I couldn't find a way to contact him from that site or the ones linked to from it. Am I missing something?Reznor007 wrote:http://www.mameworld.net/vlinde/
I'm sure he'd be interested in having a proper dump of it. He's made a simulated version for MAME, but of course the real thing is needed
Anyway, let me know the best way to get ahold of him, and I'll get in touch to see if I can be of any help.
Hmm...guess he doesn't have an email on the site.
Try here http://www.mameworld.info/ubbthreads/se ... fpart=&vc=
Try here http://www.mameworld.info/ubbthreads/se ... fpart=&vc=
-
- Hazed
- Posts: 76
- Joined: Sat Jan 28, 2006 7:21 am
I guess dopant-selective crystallographic staining technique isn't something that someone makes a web page of (Except maybe a professor as a teaching aid, perhaps searching college sites is a possible answer)
Have you tried obtaining the text book they cited as the source of the staining technique used. Considering that the book cost over a hundred bucks (Like most of my college text books), perhaps you could obtain it through an inter-library loan.
P.S. F. Beck: Integrated Circuit Failure Analysis - A Guide to Preparation Techniques. John Wiley & Sons, 1998.
Have you tried obtaining the text book they cited as the source of the staining technique used. Considering that the book cost over a hundred bucks (Like most of my college text books), perhaps you could obtain it through an inter-library loan.
P.S. F. Beck: Integrated Circuit Failure Analysis - A Guide to Preparation Techniques. John Wiley & Sons, 1998.
Reznor007 -
Okay, thanks. I'll look into it.
============
The Dash etchant worked for the NOR implantation rom (not the NAND rom, the opposite of what the paper claims).
Which makes me wonder if they accidentally mentioned something else / mislabelled / whatever.
Another possibility is that I'm just doing something horribly wrong.
The problem is this, even when using the Dash etchant, it doesn't stain just the n-type. It stains stains anything in an n-well.
Sorry for the blurry image, but here's an example.
https://netfiles.uiuc.edu/mantey/www/NE ... erview.jpg
I'm tried n-type stains, and have a similar problem:
https://netfiles.uiuc.edu/mantey/www/DS ... tain_1.jpg
None of the professors here use these techniques enough (or ever) that they could help me. And the book, while it is really nice, kind of assumes you've been doing this for awhile and list "recipes" but doesn't really have much in the way of "becareful not to do this or such and such will happen", or "if you see this or that, then this means you may have done xxx slightly wrong".
I've tried several times, and with so many etchants to choose from (and not fully understanding what I'm doing anyway), it would be nice to figure out what those people really did do to make that picture.
They keep talking about all these people working on cracking "smart cards"... is there some kind of underground community that does this? Maybe we could find someone knowledgeable there.
Anyway, the point is that there is still a lot of potential in this ... but this is just way beyond my field. I'm really enjoying this "new hobby", but I need info/guidance to get better. Any info or contacts people find would be greatly appreciated.
Okay, thanks. I'll look into it.
============
I was having enough fun with this "new hobby" that I bought the book (it wasn't at any library near me). I used the Dash etchant technique mentioned in the paper. It doesn't work as the paper showed though.bobthebuilder wrote:Have you tried obtaining the text book they cited as the source of the staining technique used. Considering that the book cost over a hundred bucks (Like most of my college text books), perhaps you could obtain it through an inter-library loan.
P.S. F. Beck: Integrated Circuit Failure Analysis - A Guide to Preparation Techniques. John Wiley & Sons, 1998.
The Dash etchant worked for the NOR implantation rom (not the NAND rom, the opposite of what the paper claims).
Which makes me wonder if they accidentally mentioned something else / mislabelled / whatever.
Another possibility is that I'm just doing something horribly wrong.
The problem is this, even when using the Dash etchant, it doesn't stain just the n-type. It stains stains anything in an n-well.
Sorry for the blurry image, but here's an example.
https://netfiles.uiuc.edu/mantey/www/NE ... erview.jpg
I'm tried n-type stains, and have a similar problem:
https://netfiles.uiuc.edu/mantey/www/DS ... tain_1.jpg
None of the professors here use these techniques enough (or ever) that they could help me. And the book, while it is really nice, kind of assumes you've been doing this for awhile and list "recipes" but doesn't really have much in the way of "becareful not to do this or such and such will happen", or "if you see this or that, then this means you may have done xxx slightly wrong".
I've tried several times, and with so many etchants to choose from (and not fully understanding what I'm doing anyway), it would be nice to figure out what those people really did do to make that picture.
They keep talking about all these people working on cracking "smart cards"... is there some kind of underground community that does this? Maybe we could find someone knowledgeable there.
Anyway, the point is that there is still a lot of potential in this ... but this is just way beyond my field. I'm really enjoying this "new hobby", but I need info/guidance to get better. Any info or contacts people find would be greatly appreciated.
The board gave me an error when I posted the above message, but it showed up anyway. However, now it won't let me edit my post above for some reason.
-----------
So, to fix some errors, here's the edit:
--snip snip--
It has been many months since I've done this, so my memory isn't that great right now. I may be mixing up the p/n types, I'd have to reread my cherry-roms posts to be sure, but the site is down. Anyway, I think the following is correct...
The problem is this, even when using the Dash etchant, it doesn't stain all p-type (or just p-type). It stains everything not in an n-well.
Sorry for the blurry images, but here's some examples.
https://netfiles.uiuc.edu/mantey/www/NE ... erview.jpg
https://netfiles.uiuc.edu/mantey/www/NE ... IC_ROM.jpg
Since NOR rom is p-implantation in a p-well, it works great for reading out the ROM.
I've tried the dash etchant on the NAND rom, and the same thing happens (nothing in an n-well is stained). So it is no help.
I've tried n-type stains, and they have a similar problem:
https://netfiles.uiuc.edu/mantey/www/DS ... tain_1.jpg
--snip snip--
-----------
So, to fix some errors, here's the edit:
--snip snip--
It has been many months since I've done this, so my memory isn't that great right now. I may be mixing up the p/n types, I'd have to reread my cherry-roms posts to be sure, but the site is down. Anyway, I think the following is correct...
The problem is this, even when using the Dash etchant, it doesn't stain all p-type (or just p-type). It stains everything not in an n-well.
Sorry for the blurry images, but here's some examples.
https://netfiles.uiuc.edu/mantey/www/NE ... erview.jpg
https://netfiles.uiuc.edu/mantey/www/NE ... IC_ROM.jpg
Since NOR rom is p-implantation in a p-well, it works great for reading out the ROM.
I've tried the dash etchant on the NAND rom, and the same thing happens (nothing in an n-well is stained). So it is no help.
I've tried n-type stains, and they have a similar problem:
https://netfiles.uiuc.edu/mantey/www/DS ... tain_1.jpg
--snip snip--
-
- Rookie
- Posts: 11
- Joined: Wed Jul 28, 2004 5:03 pm
The digital satellite testing (piracy) community does a lot of hacking of smart cards, in order to unloack all channels without a subscription. There is program code on those cards that can't be just read, I am assuming, so maybe this method has been used there?neviksti wrote:They keep talking about all these people working on cracking "smart cards"... is there some kind of underground community that does this? Maybe we could find someone knowledgeable there.
~Bent
-
- Hazed
- Posts: 76
- Joined: Sat Jan 28, 2006 7:21 am
I found a article that may point you in the correct direction. The authors of the article seems to know a Internet mailing list dedicated to amateur smartcard hacking and even provides someones e-mail adress as a source of info.
Here is the link to the article: http://www.cl.cam.ac.uk/~rja14/tamper.html
Click on either Ross Anderson or Markus Kuhn to contact them.
Here is the link to the article: http://www.cl.cam.ac.uk/~rja14/tamper.html
Click on either Ross Anderson or Markus Kuhn to contact them.
-
- Trooper
- Posts: 394
- Joined: Mon Feb 20, 2006 3:11 am
- Location: Space
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
That's a good document. It explains in detail what I remember.
Up until the latest generation of smart cards, they were broken into using what's called 'glitching' in the community.
This was effectively momentarily overvolting the chip as described in document and using some transient response anomaliess to bump the program counter beyond the protection code in the boot ROM.
The smart card reader can 'glitch' the card many times per second, so usually the trial and error process of glitching it to the correct place only takes a second or two.
The details on how much voltage, the length of time voltage is applied, and how you determine what point of code you want to start at I don't know the details on, but it seems that document is a great starting point.
Up until the latest generation of smart cards, they were broken into using what's called 'glitching' in the community.
This was effectively momentarily overvolting the chip as described in document and using some transient response anomaliess to bump the program counter beyond the protection code in the boot ROM.
The smart card reader can 'glitch' the card many times per second, so usually the trial and error process of glitching it to the correct place only takes a second or two.
The details on how much voltage, the length of time voltage is applied, and how you determine what point of code you want to start at I don't know the details on, but it seems that document is a great starting point.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.