flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Upper Memory Blocks

Author
Thread Post new topic Reply to topic
ring0



Joined: 14 Mar 2005
Posts: 15
Location: Australia
ring0
Hello All,

I am attempting to write my own hobbyOS (in FASM). Does anyone have good detailed info or assembly code on how I can turn the Upper Memory Blocks into RAM for general use?

For example:
1/ The BIOS normally copies itself into RAM and then marks that area of RAM as read only - I want to make that area read / rite and clear the BIOS code.

2/ If I use a VESA LFB in extended memory for my grafix is there any way I can unmap the segment starting at 0xA0000 from the video card and use it as ordinary read / rite memory?

Thanks.
Post 29 Aug 2008, 07:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17714
Location: In your JS exploiting you and your system
revolution
ring0 wrote:
Hello All,

I am attempting to write my own hobbyOS (in FASM). Does anyone have good detailed info or assembly code on how I can turn the Upper Memory Blocks into RAM for general use?

For example:
1/ The BIOS normally copies itself into RAM and then marks that area of RAM as read only - I want to make that area read / rite and clear the BIOS code.

2/ If I use a VESA LFB in extended memory for my grafix is there any way I can unmap the segment starting at 0xA0000 from the video card and use it as ordinary read / rite memory?

Thanks.
I think these things are heavily hardware dependant. ie. it depends upon the precise MB make and model. Check you MB manual for ways to do it.
Post 29 Aug 2008, 07:59
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
First of all, if you are writing hobby OS now, why bother with 16 bit stuff? go 32 bit, and use all those hundreds of MBs of RAM above the first megabyte
Post 29 Aug 2008, 08:03
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17714
Location: In your JS exploiting you and your system
revolution
vid wrote:
First of all, if you are writing hobby OS now, why bother with 16 bit stuff? go 32 bit, and use all those hundreds of MBs of RAM above the first megabyte
vid: Cut ring0 (Starr?) some slack, we all gotta learn to walk before we can run.
Post 29 Aug 2008, 08:12
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
Using UMB's means using V86 mode and paging - too hard imho.
If you're going to go that far you may as well use 32bit PM.

The BIOS RAM thing is chipset/mobo specific, because if you can write to the BIOS code anything could happen.

With the VESA LFB, I think you can still write to A0000 - it's like the first 64K of VRAM is still accessible...not sure about this though.
Post 29 Aug 2008, 08:23
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Agree with vid and sinsi. revolution's point that one should start with easy tasks, before attempting something as complex as an operating system, is well made, however, in my opinion, it is far easier to "RUN" on the flat terrain that is 32 bit protected mode, without segments, i.e. with all segments set to same address, than to "walk" in the swamp of the 1970's programming environment, called "real mode". I believe it is simpler to skip the first megabyte, or even the first ten megabytes. There are hundreds of megabytes to choose from....
Post 29 Aug 2008, 09:48
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
tom tobias wrote:
There are hundreds of megabytes to choose from....

Heh heh even though most of us only use the first couple (hey, my code works above the one megabyte limit. Now what do I do?) Smile
Post 29 Aug 2008, 10:23
View user's profile Send private message Reply with quote
ring0



Joined: 14 Mar 2005
Posts: 15
Location: Australia
ring0
Thankyou everyone for the responses. I understand the arguments both for and against protected mode. My current OS is FRM but I intend to write 2 OS - one FRM and one PM. You will understand that in FRM every byte counts and hence my initial question.

For those who may have an interest in this area of programing please refer to this URL:

http://www.uwe-sieber.de/umbpci_e.html

Thanks.
Post 31 Aug 2008, 06:23
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17714
Location: In your JS exploiting you and your system
revolution
ring0 wrote:
You will understand that in FRM every byte counts and hence my initial question.
One presumes you mean RM?
Post 31 Aug 2008, 06:33
View user's profile Send private message Visit poster's website Reply with quote
ring0



Joined: 14 Mar 2005
Posts: 15
Location: Australia
ring0
Quote:

One presumes you mean RM?

NO I mean FRM. I have set FS & GS to 4G so code space (CS, DS) is still limited.
Post 31 Aug 2008, 06:37
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
FRM=Flat Real Mode I guess?
ring0 wrote:
You will understand that in FRM every byte counts

With flat mode, it's only the code and stack that need to be <1MB. If you can write an OS that uses 640K for code, go for it.

From your link,
Quote:
UMBPCI is chipset dependent and brings several restrictions

Yes, like not working on my box...tried this a while ago.
Post 31 Aug 2008, 08:17
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Hi ring0

I've written a Memory Operating System in FRM which you can download here http://w17.easy-share.com/1701069287.html (bootable floppy) or at
http://w13.easy-share.com/1701082584.html (bootable CD).

As you will know, FRM is great because you can easily access all 4Gb of addressable RAM using 32-bit "offsets". The only limitation is that executing code must be 16-bit offsets in the first megabyte+64K up to FFFFh:FFFFh. All FAMOS kernel code resides in this area, but I put "user" application code and some FAMOS utilities in "32-bit" RAM space, but execute them in low RAM as required. Also it helps if all programs implement a kind of "harvard" structure, separating executable code and data. Then all data can remain in 32-bit RAM and accessed with DS=0 which leaves about 638K of executable code space (after taking out the IVT and BIOS data areas etc.) When you select any memory entry in FAMOS it will tell you its exact memory address range.

I thought about re-mapping the UMB area for a little extra executable code space but decided against it because it is too chipset dependent and would make FAMOS less likely to boot successfully. There are already more than enough hardware differences to deal with ...

Sinsi is right, even when VESA LFB mode is used, the A000 segment still maps to the first 64K of the LFB, in "parallel" with it.


BTW, now I want to develop a 64-bit version of FAMOS, but unless a 64-bit FRM can be discovered it looks like it will have to be in PM "longmode". So it looks like I'll be writing a PM OS too, although I hate the thought of having to re-write all my favourite BIOS interrupts.


I see you and sinsi are both from down under too, just over the ditch from me in fact. Say hi to Fred Dagg for me ...

_________________
FAMOS - the first memory operating system
Post 03 Sep 2008, 10:09
View user's profile Send private message Visit poster's website Reply with quote
ring0



Joined: 14 Mar 2005
Posts: 15
Location: Australia
ring0
Neville,
Thanks for the response. I have indeed downloaded FAMOS and was impressed with the amount of effort you have put into it. I will take the hint and give up on the UMB area for now. Do you have any plan to make FAMOS open source? Does FAMOS use a 32 bit segment data segment? Good luck with the long mode transition.

I live in Cairns but was in Taranake recently for the MAARI hookup - cold & rough seas!
Post 05 Sep 2008, 08:19
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
The trouble with 64-bit instructions is that they only work in long mode (not even in pmode) so there is no way of encoding a 64-bit address either directly or using a 64-bit register (there isn't a 64-bit address override).

As for a 64-bit long mode OS, once you set up your page tables to map all of the memory, you can leave it and use your OS just like a 32-bit PM OS. Just because you have to enable paging to get into long mode doesn't mean you need to use paging.
Post 05 Sep 2008, 09:30
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
ring0 wrote:
Quote:
Do you have any plan to make FAMOS open source?

If there's enough interest in FAMOS to develop the Memory OS concept then yes, I would go the open source way. So I guess it depends on the response. It's early days yet, but so far the response hasn't exactly been overwhelming...
Quote:
Does FAMOS use a 32 bit segment data segment?

Yes, I think (if I understand your question correctly). It runs Flat Real Mode, set up via a 32-bit R/W data descriptor in the GDT used for DS, ES, FS and GS intially.

I visited Cairns in 2005 - warm enough even in July! Went north as far as Daintree when the tarseal ran out Smile

_________________
FAMOS - the first memory operating system
Post 07 Sep 2008, 02:00
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.