Gameking

[Gamekin]

I need 74hc595 shifting devices as most Arduinos don't have enough address lines. ST_CP =Storage register clock pin (SRCK).
Most or all dumping projects use resistors like Ardumpino (Sega Genesis) and Cart readers for SNES and Gameboy. Some say it's optional but all use them.

http://www.brunofreitas.com/node/31

http://www.insidegadgets.com/2011/03/19 ... d-the-rom/

So not sure if I should use any at 3V (for protection) and what values (same for capacitors).

I doubt that I could dump that in few seconds. For a Genesis it took 6 minutes, for SNES 20 minutes (more memory and 16 bit though).

You think Brian who is smart enough to built an oscilloscope, measured the pins, wrote an emulator etc, don't know what voltage his PC has? Maybe because his dumper should be compatible with other consoles including Gameboy. He used both on his video capture device.

Now do I have to connect pin 46 (s3)? Is that OE? Brian said OE is tied to the ground and S1, S2 and S3 are not connected (what is different on my cart).
Bankswitching is done by the CPU but the ROMs are on the cartridge. And shouldn't I know the mapping?
Or isn't that important for dumping? Wouldn't the dumped code be scrambled?

[lidnariq]

Most or all dumping projects use resistors like Ardumpino (Sega Genesis) and Cart readers for SNES and Gameboy.
[...]
So not sure if I should use any at 3V (for protection) and what values (same for capacitors).

The resistors are a safety thing. They mean that if you got the pinout wrong, or if you inserted the cartridge slightly misaligned, you don't damage anything.
Use one 0.1µF capacitor for each IC. Might work without them, but power rail issues are an obvious failure mode to head off early.

I doubt that I could dump that in few seconds. For a Genesis it took 6 minutes, for SNES 20 minutes (more memory and 16 bit though).

..... Oh, that's because they're using shift registers. Ugh. There are obvious workarounds, if you care. (e.g. use binary counters like the CD4040s that BriPro used, or parallel latches like 74HC374s )

In any case, the Gameking games look like they're usually 1/4 the size of the smallest SNES game: it should be pretty fast.

You think Brian who is smart enough [... didn't] know what voltage his PC has?

Smart people make stupid assumptions all the time. Neither he nor I are exceptions.

In any case, the entire point is: we don't know what the ROM is under the epoxy blob. If we had a part number, we could look it up and see if it was 5V tolerant, but we don't, so we can't, so we do the most conservative thing so that we don't risk blowing up the ROM, which is to say, we run the entire thing at 3V.

Now do I have to connect pin 46 (s3)? Is that OE? Brian said OE is tied to the ground and S1, S2 and S3 are not connected (what is different on my cart).

You don't have to connect any pins that are obviously disconnected (the bank of 16 on one end) or are duplicate copies of ground or power. You probably need to connect both of the solitary traces, which look like they're what BriPro called pins 16 and 48. Which ... yes, differs from what's true for his. I have no idea what's going on, and unless we can get an oscilloscope or logic analyzer in there to figure out what's going on, we won't be able to find out. You should probably check and see if this is the same for all your cartridges, lest you overspecialize and have to modify it later.

Bankswitching is done by the CPU but the ROMs are on the cartridge. And shouldn't I know the mapping?
Or isn't that important for dumping? Wouldn't the dumped code be scrambled?

We don't know anything yet, other than the pictures of the PCB and what BriPro said close to a decade ago. Without being able to execute code on the Gameking, or monitor what's happening as a game is executing, the best we can do at first is just dump the contents of the ROM and stare at it until it makes sense.
As long as all the bits have arrived, even if it is scrambled it is pretty easy to re-shuffle all the bits without having to rewire and re-download everything.

[Gamekin]

Thanks very much for now!
It's a bit more clear now. I wait for my GBA slot and then maybe try it somehow.

what BriPro called pins 16 and 48

Both pins are not connected on either revision. You mean 18 (CE) and 46 (s3) ?
As OE is not known for sure, someone told me I could just use CE like Brian did.

[lidnariq]

You mean 18 (CE) and 46 (s3) ?

I'm having the worst time figuring where to count from, since nothing's labeled. Whichever two pins are connected to the epoxy blob but have no-connects on both sides.

As OE is not known for sure, someone told me I could just use CE like Brian did.

It wouldn't hurt to include the ability to drive both, but I strongly suspect that's right.

[Gamekin]

According Brian pics pin 1 is on the front right and pin 31 on the back left.

If I would start from left, it would be S2. But on the backside it would either be NC or D2.

[Gamekin]

I have received my Gameboy slot and it looks like it's possible together with a 2nd one. I have to build a construction that will be stable for some time, especially the upper slot.
Thats why the question about the dumping speed. I need it as fast and secure as possible. 1 minute or less would be great.

20 ADR lines means up to 1MB data. One cart is 128 k. Don't know why it's more than 512k. There's a small menu to choose the game, maybe some games with digitized speech are bigger.
Can someone tell me more about the speed (also depending on the code).

I haven't ordered a microcontroller yet. Maybe there's a better, faster and easier way. Although I've spent lots of time to study the Arduino.

Can someone please check my schematics and code? Most questions are inside the code.
Most projects and examples including 74HC595 are for LEDs or EEPROMs and only involve 2 shifting devices, I only need to read the ROM.
The FTDI USB board is wrong. There is a 6 pin 1:1 adapter to fit it.

Code: Select all

// Gameking cart reader ino sketch by Gamekin. Mostly snippets from other sources
//1 game carts have 17 Adress lines (128 K), 4in1 carts 20. So need to read up to 1 MB
//Some pin functions are unknown or unsure. So can only use CE, not OE. And use 3V.
//No RAM no EEPROMs just 1 ROM glob top. 3x74HC595, so I think I have to read 3 Bytes each loop.


#include "pins_arduino.h" 
//taken from Atariromreader unknown if needed

//Pin connected to ST_CP of 74HC595
int latchPin = 10; //Latch, SS ? might be changed, but ProMini has limited pins
//Pin connected to SH_CP of 74HC595
int clockPin = 13; //SCK
////Pin connected to DS of 74HC595
int dataPin = 11; // MOSI

int d0Pin = 2; //necessary ? most don't have this, but I have wired this
int d1Pin = 3;
int d2Pin = 4;
int d3Pin = 5;
int d4Pin = 6;
int d5Pin = 7;
int d6Pin = 8;
int d7Pin = 9;
//Arduino ProMini has internal pull-up resistors, also for data lines. Unsure if I should use them. 
//digitalWrite(d0Pin, HIGH); d0-7, digitalWrite(irqPin, HIGH); would activate them

//a buffer for bytes to burn
#define ROM_SIZE 1048576 
// in bytes
// byte buffer[ROM_SIZE];  -used by other sketch. Overflow in array dimension error with this value
int data = 0; //Used in counting up to the ROM's maximum byte
byte myByte = 0x00; // Used later as D0-D7 byte

//unknown if need more definitions like irqPin. What about CE (at the 74HC595) and SRCLR?


void setup(){
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);   // ---one code says INPUT, but maybe later
}
  void	data_bus_input() {
  pinMode(d0Pin, INPUT);
  pinMode(d1Pin, INPUT);
  pinMode(d2Pin, INPUT);
  pinMode(d3Pin, INPUT);
  pinMode(d4Pin, INPUT);
  pinMode(d5Pin, INPUT);
  pinMode(d6Pin, INPUT);
  pinMode(d7Pin, INPUT);
}

//switch IO lines of databus to OUTPUT state
void data_bus_output() {
  pinMode(d0Pin, OUTPUT);
  pinMode(d1Pin, OUTPUT);
  pinMode(d2Pin, OUTPUT);
  pinMode(d3Pin, OUTPUT);
  pinMode(d4Pin, OUTPUT);
  pinMode(d5Pin, OUTPUT);
  pinMode(d6Pin, OUTPUT);
  pinMode(d7Pin, OUTPUT);
}

//set databus to input and read a complete byte from the bus
//be sure to set data_bus to input before
byte read_data_bus(){


  Serial.begin(9600);   //unsure if speed can be higher, unknown if FTDI drivers needs other than serial, unsure if serial.begin before pinmode
}               


void loop() {
  while (Serial.available() <=0){
    delay (200);
  }
  
  //for (int i=0; i<24; i++){    // 3x8 bits ?? first attempt from other sketch
    //void shiftOut24bit(int clockPin, int latchPin, int dataPin, unsigned long value) {  //taken from sgcexplorer
	//digitalWrite(latchPin, LOW);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x00FF0000) >> 16);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x0000FF00) >> 8);
	//shiftOut(dataPin, clockPin, MSBFIRST, (value & 0x000000FF));
	//digitalWrite(latchPin, HIGH);

    
 
  digitalWrite(latchPin, LOW); //make shift reg listen 
  if (data < ROM_SIZE) {                          //Do I need to open a file and filename before?
    shiftOut(dataPin, clockPin, MSBFIRST, (data >> 16)); //read 3 Bytes and shift. binary output
    shiftOut(dataPin, clockPin, MSBFIRST, data >> 8);
    shiftOut(dataPin, clockPin, MSBFIRST, data);
    
    digitalWrite(latchPin, HIGH);
    delay(5);
    myByte = d7Pin  //originally called myDigitalRead (9), data pin 9-2
         | d6Pin <<1
         | d5Pin <<2
         | d4Pin <<3
         | d3Pin <<4
         | d2Pin <<5
         | d1Pin <<6
         | d0Pin <<7;
    Serial.write(myByte);
    data++;
    delay (5);
    //digitalWrite(latchPin, LOW);
    }
   } 
    

[lidnariq]

On a cursory look-through, that code looks like it should work? At least, nothing's immediately obviously wrong it.

The virtual protoboard is a little concerning, though: Why do you only have a few resistors on the protoboard? Each 1x5 segment of the protoboard is connected internally, so if you use that you're currently shorting out A0 to A1 and D0 to D1 and so on. Also, 10kOhm in series with Vcc is much too much.

Increasing the speed (9600) should dramatically increase the rate at which you can download the data. You'll need to change it both in the program you send to the microcontroller and also in the serial program on the computer you use to receive the data.

[Gamekin]

Thanks for your time and help!

My first code for an Arduino. I wonder that there are no mistakes. I'm absolutely not sure about everything, including timing issues (also 9600 serial to USB conversion), CE, IRQ, INPUT, OUTPUT of the daisy chain, internal pull-up resistors, FTDI drivers and other stuff. No errors while compiling though. But that doesn't mean that it will work.

For the protoboard. I haven't added all resistors and address lines (for the 2nd and 3rd 595) because of too many overlapping wires. Same logic than 1st device. I somewhere found 10k on most other similar (5V) project. But now I found 470 and 330. Which to choose?

I don't understand where is a 1x5 segment and why there's a problem. I did it according to other projects, however others most have 16 bits and additional chips, and according to a schematic someone recommended.
ADR lines to the shifting devices and Data lines to the Arduino.

I still need the dumping time.

[Gamekin]

I have never used a protoboard but soldered. You probably mean the connections below the board. I know that. But I still can't see the problem.
Originally I wired it up differently what is completly wrong for a protoboard. (I wonder why the software allows that). Then I found that optimized wiring at the 595s (what I had copied from an existing project).


There's also schematics and PCB layout but I haven't used them much. The parts on the schematics are not arranged and the wires are very thin and very light colored.

[lidnariq]

I somewhere found 10k on most other similar (5V) project. But now I found 470 and 330. Which to choose?

Many ROMs consume somewhere in the range of 10 to 100mA when selected. For this, on a 3.3V supply, you'll need to use a resistor not larger than 10-100 ohms.
I have to assume that for the 5V projects they're relying on the ROM still functioning when browning out.

I still need the dumping time.

?
9600 baud→960 bytes per second; 131072 bytes÷960(bytes/second) = 136seconds. Or maybe it's a full megabyte, in which case 1MB/960bps = 1092sec.

[Gamekin]

There we have the 20 minutes.

I had difficulties to solder the wires to the cart slot today. Not because of the pin distance (I have bent every other one up) but the wires won't stick (don't know about the material, maybe missing flux).

I have ordered a 2nd slot. It's also possible to attach the lower socket pins to the cart pins and to insert wires into holes on the other side (considered for the upper pins).
I doubt that I can fix that both for more than 1 minute that way. I considered using other stuff like miniature clothespins or glue.
I have to think about that. It's also very risky to destroy the carts.

Probably I have to ask LiraLuna or other expert who owns a dumping unit and socket and maybe send missing carts to him.

Maybe it's not worth spending more time and money for that and maybe someone's reading all that and can manage that much earlier than I could.
We can't do much anyway with a dump without understanding everything and having an emulator.
I've read that it should be a custom 6502. And where are the in-built games? I wonder how Brian dumped these.

[lidnariq]

There we have the 20 minutes.

Sure, but there's also no reason to be running things at 9600 baud. You should be able to get 115200, 12 times faster, working without difficulty.

I had difficulties to solder the wires to the cart slot today. Not because of the pin distance (I have bent every other one up) but the wires won't stick (don't know about the material, maybe missing flux).

Maybe try sandpaper on the soldering surface?

We can't do much anyway with a dump without understanding everything and having an emulator.

That's not true. You can get pretty far just by reverse-engineering the binary blob that's to be executed. It's more than enough for nesticle levels of accuracy (which, while substantially wrong, is still mostly right)

I've read that it should be a custom 6502. And where are the in-built games? I wonder how Brian dumped these.

Once you reverse-engineer enough of what the machine is doing, it's not too difficult to build a devcart. Once you can execute arbitrary code on the Gameking, it's pretty easy to poke around things and see where they've stored any built-in games, and then transmit them.

[Gamekin]

I don't have enough knowledge (or time) for writing an emulator and reverse-engineering. Even LiraNuna who wrote or better tried the first emulator obviously couldn't understand all that and stopped that. Same for MESS.

Unless I haven't found a solution for the socket and efficient coding, I probably can't do that. (However I will try continue soldering tomorrow).
Everyone (with more skills) could buy a cartrige, which isn't expensive, and dump that.
Maybe there's a reason why there's no emulator and no dumps. Sometimes I asked myself if Brian did all that or it's even a fake.
He built a devcart but no proof of how to handle the "wrong cart error" and any other code. Nobody can verify that. The only thing we have are some screencaps which could have been made manually. No infos about internal working, sound and everything else. And why he removed everything and withdraw a free license which isn't allowed? Very strange.

I read about some other dumping methods like TapeDump on nesdev but the function of the EXT connector is also unknown (not sound output).

[Gamekin]

I now have soldered most of the wires and wait for the 2nd slot. I already searched for protoboards with a pitch < 1" for the socket and searched for other slots.

I will restart my virtual protoboard and make it this time with the real schematics function. That will autotrace the protoboard wires (hardly to see and badly aligned though). I will then upload more pics.

In the meantime I have found a 3rd person who obviously has dumped the carts, at least he owns even 4-in-1 carts and a compatible dumping unit. He measured the pins and said they are 512 KB. I wonder why mine has 20 ADR lines. I also think that they are 5V compatible.
Somehow I think it could be LiraNuna or Brian. Or maybe LiraNuna is even Brian. Similar blog title like Brian but time and collection more fits to LiraNuna. Although he mainly used the same nick.
I think most or all games have already been dumped and are or were available somewhere (LiraNuna said don't ask for ROMs, dump yourself or search the web). None of them will publish their dumps or emulating code for whatever reason.

The games for Gameking 4 (not Gameking game compatible but NES games, but probably with Gameking pinouts) have also been dumped. Someone said that this NES compatible handheld also plays Gameking games. But I doubt that. Completely different screen.

Any more help with the protoboard, code or socket building?

[lidnariq]

Or maybe LiraNuna is even Brian.

Definitely not, histroical whois information shows who LiraNuna is. (someone in San Francisco)

Similar blog title like Brian but time and collection more fits to LiraNuna.

That's a standard blogspot template.

I think most or all games have already been dumped and are or were available somewhere (LiraNuna said don't ask for ROMs, dump yourself or search the web). None of them will publish their dumps or emulating code for whatever reason.

I think I doubt that the ROMs were ever available. I'm vaguely surprised that they won't provide a high-level specification, something like "the LCD is memory mapped at address X", though.

Any more help with the protoboard, code or socket building?

I think you're on the right route. I don't have any thoughts on how to help with the socket, sorry.