Well, I guess I still have a few more questions:
* In NASM, to assemble raw binary .BIN files, you used this
compile-time option: nasm test.asm -f bin -o test.bin.
How, in DJGPP, do you compile a .C file into a raw binary .BIN
file?
* To run a .BIN file, or any pure binary file, would you have to
load the program into memory, and set the IP to the starting byte
of your program? Or can't the programmer actually change the IP register's
value? If not, how would you run a file like this?
* I would like to include simple graphics in my OS. It is pmode, so the BIOS
is out, I guess. Would I use VESA? I would like to simply display simple lines
or bitmaps, at a good resolution. Any ideas on this, or resources you could
point out to me?
Once again, thanks for any replies, or help you can give me on this matter.
graphics, binary files and such
-
J. Weeks
RE:graphics, binary files and such
>On 2002-01-26 01:04:25, khaos_86 wrote:
>Well, I guess I still have a few more questions:
Oi! With all due respect, these are pretty simple
questions... you sure you're ready to write an OS?
>* In NASM, to assemble raw binary .BIN files, you used this
> compile-time option: nasm test.asm -f bin -o test.bin.
> How, in DJGPP, do you compile a .C file into a raw binary .BIN
> file?
Technically, the compile wont. You'll compile to
coff format as usual, but specify a -oformat binary
tag to the linker.
Whatever happened to gcc --help? ld --help?
>* To run a .BIN file, or any pure binary file, would you have to
> load the program into memory, and set the IP to the starting byte
> of your program? Or can't the programmer actually change the IP register's
> value? If not, how would you run a file like this?
The programmer can change the IP address... you do
_all the time_! JMP, anyone? The problem is, how
are you going to change the IP address from withen a
program before actually loading the program?!
In other words, you can't load the program with
code inside the program
Also, just because you outputted a flat binary
file doesn't mean it has to be without formatting.
You _could_ include a header section that would
contain information about how to load the file.
However, you're right... on a strictly flat, no
format binary, you'd load the application into
memory and jmp to the beginning of that code block
(thereby pointing the IP to it).
>* I would like to include simple graphics in my OS. It is pmode, so the BIOS
> is out, I guess. Would I use VESA? I would like to simply display simple lines
> or bitmaps, at a good resolution. Any ideas on this, or resources you could
> point out to me?
VESA is a BIOS implementation, dude. If you can't
call the BIOS, you can't call VESA. You'd either
have to run in through vm86 mode, _OR_ grab the
VESA pmode interface (or LFB) from real mode, in
your boot sector, and use it later, after having
entered pmode.
>Once again, thanks for any replies, or help you can give me on this matter.
Hopefully that helped. I apologize if I sound
bitchy... I'm tryin' to quit smoking _REALLY_
bitchy today
Jeff
>Well, I guess I still have a few more questions:
Oi! With all due respect, these are pretty simple
questions... you sure you're ready to write an OS?
>* In NASM, to assemble raw binary .BIN files, you used this
> compile-time option: nasm test.asm -f bin -o test.bin.
> How, in DJGPP, do you compile a .C file into a raw binary .BIN
> file?
Technically, the compile wont. You'll compile to
coff format as usual, but specify a -oformat binary
tag to the linker.
Whatever happened to gcc --help? ld --help?
>* To run a .BIN file, or any pure binary file, would you have to
> load the program into memory, and set the IP to the starting byte
> of your program? Or can't the programmer actually change the IP register's
> value? If not, how would you run a file like this?
The programmer can change the IP address... you do
_all the time_! JMP, anyone? The problem is, how
are you going to change the IP address from withen a
program before actually loading the program?!
In other words, you can't load the program with
code inside the program
Also, just because you outputted a flat binary
file doesn't mean it has to be without formatting.
You _could_ include a header section that would
contain information about how to load the file.
However, you're right... on a strictly flat, no
format binary, you'd load the application into
memory and jmp to the beginning of that code block
(thereby pointing the IP to it).
>* I would like to include simple graphics in my OS. It is pmode, so the BIOS
> is out, I guess. Would I use VESA? I would like to simply display simple lines
> or bitmaps, at a good resolution. Any ideas on this, or resources you could
> point out to me?
VESA is a BIOS implementation, dude. If you can't
call the BIOS, you can't call VESA. You'd either
have to run in through vm86 mode, _OR_ grab the
VESA pmode interface (or LFB) from real mode, in
your boot sector, and use it later, after having
entered pmode.
>Once again, thanks for any replies, or help you can give me on this matter.
Hopefully that helped. I apologize if I sound
bitchy... I'm tryin' to quit smoking
_REALLY_ bitchy today
Jeff
-
Khumba
RE:graphics, binary files and such
(snip snip)
>>* To run a .BIN file, or any pure binary file, would you have to
>> load the program into memory, and set the IP to the starting byte
>> of your program? Or can't the programmer actually change the IP register's
>> value? If not, how would you run a file like this?
>
>The programmer can change the IP address... you do
>_all the time_! JMP, anyone? The problem is, how
>are you going to change the IP address from withen a
>program before actually loading the program?!
>
>In other words, you can't load the program with
>code inside the program
>
>Also, just because you outputted a flat binary
>file doesn't mean it has to be without formatting.
>You _could_ include a header section that would
>contain information about how to load the file.
>
>However, you're right... on a strictly flat, no
>format binary, you'd load the application into
>memory and jmp to the beginning of that code block
>(thereby pointing the IP to it).
>
If you want to load the program from within DOS,
you can add "ORG 100h" to the beginning of the
assembly code, then compile it in binary format
to FILE.COM. (I don't know if this is what you
want, but oh well)
>>* To run a .BIN file, or any pure binary file, would you have to
>> load the program into memory, and set the IP to the starting byte
>> of your program? Or can't the programmer actually change the IP register's
>> value? If not, how would you run a file like this?
>
>The programmer can change the IP address... you do
>_all the time_! JMP, anyone? The problem is, how
>are you going to change the IP address from withen a
>program before actually loading the program?!
>
>In other words, you can't load the program with
>code inside the program
>
>Also, just because you outputted a flat binary
>file doesn't mean it has to be without formatting.
>You _could_ include a header section that would
>contain information about how to load the file.
>
>However, you're right... on a strictly flat, no
>format binary, you'd load the application into
>memory and jmp to the beginning of that code block
>(thereby pointing the IP to it).
>
If you want to load the program from within DOS,
you can add "ORG 100h" to the beginning of the
assembly code, then compile it in binary format
to FILE.COM. (I don't know if this is what you
want, but oh well)