#34638 - ymalik - Sun Jan 23, 2005 3:16 am
Hello,
I want to be able to read a binary file and display the contents on the GBA. There is an open source library that allows access of the contents of the file, but it uses fopen(). Since the GBA does not have a file system, how would modify the open source code to not use fopen()? I can't just put the contents into an array.
Thanks,
Yasir
#34639 - sajiimori - Sun Jan 23, 2005 3:20 am
Answered in the FAQ.
#35069 - ymalik - Sun Jan 30, 2005 1:44 am
We are working on a major GBA application, and it turns out that the CPE guys who are going to make our device are also going to provide a FAT32 formatted flash ROM. We are going to have our own file system.
#35150 - sasq - Mon Jan 31, 2005 9:32 am
If you have a filesystem, then just implement fopen to use it.
#35172 - Miked0801 - Mon Jan 31, 2005 8:11 pm
Why? ROM doesn't change so why bother with all the overhead?
#35210 - ymalik - Tue Feb 01, 2005 3:28 pm
Why would there be overhead?
Originally we had thought that we would simply include the shapefiles with our ROM. For that we would have to basically hard code the name of each file and use some data structure to indirectly access each file. However, the CPE guys revealed to us that they are making a seperate FAT32 formatted flash ROM that will contain contain our images. Our program will be stored in a seperate ROM. I don't know much about flash or FAT32 yet, but I do know that you can over write a flash ROM using some technique.
Go here to see what I'm talking about:
http://panda.ece.stevens-tech.edu/sd/grp24/
#35221 - Miked0801 - Tue Feb 01, 2005 6:48 pm
Are you going to hook that thing up to a device that allows ROM to change dynamically? If so, a paging system would work well (kinda similiar to a FAT, but much simpler). I just don't see the advantage of a 32-bit File Allocation Table system. Instead of being able to just read a rom byte/word (or block - same speed), you need to get that data's hash number (or sector id or whatever), go through either a tree struct or a hash table, get that ptr, then dereference it to get to the data. All the more slow if you must first load it into (EW) RAM a block at a time before reading which is how it is done on the PC. Since most games run their code from ROM, this would really slow down execution time.
#35225 - ymalik - Tue Feb 01, 2005 7:16 pm
The ROM won't change--a bunch of map files will be loaded onto the ROM once. If the user wants to have other map files, the user will just erase the flash ROM and load more files.
What you are describing is what I exactly thought we would be doing until the CPE guys told us that they would provide a file system to call up files. When using a seperate flash ROM we'll have to load stuff back and forth. However, there is already an open source library that allows access of map files, and if we decide not to use a file system, we'll have to modify, or make our own, shapefile library.
I'll have to talk to my team and the CPE guys.
#35497 - ymalik - Sat Feb 05, 2005 4:03 pm
Could it be possible to make the flash ROM a part of addressable memory?
#35500 - tepples - Sat Feb 05, 2005 5:37 pm
| ymalik wrote: |
| Could it be possible to make the flash ROM a part of addressable memory? |
That would be more expensive. The new Gbit-sized GBA flash carts are so cheap precisely because they have less NOR flash (directly addressable but expensive) and more NAND flash (block addressable but cheap).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#35505 - SimonB - Sat Feb 05, 2005 5:56 pm
From where I am standing the 1Gbit flash kits that only use 256Mbit(?) NOR flash and 768Mbit(?) NAND flash arent THAT much cheaper (if any) compared to 1Gbit kits made up of only NOR flash. Of course, I guess the manufacturer and resellers play a big part in this...
Maybe not related but if manufactured by Nintendo, they only charge 1$/cart more to double the ROM size of the cartridge (up to 256Mbit). So if you start with ~6$usd for a 32Mbit cartridge, going to a 256Mbit will only cost you ~3$usd more (= ~9$usd).
Simon