Cyjon OS

Odpowiedz Nowy wątek
2015-04-10 20:41
47

Programowanie może być ciekawe.

W pełni 64 bitowe jądro systemu jak i oprogramowanie oraz system plików.
W języku asemblera.

Wszystkie programy pisane własnoręcznie, nie są przenoszone z systemów GNU/Linux (tylko na nich wzorowane - wizualnie :)).

user image

Edytor tekstu "nano":

user image

Aby daleko nie szukać, poniżej paczka z obrazem systemu.

Aktualizacja 21.12.2015:

user image

Aktualizacja 3.1.2016:

user image
user image

Aktualizacja 5.1.2016:
Wykonałem trochę modyfikacji i teraz działa znacznie lepiej (znalazłem parę błędów) jak i się prezentuje.

user image

Aktualizacja 27.05.2016:
Obsługa protokołu ARP, IP i ICMP !

user image

Aktualizacja 11.06.2016:

Udało mi się nawiązać połączenie przez przeglądarkę, "stos" tcp/ip przyjmuje tylko jedno połączenie ;)
Teraz muszę wysłać dane do serwera httpd wraz z identyfikatorem połączenia.
Serwer wyśle odpowiedź do klienta(przeglądarka) i demon_tcp zakończy połączenie, oczekując na następne xD
user image

Aktualizacja 30.06.2016:

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

Aktualizacja 28.12.2016:

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).
title

Aktualizacja 15.01.2017:

title
title
title

Aktualizacja 20.02.2017:

title

Aktualizacja 22.02.2017:

Aktualizacja 21.03.2017:

title

Aktualizacja 23.03.2017:


edytowany 15x, ostatnio: akasei, 2017-03-23 14:22
Unikałbym stosowania istniejących nazw własnych programów. Tak tylko piszę. Ogólnie bardzo fajnie. :) - Tacet 2015-04-11 00:24
Tak, zgadzam się... dopóki się z tym nie panoszę na lewo i prawo, mogę je stosować. Nazwy te zastosowałem by osoby postronne szybko się odnalazły. - akasei 2015-04-11 00:34
Powoli przepisuję "uproszczony" kod jądra systemu do GitHub, dodając masę komentarzy. - akasei 2015-04-11 18:00
Plik system.zip powyżej, nieaktualny. Najnowszą wersję zawsze można pobrać z GitHub. - akasei 2015-12-21 07:15

Pozostało 580 znaków

2016-07-06 22:13
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.


Pozostało 580 znaków

2016-07-08 08:44
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.


edytowany 1x, ostatnio: akasei, 2016-07-08 08:45

Pozostało 580 znaków

2016-07-08 08:52
0

co to za pamięć, jaki tryb graficzny?

jakiś gotowiec:
http://stackoverflow.com/ques[...]t-memcpy-for-image-processing

edytowany 1x, ostatnio: Azarien, 2016-07-08 08:53

Pozostało 580 znaków

2016-07-08 08:55
0
Azarien napisał(a):

co to za pamięć, jaki tryb graficzny?

jakiś gotowiec:
http://stackoverflow.com/ques[...]t-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


edytowany 6x, ostatnio: akasei, 2016-07-08 09:33

Pozostało 580 znaków

2016-07-08 12:16
0
Azarien napisał(a):

jakiś gotowiec:
http://stackoverflow.com/ques[...]t-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

ale co to ma do x87? - Azarien 2016-07-08 23:14

Pozostało 580 znaków

2016-07-08 21:12
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.


edytowany 2x, ostatnio: akasei, 2016-07-08 21:15
może lepiej nie najwyższy, tylko poszukaj jak wyczytać natywną rozdzielczość monitora i tę ustawiaj. - Azarien 2016-07-08 23:13

Pozostało 580 znaków

2016-07-13 20:31
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.


W windowsie tak to chyba jest realizowane, że jest jeden bufor ekranu, gdzie wszystkie okna są rysowane w odpowiedniej kolejności. Cały proces jest oczywiście zoptymalizowany między innymi przez użycie regionów, dzięki którym odrysowywane są tylko fragmenty okna/pulpitu, które tego wymagają. - _0x666_ 2016-07-15 11:08
@_0x666_: tak to było kiedyś. od Visty począwszy okna są rysowane każde na osobnej powierzchni (teksturze), a potem karta graficzna sprzętowo renderuje tekstury na ekranie. - Azarien 2016-07-18 18:23
@Azarien, zapewne ma to związek z Areo. - _0x666_ 2016-07-18 18:56

Pozostało 580 znaków

2016-07-13 21:12
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).


edytowany 1x, ostatnio: akasei, 2016-07-13 21:13
eh, mam już zarys działania własnego środowiska X, teraz doszło do mnie, że potrzebuję czcionki i jej skalowania... rany boskie. - akasei 2016-07-14 20:23

Pozostało 580 znaków

2016-07-16 15:45
0

http://4programmers.net/Forum/Inne/254733-algorytmbresenhama-_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.


edytowany 1x, ostatnio: akasei, 2016-07-16 15:51
napisz w dziale Coyote to może dodadzą. - babubabu 2016-07-16 17:11
Było by to fajne i przydatne; @Adam Boduch - co o czymś takim sądzisz? Może mała ankieta? :) - furious programming 2016-07-18 18:54

Pozostało 580 znaków

2016-07-18 18:34
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.

edytowany 1x, ostatnio: Azarien, 2016-07-18 18:35
Ten drugi sposób wcale nie musi być wolniejszy, jeśli będziesz okna rysował w podobny sposób jak w sposobie pierwszym - czyli rysujesz te fragmenty, które wymagają odmalowania. Plus tego taki, że w buforach-warstwach masz już gotowe okna, więc odpadają wolne algorytmy rysujące/rasteryzujące przy każdym odmalowaniu. Minus - większe zużycie pamięci. Tak czy siak w obu przypadkach bez jakiegoś sensownego algorytmu clippingu się nie obędzie. - _0x666_ 2016-07-18 19:10

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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