More help on segmented memory in real mode

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
_mark

More help on segmented memory in real mode

Post by _mark »

I seem to have a minimal kernel working in real-mode. My problem now seems to be passing string parameters around. I have the routine:

Code: Select all

void puts( char __far *ptr )
{
     while(*ptr)
        putc(*ptr++);
}
I've tried this with and without __far. In the main routine I can call putc() with no trouble, but the pointer that gets passed to puts always seems to be null. I have tried:
puts("hello world");
char __far *ptr = "hello world"; puts(ptr);
But I cannot seem to land on the right combination. The kernel is almost 12K now and gets loaded at 0x800. The hello world string gets located at the very end of the binary when linked with jloc.

I assume there is something wrong in the way I'm declaring something. The compiler (borland C++ 5.something) does not have any trouble with it. And indeed everything seems to run OK and I can pass int arg types with no problem.

Does anyone have any advice on what I might be doing wrong regarding strings?

Thanks
_mark()
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:More help on segmented memory in real mode

Post by Pype.Clicker »

have you declared puts() in the main file ? i mean, when he reads puts("hello"), do the compiler already read that the prototype is void puts(char __far *ptr) ?
Also, is __far something the compiler defined or something *you* defined ?

maybe you need something to make a far pointer for the string out of it's regular near pointer ... some kind of MK_FP(<current data segment>, "hello") ...
_mark

Re:More help on segmented memory in real mode

Post by _mark »

Yes a forward declaration has been made for puts(). The compiler defined __far so I would assume that:

Code: Select all

char __far *ptr = "hello"
would have been converted to a far pointer for me. The compiler documentation says:
Use the far, _far and __far modifiers to generate function code for calls and returns using variables that are outside of the data segment.
The first version of far, _far, or __far declares a pointer to be two words with a range of 1 megabyte. Use _?_far when compiling small or compact models to force pointers to be _?_far.
The only thing I'm not real clear on is what the difference is between "far" and "_far". In any case I tried all three and there was no change.

If I were to use MK_FP() macro, then how do I get the current DS in C? I just tried a:
char __far *fp = MK_FP( 0x800, hello )
puts(fp)
But still a null pointer is recieved in puts().

Thanks
Mark
_mark

Re:More help on segmented memory in real mode

Post by _mark »

I found the problem - it was in the JLOC config file. Does anyone have a full referance or home page for JLOC. I've googled but have not found it.

Thanks
_mark()
Tim

Re:More help on segmented memory in real mode

Post by Tim »

Are you writing code for real mode? If so, I suggest you start using protected mode. Once you've got the basics implemented it's easier to program for, it's more capable, and it removes the restrictions (e.g. on size) that real mode imposes.
_mark

Re:More help on segmented memory in real mode

Post by _mark »

I have protected mode down just fine, I had a pm kernel up and going in no time, but it is real-mode that has really sparked my interest. Maybe it is becuase it is much more challenging.

Mark
Ozguxxx

Re:More help on segmented memory in real mode

Post by Ozguxxx »

Hi, i am just curious what compiler are you using?
_mark

Re:More help on segmented memory in real mode

Post by _mark »

I got a copy of borland c++ 5.02 when I purchased some hardware a while back. I'm finally getting around to writting some code with it. The IDE sucks, but the command line tools are OK.

_mark()
_mark

Re:More help on segmented memory in real mode

Post by _mark »

OK - just a little more help if someone would. I'm still having a little trouble with real mode. I guess I need to know what the real limits of real-mode are. I though I could load and run a program (in my case - the kernel) of up to 640K.

I seem to be running into some unexpected limits. These are just some rough numbers.
1.) I can run a kernel of about 2K when there is significant static data in it...IE char foo[1024*10].
2.) If I just add code and very little static data I can seem to run fine up to about 6K

Possible causes:
1.) I do not understand the load & run process. I'm loading my kernel at 0x000:0x500 and jumping to it from the bootcode. this is just a flat binary file created by JLOC. I have not told either the compiler or linker what sections I want or anything like that. Is it possible I need to patch up things at load time. See attached MAP file.
2) I do not have my DS, SS and maybe other registers setup correct. See ASM code below.
3.) I need to tell the linker more about where to locate things. See jloc, and asm code below.

2 cold stars for anyone that can help...:)
_mark()

MAP file gerated by JLOC

Code: Select all

    Base    Start  Lnth  Segment       Group   Class  Module
       0      500    8E  __NASMDEFSEG  (null)         test.asm     test.obj
       0      58E  155C  MAIN_TEXT     (null)  CODE   main.c       main.obj
       0     1AF0     2  MAIN5_DATA    (null)  FAR_DATA main.c       main.obj
       0     1B00   10E  MAIN6_DATA    (null)  FAR_DATA main.c       main.obj
       0     1C10   149  MAIN7_DATA    (null)  FAR_DATA main.c       main.obj
       0     1D5A   128  _DATA         DGROUP  DATA   main.c       main.obj
main NASM file.

Code: Select all

[BITS 16]
        CLI
        PUSH    CS
        POP     DS
        PUSH    CS
        POP     SS
        MOV     SP, 0xFFFF                      ;stack pointer
        XOR     AX, AX
        JMP     start


[EXTERN _main]
start:
   CALL FAR   _main
   JMP     $
JLOC file

Code: Select all

ALL:
   test.obj
   main.obj

rmos: 0 500 0
   *
Post Reply