Nie znalazłem opisu i tego jak to funkcjonuje.

Z rzeczy "marzeniowych" dla mnie jest komunikacja międzyprocesowa (rzeczy typu: dir | more lub type text.txt | convert pl atascii | more) oraz biblioteki dynamiczne (tyle, że tutaj trzeba też kompilatory modyfikować :-( ).

A jak są zrobione dynamiczne biblioteki w DracOS? Ten OS tylko dla 16bit procesora jest? Czy też mówimy o czym innym?

Brak wracania do DOS-a po zakończeniu też mnie kiedyś wkurzał... ale odkąd mam HDD via KMK/JZ IDE i DOS i po boot w sekundę mam załadowanego MyDOS-a, a kombinacja zimnego startu z Q-Megiem działa zawsze, to "powrót do DOS-a" przestał być dla mnie problemem :P
Btw. chyba ktoś jest nieco "nie w temacie" skoro pisze o powrocie do "BASIC-a" - Atari to nie C64/Spectrum, tutaj Basic nie pełnił nigdy poważnej namiastki OS-a :P

z całym szacunkiem dla projektu, ale nie ma sensu. Jest to działanie bez_celowe mając na względzie istnienie KMK/JŻ, oraz IDE'a w połączeniu ze Sparta DOS X np. 4.41 + DracOS na ten przykład. Wielość standardów oznacza ich brak, a problematyczność niektórych powyższych założeń przekracza zdrowy rozsądek. Jest to moje osobiste zdanie :)

Jak wyobrażasz sobie start programu, z wymuszeniem wyjścia przez co - przez SELECT + RESET jak w Qumeg'u?? :) - a jeśli program zapragnie danych z dysku, to jak - opracowanie nowego dosa, filesystemu pod osa, czy jak? - jakikolwiek pomysł na nowy filesystem o możliwościach co najmniej takich jakie posiada SDX, oraz dodanie funkcjonalności powyższych rozwiązań powoduje, iż na całość potrzeba by zapewne "nieco" więcej niż 16kB :) - dodatkowo otrzymując OS w którym wdrażając nowe rozwiązania należało by zaniechać niektórych istniejących rozwiązań. Można pozbyć się selftestu, można skrócić kod zachowując przy okazji tablicę skoków - ale i tak część programów skaczących w OS "na pałę" :) nie będzie działać prawidłowo. Co zresztą tyczy się DracOS'a, lecz niestety nie jest to problem samego osa, tyle co niewłaściwie napisanych programów.

a tak przy okazji niejako - dla programów nie posiadających normalnie możliwości wyjścia do dosa i namolnie po resecie powracających jak zły omen :) - pod SDX wymyślono "ctrl+alt+del" (Lizard/DLT) - sterowniczek dla Sparty umożliwiający wymuszenie wyjścia do dosa ustaloną w config.sys dziwną kombinacją klawiszy :) - np. ctrl+shift+inverse :)

nie wiem Mac - ale mi SDX po resecie wstaje około 3 sekundy ładując masę masy wszystkiego, co dobre :)

"Wystarczy, że mam pomysł na loader, który pozwoli uruchomić dowolny stary program."

... jestem za, jeśli może być to jedyna modyfikacja OS - tylko z jakiego nośnika i na jakiej zasadzie chcesz to odpalić?

Podsumuję to co przeczytałem o SDX:

* SpartaDOS nie posiada komunikacji międzyprocesowej
* brak jest zarządzania pamięcią nie licząc podstawowej relokacji programów i tego co jest od zawsze w ROM/MEMLO/MEMHI
* relokacja jest pełna/2bajty, a według mnie w zupełności wystarczy połowiczna, a co za tym idzie łatwiej, prościej, kompatybilniej.
* rzeczywiście biblioteki są dynamicznie ładowane ale jest to dosyć ograniczone i to program bibliotekę dodaje, a nie biblioteka jest ładowana do systemu. mnie interesuje załadowanie biblioteki, a nie sklejenie jej z programem, który ją używa. Nie jestem również pewny czy biblioteka może używać JMP. Wydaje mi się, że może ona jedynie poruszać się w obrębie swoim oraz wywołań systemowych.

W tej chwili tyle wyczytałem z tej dokumentacji SDX. Jeśli się mylę zapraszam.

Jedno pytanie dodam.
Czy pod 6502 istnieje jakiś assembler, który posiada opcje optymalizacyjne?
tzn. kilka rzeczy mam na myśli ale taka dosyć oczywista to automatyczny inline dla JSR-ów jeśli JSR jest wywoływany w programie tylko raz.

ArchieIl: ciekawe kiedy ci przejdzie... jesli jednak nie tylko na checiach sie skonczy, a moze cos i zakodujesz - to polecam przyjrzec sie zrodlom contiki - masz tam i zarzadzanie pamiecia (ztcp z dokladnoscia do strony, albo do 16tu bajtow) i obsluge graficznych aplikacji, multitasking, stos tcp/ip, obsluge SLIP
z podobnych rzeczy - lunix - tez multitasking, tez zarzadzanie pamiecia...
btw. jak chcesz cos co bedzie optymalizowalo kod assemblerowy - jedyne takie narzedzie jakie znam pod 6502 - to opt65 z pakietu cc65.
o zrodlach SDX - zapomnij...

tebe: pewnie misiowi chodzi o przeniesienie procki wykonywanej przez jsr (z jego jednoczesnym wywaleniem), jesli przed labelem tej procki znajduje sie rts - cos jak "faktoryzacja" (refaktoryzacja tylko od dupy strony :P ) kodu.

Archiell, co do "rurki" (pipeline), to nie trzeba tego robić za pomocą komunikacji międzyprocesowej a'la Unix. Wystarczy to zrobić tak jak kiedyś było rozwiązane w MS-DOS: proces zwraca wartość (treść STDOUT albo chociaż kod powrotu), a DOS uruchamia następny proces z podanym parametrem na wejściu.
W ten sposób jest do rozwiązania tylko kwestia tego bufora, za pomocą którego procesy będą przekazywać sobie dane.

znasz co? contiki (mialo kiedys nawet atarowski port)? luniksa? cc65?

"on jest od c-64" - kto? znajomy? czy moze o ktorys z tych projektow ci chodzi? (wszystkie tycza sie procesorac 6502, jak i maja jakotakie rozgraniczenie miedzy sprzetem, a core systemu)

edited: taka wymiana w stylu msdosowej "rurki" w przypadku sdx jest mozliwa polowicznie mozliwa, bo umozliwia on przekierowanie stdout (CON:) do pliku.
ty nie widzisz sensu - co nie oznacza ze inni go nie widza. taka konstrukcja sporo upraszczala - bo msdos nie ma wewnetrzenych mechanizmow do komunikacji miedzyprocesowej (z zasady byl stworzony jako jednoprocesowy), ale dalo sie to w ten sposob zrealizowac na poziomie programowym - czyli interpretera polecen (command.com).

Znam contiki i luniksa od dosyć dawna tak jak ELKS-a jeszcze z czasów gdy zaczynał powstawać (zresztą w tej chwili chyba ELKS nie jest dalej rozwijany).
Znajomy pisał o ile dobrze pamiętam pod LUniksa jakieś aplikacje. To było z 4-5 lat temu gdy mi pokazywał swoje wypociny więc nie pomnę dokładniej ale pewnikiem jest ujęty w Copyrightach.

I?

tzn. mam projektować system wielozadaniowy z "|" po plikach bo w SDX jest tak wygodnie?

W DOS też było w miarę z tym wygodnie co nie zmienia tego, że DOS-a ani SDX-a drugiego na Atari robić nie planuję.

LUniksa obejrzę dokadniej bo ma największe szanse posiadać w kernelu (szczególnie Atarowskim) niektóre interesujące mnie rozwiązania zrobione w sposób akceptowalny.

Z <, > i 2> jeszcze się zastanowię co zrobić. tzn. jako podstawę chciałbym mieć aplikacje pełnoekranowe zmultitaskowane (akurat na Atari powinno to ślicznie hulać) ale na potrzeby "|" jakieś strumienie też będę musieć zrobić acz jeszcze dokładniej nie mam tego fragmentu opracowanego.

Nie wiem w czym może pomóc wykształcenie informatyczne przy Twoich problemach. Samo pytanie o optymalizującego asemblera (który z definicji nie powinien robić nic ponad to co każe mu programista) nie motywuje do zabierania udziału w dyskusji :)