Cyjon OS

0

Gdyby, ktoś nie widział czym jest Cyjon :)
user image

0

widzę, że system nabiera kształtów i zaczyna sensownie wyglądać. Masz zamiar go rozwinąc do tego stopnia by móc go używać do "codziennych" czynności (przeglądanie jutówów fejsbóków słuchanie muzyki)?

0
babubabu napisał(a):

widzę, że system nabiera kształtów i zaczyna sensownie wyglądać. Masz zamiar go rozwinąc do tego stopnia by móc go używać do "codziennych" czynności (przeglądanie jutówów fejsbóków słuchanie muzyki)?

Pardon? (Słucham?/Czytam?) Chyba nie wiesz o czym piszesz :D

4

yep! tcp/ip stack prawie gotowy (tylko w jedną stronę, akceptacja połączenia i zamknięcie dla wewnętrznych serwerów) nie mam jeszcze serwera http więc nie mogę przesłać informacji od przeglądarki, ale jak widzicie - przeglądarka dała sobie spokój i zamknęła połączenia :D
user image

PS: to jest już pełnoprawna struktura stosu TCP/IP (przepisana od nowa)

10

Udało się, mam serwer WWW, stos TCP/IP i system operacyjny... a wszystko w asemberze :D

user image

4

Czas odpocząć od obsługi sieci, uff. Udostepniłem na http://github.com/Blackden/ aktualne źródła systemu.

user image user image

user image

8

Nie spodziewałem się uruchomienia za pierwszym razem... zonk.
Lenovo 3000 n200, wymieniony procek na T5470

user image

0

jak uruchamiasz httpd, to działa wtedy ten proces w tle?

0
no_solution_found napisał(a):

jak uruchamiasz httpd, to działa wtedy ten proces w tle?

jeszcze nie, za niedługo dodam obsługę & na końcu linii poleceń

0

CTRL+C oraz CTRL-Z pewnie się przydadzą. Też fajną opcją by było np CTRL+B, która by nie zatrzymywała (tak jak to robi CTRL+Z), ale uruchamiała dany proces w tle. Np kopiuję 100Gigowy plik. To trochę trwa, ale zapomniałem dodać & na końcu, a nie chcę przerywać i zaczynać tego od początku, więc daję ctrl+b i proces dalej działa, ale w tle.

0
no_solution_found napisał(a):

jak uruchamiasz httpd, to działa wtedy ten proces w tle?

Tak, dziala juz uruchamianie programow w tle za pomoca "&", nawet po ubiciu procesu "kill x", zwalniane sa porty TCP/IP zajete przez proces.

6

Rozpoczynam prace nad trybem graficznym. Terminal w trybie graficznym pójdzie dość szybko (bo już go miałem), kwestia optymalizacji pod konkretną głębię kolorów i przygotowania odpowiedniej macierzy znaków.

0
	; adres docelowy przesunięcia zawartości pamięci ekranu na początek
	mov	rdi,	qword [variable_screen_base_address]

	; oblicz adres źródłowy przsunięcia zawartości ekranu
	mov	rsi,	rdi
	add	rsi,	qword [variable_screen_line_of_chars_in_bytes]

	; rozmiar pamięci do przesunięcia (Y linii)
	mov	rcx,	qword [variable_screen_size]
	; skopiuj Y - 1 linii, skopiuj z 1..Y do 0..Y-1
	sub	rcx,	qword [variable_screen_line_of_chars_in_bytes]

	; przesuń zawartość
	shr	rcx,	VARIABLE_DIVIDE_BY_4
	rep	movsd

	; kolor tła
	mov	rax,	VARIABLE_COLOR_BACKGROUND_DEFAULT
	shr	rax,	VARIABLE_SHIFT_BY_4
	mov	eax,	dword [table_color_palette_32_bit + rax * VARIABLE_DWORD_SIZE]

	; wyczyść ostatnią linię
	mov	rcx,	qword [variable_screen_line_of_chars_in_bytes]
	shr	rcx,	VARIABLE_DIVIDE_BY_4
	rep	stosd

Dla osób które chcą dołożyć własną cegiełkę do systemu, proszę o zoptymalizowanie szybkości kopiowania przestrzeni pamięci z RSI do RDI. Na moim procku może i działa bardzo dobrze, ale właśnie uruchomiłem Bochsa na i3 i zastanawiam się czy "okno" jest otwarte.

0

co to za pamięć, jaki tryb graficzny?

jakiś gotowiec:
http://stackoverflow.com/questions/1715224/very-fast-memcpy-for-image-processing

0
Azarien napisał(a):

co to za pamięć, jaki tryb graficzny?

jakiś gotowiec:
http://stackoverflow.com/questions/1715224/very-fast-memcpy-for-image-processing

Jest to kopiowanie w przestrzeni pamięci karty graficznej mapowanej w RAMie pod adresem 0xE0000000.
Tzw. scroll, po rejestrach i zmiennych można sugerować ze 32 bitowa mapa kolorów.

PS: Będę musiał przeanalizować rejestry xmmY, jeszcze ich nie używałem.

PS2: Ocho... to już jest jakieś wyzwanie, #GP przy próbie zrobienia cokolwiek z rejestrami xmmY. Hmm, Bochs chyba nie ma wkompilowanej obsługi SSE albo adresy nie są wyrównane do pełnego adresu. Zapowiada się ciekawy weekend :D

0
Azarien napisał(a):

jakiś gotowiec:
http://stackoverflow.com/questions/1715224/very-fast-memcpy-for-image-processing

Wymagało to trochę gimnastyki.
Włączyłem dostęp do x87 (CR4 - OSFXSR[bit 9]) , dodałem odkładanie rejestrów FXSAVE i ich przywracanie FXRSTOR z stosu kontekstu... i wuala! Kopiowanie działa. Nie jest to za szybkie, albo efekt symulatora - oceniam na przyspieszenie o jakieś 15%.

.graphics:
	shr	rcx,	7

.graphics_loop:
	prefetchnta	[rsi + 128]
	prefetchnta	[rsi + 160]
	prefetchnta	[rsi + 192]
	prefetchnta	[rsi + 224]

	movdqa	xmm0,	[rsi]
	movdqa	xmm1,	[rsi + 16]
	movdqa	xmm2,	[rsi + 32]
	movdqa	xmm3,	[rsi + 48]
	movdqa	xmm4,	[rsi + 64]
	movdqa	xmm5,	[rsi + 80]
	movdqa	xmm6,	[rsi + 96]
	movdqa	xmm7,	[rsi + 112]

	movntdq	[rdi],	xmm0
	movntdq	[rdi + 16],	xmm1
	movntdq	[rdi + 32],	xmm2
	movntdq	[rdi + 48],	xmm3
	movntdq	[rdi + 64],	xmm4
	movntdq	[rdi + 80],	xmm5
	movntdq	[rdi + 96],	xmm6
	movntdq	[rdi + 112],	xmm7

	add	rsi,	128
	add	rdi,	128
	dec	rcx
	jnz	.graphics_loop
3

Proszę bardzo, tryb graficzny (emulacja terminala).

Postarałem się aby dostępny był tryb fail-safe, gdyby nie udało się przełączyć na żądany tryb graficzny 640x400.
Tryb graficzny można do woli ustawiać w pliku config.asm:

VARIABLE_SCREEN_VIDEO_WIDTH			equ	640
VARIABLE_SCREEN_VIDEO_HEIGHT			equ	400

Nawet kursor zrobiłem mrygający!

user image

Później postaram się dodać możliwość przełączenia na najwyższy dostępny w SuperVGA.

PS: w pliku kernel.asm jest wyłączony Multiboot, na czas implementacji trybu graficznego z GRUBa.

0

Jeszcze nie wiem od czego zacząć przy interfejsie graficznym. Najbardziej denerwuje mnie przekroczenie wymaganej pamięci (do tej pory mieściłem się w 1 MiB).
Nie wiem jak obsługiwane są okna w innych systemach, spodziewam się czegoś w sposób:

  1. wyświetl okno 1
  2. wyświetl okno 2, zapamiętaj obszar pamięci który został przysłonięty i nie jest częścią pulpitu
  3. zamknij okno 2, przywróć obszar pamięci który był przysłonięty i nie jest częścią pulpitu

tylko że, im więcej okien otworzę tym więcej RAMU zjem...

Mógłbym nie zapamiętywać tych obszarów przysłoniętych, ale znowu musiałbym przerysowywać znaczną ilość aplikacji w odpowiedniej kolejności, jeśli wyłączę aplikację z pierwszego planu.

0

Na IRC zostałem nakierowany, aby wykorzystać "canvas", każda aplikacja będzie posiadać wirtualny pulpit z indeksem, im wyższy indeks tym bardziej na pierwszym planie. Następnie połączyć wszystkie "płótna" od najwyższego indeksu, pomijając obszary już wykorzystane.

Coś mi się zdaje, że będę musiał zrobić obsługę pozostałych rdzeniów(i wątków) procesora, za dużo roboty dla jednego (tym powinna się zająć karta graficzna, no ale... nie można mieć wszystkiego naraz).

0

http://4programmers.net/Forum/Inne/254733-algorytm_bresenhama_-_assembly?p=1155891#id1155891

Proxima napisał(a):

chyba nie szkodzi żeby zapakować procedury obsługi screena do kernela

Dzięki @Proxima - olśniło mnie, że mogę zmapować przestrzeń pamięci ekranu bezpośrednio do serwera X, po co proces ma rysować za pomocą przerwań - skoro to on teraz ma władzę nad ekranem.

PS: @Adam Boduch, bardzo proszę o przemyślenie - dodawania ankiet w postach, a nie z nowym tematem. Czasami chciałbym (jak zapewne i inni), znać odpowiedzi/kierunek rozwoju projektu w prostej ankiecie.

1
  1. wyświetl okno 1
  2. wyświetl okno 2, zapamiętaj obszar pamięci który został przysłonięty i nie jest częścią pulpitu
  3. zamknij okno 2, przywróć obszar pamięci który był przysłonięty i nie jest częścią pulpitu

Tylko co to znaczy „wyświetl okno”? Skąd system ma wiedzieć co jest zawartością okna?

Sposób 1 (aplikacje rysują do wspólnego obszaru pamięci)

  1. Narysuj pulpit (czarno, tapeta, co chcesz)
  2. Każ aplikacji 1 wyświetlić okno (podając jej odpowiedni wskaźnik na wspólny obszar pamięci ekranu).
  3. Każ aplikacji 2 wyświetlić okno (itd. w kolejności od okna najbardziej z tyłu do najbardziej na wierzchu).
  4. Po zamknięciu jakiegoś okna wyliczasz które okna są pod spodem, i kolejno wysyłasz im komunikat odrysowania (znowu, od okna najbardziej z tyłu zaczynając)

W ten sposób nie musisz pamiętać zawartości żadnego okna osobno, tylko pozycje wszystkich okien, a okienka się odrysowują kiedy trzeba.
Windows dodatkowo oszczędza na rysowaniu wyliczając który obszar okna aplikacja powinna odrysować - ale nie każdy program to obsługuje, i odrysowuje zawsze całość.

Sposób 2 (aplikacje rysują do osobnych bitmap)

  1. Każde okno i pulpit rysuje do osobnej bitmapy.
  2. Składasz zawartość ekranu rysując gotowe bitmapy w odpowiedniej kolejności.
  3. Gdy jakieś okno zostanie zamknięte, składasz ekran z bitmap na nowo z pominięciem tego okna.

Drugi sposób (tzw. compositing) bez sprzętowej akceleracji grafiki będzie bardzo wolny. Ale z nią - ma przewagę nad sposobem 1.

0

cytat z wikipedi:

Menedżer kompozycji Edytuj
Osobny artykuł: Menedżer kompozycji.
W menedżerze kompozycji okna rysowane są niezależnie od siebie do oddzielnych buforów w pamięci, a następnie składane i wyświetlane w środowiskach 2D lub 3D. Najbardziej zaawansowane menedżery udostępniają szeroki wachlarz efektów wizualnych oraz operacji do zarządzania lub przełączania się między oknami.

@Azarien chyba o tym pisał

1

Zdobyłem programistę ;)

user image

Autor: Darek Kwieciński (link nieaktualny)

2

Przywróciłem do życia program Moko (edytor tekstowy) na potrzeby pisania skryptów dla BFi.
Co za tym idzie, zaimplementowałem możliwość zapisu pliku do wirtualnego systemu plików z wstępną obsługą uprawnień, aby nie było prób wykonywania plików tekstowych (co skutkowało Page Fault, system stabilnie zamykał dziwny proces [: ).
user image

4

Witajcie!

title
title

Niewiele zmieniło się z zew. punktu widzenia, ale pod maską jest już pełna obsługa wirtualnych konsol!
Powłoka otrzymała możliwość buszowania po systemie plików (w tym i każdy inny proces).

Prace idą powoli i niezmiernie do przodu. Wersja "stabilna" zawsze do pobrania na stronie głównej projektu.

0

Nie szybciej by go było pisać w Rust jak RedoxOS.

1

Czy wykorzystanie generatora liczb pseudolosowych typu LCG do tworzenia nazw plików tymczasowych /tmp jest dobrym pomysłem?

; Copyright (C) 2013-2017 Wataha.net
; All Rights Reserved
;
; LICENSE Creative Commons BY-NC-ND 4.0
; See LICENSE.TXT
;
; Main developer:
;	Andrzej (akasei) Adamczyk [e-mail: akasei from wataha.net]
;-------------------------------------------------------------------------------

; Use:
; nasm - http://www.nasm.us/

; 64 Bitowy kod programu
[BITS 64]

LIBLARY_RAND_A		equ	22695477
LIBLARY_RAND_C		equ	1

;===============================================================================
; wejście:
;	rax - ziarno (np. ilość mikrosekund od daty 1970.01.01 00:00)
liblary_rand_init:
	; ziarno rozpoczynające ciąg liczb pseudolosowych
	mov	qword [liblary_rand_result],	rax

	; powrót z procedury
	ret

;===============================================================================
; wejście:
;	rcx - modulo (przedział liczby pseudolosowej 0 > rcx < 2^32)
; wyjście:
;	rdx - liczba pseudolosowa
liblary_rand:
	; zachowaj oryginalny
	push	rax

	; wykonaj obliczenia liczby pseudolosowej
	mov	eax,	dword [liblary_rand_result]
	mul	qword [liblary_rand_a]
	add	rax,	LIBLARY_RAND_C
	div	rcx

	; zapamiętaj wynik
	mov	qword [liblary_rand_result],	rdx

	; przywróć oryginalny
	pop	rax

	; powrót z procedury
	ret

liblary_rand_a		dd	LIBLARY_RAND_A
liblary_rand_result	dq	STATIC_EMPTY
0

@Akasei: a co jest złego w tworzeniu plików o nazwach po prostu 1, 2, 3, 4...? ;-P

1

Czy możliwość załadowania do przestrzeni procesu zawartości pliku typu "katalog" jest złym pomysłem?
np. GNU/Linux nie pozwala

akasei@clemento ~ $ cat cyjon
cat: cyjon: Jest katalogiem

W tym momencie wykorzystuję to np. przy poleceniu ls, bo potrafi zinterpretować zawartość binarną takiego pliku.
Nie wiem dlaczego polecenie cat po prostu nie wyświetla zawartości w postaci ASCII.

Dzięki temu, mógłbym się pozbyć jednej procedury!

** AKTUALIZACJA **
Dobra, odpowiedziałem sobie na to pytanie podczas pisania od początku programu cat.
Katalog jest plikiem o domyślnym rozmiarze N bloków * 4096 Bajtów (zależnie od ilości plików w nim). Czyli po wysłaniu cat / konsola w większości przypadków zapycha się pustą przestrzenią...

AKTUALIZACJA
Od wersji 0.763 postaram się dostarczać do pobrania wersje zlokalizowane dla EN i PL w końcu to tylko jeden przełącznik w głównym pliku konfiguracyjnym :)

title
title

3

Wymiękam, nie jestem w stanie zmusić VirtualBox do uruchomienia systemu... zawiesza się podczas kopiowania przestrzeni z 0x20000 do 0x100000 (rozmiar 21KiB).

Bochs i Qemu nie mają z tym problemu, nawet porównałem kod z Pure64 od https://github.com/ReturnInfinity/Pure64, brak znaczących różnic pod względem wartości/zmiennych.

Zawiesza się, gdy skopiuje ponad 4096 Bajtów - gdzieś przed 5120 Bajtów (na pewno nie 4097 i 8 ;) )

Jeśli ktoś wie jak debugować pod VirtualBox, to proszę (link nieaktualny), kopiowanie przestrzeni zaczyna się pod adresem fizycznym/liniowym 0x23A3.

Jeśli chcesz nagrać obraz na Pendrive(USB) to idealny jest do tego program https://sourceforge.net/projects/win32diskimager (MS/Windows).
Pod systemy GNU/Linux:

sudo dd if=cyjon-0.772-en.raw of=/dev/usb_pendrive

PS: pod laptopem EeePC, nie działają(naprawionie) klawisze kierunkowe, nasz zespół do spraw likwidacji bugów, już się tym zajmuje ;]
PS: dziwne numery konsol dla demonów, naprawione :)

Dowód na sprawny system :)
title
title
title

1 użytkowników online, w tym zalogowanych: 0, gości: 1