|
|
Posted on 06-29-11, 09:44 pm
|
|
☭ coffee and cream
 Karma: 10415 Posts: 26/2768 Since: 06-26-11 |
ROMs that have been patched by SM64DS Editor, won't run on Acekard/R4 type flashcarts. Even if they were unedited. They apparently take forever to load, and then freeze. However they're not even bigger than clean ROMs... wtf?
However, it is hard for me to debug that issue. Because I only have a Supercard, and patched ROMs launch fine on it. And DeSmuME's R4 emulation is of no help there. I downloaded the source code of a R4 firmware, but can't see what would hang indefinitely either. So, help on that problem would be appreciated... _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-29-11, 09:59 pm (rev. 1)
|
 Super Mario( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 62/4457 Since: 06-08-11 |
Hmmm. The only thing that comes to mind that could cause that issue is the overlay decompression thing.
Are you de-setting the "compressed" flag in the overlay table for each overlay you decompress? If you already do, try this: A way to work-around this would be to do step-by-step the modifications the editor would do and test each rom. For example, test a clean ROM. Then decompress an overlay and test it again. Then decompress another and test again. Repeat for all the overlays the editor decompresses. Then do all the patches your editor might do to the overlays and test each one. When you see the slowdown for the first time then you can know what is causing it, at least  |
|
|
Posted on 06-29-11, 10:02 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 27/2768 Since: 06-26-11 |
I am unsetting those flags. The patching doesn't actually decompress the overlays, however it decompresses the main ARM9 binary. No decompression flag there, so the editor just removes a call to the decompression function in the loader code.
Also, I'd follow your approach, but as I mentioned earlier, I don't have a R4 and can't reproduce the issue... I can always ask someone to test it for me, but it'd be long and tedious... and perhaps annoying for that person
_________________________ Kuribo64 - zrghij |
|
|
Posted on 06-29-11, 10:14 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 64/4457 Since: 06-08-11 |
Oh, you're decompressing the main arm9 binary...
Then that's probably the cause of your headaches. First, tell whoever is testing to disable soft-reset. It might be causing issues. I think it patches the soft-reset in the arm7 side (at least on my r4sdhc it does) but still... Second, how are you exactly decompressing it? I had to do it also for ASM hacking NSMB found it to be very headache-inducing. Take a look at how I did it in NSMBe and see if there are any differences. Be careful though: I'm not sure my way is correct either. I haven't tested that one in many flashcarts, but it has proved working well with a few R4 clones and on WoodR4, both for NSMB and MKDS. Decompressing the arm9 binary DOES make the rom load slower, it's normal since it has more stuff to load. It's around double the time. I'd say more than that is not normal. Another thing you might want to take into account is that the arm9 binary, once decompressed, is split in "sections", and each one is copied to a different place. For example, there is the main arm9 code, data, and also ITCM code. Make sure you're not resizing them, or if you do, that you're doing it correctly 
|
|
|
Posted on 06-29-11, 10:32 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 28/2768 Since: 06-26-11 |
Hmm, can't directly spot differences between NSMBe and SM64DSe, since my code is structure-wise completely different from yours...
Also, I'm not even messing with the ARM9 program sections. I'm just taking the ARM9 binary, decompressing it, and writing it back into the ROM (and ofcourse adjusting the pointers and all). And I just asked one of the persons who tested; he has soft-reset disabled. _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-29-11, 10:38 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 67/4457 Since: 06-08-11 |
:|
Then I dunno. You might want to try to decompress SM64DS's arm9 bin with NSMBe and test it. That way you'll know whether it's a problem with SM64DS, your code, or both your and my code... |
|
|
Posted on 06-29-11, 10:44 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 29/2768 Since: 06-26-11 |
Won't work. NSMBe 5.2 throws an exception when loading the ROM, and loads nothing. I have NSMBe 4.7 there, it loads the ROM but no options about the ARM9 binary or even overlays...
If you meant, trying NSMBe's code in SM64DSe, that wouldn't be easy to do... _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-29-11, 10:46 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 70/4457 Since: 06-08-11 |
Ok
I'll try to make NSMBe able to load the SM64DS rom, and i'll commit it to SVN for you to try as soon as I have time
|
|
|
Posted on 06-29-11, 10:50 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 30/2768 Since: 06-26-11 |
|
|
Posted on 06-29-11, 10:52 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 72/4457 Since: 06-08-11 |
Well, mine is an R4SDHC, it's not the same as the original R4, it's a clone and it behaves differently.
Anyways, I'll try editing a ROM with your editor and then testing it. Just opening and saving reproduces the issue, right? |
| Camewel |
Posted on 06-29-11, 10:59 pm
|
 Micro-GoombaKarma: -1 Posts: 3/15 Since: 06-29-11 |
Oh, I have an original R4, and lots of time. But not today, sorry.
|
|
|
Posted on 06-29-11, 11:01 pm
|
|
☭ coffee and cream
Karma: 10415 Posts: 31/2768 Since: 06-26-11 |
|
|
Posted on 06-29-11, 11:02 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 75/4457 Since: 06-08-11 |
Okay
|
|
|
Posted on 06-30-11, 05:24 pm (rev. 1)
|
|
☭ coffee and cream
Karma: 10415 Posts: 38/2768 Since: 06-26-11 |
While inspecting that source code of a R4 firmware I have, I found something that may be the problem: in certain cases (that seem fairly common), the firmware tries to decompress the game's ARM9 binary... which is in the case of a patched SM64DS ROM, already decompressed. I'm going to try fixin' that...
Edit- confirmed. that was the issue indeed. _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-30-11, 06:58 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 87/4457 Since: 06-08-11 |
Ooooh, interesting
How did you fix it? I wanna know because maybe I have the same issue in NSMBe. |
|
|
Posted on 06-30-11, 07:04 pm (rev. 1)
|
|
☭ coffee and cream
Karma: 10415 Posts: 43/2768 Since: 06-26-11 |
private void Patch_v3(BackgroundWorker lazyman)
{ // this should keep the r4 firmware from trying to decompress // the ARM9 binary we already decompressed m_FileStream.Position = 0x4AF4; m_BinWriter.Write((uint)0); m_BinWriter.Write((uint)0); // we never know m_FileStream.Position = 0x2C; uint binend = m_BinReader.ReadUInt32() + 0x4000; m_FileStream.Position = binend; m_BinWriter.Write((uint)0); lazyman.ReportProgress(399); } Basically, this code is inspired from the following function in the R4 firmware: Edit- note that the 0x4AF4 there is probably specific to SM64DS... but basically you just have to find the following bytes: 21 06 C0 DE DE C0 06 21 and zero 'em out. _________________________ Kuribo64 - zrghij |
|
|
Posted on 06-30-11, 07:05 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 91/4457 Since: 06-08-11 |
Oh, cool
Thanks. |
| luckwii |
Posted on 07-01-11, 02:30 am
|
 Buster Beetle Karma: 379 Posts: 13/464 Since: 06-29-11 |
Could this possibly fix issues with some of the flashcards not being able to load NSMB hacks? I know of a few people saying my hack will not work on their cards, but yet it works on almost all other flashcards and DeSmume
|
|
|
Posted on 07-01-11, 01:43 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10010 Posts: 98/4457 Since: 06-08-11 |
Well, if you haven't done anything like modifying the main arm9 binary, then this is a completely separate issue.
|
| luckwii |
Posted on 07-03-11, 10:25 am
|
|
Buster Beetle Karma: 379 Posts: 23/464 Since: 06-29-11 |
Posted by Dirbaio Well, if you haven't done anything like modifying the main arm9 binary, then this is a completely separate issue. A while back, you mentioned something about how the editor adds files to the original rom. And that when we edit the rom using NSMBe, some flashcards have issues because they don't recognize the game correctly. The flashcard looks for the original rom size, not the edited size. I have told everyone that has one of these cards, to contact the flashcard software developers and add support for hacked NSMB roms. Do you think this will ever be fixed? Or am I accurate with what is happening? |