[C# / X# ] Cosmos - C# Open Source Managed Operating System

[GTKM]

Originariamente inviato da fano

Mah mi chiedo alla fine, ma vale la pena davvero cambiare le divisioni con gli shift e i moduli con gli and se ci sono tutte queste trappole? Perché la CPU non può farsele da sole queste cose (magari quelle può moderne lo fanno pure, ma si ottimizza per il caso più generico... il 486)?

Nei test che feci ho visto che anche Visual Studia fa questi "giochini" oltre che GCC e Clang quindi sicuramente è un ottimizzazione "benefica" però mi fa pensare sembra così semplice la divisione

Ritornando alla VGA devo forse settare la palette? Ovvero la palette di default dopo il boot mappa tutti i 256 possibili valori sul nero?

Beh, la divisione di per sé tanto semplice non lo è mai stata. Lo shift dei bit ha un costo "computazionale" inferiore, a livello di CPU. A meno che le cose non siano cambiate recentemente.
Ovviamente, lo shift vale solo quando il divisore è potenza di due, e per numeri senza segno, come ha detto cdimauro, altrimenti bisogna tener conto di 'ste cose.

[cdimauro]

Originariamente inviato da fano

Mah mi chiedo alla fine, ma vale la pena davvero cambiare le divisioni con gli shift e i moduli con gli and se ci sono tutte queste trappole? Perché la CPU non può farsele da sole queste cose (magari quelle può moderne lo fanno pure, ma si ottimizza per il caso più generico... il 486)?

Nei test che feci ho visto che anche Visual Studia fa questi "giochini" oltre che GCC e Clang quindi sicuramente è un ottimizzazione "benefica" però mi fa pensare sembra così semplice la divisione

Infatti i benefici ci sono sicuramente.

Ritornando alla VGA devo forse settare la palette? Ovvero la palette di default dopo il boot mappa tutti i 256 possibili valori sul nero?

No, già di default il RAMDAC è caricato coi classici 16 colori della CGA, più diverse tonalità fino a coprire tutti e 256 colori.

Dunque il problema sarà un altro. Butta via Bochs.

[fano]

Purtroppo anche con VmWare vedo un "grazioso" schermo nero

Mi dicono che un tempo la cosa funzionava anche se era molto lento (5 secondi per mostrare un pixel! Probabilmente la nostra gestione dei delegates ha qualcosa che non va) io l'ho lasciato 30 secondi, ma nulla accadeva.

Questa è la SetPixel, mi pare OK:

public void SetPixel320x200x8(uint x, uint y, uint c)
{
       mIO.VGAMemoryBlock[(y * 320) + x] = (byte)(c & 0xFF);
}

dove VGAMemoryBlock è:

MemoryBlock08 VGAMemoryBlock = new MemoryBlock08(0xA0000, 1024 * 64);

ovvero 64 KB mappati all'indirizzo della VGA 0xA0000...

A me sembra tutto OK, ho molti più dubbi su come viene programmata la VGA settando quei registri con quei valori "a caso" boh...

[cdimauro]

Ma per adesso non puoi semplicemente generare delle istruzioni con X#, che settano un po' di pixel sullo schermo 320x200, con tutti e 256 colori? Così vedi se intanto l'accesso al framebuffer funziona.

[fano]

Nel ring1 (HAL) non si può usare X# solo nel ring 0 infatti tutte le operazioni sulla memoria grezza solo nascoste nel MemoryBlock... le astrazione a volte quando poi si vogliono fare "porcate" sono un po' tra i piedi (beh del resto esistono - le astrazioni - per impedirti di farle... le porcate ).

Sai cosa penso? Che alla fine ci siano qualche casino in questo calcolo:

[(42 * 320) + 42] (che dovrebbe fare 13482) sono "unsigned int" x ed y e magari fa qualche strano casino anche perché l'indice poi è int quindi c'è anche una conversione implicita tra uint e int...

anche questo calcolo semplice potrebbe fregarmi:

(byte)(c & 0xFF) ('c' è di nuovo un uint e magari l'end con uint non funziona o il cast a byte).

Quindi il mio piano è di dividere l'operazione in calcolo di "where" e di "color" e stamparli, vediamo che valori escono...

I tipi unsigned alla fine più uso C# e penso che a parte byte non hanno davvero senso infatti non tutti i linguaggi .NET li implementano e NON dovresti usarli in classi pubbliche.
Java se avesse definito byte come unsigned (C# l'ha fatto infatti) avrebbe avuto molte meno critiche sulla mancanza dei tipi unsigned la loro intuizione era corretta...

Infatti la futura classe Canvas userà int tornando eccezione se si passano valori fuori range al costruttore come giusto che sia

[cdimauro]

Non credo che ci siano problemi relativi a quei calcoli.

Ma una cosuccia non potresti farla? Alla partenza di Cosmos, in ring 0, scrivi una manciata di istruzioni X# per pulire lo schermo e scrivere qualche pixel. Giusto per vedere se qualcosa funziona.

[fano]

Originariamente inviato da cdimauro

Non credo che ci siano problemi relativi a quei calcoli.

Mah ricordiamoci che il compilatore lo scriviamo noi, magari c'è qualche casino nell opcode add se il tipo è unsigned o (più probabile) nel cast da uint a int...

Mi sa che prima di RAT era lento, ma funzionava

Originariamente inviato da cdimauro

Ma una cosuccia non potresti farla? Alla partenza di Cosmos, in ring 0, scrivi una manciata di istruzioni X# per pulire lo schermo e scrivere qualche pixel. Giusto per vedere se qualcosa funziona.

Forse non è chiaro, ma il driver non chiama il BIOS, ma gira in modalità protetta quindi temo non siano una manciata d'istruzioni almeno vedendo il codice C (e il C# da esso derivato) per settare il modo e poi disegnare sullo schermo...

[cdimauro]

Originariamente inviato da fano

Mah ricordiamoci che il compilatore lo scriviamo noi, magari c'è qualche casino nell opcode add se il tipo è unsigned o (più probabile) nel cast da uint a int...

Mi sa che prima di RAT era lento, ma funzionava

Allora taglia la testa al toro: niente calcoli. Passagli direttamente l'offset a cui scrivere.

Forse non è chiaro, ma il driver non chiama il BIOS, ma gira in modalità protetta quindi temo non siano una manciata d'istruzioni almeno vedendo il codice C (e il C# da esso derivato) per settare il modo e poi disegnare sullo schermo...

Per settare il modo sì, ma per scrivere qualche pixel sarà giusto una manciata di istruzioni.

[syngian]

Questo è un buon sito (un po' vecchiotto, ma d'altra parte non c'è nulla di nuovo sotto il sole della VGA) riguardo la programmazione della VGA.
http://www.brackeen.com/home/vga

Se ti accontenti di una risoluzione grafica 320x200 a 256 colori basta switchare in VGA mode 0x13 (è una delle risoluzioni standard che hanno tutte le schede video)... senza problemi puoi arrivare ad una risoluzione di 640x480, anche se occorre qualche attenzione con i registri VGA e qualche linea di codice in più, ma per i tuoi esperimenti mi pare che il VGA mode 0x13 è sufficiente.

Questa estate non sapevo come fare e mi sono deciso di buttare giù un sistema operativo derivato dall'Amiga OS... il sistema si chiama XAM OS (eXtended AMiga OS) e nel mese di agosto ho fatto un bootloader a 2 stadi e una debug console (che in effetti è un mini sistema operativo a se stante) in 20 k di codice.

Non so quanto sia sofisticato il vostro X#, ma per settare i registri VGA basta semplicemente scrivere e/o leggere con le istruzioni assembler outb, outw, inb, inw direttamente
oppure incapsulate in una funzione (ti metto sotto un esempio in C e assembler in linea del CCG di uno dei moduli del mio XAM).

/**	XAM ************************************************************************
**
**	$VER: main.c 0.0 (01.08.2016)
**
**	DESC: Kernel debug console: C code entry
**
**  Note:
**  code derived from bkerndev - Bran's Kernel Development
**  by Brandon F. (friesenb@gmail.com)
*******************************************************************************/

#include "system.h"

void *memcpy(void *dest, const void *src, SIZE count)
{
	const UBYTE *sp = (const UBYTE *)src;
	UBYTE *dp = (UBYTE *)dest;
	for (; count != 0; count--) *dp++ = *sp++;
	return dest;
}

void *memset(void *dest, LONG val, SIZE count)
{
	CHAR a = val;
	UBYTE *dp = (UBYTE *)dest;
	for (; count != 0; count--) *dp++ = a;
	return dest;
}

UWORD *memsetw(UWORD *dest, UWORD val, SIZE count)
{
	UWORD *dp = (UWORD *)dest;
	for (; count != 0; count--) *dp++ = val;
	return dest;
}

SIZE strlen(const CHAR *str)
{
	SIZE retval;
	for (retval = 0; *str != '\0'; str++) retval++;
	return retval;
}

UBYTE inportb(UWORD port)
{
	UBYTE rv;
	ASM volatile ("inb %1, %0" : "=a" (rv) : "dN" (port));
	return rv;
}

UWORD inportw(UWORD port)
{
	UWORD rv;
	ASM volatile ("inw %1, %0" : "=a" (rv) : "dN" (port));
	return rv;
}

void outportb(UWORD port, UBYTE data)
{
	ASM volatile ("outb %1, %0" : : "dN" (port), "a" (data));
}

// This function outputs a word to a hardware port, added for enable/disable the video hardware text cursor.

void outportw(UWORD port, UWORD data)
{
	ASM volatile ("outw %1, %0" : : "dN" (port), "a" (data));
}

extern UBYTE heap_base;
static UBYTE *heap_break = &heap_base;

// a simple initial memory management
// heap_base is setted in the linker script and point at the end of bbs section (is the start of free memory after the loaded kernel)

// srbk() (or mmap) is the function called by standard C library function Malloc() & friends for obtain chunk of memory from the system
// for their internal managed pool for the allocation dynamic memory. Malloc() when the internal heap run out of memory call sbrk() for obtain
// more memory from the system), the drawback is that the memory managed by Malloc() & friends is never returned to the system.
// now the rudimentale memory management is working, be carefull, the stuff of the heap_base is a finesse, is possible brutally set for example
// heap_base at 4MB memory address (heap_break=0x400000) and the stack pointer where u like.

static void *sbrk(SIZE size)
{
	//#define MEM_BLOCKSIZE	(sizeof(APTR)*2) // 2 times of sizeof APTR -- 8/16 bytes for 32/64 bit system
	//#define MEM_BLOCKMASK	(MEM_BLOCKSIZE-1)
	//if (num & MEM_BLOCKMASK) num = (num + MEM_BLOCKSIZE) & ~MEM_BLOCKMASK;

	SIZE num = heap_break;

	//-- align to 4 --
	if (num & 3) {
		num = (num + 4) & ~3;
		heap_break = (void *)num;
	}

	void *temp = heap_break;
	heap_break += size;
	return temp;
}

int kernel_main()
{
	// gdt_install(); dont need, the initial kernel gdt is already setting in kernel.asm with a simple preprocessor stuff
	init_video(); // really dont need (now the screen routines work without initialization, but is ok )

	CursorEnabled(FALSE); //disable the hardware blinking cursor

	UBYTE msg1[] = "- XAM OS (eXtended AMiga OS) -\n";
	UBYTE msg2[] = "KICKSTART 32 bit running in protect mode at 0x100000 address\n";

	GotoXY((80 - strlen(msg1)) / 2, 2); puts(msg1);
	GotoXY((80 - strlen(msg2)) / 2, 4); puts(msg2);

	idt_install();
	isrs_install();
	irq_install();
	timer_install();
	keyboard_install();

	ASM volatile ("sti"); // enable interrups

	/*
	int x, y;
	x = GetCursorX;
	y = GetCursorY;
	SetTextColor(1, 15);
	GotoXY(1, 1); puts("interrups enabled");
	SetTextColor(15, 3);
	GotoXY(x, y);
	*/

	puts("interrups enabled - write something - Press F1 for enable/disable the hardware cursor\n");
	CursorEnabled(TRUE);

	// dont touch this infinite loop
	for (;;);
}

e poi usi le funzioni per scrivere e leggere nei registri VGA.

/**	XAM ************************************************************************
**
**	$VER: scrn.c 0.0 (01.08.2016)
**
**	DESC: Kernel debug console: screen output I/O functions
**
**  Note:
**  code derived from bkerndev - Bran's Kernel Development
**  by Brandon F. (friesenb@gmail.com)
*******************************************************************************/

#include "system.h"

/* These define our textpointer, our background and foreground
*  colors (attributes), and x and y cursor coordinates */
UWORD *textmemptr = (UWORD *)0xB8000;
UWORD attrib = 63; // SetTextColor(15, 3);

UWORD csr_x = 0, csr_y = 0;
BOOL CursorVisible = TRUE;

/* Scrolls the screen */
void scroll(void)
{
	UWORD blank, temp;

	/* A blank is defined as a space... we need to give it backcolor too */
	blank = ' ' | (attrib << 8);

	/* Row 25 is the end, this means we need to scroll up */
	if (csr_y >= 25)
	{
		/* Move the current text chunk that makes up the screen back in the buffer by a line */
		temp = csr_y - 25 + 1;
		memcpy(textmemptr, textmemptr + temp * 80, (25 - temp) * 80 * 2);

		/* Finally, we set the chunk of memory that occupies the last line of text to our 'blank' character */
		memsetw(textmemptr + (25 - temp) * 80, blank, 80);
		csr_y = 25 - 1;
	}
}

/* Updates the hardware cursor: the little blinking line
*  on the screen under the last character pressed! */
void move_csr(void)
{
	UWORD temp;

	if (CursorVisible == FALSE) return;

	/* The equation for finding the index in a linear
	*  chunk of memory can be represented by:
	*  Index = [(y * width) + x] */
	temp = csr_y * 80 + csr_x;

	/* This sends a command to indicies 14 and 15 in the
	*  CRT Control Register of the VGA controller. These
	*  are the high and low bytes of the index that show
	*  where the hardware cursor is to be 'blinking'. To
	*  learn more, you should look up some VGA specific
	*  programming documents. A great start to graphics:
	*  http://www.brackeen.com/home/vga */


	outportb(0x3D4, 14);
	outportb(0x3D5, temp >> 8);
	outportb(0x3D4, 15);
	outportb(0x3D5, temp);
}

// set x,y cursor coordinates x=1-80, y=1-25, 0 for skip x or y setting, example: gotoxy(0,5) set only y
void GotoXY(WORD x, WORD y)
{
	if (x >= 1 && x <= 80) csr_x = x-1;
	if (y >= 1 && y <= 25) csr_y = y-1;
}

WORD GetCursorX(void)
{
	return csr_x + 1;
}

WORD GetCursorY(void)
{
	return csr_y + 1;
}

/* Clears the screen */
void cls()
{
	UWORD *ptr = textmemptr;
	UWORD blank;
	UWORD i;

	/* The 'short' that will be used to represent a space with color */
	blank = ' ' | (attrib << 8);

	/* Sets the entire screen to spaces in our current color, 80*25 = 2000 */
	for (i = 0; i < 2000; i++)
		*ptr++ = blank;

	/* Update the virtual cursor, and then move the hardware cursor */
	csr_x = 0;
	csr_y = 0;
	move_csr();
}

/* Puts a single character on the screen */
void putch(const char c)
{
	UWORD *ptr;

	/* Handle a backspace, by moving the cursor back one space */
	if (c == 0x08)
	{
		if (csr_x != 0) csr_x--;
	}
	/* Handles a tab by incrementing the cursor's x, but only
	*  to a point that will make it divisible by 8 */
	else if (c == 0x09)
	{
		csr_x = (csr_x + 8) & ~(8 - 1);
	}
	/* Handles a 'Carriage Return', which simply brings the
	*  cursor back to the margin */
	else if (c == '\r')
	{
		csr_x = 0;
	}
	/* We handle our newlines the way DOS and the BIOS do: we
	*  treat it as if a 'CR' was also there, so we bring the
	*  cursor to the margin and we increment the 'y' value */
	else if (c == '\n')
	{
		csr_x = 0;
		csr_y++;
	}
	/* Any character greater than and including a space, is a
	*  printable character. The equation for finding the index
	*  in a linear chunk of memory can be represented by:
	*  Index = [(y * width) + x] */
	else if (c >= ' ')
	{
		ptr = textmemptr + (csr_y * 80 + csr_x);
		*ptr = c | attrib << 8;	/* character AND attributes color */
		csr_x++;
	}

	/* If the cursor has reached the edge of the screen's width, we
	*  insert a new line in there */
	if (csr_x >= 80)
	{
		csr_x = 0;
		csr_y++;
	}

	/* Scroll the screen if needed, and finally move the cursor */
	scroll();
	move_csr();
}

/* Uses the above routine to output a string... */
LONG puts(const char *str)
{
	SIZE n;

	for (n = 0; n < strlen(str); n++)
	{
		putch(str[n]);
	}
	return n;
}

/* Sets the forecolor and backcolor that we will use */
void SetTextColor(unsigned char forecolor, unsigned char backcolor)
{
	/* Top 4 bytes are the background, bottom 4 bytes
	*  are the foreground color */
	attrib = (backcolor << 4) | (forecolor & 0x0F);
}

/* Sets our text-mode VGA pointer, then clears the screen for us */
void init_video()
{
	//textmemptr = (UWORD *)0xB8000;
	cls();
}

/* enable/disable the video hardware cursor in text mode
   with status = true the cursor is visible, with false no*/
void CursorEnabled(BOOL status)
{
	CursorVisible = status;

	if (status)
	{
		outportw(0x3D4, 0xE0A);
		outportw(0x3D4, 0xF0B);
		move_csr();
	}
	else
	{
		outportw(0x3D4, 0x200A);
		outportw(0x3D4, 0xB);
	}

}

I nomi dei tipi di dati credo che si capiscono facilmente (io mi attengo strettamente alle convenzioni dell'Amiga OS e uso lo stesso tipo di denominazione adeguata ai tempi) comunque ti metto anche il file che li definisce per sicurezza.. uso un IDE misto CCG/VC++ per lo sviluppo di XAM.. sinceramente non sopporto un abominio come Linux e soprattutto CCG e uso se posso VC++

#ifndef	EXEC_TYPES_H
#define	EXEC_TYPES_H

/** XAM ***********************************************************************
**
**  $VER: types.h 0.1 (01.08.2016) (20.08.2016)
**
**  DESC: Data typing - Must be included before any other include
**
**	NOTE: standard exec/types.h - modified for kernel debug console
*******************************************************************************/

#define LIBRARY_VERSION	0		// Lowest version supported
#define INCLUDE_VERSION	0		// Version of the include files in use. (Do not use this label for OpenLibrary() calls)

#define _ARCH_x86_32_

#define INLINE   __inline
#define VOLATILE volatile

#ifdef _MSC_VER
#define ASM  _asm
#else
#define ASM asm
#endif // _MSC_VER

#define EXTERN		extern		// reference to an external
#define STATIC		static		// a local static variable
#define REGISTER	register	// a register variable

#ifndef VOID
#define VOID void
#endif

#ifndef CONST
#define CONST const
#endif

typedef void* APTR;	// 32/64 bit untyped pointer (absolute/address pointer)

#undef BYTE

#ifdef __cplusplus
typedef char CHAR;	// character
#else
typedef char CHAR;	// character
#endif

					// the use of CPTR and SPTR is for pointers math and protection, use the CHAR * and CHAR [] as default types
typedef CHAR* CPTR;	// character pointer
typedef CHAR* SPTR;	// string pointer (NULL terminated)

typedef signed char		BYTE;		// signed 8-bit quantity
typedef unsigned char	UBYTE;		// unsigned 8-bit quantity
typedef unsigned char	BYTEBITS;	// 8 bits manipulated individually

typedef short			WORD;		// signed 16-bit quantity
typedef unsigned short	UWORD;		// unsigned 16-bit quantity
typedef unsigned short	WORDBITS;	// 16 bits manipulated individually

typedef long			LONG;		// signed 32-bit quantity
typedef unsigned long	ULONG;		// unsigned 32-bit quantity
typedef unsigned long	LONGBITS;	// 32 bits manipulated individually

typedef long long			QUAD;
typedef unsigned long long	UQUAD;
typedef unsigned long long	QUADBITS;

#ifdef size_t
typedef size_t SIZE
#endif

#ifndef SIZE
#ifdef _ARCH_x86_32_
typedef ULONG SIZE;	// unsigned 32/64-bit quantity
#else
typedef UQUAD SIZE;	// unsigned 32/64-bit quantity
#endif
#endif

//---- Types with specific semantics ----

typedef int		INT;		// integer
typedef float	FLOAT32;
typedef double	FLOAT64;
typedef UBYTE	BOOL;		// unsigned, 0 = false, 1 = true

#ifndef TRUE
#define TRUE  1
#endif
#ifndef FALSE
#define FALSE 0
#endif

#define BYTEMASK	0xFF

//---- standard NULL declaration ----

#ifdef NULL
#undef NULL
#endif

#ifdef __cplusplus
#define	NULL 0
#else
#define NULL ((void *)0)
#endif

/*
#ifdef __cplusplus
extern "C"
{
#endif
#ifdef __cplusplus
}
#endif
*/

#endif // EXEC_TYPES_H

Questo è il file BUILD.bat che sotto Windows compila il mini sistema operativo Kernel console e crea un image disk (Disk.img) per Bochs.
(servono le versioni a 32 bit di Nasm e MINGW o TDM-GCC).

@IF EXIST TMP @rd /S /Q TMP 

@md TMP
@md TMP\BFI

@rem -------------------------
@rem -- Boot -----------------
@rem -------------------------

@cd 0001_00_stage1
nasm -f bin -o ..\TMP\boot.bin Stage1.asm 

@cd ..\0001_00_stage2
nasm -f bin -o ..\TMP\BFI\BOOTLDR.SYS Stage2.asm

@cd ..\0002_00_kernel_asm
nasm -f elf -o ..\TMP\kernel.o kernel.asm

@rem -------------------------
@rem -- Kernel ---------------
@rem -------------------------

@cd ..\0002_01_kernel
@rem extra compiler flags: -Wextra -Wall -I./include -ffreestanding 
@set "$cc=gcc -std=gnu99 -nostdlib -c -O2 -m32 -march=i686 -lgcc"

%$cc% -o ..\TMP\main.o main.c 
%$cc% -o ..\TMP\scrn.o scrn.c 
%$cc% -o ..\TMP\idt.o idt.c 
%$cc% -o ..\TMP\isrs.o isrs.c 
%$cc% -o ..\TMP\irq.o irq.c 
%$cc% -o ..\TMP\timer.o timer.c 
%$cc% -o ..\TMP\kbd.o kbd.c 

@rem -------------------------
@rem -- Linker ---------------
@rem -------------------------

@cd ..\TMP
@set "$ld=ld -T ..\0000_01_Linker\boot.ld -nostdlib --nmagic -o KERNEL.OBJ"

%$ld% kernel.o main.o scrn.o idt.o isrs.o irq.o timer.o kbd.o

objcopy -O binary KERNEL.OBJ BFI\KERNEL.SYS

@cd ..
bfi -f="Disk.img" -b=TMP\boot.bin TMP\BFI

[fano]

syngian se ho capito bene tu hai usato il BIOS per invocare il modo 0x13, noi questo non possiamo farlo: Cosmos gira in modalità protetta a 32 Bit sempre.

Infatti quello che stiamo usando è un vero e proprio driver VGA programmando il modo scrivendo direttamente sui registri della scheda.
Questa è com'è fatto il nostro driver VGA è puro C# di fatto:

https://github.com/CosmosOS/Cosmos/b...s/VGAScreen.cs

l'equivalente di inb, outb sono fatte scrivendo dentro "mIO" che astrae i blocchi di memoria corrispondenti agli indirizzi che in x86 piacciano tanto (in questo caso quindi si legge / scrive su 0xA000...).

[cdimauro]

In tutta onestà non mi piace il codice attuale, che mi sa tanto di "God class", visto che contiene tutto, e metodi ripetuti per ogni modo grafico supportato.

Una ristrutturazione col concetto di classe schermo e relativi parametri sarebbe necessaria, dividendo gli schermi per lo meno in testuali, bitmapped, e packed/chunky, e delegando ad apposite tabelle l'elenco dei valori da scrivere nei registri della VGA.

Comunque per adesso non avete altra scelta: non potete usare l'int 10 per impostare il modo video.

[fano]

Sì quel codice non piace molto nemmeno a me onestamente... è chiaramente un porting fatto dal codice C che avevo allegato.

C'è da dire - a nostra parziale discolpa - che mancano ancora molte classi della BCL nel .NET di Cosmos per esempio una mancanza importante è la classe Dictionary che semplificherebbe molto le cose...

Anche l'uso dei delegates sembra essere un problema probabilmente perché l'implementazione in Cosmos non è ancora ben ottimizzata (leggende parlano di 5 secondi per disegnare un pixel! Io ne aspetterei pure 30 per vederlo un pixel ) quindi sarà una delle cose da cambiare... al momento mi viene in mente solo if / else if / else if
Quindi molte volte il codice dentro Cosmos non è molto ad "oggetti" anche per questo, speriamo che con .Net Core riusciremo a liberarci dell'incubo dei plug!

Comunque ho intenzione di cambiare un bel po' di cose unificare VGA / VBE facendoli ereditare da una stessa classe astratta ecc...
La parte testuale c'è l'idea effettivamente di fare un driver separato quindi vedendo "virtualmente" la scheda video come 2 dispositivi un dispositivo stupido per scrivere testo (scrivendo probabilmente brutalmente sulla porta 0xB000... come facciamo ora) e un dispositivo più "furbo" per fare grafica che probabilmente avrà driver diversi a seconda dell'hardware.

Non sono comunque sicuro che sbattersi a fare un driver VGA in modalità protetta sia veramente la via giusta da seguire o se sarebbe meglio fare direttamente un vero driver VBE3 usando o sta modalità protetta (se funziona, pare solo Haiku OS sia riuscito ad usarla, forse...) o se è impossibile VM86 che però poi non funziona a 64 bit... quindi boh?

[cdimauro]

@fano. Ne abbiamo già parlato in privato: la soluzione per lavorare con la VGA è un emulatore 8086, sviluppato tenendo conto delle esigenze di cui hai parlato. Al momento, però, devi riuscire a disegnare un pixel col codice che avete a disposizione. Per le finezze se ne parlerà più avanti.

Riguardo al codice, ho solo esposto le mie idee: non volevo essere brusco o sgarbato. Non è un critica distruttiva, ma serve a spronare a rifattorizzare il codice per renderlo più manutenibile e/o estensibile, specialmente considerato che il progetto è pubblico e sarà sotto gli occhi di tutti. Deformazione professionale, dopo anni di code review...

[fano]

Originariamente inviato da cdimauro

@fano. Ne abbiamo già parlato in privato: la soluzione per lavorare con la VGA è un emulatore 8086, sviluppato tenendo conto delle esigenze di cui hai parlato. Al momento, però, devi riuscire a disegnare un pixel col codice che avete a disposizione. Per le finezze se ne parlerà più avanti.

Sì concordo la cosa che mi annoia di più è che un tempo andava cosa gli hanno fatto a sta povera VGA?

E guarda cosa succede con VirtualBox:

https://github.com/CosmosOS/Cosmos/issues/505



Io sarei quasi contento almeno è un segno di vita, no?
(Beh qualcosa di diverso c'è Clear() probabilmente fa qualcosa di errato però sullo schermo almeno con VirtualBox viene disegnato qualcosa boh... Bochs e VmWare sono concordi nello schermo nero... e avevo capito che VirtualBox usava la stessa VGA emulata di Bochs[*]).

Originariamente inviato da cdimauro

Riguardo al codice, ho solo esposto le mie idee: non volevo essere brusco o sgarbato. Non è un critica distruttiva, ma serve a spronare a rifattorizzare il codice per renderlo più manutenibile e/o estensibile, specialmente considerato che il progetto è pubblico e sarà sotto gli occhi di tutti. Deformazione professionale, dopo anni di code review...

No avevo inteso benissimo non ti preoccupare e concordo al 100% non voglio che il kernel di Cosmos si riduca come il kernel di Linux che nemmeno sua papà Linus Torvalds riesce più a metterci le mani
(vedi il caso del bug novenne che tentò di aggiustare ed il kernel gli esplose in faccia )
[*] Virtualbox usa la stessa GPU dell'host (credo sia la configurazione di default) hmm interessante questa differenza tra un GPU reale e una "simulata"...

[cdimauro]

VirtualBox crea un sacco di problemi. Non ha una compatibilità così elevata. Rimani con VMWare. Oppure puoi provare con QEMU.

E invece di Bochs potresti provare anche DOSBox, che dovrebbe consentire un'emulazione più accurata di un PC, se non ricordo male.

[fano]

All'inizio pensavo male di Bochs, ma mentre non credo abbia senso usarlo a livello "utente" (troppo incasinato rispetto a VmWare con i soliti file da editare a mano! Classico stile Linux...) devo dire che lato sviluppatore OS non è male per capire che casini stai combinando... c'è dentro persino una specie di GDB!

VmWare essendo appunto più "consumer" si limita a crashare in molti casi...

[cdimauro]

QEMU ti dà anche la possibilità di lanciare direttamente un kernel, senza passare da un bootloader.

[fano]

Cosmos su Channel 9 (il canale ufficiale di .NET) Kudzu intervistato da Bertrand Le Roy (Microsoft Program Manager):

https://channel9.msdn.com/Shows/On-N...a-Kudzu-Cosmos

Se potete loggarvi e votare il video ci fate contenti!

... ci fate ancora più contenti se vi unite al gruppo degli sviluppatori

[fano]

Ebbene i vostri commenti?

[cdimauro]

Sulla carta sembra molto fico, ma finché sul lato prestazionale non si passerà ai risultati concreti, dubito che si potrà prendere sul serio ciò che dice il main developer.

Non prenderlo come una critica distruttiva, ma sparare che si possa andare 20 volte più velocemente di C++ (se non ricordo male la frase) e poi affermare che attualmente Cosmos è troppo lento perché ancora in fase di debug, non fa certo una buona impressione.

Per cui consiglierei di lasciar perdere certi slogan. Almeno finché non ci sarà qualche risultato a supporto.

Altra cosa, francamente togliete di mezzo completamente X#. E' eccessivamente complesso e farraginoso rispetto a usare direttamente il ben più conosciuto, classico, semplice linguaggio assembly (con sintassi Intel e NON AT&T!).

D'altra parte lo dice anche lo sviluppatore che si usa per pochissime righe di codice. Inutile reinventarsi la ruota con uno strumento così astruso, per così poco: usate l'assembly e metteteci una pietra sopra.

Per il resto promette molto bene. Ma, come ti dicevo anche tempo, se non rilasciate velocemente qualcosa di funzionante, non verrà mai preso seriamente in considerazione. E visto che siete pochi e cercate sviluppatori, sarebbe sicuramente di stimolo vederlo già all'opera.