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