#68940 - wiz - Fri Jan 27, 2006 2:41 pm
With a bit of help previously I had a "techincally perfect" game rating from no$gba.
Nothing has changed besides the emulator, as announced on the news page that a new release of nocash is available so being quite happy to upgrade and find any new features. I had a look at the error log to be satisfied yet again about a "technically perfect" game rating but to shock horror there were thousands of errors! and telling me my game contains bugs and is unstable.
help me, what has changed?, why is it now picking up all these new errors :*(
of course I still need to disable all my code and pin point the problems myself but Im really hoping someone may be aware of anything obvious to look for.
Thank you!
#68952 - wintermute - Fri Jan 27, 2006 4:22 pm
You could register the homebrew debugger and find the problems that way or upload your rom somewhere so that someone with the registered version can test for you.
#68988 - Miked0801 - Fri Jan 27, 2006 8:16 pm
I'll take a breeze through the notes and see if anything has changed...
#69583 - wiz - Tue Jan 31, 2006 5:16 pm
Cheers Mike, anything noticed?
I'll have a look tonight to see if I can discover what is throwing all these errors.. will let you know if I manage it :)
#78764 - Cearn - Sun Apr 09, 2006 5:12 pm
* uses phoenix down on thread *
Just saw that I have the same problem with no$gba 2.2b: thousands (tens of thousands) of errors, even right at the start, and a lot more when I enable interrupts. I found these to be the main culprits.
First, interrupt code that makes advantage of IWRAM mirroring for the main interrupt vector (0300:7FFC->03FF:FFFC) and/or bios acknowledge register (0300:7FF8->03FF:FFF8). The latter is an issue for pern, tonc and libgba. A fix would be the following:
| Code: |
@ ---current code ---
@ (InterruptDispatcher.s, irq_handler.asm, single_ints.s):
ldrh r2, [r3, #-8]
orr r2, r2, r1
strh r2, [r3, #-8]
@ --- suggested replacement: ---
ldr r0, =0x03007FF8
ldrh r2, [r0]
orr r2, r2, r1
strh r2, [r0]
|
The second problem I found is in the copy-code for multiboot games in the boot code of devkitARM (gba_crt0.s, around line 80), and probably devkit advance and HAM too. The problem here is that it copies the full 256kB into EWRAM, even when the binary itself is much smaller. Guess no$gba doesn't like that.
My current solution is to get the actual size via __ewram_end, though I'm not entirely certain this is the right linkscript variable to use here. There seem to be a lot of them that give the right size in my test cases so it's hard to be sure.
| Code: |
@---------------------------------------------------------------------------------
@ We were started in ROM, silly emulators. :P
@ So we need to copy to ExWRAM.
@---------------------------------------------------------------------------------
@ --- current ---
mov r3, #0x40
lsl r3, #12 @ r3 = 0x40000
lsl r2, r3, #7 @ r2 = 0x2000000
mov r6, r2 @ r6 = 0x2000000
lsl r1, r2, #2 @ r1 = 0x8000000
@ --- suggested replacement ---
mov r2, #2
lsl r2, r2, #24 @ r2= 0x02000000
ldr r3, =__ewram_end @ PONDER: is this right?
sub r3, r2 @ r3= actual binary size
mov r6, r2 @ r6= 0x02000000
lsl r1, r2, #2 @ r1= 0x08000000
|
There may be a need for an extra EWRAM clear as well. A word-alignment check might be useful too.
This removed nearly all of my problems with no$. The remaining errors I get have something to do with VBlankIntrWait, but I can't really see what. All I know is that if I remove it I get no errors, and putting it back gives 180/s (just with VBlank irq), or even 14k/s (HBlank irq).
Note that none of these things seem fatal, but I guess there will be prefectly logical explanations for flagging them. Regardless of that, they do tend to hide any real errors so fixing them might be a good idea.
#79886 - wintermute - Sun Apr 16, 2006 8:19 pm
I mailed Martin about the problems recently and it seems he accidentally made the error reporting stricter than it should have been in the freeware version.
I've updated the gba crt0 copy to reflect the size of the binary. Next update of no$gba should fix the rest.
| Martin Korth wrote: |
Whoops, I somehow got the freeware version to act "strict". If you select "strict" memory-range-checks in the debug version, then you should get the warnings about bios-bugs there, too. Anyways, you are right, of course the freeware version shouldn't count bios-bugs as game-bugs.
Many thanks for pointing me on it! Next version should be working again.
|
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog