OSDev.org

hi,
i'm trying to write something to screen using vbe. the problem is that i can't draw the figures that i want in colors that i want.so, how can i do it?.also i've tried with vga, and it works, but it's in vesa.h like a comentary, 'cause its low resolution.

i actualy read GUI, Vesa Video Modes, Drawing in protected mode, http://www.osdever.net/tutorials/view/gui-development and some other pages that i don't remeber.

Thanks!

Without more details, you may not get much help. Why can't you draw the figures you want?

Once you have set a screen mode using the VBE BIOS, most of the time you now have a Linear Frame Buffer ready for pixels to be placed in it. However, you have to place these pixels as a specific size, 8-, 15-, 16-, 24-, or 32-bits each, as well as in the correct places.

There are details in the VBE "get video mode details" call that tell you how many bytes there are per scan line. Sometimes this value is more than the number of pixels in a scan line. You have to account for this. Also, the VBE will tell you how many pixels are used for the BLUE value, as well as the position this BLUE value is within the pixel. The operating model (memory_model field) will tell you if you can assume RGB sizes and positions or if you have to extract these values from the data returned.

Please give more information why you can't draw to the screen.

- Ben
http://www.fysnet.net/osdesign_book_series.htm

i can draw to screen, but not something "controlled", see that while excecuting my os ,will give you a image with all pixels of different colors all around the screen

I downloaded your ISO image and tried to emulate it under Bochs. After Grub let me choose the one and only option, it cleared the (emulated) screen, left a blinking cursor in the top left corner, then Bochs exited with the following:

It didn't get any further.

Ben

you have to download the source and build it. probably i forgot to update the iso image

I did have a look at your code a bit. You assume that the VESA mode values are default and valid. This cannot be assumed anymore.

i.e.: You assume that by setting to mode 0x101, you will have a width of 640 and a height to 480. Though this will probably be the case, you should not assume this. The VESA clearly states that mode numbers are no longer a default to a specific mode. You *must* parse the information returned by a specific mode and use that information instead.

Also, may I make a few suggestions? You may take them as you wish.

You seem to use GRUB to boot your kernel, maybe so that you don't have to write boot code. Okay, but GRUB places you in a protected mode state. Therefore, you write a v86 mode driver to get you back to real mode so that you can set the screen mode.

In my opinion, it is a lot easier to write boot code than it is to write a good, working V86 mode interface.

If you write boot code, you are in 16-bit real mode where you can change the screen mode without any v86 interface, then move to protected mode. However, now you have to write the code to parse the file system to load the ISO.

Therefore, one way (the way you have done it):
Pros:
1) Don't have to write boot code.
2) Don't have to write file system parsing code.
3) Don't have to write code to move to protected mode.
Cons:
1) Have to write a virtual 86 interface just to get back to real mode to set the screen.

The other way:
Cons:
1) Have to write boot code.
2) Have to write file system parsing code.
3) Have to write code to move to protected mode.
Pros:
1) You are still in real mode, before 3) above, and can set the screen mode.
2) No need to write a v86 mode interface.

It is six of one and half-a-dozen of another of which choice you make. I took the second route...

Ben

well, i already have a VM8086 due the protected mode of grub, so there is no reason for writing boot code.

so i have to use the values provided by the function int 10h/ ax = 0x4F01. but there still having the question about the color and position of what i want to draw. almost not the position but the color

And that is your opinion, and I respect that. My opinion is the video mode and any other information or task that must be done by the firmware, in this case the real-mode BIOS, should be done before moving to protected mode.


The color is made up of three fields, Red, Green, and Blue. However, where these fields are and the size of these fields is determined by the mode returned. For example, if the mode returns a Model value of 0x04[1], you can assume the positions and sizes depending on the width of the pixel. If it returns a value of 0x06[1], you must extract the positions and sizes from the mode info returned.

Once you have the positions and sizes of each of the three fields, (R G B), you can then form a color shade.

For a (mostly) red shade, make the R value a high value and the other two low or zero. For a green shade, the G value. Etc. You can combine the values to make Yellow, Purple, etc.

A good reference for these values would be something like: https://www.rapidtables.com/web/color/RGB_Color.html

Ben

[1]This is from memory, so please verify with the specifications.

ok. using what http://www.ctyme.com/intr/rb-0274.htm#Table79 says. if i move 0x12 to [ES:DI], then i will get the width of the screen, and the same moving 0x14 for giving the height.but i cant move a value to a segment:offset directly, so how can i?.

I'm pretty sure this doesn't make sense - GRUB does not, and cannot, set up a VM8086 process for your OS at boot time. I may be misreading what are saying, but if you think that you would have a VM8086 process mode provided by GRUB, you are mistaken.

Just to clarify: my understanding, based on things I have read about this (going back to the late 1980s, though I have since learned - I hope - a lot more about it), is that VM8086 is a mechanism for running real mode code in a system that is otherwise running in protected mode. It isn't a CPU mode in and of itself; it is a virtualization mode for an individual process running on the CPU. The rest of the system, and the kernel in particular, is still running in 32-bit protected mode.

Protected mode is a CPU mode, something that changes the behavior of the CPU at the hardware level. When running a VM86 process under a p-mode OS, the 16-bit code is executed in a local mode that treats addresses as 20-bit segment/offset pairs (often with the segment being assumed to a specific segment register), and traps any privileged instructions or out-of-range memory accesses as exceptions, which then get either handled or emulated by the p-mode kernel.

The point is, you need a fully operational kernel, with memory management, interrupt handling, and process scheduling, before you can spawn a VM86 process that won't crash the system. While GRUB gives you a minimal protected mode environment when it hands the system off to the kernel, what you have at that point is not enough of a working system to do that - all you get from GRUB is a starting position, just enough to give you room to work.



Let me be honest with you: I don't recommend jumping into the graphical aspects of the system yet, anyway. While the James T. Klik archetype is a known approach, it is not really a great one (IMAO), as an effective GUI design really needs a working kernel underpinning it. At this stage, just getting a Text UI is going to be hard enough, and even if you have no intention of having a user shell, you probably will need to use one for a while until you have more fundamental system services - services which the GUI will depend on - working and stable.

no, grub do not setup a vm8086. i mean that due the Protected mode that grub sets, i included a VM8086. well, then i have make first memory management, a shell,a chrash and error handler(?), and start with graphics later?

Have to? Well, some of it, yes - certainly a GDT, a rump set of interrupt and exception handlers (that is, at least something that catches the basic physical interrupts such as the clock, and basic exceptions such as divide by zero, even if it doesn't do anything with them), and an IDT for vectoring the interrupts to them. You definitely will need at least that much first, as the VM8086 will need those to run, if nothing else.

All of it? Maybe not, technically, but trying to jump straight to the GUI from there is likely to be harder than getting a more complete system set up first. Process scheduling, a minimal driver for the keyboard, enough of a text print out setup that you can test those functions, all that would make sense as a scaffolding to make sure that the parts that the GUI itself will rely on are working before moving on to the graphics drivers.

I would strongly recommend that you have a basic scheduler and process launcher (something equivalent to the Unix fork()/exec() pair or the Windows spawn() functions, even if you don't expose it to the user-space applications), so you can have at least one process - the VM8086 one, presumably - running in user space. If you are planning a purely monotasking system, this isn't really necessary; but even in a system with only a single user process, it is useful to be able to have separate system processes which can do basic background stuff.

A HDD driver and file system would make sense as well, at least enough of one that the boot loader won't have to load everything into memory at once. If you choose to use virtual memory - which would be very useful in dealing with a VM8086 driver that only needs to run infrequently, as well as for a number of other reasons - you will need disk access and possibly file services, again. Fortunately, the disk interface is something that can readily be done in protected mode without needing any Legacy BIOS operations - no VM8086 needed there at all.

As for anything else, and which to do first, that's going depend on your OS design plans. If you do want to aim directly at the GUI as fast as you can, I would suggest first trying to think of all the things that you would need to have running first before you can do that. Read through the different parts of the wiki and browse older posts a bit, and when you think you have a decent list of things your GUI would depend on, post it here and we'll see if we can spot anything you missed or make any further recommendations.

Schol-R-LEA, your memory of the v86 mode is really close, though it is actual hardware that does the switch. You use hardware tasking, the hardware tasking of the CPU, to switch to a v86 task. It is very difficult to get correct, especially for a newbie. The reason it is hardware, as I am sure you know, is you must tell the CPU to use the lower half of some registers, like ESP and EIP for example, as well as only push two bytes and not four when CALLing, etc.

In my opinion, if you are going to use hardware tasking to move to v86 mode, you might as well use hardware tasking for all tasking. I have since commented out all my v86 code and may not re-instate it at all. It really is a nightmare to make sure it works correctly. And of course is completely gone in long mode, so I've heard.

alberinfo does have his/her own v86 code, though it looks to be copy/pasted from another project.


alberinfo, I think you are mistaken here. On the call to the service, you place a 20-bit real-mode segmented address into the ES and DI registers of a memory buffer large enough to hold the information returned. The BIOS will fill this buffer with the requested information and return. Then you can extract the information from that buffer.

If you know nothing of segmentation and real mode, this will mean absolutely nothing to you.

How much do you know of real-mode segmentation addresses?

Ben

about segmentation adress... nothing?i was reading the past day something about it, but i forgot all that i have readed.

To be able to call the v86 correctly, and use it correctly, I suggest you look up and read a little about segmentation. Since the real-mode 8086 could only use 16-bits and had a 20-bit address bus, it needed some way to access the whole meg using only 16-bits. Segmentation, with 64k segments, was/is used. The ES: part is the 64k segment address, with the DI part being the offset within that segment.

A physical address can be found by ADDR = ((ES << 4) + DI) while a segmented address can be found by ES = (ADDR >> 4) and DI = (ADDR & 0xF).

If you can allocate a block of memory within your kernel before you call the v86 mode, the above line should give you enough information to pass the physical (or segmented) address to the v86 code.

Hope this helps. Note that ADDR must be equal to or less than ((0xFFFF << 4) + 0xFFFF) not counting the location of the BIOS itself.

Ben