BigBoss: too bad PSRAM loading isn't working... gonna have to look into it (maybe it is cheap/slow memory only meant for the browser... but then again maybe it is good enough to load ds.gba to). Thanks for the go ahead on the fifo, I basically only need a register to pass back and forth. I figured out the previous IPC problem I had as well, it was because I was using a (not updated) fragged Arm7 template.
I haven't really spent much time on PSRAM. It's possible I goofed something, but the header read I do at the end of the copy loop works. It's possible it's too slow. Hopefully EZ-Team will get back to me and tell us for sure. I didn't try .ds.gba, that would be interesting.
I'm glad you can use the FIFO stuff, it's the least I can do for you getting the flashing stuff off the ground.
Joined: Sun Apr 30, 2006 5:39 am Posts: 1560 Location: Canada, eh?
BigBoss, somewhat good news for you, I did some fiddling around with TR4 to see why it isn't working on EZ5 when mine is, basically I used FatInitDefault() and have modified libfat to not have any built in drivers (so there is only dldi). The libfat mod is not making a difference (though it saves ~8k in the final binary??), but I do not use FATx:, I just use FAT:, replacing all instances of "FAT1:" with "FAT:" has fixed it up, so it is not directly related to the kernel version.
For the EZV users who want to not loose their save data in a better fashion:
copyTest4-EZV.zip <- src changes included, pre-patched for EZ5
Just an interesting thing to note too, it seems homebrew gamecode detection has been improved in the last couple kernels, it now assumes "####" and "PASS" are both going to use EZV SD card FAT.
While I was at it and had a working version I tested your multiRom stuff too. Good news again, I wrote an 8MiB ROM to 0, and a 4MiB one to 128, from the program the 128 one boot fine, from the DS main menu the first one boot fine. Probably best to bankswitch the SRAM as well for the second one when you boot it from the menu (which I assume you are waiting for people to try it to see if it works), but other than that it works great. TMNT and Tringo FTW (sure is nice having an EZ2 writer to dump these buggers, too bad more places around here didn't carry the better GBA games so I have to risk fakes via fleabay).
Joined: Wed Jan 24, 2007 12:34 pm Posts: 5408 Location: Has left the place ...
cory1492 wrote:
For the EZV users who want to not loose their save data in a better fashion: copyTest4-EZV.zip <- src changes included, pre-patched for EZ5
Thank you cory now i can give a try to Bigboss program
cory1492 wrote:
Just an interesting thing to note too, it seems homebrew gamecode detection has been improved in the last couple kernels, it now assumes "####" and "PASS" are both going to use EZV SD card FAT.
Good news !
so now we can use generic dldi patcher
EDIT :
Bigboss> multi rom works for me too 4mB games on each bank. Mkart and BoulderDashEX.
Good job
Ps: for information. Link fonction between NDS and GBA game work well. Tested 105 nds on ezv slot1 and 997OFL on 3in1 slot 2 (transfered with copytestR4) and a "rare ring" appear in equip > ARMS.
This one is not displayed if you have just 105 on slot 1
Interesting that the FAT1: stuff was causing a problem. It works perfectly on R4/M3 Simply. I was attempting to force libfat to use the slot-1 cart just in case someone had a slot-2 cart in that was recognized by libfat. I suppose that's not a big issue, so perhaps I can kill it if it increases compatibility with EZV carts.
Nice to hear that the multi-ROM stuff works for a few other people. I can bankswitch the SRAM, but I've been avoiding it because I'm not sure that the EZ4 client save patching doesn't mess with the other SRAM banks. I was going to load/save on every game switch and just not use the other banks. That doesn't help much for users booting the first game from the DS firmware though, unless I put a loader app in first I guess.
One reason I was leaning toward avoiding banks was that I tend to either have a lot of really small ROMs, like emulators, or one or two big ones. The many small ROMs case will not work with bankswitching, there would be too many and I would become limited by the number of SRAM banks rather than the NOR size. It looks like there are only 4 SRAM banks.
Glad to hear multi-ROM and linking are working for a few people now. I've got some ideas for a more robust multi-ROM setup, so perhaps I'll go there next. I will also make the changes for better EZV compatibility so those with that card can use my program. Don't you guys have built-in support? Not that I don't appreciate any testing.
Fixed version: ez5s-dldi-V2.zip Works like a charm with TR4 unchanged. Wonder how long that would have gone unnoticed if it hadn't been pointed out while I was looking...
BTW: gamecode "####" doesn't work, so I updated the dldifix V1 with the new dldi, though the program itself hasn't changed.
There should be 0.5MBytes (4Mbit) divided into 64Kbit size; practical experimentation would probably be the best way to tell, though the sample does check up on 512k paged in 0x8000 chunks (once again relying on LEN). Still not certain on the max individual save size, though I know homebrew generally doesn't use more than 64k.
There should be 0.5MBytes (4Mbit) divided into 64Kbit size; practical experimentation would probably be the best way to tell, though the sample does check up on 512k paged in 0x8000 chunks (once again relying on LEN). Still not certain on the max individual save size, though I know homebrew generally doesn't use more than 64k.
I'm glad you found the DLDI issue.
Sounds like there are 8 banks then. I think most saves are going to be under 64K. I've read somewhere that there is a savetype that is 128K, but I've never seen one. I'll have to see if I can find one and load it up to see what the EZTeam does with the save patch. No reason they couldn't bankswitch and let it have 128K for its save if it needs it. If that's the case, I'm going to have to up the save size I'm using to account for it.
1) Will my .sav files from an emulator work with my GBA games on the 3 in 1?
2) Does Rein work with 3 in 1?
3) What is the process like for putting homebrew on the 3 in 1? Do I need the patch the .nds file with DLDI, copy it to the slot 1 device, flash the .gba.nds file to the 3-in-1 and just start the .gba.nds file from the 3 in 1?
Thanks for the help and keep up the great work guys! Hopefully, mine will arrive soon.
1) Will my .sav files from an emulator work with my GBA games on the 3 in 1? 2) Does Rein work with 3 in 1? 3) What is the process like for putting homebrew on the 3 in 1? Do I need the patch the .nds file with DLDI, copy it to the slot 1 device, flash the .gba.nds file to the 3-in-1 and just start the .gba.nds file from the 3 in 1?
Thanks for the help and keep up the great work guys! Hopefully, mine will arrive soon.
1) Maybe. It depends on how the emulator deals with save files. What you need for copyTest to work properly is a raw SRAM image 64KByte or less. No headers, no special stuff. It's just plain data. Most emulators probably have an option to get such an image, even if they don't use it natively, for exactly this sort of use.
2) No, Rein does not work with the 3in1. I am considering writing a simple DS save extractor that will save the data to the SRAM on the 3in1 to be copied to a slot-1 card after a reboot. Many Slot-1 cards cannot be removed and re-inserted without problems.
3) Depends on the homebrew. Some DS homebrew won't work on a 3in1. It just depends. In general, if the homebrew will work with an old fashioned GBA cart, it will probably work on the 3in1. No patching should be needed. In general, more modern DS homebrew that uses DLDI probably won't work on a 3in1. Just use your slot-1 cart for those. Really, with DS stuff, I recommend just using the slot-1 card you already have.
GBA homebrew should also work without any patching. GBA homebrew already expects an SRAM save, so there isn't any reason to patch. Just follow any directions the author of the GBA homebrew gave you and you should be able to use it from there. For example, emulators usually have to have ROMs "built" into the emulator ROM.
Commercial GBA will require save patching. Just use EZ4 Client and you should be good to go.
Joined: Wed Jan 24, 2007 12:34 pm Posts: 5408 Location: Has left the place ...
Volsfan91> Do you know this ? Rein clone with dldi On my Ez Flash V got a fat access error when i try to backup my mario kart DS save to FAT.
cory1492> Wow cory. I 'm happy to see that you have corrected your dldi patch.
Works like a charm now Perhaps it will be nice to update it on chishm website ?
Bigboss> copytestR5 works form me too with a big gba backup
EDIT : Just noticed something strange after starting to play "The Urbz". Sprites are missing in the game The same game sent with ez flash V firmware has no problem.
Last edited by Mbmax on Thu Mar 29, 2007 3:53 pm, edited 4 times in total.
Haha, yeah I knew about that.. in fact, I'm in that thread under the same alias. It's not working with M3 Simply because the card resets when switched out for some reason. Thanks anyway, though.
BigBoss: when GBA games are patched for 3-in-1 use with the EZ4 Client, patch them with 64k saves?
Joined: Wed Jan 24, 2007 12:34 pm Posts: 5408 Location: Has left the place ...
Volsfan91 wrote:
Haha, yeah I knew about that.. in fact, I'm in that thread under the same alias. It's not working with M3 Simply because the card resets when switched out for some reason. Thanks anyway, though.
Ho ! yes, just read the rest of david's post Well, no reset on ez flash V but fat access doesn't works That's strange ...
Haha, yeah I knew about that.. in fact, I'm in that thread under the same alias. It's not working with M3 Simply because the card resets when switched out for some reason. Thanks anyway, though.
BigBoss: when GBA games are patched for 3-in-1 use with the EZ4 Client, patch them with 64k saves?
Just use the default save type, the EZ4 Client probably knows what it's doing. I haven't had a problem with 16K and 32K save types.
Joined: Sun Apr 30, 2006 5:39 am Posts: 1560 Location: Canada, eh?
BigBoss wrote:
2) No, Rein does not work with the 3in1. I am considering writing a simple DS save extractor that will save the data to the SRAM on the 3in1 to be copied to a slot-1 card after a reboot. Many Slot-1 cards cannot be removed and re-inserted without problems.
Don't bother, unless you have some burning desire to. I already wrote (ages ago, before SuperCard supported NDS games at all) a GBA flashcart DS save manager called ETool. It copies the save off of a DS cart to SRAM, if it is a 2mbit save it tries to compress it to fit 64K (or does not back it up). It comes with PC side programs to create and extract saves on a 64k .sav file.
mbmax wrote:
Perhaps it will be nice to update it on chishm website ?
Perhaps when chishm has time and reads the email I sent him before posting here, he will do just that. The direct link to dldi&header fix is already correct.
Quote:
3) Depends on the homebrew. Some DS homebrew won't work on a 3in1. It just depends. In general, if the homebrew will work with an old fashioned GBA cart, it will probably work on the 3in1. No patching should be needed. In general, more modern DS homebrew that uses DLDI probably won't work on a 3in1. Just use your slot-1 cart for those. Really, with DS stuff, I recommend just using the slot-1 card you already have.
Homebrew that doesn't require write access but uses dldi for things like ROMs can use the FCSR driver, fcsr.dldi and filesystem builder.
Users browsing this forum: Google [Bot] and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum