Hi,
Hopefully you already downloaded and played the latest beta release of the ultimate NES hack: Zelda - The Legend of Link:
http://acmlm.kafuka.org/board/thread.php?id=7308&page=1
I have been looking into why 'Zelda - The Legend of Link' does NOT run properly on nesDS. It seems as if it fit the profile of what is described by the author:
"There is a fast way to learn if my rom will play perfectly on an emulator you use.
Watch the intro after the title screen fades away. I have a golden scroll moving up the screen.
If that scroll & text comes up garbage, then you should stop playing unfortunately.
This is because the emulator you are using, is not utilizing the MMC5 register $5130 correctly.
I perform chr swaps for 3 specific things, the intro, a mini game, and the Ganon fight.
If you continue to play the game with the garbaged gfx, it will obviously look bad, and it might even crash."
Since the emulator FCEUX does handle the register in question correctly, I did a comparison of the source-code between the two.
Here is a screen-shot of the file mmc5.cpp from the source of FCEUX (http://sourceforge.net/p/fceultra/code/HEAD/tree/fceu/trunk/src/boards/mmc5.cpp):
And here is the corresponding code of map5.s from the source of nesDS (http://sourceforge.net/p/nesds/code/ci/master/tree/arm9/source/mappers/map5.s):
So, if I understand it correctly, it is a matter of translating the C-code below into Assembler, in a way that fit the rest of the Assembler code for nesDS:
'CHRBanksA[A & 7] = V | ((MMC50x5130 & 0x3) << 8);'
/d-ace
E.. I don't have a console now.
I've checked the source, not too hard to implement it.
I could try it on Desmume.
You replied - awesome!
This is what I've tried:
Adding another variable, called mmc50x5130:
Line 33:
mmc50x5130 = mapperdata+25
Storing the value of address x5130:
Line 293:
__30
and r0,r0,#0x03
strb_ r0,mmc50x5130
Modifying the sprite section:
Line 159:
20: @ For sprites.
_21:
_22:
_23:
_24:
_25:
_26:
_27:
ldrb r1,mmc50x5130
mov r1,r1,lsl#8
orr r0,r0,r1
mov r1,#0
strb_ r1,chrbank
adrl_ r1,chrpage0
sub r2,r2,#0x20
strb r0,[r1,r2]
Modifying the background section:
Line 229:
28: @ For background.
_29:
_2a:
_2b:
ldrb r1,mmc50x5130
mov r1,r1,lsl#8
orr r0,r0,r1
mov r1,#1
strb_ r1,chrbank
adrl_ r1,chrpage0
sub r2,r2,#0x20
strb r0,[r1,r2]
/d-ace
Last edit: Nitendo 2014-08-05
Hi huiming hao!
I realized I have been using the wrong version of devKitARM - when I got hold of the right version - I got rid of the 'red screens of death' :-)
Anyhow, I have modified the code above BUT since I don't know any Assembler - it is all guess-work.
I also found the source-file 'rompatch.c' and added the following to the romdb[] patch-table:
0xA1C61318, 0x00000000, 0x00010052,
Fist value is the CRC of 'Zelda - The Legend of Link (v1.2 BETA)' as it appears in the info-window in the emulator Nestopia. It should be the same as (rom + 16, prgsize + chrsize).
Second value is blank - since I couln't properly calculate the CRC without 'chrsize'.
Third value is the same as for the game 'Metal Slader Glory'
I don't know what it does (if anything) but I thought it could be worth a try.
How is it going for you - have you got around to test anything yet?
/d-ace
I've tried with the 5130 thing, no help on emulation.
The debug says it has a mapper of '0xB', and the original of '0x1'.
The source of nesDS on mapper11 never played the MMC5 chip, so some work has to be done on that.
I think the main problem is that nesDS supports to little CHR ROM (only 256k)!
I hacked the 'Zelda - The Legend of Link (v1.2 BETA)' rom by changing the 6th byte of the rom in a Hex-editor. When I changed it from 80 (1024k) to 20 (256k) and used it in Nestopia/Fceux - I got the exact same behaviour as in nesDS (garbled gfx).
So - how hard do you think it is to make nesDS support 1024k CHR ROM - probably a lot of work?
How do you feel about this problem - getting 'Zelda - The Legend of Link' running in nesDS - is this something you are villing to comit to and make a reality?
/d-ace
nesDS DO supports CHR ROM up to 65536 banks, which would be up to 64M.
When I first tried to improve nesDS, I've already known that limit.
Cheating on the EMU would get nothing, the roms from internet are most clean.
The mapper code is from VirtuaNES, Im not familiar with other emus.
Really, I dont have that time to read the code of FCEUX, etc. Even contribute code to VirtuaNES to make it work..
When VirtuaNES(EX/Plus) played that game, I would convert that.
Nope - the mapper code in nesDS is definitly from PocketNES.
I know this because I have double-checked that.
VirtuaNES on the other hand seems to have borrowed their mapper code from Nester (It says so on their site)
Guess it would take FluBBa or Loopy to get this game running in nesDS...
/d-ace
Try the latest version. Tested ok on desmume.