Re: [Nasm-users] calling 'C' functions

[Frank K. <fbk...@zy...>]

zak100 wrote:
> Hi,
> Thanks for your help. 
>  
> 
> I have received your mz folder. It has two binaries: boot and image. 'boot'
> is fine
> but when i tried to load image to sector 2 it didnt work. Maybe I am doing
> something 
> wrong.

What *I* do is to combine "boot.bin" plus "mzt1.exe"(!) into 
"image.bin", and load the whole thing, starting at sector 1. You could 
use "image.bin", loading it to sector 1 - "writeit" won't do (only does 
512 bytes), but "partcopy" ought to - "partcopy image.bin 0 323 -f0", I 
think would do it. (I create "image.bin" with "cat", but you could use 
"copy /b boot.bin+mzt1.exe image bin", I think)

Alternatively, you could write them separately - "boot.bin" with 
"writeit" or "partcopy", and "partcopy" for "mzt1.exe". The idea is 
simply to eliminate the "exe2bin" step, and load an MZ executable.

> However, I didnt find any 'C' files.

Heh! No, I'm not taking the course, so I don't have to follow the rules. :)

I don't "do" C, unless absolutely necessary - haven't got a 16-bit 
compiler, in any case. If you look at "kmain.asm", "write.asm" and 
"getkey.asm", you'll see that they're "fake C" - you "should" be able to 
replace them with "real C" equivalents... if I've done it right (big 
if). "mzt1.asm" serves the purpose (approximately) of "crt0" or whatever 
your compiler calls the "startup code" that calls "main" - "kmain", in 
this case.

I've modified your bootsector (the one we "translated" from Tasmese) - 
among other things, I altered it to read just one sector (reading 5 
tracks wasn't working for me, for some reason). My "mzt1.exe" is well 
under that, so far, but when it gets more extensive, the bootsector is 
going to have to change. I mention this because, in my experience, C 
tends to produce "bloated" code, compared to asm, and if you go over 512 
bytes, it's going to mysteriously quit working.

Another way I haven't "followed the assignment" is that I used int 10h 
for "write()". I'm confident I can write a string to B800:????, if I can 
find the string! The purpose of this step of the exercise, for me, is to 
be able to find my data! I figure if I can find the string, I can find 
"cursor_x" and "cursor_y", and I know how to find the "screen". This 
seems to "work"... as long as I put code and data in the same segment. 
So far, my attempts to declare a "proper stack" and put "data" in 
"segment data" have failed. What I'm seeing in the executable header 
doesn't match what I "expect" to see. If and when I figure out how to 
deal with that, and with far calls and far data, I won't be stuck in a 
single 64k segment! (plus, it's not nice to teach beginners to ignore 
the warning about "no stack"! :)

I don't know what compiler you're using, or what you're telling it. Are 
you sticking to "model tiny"? I'm not sure what a compiler (and Alink) 
will emit, from the code you posted. If you want to send me some 
"output" - either before or after "exe2bin", or both, I'll try to figure 
out how we might load it (if you're still having trouble with that). No 
guarantee - I can't always figure out how to load my own stuff. :) "Post 
exe2bin" should be "easier"... maybe...

Sorry I wasn't clearer about how to use that example. I was pretty tired 
when I posted. ("try this *one* more thing and test it and then I'm 
going to bed!"...) I should have mentioned that while "build" won't work 
in dos (a bash script), it has some clues to how to put the thing together.

Lemme see if I remember how to write a dos batch file...

call nasm -f bin bootmz.asm -o boot.bin

call nasm -f obj mzt1.asm
call nasm -f obj kmain.asm
call nasm -f obj write.asm
call nasm -f obj getkey.asm

call alink -oEXE mzt1.obj kmain.obj write.obj getkey.obj

call copy /b boot.bin+mzt1.exe image.bin
call partcopy image.bin 0 323 -f0
echo done

That's totally untested (and doesn't check returned errorlevels). Good luck!

Best,
Frank