Gameking

[Gamekin]

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.

[lidnariq]

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.

[Gamekin]

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.

[lidnariq]

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)

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.

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.

Can a blown up cart damage the console?

Depends on the exact failure mode, but I think it's unlikely.

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.

[Gamekin]

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.

[tepples]

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.

[Gamekin]

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-1

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?

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.png

I 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.

[lidnariq]

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.png
Most 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)

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#gbasystemcontrol
Basically, 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)

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.

[tepples]

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.

[Gamekin]

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.

[lidnariq]

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.

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.

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.

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.

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.

[Gamekin]

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.

[lidnariq]

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.

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.

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)

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.

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?

[Gamekin]

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.

[lidnariq]

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.)

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.

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. :/