The rumble can only be set once (it appears), but here is the code, binaries and original text that was forwarded to me by EZTeam. It should allow the use of all the 3in1's abilities with only minor adaptation.

My goal in my co-operation with EZTeam is to produce a 3rd party GBA loader that will allow EZ 3in1 to work with any Slot 1 card, as well as better info for homebrewers to use EZ4 products to their fullest Also, hopefully, the loader I am producing will eventually be extended to work with many cards (F2A, Neo2, etc).



triplecard_sample.zip
Just a note: once it says "Rumble Enabled" press any button to make it "rumble".

BigBoss' copyTest (test release versions):
copyTest-TR5.zip
copyTest-TR6.zip
copyTest-TR7.zip latest - use this version to report bugs
- also see destructobot's post here if you want to import saves.

Congrats, finally made some contact with them! I got scared for a second, it's been so quiet around here. I hope all goes well and we can get the EZ4/EZV at their full potential. It seems it can be able to do so much if the right minds get together. The NOR + PSRAM can do some wonders if used right. Goodluck, hope I can help along the way.

Wait, so the EZ Flash 3 in 1 will work on the R4 soon?

It should work with any Slot1 DLDI enabled device, which includes R4. Only thing that will be tough is a rumble enable app, I currently only know where the source is to reset DSLink into it's menu is.

THANK YOU!!!

I spent a couple hours last night trying to get the card to work. I couldn't figure out the memory map and the exact steps to get the NOR writing to work. I figured the NOR had to be at 0x08000000 as the DS thinks it's a GBA game, but I missed the SetSerialMode() call. Odd one that, I couldn't figure out what it was supposed to do.

Interesting that the SRAM isn't in the usual spot without mapping. I wouldn't have thought of that. Certainly explains why I couldn't access it.

I got this thing looking to do what you are talking about doing, creating a loader app for other carts. The PSRAM also looks interesting for some homebrew stuff I have in mind. Any interest in collaborating? I'd love to flesh the sample code out into a nice access lib for general homebrew.

I can honestly say, without cracking a grin... R4/M3DSS is as much a PITA to deal with as previous M3 products

BigBoss: that was essentially my reaction to EZ sending me the sample code
I think language provides a large barrier for understanding some of the stuff they are telling us in their docs. The SetSerialMode, IIRC, the NOR has a serial and parallel mode. Could very well be something I missed with EZ4 OS NOR stuff that made deluxe writable but the others not.

SRAM is where it always was. I am assuming at startup it is in the first page (haven't touched SRAM, yet).

It's just that there is more of it than is normally writable by a GBA cart, so bank switching is used to access/set the rest (part of the reason for patching GBA using the client, so it uses banked SRAM instead of 512kbit EEPROM/FLASH and such, though sometimes the hardware directly supports converting FLASH/EEPROM commands).

512K divided into 64Kbit chunks, each of which can take the place and begin on the same address.

As to collaboration... I'm all ears. I share pretty much every bit of code I have time to make (with the exception of some things I feel are far to hackish as they are to have anyone look at).

I tried to use the standard write to 0x0A000000 to access the SRAM and it didn't work. I'll try with the bankswitch command and see if that gets the job done. It could be that the patcher is expecting to be able to add that in addition to the stuff to write to SRAM rather than FLASH.

No joy on M3DSS/R4 reset code then? How about using the trick multi-loaders use to boot another DS program from your app?

Alright, apparently I was setting the WAIT_CR register incorrectly. After using the value you used rather than Enable_Arm9DS() from the lib, I was able to get SRAM R/W working without bothering with the bankswitching. Nice! Now I'm at least accessing things.

Yeah ! Great news Cory
Do you think it would be possible to have multiple gba rom with this loader ?

Glad to hear it! I'm the same way. I hacked together a simple loader last night that loads a file from the M3DSS into the PSRAM. I figured it would be eaiser to load there for a first test. My reset to GBA code doesn't work though, so I can't test it. I don't suppose you have figured that out have you? I got a copy of a homebrew firmware replacement, so I may be able to find what I need in there as well. Hopefully I can get a GBA to boot from PSRAM, it would be great for small stuff like Goomba Color. Faster to set up and doesn't use up flash cycles. Of course, if I flashed it, I could use the DS menu to load the game. Owell...

I presume you need to erase the flash before writing? Any info on how big the flash blocks are and what the block erase function needs? From the code, it doesn't look like the blocks are the same size as the page size.

As I understand multi-GBA carts, we would need the ability to backswitch the other ROMs into the main address space. I haven't tested to see if it works, but the lib looks like it might be possible.

Should I be able to boot from the card after flashing something on to it with your tool? Or is it too early for that All I get is a blank white screen when I try to boot from GBA slot. Using M3DSS in slot-1.

It's a bit early for that. I'm writing to PSRAM right now, so booting after a power-cycle is probably not possible. I'll try writing a quick util to write to the NOR flash so that we can try it that way.

I mostly wanted to make sure I had the FAT access stuff working for last night. It ended up being quite simple, so long as I didn't forget to DLDI patch it before trying to run it! So I tried PSRAM since I can write to it with memcpy and I don't have to worry about things like erasing blocks before writing to them and such. I seem to be writing properly, though I should do more validation code before I say for sure that it works. I thought doing a soft-reset to GBA mode would be easy, but the code I found didn't work so I need to look into it more.

Browsing the sample code, it looks like the block size is 256KByte for the NOR flash. The limits in the for loops dealing with it are based on that value anyway. It looks to erase one block here:



That loop will execute once....

And we are reading in 32KByte chunks and writing them in this loop limited by what appears to be the block size:



Now, LEN is #defined to 0x8000 and the comment says that is the 1Mbit page size. Wouldn't 1MBit = 128KByte? So shouldn't that be 0x20000? Assuming 1Byte = 8 bits....

Am I missing something? 32KB is fine for a buffer size, I'm just confused by the comment saying that it is the size of the NOR page. If I'm right about the page size, it would kind of make sense, 2 pages per block. Maybe I should write a few markers at specifc spots and do a bankswitch to see where they end up?

Perhaps it's expecting 32-bit writes? Then 0x8000 would work.