#45614 - Wriggler - Sun Jun 12, 2005 7:37 pm
Hi everyone, I've been frustrated using my crappy flash card with an (excellent) Passme device. At the moment I'm having to use crazy methods to get Arm9 code at the start of the GBA cart (the default software always writes a boot menu, which of course is Arm7 stuff and kills the passme).
The problem comes with my flash software; it only writes the first three blocks successfully. This is fine for tiny demos, but anything larger just won't write to the flash card (at least not using the method I'm using!).
So, two approaches to this problem:
-Anyone know of/has made a flash app for a MagicFlash/PowerFlash card?
-(...or...) Can the passme be changed so that the area of execution is not the start of GBA rom memory? Could I reflash the passme to point to the third block on the card, instead of the zeroth?
Cheers everyone!
Ben
#45620 - natrium42 - Sun Jun 12, 2005 8:42 pm
| Wriggler wrote: |
-(...or...) Can the passme be changed so that the area of execution is not the start of GBA rom memory? Could I reflash the passme to point to the third block on the card, instead of the zeroth?
|
Yes, change the following lines in passme.vhd available at http://darkfader.net/ds
| Code: |
-- patch ARM7 entry address
when 16#034# => patched_data <= X"C0";
when 16#035# => patched_data <= X"00";
when 16#036# => patched_data <= X"00";
when 16#037# => patched_data <= X"08";
|
(In this example the offset the PassMe jumps to is 0x080000C0.)
Generate the programming file using Xilinx ISE WebPack (free with registration). Use a CheapTag JTAG cable to reprogram the PassMe.
Now that your PassMe jumps to a different address, you have to make a modified loader (similar to ndsmall.bin) which will contain a few dozen NOPs in the beginning to cover the bytes jumped over by new VHDL.
_________________
www.natrium42.com
#45649 - cory1492 - Mon Jun 13, 2005 11:13 am
| Quote: |
| Now that your PassMe jumps to a different address, you have to make a modified loader (similar to ndsmall.bin) which will contain a few dozen NOPs in the beginning to cover the bytes jumped over by new VHDL. |
You sure natruim? I thought changing the jump in VHDL would cover that, unless you mean the loader looks to raw addresses on the cart and needs to be modified to match the VHDL code... I suppose there is no simple way to do something similar with the firmware?
#45737 - Lynx - Tue Jun 14, 2005 1:38 pm
He means that if the PassMe is looking for 0x080000C8, you need to pad the ROM up to 0x080000C8 so that your real data will start there. Otherwise, PassMe will be jumping to the middle of the ROM.
#45743 - cory1492 - Tue Jun 14, 2005 3:40 pm
I had thought by the question he was looking to use passme to start code after the first 3 blocks on the flash cart (sounds like he wants to use it to bypass the standard loader) which would, technically, mean that the loader "is" the padding...
#45769 - Wriggler - Tue Jun 14, 2005 7:52 pm
Great, thanks for the help guys. I'll look into trying something along these lines...
| cory1492 wrote: |
| I had thought by the question he was looking to use passme to start code after the first 3 blocks on the flash cart (sounds like he wants to use it to bypass the standard loader) which would, technically, mean that the loader "is" the padding... |
Yup, that's the one. I'm only interested in bypassing the loader, as there doesn't seem to be an effective way of writing to my flash cart without it :(
Again, thanks for your help.
Ben
#45772 - natrium42 - Tue Jun 14, 2005 8:14 pm
| Wriggler wrote: |
Great, thanks for the help guys. I'll look into trying something along these lines...
| cory1492 wrote: | | I had thought by the question he was looking to use passme to start code after the first 3 blocks on the flash cart (sounds like he wants to use it to bypass the standard loader) which would, technically, mean that the loader "is" the padding... |
Yup, that's the one. I'm only interested in bypassing the loader, as there doesn't seem to be an effective way of writing to my flash cart without it :(
Again, thanks for your help.
Ben |
The GBA menu loader comes after the binary and not before the binary. A jump to it is inserted into GBA header by your flashing software. PassMe jumps over this GBA header. Hence jumps to GBA menu loader are not executed.
How old is your flashcart? Maybe it has a few bad blocks since flash wears out?
_________________
www.natrium42.com
#45773 - Wriggler - Tue Jun 14, 2005 8:41 pm
...so you're saying that the passme should work even though the menu is copied to the flash cart? Because, well, it doesn't. The flash cart isn't that old, and it doesn't have bad blocks in the first few sectors (as I can write it using one method, but not the other).
If the boot menu is at the end of the cart, shouldn't the passme just ignore it completely?
(BTW- Flash cart is a MagicFlash 256)
Ben
#45783 - natrium42 - Tue Jun 14, 2005 10:22 pm
| Wriggler wrote: |
| ...so you're saying that the passme should work even though the menu is copied to the flash cart? Because, well, it doesn't. |
Well, I do believe you, so let's figure it out :)
| Wriggler wrote: |
If the boot menu is at the end of the cart, shouldn't the passme just ignore it completely?
|
That's the idea.
| Wriggler wrote: |
(BTW- Flash cart is a MagicFlash 256)
|
Can you write a demo to the flashcart and then read it back? If this is possible, you can compare it to the original binary (use HexWorkshop) and see what bytes are being changed. Usually a few bytes in the 192 byte header are changed and the menu loader is attached somewhere after the demo binary.
_________________
www.natrium42.com
#45802 - Lynx - Wed Jun 15, 2005 4:53 am
:'( Man, you should dump those other projects and get back to the NDS, Natrium42. We miss you! :P
#45811 - cory1492 - Wed Jun 15, 2005 11:47 am
Wriggler, is the current method you use replacing the loader in the standard writing soft with you nds stuff?
#45813 - Vince - Wed Jun 15, 2005 1:57 pm
Hiya,
I am not sure here about what Natrium says concerning the loader : on F2A/F2A Ultra for instance, the loader is written at the beginning of the cart (0x8000000) and ROMS are after it.
This seems odd to me that the loader lies at the end because this would mean rewriting it every time we add a new ROM (and repatching the jump accordingly every time). This would also pose problems to bankswitch : if the first ROM's size is equal to 256M, supplementary code would need to be inserted to bankswitch before jumping at the loader address.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#45834 - cory1492 - Wed Jun 15, 2005 5:45 pm
| Vince wrote: |
| on F2A/F2A Ultra for instance, the loader is written at the beginning of the cart (0x8000000) and ROMS are after it. |
Thanks Vince, Natrium confused me there. I didnt think there was any changes to the header with the f2a carts since it uses a content descriptor, but I am not certain about the magicflash series...it just seems to make sense to me to put the bootloader at the beginning as its what gets loaded first.
You could try it and see, I guess, you could look at the loaders bin and find its hex size, then add 0xC0 to that and use that for the value that passme loads, and load the loader as well as a nds.gba file to see if it works... not sure how many time the Xilinx CPLD was meant to be reprogrammed effectively, but it shouldnt be hard to put it back the way it was if you are able to dump the code with ISE first. You may have to make a custom loader.bin with that number added to the start address codes so the addresses of the arm7 and 9 arent skewed...
#45840 - natrium42 - Wed Jun 15, 2005 6:45 pm
| Vince wrote: |
I am not sure here about what Natrium says concerning the loader : on F2A/F2A Ultra for instance, the loader is written at the beginning of the cart (0x8000000) and ROMS are after it. |
Well, if it's a cart with a memory bank just for the menu loader, this is possible. Otherwise, you cannot write a GBA menu loader into the beginning of a bank and still use that same bank for GBA roms. The reason is that you cannot relocate the GBA code (i.e. when you shift every byte of a GBA demo, all the absolute references will be wrong.)
So, you'd have to investigate what a particular flashcart does. There is no generalization.
_________________
www.natrium42.com
#45901 - Vince - Thu Jun 16, 2005 9:30 am
| Quote: |
| Well, if it's a cart with a memory bank just for the menu loader, this is possible. Otherwise, you cannot write a GBA menu loader into the beginning of a bank and still use that same bank for GBA roms. The reason is that you cannot relocate the GBA code (i.e. when you shift every byte of a GBA demo, all the absolute references will be wrong.) |
Yes, that's true for the F2A : the loader takes 128KB, the exact size of a flash bank on that card.
I, however, don't get why this would pose problem to put the loader and a ROM on the same bank (you are talking about flash banks aren't you?). The old F2A pro carts loader was only 32K so there was room for a (small) ROM in the same bank. I suppose this is based on how flash addressing works... I'll have a look into that.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!