NASM Binary File IO

[arcandersen]

2010-02-14 14:38:58 MST
I need some help with binary file io. I hope I'm going in the right direction on this so I'll give some background on the project.

I have some code that needs to display different languages on the screen. This code cannot use any API's (Windows or Linux) as it won't run on those systems. I'm thinking that if I can embed the character images for say the chinese character strings into a binary file,read the images and post them to the screen.

I'm using nasm (could possibly switch to masm32 if needed). Can anyone show me how to read two images from a .dat file and the way to layout the binary images into the file?

I know this has to be possible.

Thanks in advance.

[Frank Kotler]

Hi Again...

I see you found the "improved" forum. Sorry for the delay, I've been "scattered". We determined, I think, that you want to "incbin" a file containing "character images" of some kind. Do you have this file, or do you have to create it? If you've got it, the layout is what it is. If you're creating it, you can give some thought to laying it out in a way to make the coding easier.

Roughly, you'd want to put the data somewhere it won't get executed, probably in the ".data" section...

Code: [Select]

section .data
the_data:
incbin "chinese.dat"

section .text
...
mov si, the_data
mov al, [si]
inc si
...

At his point, you've got the first byte of "chinese.dat" in al. Possibly you'd want to get a bigger piece than that... I don't know what you'll want to do next without knowing the layout of the file. Possibly as simple as just moving it to the screen... but probably more complicated than that...

You mention two (or more?) images in the file - do we know where the second one starts? No "labels" in the "incbin"ed file, of course. Generally, the length of the data for each character would be the same, so we could just multiply to find the Nth character. If this isn't the case... maybe separate ".dat" files for each character?

Tell us more about what you've got to work with.

Best,
Frank