EZ-Flash USA Forum

Perhaps. I'll be messing with things to see what I can come up with over the next couple days. Mostly, I wanted to have some idea what the erase blocksize might be so I can erase just what I need, rather than waste time erasing the whole NOR. I think that's covered at this point, so I'll continue on and see what happens. I thought I would post my thoughts just in case they help someone else messing with this stuff or someone sees an error.

Test build 1 is available!

http://www.tabbal.net/LoaderTest.nds

This loads a file called 0001.gba from the root directory of your Slot-1 device into the expansion cart's NOR Flash.

Limitations/Bugs:

It only erases 2Mbyte of the NOR before writing. This might mean you need to use small ROMs. I'm testing with Goomba Color.

No SRAM management is available. Saves from homebrew and probably patched commercial ROMS will save, but if you load another ROM or otherwise mess with the SRAM, you will lose your save.

No real sanity checking, if you load something that isn't a GBA, is too big, etc. it will try to load it anyway. It may or may not work.


Usage/Expected Results....

Don't forget to DLDI patch the NDS file!!

When you run it, you will see the app erasing the NOR blocks. After that, it prints out the contents of your root dir, so you can see that libfat is working.

After that, it goes into the copy/verify loop. At the end, you should see an EOF notification, followed by "Copy Complete!". You can restart your DS now. If you don't see the EOF (it might be a line or two up) then there is probably a problem.

When you start your DS, remove the slot-1 card so that you can boot in GBA mode from the DS firmware menu. I have not implemented the GBA reboot code yet. Your GBA ROM should start running now.

Please report any errors you see to me and I'll see if I can get them fixed for the next test build.

Please report success as well, I would like to know how it's working for people.

BigBoss:
The #define was made up, I didn't do any real digging to see what it was supposed to be (but I should have left a comment there regarding the page size to allow such confusion). The "page" sizes appear to be 0x4000 16bit/words (or 0x8000 bytes/32Kbyte), with 8 "pages" per block (256K/0x40000 bytes should be erased on a block erase).

Everything to do with GBA slot ROM space should be 16bit. Everything to do with GBA slot SRAM should be 8bit. The bit value does not affect hardware NOR page sizes, and don't confuse bank switching page sizes with NOR block sizes.

If you are working from R4/M3DSS and using DKArm R20, read this:
http://forum.gbadev.org/viewtopic.php?t=12650
Have a look in the EZ4 section of the wiki, there are links to my reset to GBA apps (with source), though those were compiled under R17. The V3 one uses IPC, which could get buggered on M3DSS. FWNitro has some decent reset to DS code, though Chishm's GBAMP DS loader's code and Moonshell 1.51's NDS loader... both are far better/newer.

Mbmax:
Multi is possible, though I am shooting for 1 PSRAM and 1 NOR ROM sharing the SRAM so the game that is put onto NOR does not rely on any sort of loader app (eating NOR space, along with saver backups etc) to deal with it's saver being loaded/kept. Kinda like the first EZ4, it has 128Mbit PSRAM, and only really required NOR when you wanted a fast load or 256Mbit ROM space

I don't know if i understood all the thinks you have written cory
Sound great that no loader is required into NOR space but if there is no loader how can we select GBA games to play in slot 2 cartridge when it's alone in DS ?

Confirmed working. 1MB ROM. M3DSS.

The above was a GBA rom launced by unplugging the slot-1 card. I can also confirm launching DS homebrew code (.nds.gba) from the 3in1, however u must use the M3DSS boot from slot-2 menu option to do that.

You would not be able to. In order to do that, you would need a multi-ROM loader at the begining of the NOR flash. The problem with doing that, is that we don't have the space if you wanted to put a full 256M ROM in there, the loader wouldn't fit. Not likely a big problem as you wouldn't want multi-boot in that situation though I suppose. I was thinking to use a DS app to bankswitch then reboot to GBA mode to do a multi-loader. In part because I only know DS coding, I've never done any GBA stuff. Which means you would need to keep the DS cart in there.

I was also going to do the SRAM saver manager in DS mode so I could write to the FAT on the DS card.

Nice to know someone else is working on this.

Thanks again for the info Cory! I've been coding for years, but I'm new at this DS stuff. Sounds like I need to make sure to clear out the IPC struct. Odd that it would be a problem, but easy to do. I'm thinking I might do the next build with the dual proc stuff so I can try to get GBA reset working. I found some nice looking code for it in hbfirmware that handles turning the other screen and backlight off etc..

Thanks Tantrum! I'm working on adding more support as time goes on. Right now it's really rough. I'll be making a source release once I clean up the code a little. It's a mess in there right now.

For DS code, there is no reason it shouldn't work. However, like you found, you will need to use a slot-1 passme or be running flashme on your DS to boot DS code from the GBA slot. For homebrew, there is no filesystem on the expansion pack, so libfat will probably never work on it.

BigBoss: just an example of why I said to check out fwnitro and moonshell instead of hbfirmware... the sound pop is related to incorrectly handling writing to the serial power management register. You have to read it, alter it and write it back (using A7?) instead of just arbitrarily writing it.

Homebrew can use read only FCSR (which also works in the emulators) as a dldi/FAT too, along with appended GBFS and the like
http://forum.gbadev.org/viewtopic.php?p ... ldi#114090
http://gpf.dcemu.co.uk/

edit:/ still wondering about the collaboration bit... feels more like I'm feeding my hard won learning to the guy who is pulling the carpet out from under many many hours of work

That's great, keep up the good work!

Well, I certainly didn't intend that! If you'd like to set up a CVS/SVN repository (or I can) we can work in the same codebase. I happen to like the release early and often approach, it helps people see something is happening and gives them a chance to help test early code. It might even get us some extra users as they can see some light at the end of the tunnel and buy a cart. I've said from the beginning that I will release code, in fact, I hope to have the code for TR1 posted tonight. I'm attempting to contribute, you've just had more time to work out the details, and you've been sharing the information learned from all that work, which I am very grateful for!

Edit:

While I was thinking about it, I did a quick pass through the code to clean it up enough that I'm not too embarrassed to release it to the public.

http://www.tabbal.net/test-TR1.zip

You did catch the at the end, right... I have always been a fan of choices.
http://ezflash.sosuke.com/viewtopic.php?t=3966&start=15
Check the hidden bit in that post, that is what I have been trying to work out and is stalling any release from me (so in fact I am grateful for your help on it, takes a bit of concern about self imposed deadlines off). Once I get that done and have a good grip on why it is currently failing a per game rumble enable patch may be in order...

At any rate, I had a chance to work out how the NOR erase is supposed to work.

That should erase the entire NOR, though I have yet to test it out. It is in serial mode when doing NOR operations, so bank switching is not used (and addresses aren't limited to 128Mbit like the GBA bus is) since it is dealing more with the NOR's buffer instead of GBA address space. Blocks being 0x40000 in length, and Block_Erase takes the offset of the block to be erased and deals with it properly. If it works like EZ4 dlx OS NOR, then any address within a block should be sufficient to erase it (though I can see from the commands it is not identical).


That is where I originally got the size for LEN, I guessed the write's LEN would be the same as how much was read.

Oh yes, I just wanted to make sure you knew my motivations. I'm not trying to steal your thunder or anything, like most developer spare-time projects, this is to scratch an itch I've been having, GBA and RAM expansion for some other ideas I've had/seen is worth me spending some time on this. Rumble is cool and I hope to get something working for that as well. Though I need to be able to soft-reset the M3 or maybe the DS to get it to work. Another way might be to load the target NDS myself, I guess I could look in the homebrew firmware projects for how to do it.




Ooooooo.... A DS based patcher? Very cool. If I'd get off my duff and learn ASM I might be able to help you more with it.



For the browser, I did see a bit on the dsdev forums about the RAM card that goes with it. There is a header it might be looking for, and the ram is offset in the address space to 0x09000000 IIRC. You might be able to write the header to the right spot after mapping the PSRAM in to get the browser to work. I don't know on rumble, the idea seems sound from the ASM I do understand.



Thanks! That's basically all I did to get more blocks erased, I just changed the for loop constraint. Glad to see I was on the right track.



That makes perfect sense. You would generally want to write the same amount you read. And there is nothing wrong with the size, I was just confused by the comment. I'm not as familiar with the internals of flash chips as I ought to be for guessing things like page sizes. It flashes plenty fast with that size buffer.

I'm thinking my next step is to let the user pick a file to write and erase only the flash I need for it. No point in making them wait for erasing the whole flash if they want to write a 1MB file. I got the directory stuff in libfat working a little better for me and I now have a list of files and their sizes from the card.

So the 3in1 has 128Mb of PSRAM?