VESA problem, help

[codemastersnake]

So proper order is like this ? : (in my case of course)
1. Set stack
2. Say hello
3. Check VESA and obtain framwork buffer address
4. Switch to proper video mode with framebuffer enable
5. Switch to protected mode
6. and what now ???
Okey so let say that I switch to pmode by setting cr register and so on and what next ? There is a lot tutorials on net about pmode so maybe i will gunderstand something but what should i do when i in pmode and have LFB adress (i get it when i was in real mode) ...

After switching to pmode: Write anything on the obtained address in the real mode of the LFB and results will be reflected on the screen!

[inflater]

Because it would destroy real-time performance.

For a simple occasional graphics mode switching? C'mon, 386 could do it in less than 5 seconds, so why a dual core 2.5GHz (today's common CPU) wouldn't?

Actually, to be fair, I found that addresing the floppy drive controller and reading from the FDD that way is way more slow than switching to rmode and using BIOS, because the FDC needs very correct timing for everything.

[jal]

Because it would destroy real-time performance.

For a simple occasional graphics mode switching? C'mon, 386 could do it in less than 5 seconds, so why a dual core 2.5GHz (today's common CPU) wouldn't?

rdos was explicitly referring to real time, embedded OSes, so switching to real mode would be a disaster in that case.

Actually, to be fair, I found that addresing the floppy drive controller and reading from the FDD that way is way more slow than switching to rmode and using BIOS, because the FDC needs very correct timing for everything.

There is nothing preventing you from getting such timing in a multi-tasking, pmode environment, it just takes more work.


JAL

[inflater]

There is nothing preventing you from getting such timing in a multi-tasking

It's the same thing like in a singletasking pmode OS... depends on your timer settings. Dont talk about you are unsure of.
The thing is, my pmode FDD driver is single-sector only, it reads one sector at a time and its way too slow. If I lower the timing, then it will fail on real machines, but it works and its pretty fast on either timings on Bochs. (Bochs doesnt emulate FDC timings BTW)

[jal]

Dont talk about you are unsure of.

You are advising people to do certain things they shouldn't, based on your personal taste and often questionable implementation. Telling people to abandon writing pmode FDD drivers because your pmode FDD driver sucks and therefore BIOS is faster is misleading at best.


JAL

[djsilence]

Hi, anyone!

I'd like to tell about DEX LFB demo. It works correctly. I've try to test it on VMWare, on my real PC(with Radeon 9200) - anything works great. I've made some functions (like draw_rect, draw_line, put_pixel, etc.), and all of them works!

But! All of them are written in asm. But i want to write my OS in C. I've tried to make an

Code: Select all

extern unsigned long * ModeInfo_PhysBasePtr;
GLOBAL _ModeInfo_PhysBasePtr
...

tried to push it in stack, and even:

Code: Select all

extern void fill_screen(void);

int main()
{
    ...

    fill_screen();

    ...
}

///////////

GLOBAL _fill_screen
_fill_screen:
      mov edi, [ModeInfo_PhysBasePtr]
      mov eax, 0x00FFFFFF
      mov ecx, x_res*y_res                     //I use 1280x1024; but the results are same in any other modes
      rep stosd
      retn

but nothing works. In asm - everything works great, In C - nothing.

Maybe, someone can help?

Thanks, for trying!

[ivarivar]

but nothing works. In asm - everything works great, In C - nothing.

Maybe, someone can help?

Thanks, for trying!

Hi. Maybe you can make an asm function which returns the adress (pointer) of LFB (in eax) to C.
And then use that if the extern thing is not working.
Good luck!

[~]

That simple mode number, from 0x0112 to 0x4112 solved my LFB access in one of my PC's.

So, does somebody know how is that some systems can have the LFB accessed with no problem by using a VESA video mode like 0x0101 instead of 0x4101?

For example, if using the Cirrus Logic emulation in Bochs (and plenty other real video cards), we can either use the mode 0x0101 and 0x4101 without apparent differences and easily access the LFB.

Unlike that, if I try to run the same code in an XCel2000 motherboard with an integrated VESA 2.x "SiS530,620 GUI Accelerator+3D" graphics card, it will fail in all VESA modes if we use mode numbers like 0x0101, 0x0113, etc., and once we use mode numbers 0x4101, 0x4113, etc., everything works fine.

In other words, does anybody know the reasons that some cards can work without the "VESA LFB Enable" bit set into the mode number?

And more importantly, is it a known behavior that some cards respond and others seem to not care about the mode's LFB bit, either giving "unconditional" access to the LFB or failing because of that?

[Combuster]

Most videocards have a LFB ready for you to use. In fact, you don't even need VESA code to use it, just grab a BAR from the PCI configuration space and you're set. Its much easier on the device to just give you the LFB address and be done with it rather than also having to emulate a banking mechanism.

The spec tells you the same thing between the lines:

WinASegment and WinBSegment address specify the segment address where the windows are located in the CPU address space. Note that these values are real mode segment values, so to convert the real 32 bit physical address you need to shift the values left 4 bits. Also note that if the hardware has only linear framebuffer modes available, the values listed in here will be set to 0 indicating the banked framebuffer is not available

[~]

Most videocards have a LFB ready for you to use. In fact, you don't even need VESA code to use it, just grab a BAR from the PCI configuration space and you're set. Its much easier on the device to just give you the LFB address and be done with it rather than also having to emulate a banking mechanism.

The spec tells you the same thing between the lines:

WinASegment and WinBSegment address specify the segment address where the windows are located in the CPU address space. Note that these values are real mode segment values, so to convert the real 32 bit physical address you need to shift the values left 4 bits. Also note that if the hardware has only linear framebuffer modes available, the values listed in here will be set to 0 indicating the banked framebuffer is not available

Yes, I have done that before, test one of the addresses from the PCI device to try and write there, mainly in my newer MSI K8MM-V AMD Athlon 64 3000+ PC. Strangely, if it's in 80x25 standard text mode and write to the address 0XF0000000 the system just locks as far as I can remember (unless it's in "VESA mode"), when its PCI information is something like this:

Code: Select all

 Bus 1 (AGP), Device Number 0, Device Function 0
 Vendor 1106h VIA Technologies Inc
 Device 3108h VIA/S3 Unichrome Pro VGA Adapter
 Command 0007h (I/O Access, Memory Access, BusMaster)
 Status 0230h (Has Capabilities List, Supports 66MHz, Medium Timing)
 Revision 01h, Header Type 00h, Bus Latency Timer 20h
 Minimum Bus Grant 02h, Maximum Bus Latency 00h
 Self test 00h (Self test not supported)
 PCI Class Display, type VGA
 Subsystem ID 71421462h Unknown
 Subsystem Vendor 1462h Micro-Star International Co Ltd (MSI)
 Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) : F0000000h
 Address 1 is a Memory Address (anywhere in 0-4Gb) : F4000000h
 System IRQ 16, INT# A
 Expansion ROM of 64Kb decoded by this card (Currently disabled)
 New Capabilities List Present:
   Power Management Capability, Version 1.1
     Supports low power State D1
     Supports low power State D2
     Does not support PME# signalling
     Current Power State : D0 (Device operational, no power saving)
   AGP Capability, Version 3.0 (AGP 8x and 4x, core register support)
     AGP Mode Enabled : Yes
     AGP Speed(s) Supported : 4x 8x, Currently : 8x
     FW Transfers Supported : No, Enabled : No
     >4Gb Address Space Supported : No, Enabled : No
     Sideband Addressing Supported : Yes, Enabled : Yes
     AGP v3.0 Operation Mode Available : Yes, Enabled : Yes
     Isosynchronous Transactions Supported : No
     Maximum Command Queue Length : 256 bytes, Current Queue Length : 32 bytes

In the other case I mentioned, I could set a VESA mode via the BIOS, and I could write only to the first 64Kb video window ("banked" memory area) if I use something like 0x0101 instead of 0x4101, with PCI information like this:

Code: Select all

 Vendor 1039h Silicon Integrated Systems (SiS)
 Device 6306h SiS530,620 GUI Accelerator+3D
 Command 0007h (I/O Access, Memory Access, BusMaster)
 Status 0230h (Has Capabilities List, Supports 66MHz, Medium Timing)
 Revision 2Ah, Header Type 00h, Bus Latency Timer 40h
 Minimum Bus Grant 02h, Maximum Bus Latency 00h
 Self test 00h (Self test not supported)
 PCI Class Display, type VGA
 Subsystem ID 63061039h SiS530,620 GUI Accelerator+3D (Generic ID)
 Subsystem Vendor 1039h Silicon Integrated Systems (SiS)
 Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) : EE800000h
 Address 1 is a Memory Address (anywhere in 0-4Gb) : EF6F0000h
 Address 2 is an I/O Port : 0000CC00h
 New Capabilities List Present:
   Power Management Capability, Version 1.0
     Supports low power State D2
     Does not support PME# signalling
     Current Power State : D0 (Device operational, no power saving)
   AGP Capability, Version 1.0 (AGP 1x and/or 2x support)
     AGP Speed(s) Supported : 1x 2x 
     FW Transfers Supported : No
     >4Gb Address Space Supported : No
     Sideband Addressing Supported : No
     Maximum Command Queue Length : 2 bytes
     AGP Speed Selected : None Selected
     FW Transfers Enabled : No
     >4Gb Address Space Enabled : No
     AGP Enabled : No
     Sideband Addressing Enabled : No
     Current Command Queue Length : 1 byte

And LFB address for the VESA mode selected isn't EE800000h or EF6F0000h, but E0000000h for mode 0x4101 according to the gathered ModeInfo block. So at least in my experience I have got system lockups and some "malfunctioning" cards if I don't take into account the little details I mentioned above to avoid chances of "instability" while possible.

Maybe it's something that works right more commonly in newer systems than in those built like 8 years ago, I don't really know... I haven't tested whether some PCI address pointed above changes every time the video mode is switched either. If that isn't the case, then I like many others would really appreciate to know how or what to look for from the PCI information of the device. I have no more information for that.

[djmauretto]

Hello
Here there is a Vesa info utility that i wrote some time ago for
DOS , Windows98/2000 , XP.

Vesa 1.4.zip

[djsilence]

Hi, ivarivar!

I tried to do something like this:

Code: Select all

mov eax, [ModeInfo_PhysBasePtr]          //ModeInfo_PhysBasePtr is valid! It gets by int 0x10

                                                       //I use EXE file format (like in BrokenThron.com tutorial
call ebp                                             //So my ebp = 0x0010000 + EXE_AddressOfEntryPoint
                                                       //It works great


...........................................................................................................

#define x_res 1280
#define y_res 1024

int main()
{
          unsigned long* addr;

          _asm mov [addr], eax                   //MS VC++ asm syntax

          for (int i = 0; i < x_res*y_res; i++)
          *addr = 0x00FFFFFF;

          . . . . . . .

}

Nothing. Do I right understand you?

Thanks, Daniel!

[djsilence]

I lost one '0' in my ebp address in previous reply!