Wrong, you don't need INT 0x10 at all. You can write a native BGA driver using this information.fano1 wrote:The only way to drive BGA is using VBE right?
BGA doesn't have hardware acceleration.fano1 wrote:I don't think it is more slower emulating VBE but I have little hopes that using it natively it will have hardware accelerations to draw lines, rectangles and so on...
I may try playing around with that when I get a few minutes...Looking at http://bochs.sourceforge.net/doc/docbook/user/x75.html it
tells you to use the LGPL'ed VGABIOS.
What kind of code is in that for loop? There are some potential optimizations that don't involve writing it in assembly.fano1 wrote:I wanted a Clear(Color) command and I've done it but it is really inefficient as for now our fill method is simply using a for() of words so it is doing 4'000'000 of times! I fear I'll have to resort to X# (that is assembler)
There are different levels of difficulty...fano1 wrote:it seems for now the only solutions would to have a real VBE driver (but is difficult to do this / impossible in protected mode)
It's not unusual for video cards to have standard VGA registers and extended non-VGA registers. The only difference is that Bochs puts the extended registers at a different I/O address. With SVGA cards like the Cirrus (which Bochs also supports), the extended registers are accessed the same way as the standard VGA registers.fano1 wrote:or to have an hybrid solution and set registers that in this driver should not exist.
They already do have a way to return to text mode: disable the extensions and set up text mode using the standard VGA registers.fano1 wrote:Probably the better way will be to fix the Bochs VBE extensions and add a way to return to text mode
That's exactly how Linux does it.fano1 wrote:The idea to do the "text mode" all in graphic mode is securely a possibility I suspect that Linux does this or how Tux could be in the right corner of the screen?
The code is written in C# but is in an unsafe block so the de facto should be fast as C code:Octocontrabass wrote:What kind of code is in that for loop? There are some potential optimizations that don't involve writing it in assembly.fano1 wrote:I wanted a Clear(Color) command and I've done it but it is really inefficient as for now our fill method is simply using a for() of words so it is doing 4'000'000 of times! I fear I'll have to resort to X# (that is assembler)
Code: Select all
public unsafe void Fill(UInt32 aStart, UInt32 aCount, UInt32 aData)
{
UInt32* xDest = (UInt32*)(this.Base + aStart);
for (UInt32 i = 0; i < aCount; i++)
{
*xDest = aData;
xDest++;
}
}
OK for now our plan is to support Virtual Machines with this BGA/VBE driver we have covered Bochs, QEMU and Virtualbox already, we have a driver for the VmWare GPU too but need to be tested to see if it works.Octocontrabass wrote:There are different levels of difficulty...fano1 wrote:it seems for now the only solutions would to have a real VBE driver (but is difficult to do this / impossible in protected mode)
The easiest is to write an x86 instruction interpreter and put together a small emulator. You can simulate INT 0x10 in your emulator to control the video card. As long as you are aware of the limitations (it only works with legacy BIOS, not UEFI; it needs to read/write the IVT and BDA) you'll be fine.
Interesting... nevertheless UFT-8 not works in Linux a simply accented 'è' risk to appear as something weird never understood what they do of wrong I suspect that the problem are really in the fonts!Octocontrabass wrote:That's exactly how Linux does it.fano1 wrote:The idea to do the "text mode" all in graphic mode is securely a possibility I suspect that Linux does this or how Tux could be in the right corner of the screen?
You may be able to gain some speed by unrolling the loop, especially if you mostly use this function to fill the entire screen. There are limits to what you can gain through loop unrolling, so do benchmarks if you don't see obvious speed differences.fano1 wrote:The code is written in C# but is in an unsafe block so the de facto should be fast as C code:
[...]
Indeed I suspect this code will not fast in C too... I'm unsure if C memset() is faster to fill a 9 MB array!
There's a lot more to Unicode than just fonts. There may be other reasons for your text being mangled.fano1 wrote:Interesting... nevertheless UFT-8 not works in Linux a simply accented 'è' risk to appear as something weird never understood what they do of wrong I suspect that the problem are really in the fonts!
To unroll the loop is to take everything out of the loop, example:fano1 wrote:What do you mean to unroll the loop?
Code: Select all
// before loop unrolling
for (int i = 0; i < 3; i++)
foo(i);
// after loop unrolling
foo(0);
foo(1);
foo(2);
You mean MMIO, not port IO, right? And yes, you may be right about MMIO being slower than RAM. That's why I said to benchmark your optimizations: they may not be faster than what you already have.fano1 wrote:but I'm thinking there is bigger difference too I'm writing to RAM not to a IOPort that could be slower...
Generally, memcpy() is slower than memset(). In practice, the LFB may be too slow for that to make a difference.fano1 wrote:maybe an optimization could to do the for() in a byte[] and only at the end assign the array to our MemoryBlock. What do you think?
Code: Select all
int[MemoryBlock.Size] buffer;
UInt32* xDest = (UInt32*)(this.Base + aStart)
fixed {
int *bufferPtr = buffer;
for (UInt32 i = 0; i < aCount; i++)
{
*buffer = aData;
buffer++;
}
xDest = buffer;
}