#85544 - Kjata1013 - Wed May 31, 2006 4:23 pm
Hi,
I need some veteran experience. Here is what I am trying to do, the company I work for is a paint company, and we are looking for a low cost, PC alternative to display our color formulas. Optimally, we would like the GBA to display text that the user can select the color name and then select the appropriate product line and a formula would appear on the screen. Right now, we are interested in proof ? of ? concept. We have had *minor* success using Visual HAM in conjunction with Borland C++. However, when compiling, Visual HAM chokes if we input more than 200 records. We found the Catapult utility by Nocturne, and that chokes after 2500 records. Our smallest database holds approx. 7200 records.
I need to know if anyone out there believes that the GBA can do what we need it to do, and offer any can of suggestions, be it a compiler or simply stating that we are out of our tiny minds and that the GBA cannot support this. Any help offered is greatly appreciated.
Thank you,
Kathy
#85548 - SevenString - Wed May 31, 2006 5:32 pm
I think that's a really cool idea. I can see how it would be so convenient "in the field" to just whip out a GBA SP or Micro to access a database.
My suggestions all depends on your target Flash hardware, and without knowing more about your code, I can't really offer suggestions for fixes to your existing architecture.
However, for an application such as you are suggesting, you could do something like this:
Use a GBA MoviePlayer V2 with a CompactFlash card.
Compile your program as a MULTIBOOT application, and use chism's GBA_NDS_FAT library for data access. This library will let you open and read external files directly from the CompactFlash card. Then, all you have to do is dynamically load the specific data that you are looking for into RAM as you need it.
Note that although this library supposedly requires libgba or libnds to run, it is very easy to make the minor tweaks to the headers so that it compiles and runs just fine with hamlib.
So, using a FAT-based file system, as you update your database in the future, all you have to do is copy the new version(s) of the appropriate data files to CompactFlash, with no need to recompile or copy the .gba program itself.
Finally, by dynamically loading the data directly from a CF file or files, your storage is only limited by the size of the CF card itself.
Does that help?
_________________
"Artificial Intelligence is no match for natural stupidity."
#85550 - Kjata1013 - Wed May 31, 2006 6:03 pm
I have to admit, I am blown away by the amount of feedback I am getting, I have been hitting all the boards that I can think of hoping to get a hit in the next few days, but I have been steadily responding to people for the last hour. Very cool.
Anyway, sorry about that tangent. Our exsisting code is broken. We are using Borland C++ and Visual HAM SDK to compile and we have hit a few roadblocks. We are not able to find a way to use the itoa function, our program chokes at complie after 200 records, and so on.
The optimal output that we would like is fairly simple. It would be texted base, we do not need to show the color itself. The dealer would open the GBA, search for the color name or number, choose the product line availabe, pick the can size, and then there would be the formula. Our smallest database has 7200 records. I am confident that the GBA would not have a problem holding that info, the problem is finding a compilier that can compile our 7200 records and more.
I think you have a great idea - I am going to check out GBA Movie player and the GBA_NDS__FAT and see where that leads us.
Thank you again for your help,
Kathy
#85555 - tepples - Wed May 31, 2006 6:39 pm
If your database will not change in the field, then try making it 'const'. Making your database 'const' will instruct the compiler to stick it in ROM, saving valuable RAM for other uses.
But have you calibrated the colors of the GBA's screen?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#85557 - ScottLininger - Wed May 31, 2006 6:47 pm
Kathy,
I'm not that familiar with visual HAM. I assume you're converting your database into some sort of C struct or set of arrays? If so, the 1st thing to look for is that your arrays are declared as CONST, like so...
| Code: |
| const int paintValue[] = { 555, 444, 777... etc. } |
The const keyword tells the compiler to store the values on the cart. Otherwise, all of that data will end up going into RAM, of which the GBA only has a little over 256Kb.
When you compile your .GBA, how big does it end up being? That's will tell you very quickly whether it will fit on a cart. (It would be helpful to know what kind of cart you're using.)
However, it sounds like you're trying to compile data that is simply too large for the compiler. (I've run into similar problems when trying to compile huge images for some video experiments I was trying. My compiler simply bombed when I asked it to compile big chunks.)
This is a different problem than it fitting on the cart. One way to handle this is to use a tool like tepples' GBFS, which will convert your raw data into binary format, then concatenate it to the end of your GBA program... no compilation needed.
Using something like GBFS means you need to understand your database format at a low level, of course, which could be a pain.
Is your program working at all? If not, start simple and build up from there. Build a program that displays a piece of text, then a single record, etc. Programming the gameboy has a huge learning curve if you've not done this sort of thing before.
As you've discovered, this forum is a great resource for help, especially if you can post specific problems as you encounter them.
-Scott