ROM Hack Pokemon B/W no$gba-Fix

the avenger

Well-Known Member
Newcomer
Joined
Oct 9, 2010
Messages
55
Trophies
0
XP
107
Country
United States
hey guys i tried to retransalate that blue screen of doom and it appeard as
There is no data flow filter

Yesterday saw the return of Hail
The Yumyouga Matahaji
Although you can not save
Game - you can run system
or
The backup yesterday
saw hail or the [ji]
[yu] seeing [yo] which did not apply the data came,
it is not possible to save, but
[ge] - [mu] it can play,
is the [ge] it is please finish
Requests the category "Electrical
Please type power
ps : the way to translate the screen is to try multi language then return it to english
 

sooryansaiyajin9

Member
Newcomer
Joined
Oct 10, 2010
Messages
6
Trophies
0
XP
1
Country
India
i think that most of us can only give ideas to Mastermind.
wtf.gif
Lol am not good at the technical stuff of emulators. Will making a plugin just for the saving work? Like A No$ version Just for this game? Hey! There was a saving problem for pokemon mystery dungeon explorers of the sky? It said Save failed. Maybe both have the same problem? Just that Black and White has more 3D stuff as wel
nds.gif
l. and is a waay bigger file. Common people! Think!!!
unsure.gif
 

DeamonicHero

Member
Newcomer
Joined
Oct 6, 2010
Messages
14
Trophies
0
XP
99
Country
Pakistan
reading from the different translations, i am guessing it says the data you are trying to load is not compatible with game, but you can still play the game without saving. So i think Mastermind was trying to use a different size of data
mellow.gif
, that is not recognized by the pk w&b
hate2.gif
. Now, the million dollar question "what can we do about it"?
sleep.gif
 

Mastermind_X

Active Member
OP
Newcomer
Joined
Sep 19, 2010
Messages
25
Trophies
0
XP
12
Country
Gambia, The
Okay, alltogether, a (not so) short summary.

1) Is there anyone around being able to read and understand ARM/THUMB-assembler to assist me? Without this ability, the code will be useless for you anyway. (Besides the fact that you can see the progrss bar running through when you save and reading "player saved the game", but with no effect as mentioned before.

The whole matter:
I'm still not one-houndred percent sure why the first bluescreen appears in no$gba. Maybe it's an AP-isuue, maybe it's a hardware incompatibility of the emulator... The game seems to test the ROM-Chip-ID failing on no$gba somehow. Actually the problem should occur for DesMuME too, I looked into its implementation of responding to the "Get-ROM-Chip-ID"-command and it returns the same "wrong" value, but for some odd reason, it doesn't show the bluescreen as you all know. I patched no$gba to return the correct value and then the game boots up (without patching the ROM or using an AR-code), activating the BackupSystem. With my old (let's consider it as the v1.0) bootup-fix-AR-code, the process of booting the BackupSystem is just skipped, disabling the bluescreens. (yes plural, which leads the next point)
As soon as the BackupSystem is running, it detects BATTERY files created with desmume and converted to no$gba format in the game menu screen, however it crashes when you try to load them (should be fixable, I didn't focus on that too much). The main problem with BackupSystem booted up is that it activates all those flash-memory-checking (and maybe anti-piracy) routines out there in the ROM, which cause the game to display the "Please turn off your device and reinsert the cartridge" at several points in the game (i.e. when you have to choose kana or kanji). (annotation: normally the ROM-chip-id is checked all the time by the game to recognise if the card has been pulled out)
Not booting the BackupSystem results in the main issue: The save procedure fails immediately.
So, my solution enables the BackupSystem when you want to save by pressing L&R. After that, I removed about 8 routines, all checking the flash-memory and resulting in the bluescreen. If you pass those screens you get a frozen screen, since ARM7 is stalled for some reason. I forced it to resume anyway with another two patches and after applying those changes, the game hangs in the screen "saving, don't turn off the power" with the spinning wheel. The problem occuring here is that ARM9 waits for an interrupt which just doesn't happen while ARM7 executes SWI$6 with a standart-IRQ not triggering the desired interrupt. After removing the "wait for interrupt"-part of ARM9 the save bar starts running through taking about 10 seconds. (Is this realistic btw?) It breaks when it reaches 50 percent, cause the sub-sub-main-saver-routine fails to check if it needs to write one or two backup files (you know the difference 512kb or 256mb and so on...). I persuaded it to write 512kb and after that the process runs through displaying "MX has saved the game".

Yay.

Nevertheless, I already mentioned it some pages above, the save file is not WRITTEN to the backup media. Although no$gba recognises the save file and displays my old gamestate + timestamp when I try to save twice. Saving twice causes another BSoD which was successfully removed. So all in all, I can save but still NO DAMN SAVE IS WRITTEN.
At least I'm now sure that this problem is not directly connected to no$. The I/O-ports communicating with the backup media on a real cartridge arent accessed while saving, proving that there is missing one final patch. I realized that the ownership of the backup media is switched to ARM7, as it would be the normal case, but the sequential writes are just missing. (It alignes the save data in the EWRAM though)
So I guess that ARM7 fails to start the save-thread which explains the deadlock of both CPUs waiting for each other.

There is another very interesting thing: Each second time when you try to save, no$gba lags and accesses the I/O ports, writing some save data to the backup media but it stops doing so and runs through "normally" afterwards.

Well... even if it was a lot of information, I hope that somebody out there is able to understand it and can give me some useful hints.

In the meantime I'll try to get the game to load saves. Maybe I find the key there...


greetz
MX
 

the avenger

Well-Known Member
Newcomer
Joined
Oct 9, 2010
Messages
55
Trophies
0
XP
107
Country
United States
Mastermind_X said:
Okay, alltogether, a (not so) short summary.

1) Is there anyone around being able to read and understand ARM/THUMB-assembler to assist me? Without this ability, the code will be useless for you anyway. (Besides the fact that you can see the progrss bar running through when you save and reading "player saved the game", but with no effect as mentioned before.

The whole matter:
I'm still not one-houndred percent sure why the first bluescreen appears in no$gba. Maybe it's an AP-isuue, maybe it's a hardware incompatibility of the emulator... The game seems to test the ROM-Chip-ID failing on no$gba somehow. Actually the problem should occur for DesMuME too, I looked into its implementation of responding to the "Get-ROM-Chip-ID"-command and it returns the same "wrong" value, but for some odd reason, it doesn't show the bluescreen as you all know. I patched no$gba to return the correct value and then the game boots up (without patching the ROM or using an AR-code), activating the BackupSystem. With my old (let's consider it as the v1.0) bootup-fix-AR-code, the process of booting the BackupSystem is just skipped, disabling the bluescreens. (yes plural, which leads the next point)
As soon as the BackupSystem is running, it detects BATTERY files created with desmume and converted to no$gba format in the game menu screen, however it crashes when you try to load them (should be fixable, I didn't focus on that too much). The main problem with BackupSystem booted up is that it activates all those flash-memory-checking (and maybe anti-piracy) routines out there in the ROM, which cause the game to display the "Please turn off your device and reinsert the cartridge" at several points in the game (i.e. when you have to choose kana or kanji). (annotation: normally the ROM-chip-id is checked all the time by the game to recognise if the card has been pulled out)
Not booting the BackupSystem results in the main issue: The save procedure fails immediately.
So, my solution enables the BackupSystem when you want to save by pressing L&R. After that, I removed about 8 routines, all checking the flash-memory and resulting in the bluescreen. If you pass those screens you get a frozen screen, since ARM7 is stalled for some reason. I forced it to resume anyway with another two patches and after applying those changes, the game hangs in the screen "saving, don't turn off the power" with the spinning wheel. The problem occuring here is that ARM9 waits for an interrupt which just doesn't happen while ARM7 executes SWI$6 with a standart-IRQ not triggering the desired interrupt. After removing the "wait for interrupt"-part of ARM9 the save bar starts running through taking about 10 seconds. (Is this realistic btw?) It breaks when it reaches 50 percent, cause the sub-sub-main-saver-routine fails to check if it needs to write one or two backup files (you know the difference 512kb or 256mb and so on...). I persuaded it to write 512kb and after that the process runs through displaying "MX has saved the game".

Yay.

Nevertheless, I already mentioned it some pages above, the save file is not WRITTEN to the backup media. Although no$gba recognises the save file and displays my old gamestate + timestamp when I try to save twice. Saving twice causes another BSoD which was successfully removed. So all in all, I can save but still NO DAMN SAVE IS WRITTEN.
At least I'm now sure that this problem is not directly connected to no$. The I/O-ports communicating with the backup media on a real cartridge arent accessed while saving, proving that there is missing one final patch. I realized that the ownership of the backup media is switched to ARM7, as it would be the normal case, but the sequential writes are just missing. (It alignes the save data in the EWRAM though)
So I guess that ARM7 fails to start the save-thread which explains the deadlock of both CPUs waiting for each other.

There is another very interesting thing: Each second time when you try to save, no$gba lags and accesses the I/O ports, writing some save data to the backup media but it stops doing so and runs through "normally" afterwards.

Well... even if it was a lot of information, I hope that somebody out there is able to understand it and can give me some useful hints.

In the meantime I'll try to get the game to load saves. Maybe I find the key there...


greetz
MX
bow.gif
go go mastemind x our savior
toot.gif
 

q000

Member
Newcomer
Joined
Oct 4, 2010
Messages
11
Trophies
0
XP
21
Country
United States
Mastermind_X said:
Okay, alltogether, a (not so) short summary.

1) Is there anyone around being able to read and understand ARM/THUMB-assembler to assist me? Without this ability, the code will be useless for you anyway. (Besides the fact that you can see the progrss bar running through when you save and reading "player saved the game", but with no effect as mentioned before.

The whole matter:
I'm still not one-houndred percent sure why the first bluescreen appears in no$gba. Maybe it's an AP-isuue, maybe it's a hardware incompatibility of the emulator... The game seems to test the ROM-Chip-ID failing on no$gba somehow. Actually the problem should occur for DesMuME too, I looked into its implementation of responding to the "Get-ROM-Chip-ID"-command and it returns the same "wrong" value, but for some odd reason, it doesn't show the bluescreen as you all know. I patched no$gba to return the correct value and then the game boots up (without patching the ROM or using an AR-code), activating the BackupSystem. With my old (let's consider it as the v1.0) bootup-fix-AR-code, the process of booting the BackupSystem is just skipped, disabling the bluescreens. (yes plural, which leads the next point)
As soon as the BackupSystem is running, it detects BATTERY files created with desmume and converted to no$gba format in the game menu screen, however it crashes when you try to load them (should be fixable, I didn't focus on that too much). The main problem with BackupSystem booted up is that it activates all those flash-memory-checking (and maybe anti-piracy) routines out there in the ROM, which cause the game to display the "Please turn off your device and reinsert the cartridge" at several points in the game (i.e. when you have to choose kana or kanji). (annotation: normally the ROM-chip-id is checked all the time by the game to recognise if the card has been pulled out)
Not booting the BackupSystem results in the main issue: The save procedure fails immediately.
So, my solution enables the BackupSystem when you want to save by pressing L&R. After that, I removed about 8 routines, all checking the flash-memory and resulting in the bluescreen. If you pass those screens you get a frozen screen, since ARM7 is stalled for some reason. I forced it to resume anyway with another two patches and after applying those changes, the game hangs in the screen "saving, don't turn off the power" with the spinning wheel. The problem occuring here is that ARM9 waits for an interrupt which just doesn't happen while ARM7 executes SWI$6 with a standart-IRQ not triggering the desired interrupt. After removing the "wait for interrupt"-part of ARM9 the save bar starts running through taking about 10 seconds. (Is this realistic btw?) It breaks when it reaches 50 percent, cause the sub-sub-main-saver-routine fails to check if it needs to write one or two backup files (you know the difference 512kb or 256mb and so on...). I persuaded it to write 512kb and after that the process runs through displaying "MX has saved the game".

Yay.

Nevertheless, I already mentioned it some pages above, the save file is not WRITTEN to the backup media. Although no$gba recognises the save file and displays my old gamestate + timestamp when I try to save twice. Saving twice causes another BSoD which was successfully removed. So all in all, I can save but still NO DAMN SAVE IS WRITTEN.
At least I'm now sure that this problem is not directly connected to no$. The I/O-ports communicating with the backup media on a real cartridge arent accessed while saving, proving that there is missing one final patch. I realized that the ownership of the backup media is switched to ARM7, as it would be the normal case, but the sequential writes are just missing. (It alignes the save data in the EWRAM though)
So I guess that ARM7 fails to start the save-thread which explains the deadlock of both CPUs waiting for each other.

There is another very interesting thing: Each second time when you try to save, no$gba lags and accesses the I/O ports, writing some save data to the backup media but it stops doing so and runs through "normally" afterwards.

Well... even if it was a lot of information, I hope that somebody out there is able to understand it and can give me some useful hints.

In the meantime I'll try to get the game to load saves. Maybe I find the key there...


greetz
MX

OKey...Maybe You can update the no$gba Software
 

Mastermind_X

Active Member
OP
Newcomer
Joined
Sep 19, 2010
Messages
25
Trophies
0
XP
12
Country
Gambia, The
Just to underline it, this is not necessarily good news. Under normal circumstances I should have found a solution withing several days. Now it's nearly a month.
 

the avenger

Well-Known Member
Newcomer
Joined
Oct 9, 2010
Messages
55
Trophies
0
XP
107
Country
United States
Mastermind_X said:
Just to underline it, this is not necessarily good news. Under normal circumstances I should have found a solution withing several days. Now it's nearly a month.
its better than nothing, we were getting despiret for information
 

Takanato

Well-Known Member
Member
Joined
Jun 27, 2009
Messages
454
Trophies
0
Age
32
Location
Jamaica
XP
132
Country
Jamaica
Mastermind_X said:
Just to underline it, this is not necessarily good news. Under normal circumstances I should have found a solution withing several days. Now it's nearly a month.

I got a suggestion. The second save that you mentioned in your summary where you talked about a backup media; did you try the NO$Zoomer version with it and go to options and click "Save Battery File"? This might work, seeing as it directly attaches the game's internal save file to the sav file that NO$GBA has assigned to the game. Its sort of like the backup save function on the ds flashcarts.
 

DeamonicHero

Member
Newcomer
Joined
Oct 6, 2010
Messages
14
Trophies
0
XP
99
Country
Pakistan
Mastermind_X said:
Just to underline it, this is not necessarily good news. Under normal circumstances I should have found a solution withing several days. Now it's nearly a month.

Cmon man its certainly better than nothing. From the look of it seems that you are quite close to the solution
hrth.gif
yaywii.gif
. SO KEEP UP THE GOOD WORK
hrth.gif
toot.gif
.
 

the avenger

Well-Known Member
Newcomer
Joined
Oct 9, 2010
Messages
55
Trophies
0
XP
107
Country
United States
hey guys, i know that this is a no$gba topic, but here is a momentery sulotion for desmume:
Make sure 3d is on softerrasterizer, uncheck all 3 boxes,uncheck enable bus-level timing, Next:
go to Config, Frame Skip, Uncheck Limit Framerate, set to 3 or 4.

Message fast display (white)
5201D0CC D1024281
1201D054 000046C0
1201D0CE 0000D1D1
D0000000 00000000

Message fast display (Black)
5201D0B0 D1024281
1201D038 000046C0
1201D0B2 0000D1D1
D0000000 00000000

Double Speed (White)
52197074 BD381C28
02198070 085F0056
D0000000 00000000

Double Speed (Black)
52197054 BD381C28
02198050 085F0056
D0000000 00000000
 

Lord Patamon

Well-Known Member
Newcomer
Joined
Sep 28, 2003
Messages
86
Trophies
0
XP
304
Country
Mexico
I had been thinking about that other blue screen that returns a weird translation.

Just let's put a bit of thinking on it for a moment.

It clearly says that the saved data coudn't be dumped from the memory to the gamecard to make the permanent saving and that even though we can't save we still can play the game with the system.

This points towards that the game is saying that either the DS memory dump is doomed or that the batery on the gamecard is doomed as in it won't save.

The electric part must be probably telling that probably was an electric failure or something of the sort.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    BakerMan @ BakerMan: I bet he looks at my record and thinks "he fell off."