Author Topic: NASM Binary File IO  (Read 4272 times)

Offline arcandersen

  • New Member
  • Posts: 1
NASM Binary File IO
« on: February 14, 2010, 10:05:29 PM »
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.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2437
  • Country: us
Re: NASM Binary File IO
« Reply #1 on: February 17, 2010, 09:34:37 PM »
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
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.