testing KolibriOS
After a long time of doing nothing on my computer I decided to test the latest KolibriOS and OctaOS... I don't know why but VESA works perfect on OctaOS on my old AMD k6-2, without flickering even when I moved all the entire desktop... an KolibriOS has a lot of problems about this, OctaOS doesn't ask anything on system startup... very nice job, I was thinking if that could be posible in KolibriOS... cause is very anoying to search manually for the right resolution, I have to reboot my computer every time I make a mistake (my monitor doesn't suport VRR :S.. and I get resolution errors if I use VESA 3.0+ another problem I'have seen in the current KlibriOS distro is a little problem when I press the keyboard, for example in Tinypad (it's the same in any program), if I press for example the "Up" arrow on the keyboard and release it 2 or 3 seconds later, then the cursor(in tinypad) keeps going up a few seconds... the same happens on KFar... when I press "Down" key to select a folder and release the key a few seconds later, then the "select mark" (i don't know how to call it) keeps going down to other folders :S maybe the OS puts all the pressed keys on the queue and the programs keep moving their "keyboard controled" things until the queue is empty.... but is very annoying when you are reading a text and press the down key to keep reading the next 3, or maybe 4 lines, but the cursor keeps going down about ten or fifteen lines... I don't know if thi happens on fast machines, but it happens on my AMD (450 Mhz)... and the flickering also is very very obvious... is almost unconfortable to work for exapmple with tynipad be cause every click you do on the menu, everything is redrawed thanks to all for your time, I LOVE this OS... I hope my report will be helpfull to fix some small problems :)

Don I have available Cyrix6x86MX-233. I shall try to check up that you have written. Earlier I did not see on this attention. I shall look it is possible to decide this problem.

It`ll be great if u post OctaOS site link ^_~ google says nothing to me :)

The OctaOS was written by the spanish man Octavio Vega, but no longer in development.

who told you that??? I mailed Octavio three days ago about the OS... he IS still developing it... the project is alive... I tested the OS a week ago and I saw that it didn't flicker when you move the windows :? here is the link http://octaos.joox.net/ it's written on OctaASM, his own assembler... on the OS you write code and it's automatically executed. you don't need to compile it to an executable file.... strange isn't it? but it also has suport for writting programs on fasm 1.66

>on the OS you write code and it's automatically executed. cool! :) let see. PS> no source?? :(

yes, I checked that too... the source code is included on the floppy and cd image you can download from the site

Don I have checked up what you wrote about. Really output of the applications in OctaOS smoother, but in KolibriOS it occurs not because of absence VRR. OctaOS displays the map with frequency of the horizontal scanning 60Hz, KolibriOS too. There is a difference in output of the window of the application and mouse pointer. 1) The mouse pointer is in general output as inversion of the main map. Such approach is much faster, but the figure of the cursor does not look beautifully, is especial on the multi-coloured image. In KolibriOS at the moment of drawing windows the cursor is switched off. Certainly, it is possible to output the cursor, not switching off it, but it requires more complex algorithm of output. In the future we probably and shall make, but, unfortunately not so fast. 2) Structure of windows of the applications more simple, are absent: gradient the flood filling and buttons, probably, is absent still, that be, it allows, to output more fast, but this simplified image. For example, Tynypad (especially newest) has complex structure of the window. If in Kolibri were of the driver of videomaps, you would not notice drawing, but as all works in VESA, unfortunately, speed of output low. More complex structure at output always requires more time. By the way you can try last kernels with SVN or http: // kolibrios.org /? p=Download since revision 112, Ivan Poddubny has improved some things in output of windows, probably, it will help you slightly. The code autodetection of valid modes of a graphics is in a stage of completion of development. In this question is engaged mike.dld Unfortunately, I can not finish all parts of a kernel, I am engaged in a plenty of the code, but not by all kernel nevertheless. The problem with backlog of processing of the buffer of the pressed buttons really is present. However appears in main on slower computers. It is not present on my Duron950 (958 MHz), but it is observed on my Cyrix 6x86MX 233 (187,5 MHz). I shall try to decide this problem, probably, still who be, will try to decide it. The problem exists also it is necessary to decide. Thank for attention. Good luck.

Don The problem with delay of processing of pressing the keys on slow computers is decided through decrease of depth of the buffer in a kernel. In a folder HID there is a file KEYBOARD.INC, this code: .dowrite: movzx eax, byte <0xF400> cmp al, 120 jae .exit.irq1 inc eax mov <0xF400>, al mov <0xF400+eax>, bl It is possible to replace cmp al, 120 On cmp al, 2 In result the buffer will not be used and the problem disappears. However I did not check all subtleties, it is possible for what be of cases originating in the separate applications it is undesirable. However I yet have not detected any additional errors. Good luck.

Thank you Mario79, I'll try it today