A zaboli kogoś jeśli mi nie wyjdzie? Lub raczej jeśli mi chęci nie stanie?

Wiesz... dla was guru to np. Drac030 ale on mi już wielokrotnie udowodnił, że nie rozumie nomenklatury jaka powstała przez te X lat od momentu gdy Atari 8bit przestało być produkowane.

Tak było kiedyś z DMA/bus masteringiem.

Tak jest teraz z WE/WY sterowanym przerwaniami, a nie z użyciem polling.

Może rzeczywiście czegoś nie wiem, zapomniałem. Informację zbieram po kawałeczku przez całkiem długi okres czasu więc coś mogło mi się zatrzeć w pamięci...
Stawiam jednak, że dla Drac030 WE/WY po przerwaniach to polling z opóźnieniami odczytu portów sterowanym przerwaniami zegarowymi.

Przynajmniej z procedur SIO jakie znalazłem wynika, że timeouty i opóźnienia są z użyciem przerwań timerów POKEY ustalane ale to nie jest WE/WY sterowane przerwaniami. Urządzenia w Atari według wszelkich szans nawet linii interrupt w SIO nie mają podłączonej do czegokolwiek.

Pomijając. Zbaczamy z tematu.
To co znalazłem potwierdziło jednak, że powinno udać się asynchroniczne WE/WY zrobić nawet jeśli mam rację, że "normalne" urządzenia w Atari korzystają wyłącznie z polling.

MM: Proszę przeczytać regulamin, szczególnie w punktach dot. poprawnego cytowania. Timer: 24h. Dziękuję za uwagę.

a) Opieram się na zdaniu: brak było urządzeń korzystających z linii interrupt w SIO (mowa o oryginalnych produkowanych przez Atari). W tej chwili nie znalazłem źródła tej informacji.
b) Znalazłem to: http://tajemnice.atari8.info/ksiazki/pw … egowa.html i z tego wynika, że oryginalne procedury I/O używały polling.
c) Z opisu tutaj: http://atariki.krap.pl/index.php/SIO również nic nie wskazuje na to żeby linia interrupt w SIO była używana. Nie pamiętam czy w schemacie SIO2PC interrupt jest do czegoś używany.

Dodatkowo znalazłem informacje, że w ROM istniały procedury SERIN, SEROUT czy jakoś tak, które miały obsługiwać przerwania od urządzeń ale nie znalazłem dokładniejszych informacji o tym jakie urządzenia z tego korzystały.

Nie znalazłem również źródeł szybkich I/O, które są używane w nowych "OS-ach" Atarowskich. Nie wiem jak w nich jest to zorganizowane. Trudno mi też powiedzieć jak wygląda sytuacja po instalacji turbo w stacjach i czy stacje nie produkowane przez Atari również nie obsługiwały linii interrupt w SIO.

Oczywiście pamięć bywa zawodna, a ja informację o interrupt w SIO znalazłem w opisie sprzętu, a nie opisu procedur SIO w ROM.

Przeczytałem uważniej ale zarządzanie na zasadzie przydziału pełnych 16K potraktowałem jako brak zarządzania.
Tak jest to już coś, a w systemie jednozadaniowym nawet wystarczające coś.
Tylko, że to trochę nie ten poziom zarządzania pamięcią. Może się mylę ale nie pamiętam np. przełączania banków przez SDX-a w zależności od potrzeb programu.

Jest o tym w przykładach.
Połowiczna zmienia tylko bardziej znaczący bajt i pozwala na rzeczy typu:

  LDA #<MEM
  ....
  LDA #>MEM

Jeśli dobrze zrozumiałem biblioteka jest linkowana z programem i JMP relokowane względem miejsca dołączenia czyli albo wewnątrz biblioteki można JMP używać albo do adresów ogólnie znanych. Nie można zrobić JMP do innej biblioteki, programu itp.
Mogę się tutaj mylić bo bazuję na zgrubnym opisie z PDF-a, a nie źródłach.

nie ma sprawy ty. ;-)

Z maszynowym przesadziłem.
Maszynowy optymalizują sobie same procesory ;-) i emulatory co niektóre ;-).

Przykład zmiany kodu w zależności od opcji podałem.
Szukać optymalizującego w kompilatorach nie planuję bo mi to nie potrzebne (as86 wystarcza jako przykład), a u siebie mam gcc, w którym as chyba nic w tym względzie nie robi (kompilator tworząc kod wynikowy wyręcza assembler w tej sprawie).

Jeśli ktoś tutaj jest zainteresowany to w googlach pewnikiem coś znajdzie.

google twoim przyjacielem.

Optymalizujące assemblery znam z lat 93-94 (opisy w jakichś gazetach, część kompilatorów końcową optymalizację robi w assemblerze lub oddzielnym narzędziu optymalizującym kod maszynowy np. na potrzeby pipeliningu w procesorach).

Z nie optymalizujących (w moim znaczeniu tego słowa) ale ingerujących w wynikowy kod opcji np. as86 (man as86):

 -j  replace  all  short  jumps  with similar 16 or 32 bit jumps, the 16 bit conditional branches
     are encoded as a short conditional and a long unconditional branch.
 -O  this causes the assembler to add extra passes to try to use forward  references  to  reduce 
     the bytes needed for some instructions.  If the labels move on the last pass the assembler will
     keep adding passes until the labels all stabilise (to a maximum of 30 passes)  It's  probably  not
      a good  idea to use this with hand written assembler use the explicit br bmi bcc style opcodes
     for 8086 code or the jmp near style for conditional i386 instructions and make  sure
     all  variables are defined before they are used.

Prosiłbym jednak o odzywanie się ludzi mających jakąś wiedzę i rozumiejących temat, a nie chcących się douczać.

Ja nic(*) nie robię a'la UNIX. a'la UNIX robią spece od contiki i LUnixa wraz z C jako podstawą systemu ;-).

W DOS komunikacja międzyprocesowa odbywała się z użyciem plików zewnętrznych, a nie zostawianiem stdout w pamięci.

Jeśli robić system wielozadaniowy nie widzę sensu w bawienie się wymianą danych z użyciem plików.

*) ideowo komunikacja międzyprocesowa... praktycznie zależy mi na szybkości, a nie robieniu czegoś a'la coś działającego na procku z 8 (i więcej) rejestrami

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.

Znalazłem:
http://trub.atari8.info/sdx_files/4.41/ … amming.pdf.

Co do wgłębiania się w sens mojej realizacji to nie chce mi się.

Z chęcią jednak zobaczę co z tego co chciałbym mieć zostało zrobione. Ja spartę widziałem ostatni raz w wersji 3.x o ile nie wczesniej i bardziej na obrazku niż w rzeczywistym użyciu.

Jeśli do SDX znajdę źródła i dokładną dokumentację, a nie tylko pobieżny opis to możliwe, że włożę do niej tyle ile się da z tego co chciałbym żeby było zrobione ;-) zamiast kombinować z zastąpieniem OS-a w całości.

Tyle powiem, że nie widzę sensu zachowania zgodności z oryginalnym OS Atari w żadnym aspekcie. Wystarczy, że mam pomysł na loader, który pozwoli uruchomić dowolny stary program.

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?

dzięki.

W zasadzie wątek znalazłem szukając postów truba i zdążyłem się w sprawę nieco bardziej wgłębić.
Zostaje mi tylko upolować w dalszej perspektywie odpowiednią stację ;-).

Gdyby ktoś tutaj miał zbędną stacje, może być z niedziałającym flopem ale widoczną na SIO (istnieje pomysł startowania CP/M z SIO z użyciem stosownej funkcji ROM stacji, a nie z dyskietki).
Acz ja raczej przed czerwcem/lipcem raczej większych kwot w Atari inwestować nie będę.

nie nie nie... ;-)

Nie mówię o rozszerzeniach. Akurat te oglądam i w tej chwili jestem w miarę na bieżąco. Zresztą od tego jest inny wątek (w tym moim kupionym 130XE GTIA mam na podstawce więc w zasadzie nie miałbym przeciwskazań dodać "kanapkę", która nie wymagałaby innych przeróbek czy wierceń).

Zastanawiam się raczej nad:
* podłączeniem do inetu i wystawieniem microchessa na Atari jako samodzielnego użytkownika serwera szachowego z preprocessingiem bardziej skomplikowanych requestów na PC (tzn. grałoby Atari, a komunikował się z serwerem PC żeby to Atari nie wymiękło od nadmiaru śmieci).
* zrobieniem łączki Centronics->JOY co pozwoliłoby mi wygodnie grać w gierki Atarowskie... mówiąc szczerze wolę klawiaturę prawie zawsze niż joy stickowy.
* porobieniem trochę rzeczy, których nie mogę nigdzie znaleźć, a które z chęcią bym sprawdził.

Stacji dysków nie mam i jeśli bym kupił to właśnie tylko na potrzeby sprawdzenia owego CP/M. Chyba, że znajomy ma jeszcze swoje Atari i od niego udałoby mi się wydobyć komplet, który z kumplami podczas "szkółki szachowej" czasem u niego obciążaliśmy.