gui painting?

[Ready4Dis]

You did very well to fit all that in 8k Ready4Dis , I do not use windows in my OS, it was just for people who want to have them in there user program, that code for DexOS.
I use more menu driven like in Xbox etc.

Also you should not have been so quick to redo your (nice) ASM kernel on portability grounds, as i am porting DexOS to ARM very easly and the assembler fasm, was made into a good cross assembler by just changing 1 or 2 include files

Yeah, I know, but it was trending towards a monolithic kernel, which wasn't the direction i wanted to head. I am re-using some of the code (a lot of x86 specifics are still in ASM, for example, paging mechanisms, which does all the x86 paging specifics). I am not sure how much will stay asm and get converted to C, but I am re-writing all my module handling code in C. I am also working on adding relocation code so I can load system drivers to any location, rather than load them to a static location like user apps. I was working on a program to convert coff and a.out files into an os specific format (remove symbols, and just leave the relocation table). I'm kinda curious how your DexOS to ARM went, I mean, I already figured a ton of things that will need changing, like the entry code, paging mechanism, PIC stuff (the timer interrupt), all the interrupt code, etc. I haven't looked to much into arm, but I am interrested in porting to my PocketPC and macintosh power pc as well (although, they are migrating to intel cpu's soon aren't they?). I checked out your page, looks cool, glad your OS is doing good, I'll hopefully have a demo version sometime in the near future, after this relocation stuff is done and I can re-implement my drivers, lol.

Ok, just checked, my latest build of the asm kernel was 5,913 bytes. Forgot I added all that ascii bitmap to my gui, it weighs in at 81,728, the ascii map consists of 73,784 bytes of that, so the gui + cursor + windows weighs in at 7,944 bytes. I guess I could convert my ascii table over to bit based rather than byte based, would save a lot of space . Guess I'll fgure that out once I get it all re-implemented, either that or change over to another type of font types.

Anywho, nuff bout my OS, if you wanted to talk about that stuff, or any specifics, feel free to message me. I hope the OP got enough information, any more questions, we'll be here.

[Dex]

I'm kinda curious how your DexOS to ARM went, I mean, I already figured a ton of things that will need changing, like the entry code, paging mechanism, PIC stuff (the timer interrupt), all the interrupt code, etc. I haven't looked to much into arm, but I am interrested in porting to my PocketPC and macintosh power pc as well (although, they are migrating to intel cpu's soon aren't they?)

Its going well, but the DexOS is based on KISS and as such, it only need to load a program into memory and give it control, Also gives it access to lot of built in functions.
Here how easy ARM is, this a boot sector of 99% of ARM chips

Code: Select all

:****************************************;
; ARM BootLoader.                        ;
;----------------------------------------;
; Prog by Dex.                           ;
; Coded with FasmARM.                    ;
; Part of the the x86 to ARM Dex4u port. ;
; C:\fasmarm ArmBoot.asm ArmBoot.bin     ;
;                                        ;
;  C Bamford.2006(c)                   ;
;****************************************;
format binary
org	0			      ; code starts at offset 0.
use32				      ; use 32-bit code.

        b     reset                   ;
        b     undefined_instruction
        b     software_interrupt
        b     prefetch_abort
        b     data_abort
        b     not_used
        b     irq
        b     fiq

align 4

;********************************;
; boot start.                    ;
;********************************;
reset:
; you main load code would be here;

LetsLoop:
	b LetsLoop

;********************************;
; just Loop For Now ;)           ;
;********************************;
undefined_instruction:
software_interrupt:
prefetch_abort:
data_abort:
not_used:
irq:
fiq:
LetsLoopForNow:
	b     LetsLoopForNow

Note "b label" is like "jmp label"
As you can see from these labels you can write the code for int etc.

[Ready4Dis]

ahh, looks pretty easy, lol. Only other CPU's i've programmed for were r4300i (n64 asm) and a microchip pic18f series cpu, haven't dabbled in ARM at all, but that seems really simple so far, I may check it out sometime soon, but first I need to get my OS back together and finish up all my library/plugin support, re-write my vesa driver, add a bit more code to the GUI, finish up IPC, add priveledge levels to user apps, re-write my scheduler, and, well, you get the idea i'm sure .

I'm assuming that b is short for branch, and you are branching on no condition, so it continuously does so, or am I way off?

[Dex]

I'm assuming that b is short for branch, and you are branching on no condition, so it continuously does so, or am I way off?

You are right,:).
The boot loader is stored in flash and at bootup the first 4k of flash is loaded to the start of ram, and control is given to the first address that all it does at start up, no checks, just load and jump to.
So we end up at "reset" and we need to set things up from there default setting to more useable ones, if we got a software int, we end up at "software_interrupt
", but that a differant story.
Good luck with your OS.

PS: The loops are just a demo, in real life you would have your code for that case there.

[Ready4Dis]

Yeah, I got you, that is cool, similar to how PIC microchips work, except you are responsible for all hardware as well, you can't just tell it to input from a location, you have to read or get interrupts from pins going high/low and translate that data into something useable, or get analog readings from analog pins (for things like temperature sensors, etc). I was working on a fuel system for my motorcycle and car with the PIC, got it mostly functional now, all the inputs from tachometer pulses, temp sensors, manifold pressure, etc, as well as interface to my laptop via serial port for flash real-time data aquisition and updates (aka, can change the fuel trim while engine is running, or see how rich/lean you are running and log to hd). It's a very different perspective on things to make the hardware and the software interface, rather than reading specs on something already made.

[FlashBurn]

@Ready4Dis

Your kernel was only 8k in size, with these features??? WOW!!! I´m at 25k and I don´t have much features. I think I will come to 50k-60k for my kernel. My os is also written in asm.

[Ready4Dis]

@Ready4Dis

Your kernel was only 8k in size, with these features??? WOW!!! I´m at 25k and I don´t have much features. I think I will come to 50k-60k for my kernel. My os is also written in asm.

Well, it's not to well documented, but I could let you take a look at it if you're really interested, it's old code that I will be reusing parts of, but if you use anything, just give me some credit or whatever, email me for the code if you want it..

ready4dis at cox.net, if anybody else is interested, I can post it up on my site somewhere.

[axilmar]

hi
i'm beginning my gui. windows are arranged based on its depth.
just i have to simply walk through the windows and paint them in secondary buffer.
i should hand over the drawing surface to each user process, double buffer couldn't be given because they might overwrite the entire screen. so a buffer of appropriate rectangle should be created and given to them, then it should be copied to the double buffer. when all process finished painting, double buffer should be copied to frame buffer.
creating memory surface for each and every process seems to be not a good idea. how you guys do it?

You must separate your code in layers.

At the bottom layer, there is the graphics driver. It has functions like setting up the video mode, drawing primitives and offering direct access to the frame buffer. Usually the graphics driver is occupied by one client module.

At the middle layer, we have the GUI, which is the client module that most often uses the graphics driver. But there can be other clients which can use the driver, for example full screen games.

At the top layer, above the GUI, we have an abstraction of a piece of paper which allows drawing in (almost) infinite resolution. This is required in order to implement WYSIWYG.

----

At the middle layer, the GUI mechanism, there are two ways to implement layered drawing:

1) each window produces a list of drawing commands to the drawing engine. Then the drawing engine sorts these commands according to the order of painting.

2) you use regions. A region is a collection of rectangles. By using set operations on regions (intersection, union, subtraction) you can create output regions which can be used to clip drawing of a window.

[exkor]

Hi,
The general idea is that one of the software (except the video driver) needs to care about screen resolutions, pixel formats or buffering; and the video driver is free to optimize as much as possible, depending on what it supports.

OS needs to give choices if buffering is used or direct port access(modern video cards) and select either VESA with some sort of buffering or specific videocard driver with ports.

Bitmaps can possibly be drawn without copying anything in to memory. Need to have exact info how videcards work or debug their drivers.

Most of buffering can possibly be implemented in the user mode(ring3) but port access needs to be in kernel if you care about speed (and if driver doesn't use memory mapped i/o).