gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > accessing data from binaries

#163144 - gauauu - Tue Sep 23, 2008 9:52 pm

I've got binary audio data that I'm compiling into my game, but which isn't working right. Maybe somebody can tell me what's wrong.

I have some audio files. I'm using $(bin2o) from devkitArm's base_rules to convert it to an object file to link in.

The assembly that is created by bin2s looks like:

Code:

/* Generated by BIN2S - please don't edit directly */
   .section .rodata
   .balign 4
   .global thunk_wav_size
   .global thunk_wav
thunk_wav:
   .byte  70, 79, 82, 77,  0,  0, 29, 78, 65, 73, 70, 70, 67, 79, 77, 77
   .byte   0,  0,  0, 18,  0,  1,  0,  0, 28,226,  0,  8, 64, 14,172, 68
...snip....
   .byte 253,254,255,  1,  1,  2,  3,  3,  4,  4,  4,  3,  2,  1,  0,255
   .byte 255,254,253,252,250,  0

   .global thunk_wav_end
thunk_wav_end:

thunk_wav_size: .int 7510


As far as I understand, I should then be able to access it from C:
Code:

extern const u32 thunk_wav_size;

displayNumber(thunk_wav_size);
if (thunk_wav_size == 7510)
{
      //it SHOULD get here...but doesn't
}


The value of thunk_wav_size that I get when I read it, though, is 16391510. The pointer to the beginning of the binary blob is also wrong.

What makes it more odd is that there are about 10 sound files. Two or three of them work fine. The others are all messed up in similar ways.

Any ideas what's going on, or what I'm doing wrong?

#163156 - gauauu - Wed Sep 24, 2008 4:05 am

Well, I still don't know what the problem was, but I tried using the bin2o.exe tool from the tools section of gbadev, instead of using the bin2o rule from devkitArm, and it works for me now.

I'd still be interested to know what the problem was, but my issue is solved.

#163167 - Cearn - Wed Sep 24, 2008 9:19 am

The issue is word alignment. This is the situation in hex. Addresses are on the left and the placement of the size is shown in brackets.
Code:
00001D40  FD FE FF 01  01 02 03 03  04 04 04 03  02 01 00 FF
00001D50  FF FE FD FC  FA 00[56 1D  00 00]

As you can see, the thunk_wav_size starts in the middle of a word. When reading the word via LDR, the data used will start at address&~3 (meaning 1D54 to 1D57), giving 1D5600FA. These are then rotated for the off-alignment to give 00FA1D56, which is 16391510 in decimal.

#163172 - gauauu - Wed Sep 24, 2008 1:32 pm

Thanks, Cearn, I wondered if that might have something to do with it.

What does .balign 4 do if not align it on word boundaries? Is there some other way to specify that it should be word aligned?

#163173 - Cearn - Wed Sep 24, 2008 1:47 pm

.balign aligns the next label to the selected boundary. It doesn't do anything for later ones.

#163175 - gauauu - Wed Sep 24, 2008 3:06 pm

Aaah, makes sense. Again, thanks for all your help!

So it looks like then, to use the bin2o rule, the binary files must be padded to a word boundary. Does anyone know why the assembly files produced by bin2s don't add another .balign 4 before the size label, which seems to me to be the "obvious" fix?

#163185 - tepples - Wed Sep 24, 2008 8:38 pm

When I wrote bin2s for GBFS, I originally had it put _size (originally called _len) above the data, so that both the size and the data would be aligned to 4 bytes as required by the ARM ABI. In June 2005 (source), WinterMute picked up the GBFS tools and incorporated them into devkitARM. The revision history of devkitPro bin2s shows that revision 1.4 (February 2008) moved _size to the bottom in order to guarantee that the data is aligned, even on platforms where the data needs to be aligned to 8 bytes or bigger. I guess I never noticed the change because most file formats that I have used with bin2s are specified to be a multiple of 4 bytes in size: .wav is 4 bytes, .chr (tiled graphics data) is 32 bytes, .gbfs is 16 bytes, etc. Apparently, revision 1.6 (September 2008) fixed the _size alignment, so it should end up fixed if and when devkitARM R24 becomes available through devkitProUpdater.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.