GBALdr 0.1 beta 5 Released

moshii · Apr 28, 2007

QUOTE(cory1492 @ Apr 28 2007 said:
Trying to read past 32MB is kind of pointless

If you read past the size of the mask rom inside the cart you start to get a nice pattern based on part of the 24bit address you've requested.. If you know that you can detect the size of the mask rom within the address space. So much for dropping hints

It looks like this.

NB. If you read past the first 32MB you'd see the ROM again. There are two mirrors of the ROM after the first copy with different waitstates.

moshii · Apr 28, 2007

QUOTE(Bloodiator @ Apr 28 2007 said:
is there a way to use the gbaldr with the opera memory expansion pack?

If you have a cheat device that lets you do (lots of) ROM patches you could... the problem is that the GBA expects the cart to be at 0x0800 0000 the Opera carts memory starts at 0x0900 0000 and there's no way of telling it to look there instead. If you had a cart that did rom patches you could patch the rom header in at 0x0800 0000 and a branch to jump up to the start of the opera memory.

cory1492 · Apr 28, 2007

Ok, I have never been a huge fan of programming on GBA (aside from trying to reverse certain flash carts stuff), but I do know a couple things. Aren't non multiboot GBA files statically linked (meaning a patcher would have to basically reassemble the entire thing to make it work at a different address).

QUOTE(moshii @ Apr 28 2007 said:
NB. If you read past the first 32MB you'd see the ROM again. There are two mirrors of the ROM after the first copy with different waitstates.

From DS mode... really? From GBA mode what you say holds true... but we aren't creating a "to slot 1" dumper in GBA mode

http://nocash.emubase.de/gbatek.htm#dsmemorymaps
CODEARM9...
Â08000000h ÂGBA Slot ROM (max. 32MB)
Â0A000000h ÂGBA Slot RAM (max. 64KB)

ARM7...
Â08000000h ÂGBA Slot ROM (max. 32MB)
Â0A000000h ÂGBA Slot RAM (max. 64KB)

0A000000h (SRAM) - 08000000h (ROM base) = 2000000h = 33554432 = 32MiB (aka 32MiB from base before you reach backup RAM area - meaning in DS mode it is quite pointless to go to addresses beyond that)

If it actually was that simple to detect the end of the mask using that method (for all games), there wouldn't have been so many overdumps (though it could well account for some of the underdumps too).

moshii · Apr 28, 2007

QUOTE(cory1492 @ Apr 28 2007 said:
Ok, I have never been a huge fan of programming on GBA (aside from trying to reverse certain flash carts stuff), but I do know a couple things. Aren't non multiboot GBA files statically linked (meaning a patcher would have to basically reassemble the entire thing to make it work at a different address).

IIRC a lot of ARM code is relocatable and branches aren't direct but depend on the PC. A patcher wouldn't be too hard to make either... and if you had a decent cheat cart you could rewrite addresses as they are coming in and out. But that would be a lot of work for such an ugly contraption.

QUOTE said:

If it actually was that simple to detect the end of the mask using that method (for all games), there wouldn't have been so many overdumps (though it could well account for some of the underdumps too).

The screenshot provided is from dumps done in DS mode from two original carts (Duke nukem US and GT Chapionship) to an R4DS. The pattern that comes out when overdumping is something that comes out of the cart's address decoder logic from what I can see. I think the same thing happens when dumping from a real GBA using my multiboot dumper but I'll have to charge some battys and dig my xboo cable out to confirm that.

QUOTE

Click to expand...

0A000000h (SRAM) - 08000000h (ROM base) = 2000000h = 33554432 = 32MiB (aka 32MiB from base before you reach backup RAM area - meaning in DS mode it is quite pointless to go to addresses beyond that)

Yeah, I was thinking for the GBA that uses different addresses spaces for the different waitstates. the NDS has the memory control register to set that... still I said nothing about reading beyond the 256mbit GBA address space... if you read within that space but above the end of the actual mask rom you *don't* get 0x00 or 0xFF like the mask rom padding.

moshii · Apr 28, 2007

Ok... confirmed, there's screenie of the overdump directly from a GBA here.
You can see the output still coming out of the xboo software.. it takes a while to fully dump 256mbit on a gba :/

Sebokie · Apr 28, 2007

This whole dumping thing is interesting, are you planning to code a ds dumper as well?
Could you please link me to any documentation regarding how to read/write to slot 1 and slot 2?
Anyway, thanks for your work.

H8TR · Apr 28, 2007

I think I found a bug. I wrote the GBA SMW rom but never played it. When I went to change the rom on the 3in1 to PKMN Emerald it erased the NOR and restored the PKMN Emerald rom. When it came time to back up the SRAM for SMW, it froze. I'm assuming it did because there was nothing in the SRAM to restore (I had never started the game). BTW, the Pokemon Emerald did start. All I did was turn off the DS and start the game worked.

-EX- · Apr 28, 2007

One more skin, I hope you like this one. All fonts and other stuff colors are changed, GBA frame included as well.

cory1492 · Apr 28, 2007

Thanks for another skin for it -EX-

You guys want a copy of the stuff I used to take the screenshot in no$?

QUOTE(moshii @ Apr 28 2007 said:
Ok... confirmed, there's screenie of the overdump directly from a GBA here.
You can see the output still coming out of the xboo software.. it takes a while to fully dump 256mbit on a gba :/

Funny thing being, in all of your examples so far I have seen a block of 0xFF or 0x00's right before the 16bit incrementing sequence

at the same time, in the past I have also seen my own dumps repeat the game header (sometime multiple times after ROM end) - though I could well be thinking of dumps I did from non-retail cards...

edit:/ OK, using my dumper I have now tested 6 of approximately 20 of my own games, and so far your mask has shown up in 100% of them. I'm thinking the games I had that gave different data are ones I passed on to a friend ages ago, which were as far as I know HK knockoffs.

Sebokie: http://nocash.emubase.de/gbatek.htm
AFAIK there is no "step-by-step" guide on how to dump unless you are using an already existing program.
QUOTEare you planning to code a ds dumper as well

Eventually, there is still a lot I don't understand and I'd need to track down a couple of the "hard to dump" carts. Needless to say, it has been something I have been fiddling with off an on for the last 2 years... I do currently have code that can dump anything DS I want (worked with supercard and neo2, dumped R4 as well as all the DS games I have reliably), but it is basically just a modified version of fwnitro 1.3c (meaning it has to replace the DS' firmware).

Sebokie · Apr 28, 2007

This is indeed interesting, I assume you have to use ASM to read from slot1/2? And is there a decryption algorithm you need to use for ds games?
I would be quite interested to see some (commented) code of a dumper, although I currently am not very knowledgeable.

cory1492 · Apr 29, 2007

QUOTE(Sebokie @ Apr 28 2007 said:
This is indeed interesting, I assume you have to use ASM to read from slot1/2? And is there a decryption algorithm you need to use for ds games?
I would be quite interested to see some (commented) code of a dumper, although I currently am not very knowledgeable.

- ASM? Why would you need that? It might be more efficient but... GBA is just memory on a 16 bit bus and DS ROM is a serial device with a control register and a data register.
- decrypt? if you replace the firmware you have the header and decrypted secure area in memory from the BIOS startup (just like the DS does when you press "start DS game"), and the DS cart is already in "mode3".
- so would I. Let me know when you have it done

I have been nibbling at it (time and patience permitting) for 2 years and I still don't have the understanding to create a 100% working method that doesn't involve replacing the firmware. Nearly everything one would need to do so is contained in the link I gave you, (stepping through from reset and getting the header to putting the cart into mode 3 and dealing with the crypt along the way) though implementing some of it can be wrather confusing (especially for someone who is essentially a hobbyist programmer who taught themselves in rare spare time... like me).

At any rate, this (mostly) is far off topic and completely irrelevant to GBALdr. I did post a snippet that can be used to dump data off the GBA bus (aka: the GBA game ROM) previously in this thread, there is very little to comment as it is basically just reading 16bit memory sequentially and is best suited to ensuring proper writes were done to the 3in1.

scrawl · Apr 29, 2007

Cory1492 said:
You guys want a copy of the stuff I used to take the screenshot in no$?

I believe the phrase "hell yes" is appropriate in this particular situation.

Sebokie · Apr 29, 2007

Sorry cory1492, i didn't mean to bother you, I'm just curious, I guess I'll look at the fw Nitro's source code

cory1492 · Apr 29, 2007

QUOTE(scrawl @ Apr 28 2007 said:
I believe the phrase "hell yes" is appropriate in this particular situation.

gbaldr_b6_emu.zip (not actually beta 6, but it may as well be)
Instructions included, the dldi is already FCSR you just need to get the image building stuff from GPF's site, add it in and use the supplied bat file (it's fairly simple if you know any command line stuff, too). The FAT12 image building process on windows is somewhat "fiddly" and can be a pain in the butt, but adding/removing files of varying sizes and retrying seems to cure it... eventually (either the image building process or the FAT init process can both be bunged up by a odd image). With just the files included, I have not been able to get a working image, but when I add a 4M GBA dump to it it seems to work great (I also tried a 4M dummy file, but that didn't work at all).

Sebokie: no biggie (it's not a bother, if it was I would have ignored it in the first place).

scrawl · Apr 30, 2007

Working nicely, thanks for that.

I thought you might have been doing your screenshots via Dualis and using the GBAMP DLDI driver.

I understand now why I could never get it to work.

poloman · Apr 30, 2007

my 3-in-1 just arrived - i'd prepped my r4 yesterday. slapped the (slightly bulging) 3-in-1 into my ds, powered up, loaded up GBALdr. copied advance wars 2 over, then rebooted and played.

3-in-1 and GBALdr (plus scrawl's blue skin) in a word: Awesome!!!!

poloman · Apr 30, 2007

sorry to keep asking questions......

when does the 3-in-1 back up the saves to my r4? is it when i change the game, or every time i boot?

edit: the ini file has the answer!
autosaves = true; whether when flashing a new game the previous save will be backed up - default is true

reading the thread here:
http://ezflash.sosuke.com/about4749-0-asc-60.html

when you say dumping, do you mean a game, or the save? how do i specifically tell the app to dump the current save file to "disk"?

cory1492 · May 1, 2007

To dump the current save to disk, you select a .sav file and press A and follow the prompt. If you don't have a file to dump to, the simplest way to create one is to make a new notepad (txt) file, don't bother to put anything in it and rename it to "game name.sav" (whatever you want to call it, just make sure to change the extension from .txt to .sav) - it will fill it with your save when you use the menu to back it up.

The place in the thread you point to is talking about dumping the NOR ROM space, though I find it is always a good idea to try and leave a chunk of spare room on your SD cards (I usually leave 40-60M free).

poloman · May 1, 2007

great! I'll give that a go. thanks for the info cory.

another question tho - why would i dump the NOR ROM? if i'd copied it on from my sd card, wouldn't the rom be on the sd card anyway? (or is this in case you put it in someone else's ds?)

(sorry if im missing an obvious answer - or is it for dumping commercial roms?)

edit: save dumping works a treat - i wouldn't have thought to select the saves - brilliant program!!!

cory1492 · May 1, 2007

QUOTE said:
why would i dump the NOR ROM?

If you flash something and it doesn't work as expected (and this has happened a couple times now, actually resulting in beta6 when heretic.ds.gba did not write correctly), taking a dump (har har) of the 3in1 will give you something to hex compare to see if it was written correctly (though, I also enabled internal error checking on every chunk written in beta6 and have had no reports of problems yet).

GBALdr 0.1 beta 5 Released

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

Racer

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum