i started writing a simple operating system some times ago. my bootcode loads the core into memory with the int 0x13. i displayed text and controlled the vesa gfx-mode using int 0x10. i tried after switching to pm (and loading my idt), it didnt work any more - how souldt it? i have overwritten the idtr. so, how can i still use the bios ints?

greets, hartyl
Posted on 2003-02-09 13:28:03 by hartyl
If you REALLY need to use BIOS ints in Protected Mode, you could make a multiplexer function, that switches to V86 or realmode, and calls the specified int.

But in reality, you should try to access those hardware services directly, as using BIOS is slow.

For loading the kernel, you could use int 13h with the "un-real" mode, so it's easier to load a large kernel (load GDT, switch to PM, jump, set segment regs to descriptors with big limits, switch to realmode, and poof, you can access memory beyond 1 MB).

-Stealth
Posted on 2003-02-09 17:49:47 by Stealth
i've seen much code using the ports to access this and that. these instructions in & out. is any reference availible containing all ports & bytes to send and receive? what can be done with them? or, sould i ask: what cannot be done?

by the way: VESA. i want to have the LFB for screen access. i set an vesa-gfx-mode and can access it with


mov ax, LINEAR_SELECTOR
mov es, ax
mov [es:BPP*(Y*MAX_X+X)],COLOR

with that get just the top 20 pixels - but the last pixel is at the right bottom of this 20px-frame... in some tuts (dmpi is used) the map the LFB - i got no idea how I do that. any suggestions?

greets, hartyl
Posted on 2003-02-10 13:15:03 by hartyl
You could get the Ralf Brown's Interrupt List, it includes much information about ports, memory and ints.
http://www.pobox.com/~ralf

I'm sorry to say, that I haven't done so much graphics coding with VESA, but I think you should find the answer in the Ralf's intlist. I think it's quite easy to enable the Linear Frame Buffer, if I remember correctly, you have to set some bit (14, maybe) in the mode number. The Linear Frame Buffer is supported only on VBE 2.0+.

-Stealth
Posted on 2003-02-10 17:04:39 by Stealth

Accessing Linear Framebuffer Memory
Once you have initialized the graphics hardware into a mode that supports a hardware linear
framebuffer, you need to create a pointer that your application can use to write to the linear
framebuffer memory. The first thing you should realize is that the linear framebuffer location
reported in the ModeInfoBlock for the mode you are using is a physical memory address, and
cannot be used directly from protected mode applications. Before you can use the memory you
must use the services your operating system provides to map the physical memory to a linear
memory address, and then map this linear address into your applications memory space. Under
DPMI mapping the linear memory is done with DPMI function 0x800, and equivalent functions
exist under other operating systems.
The steps involved in mapping in a linear framebuffer region are as follows (32-bit protected
mode only):
1. Map the physical memory address to a linear memory address (using DPMI function
0x800 for example).
2. Find the base address of the default DS selector for your operating environment.
3. Subtract the base address from the linear address computed in step 1 to give you a
near pointer (relative to DS) that you can use from within your code.


i still don't get it. this is a part of the vbe3.pdf. the BIG problem is step 1. i don't know how
to map memory. what does this 0x0800 dpmi-function excatly do? how do I do that?
before i jused the mode number 0x0118. i found, that i need bit 14 for my LFB, so i tried
0x4118, but it didn't change anything - i still get the top 20 pixels. HELP!

greets, hartyl
Posted on 2003-02-12 13:15:32 by hartyl
Sorry, I'm VERY late...

If your OS doesn't use paging, you don't actually have to map anything. Just use descriptors that have base of 0, and limit of FFFFFFFF bytes, so the physical address == linear address. Or, if you want, you can create an own descriptor for the LFB.

-Stealth
Posted on 2003-02-22 16:28:52 by Stealth
:confused:
Changing to Pmode is done by setting bit 0 at CR0 ( Mov Eax,CR0 <=>FF 20 ).
so it was done by :


Mov Eax,Cr0
or Eax,1
mov Cr0,eax

After that code executed, all the segment register is Set to Zephiro by BIOS.
That mean we only can use Extended register only if CR0 is set.
I coded all of this manually (By a hexa Editor, can you suggest me a good Compiler to do it?).
Posted on 2003-02-23 09:28:52 by realvampire
Since you will be starting in real mode (16 bit) Dos debug in very useful. The "A" assemble and "U" unassemble commands and you will need to use "E"edit command to insert some pure machine code instructions since instructions like LGDT (Load Global Descriptor Table) and other PM environment instructions are not suppoted by the assembler. But "Debug" is very handy and has all the features of a very powerful debug utility such as tracing (singel step), writing,loading and updating files by name etc.
As far as your original question. It's been a long time since I wrote a small protected mode system and never had a chance to deal with virtual 8086 mode, but like stealth said use your 4Gig physical memory and I would write my own exception handlers. Just set up the IDT with your own interrupt vector table. A good refernce for this is "Intel Architecture Software Developer's Manual" vols 1,2 and 3 in the developers section. I don't know where to tell you to get info on using "Debug" except an old book called "DOS Power Tools" by Paul Somerson the then editor of PC Magazine. Or you can ask me if you choose to use the program.
Posted on 2003-02-23 10:59:23 by mrgone

If your OS doesn't use paging, you don't actually have to map anything. Just use descriptors that have base of 0, and limit of FFFFFFFF bytes, so the physical address == linear address. Or, if you want, you can create an own descriptor for the LFB.


this is what i do. i just write at the adress i get by the mode_info-struct of vesa. it partially works, but i just get the top 20 pixels - like the memory displayed is resized to them - squished :). so, if i but 0x00FFFFFF at MAX_X*MAX_Y*BytePerPixel, it should be at the bottom right. but it is somwhere in the top 2 centimeters of the screen - i dont remember exactly, but i think it wasn't even at the very right. i indeed set the bit 14 of the mode-index.

@mrgone:
you tell me what i have done yet :). the idt is done, so the exception handling too. i set up a little gdt with a null-, linear-, data- and code-descriptor.

@realvampire:
i use fasm to write my OS. the flat assembler just generates the byte-code out of the instructions, not careing about PE-headers.

@all:
is any "flat c++-compiler" availible?
Posted on 2003-02-23 11:18:08 by hartyl
Did you set up your TSS (Task State Segments) and LDT (Local Decriptor Tables)?
You know you graphic program is a task so the processor with be looking for other tasks to run in a time multiplexed order.
Posted on 2003-02-23 11:49:03 by mrgone
Look at MenuetOS - they have done all of this in FASM with source code availible:
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=MenuetOS
Posted on 2003-02-23 12:29:17 by bitRAKE
Ok, a stupid question, but are you sure your display adapter supports Linear Framebuffer for that mode?
I just wrote a little LFB test proggie using DPMI, and it works fine on my adapter.

Here, you can test if it works for you. I also included the NASM source. The program is not optimized in any way, and is just a quick hack, and I was so damn tired, when coding it (and still are, insomnia, say), and blah blah...

-Stealth

P.S. Also note, that the app assumes 4 bytes per pixel, so if your adapter uses 3 bytes per pixel, you need to change lines 4 and 76, or it'll overflow the buffer.
Posted on 2003-02-23 16:05:15 by Stealth
...:stupid: but what is int 0x31 use for? is it Bios Interupt ?
Posted on 2003-02-23 20:49:17 by realvampire
huh?! you made me worry about that...
i don't know how i should launch your app. it made windows hang completely and in dos i just get some weired characters on the screen. i dunno the intention of this program...
so i checked my own just by using the int 0x10 and the vga- and modeinfo-structs. after checking the version (0x0300 -> 3.0) i looked wheather the lfb is supported. (word @ offset 0 in modeinfo-block -> attributes. bit 7) it is supported. i also took a look at the address: 0xb4000000.
i think i'll do that later and output just on textscreen. it's more important to have multitasking and the OS-task running :)


and the :last: thing i want to do is just copy the code from MenuetOS. i've already taken a look at it, its brilliant - this, and a little bit more, sould my OS be able to do :). but i want to do as much as i can on my own. if someone asks me "what does this line in your code" i want to have an answer :)


greets, hartyl
Posted on 2003-02-24 13:27:26 by hartyl

...but what is int 0x31 use for? is it Bios Interupt ?

It's used to access the DPMI services.


huh?! you made me worry about that...
i don't know how i should launch your app. it made windows hang completely and in dos i just get some weired characters on the screen. i dunno the intention of this program...

I warned it's just a hack...
It should work on Win32, or dos running a DPMI driver.

So, most likely your display adapter uses 3 bytes per pixel for that mode...
Sorry about that.


so i checked my own just by using the int 0x10 and the vga- and modeinfo-structs. after checking the version (0x0300 -> 3.0) i looked wheather the lfb is supported. (word @ offset 0 in modeinfo-block -> attributes. bit 7) it is supported. i also took a look at the address: 0xb4000000.

Sounds strange...
Have you got any other (working) program that uses that VESA mode with LFB?


i think i'll do that later and output just on textscreen. it's more important to have multitasking and the OS-task running

Certainly.

It's better to build all the other things, before coding the GUI.

-Stealth
Posted on 2003-02-24 15:23:35 by Stealth
Here's a better version of that test program...
That one in the previous post was a damn crappy 'hack', probably the worst piece of code I have ever done (and had the most bugs in smallest program).

Ok, lesson #512: "Never code when you're too tired" :(

-Stealth
Posted on 2003-02-25 00:18:25 by Stealth


Have you got any other (working) program that uses that VESA mode with LFB?


i dunno, but MenuetOS works, i think i tested it with lfb. i haven't had that much time lately, but i'll test it asap.


i use 0x4118 (1024x768x16M), i'll also try with 800x600x32bit. this mode uses your lfb.zip::pm.com and it works.



greets, hartyl
Posted on 2003-02-25 12:12:47 by hartyl
So, it gotta be somekind of bug in your code, then.

-Stealth
Posted on 2003-02-28 23:10:54 by Stealth
i still didn't test yet :)
i finally got my timer ticking (:D) and i'm about multitasking. after that i'll do the gui and then i'll keep on working untill i get it. thanks for your help, i'll grab back to this thread. maybe i'll attach some further questions.

greets, hartyl
Posted on 2003-03-01 12:04:52 by hartyl
I'm glad, if I could be of some help.

Yeah, there's nothing like OS coding... Just me, hardware, and an empty memory waiting to get filled with stuff...
A true definition of freedom :grin:

-Stealth
Posted on 2003-03-02 03:19:38 by Stealth