SPC7110 Reverse Engineering Project

caitsith2 · Post by **caitsith2** » Mon Jun 09, 2008 6:57 pm

Starting on the PCB design. seems nintendo could not stick with even 100mil pin spacing on the snes cart connector. Its 98 mil between pins horizontally, and 180 mils row spacing. The group of 4 pins off the main ones, are 275 mils away.

kyuusaku · Post by **kyuusaku** » Mon Jun 09, 2008 8:25 pm

neviksti wrote:I'm not entirely sure I understand. You have a cartridge with the SPC removed, and the BIOS still can't start up? Since the SPC controls the chip select for both ROMs I don't think the ROM would still start without it. I have a feeling I am misunderstanding something simple here.

No no, I had tried running the game in an emulator in the past, and noticed the game will still start and go through it's self test regardless of emulating the SPC7110 at all, so I knew it couldn't be the lack of signals being passed to the cart.

kammedo · Post by **kammedo** » Mon Jun 09, 2008 11:23 pm

Ok, so now I finally managed to get the GDSF7 up and running. The disk was broken, it didnt even start if it was present. I removed the Floppy disk and voilá! But then, once again - FEoEZ does NOT start up on a GDSF7, nor in menu mode nor in play mode, it just black-screens..

i have this USB to par cable. transfering through Ucon64 works fine, but the game doesnt get recognized. If I am not wrong, the GDSF should at least show the file if it has been received, but it should be unplayable. Am i wrong?

I used ucon with --xgd3 flag, as the --xgd6 doesnt work. I will try again later today.

Andreas Naive · Post by **Andreas Naive** » Tue Jun 10, 2008 12:05 am

jolly_codger wrote:Seiko Epson (JP,08-29-1997):

Nice catch. It seems to fit with what we are looking for.

I won't recommend you to read all the patent document at this point, as those patents use to be excesively generic, but taking in mind the general ideas could be useful when studying the data to see if this could be related with the SPC7110.

kammedo · Post by **kammedo** » Tue Jun 10, 2008 2:28 am

Andreas Naive wrote:
jolly_codger wrote:Seiko Epson (JP,08-29-1997):
Nice catch. It seems to fit with what we are looking for.

I won't recommend you to read all the patent document at this point, as those patents use to be excesively generic, but taking in mind the general ideas could be useful when studying the data to see if this could be related with the SPC7110.

Intresting read indeed! Lets see what pops out!

EDIT : its referring to a "probability estimate table LSZ". I recall Darkforce saying that it seemed to him the SPC seemed to be using some kind of internal table. Not that it could be directly related, just seemed intresting to tell.
Oh btw, I didnt had the chance to chat with him, I hope I will tonight.

kyuusaku · Post by **kyuusaku** » Tue Jun 10, 2008 11:51 am

kammedo wrote:Ok, so now I finally managed to get the GDSF7 up and running. The disk was broken, it didnt even start if it was present. I removed the Floppy disk and voilá! But then, once again - FEoEZ does NOT start up on a GDSF7, nor in menu mode nor in play mode, it just black-screens..

Load any game with all blocks set to passthrough, immediately after selecting play, the CPU will lock, insert the game, then reset.

kammedo wrote:i have this USB to par cable. transfering through Ucon64 works fine, but the game doesnt get recognized. If I am not wrong, the GDSF should at least show the file if it has been received, but it should be unplayable. Am i wrong?

I'm really surprised it got that far, USB to parallel cables only emulate the centronics handshake used by printers, it's not a full fledged parallel port, you should know that.

kammedo · Post by **kammedo** » Tue Jun 10, 2008 8:53 pm

kyuusaku wrote:
kammedo wrote:Ok, so now I finally managed to get the GDSF7 up and running. The disk was broken, it didnt even start if it was present. I removed the Floppy disk and voilá! But then, once again - FEoEZ does NOT start up on a GDSF7, nor in menu mode nor in play mode, it just black-screens..
Load any game with all blocks set to passthrough, immediately after selecting play, the CPU will lock, insert the game, then reset.

kammedo wrote:i have this USB to par cable. transfering through Ucon64 works fine, but the game doesnt get recognized. If I am not wrong, the GDSF should at least show the file if it has been received, but it should be unplayable. Am i wrong?
I'm really surprised it got that far, USB to parallel cables only emulate the centronics handshake used by printers, it's not a full fledged parallel port, you should know that.

Eh, it wasn't that easy to get that far. I had to try quite a few drivers.

This is not so nice. I have a USB only laptop. The floppy drive of the GDSF is gone, and I don't have any floppies, nor a floppy drive for USB... The cable is a HL-340, the driver is the native one, that is, the one that came with the CD. I am thinking about getting me a USB sniffer. Bah. Or just wait untill I get my new dev station up, which has a DB 25.

Andreas Naive · Post by **Andreas Naive** » Wed Jun 11, 2008 8:11 am

Take a look at this:

http://www.mameworld.info/ubbthreads/sh ... =5&o=&vc=1

Reading Lord Nightmare's comment, it's clear the S-DSP isn't decapped, but he is trying it to be done.

kammedo · Post by **kammedo** » Wed Jun 11, 2008 10:09 pm

Andreas Naive wrote:Take a look at this:

http://www.mameworld.info/ubbthreads/sh ... =5&o=&vc=1

Reading Lord Nightmare's comment, it's clear the S-DSP isn't decapped, but he is trying it to be done.

Hm. Decapping the SPC? Btw, I didnt know the NES CIC chip had been reverse-engineered!

Lord Nightmare · Post by **Lord Nightmare** » Wed Jun 11, 2008 11:10 pm

Yeah but I may have missed the boat in regards to Guru's big decap-a-thon, so I might end up sending it (the s-dsp) to neviksti instead.

Its an S-DSP A btw, so it has a different firmware revision to the original S-DSP. The 1/1/1 and 1/2/2 sneses have the metal APU module and have the S-DSP non-A. the 1/3/2 and later sneses which have the apu on the main pcb have the S-DSP A.
(and the final, 2/4/3 snes with everything on one chip probably effectively has the s-dsp B although the firmware is likely the same as the A)
If anyone has a dead metal module APU (possibly from a failed attempt to hook it to the pc parallel port or something) that would be nice to decap too.

LN

caitsith2 · Post by **caitsith2** » Wed Jun 11, 2008 11:31 pm

What exactly are you referring to, by 1/1/1 and 1/2/2 snes systems. Is there an easy way to tell these systems apart from the 1/3/2 and later systems, without opening them, that you are aware of? (I now have PCBs for the purpose of parallel port APU hookup, and this kind of info would help here.)

Lord Nightmare · Post by **Lord Nightmare** » Wed Jun 11, 2008 11:37 pm

ppu1 rev / ppu2 rev / cpu rev (I THINK)
I need to re-ask TRAC, he has a 1/2/2 system.

a 1/1/1 system has PPU1 and PPU2 and CPU, and a metal removable APU module (these are the first snes systems). According to kevtris, some ?1/1/1? systems are unable to run certain games at all, due to a timing conflict with the MAD-1? (I'm really not sure what was going on, but he had two snes systems which both refused to run super metroid but would run smw just fine.)
a 1/2/2 system has PPU1 and PPU2 A and CPU A, and a metal removable APU module (these are rare second release systems, bundled with some game other than SMW i think? I'm not sure). TRAC has one of these.
a 1/3/2 system has PPU1 and PPU2 B and CPU A, and has the two APU chips on the mainboard (the APU has S-DSP A instead of S-DSP). these systems were sold bundled with zelda:LTTP I believe. Later ones may have been bundled with other games. This is the most common type of SNES I THINK. I have one of these.
a minisnes ?1/3/2? (1997, SNN-CPU-01 pcb) system has one large chip called the S-CPUN which contains the CPU, PPU1 and PPU2, and the APU has both chips lumped together into one chip called the S-APU. There are two new small chips near the cart connector called S-MIX A and S-RGB A, which probably somehow involve audio and video respectively. The snes work ram is on a chip called the S-WRAM A (and the APU's 64k of ram is probably there too). I have one of these.
a minisnes 2/4/3 system has one HUGE IC on it which contains ALL FIVE MAIN SNES CHIPS (CPU, PPU1, PPU2, SMP, DSP). these sneses are also known as the ?G-something? systems, and were made for both europe and US. these are very rare in the US. pagefault has one of these.

Edit: fix info for the ?earlier? 1997 minisnes
LN

caitsith2 · Post by **caitsith2** » Wed Jun 11, 2008 11:43 pm

The 2 systems which I have pulled metal box APUs from, are 1/1/1, and if it is PPU1/PPU2/CPU, then 1/1/2.

Lord Nightmare · Post by **Lord Nightmare** » Wed Jun 11, 2008 11:48 pm

see edit to previous post.
Edit: see NEW edit to previous post, involving the minisnes details

1/1/2 system? interesting, that's YET ANOTHER revision...

neviksti · Post by **neviksti** » Thu Jun 12, 2008 9:49 pm

kyuusaku,
Can you try this on your SF7 with FEoEZ?
http://www.neviksti.com/testSPC7110.zip

It stores the decompressed data at $0000, and $1000 in the SRAM (and should fill the rest with FF's).
This is just a simple test to start with (and also tests to make sure there is nothing special about the table location / index ... for it decompresses the same data using two different table/indexes).