#4811 - ragefan - Thu Apr 10, 2003 2:59 pm
Is there any way to read into the rom his real size without his dummy blocks (FF & 00 bytes) at the end ?
#4825 - tepples - Fri Apr 11, 2003 2:12 am
| ragefan wrote: |
| Is there any way to read into the rom his real size without his dummy blocks (FF & 00 bytes) at the end ? |
You mean from the PC or from the GBA?
If you're writing your own program and trying to append your assets to the end of the program, you'll have to scan ROM address space for a "signature" that marks the beginning of your data. This is faster if you make sure the size of the program is a multiple of 256 bytes. You may want to take a look at GBFS.
If you're trying to shrink an existing binary, you'll just have to find how much dummy data is at the end, and then round the real ROM size up to a 32 KB boundary.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4831 - ampz - Fri Apr 11, 2003 8:13 am
If you let the linker automatically include the data you wount get that kind of problems.
#4832 - ragefan - Fri Apr 11, 2003 9:41 am
| tepples wrote: |
| ragefan wrote: | | Is there any way to read into the rom his real size without his dummy blocks (FF & 00 bytes) at the end ? |
You mean from the PC or from the GBA?
If you're writing your own program and trying to append your assets to the end of the program, you'll have to scan ROM address space for a "signature" that marks the beginning of your data. This is faster if you make sure the size of the program is a multiple of 256 bytes. You may want to take a look at GBFS.
If you're trying to shrink an existing binary, you'll just have to find how much dummy data is at the end, and then round the real ROM size up to a 32 KB boundary. |
How to find that ? simply by deleting the FF or 00 at the end ?
#4847 - MrMr[iCE] - Sat Apr 12, 2003 6:53 am
are you talking of the address in cart memory where the rom ends?
_________________
Does the corpse have a familiar face?
#5130 - ragefan - Mon Apr 21, 2003 6:51 pm
| MrMr[iCE] wrote: |
| are you talking of the address in cart memory where the rom ends? |
yes ;)
#5898 - Jason Wilkins - Mon May 12, 2003 3:47 pm
If you are using that latest DevKit Advance R5, then the last address in the program image is stored in the variable 'extern char *__load_break_appended_ptr'
This value is NOT automatically updated if you add stuff at the end of the file, but that is easy enough to do. I explain how to do that in another post, and will provide a tool soon.
One thing I forgot to mention in that post is that this value HAS to be updated for multiboot programs loaded into a cartridge because the variable is used to determine how much ROM is copied to EWRAM.
_________________
http://devkitadv.sourceforge.net
#5905 - Sweex - Mon May 12, 2003 5:25 pm
I'm quite curious now. Why do you want to append data at the end of a rom? Is it so that you won't have to recompile/link it all?
(Currently working on a imho nifty tool to get data into a ROM, including conversion. If it's finished (and reasonably) bugfree I'll release it...)
#5906 - Jason Wilkins - Mon May 12, 2003 5:43 pm
The possibilities are endless, and that is why I felt is was important enough to add support at a low level directly into the devkit.
The programming team could provide a bare ROM image to the artists, and a tool which appends artwork and other assets. The artists then do not have to have a tool chain installed to test their work, they just run the appending program and get a usable ROM image.
A hobby developer would develop a game with a level editor, or some kind of random dungeon generator. The custom appender program could then add the levels to the end of the ROM and the user could use their MBV2 cable or flash cart to get the game into their GBA.
The main purpose of appending assets instead of linking them is that it can be done dynamically and simply without providing object files and without requiring a toolchain. These are the requirements when dealing with end users or members of a team that do not need a full compiler installed. Even though an artists box could easily have a toolchain and a few scripts to make it easy, I think they would appreciate the speed.
For the hobby game developer, making games for people with Flashcarts and MVB2 cables, being able to do this without the 4MB download of agb-win-binutils-r5.zip is a huge win.
I guess you could just supply ld.exe, objcopy.exe, and a few scripts, but then, to follow the GPL, you would have to provide the source code as well. Just use appended assets and all those considerations go away (did I mention it is faster as well).
_________________
http://devkitadv.sourceforge.net
#5925 - Sweex - Tue May 13, 2003 12:14 am
As I thought, mainly for appending data to it. Maybe I'll add that option to my tool as well then!:)
(As for those curious why I'm working on "another data tool"; It will automate all the conversions! Give it a directory, a conversion script (ini file) and a target and it will convert and add all files (that are newer than the ones in the archive))