Reverse Engineering the CIC

[Patnukem]

I am still getting the same dump with the Capacitor.

Fiskbit, yes I got that starting point when I made those two changes to Jeroen's code. It seems to be the same string just different start point but it would start there each time.

Probably a dumb idea but I need to ask, What are the chances they used one of the other SM series chips with additional rom space here?

SM590: 508X8 bits
SM591: 1016X8 bits
SM595: 762X8 bits

[Jeroen]

Ok so I tried to see if it's possible to set R20, R21 low at the same time, this seems to work. In fact, it gets rid of the one redundant clock that was causing an offset, leading me to believe that's how it was intended to be done maybe.

Code: Select all

//sm590 dumper script

//Written by Jero32 21/09/2020
//to run, hook the arduino pins up to sm590 chip according to pinout below. Upload sketch to arduino. Clear the terminal window
//and press the reset button

//do one clock cycle. Note: relies on opcodes taking time to provide delay for speed, not very portable
#define ClockMacro()\
  if(1){\
    PORTC |= 0b00001000; delayMicroseconds(5); PORTC &= 0b11110111; delayMicroseconds(5);\
  } else {}

#define ClockMacroTrigger()\
  if(1){\
    PORTC |= 0b00101000; delayMicroseconds(5); PORTC &= 0b11010111; delayMicroseconds(5);\
  } else {}

  
//do 3 clocks
#define ThreeClockMacro()\
  if(1){\
    ClockMacro();\
    ClockMacro();\
    ClockMacro();\
  } else {}

//do 4 clocks
#define FourClockMacro()\
  if(1){\
    ClockMacro();\
    ClockMacro();\
    ClockMacro();\
    ClockMacro();\
  } else {}

void setup() {
  int i;
  
  //R20 A0
  //R21 A1
  //R22 A2
  //CLOCK A3
  //Reset/ACL A4

  //D0 pin 2
  //D1 pin 3
  //D2 pin 4
  //D3 pin 5

  //D4 pin 6
  //D5 pin 7
  //D6 pin 8
  //D7 pin 9

  noInterrupts();

  DDRD &= 0b00000011; //set pins 2 through 7 as inputs
  DDRB &= 0b11111100; //set pin 8 and 9 as inputs
  DDRC |= 0b00111111; // Set A0 through A4 as outputs */

  DIDR0 = 0x00; //no longer neccessary but it doesn't hurt.
  PORTC &= 0b11100000; //make sure all bits are in a known cleared state
  PORTC |= 0b00010111; // set pin A0 - A4 High with the exception of A3/CLK

  for(i= 0; i<255; i++){
    FourClockMacro(); //start the clock give some time to boot up
  }

  PORTC &= 0b11101111;// lower ACL
  FourClockMacro();
  PORTC &= 0b11111100;//lower R20, R21
  FourClockMacro();
  

}

void loop() {
  int i;
  
  unsigned char dataArray[508];
  for (i = 0; i < 508; i++) { //fill a 508 byte array with the rom data
    ClockMacroTrigger();
    ClockMacro();
    dataArray[i] = ((PIND & 0b11111100) >> 2) | ((PINB & 0b00000011) << 6); //note date seems inverted compared to "known" romdumps
    ClockMacro();
    ClockMacro();
  }

  Serial.begin(9600);
  
  for (i = 0; i < 508; i++) {
    Serial.print("i");
    Serial.print(i, HEX);
    Serial.print(" :");
    Serial.print(((dataArray[i] ^ 0XFF)) & 0xFF, HEX);//data inverted to match "known" rom dumps
    Serial.print("\r\n");
  }
  while (1) {}

}

I'm gonna run some experiments to see if I can maybe put some clocks between setting reset low and R20/21

edit: I can confirm that putting:

Code: Select all

for(i=0; i<509; i++){FourClockMacro();}

after ACL does not break the above script.

edit2: forgot to mention, this was all spurred on by the fact that if I set reset low at the same time as R20/21 it would be all 0xEC (iirc). So fiskbit, I think this update will at least fix your issue.

[Patnukem]

Not sure if I am being helpful at this point, but I am still getting same results with the updated code on mine.

[Jeroen]

Not sure if I am being helpful at this point, but I am still getting same results with the updated code on mine.

Well I can't duplicate the results, so someone needs to confirm if the update worked or not

[Patnukem]

I was reviewing the Seanriddle dumping directions and see where it is noted that

“SM591 and SM595 might require changing fields somehow to get all the data”

Maybe the 6113(mine is a B version after checking as is every nes game I can find In the house) & the 3198A are these other chips because this statement makes me think his directions would get some of the data and not all like how my dump starts off looking ok but is missing stuff?

[lidnariq]

Sadly, your 3198 dumps appear to be completely fine, other than the two LSbits being completely broken. Even if there are more than four pages of instructions inside, the dumps you've recovered can only be six-bit-wide subsets of those 508 instructions.

[Fiskbit]

I haven't seen anything yet that would make me think these are SM591 or SM595 chips. Even if they were, we should be getting the first field, and would know it's incomplete because the code in that field would have jump instructions referencing the other field.

[Patnukem]

what lines am I missing data on so I can watch out for it after trying some stuff code edits.

[Fiskbit]

I believe CIC pins 1 and 2 are the ones that should be outputting your missing bits.

[Patnukem]

Out of curiosity I ran it with pin 1 disconnected and again with pin 2...

Pin 1 disconnected I got mostly the same code shifted up by 1, except in the middle it syncs back up with the original code then shifts again up one.

Pin 2 disconnected was all shifted up by 2 for the entirety of the dump.

No idea if that is helpful but it is interesting.

I also did some further investigating how the CIC is networked, besides the 4 pins I described earlier that are tied in combinations of ground and voltage to signify cart positions. I also found all CIC pin 1's are tied to pin 2 of the main CIC, minus the menu cart (unless there was a short in my multimeter I could not get a reading.), this makes sense for input/output. Pin 2 of the 3198A are all tied together on the cart board but exit to 6C a 74ALS541. Maybe this will help.

I believe CIC pins 1 and 2 are the ones that should be outputting your missing bits.

[Jeroen]

Considering the bits are inverted, if you disconnect them they'd read 0x0, so it would present as a 1 or 2 depending on bit position, so that's expected.

[Jeroen]

If anyone's interested in giving dumping a try. This seller seems to be selling quite a few famicombox games https://www.ebay.com/sch/shinjuku_card_ ... pg=&_from=

note: if someone can send me a known working one, I can probably dump it.

[Patnukem]

Do we know why the 6113B won’t dump either? Mine is a working chip.

I can try another game, I did get a proper desoldering setup to prevent messing up anything on the main board repairs.

[Fiskbit]

I have a desoldering station coming in the next couple weeks and will try to dump a 3198A after that arrives.

Another thing I'd like to look at is the Famicom Modem CIC. The modem uses an 8633AN and its carts an 8634A. These are surface-mounted 18-pin chips. The wiring looks like it might match the pinout of the 18-pin SM59x packaging, so perhaps it's an SM59x and can be dumped in the same way.

[Jeroen]

Do we know why the 6113B won’t dump either? Mine is a working chip.

I can try another game, I did get a proper desoldering setup to prevent messing up anything on the main board repairs.

I do not know at this point, but without using an oscilloscope and actually seeing what's going on, it becomes a frustrating exercise of "maybe it's x".