Hi,
I want to dump Gameking cartridges which are similar to a Game Boy but have 2x30 pins like the Famicom or better Game Theory Admiral but different pinout.
It must be possible. 2 guys have managed it but discontinued. There is no well working emulator.
The basic facts like the pinout is known and it should be easy. Not sure about if mapping, bank switching and thelike are the problems.
Can someone tell me if it's possible or too difficult.
Maybe with a Arduino. The Cartridges have 17 address lines and needs 3V (5V should be too high).
Any hints?
If I remember correctly, Brian Provinciano(he's also
a member here who posted a while earlier), who created
Grand Threftendo Retro City Rampage, did some researches on the system and dumped the ROMs. He never published the games for downloading though.
I really miss his original homepage(it's now just a twitter page). There're loads of interesting stuff on
obscure systems, not to mention that he also worked with SCI Studio.
Brian Provinciano's website is still available via archive.org.
http://web.archive.org/web/200710280903 ... /index.phpThat's the only useful website with pinout details. He also built a cart reader
http://web.archive.org/web/200710250631 ... cartreaderbut the images are very tiny and he didn't tell exactly what kind of resistors, software etc he used. And no schematics. The Graphics editor can still be downloaded from there.
I doubt that he would help me, now as a professional game designer. Maybe there is a reason why everything was removed from the web. There was an emulator of him on SourceForge but nothing there anymore.
And the GameKengu emulator for DS of Lira Nuna is still available but doesn't work properly. And no source code anyway. Emulation is secondary. First I need to dump.
My skills are limited, maybe someone can say something more by watching the images.
Of course his old site is still available via web.archive.org, but I rather wish he would continue to update it, especially SCI Studio.
Since Brian is still around, why not try sending him a PM or ask in his current Twitter page? Maybe he would offer the information you need.
I have to think about it if I should bother him.
Look what he posted here. Just to promote his game and to ask for music. Last post mid 2011.
Do you think a professional game designer has the time and will send me schematics for a 10 year old project what he removed on purpose from the web? His 2 other SourceForge projects are still there but not this one.
Maybe he didn't made schematics.
I think I rather contact Lira Nuna. He even still collects that Cartridges in 2013.
As I don't have much experience I think I would make it on a different way using a microcontroller instead of direct wiring.
There are many microcontroller dumping projects and there must be many folks around to know how to dump (any) ROMs if the pinout is known what is the case.
There are many Game Boy projects but I choose this board as the Famicom also has 60 pins.
I first considered buying a commercial product but I'm not sure if there's something what will do it without major changes for a reasonable price. So probably a microcontroller is the best way.
The easiest way to figure out what you need to do is open up your cartridge; the labels on any parts inside will probably give you enough information to dump it.
Anyway, the scant information BriPro gives is actually enough to figure out most of what kind of interface the game king wants.
The two CD4040s he uses are each 12-bit counter ICs, which strongly implies inside the cartridge is just a parallel ROM without any special decoding logic. Smaller than 2^(24) addresses (16MB), and almost certainly 8-bit wide output, too.
Thanks! I knew that there must be enough information. And the system is quite easy.
However there are no ROM packages inside but globs. Here are high res pictures
http://wiki.portablegaming.de/GameKingI still need more information of how to build a cart reader. What microcontroller is the best? Can I use other software and hardware with minor changes?
And here's the reason, why Brian stopped his site. He could make money of his emulating project and knowledge. So he won't give me any infos (I wonder why he chose SourceForge and released his emulator under GPL. Maybe someone has downloaded it.)
http://contrabvs.wordpress.com/2010/01/ ... ng-clones/
Gamekin wrote:
I still need more information of how to build a cart reader. What microcontroller is the best? Can I use other software and hardware with minor changes?
Oh, boy. This is going to be a doozy... Do you have a functioning GameKing and an (oscilloscope or logic analyzer)? I wouldn't even bother trying without both.
The best microcontroller is the one you're comfortable using. It sounds like this is all new to you, so you probably either want a BASIC Stamp or an Arduino, but I'm really not qualified to advise on this.
Quote:
And here's the reason, why Brian stopped his site. He could make money of his emulating project and knowledge.
I really find that implausible; the only thing he's been up to with any visibility is Retro City Rampage. Also, if he's selling a GK emulator ... why haven't you heard of it?
Anyway, here's a stab in the dark of what some of the pins might be. Don't trust them: I'm just going on pattern recognition, and it's really easy for that to be wrong.
We have complete pinout informations
http://web.archive.org/web/200710271141 ... page=cartsI don't have an oscilloscope.
Oh, well, I guess given a pinout...
You'll want to drive 18 lines, and read 8 lines. Do any of the Arduinos come with that many I/O in the first place? If so, I'd just hook it up and start writing code to drive it appropriately.
You'd want to do something like
- Set Dx lines to inputs
- Out binary 0 on Ax lines
- Assert /OE low
- Read value on Dx, send to computer
- Assert /OE high
- Increment address on Ax lines
- Go to step 3 until done
That's one of the problems. Most dumping projects use an Arduina Mega which is expensive enough but it must work with boards with fewer ports by reading data in 2 parts (but needs additional electronics).
There is a Sega Genesis project called Ardumpino including schematics and source code. Genesis has 23 lines and he used a small Duemilanove. The other problem is the voltage because I need 3V.
However I have to change the pinouts and dumping code. And need a 2x30 pin socket. It's not that easy. I've also seen projects using a modified cheap programmer. I think I have to ask some Arduino experts (or dumping experts).
http://www.brunofreitas.com/node/31The 2nd one looks even simpler without that many wires. I even have a similar controller. But I can't use that Genesis cartridge and have to built at least a cartrige adapter. Not sure about other issues like voltage and timing. I have to check out the schematics and Sega pinout details. Famicom would be better.
http://www.brunofreitas.com/node/42
You're either going to have to salvage the the game connector off a (hopefully already dead) Gameking, or maybe you'll luck out and find that it's something standard that you can buy at digikey/mouser/newark.
Some of the Arduinos already run at 3V. I don't know more. (I've never had reason to leave the Microchip world)
The 2nd one is the same as the first, he just got a real PCB made instead of using a protoboard.
The slot is standard for Gameking and Game Theory Admiral. Or there is a larger slot but I have to check the right pin distance. Or I have to attach the wires somehow.
I have checked some of the source codes of Ardumpino and found a different SNES project (based on Ardumpino and others, also referring to nesdev) with better source code description but they are all different. 16 bit, 5V, different (fewer) address lines, including bank switching, RAM reading and much more.
So I have to change hardware and software. My skills are limited and I think I need someone who can explain it to me including complete schematics or very detailed descriptions.
First I have to know what controller is the best for this purpose and easy to handle and not too expensive. Depending on the hardware and programming language, I maybe also need someone to help me coding.
I did some other projects some time ago but don't have experience with all that. I don't want to ruin either controller or cartridges or PC.
I need a more versatile dumper or have to read much more source codes.
Any help what I should do is appreciated. Is there a better forum for that purpose? I wonder why only 2 guys in the world managed that. Hardware and games are also owned by a MESS member but nobody can read that (or want to ruin console and games). Maybe I have to contact Lira Nuna who wrote the first emulator. I wonder how he has dumped them.
Dumping games isn't hard, but between the short commercial run of the console, the games not being particularly compelling, and the non-zero barrier to entry, you're not going to see very many people attempting.
The dumper systems you see for the Genesis (16 bit data instead of 8, 5V instead of 3V), SNES or NES or 2600 or GameBoy (5V instead of 3V), GBA (multiplexed data/address) are all quite similar to this. You should be able to adapt any of them pretty easily.
In general, a design that would work at 5V will still work at 3V, you'll just need to change what it's powered by.
In any case, I'm not interested in simply giving people solutions: I want them to learn to do it themselves. Dumping a ROM makes a good 2nd or 3rd microcontroller project, but you should get comfortable with digital stuff first.
Yes, my skills are limited although I did some microcontroller projects and emulating stuff including compiling and debugging some years ago. Few own projects though.
Yes I have to learn and study more. But first I have to know what microcontroller I should buy to not buy the wrong stuff and waste too much money.
With a 3V Arduino how do I get data to a 5V PC? Don't know if there's conversion stuff embedded or if I have to pull up with electronics by myself. Then I don't need a microcontroller and can built a card reader like Brian.
People say he is a genius managing that.
I'm not sure if you could do that by reading what you told here. Just hooking it all up is obviously not enough. Sounds easy. But it's a system with few facts known. And too expensive to experiment without enough knowledge.
Even Brian doesn't know all of the Gameking as there are pins with functions he didn't understand at all even with an oscilloscope and his code.
I think I will try it somehow and first buy a microcontroller. But I think I need someone to check if my schematics and code would work before I do the real thing.
As I told I better ask elsewhere. Why should I do that alone?
There are different Gamekings and probably many people in China and elsewhere own one and maybe tried. And I don't think that Genesis, GBA and Gameking are that similar. Even a Gameboy has many different styles of cartridges. And who knows if a 4in1 Gameking cartridge needs bank switching or else.
Gamekin wrote:
Yes I have to learn and study more. But first I have to know what microcontroller I should buy to not buy the wrong stuff and waste too much money.
Honestly, it's really hard to go wrong. ARM, atmega, PIC will all work.
Quote:
With a 3V Arduino how do I get data to a 5V PC?
Most Arduino and clones use a USB-serial converter and take care of that invisibly.
Quote:
There are different Gamekings and probably many people in China and elsewhere own one and maybe tried.
If they were in China and tried to dump them, there's no reason to think they'd have written about it in a way that is easy for english speakers to find.
Quote:
And I don't think that Genesis, GBA and Gameking are that similar.
You're getting stuck on high-level details. Electrically, the thing you're trying to interface, at least for the 128KiB versions, is something that behaves identically to a 3V 27C1000.
Quote:
Even a Gameboy has many different styles of cartridges.
Yes, banking might be a pain. But once you get something that can implement any part, it's a lot easier to see what you need to do next.
Correct me if I am wrong, but I see no indication that Brian had "stopped" his original site. What led to this conclusion?
Instead of "stopping" or removing the site I think he just abandoned it because he was busy with other stuff, and the domain just expired and the site disappeared. It's until fairly recently that he directed the domain name to his twitter page.
I found someone who gave a little more details (not much though) and some advice what I should buy and link to a similar project.
I still have to study much more about that. And I'm not sure if I can handle all that in the near future.
Probably I will order a (cheap) microcontroller . After having ruined some cartridges or the controller, I think I have to pay someone to build that for me or give it up.
I don't want to study for a very long time and waste money and destroy rare cartridges. Maybe I'm not smart enough or didn't spent enough time.
I don't understand Chinese either. Although projects and images would have been found. I even searched the web by typing Chinese stuff. "Gameking" and most games have English titles even in China or elsewhere.
One of the problems is still to find a cartridge slot.
Brian obviously stopped (or paused or abandoned) his project and deleted everything from the web including that particular SourceForge project (robots.txt). He claims to put there an emulator. Nothing to find at all anymore except via archive.org. Also others say that he stopped that.
Yes he is or was obviously busy with something else. What doesn't mean he consider(ed) making money of his knowledge in the future. Maybe there were legal issues or other reasons or he tries to find some cooperation with companies. Gameking 3 and 4 are even more mysterious and rare. I don't know the truth but I still doubt that he will help me. Interesting there are even at least 2 clones of the Gameking. So clones of the clone.
"Cooperation" looks likely. I'm under the impression Mr. Provinciano blanked his reverse-engineering past to make Vblank Entertainment (his game studio) more attractive to gaming platform gatekeepers such as SNE/MSFT/NTDOY.
That sounds plausible. But he didn't remove his 2 other SourceForge projects, just this one. And he can always be found at archive.org, Wikipedia and elsewhere including this forum.
We can only speculate.
Since GrandTheftTendo was the original NES version of Retro City Rampage, And the original NES version was recompleted for the Wii as an extra, I highly doubt that things would be valid here (it is an MMC5 rom, same as the old one), does it?
I researched a bit more and almost ordered the dumping stuff.
For the socket: Gameking, GB and GBA sockets seem to have the same contact distance. The Gameking cartridge is similar to the GB cart and the 30 pins seem to be at the same places as the 32 pins of the GB missing the outermost 2 pins. I need pins on both sides, so either use 2 GB slots or at least one slot on the rear and attach wires on front manually or build something custom.
I only have 4-in1 carts. I opened one and it says Rev 1.0 2007E, year 2005. Different pinouts.
Brian claims to have Rev 1.0 but pics and descriptions match Rev 2.0.
I traced the lines and the 4-1 carts obviously have 20 instead of 17 ADR lines. Pins 20,21 and 50 connected to the glob.
Pin 10 is also connected to VCC. Brian said S1 with unknown function.
Pin 15 is NC (Brian said S2).
Pin 46 is connected somewhere to the front PCB (Brian said S3). I can't see exactly where, as text is printed on.
ADR pins are much better arranged making a 45 degree line.
Some other pins seem to be arranged or shifted differently. Pin 29 is attached to the glob on the front side instead of the rear. I can upload PCB pics.
What does that mean, especially for dumping? Bank switching? Pins must be compatible to all Gamekings. Maybe the 4-1 carts have color infos for Gameking 3?
What about emulating? A 65C02 is used. Much of the data are uncompressed graphics (which can be extracted using Brian's editor). The sound probably consists of samples. The rest must be the game code.
Is that simple 6502 code or maybe encrypted opcodes or a custom 6502? Could Brian and LiraLuna managed it that easy with encryption? Graphics are more likely GB based, games NES based. Sound, music and digitized speech of unknown origin. The GB has predefined sound effects, maybe they have been used. But could be any samples. Is NES capable of digitized speech?
An Arduino ProMini 3.3 V is maybe the cheapest solution. 3 more ADR lines is no problem as I need 3 shifting devices anyway. I have rough schematics and tried to wire that up using fritzing.
Can I use pins 2-9 as data lines (analog or digital ?) and what latch pin to choose? Previously I have chosen Pin 6. Latch pin could be chosen but pins on a tiny board are limited and some reserved.
Any advice?
Gamekin wrote:
Pin 10 is also connected to VCC. Brian said S1 with unknown function.
Pin 15 is NC (Brian said S2).
Pin 46 is connected somewhere to the front PCB (Brian said S3). I can't see exactly where, as text is printed on.
The S pins look like they are for signalling static content back to the console, with one of 8 numbers specified in binary by tying the lines high or low.
... Although, if one is N/C it might be trinary, but that feels unlikely.
Quote:
I can upload PCB pics.
That'd be helpful.
Quote:
What does that mean, especially for dumping? Bank switching? Pins must be compatible to all Gamekings. Maybe the 4-1 carts have color infos for Gameking 3?
It's hard to tell, because the only information we have is that it's a 65C02 at 6MHz, using a very low resolution framebuffer. With 60 whole pins for it, who knows what they did with the extra pins? It could be like the NES or NeoGeo and export the graphics bus to the cartridge, or maybe something else.
Quote:
Is that simple 6502 code or maybe encrypted opcodes or a custom 6502?
Encrypted is unlikely because doing so would be more expensive. It is probably either a plain-jane 65C02 (CMOS variant) or a SunPlus part (which we believe is a superset of the 65C02 but don't have public documentation)
Quote:
Is NES capable of digitized speech?
The NES's CPU is fast enough to implement a simple speech synthesizer. There's no dedicated hardware for it.
Quote:
Can I use pins 2-9 as data lines (analog or digital ?)
All of the pins of the atmega168# that are brought out from the original package can be used fine for digital I/O. (There are two pins that can't be, ADC6 and ADC7, but they are harder to get to)
Thanks.
I will upload PCB pics tomorrow.
On the one hand cart specs must be the same to match the same hardware slot.
On the other hand the whole thing is getting more and more complicated.
Obviously I'm the first in the world figuring out the different cart revisions.
I don't know if I should dare dumping it.
How do I know If I need 3V? 3V GB dumping projects use 5V powered controllers. Don't know about resistor (others use 10k, others say no need) and caps values, timing, software access etc.
Brian claims, one pin could be OE, but he only used CE.
Some controllers have built-in resistors others don't. There seem to be different Arduinos standards. (especially PIN 13). And 3V hardware.
Cart size should be 128k. But how do I know if 4-in1 carts are bigger? And how big? The code would later give the answer. How long would a dump takes at 8MHZ? 5 minutes?
Maybe a simulation like the LCD games would be easier. But needs completely playing a game and recording sound samples. Then drawing each pixel of the graphics by hand (background and character) what is no big deal at this resolution. However it's not the same as emulating.
Gamekin wrote:
On the one hand cart specs must be the same to match the same hardware slot.
On the other hand the whole thing is getting more and more complicated.
Obviously I'm the first in the world figuring out the different cart revisions.
I don't know if I should dare dumping it.
The only alternatives are finding someone else who's already comfortable with 3V digital stuff, or leaving it alone.
Quote:
How do I know If I need 3V?
The Gameking (apparently) runs at 3V, so you should use 3V.
Quote:
3V GB dumping projects use 5V powered controllers.
The GB and GBC are 5V; the GBA is 3V.
Quote:
Brian claims, one pin could be OE, but he only used CE.
These are the reasons that having a logic analyzer or oscilloscope would be useful.
Quote:
How long would a dump takes at 8MHZ? 5 minutes?
That depends entirely on what connection you're using to the computer.
At absolute fastest, you could plausibly read an entire 128KiB game in less than 1/40th of a second, because the cartridge must be able to provide new data every 1/(6MHz) for the CPU to work.
But you don't have the necessary hardware to upload 6MB/sec to your computer. In practice you will probably be uploading stuff at 11kiB/sec or slower (by using 115200 baud asynchronous serial).
I don't give up easily, until someone's telling me that it's extremely difficult and the risk of damaging the carts is too high. But people say dumping is easy. And it must be possible with 5V like Brian did. You have to convert the voltage either way to get it to the PC. There are few 3V microcontrollers and they have limitations (hard+software). Anyway here are the pics. I don't think that more pins are used on other carts although there were other manufacturers. There are single games and 4-in1 games. Nothing else. Gameking 3 is probably different, but is backwards compatible playing old games in color like GBC. And I don't think that's a special 6502 as Brian created an emulator and a devcart without problems.
Quote:
And it must be possible with 5V like Brian did. You have to convert the voltage either way to get it to the PC.
Sure, it's just a lot easier to convert 1 or 2 lines instead of 30. Also, the PC parallel port has run at 3.3V since the mid-to-late-1990s, not 5V as on the original XT, so he was most likely actually using 3V logic to talk to the ROM anyway.
Quote:
There are few 3V microcontrollers and they have limitations (hard+software).
Whenever I look, I see about twice as many 3V microcontrollers as 5V ones. No idea what's true where you are... Since you're going to have to program a little bit, what experience do you have? There's a fork of GCC for the atmega microcontrollers, so you can program them using C even without the arduino environment. And ARM or MIPS microcontrollers can be used with plain GCC, and it's not too hard to get a hold of a PIC C compiler.
Quote:
I don't think that more pins are used on other carts although there were other manufacturers.
I agree, it looks like you've got 20 address lines, 8 data lines, and 2 control lines.
Quote:
I don't think that's a special 6502 as Brian created an emulator and a devcart without problems.
Well, the devcart isn't relevant, since the Sunplus is a superset of the 65C02 is a superset of the 6502, and so even a bare 6502 program would work.
Whether the emulator is relevant really depends on whether the games he dumped use any of the more advances features of the CPU.
Most of the 5V MCUs run fine at 3.3V, especially AVRs.
Although most Arduinos has 5V and 3.3V pins (internal or external voltage ?) the official specs don't recommend 3V. There are very few plain 3 V controllers. The Due (incompatible with other 5V Arduino hardware like shields, other problems and of course more expensive) and some tiny boards, most with fewer pins. So someone recommends a ProMini 3.3 V. A 5V Uno would require a secondary 3V AtMega 1284 controller.
The ProMini needs pin soldering and external USB board and shifting devices. But is probably the cheapest solution. The ProMin has internal (software ?) pull-up resistors but I understand that I better need resistors at the address lines.
Should I use 10k resistors with that 3V board? And a 100nF capacitor at the shifting device ST_CP? The dumping speed was meant with this hardware and Arduino USB connection.
We can only speculate what PC Brian used in 2004. But he told about 5V pulling-up and pulling-down stuff.
PCB pics: So I hope that pin 29 is still A1 although other aligned. Pin 46 is connected (s3) but I don't need it. Where is the 2nd control line? I only know for sure pin 18 CE.
If I don't need games 2-4 is it possible to use fewer address lines? Is bank switching likely here ? Or other dumping problems?
I probably don't have enough programming skills, so that's why I want to use an existing similar project and simply change the values. And why not using the Arduino IDE?
I first have ordered a GBA slot to check if I can use it.
Gamekin wrote:
Should I use 10k resistors with that 3V board? And a 100nF capacitor at the shifting device ST_CP?
I'm not clear why you would need resistors? "ST_CP"? You'll need to find me a schematic for me to understand.
Quote:
The dumping speed was meant with this hardware and Arduino USB connection.
Ah. Arduinos use a standard USB-serial bridge, so you'll probably be transmitting bytes as 115200 baud (as it's the fastest standardized speed). You could probably read a 128KiB ROM in about 12 seconds.
Quote:
We can only speculate what PC Brian used in 2004. But he told about 5V pulling-up and pulling-down stuff.
Using 3.3V for parallel ports has been standard since at least 1998, so while it's true that we don't know exactly what computer he was using, I doubt it was old enough to be actually running at 5V. He said he was using the Gameking as power rather than using an external adapter, so he was using its 3V supply for everything anyway, including buffering the output of the parallel port. So he dumped it all at 3V, even if he thought otherwise.
Quote:
PCB pics: So I hope that pin 29 is still A1 although other aligned. Pin 46 is connected (s3) but I don't need it. Where is the 2nd control line? I only know for sure pin 18 CE.
If I don't need games 2-4 is it possible to use fewer address lines? Is bank switching likely here ? Or other dumping problems?
It looks like whatever bankswitching happens here is going to be part of the CPU, not part of the cartridge.
If you look at your photos, there's a bank of 10 on each side (address lines), skip 3, 1 line by itself on each side (control lines), skip one, and a final bank of 4 on each side (data lines).
The control lines are probably "output data on data lines when both control lines are low"
If you need more lines than you have control lines for, you could fix some lines high or low manually and toggle them by hand, to dump N KB slices at a time and then reassemble them later.
Quote:
I probably don't have enough programming skills, so that's why I want to use an existing similar project and simply change the values. And why not using the Arduino IDE?
The software is really simple, and I think you could even do this without a reference to adapt from. As long as the arduino IDE works, there's no reason to not use it.
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/31http://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?
Gamekin wrote:
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.
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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.
Thanks very much for now!
It's a bit more clear now. I wait for my GBA slot and then maybe try it somehow.
Quote:
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.
Gamekin wrote:
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.
Quote:
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.
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.
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:
// 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);
}
}
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.
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.
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.
Gamekin wrote:
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.
Quote:
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.
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.
Gamekin wrote:
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.
Quote:
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?
Quote:
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)
Quote:
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.
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).
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?
Gamekin wrote:
Or maybe LiraNuna is even Brian.
Definitely not, histroical whois information shows who LiraNuna is. (someone in San Francisco)
Quote:
Similar blog title like Brian but time and collection more fits to LiraNuna.
That's a standard blogspot template.
Quote:
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.
Quote:
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.
Low-end.net and The low-level sounds similar. And coders may change IPs or use proxy or else. Don't know where Brian or LiraLuna lived many years ago or now. Maybe someone used a similar title that sounds like Brian did it.
Either we have 3 guys who claim having dumps and not publish them or just two or one. Doesn't make any difference. But the more people involved the more strange.
Brian gave some LCD driver facts. Sounds all plausible. However nobody can verify it, like all other stuff without having a dump.
In the Gamekengu emu by LiraNuna there's another coder involved called Dovoto. I also wonder why LiraNuna still searching for games in 2013 but haven't posted anything for a very long period.
Anyway I made a new schematic. Again not every ADR lines connected and the protoboard still needs adjustments.
It's a little difficult to tell due to the rats-nest nature of the large schmeatic, but as near as I can tell, your schematic looks plausible.
My 2nd slot arrived. Soldering is a bit more complicated, but I think I can do it.
Dumping speed is limited to 57600 (max) due to the ATMega CPU. For 512 KB according to other dumps I guess I will need ~1 minute using two 595s. So I think about 2 minutes with 3 shifting devices. I need some latency period (I don't want missing bytes). Detailed speed and functions of the FTDI chips isn't known and there's limited predefined cache. I don't need screen output or status LEDs. Most projects using an Arduino IDE code + an additional code writing the dumped code into a file. But probably this isn't faster. I will order dumping stuff soon.
I would like to test the board and installation before plugging it to the rare carts. 3.3 V and same Gameboy pin pitch.
Is it possible to try dumping a GBA cart? Different pinout is no problem but here we have additional pins, RD, WR, Reset, OW, and 16 bits, different ROM mapping, additonal RAM and maybe other problems. I there a cheap cart without encryption and easy way wiring up and coding? Can I just use some few pins and some ADR lines only and just 8 bit for testing? I don't want to spend another weeks and months with that.
Or LEDs instead of a cart. But I can't read a byte from a LED, just a BIT state. Does this help testing the device?
I don't want to damage more than 2 carts. How sensible is a cart's ROM (for misalignment)? Sometimes carts don't fit properly to the slot. There is one resistor.
Can a blown up cart damage the console?
Mabye dumping the console's ROM with it's built in games is easier and cheaper than rare carts. The console's ROM would also be interesting, but soldering is more difficult here.
Is it possible to dump using a doubled edged or customized DEVcart? But needs making a PCB or destroying another cart. If I have destroyed one I can think about that.
Gamekin wrote:
Is it possible to try dumping a GBA cart? Different pinout is no problem but here we have additional pins, RD, WR, Reset, OW, and 16 bits, different ROM mapping, additonal RAM and maybe other problems. Is there a cheap cart without encryption and easy way wiring up and coding? Can I just use some few pins and some ADR lines only and just 8 bit for testing? I don't want to spend another weeks and months with that.
You could dump a GBA cartridge's NVRAM without changing much other than pinout. Actually dumping the game itself would be a bit of a pain because of the bus multiplexing (A0..A15 are D0..D15 and so you'd need to both drive and read it; as such you couldn't really use a shift register for these pins)
Quote:
Or LEDs instead of a cart. But I can't read a byte from a LED, just a BIT state. Does this help testing the device?
Well, there's two things, right? One is whether your circuit is right otherwise, in which case LEDs are a perfectly reasonable diagnostic device.
The other thing is making sure the cartridge connector is making a good contact; the LEDs won't be useful for that.
Quote:
I don't want to damage more than 2 carts. How sensible is a cart's ROM (for misalignment)? Sometimes carts don't fit properly to the slot. There is one resistor.
I would strongly recommend putting resistors in series with ALL address and control lines. Putting a small resistor in series with power means if the data lines are shorted the ROM will brownout instead of damaging itself.
Quote:
Can a blown up cart damage the console?
Depends on the exact failure mode, but I think it's unlikely.
Quote:
Maybe dumping the console's ROM with its built in games is easier and cheaper than rare carts. The console's ROM would also be interesting, but soldering is more difficult here.
Is it possible to dump using a doubled edged or customized DEVcart? But needs making a PCB or destroying another cart. If I have destroyed one I can think about that.
You should be able to manufacture a new one without too much difficulty, although it will require sitting down with some calipers to measure everything and some layout software (eagle, KiCAD, whatever). Especially since the original games are epoxy blobs, replacing them is going to involve so much rework that a new board is probably easier.
Thanks. That's what I figured.
Dumping a GBA cart is too complicated and doesn't help much. Same for LEDs.
So I have to just try it.
I considered resistors for ADR lines, was not sure about other lines including GND, VCC, SRCLR, CE...
I still don't understand everything including efficient coding and protoboard setup, FTDI drivers, functions and coding, etc.
I doubt that it will be successfull at the first try. But we'll see. At least I know how the header and GFX should look like.
GBA ROM is seek and read. A circuit to dump it is easy to construct: put resistors to GND on A0-A15, set the bank number (A16-A23), select the chip, and read 65,536 words from A0-A15.
Everything is easy (for experts). Probably easier than dumping an unknown glob top.
I even found a GBA dumping project for an Arduino.
http://shinyquagsire23.tumblr.com/post/ ... per-part-1But I want to use an Arduino ProMini with fewer input pins. I want to order dumping stuff tomorrow. Can you give me a list what electronics I need?
Here's a schematic (without Arduino but DSUB and including writing). Needs 8 chips and lots of wiring. Looks too complicated to me.
http://reinerziegler.de/GBA/romcap15.pngI also have to then change the code for dumping, but that's the next thing.
What about 4,2 waitstates (N,S), some games have fewer. What is that anyway, especially N/S?
Aren't there different types of carts? At least different size. So what is the easiest game (without SRAM etc and using upper memory)? Don't I have to know the mapping? Is there a list? Probably the early games.
Gamekin wrote:
But I want to use an Arduino ProMini with fewer input pins. I want to order dumping stuff tomorrow. Can you give me a list what electronics I need?
Er, to dump a GBA game or to dump a Gameking game?
To dump a GBA game you're going to need 16 bidirectional lines, period. If you want something like your current design, you can only use shift registers if you find ones that can be switched to high-impedance ("three-state") such as the 74HC299 or 74HC595. The arduino will now need to additionally control the /OE line, and you'll also need a parallel-in-serial-out shift register (such as the 74HC165) to read the data back from the GBA.
The other design you could implement is much like this one you linked to:
http://reinerziegler.de/GBA/romcap15.pngMost of the weirdness of this link has to do with constraints of the IBM PC parallel port (8 outputs, 5 inputs, 4 bidirectional lines).
You could replace the two 74HC157s and one 74HC257 with two 74HC245s, and use the 3V microcontroller directly in lieu of the 4th 74HC574, ending up with a system that will take 5 ICs, and 16 I/O lines on your microcontroller. (8 data, 3 latch enables, 3 output enables, /RD and /CS to the cart)
Quote:
What about 4,2 waitstates (N,S), some games have fewer. What is that anyway, especially N/S?
N/S is "non-sequential" and "sequential". Nocash mentions it here:
http://nocash.emubase.de/gbatek.htm#gbasystemcontrolBasically, these are the number of cycles, where each cycle is 2^(-24) seconds, that you have to wait
N) from "writing new address" to "reading out new data"
S) from "after reading previous data" to "reading out next memory location"
The overhead of using shift registers is going to be an order of magnitude slower than the GBA cartridge waitstates, so you wouldn't need to worry. (Even if you use the latch design, you're still probably just fine)
Quote:
Aren't there different types of carts? At least different size. So what is the easiest game (without SRAM etc and using upper memory)? Don't I have to know the mapping? Is there a list? Probably the early games.
As far as I know, they're all the same? Almost none of the GBA games seem to be particularly small: the smallest games seem to be the NES emulator ones, at 1MiB. After that, 4MiB or bigger.
The vast majority of GBA Game Paks are 32 megabits (4 MiB) to 256 megabits (32 MiB) in size. There might be one that's bigger (such as the rumored Shrek and Shark Tale GBA Video), but I haven't seen evidence that that ever made it to market.
Why would bidi lines be needed for dumping a GBA Game Pak? They'd just need to be input lines with pulldowns because the ROM chip will auto-increment the address after each read. So start reading at address 0 of each 128 KiB bank and read 65536 words (128 KiB) at a time.
Yes, I meant GBA. The Gameking stuff I already knew. I used 3x74hc595 .
Thanks. But I think that's all too difficult for me. I had to know exactly how many chips each and other stuff I need. And without detailed description, schematics and code I can't do that.
In the MESS SRC there are about 100 special carts at least involving special EEPROM behavior. I can't believe that there are more different GB cart types than GBA.
I now have already ordered all dumping stuff and will try it then directly with Gameking carts.
Soldering the upper slot is getting more and more difficult with my cheap iron and stiff wires. There are holes on top of the slot edge but wires won't keep sticking and I can't solder to gold.
So I also solder to the lower socket but can't bent every other one as I need to put every pin on the cart pins. I don't want to use the usual socket connectors for the upper pins. I think 2 slots don't fit 1:1
or the PCB is too thin. I probably have to push the upper slot to the cart pins (without misalignment) so I need for a fast dumping speed of 1-2 minutes which I thinks is possible.
Any hints about dumping speed or improving the code or slot construction is appreciated.
Gamekin wrote:
Thanks. But I think that's all too difficult for me. I had to know exactly how many chips each and other stuff I need. And without detailed description, schematics and code I can't do that.
You could build a GBA dumper using three 74HC595s and two (or three, I guess, if you want to support reading save memory too) 74HC165s.
Tepples also makes the valid point that, in practice, the dumping process is just going to read each 64KiW plane in sequence, so you'll never need to write anything but 0 to the lower 16 bits, and you could probably replace two of the three shift registers with pull-down resistors.
Anyway, I would really rather you ask "is this right?" rather than "please give me a design". I feel that the latter encourages dependence and discourages learning.
Quote:
In the MESS SRC there are about 100 special carts at least involving special EEPROM behavior.
As far as I understand, those all have to do with how games save, not with how the game itself is stored. I think you don't need to care about that.
Quote:
Soldering the upper slot is getting more and more difficult with my cheap iron and stiff wires. There are holes on top of the slot edge but wires won't keep sticking and I can't solder to gold.
Maybe try using thin (32ga) wire and a wire-wrap tool? I've found it very useful for this kind of problem. If you're wrapping around something that's not circular in cross-section you may not even need to solder.
Quote:
so I need for a fast dumping speed of 1-2 minutes which I thinks is possible.
57600 is 5760 bytes per second, so in two minutes you could dump about 690KB. Having not used the arduino environment, I have no idea why they're not allowing you any faster speeds.
Quote:
Any hints about dumping speed or improving the code or slot construction is appreciated.
Can you post a picture of the slot? I might be able to take a guess as to how to modify things to work better, maybe.
No need for more GBA discussion. It would take many weeks or months to study and ask a 100 times "is that correct?"
My project is not about the GBA. I could spend some more hours by searching for projects or existing schematics (I can't invent something new) but that has nothing to do of how to learn.
I think someone can learn by reading and trying it. Reading, understanding and even finding what to read takes much time. And studying is risky and expensive and could destroy things without having someone near me.
Same for soldering. You read and try.
I read about alternatives and also about the wire-wrap. Probably I have the wrong wires, but I think I could manage it.
Yes, I could buy an expensive soldering station and books how to solder and try some more. Yes it would be better and I learn more. But for a single project, I've spent enough time and money already.
According to the datasheets the AtMega of the ProMini is limited to 57600 baud. As I don't need 4 games, I think I will try to read 178 KB or a bit more only. I hope to dump that in 25 sec.
Do three 595s take 33% more time than two or no delay at all as I need some latency anyway?
I also need to unplug the voltage soon after dumping (someone else has to pull the USB cable or else). I don't know if the serial output then disappear. So better also writing to a file. I haven't found a buil-in function for that.
Now my slot pics. Probably someone else would learn of how to not do it.
An ordinary GBA slot x2. There are enough pics on the web.
Different technique for the upper slot. I have to make sure to correctly align and keep the cart to the lower slot and then attach or hold the upper slot with the silver socket pins to the upper cart pins.
Otherway I can't see through it. And attaching the 2 slots to build one real slot probably doesn't work. Cart is too thin and there are 32 pins and I have to make sure that cart pin 1 is on slot pin 2.
Gamekin wrote:
According to the datasheets the AtMega of the ProMini is limited to 57600 baud.
... Oh, ugh. Right. The 3V ProMini runs at 8MHz, and is an ATmega168, so the only clock speeds you can achieve are integer divisions of 1MHz.
Now, some serial ports can be run at 500kbit or 1Mbit, which would help nicely with doing things (a lot!) faster, but I have no idea whether your OS will let you get those other rates. For later consideration, I suppose.
Quote:
Do three 595s take 33% more time than two or no delay at all as I need some latency anyway?
At 57600 baud, you're only going to be able to send a new byte once every 174µs. The overhead of the shift registers are tiny in comparison—probably somewhere around 10µs or so. Same with the 5µs settling times the software you already posted uses.
Quote:
I don't know if the serial output then disappear.
It depends on the specific serial program you're using. I guess I remember old versions of Windows 95 Terminal would die horribly when their associated serial port went away... but I have no idea what current best practices are in the windows world. (I usually use minicom in linux, just because no-one else much cares)
Quote:
I haven't found a built-in function for that.
Built in to what? You could probably do something like
copy com15: output.txt or
cat /dev/ttyUSB0 > output.txt from a terminal, depending on OS.
Quote:
Now my slot pics.
Oh, I understand now: the problem is that the GBA sockets are right-angle offset surface-mount things, and the gameking isn't. So you're going to have to either bend all the leads back and cut off even more plastic, or cantilever things funny.
Hm. So what we want here is some kind of alignment jig that will make sure all the pins are correctly in line, and hopefully hold the two connectors at the angle such that they all make contact.
Maybe you could try getting two small pins or nails hot and melting it through the plastic on the ends? Or drilling two small holes and guiding down the connectors on pegs, which would additionally allow you to just press down on the entire assembly to make good contact?
Do either of those ideas sound practicable?
The current ProMini is an Atmega 328. I read about problems someone had using the default 115 kbaud. But as I now will try reading just 178 KB I probably won't have a speed problem.
I have Ubuntu and Windows 7 but I will better try it on Windows using the Arduine IDE. So I meant a built-in function there. Is it that easy to just use "copy com15: output.txt"? I wonder why people writing separate, external code for that and using the Arduino IDE and another code. I haven't studied much about the FTDI USB drivers and functions and timing issues. I have downloaded the driver but not installed as I don't have the hardware yet.
I don't know how the Gameking slot looks like. Obviously similar. Just 2 rows. Even if I had one, it would be the same problems with soldering. But of course no problems of pin alignment.
Thanks for your ideas about the socket. I have to think about that. It isn't easy. I think I better need some attachment at least at one side to make sure that the cart will stay on the right pins. At least for the lower slot.
Gamekin wrote:
The current ProMini is an Atmega 328. I read about problems someone had using the default 115 kbaud.
Unfortunately, same problem. Both the atmega328 and 168 use the same "master clock divided by 8 divided by a number of your choosing", so the best you can do with an 8MHz master clock is going to be 111kbaud, which is just a little slower than is expected to reliably work (it's more than the 3% error that RS232 is robust to).
I don't see a crystal, so it's got to be using Atmega's internal oscillator. In the category of Advanced Techniques, you could adjust the Atmega's internal oscillator (by writing to OSCCAL) to be slower enough to match. (If you can tune it to ≈8.3MHz or ≈7.4MHz you could get the 115200 baud rate to work fine. In practice you should be able to calibrate by sweeping over the range of 0 to 127 or 128 to 255 and sending the byte "U" over the serial port, seeing what are the fastest and slowest values of OSCCAL for which "U" is correctly received all the time, and splitting the difference.)
Quote:
I have Ubuntu and Windows 7 but I will better try it on Windows using the Arduino IDE. So I meant a built-in function there.
Oh, in the Arduino IDE. I have no idea, sorry.
Quote:
Is it that easy to just use "copy com15: output.txt"? I wonder why people writing separate, external code for that and using the Arduino IDE and another code.
You'll still need something to configure it to use the right baud rate, like HyperTerminal or something. There also seems to be a port of Minicom to windows, which will probably also work.
In linux, I've been doing the equivalent by opening the serial port in Minicom, quitting minicom without resetting the serial port (ctrl-A, Q) and then cat /dev/ttyUSB0 > file. I have no idea if Windows will let you leave the serial port settings unchanged when the serial software quits, but I remember HyperTerminal as having the ability to do "ASCII" downloads, which should also work.
Windows or HyperTerminal might also do some standard CRLF munging (by which I mean replacing byte 13 with two bytes 13,10 unless it is already two bytes 13,10) No idea. :/
lidnariq wrote:
You'll still need something to configure it to use the right baud rate, like HyperTerminal or something. There also seems to be a port of Minicom to windows, which will probably also work.
On Windows, the
mode command should do the trick (
http://www.microsoft.com/resources/docu ... x?mfr=true).
I don't understand why I need a Terminal software and manual baud setting. There's is a serial output window in the Arduino IDE and I hope the FTDI board will use the right USB baud setting according to the code. Dead Microsoft link.
As I still had problems building the cart adapter (I had almost finished that, then using other, thinner wires from a floppy cable) but it was also hard to solder and wasn't very stable. No problems soldering the header pins to the Arduino.
But now I have ordered another console with a single cart game also, and so I will use that cart slot.
Is it possible to leave the cart slot inside the console and to solder wires in there? I probably have to disable at least one power lead to the CPU (how and where ?) Anything else? No batteries but the system would then be powered by the Arduino.
Or is there a better way to dump from the running CPU or elsewhere?
Here's the PCB of the console
http://wiki.portablegaming.de/Der_GameKing_von_innenOr better desoldering the slot. But soldering would be much easier to the PCB.
Gamekin wrote:
There's is a serial output window in the Arduino IDE and I hope the FTDI board will use the right USB baud setting according to the code.
I recently helped friend-of-a-friend with this: this described functionality did not work for him. This may well be why other Arduino-based dumping projects have all sucked it up and used 9600 baud.
I also wouldn't be surprised if the Arduino IDE set its baud rate somewhere else altogether.
Quote:
Is it possible to leave the cart slot inside the console and to solder wires in there? I probably have to disable at least one power lead to the CPU (how and where ?) Anything else? No batteries but the system would then be powered by the Arduino.
No, there is no way to disable the CPU. Even if you try to remove power from it, you'll now power it through its address and data lines, so that's simply not possible.
Quote:
Or is there a better way to dump from the running CPU or elsewhere?
You could get a (very expensive) massively parallel logic analyzer, and hook it up to all the data and address lines, and play through the game. But you wouldn't be able to dump any data that the game didn't use.
Quote:
Or better desoldering the slot.
You could try a heat gun, with some heat shielding to protect the other components. Or if you can find a (friend with a) desoldering station...
Yes, I also wonder why most using 9600 baud. I know the the FTDI chip functions are unknown. But now with a real slot I don't have timing issues anymore.
There must be a way to use the slot still on the PCB. I don't care about the 2nd console. I could even cut it out and cut away all other PCB parts, but these soldering pins are probably much better than to solder wires manually to the slot pins. I don't know what is the pitch and if there's a board available with that.
I don't know exactly how the slot looks like at it's bottom. There are 4 rows (2x2 each side) with shorter and longer pins. Maybe there are even hooks or holes. Maybe it's possible to attach the wires better to those shorter and longer pins but I have to wait till it arrives.
Gamekin wrote:
There must be a way to use the slot still on the PCB. I don't care about the 2nd console. I could even cut it out and cut away all other PCB parts, but these soldering pins are probably much better than to solder wires manually to the slot pins. I don't know what is the pitch and if there's a board available with that.
If you are willing to destroy one, then yes, cutting it out will work fine. Removing both epoxy blobs should also be effective.
You'll still get a nicer (and reuseable) result if you can find a desoldering iron or heat gun or possibly even a blowtorch.
Here's some reference material:
Desoldering using a plate full of rubbing alcoholDesoldering using a heat gun
I almost did it with the new slot. Desoldering took 3 hours. I couldn't find my sold absorber. I don't have a heat gun and didn't want to try it the other way at open fire.
Almost everything attached, 4 wires missing, it was very stable but the wires are thick and heavy (what has pro and cons) but I didn't know how to stick that to my breadboard. They are also too short. Soldering to aluminium now worked.
And the slot construction would make it very difficult to later change the cartridge. So I desoldered again all wires and first have to built a more stable and upright construction.
I'm running out of long wires and maybe they shouldn't be much too long or connected multiple times. I will try to measure and bend the wires before soldering now or maybe use again a floppy disk cable.
Maybe female jumper wires would fit to the slot pins? But either pins or black tubing might be too thick for the neighboring pins. I also don't want to spend much more money (at least nothing expensive for stuff that might work, then wait and test again and pay again shipping costs).
I will try it somehow but it turns out more and more, that I maybe can't manage that. At least not on my own.
I also found some mistakes on my breadboard and also in the code.
Any more advice?
I now have attached the slot to a wooden box.
Currently I'm building the wiring including one or 2 harness adapters which is a combination of a floppy disk cable and thicker wires to better plug them into the breadboard.
I doubt that this will work. The wires in the floppy cable are very thin and break easily. In total 34 long wires are needed and that's quite heavy, difficult to hold and solder. Maybe I would need another construction to lift and hold up the wires.
Probably this is my last try.
After that I have to search for someone with more skills who is willing to cooperate and where I can send my slot (and carts). I probably would need help writing an emulator later anyway.
Gamekin wrote:
or maybe use again a floppy disk cable.
I've found that tinning the wires in such a cable has worked very well for me.
Quote:
Maybe female jumper wires would fit to the slot pins? But either pins or black tubing might be too thick for the neighboring pins.
Well, you know what the pin pitch is, so you should be able to calculate whether they'll fit, right?
AIUI, the Gameboy pitch is 1.5mm, and it looks like the connector for the gameking has alternating offset rows for both sides, so there should be 3mm between pins. I would think that anything bigger than 0.1"=2.54mm should be safe for ordinary female jumper wires...
although you probably should measure the dimensions of the pins where they came out and make sure the jumper wire connector will fit over it.
Gamekin wrote:
The wires in the floppy cable are very thin and break easily.
How much weight are you putting on them? They're not really meant to support things, just conduct electricity...
Quote:
Maybe I would need another construction to lift and hold up the wires.
But that's probably a reasonable workaround.
Soldering some of the thin floppy wires worked much better than thought and better than on the previous slot as this slot was soldered to the PCB and isn't new. Although it's very fragile and I don't know if I can manage 34 wires. Maybe I need 2 floppy cables for the 4 rows.
The wiring construction including harness, thicker long wires and base is heavy and fragile. A floppy cable alone is heavy. Maybe I can't move that construction including the wooden box and have to carry the PC and monitor to where I'm soldering.
Another problem is that wire 1 is not near pin 1 on the breadboard but at pin 60. I turned it over and first considered the box upright and bending the wires over. Maybe I better would have started from the breadboard.
Maybe I build a 2 story or angled construction from the other side of the breadboard. Can you imagine 34 thicker wires next to each other? 3 or 4 times as wide as the floppy cable. The 60 pins on the breadboard are also aligned in one long row (so one complete board wide).
I don't know how thick a pin is and what the distance is. Some pins are also bent and have some solder on it. Maybe the jumper wires fit but don't know if they would keep sticking. The pins could also be too short.
In 1 or 2 days I will know if it all works. I hope the code is OK. I don't know if it all would be stable for more days.
I give it up.
Look to the photos and you see why.
First the thin drilled wires often undrill and the tin hardly sticks. The tension and force of the other wires are too big. One soldered, 2 got loose. Either break off or get in contact with the tin of the neighboring pin or the iron.
Then I tried it with a 2nd harness adapter. No big problem soldering the copper wires to the thinner wires due to the different material. And the copper wires also can be soldered much easier to the slot pins.
Same problem with the tension forces. I also have problems with the tin temperature (often not fluid enough) and I would need a 3rd hand. No problems soldering the Arduino header pins.
The outer rows are quite easy as you can solder them to the side. But not with 4 rows. At some points I have less than 1 mm. I can't solder that with my equipment and skills.
I also have too many bridged connections and I doubt that everything is still on the right place.
I'm more and more destroying the slot. The 2nd console is also destroyed during desoldering. Soldering onto the PCB was much easier, but I couldn't cut it out as there was a glob chip on the rear side at the same place.
I need somebody who can do that for me. Either in my neighborhood or I have to send slot and games. Better than I would ruin my carts.
Gamekin wrote:
I need somebody who can do that for me. Either in my neighborhood or I have to send slot and games.
Do you know of any
hackerspaces near you? I think they should have people able to help you. I'd offer to help, but it feels like there should be better options than sending something halfway around the world.
Thanks very much for this link.
There are 2 or 3 in my region.
One needs to pay an annual membership.
Others seems to be universal meetings (and also have quite high fees). And one is more far away. But I will check them.
Probably there are much more people with soldering skills in my neighborhood.
And one meeting is obviously not enough. Multiple travelling costs are also expensive. So shipping would be better.
I won't ship all my games to someone I don't know at all to a different country.
Gamekin wrote:
One needs to pay an annual membership.
Others seems to be universal meetings (and also have quite high fees). And one is more far away. But I will check them.
I bet you could reach out for help without having to pay a membership fee. Or at least, not having to pay it until they've established whether they can/will help you.
I finally have attached all wires. Even without soldering. I bought thinner ones and plugged them into the slot behind the cart.
No data are displayed on the PC. I tried 57600 and 9600 baud.
Probably the code is wrong.
The arduino interface to upload code uses the same serial port, right? So you wouldn't be able to flash it if that part if the serial part wasn't connected correctly?
Looking back at your code, I'd arbitrarily guess you aren't successfully initializing your serial port (i.e. calling read_data_bus) before staring the dumping routine (loop) and so it's waiting forever at while (Serial.available() <=0){
Yes, it's the same port. Uploading the sketch obviously worked (according to IDE and some lights flashing).
I don't know how to correctly initialize the port. And I don't have experience with Arduino programming.
As said I have copied the code from other projects.
I changed "while Serial.available() <=0" in >0. Same problem.
I also don't know if the setting of parity and stop bits, flow control etc are correct. I haven't found anything about that. It's somehow serial to USB convert.
I have obviously destroyed my dumping device. So that's the end.
Someone said, I would need a connection to OE.
I was pretty sure that this only can be pin 46 (S3). I put that to GND (using a resistor). After that the FTDI board wasn't recognized anymore. No COM port.
Device Manager code 43 (Unknown device). I read that could mean that the front USB hub was busted But I also checked the rear one and on a different PC).
I tried to remove and reinstall the drivers automatically and manually and tried every FTDI tool including deleting the vendor ID. It could also have been destroyed for some other reason.
If I had a working code at the beginning, it might have been worked.
Thanks to everybody who tried to help.
Maybe I will find someone who has more skills and some hardware or maybe there will be someone else who read this and trying it himself.
Even if I had a dump, someone said that writing an emulator would be extremely difficult.
I currently trying to write a simulator of my favourite game.
First I tried it for Gameboy. But I had problems with the map tool. Always displayed wrong. Music and sound effects would also be a problem on the GB. Many tools disappeared. I tried some software on the C64. But it's also quite difficult and slowly. Shooters could maybe be written using SEUCK. Or it's possible just changing the GFX and sprites from other games.
Currently I'm using tools on Windows. Also few good (free) software for that.
I now made a simulation using openBOR about my favourite game galled Terminator what is a Double Dragon clone. Not completed yet, 1 level only.
You have to sign up at chronocrash to download it from there.
There is a fighting game what can be made using mugen. And the platformers can also be made quite easily. The 194x shooters are very simple and I don't like them.
It's not the same as real emulating but it's at least possible to have a feeling what the console, some games and sound is like.
Now Porchy from JAMMArcade.net has dumped some games. He owns 13 games, looks like no multi carts.
He used female (?) jumper wires to attach to the slot pins and 74HC4040. To me it doesn't look like if they are enough wires. And on the upper slot pins row he has 2 rows of jumpers attached, I wonder how he had managed that (PINS bent? Soldered?) Oh, I forgot. There are 4 rows.
But he claims to have dumps and saw all the game graphics. Nothing much shown other than the previously known header data.
He also doesn't have released the ROM contents and he obviously can't write an emulator.
But there is at least hope, that he donates the ROM data to MESS or somewhere else.
If I had detailed schematics, complete PIN layout and dumping software, I maybe retry it with my multicarts or maybe send my carts. But without an emulator it doesn't make much sense, except for having all graphics and maybe find the sound data.
Does anybody know him? Or can post this on the MESS forum?
http://www.jammarcade.net/dumping-gameking-cartridges/
Gamekin wrote:
But without an emulator it doesn't make much sense, except for having all graphics and maybe find the sound data.
Can't make an emulator without (at least) known-good software, and preferably the ability to program tests.
I don't understand.
How to start any other unknown emulator project?
The person who dumped and connected it, knows the software, the game. And can test and compare it. Otherwise it won't be possible to write any emulator for unknown stuff. Or need for in-circuit testing?
The ROM data consists of 6502 code, GFX and sound and maybe some other data and logic tables.
If you have the GFX, what is the case and can also extract the uncompressed music and sound (not done yet?), the rest must be the gaming code what is probably very few parts of the data.
There are some more bytes now dumped than the length of the previously known original header from Brian but the few bytes look like some more GFX, maybe a logo, and the few bytes don't help much.
I have to check the data with Brian's GFX tool and compare to 6502 code.
Dumping is the first step. And identifying and extracting the complete GFX and sound is very important. Even if you don't have the code, you can try to simulate and play with the GFX.
GFX encryption is fully known, Sound should be uncompressed 6 KHz. What else is needed?
At least he managed to dump them. Knows the correct PIN layout, dumping software using an Arduino and some more details previously not known.
We know that the Gameking uses a 65C02. We don't know how the game writes configures the sound hardware, or how it works, or where in memory it is. We don't know how the display is accessed, configured, or anything else. We don't know how it accesses the more-than-64KiB of data on the cartridge, or how it reads the joypad.
All of this information can be determined either from the manufacturer, looking at existing games, or by exhaustively trying tests until it does something, in order of increasing frustration but also accuracy.
If you could get kevtris (visit #nesdev on efnet) interested in this device it would be reverse egineered in a relativley short time span.
EDIT: After a quick google search, seems it is on his TODO list, but also, he says:
Quote:
..it's all bit mapped. The biggest problem though is the games were very poorly coded. I looked at some game code and it's horrible, and appears it might've been compiled. I was thinking of adding Game King but I have no documentation or anything.
Unlicensed NES game developers had to do the same things. Starting with only ROM pinouts, they dumped old NROM games, looked at the bytes, realized it was 6502, and followed from the reset vector to see what was going on.
Quote:
We don't know how the display is accessed, configured, or anything else
BriPro gave very detailed infos about how the display works.
http://web.archive.org/web/200710250643 ... page=videoThe sound should be uncompressed maybe ADPCM. Of course some details are not fully understood.
Thanks Movax12 for your info about the TODO list.
If I knew that before that it is so difficult, I could have saved lots of time and money.
The ROM data would be of interest anyway. At least you can extract all the GFX including sprites.
5 months after Porchy dumped some of the games, we have a skeleton driver in MESS with some few new details.
So work is going on. I wonder why he hadn't used all the tech infos from BriPro that is already known.
Maybe someone will dump the system BIOS (including the 3 games) or try writing some homebrew stuff.
So it maybe isn't / wasn't that difficult and in the near future we will have an emulator.
Later more games needs to be dumped.
Why isn't there an easy-to-use dumping unit for sale so people can legally dump and backup their games?
Maybe one day there will be even officially licenced games available for PC or mobile.
Gamekin wrote:
So work is going on. I wonder why he hadn't used all the tech infos from BriPro that is already known.
Probably because BriPro pulled all his reverse engineering docs off the web to satisfy requirements placed on his game studio Vblank Entertainment, developer of
Retro City Rampage, by the curators of modern video game platforms.
I mean the stuff that is still available like this one
http://web.archive.org/web/200710252004 ... age=video3And the Graphics Editor must be very useful. The src is also available.
I don't know if he actually owns the handheld itself. He should be able to extract the sound as well or at least record samples.
Sound and music is probably the most of the data.
A bit of a necrobump, but I figured I'd post this here. I have completed reverse engineering of the Game King, and have posted my findings here:
http://blog.kevtris.org/blogfiles/Game% ... Inside.txtAlso, I have a video of it running on my FPGA:
https://www.youtube.com/watch?v=uezaEUitUJ4
Thanks very much for the info and all your work!
I knew that an expert with the skills and hardware can do it.
Unfortunately it still doesn't work in MAME but probably it will run soon with all that info.
The 2nd video is even more interesting.
Most of the games have been dumped including the 4in1 Multi-ROM-Cartridges and the system BIOS with the 3 games.
Just some few things to go. And the GameKing 3 color games ...
Personally, I almost forgot it and am busy with something else.
All games are very difficult and you can't play very long with this device and that poor graphics.
More fun than playing is maybe the emulation work and developement of homebrew games.
kevtris wrote:
A bit of a necrobump, but I figured I'd post this here. I have completed reverse engineering of the Game King, and have posted my findings here:
http://blog.kevtris.org/blogfiles/Game% ... Inside.txtAlso, I have a video of it running on my FPGA:
https://www.youtube.com/watch?v=uezaEUitUJ4Oh, nice work!
Now how long until we get Game King III emulation? :D
byuu wrote:
Oh, nice work!
Now how long until we get Game King III emulation?
Send me one and I'll do it. I looked for one for awhile on ebay but one never showed up. I suspect if it did the cost would've been $300+. I had this problem with the Gamate and someone graciously donated two to me with some games, so I was going to do some videos on that as well (and reverse engineer it and add it to my FPGA too).
Makes me wonder about Brick Game too (though I don't have one at hand), although that one is a lot more annoying in that games didn't come in separate cartridges so there are a ton of models that just happen to have different games and with tons of minor variations over time. The hardware seems pretty neat though as far as working properly goes, and they even implemented a suspend feature before any of the major handhelds did (power off while paused, the game will be restored on power on)
Sik wrote:
Makes me wonder about Brick Game too
I always wondered how those things worked! Last time I checked they were selling for only US$3 or so!
Eh,
just started a separate thread for that. I doubt it'll get very far though...