Cyjon OS

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

Edytor tekstu "nano":

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

Aktualizacja 21.12.2015:

Aktualizacja 3.1.2016:

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

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

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

** Aktualizacja 30.06.2016: **

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

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

** Aktualizacja 15.01.2017: **

** Aktualizacja 20.02.2017: **

** Aktualizacja 22.02.2017: **

** Aktualizacja 21.03.2017: **

** Aktualizacja 23.03.2017: **

** Aktualizacja 02.07.2017: **

** Aktualizacja 25.08.2017: **

No ładnie to wygląda :)

Super sprawa, na pewno musiałeś poświęcić sporo czasu.
Na czym to odpalasz? Masz jakąś maszynkę wirtualną czy pod jakimś sprzętem?

@akasei - z jakich materiałów korzystałeś pisząc projekt? Pisałeś w czystym asemblerze czy również w C? Uruchomiłem system na wirtualce, wszystko bangla jak trzeba :] Graty za włożony wysiłek.

przykładowe zadania:

• obsługa myszki (naprościej będzie PS/2)
• grafika (podstawowe tryby VGA/VESA na początek)
• możliwość ładowania binarek skompilowanych w C

:)

Nie wygodniej i szybciej byłoby to pisać w C?

Azarien napisał(a):

przykładowe zadania:

• obsługa myszki (naprościej będzie PS/2)
• grafika (podstawowe tryby VGA/VESA na początek)
• możliwość ładowania binarek skompilowanych w C

:)

Mam taki zarys w głowie:

1. wersja x <= 1.0 tylko tryb tekstowy
2. wersja 1.0 > x <= 2.0 dodana zostanie obsługa sieci
3. wersja 2.0 > x <= 3.0 dodana zostanie obsługa trybu graficznego (najważniejszy będzie framebuffer, by uzyskać większe możliowości dla konsoli)

KijWMrowisku napisał(a):

Nie wygodniej i szybciej byłoby to pisać w C?

Nie :) Straciłbym pare lat na nauke języka w stopniu zadowalającym.

PS: 16.04.2015
Jeśli są osoby zaznajomione z językiem asemblera, proszę: https://github.com/Blackden/
Przepisuję kod jądra systemu... powoli.

PS: 17.04.2015
Na serwerze GitHub jest już wystarczająca ilość kodu przeznaczona do kompilacji i uruchomienia jądra systemu w warunkach testowych.

PS: 17.04.2015 12:57
Sprawdziłem czy działa na prawdziwym sprzęcie, płyta główna D510MO + PENDRIVE

Oczywiście to nic nie znaczy :) Bootloader nie posiada obsługi portów USB, tym zajął się BIOS.
Dodatkowo na prawdziwej maszynie po paru/kilku minutach wyskakuje informacja "Unhandled Hardware Interrupt!", co nie występuje na emulatorze. Zdawało mi się, że wyłączyłem pozostałe przerwania sprzętowe...

akasei napisał(a):

KijWMrowisku napisał(a):

Nie wygodniej i szybciej byłoby to pisać w C?

Nie :) Straciłbym pare lat na nauke języka w stopniu zadowalającym.

Wątpię. C to bardzo prosty język, tylko trzeba się trzymać pewnych reguł.

Przeczytaj tę książkę i będziesz wiedział właściwie wszystko co potrzeba na początek:
"Język ANSI C. Programowanie.", Brian W. Kernighan, Dennis M. Ritchie

Tworzenie programowania to:

• napisanie/dodanie kodu
• kompilacja
• uruchomienie
• debugowanie (może być zastąpione przez wyświetlanie)

Dzięki C możesz ten cykl znacząco przyspieszyć. O ile chcesz zrobić coś użytecznego.

Jeśli chcesz zrobić sam wszystko od A do Z (bo np. nie pasuje Ci GNU) to możesz użyć Small C: http://en.wikipedia.org/wiki/Small-C

Musiałbyś go pewnie tylko dostosować do budowania execów x64 zgodnie z Twoimi założeniami.

Jeśli GNU to nie przeszkoda: Tiny C (LGPL): http://bellard.org/tcc/

• dostępne w przeglądarce: http://bellard.org/jslinux/

Więcej kompilatorów: http://en.wikipedia.org/wiki/List_of_compilers#C_compilers

ASM jest dobry do wszelkich interfejsów z hardwarem, do pisania programów (czy nie daj Boże aplikacji) jest strasznym spowalniaczem (chyba że masz już bibliotekę standardową - łańcuchy, pliki, wątki, strumienie, sterta itd).

Edit: jak zrobić własny kompilator: http://www.stack.nl/~marcov/compiler.pdf

vpiotr napisał(a):

Edit: jak zrobić własny kompilator: http://www.stack.nl/~marcov/compiler.pdf

Dziękuje za dokument. Na pewno wyciągnę z niego interesujące informacje przy tworzeniu własnego kompilatora w języku asemblera.

Raczej podziękuję za propozycje wykorzystania języków wysokiego poziomu. Lubię porozmawiać z procesorem i sprzętem po swojemu ;) Projekt zapewne nie będzie znany w świecie. Piszę dla własnej przyjemności.

PS: Z chęcią przygarnę dokumentacje na potrzeby tworzenia kompilatora dla języka asemblera.

Jest parę w miarę działających systemów napisanych w ASM jak kolibriOS.
http://www.dobreprogramy.pl/MikeOS-1.1.1,News,7426.html
http://www.dobreprogramy.pl/ReactOS-0.3.12-dostepny,News,21092.html
http://www.dobreprogramy.pl/MenuetOS-zobacz-co-moze-system-operacyjny-mieszczacy-sie-na-jednej-dyskietce,News,49361.html

Teraz mój edytor tekstowy potrafi zapisywać pliki 8)

Otrzymał(a) nazwę: Moko

Pobierz ostatnią wersje (alfa) 0.392 Uruchamiaj za pomocą Bochs!
Login jest zbędny (hasło też, wciąż nad tym pracuje).

Nie oszukujmy się - poziom dla zdecydowanej większości tutaj nieosiągalny. :)

Próby z obsługą trybu graficznego (framebuffer).
Niestety nie mogę znaleźć w specyfikacji VESA (VBE 2.0, 3.0) obsługi trybów 16:9

Aktualizacja: 20:05

Ta strona może się przydać: http://wiki.osdev.org/Getting_VBE_Mode_Info
Zależnie od tego co masz za sprzęt możliwe, że musisz stosować "haki" w rodzaju tego: http://915resolution.mango-lang.org/

Nie przestaję... :)

Rozdzielczość 320x200x32bpp, czcionka Sinclair (zdobycz od http://flabra.mine.nu/).

Idzie ciężko, gdyż Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia, a Bochs nie wspiera kontrolera SATA.

akasei napisał(a):

Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia
Do Qemu możesz podpiąć GDB (http://wiki.osdev.org/Qemu#GDB-stub). IMHO to bardzo wygodne rozwiązanie, lepsze niż w Bochs.

lukasz1235 napisał(a):

akasei napisał(a):

Qemu i VirtualBox nie posiadają debugera z prawdziwego zdarzenia
Do Qemu możesz podpiąć GDB (http://wiki.osdev.org/Qemu#GDB-stub). IMHO to bardzo wygodne rozwiązanie, lepsze niż w Bochs.

Do GDB mam mieszane uczucia, przykład:
Uruchamiam Qemu z parametrami "-s -S"
To jest mój plik .gdbinit

set arch i386:x86-64
target remote :1234
break *0x100147
set disassembly-flavor intel
continue

Uruchamiam GDB i co się okazuje:

GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
0x0000fff0 in ?? ()
Breakpoint 1 at 0x100147
/root/.gdbinit:4: Error in sourced command file:
Remote 'g' packet reply is too long: 0000000000000000a08f12000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000047011000000000004600000008000000100000001000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000
(gdb)

Podobno popularny błąd przy debugowaniu binarek, którego rozwiązania nie idzie znaleźć...
Zdawało mi się, że mogę to zignorować i po prostu debugować dalej, więc wyświetliłem TUI dla rejestrów i disas.

┌──Register group: general────────────────────────────────────────────────┐
│eax            0x0      0           ecx            0x0      0            │
│edx            0x663    1635        ebx            0x0      0            │
│esp            0x0      0x0         ebp            0x0      0x0          │
│esi            0x0      0           edi            0x0      0            │
│eip            0xfff0   0xfff0      eflags         0x2      [ ]          │
│cs             0xf000   61440       ss             0x0      0            │
│ds             0x0      0           es             0x0      0            │
│fs             0x0      0           gs             0x0      0            │
│                                                                         │
│                                                                         │
│                                                                         │
   ───────────────────────────────────────────────────────────────────────┘
  >│0xfff0  add    BYTE PTR [eax],al                                      │
   │0xfff2  add    BYTE PTR [eax],al                                      │
   │0xfff4  add    BYTE PTR [eax],al                                      │
   │0xfff6  add    BYTE PTR [eax],al                                      │
   │0xfff8  add    BYTE PTR [eax],al                                      │
   │0xfffa  add    BYTE PTR [eax],al                                      │
   │0xfffc  add    BYTE PTR [eax],al                                      │
   │0xfffe  add    BYTE PTR [eax],al                                      │
   │0x10000 add    BYTE PTR [eax],al                                      │
   │0x10002 add    BYTE PTR [eax],al                                      │
   │0x10004 add    BYTE PTR [eax],al                                      │
   └──────────────────────────────────────────────────────────────────────┘
remote Thread 1 In:                                       L??   PC: 0xfff0 
000000000460000000800000010000000100000001000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
7f0300000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000801f0000
(gdb)

GDB nawet nie ruszył z miejsca. Sprawdzam co za "kura" zatrzymała mój kod.

(gdb) info threads
  Id   Target Id         Frame
  8    Thread 8 (CPU#7 [halted ]) (running)
  7    Thread 7 (CPU#6 [halted ]) (running)
  6    Thread 6 (CPU#5 [halted ]) (running)
  5    Thread 5 (CPU#4 [halted ]) (running)
  4    Thread 4 (CPU#3 [halted ]) (running)
  3    Thread 3 (CPU#2 [halted ]) (running)
  2    Thread 2 (CPU#1 [halted ]) (running)
* 1    Thread 1 (CPU#0 [running]) (running)
(gdb)

Sprawdzałem nawet nakładki do GDB, typu DDD... zawiesza się.

Dalej dałem sobie siana, i zostałem przy Bochs Enhanced Debugger.

Zapewne próbujesz debugować binarkę 64-bitową. Faktycznie GDB ma z tym problem, ale istnieje patch (na wersję 7.1, nie wiem czy pasuje do nowszych): http://4programmers.net/Pastebin/4225. Widocznie ciągle tego nie naprawili...

Nic z tego nie rozumiem ale kupie sobie książkę o asm. Na początek dystrybucja Linuxa. Ale czy to co tu jest to jądro czy też dystrybucja Linuxa ?

Wyeliminowałem większość błędów po przejściu na tryb graficzny, za pozostałe znalezione z góry dziękuję.

Proszę bardzo do testowania, przedstawiam dwa dyski twarde:
Qemu, Bochs: hda.zip (GRUB potrafi uruchamiać się wraz z jądrem do 15 sek.)
VBox: disk.zip

Dysk SATA w Qemu podłączamy w następujący sposób (Bochs nie obsługuje dysków SATA):

qemu-system-x86_64 -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0
W tym wydaniu jest już programowy kursor! :D

Próba zlokalizowania karty sieciowej e1000 i pobranie jej adresu MAC:

Na tym zaprzestanę. Muszę skupić się na obsłudze dysków i systemów plików, aby za pomocą panelu sterowania móc zapisywać konfiguracje systemu np.: nazwa jednostki (localhost), strefa czasowa itp.

Gdyby ktoś był zainteresowany to mam w pełni działający patch do gdb 7.9.1:

--- remote-o.c	2015-05-13 19:36:05.000000000 +0200
+++ remote.c	2015-08-08 09:12:42.590407476 +0200
@@ -6154,8 +6154,25 @@
   buf_len = strlen (rs->buf);
 
   /* Further sanity checks, with knowledge of the architecture.  */
-  if (buf_len > 2 * rsa->sizeof_g_packet)
-    error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
+  //if (buf_len > 2 * rsa->sizeof_g_packet)
+  //  error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
+  // Parche implementado para solucionar el problem de reply too long
+  // by Matias Vara 
+  if (buf_len > 2 * rsa->sizeof_g_packet) {
+
+       rsa->sizeof_g_packet = buf_len ;
+
+      for (i = 0; i < gdbarch_num_regs (gdbarch); i++)
+	{
+	  if (rsa->regs[i].pnum == -1)
+	    continue;
+
+	  if (rsa->regs[i].offset >= rsa->sizeof_g_packet)
+	    rsa->regs[i].in_g_packet = 0;
+	  else
+	    rsa->regs[i].in_g_packet = 1;
+	}
+  }
 
   /* Save the size of the packet sent to us by the target.  It is used
      as a heuristic when determining the max size of packets that the
@@ -6167,6 +6184,7 @@
      update our records.  A 'g' reply that doesn't include a register's
      value implies either that the register is not available, or that
      the 'p' packet must be used.  */
+  // Tenemos un serio problema aqui al entrar en real mode me cambia el tamaño de los registros 
   if (buf_len < 2 * rsa->sizeof_g_packet)
     {
       rsa->sizeof_g_packet = buf_len / 2;

Kod źródłowy systemu operacyjnego Cyjon OS (jak i on sam), zostanie wydany na licencji CC SA-NC-ND.
Wszelkie modyfikacje/poprawki/usprawnienia będzie można wprowadzać tylko za pomocą oficjalnych narzędzi np. Git.

Udostępniłem na licencji CC BY-NC-ND pierwszą część kodu źródłowego systemu operacyjnego Cyjon OS
Blisko 6 tyś linii kodu wraz z komentarzami.
https://github.com/Blackden/

Zapraszam do przeglądania.

"Oby slady stóp twoich przetrwały na piasku"

Widzę czcionkę, którą kiedyś stworzyłem kopiując z zxspectrum a potem podarowałem w przypływie pijaństwa akasei :)

Miło przy okazji zobaczyć mnóstwo nowych twarzy i pozdrowienia dlawszystkich (i zielonego pq) :)

Udostępniłem drugą część kodu źródłowego, zapraszam do przeglądania.

@akasei: zakładam że pytałeś o to czy zajrzałem do kodu.

Nic na tyle zaawansowanego w ASM nie pisałem, więc tylko kilka porad natury ogólnej.

1. Komentarze.

• Jest ich dużo, szkoda tylko że po polsku. Blokuje to dostęp programistom spoza Polski (jest ich ok. 150x więcej zakładając podobny rozkład wszędzie).
• czasami przesadzasz (piszesz oczywistości):

	
	; kontynuuj z pozostałymi fragmentami
	loop	.loop

        ; powrót z procedury
	ret

Takie komentarze nie pomagają w czytaniu kodu.

1. W wielu miejscach nie używasz stałych:

        shr	eax,	9	; /512

... w tym samym pliku dalej

	; zamień na pozostałą ilość sektorów do załadowania
	shr	eax,	9

Zamiast tego powinno się dać zrobić:

        SECTOR_CNT equ 9
        shr	eax,	SECTOR_CNT

1. dokumentacja:

• w readme powinno znaleźć się:
  a) wymagania sprzętowe
  b) przetestowane platformy (w tym wirtualne)
  c) adres www projektu
  d) wymagania softwarowe, np. wersja nasm, ew. adres www do kompilatora, wersja i rodzaj OS do kompilacji

• brakuje katalogu \doc, a w nim:
  a) opis katalogów projektu
  b) opis zaimplementowanych komend
  c) lista znanych błędów oprogramowania (niekoniecznie - jeśli jest to prowadzone w github)
  d) opis komunikatów błędów (jeśli jakieś są): kod, treść, znaczenie

1. marketing: dodaj zrzut ekranu do katalogu \doc i podłącz do README.md na github.

1. użyj make w readme
2. w plikach powinna być chociaż 1-liniowa informacja czego dotyczy dany plik, przykład: key_delete.asm: zawiera 14 linii wstępu i w żadnej nie ma takiej informacji

BTW, do kupienia jest nowe ZX, za jedyne 582 zł ;-)
http://www.zxvega.co.uk/

(myślę czy się nie skusić)

Ja dalej żyję :)

Aktualizacja 3.1.2016:

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

Jak tam prace nad systemem? :)

Skupiam się na obsłudze sieci, mogę odbierać i wysyłać ramki Ethernet, odpowiadać na zapytania ARP (czyli, ktoś pyta o adres MAC interfejsu skonfigurowanej dla danego adresu IP).
Niedawno mogłem mieć już gotowe odpowiedzi na protokole ICMP, ale okazało się że takowe ramki nie dochodzą do maszyny wirtualnej. Po prostu cisza, Wireshark jasno dawał mi do zrozumienia, że krążą po sieci, ale wirtualka krzyczy "basta".
Więc na razie rezygnuje z ICMP, i idę głębiej w IP>TCP, same podstawy by obsłużyć protokół HTTP.

Ha! Stało się zadość :)

Pingi działają!

PS: nie piszę stosu TCP/IP, dopóki nie obsłużę choćby połowicznie HTTP.

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

akasei napisał(a):

Aktualizacja 11.06.2016

Nie rób w ten sposób, pisz nowego posta.

Jedna uwaga: czy piszesz kod tak by był thread-safe? Będzie ci potem łatwiej gdy dodasz obsługę wątków (nie wiem czy już masz) i wielordzeniowości.