OSDev.org

Hello everyone!
Is it possible to use higher resolutions than 320x200 in real mode? I have my functions for getting and setting video modes using VBE, but with higher resolutions I'll need more memory than the 64KB available at 0xA0000.

Thanks in advance,
Fergo

I think you'll have to use vesa with bank switching, otherwise I don't think i'ts posible to put a framebuffer (for example 800*600*24) in a real mode with only 1MB address!

Cheers,
Gonzalo

why dont you set up unreal mode?

gzaloprgm wrote:I think you'll have to use vesa with bank switching, otherwise I don't think i'ts posible to put a framebuffer (for example 800*600*24) in a real mode with only 1MB address!

Cheers,
Gonzalo

Thanks! I'll search for this "bank switching" thing. If not asking too much, do you have an example code?

lukem_95 wrote:why dont you set up unreal mode?

Well, I'm a starter in OS programming, I don't feel prepared to code even in protected mode. I've never looked at this "Unreal Mode" though, so I don't know if it is easier or harder, but I'll try to find something about it. Thanks for the advice ;D
(if you have some code samples or papers to recomend either...)

Thanks again to both of you ;D

Fergo

Look at Dex's post in my thread:

http://www.osdev.org/phpBB2/viewtopic.php?t=15028

Ask him in which register should you put the bank number, I never used it.

Cheers,
Gonzalo

You can refer the VESA spec.
VESA has a method to access all display buffer.

Yes, but since rmode uses 20bit addressing (if you enabled A20) , a linear framebuffer is 1440000bytes (800*600*3) and the max of rmode is 1048576bytes (1MB), it doesn't fit.

Hi,

gzaloprgm wrote:Yes, but since rmode uses 20bit addressing (if you enabled A20) , a linear framebuffer is 1440000bytes (800*600*3) and the max of rmode is 1048576bytes (1MB), it doesn't fit.

In this case (with a "bank switched" video mode) you'd get 22 seperate banks, where each bank is 64 KB of display memory. The selected bank is mapped into the 64 KB from 0x000A0000 to 0x000AFFFF. You can accessed the selected bank in real mode, and you can select a different bank in real mode, so therefore you can access the entire frame buffer in real mode (in an awkward way).

The problem is that (for 24 bits per pixel) you get pixels in seperate banks. For example, there's 21845.3333 pixels per 64 KB bank, and for "800 * 600 * 24 bpp" there'd be 27.30666 lines per 64 KB bank.

This is what makes "24 bits per pixel" a pain in the neck (it's painful enough with a linear framebuffer). Using unreal mode and a LFB isn't really a bad idea, especially if you're using a buffer in RAM (e.g. double buffering).

Also note that some (older) video cards don't support linear frame buffers at all, so for the highest level of compatability you might want to consider supporting both methods (bank switched and LFB with unreal mode).

Of course a better idea might be to use protected mode, and perhaps even use paging to emulate a LFB on video cards that only support bank switching...


Cheers,

Brendan

Here is a old post of mine, that may help

As your in realmode you limted to 64k, so this mode uses 1 boxs 64k in size, you need to switch boxs eg:
********box0****
64k
********box1****
64k
********box2****
64k
********box3****
64k
********box4****
64k
****************
Here this may help

Code: Select all

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;                                           ;;
;; fasm example.By Craig Bamford (Dex) 2002. ;;
;; 640*480 8bpp (256 colors) vesa1           ;;
;; C:\fasm vesa1.asm vesa1.com               ;;
;;                                           ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
ORG    100h

Start:
        mov ax,4f02h
        mov bx,101h
        int 10h

        mov dx,0xa000
        mov es,dx
        call window

StartAgain:
        xor dx,dx
        mov [color],0	   
MainLoop:
        push dx
        call window
        xor bx,bx
        inc [color]
        mov al,[color]
        call static

        pop dx
        cmp dx,4
        je StartAgain
        inc dx  ;<** here is box number
        mov ah,01h
        int 16h
        jz MainLoop
        mov ah,00h
        int 16h
        mov ax,0003h
        int 10h

        ret

window:
        mov ax,4f05h
        mov bx,0
        int 10h
        xor bx,bx
        ret

static:         
        stosb
        inc bx
        cmp bx,0x00000
        jne static
        ret




color    db         0
Row      db         0

The code will work fine with little modification from your boot code.

I also have vesa demos, of using LFB from pmode, if you need them, let me know and i will post link.

Thanks for the support people, I really appreciate ;D
Dex, in the code you've posted, those boxes are the banks as explained earlier or I'm making some confusion?

About the VESA demos: as I said, I think I'm not ready for PMode yet, but I try to save and backup any information that I find on the internet (in case that the website goes offline and stuff like that), so If you could post those demos, I'd really appreciate. When I feel ready to go for something bigger like PMode, I'm sure those demos will be very useful.

Thanks again to all of you, and sorry for my english.

Regards,
Fergo

Fergo wrote:Dex, in the code you've posted, those boxes are the banks as explained earlier or I'm making some confusion?

Yes you are right, those boxes are the banks.

Here's one of my pmode vesa demos, that also demos vesa fonts.
http://www.dex4u.com/demos/VesaTxtDemo.zip

In the zip you will find the fasm source code and a selfextracting exe to put the bootable demo on a floppy.

PS: As you going for a realmode OS, i wrote a basic dos clone, as a tut, it may help.
See here: http://board.flatassembler.net/topic.php?t=5275&start=0

...the "boxes" are also called "windows"