OSDev.org

Posted: **Tue Mar 17, 2009 9:36 am**

My current memory map is horrible (I'm writing an OS in real mode too):

1000:0000 +----------------+
          |  Second-stage  |
          |   bootloader   |
2000:0000 +----------------+
          | Kernel and CLI |
2000:8000 +----------------+
          | Program & data |
          +----------------+

I'm planning on going to this:

Code: Select all

1000:0000 +----------------+
          |  Second-stage  |
          |   bootloader   |
2000:0000 +----------------+
          | Kernel and CLI |
3000:0000 +----------------+
          | Program & data |
4000:0000 +----------------+
          | Program & data |
5000:0000 +----------------+
          | Program & data |
6000:0000 +----------------+
          | Program & data |
          +----------------+

There will be four program spots for pausing and resuming programs as well as possibly a simple multitasking system in the future.

Posted: **Tue Mar 17, 2009 10:23 am**

Here's my memory map for Socks:

Code: Select all

0000:0000 +----------------+
          |    Untouched   |
0000:1000 +----------------+
          | Command buffer |
0000:2000 +----------------+
          |    Path and    |
          | current folder |
          |     cluster    |
0000:5000 +----------------+
          | Working space  |
0000:8000 +----------------+
          | Kernel and CLI |
1000:0000 +----------------+
          | Program(s)     |
          +----------------+

I'm not entirely sure I'm going to keep this structure though, since there's quite a bit of unused space. It's also going to be dumped as soon as I work on getting Socks to be 32-bit.

Posted: **Wed Mar 18, 2009 9:24 am**

Thank you guys ,that gave me alot of :idea:s.

About the heep manager,i don't think I'll do it because,I'm planning to keep my code as simple as possible.

stay safe

Posted: **Wed Mar 18, 2009 12:56 pm**

For that matter, STFWiki, as well. There is an overview tutorial on the basic concepts of writing a memory manager, anddiscussions on the general principles, which would at least show the issues involved and have links to more in-depth tutorials.

The basic idea is to keep an ordered list of memory blocks (just how you order it will depend on the allocation scheme), and when memory is needed, look through the list to find an unused space. Segmentation complicates matters, because of overlapping segments, but if you allocate in 16-byte blocks - and/or use absolute addresses for the specific start and end points - it shouldn't be too difficult.

Two questions: first, what sort of memory model are you assuming, and will you allow applications to use a large model (multiple segments for both code and data)? Second, what sort of executable file format do you expect to use (when you get around to writing your loader if you haven't done so already), and do you expect you use any sort of non-static shared code (rather difficult to manage safely in real mode) or anything else that would require load-time address relocation?

Posted: **Wed Mar 18, 2009 2:22 pm**

Take a look at MikeOS or MiniDos, as example of simple realmode OS.
MikeOS
http://mikeos.berlios.de/
MiniDos
http://board.flatassembler.net/topic.php?t=5275

OSDev.org

real mode

Re: real mode

Re: real mode

Re: real mode

Re: real mode

Re: real mode