One thing I would really like to see in the FAQ would be a tutorial / doc / memory map of what's in RAM after GRUB passed control to your code. (I'm at that point right now, and I find it to be a pain.)
GRUB booted, read the memory map from the BIOS, and passed control to my code. I know where my kernel starts (I wrote the linker script, after all), how large it is, and that I used .bss to reserve me some kernel stack space.
But I don't know my neighbours, so to speak.
There are lots of pages on the web with references to BIOS data structures. But usually they use real-mode notation for addresses (something I never really was comfortable with), or they list BIOS interrupts instead. No page I've found so far summarizes on BIOS data structures and what state GRUB leaves memory in.
Not only would it help me to get going with FirstStep again, but I think it would be a valuable addition to our FAQ.
I'm quite willing to help, but I need some starting point (e.g., link to a good BIOS reference and a hint how the real-mode address references map to the post-GRUB environment).
Anyone?
What does my memory look like?
What does my memory look like?
Every good solution is obvious once you've found it.
Re:What does my memory look like?
Just a comment on your topic title, it made me go like "those small chips on those small boards in your computer, those with 256mbit on them". Not as bad as some topic in a different forum which was "Who has a good compiler?" (me!!!).
For the complete reference for computers with 640k base memory and something above 1M:
000000000-000000400 - IVT, interrupt vector table. Save this for real and V86 mode, ignore it if you don't support those.
000000400-000000600 - (possibly only to 500), BDA. Bios data area. As listed in RBIL (www.ctyme.com/rbrown.htm).
000000600-00009FC00 - Free memory, in theory at least. You can dump whatever you like here, shouldn't hurt anybody. Note though that you yourself are in this area too (for boot sector 7c00-7e00) and that you can kill yourself.
00009FC00-0000A0000 - Memory in use by the EBDA, which is a nonstandard area with probably no interesting information. (personal opinion)
----------------------------------------------
Anything below this line up to the next is not actually memory, but hardware that you should not abuse as memory.
0000A0000-0000C0000 - Video memory, a0000-b0000 is graphical memory, b0000-b8000 is text for monochrome displays, b8000-c0000 is text for color displays.
0000C0000-0000E8000 - Sometimes E0000, your "other" bioses. Harddisk bios, scsi bios, things like that.
0000E8000-0000F0000 - Video bios, sometimes from E0000 and up.
0000F0000-000100000 - Your computer BIOS. Don't write here, this is a ROM shadow (or the ROM itself). Probably the ROM shadow, the rom itself is usually from FFFF0000-FFFFFFFF
-----------------------------------------------
000100000-????????? - Whatever your E820 memory call returned. No structures held here, you cannot even access this usually. This is the playing field for big OSes. Enjoy
HTH, C&CW, Candy
For the complete reference for computers with 640k base memory and something above 1M:
000000000-000000400 - IVT, interrupt vector table. Save this for real and V86 mode, ignore it if you don't support those.
000000400-000000600 - (possibly only to 500), BDA. Bios data area. As listed in RBIL (www.ctyme.com/rbrown.htm).
000000600-00009FC00 - Free memory, in theory at least. You can dump whatever you like here, shouldn't hurt anybody. Note though that you yourself are in this area too (for boot sector 7c00-7e00) and that you can kill yourself.
00009FC00-0000A0000 - Memory in use by the EBDA, which is a nonstandard area with probably no interesting information. (personal opinion)
----------------------------------------------
Anything below this line up to the next is not actually memory, but hardware that you should not abuse as memory.
0000A0000-0000C0000 - Video memory, a0000-b0000 is graphical memory, b0000-b8000 is text for monochrome displays, b8000-c0000 is text for color displays.
0000C0000-0000E8000 - Sometimes E0000, your "other" bioses. Harddisk bios, scsi bios, things like that.
0000E8000-0000F0000 - Video bios, sometimes from E0000 and up.
0000F0000-000100000 - Your computer BIOS. Don't write here, this is a ROM shadow (or the ROM itself). Probably the ROM shadow, the rom itself is usually from FFFF0000-FFFFFFFF
-----------------------------------------------
000100000-????????? - Whatever your E820 memory call returned. No structures held here, you cannot even access this usually. This is the playing field for big OSes. Enjoy
HTH, C&CW, Candy
Re:What does my memory look like?
That pun was intended.Candy wrote: Just a comment on your topic title, it made me go like "those small chips on those small boards in your computer, those with 256mbit on them".
Now *that* looks good. I'll merge that with what I figured out so far myself, and put it to the FAQ these days.For the complete reference for computers with 640k base memory and something above 1M...
Every good solution is obvious once you've found it.
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:What does my memory look like?
*grins* --> ;D
I don't care that much about memory map, hm? Just keep in mind, that you need some area below 1 MB for the vm86 stuff, and that you need the video buffers mapped to some other hamless region in virtual memory too.
some other structures delivered by Grub are of more use for me: the location of the modules: just pick them and move them to the desired location and off you go. I love them (have 8 of them in the boot entry *gg*) Very Useful they are until you have file system access.
If I were you, Solar (well, I *know* I am not), I'd rather go ahead, lay out the memory management design (heap/stack/driver space) for the kernel, process memory layout and how you intend to manage the physical pages (here, the bios memory report comes in handy) you hand out to the virtual memory allocator (in short, the pager).
Fun starts as soon as you go on and implement interrupt/exceptions and multitasking *gg*
It is easy: you decide who your neighbours are and you decide, to whom the bell tolls. *gg*
I don't care that much about memory map, hm? Just keep in mind, that you need some area below 1 MB for the vm86 stuff, and that you need the video buffers mapped to some other hamless region in virtual memory too.
some other structures delivered by Grub are of more use for me: the location of the modules: just pick them and move them to the desired location and off you go. I love them (have 8 of them in the boot entry *gg*) Very Useful they are until you have file system access.
If I were you, Solar (well, I *know* I am not), I'd rather go ahead, lay out the memory management design (heap/stack/driver space) for the kernel, process memory layout and how you intend to manage the physical pages (here, the bios memory report comes in handy) you hand out to the virtual memory allocator (in short, the pager).
Fun starts as soon as you go on and implement interrupt/exceptions and multitasking *gg*
It is easy: you decide who your neighbours are and you decide, to whom the bell tolls. *gg*
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:What does my memory look like?
Can't really say that's fun to debug, but if you make a cool bunch of mistakes you get really cool instruction tracesbeyond infinity wrote: Fun starts as soon as you go on and implement interrupt/exceptions and multitasking *gg*
I did that while doing the multitasking code, and the new paging code both at once. I forgot to clean the page before returning it (mistake #1), didn't check pointers in my multitasking code but instead used an auto-alloc by page fault handler (mistake #2, even though by design, it did contribute to this). I auto-mapped **** there, used it as a thread (with a link to the next), and through some amazing fortune after 5 or 6 links none of the "threads" was runnable and the link finally ended up to 0, which was the idle thread. It did finish running, did so correctly, but in a wrong way. That was one cool interrupt trace
Not like DOS, where DOS crashes if you decide to let the bell toll for *whatever* is at 0x20000... Never did get DOS memory management working rightIt is easy: you decide who your neighbours are and you decide, to whom the bell tolls. *gg*
. While in Real mode, the BIOS might complain if you overwrite the BDA or the EBDA. It does not complain when put on non-active (rip out the vectors in the interrupt table, disable interrupts or disable interrupts & go to pmode). Still, it's nice to know what's where even if you never use it.-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:What does my memory look like?
As for the question ... I've always thought, it looked like grey cells linked together under the roof of your head... *lol*
@candy&the paging code: Ouch, that's hard. it reminds me of my own troubles to get the multitasking stuff running (but finally, it came together like buttons on the trousers - smooth and cool). all the bunch of triple faults one after another and endless sessions behind the box in the box debugger to get a clue. The same it was with the paging. Didn't understand anything about it in the beginning, but suddenly it was as if a knot sprang open: *Plink* it 's made in my brain and there the understanding 's been. nice thing.
@candy&the paging code: Ouch, that's hard. it reminds me of my own troubles to get the multitasking stuff running (but finally, it came together like buttons on the trousers - smooth and cool). all the bunch of triple faults one after another and endless sessions behind the box in the box debugger to get a clue. The same it was with the paging. Didn't understand anything about it in the beginning, but suddenly it was as if a knot sprang open: *Plink* it 's made in my brain and there the understanding 's been. nice thing.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:What does my memory look like?
I prefer it over polling for memory myself, so I don't want to overwrite it before I've fed it to my memory management...beyond infinity wrote: I don't care that much about memory map, hm?
You mean, mapping the video buffers for the user, right?Just keep in mind, that you need some area below 1 MB for the vm86 stuff, and that you need the video buffers mapped to some other hamless region in virtual memory too.
Why move them at all?some other structures delivered by Grub are of more use for me: the location of the modules: just pick them and move them to the desired location and off you go.
I don't use them yet, but I loved them from the moment I read about them...I love them (have 8 of them in the boot entry *gg*) Very Useful they are until you have file system access.
All fine and well, but:If I were you, Solar (well, I *know* I am not), I'd rather go ahead...
#1 - I want to query the BIOS data area to make sure I'm actually writing to the correct video memory (monochrome vs. color, 40x25 vs. 80x25) when using my kout (kprintf());
#2 - I want to know my neighbours before setting up my own kernel data structures somewhere they don't belong.
Would you be shocked if I tell you I intend to make paging fully optional?...and how you intend to manage the physical pages (here, the bios memory report comes in handy) you hand out to the virtual memory allocator (in short, the pager).
Funny enough, that's not the part I'm worried about at all. I guess, years of talking bits & bytes with Amiga gurus does that for you.Fun starts as soon as you go on and implement interrupt/exceptions and multitasking *gg*
I like to see their passports before I shoot 'em.It is easy: you decide who your neighbours are and you decide, to whom the bell tolls. *gg*
Every good solution is obvious once you've found it.
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:What does my memory look like?
I'm not shocked if you want to make paging optional in your os. A contraire: It's Your Baby, so it's not up to me to tell you what to do or iven being shocked if your Intentions go an other way. At least Rome you'll reach.
videobuffers ... no, I *don't* map video buffers for the user. They belong solely to the kernel. The video driver has access to it. I just map it *Out of the way*. If you wanna have processes start at 0x1000, you will find this approach very convenient.
grub modules: Why moving them: ha, it is like with the block cache. They are images of programs - they become processes, so I have to copy the images to their place for execution. But sorry, I 've used the wrong word. I've meant 'copying'. I don't yet play with COW or shared pages.
as for the "all fine and well" paragraph: This can be done *alongside*
In my init code, I have one function, which reads the memory table, grub passes to the kernel. (one needs to push some register, right?) This table, I 've made globally available in kernel land, so that the memory driver is able to access it. As soon as I am able to parse the damned thing - and it isn't complete either for it doesn't report the IVT and BDA regions - I may use it to fine grain my memory mapping - for moving stuff out of the way.
Mark: 'tough' I intend to do myself a treat and get an amiga 1200 as soon as one is available and my purse allows it, I am not thinking the amiga way. Also, I didn't say Problems, I have said 'Fun', because it's a straight forward thing. But I don't thing, the talking does it to one - it might draw away the "fear" and the miracles - but *doing it* does it to one way more satisfyingly. (screwed sentence this is)
Ah, don't take me too serious, I 'm in a plain good mood today *gg*
videobuffers ... no, I *don't* map video buffers for the user. They belong solely to the kernel. The video driver has access to it. I just map it *Out of the way*. If you wanna have processes start at 0x1000, you will find this approach very convenient.
grub modules: Why moving them: ha, it is like with the block cache. They are images of programs - they become processes, so I have to copy the images to their place for execution. But sorry, I 've used the wrong word. I've meant 'copying'. I don't yet play with COW or shared pages.
as for the "all fine and well" paragraph: This can be done *alongside*
In my init code, I have one function, which reads the memory table, grub passes to the kernel. (one needs to push some register, right?) This table, I 've made globally available in kernel land, so that the memory driver is able to access it. As soon as I am able to parse the damned thing - and it isn't complete either for it doesn't report the IVT and BDA regions - I may use it to fine grain my memory mapping - for moving stuff out of the way.
Mark: 'tough' I intend to do myself a treat and get an amiga 1200 as soon as one is available and my purse allows it, I am not thinking the amiga way. Also, I didn't say Problems, I have said 'Fun', because it's a straight forward thing. But I don't thing, the talking does it to one - it might draw away the "fear" and the miracles - but *doing it* does it to one way more satisfyingly. (screwed sentence this is)
Ah, don't take me too serious, I 'm in a plain good mood today *gg*
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:What does my memory look like?
Quite honestly... don't. Get yourself a copy of "Amiga Forever" (http://www.amigaforever.com) instead - that's a fully licensed Amiga emulator package including all the different OS releases plus preinstalled software and bonus material. That's much cheaper - and faster! - than buying an A1200 plus the necessary add-ons to make it a machine capable of anything...beyond infinity wrote: Mark: 'tough' I intend to do myself a treat and get an amiga 1200 as soon as one is available and my purse allows it, I am not thinking the amiga way.
That doesn't do the trick, though. You'd have to read the Amiga ROM Kernel Reference Manuals and the Amiga Guru Book, you'd have had to be there in the golden times of comp.sys.amiga, or during the various "post-Commodore" technical discussions (QNX kernel, Linux kernel, Tao Elate)... ah, the olden times... :-[
Every good solution is obvious once you've found it.
-
BI lazy
Re:What does my memory look like?
Not with sadness but with joy in the heart I remember the looong sessions (pirates!, Defender Of The Crown, ASM programming sessions - demo programming) overnight with the good ole Commodore C64. Those sessions will remain with me forever. Good moments, good memories.
I have one at home - dormant for now as I lack the place to install it as well as decent software.
There's an intro piece with good music by Markus Schneider - distributed by Markt&Technik in those former times. the text says: On a cold winter's night four dudes sat together with a coupla boxes of beer ... That's what I call enjoying life.
stay safe
I have one at home - dormant for now as I lack the place to install it as well as decent software.
There's an intro piece with good music by Markus Schneider - distributed by Markt&Technik in those former times. the text says: On a cold winter's night four dudes sat together with a coupla boxes of beer ... That's what I call enjoying life.
stay safe
Re:What does my memory look like?
If you really want to get your hands on an A1200, I have an unused one in my basement... but it's without accelerator card (7 MHz 68020), no flicker-fixer / scandoubler (15 kHz RGB / HF TV output only), no memory extension (2 MByte combined chip / fastram), and a measly low-capacity hard drive...
Every good solution is obvious once you've found it.