Board.KolibriOS.org

Mario
Мог бы и не писать.
Все равно хабрапиплы всегда будут правы - у этой оськи никогда не будет никаких реально нужных практических применений.
И сейчас она никому нафиг не нужна.
Под нее даже и задач никаких специфических не существует.
И прошу заметить - никогда не существовало.
Так, одно недоразумение.
Потому что все равно винда (линукс, qnx) гораздо круче, и отлично работают во всех мыслимых ситуациях.

art_zh wrote:Mario
Мог бы и не писать.
Все равно хабрапиплы всегда будут правы - у этой оськи никогда не будет никаких реально нужных практических применений.
И сейчас она никому нафиг не нужна.
Под нее даже и задач никаких специфических не существует.
И прошу заметить - никогда не существовало.
Так, одно недоразумение.
Потому что все равно винда (линукс, qnx) гораздо круче, и отлично работают во всех мыслимых ситуациях.

Ну, я рад что ты встал на путь истинный и праведный.

Напомнило, как мы в школе ходили гулять к девчёнкам в ругой двор. Приходим как-то раз, они говорят: "Мы кое-что знаем"
Мы такие: "И что же?"
"А мы не скажем" и смеются.

leency
а тебя-то что конкретно интересует ?

As of revision #5154 KolibriOS kernel supports 16bpp VESA modes.

hidnplayr
Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.

Dell Inspiron 32bpp SVN r.5150

Spoiler:

dell_5150.png (6.89 KiB)

Viewed 7638 times

Dell Inspiron 32bpp SVN r.5154

Spoiler:

dell_5154.png (7.1 KiB)

Viewed 7638 times

Also we need to fix some of the programs that receive data through f.36 and GS.

Mario_r4 wrote:hidnplayr
Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.

Also we need to fix some of the programs that receive data through f.36 and GS.

Okay, I only removed "align 4" where it doesn't seem to make any sense.
If I'm wrong, please show me where or why and I'll be happy to correct.
Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150

Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?

hidnplayr wrote:Okay, I only removed "align 4" where it doesn't seem to make any sense.
If I'm wrong, please show me where or why and I'll be happy to correct.

I am very lazy person so I just put align4 everywhere.

hidnplayr wrote:Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150

Damn COPY-PASTE! The picture however are right. It's not so noticeable on a Dell Inspiron (core i5), but on slower machines this becomes more apparent. Unfortunately my RoverBook u800 is not working since r.5130. I will be testing 5150 and 5154 on eBox-3300MX and I will post the results later.

hidnplayr wrote:Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?

Problems exist for MGB and SCRSHOOT for 16 bpp modes. Perhaps there is any program yet.

btw, here are my test results (from virtualbox, in 800x600x32bpp mode)
align 4 can actually slow down code because it inserts NOP instructions in some code paths.

Spoiler:

PS: more is better.

eBox-3300MX 32bpp SVN r.5150

Spoiler:

ebox_5150.png (6.85 KiB)

Viewed 7709 times

eBox-3300MX 32bpp SVN r.5154
OOPS...

Spoiler:

IMGP9031.jpg (908.73 KiB)

Viewed 7709 times

Mario_r4 wrote:eBox-3300MX 32bpp SVN r.5154
OOPS...

What happened? System crashed/hung after loading RDC driver?
Just tested on my eBox, everything OK (32bpp and 16bpp modes work fine)

EDIT: Looks like I spotted the problem, expect a fix soon

please try again with #5157

Mario_r4 wrote:Also we need to fix some of the programs that receive data through f.36 and GS.

f36 works correctly, but f73 (blitter) is not yet implemented in 16bpp mode.

hidnplayr wrote:please try again with #5157

Yes, it's work fine. Thanks, great job and I withdraw my objections about align4.

Spoiler:

eBox-3300MX 32bpp SVN r.5150

ebox_5150.png (6.85 KiB)

Viewed 7653 times

eBox-3300MX 32bpp SVN r.5157

ebox_5157.png (6.96 KiB)

Viewed 7653 times

eBox-3300MX 16bpp SVN r.5157

IMGP9035.jpg (99.69 KiB)

Viewed 7653 times

hidnplayr wrote:

Mario_r4 wrote:Also we need to fix some of the programs that receive data through f.36 and GS.

f36 works correctly, but f73 (blitter) is not yet implemented in 16bpp mode.

I'm not sure about the correct operation f36. You can see in the picture the colors displayed on the screen and the colors obtained in f36 not conform to the format. The application expects that the color will be in the format 24bpp, but the current code simply copies 16bpp to 24bpp.

I think it is better to do the conversion 16bpp to 24bpp at the kernel level - it will solve the problem for many applications.

Spoiler:

IMGP9040.JPG (243.93 KiB)

Viewed 7651 times