Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I left a scheduler test on to make sure it wouldn't leak any memory over a long period of time by setting up two threads (one to spin idly, the other to instantly invoke KeSyscallYield and give up its time share whenever it received one) and letting it sit. Didn't lose any memory, but I lost a chunk of hard drive space, having accidentally left the scheduler debug statements turned on...
I came back to find a very large serial dump file with this over and over and over and over...
What is ironic is that you would probably have a pretty hard time writing code to do that, if you were doing it on purpose.
You guys should start with simple REPD copying until everything is stable, and then swap it out with a faster method after it has been tested.
Step 1: make it work.
Step 2: make it fast.
Step 3: make it bulletproof.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
osdeverr wrote:Tried to implement double-buffering
That is what happens to me every single time I try to implement it. I couldn't fix it for months so I gave up. SSE memory copy is just too tough.
Old picture of mine:
[imgsnip]http://forum.osdev.org/download/file.php?id=3349&mode=view[/img]
It looks quite cool though. Double mouse support anyone?
Yeah it does look cool but not functional. It looks like that I am better at creating mosaics than coding.
Dual mouse support would be epic, just image that! Endless possibilities.
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
I'm currently writing a native graphics mode setting driver (for the Intel G45 chipset) for my OS. This is what happens when you set a bad pixel clock . This imgur album (click me) has another funny fail and a picture of the working driver.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
I'm currently writing a native graphics mode setting driver (for the Intel G45 chipset) for my OS. This is what happens when you set a bad pixel clock . This imgur album (click me) has another funny fail and a picture of the working driver.
That is actually impressive! Btw what do you mean by native graphics driver? Setting a bad pixel clock? What is your method, VESA or VGA?
OS: Basic OS
About: 32 Bit Monolithic Kernel Written in C++ and Assembly, Custom FAT 32 Bootloader
octacone wrote:That is actually impressive! Btw what do you mean by native graphics driver? Setting a bad pixel clock? What is your method, VESA or VGA?
I'm using neither VESA nor VGA. I manipulate the native registers of the graphics card (i.e. I set a pixel clock, display timings, program the framebuffer address and enable graphics output). The driver can set any mode (e.g. 1920x1080@32bpp) that is supported by the card and the monitor. I do not have to use the BIOS or any third party functionality. However keep in mind that the driver is tied to Intel G45 and similar chipsets.
It is easy to extend this to hardware double/triple/whatever buffering on VSYNC, hardware mouse cursors, hardware overlays (i.e. displaying a second framebuffer inside a window) and multiple monitors. My code does not support acceleration (BLTing or shaders) yet though.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].