Gdyby, ktoś nie widział czym jest Cyjon :)
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)?
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
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
PS: to jest już pełnoprawna struktura stosu TCP/IP (przepisana od nowa)
Udało się, mam serwer WWW, stos TCP/IP i system operacyjny... a wszystko w asemberze :D
Czas odpocząć od obsługi sieci, uff. Udostepniłem na http://github.com/Blackden/ aktualne źródła systemu.
Nie spodziewałem się uruchomienia za pierwszym razem... zonk.
Lenovo 3000 n200, wymieniony procek na T5470
jak uruchamiasz httpd, to działa wtedy ten proces w tle?
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ń
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.
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.
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.
; 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.
co to za pamięć, jaki tryb graficzny?
jakiś gotowiec:
http://stackoverflow.com/questions/1715224/very-fast-memcpy-for-image-processing
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
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
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!
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.
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:
- wyświetl okno 1
- wyświetl okno 2, zapamiętaj obszar pamięci który został przysłonięty i nie jest częścią pulpitu
- 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.
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).
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.
- wyświetl okno 1
- wyświetl okno 2, zapamiętaj obszar pamięci który został przysłonięty i nie jest częścią pulpitu
- 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)
- Narysuj pulpit (czarno, tapeta, co chcesz)
- Każ aplikacji 1 wyświetlić okno (podając jej odpowiedni wskaźnik na wspólny obszar pamięci ekranu).
- Każ aplikacji 2 wyświetlić okno (itd. w kolejności od okna najbardziej z tyłu do najbardziej na wierzchu).
- 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)
- Każde okno i pulpit rysuje do osobnej bitmapy.
- Składasz zawartość ekranu rysując gotowe bitmapy w odpowiedniej kolejności.
- 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.
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ł
Zdobyłem programistę ;)
Autor: Darek Kwieciński (link nieaktualny)
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 [: ).
Witajcie!
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.
Nie szybciej by go było pisać w Rust jak RedoxOS.
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
@Akasei: a co jest złego w tworzeniu plików o nazwach po prostu 1, 2, 3, 4...? ;-P
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 :)
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 :)