Żebyś nie pożałował, że się tutaj publicznie przyznałeś.

Jeśli coś zrobię i zacznie wyglądać, że nie będzie to tylko papier to z tego wątku powybieram sobie ludzi do męczenia o pomoc w rozwijaniu projektu.

Potrzebuję docelowo oprócz OS-a:
* zmodyfikowany assembler potrafiący tworzyć "exe" pod niego
* zmodyfikowane cc65 potrafiące kompilować pod OS i posiadające zmienione biblioteki związane z komunikacją systemową
* całą masę programów narzędziowych do przeportowania zarówno z SDX jak i z LUnix, contiki jeśli będzie to możliwe.
* BASIC potrafiący działać w nowym OS-ie i będący zgodny z Atari BASIC (tutaj akurat liczę, że uda się Drac030 przekonać do sportowania jego MultiBASIC-a)
* testerów, którzy powieszą albo mnie albo OS-a ;-)

Przy okazji przypomniałem sobie, że w przypadku Atari dobrze by było gdyby OS potrafił zarządzać overlaysami. Wtedy Numen w jednej wersji mógłby działać z dowolną Atarką. Z rozbudowaną całość byłaby w pamięci rozszerzonej, a w biednej starej 65XE zarzynałby stację/dysk/PC-ta (o ile autorzy Numena chcieliby zrobić taki port).

pozwolicie, ze sie wtrace, ale mam pytanie:
bazujac na dotychczasowych doswiadczeniach (sparta i jej rozne formaty binarne) wnosze, ze jakies 98% rzeczy, ktore na atari powstaja sa w starym dobrym formacie z naglowkiem ffff. jakos ciezko sie ludziom przelamac i nie za bardzo chca uzywac nowych/innych formatow (w tym i ja).
mozna wiec stwierdzic, ze nowy system bedzie musial walczyc w zdecydowanej wiekszosci z takimi programami. wiele z nich, pierwsze co robi po uruchomieniu sie, to wywala rom i wstawia wlasne przerwania (i wszystko inne jak trzeba). jak zatem planujesz/kombinujesz, aby taki program nie rozwalil systemu z jego feature'ami? bo system sam w sobie ok, ale fajnie by bylo, zeby tego dalo sie z czymkolwiek uzywac. nawet autorzy sparty to zrozumieli i kompatybilnosc (w jedna strone) jest zachowana z wiekszoscia rzeczy.

jako doswiadczony user atari (przeszedlem river raid - na czitach ale zawsze) uwazam, ze taki os nigdy nie powstanie! smialo, sprobujcie mi udowodnic ze sie myle.

> W zasadzie biorę pod uwagę "patchowanie" takich programów w locie

w locie uruchomiony program czy w locie podczas ladowanaia?

To ja jeszcze raz odpowiem na pytanie z tematu: NIE.

A jak czytam coraz to nowsze pomysly nie majace poparcia doswiadczeniem w pisaniu czegos na atari (to widac po pomyslach :) ), to tylko moge zacytowac kolega - "Napisz se".
Nie lubie czytac jak ktos majacy mgliste pojecie o sprzecie i oprogramowaniu rzuca tekstami o wspanalym sofcie jaki zaraz stworzy. Powodzenia, zdezygnuje z czytania tego watku, bo nerwowy jestem i moglbym kogos nieumyslnie obrazic ;)

>> W zasadzie biorę pod uwagę "patchowanie" takich programów w locie

>w locie uruchomiony program czy w locie podczas ladowanaia?

>I tak i tak.

nie mozna tego zrobic ani tak ni tak. powodow jest kilka. niestety musze sie zgodzic z innymi w tym watku - nie masz doswiadczenia w programowaniu tego typu 'aplikacji'.

ArchieIl: A jak planujesz wykrywać i patchować kod samomodyfikujący się? Ot takie proste:

src equ *+1
  lda *
dst equ *+1
  sta *
  inc src
  bne *+5
  inc src+1
  inc dst
  bne *+5
  inc dst+1

To oczywiście najprostszy przypadek - zdarzają się nieco bardziej zagmatwane (xxl chyba ma najwięcej doświadczenia z racji prac nad emulatorem zx).

edit: Czy też może sensowniejszy przykład:

  lda dosvec
  sta restl
  lda dosvec+1
  sta resth
  ...
restl equ *+1
  lda #<*
  sta dosvec
resth equ *+1
  lda #>*
  sta dosvec+1

Albo wektory nadpisywane/modyfikowane na przerwaniach dli lub vblk?

W sumie mając system wielozadaniowy z wywłaszczaniem procesów można by było zrobić proces systemowy zajmujący się tylko patchowaniem pozostałych procesów w locie. Ale wydaje mi się, że zarżniesz w ten sposób system operacyjny. Można sobie wyobrazić, że w ten sposób mógłby działać antywirus, ale żaden do tej pory tego nie robi, bo każda wirtualizacja/emulacja będzie wolniejsza, niż realizacja programu w realtime. W efekcie Twoje patchowanie nie będzie działać do końca poprawnie (bo będzie się ścigać z analizowanym procesem), albo jeśli wyhamujesz procesy użytkownika okaże się, że Twój OS w zasadzie będzie służył do analizy procesów użytkownika, zamiast do ich jak najszybszego wykonania, co chyba nieco mija się z celem.
Patchowanie przed uruchomieniem procesu (np. podczas ładowania z dysku) nie załatwi Ci dynamicznych modyfikacji kodu chyba, że znajdziesz w programie wszystkie sekwencje modyfikujące dynamicznie kod i je "naprawisz" nie zaburzając funkcji programu. A potem wyszukasz sekwencje, które korzystały z poprawionego przez Ciebie kodu i je znowu "naprawisz" i tak w nieskończoność. Można się umówić oczywiście, że takie działania są już bardzo hakerskie i raczej żaden rozsądny program nie będzie tego robił albo, że przeanalizujemy tak kod do 3 zagnieżdżeń - ale nie osiągniemy w takim razie 100% pewności. Ale może na 100% pewności nam nie zależy, a jedynie na tym, żeby działało powiedzmy 90% programów.
Jeśli masz inny pomysł na to patchowanie to chętnie posłucham.

Ostatnio edytowany przez mono (2008-04-17 00:03:49)

Eh, znowu teoretyzowanie... A miałem nadzieję na porządny port Lunixa na Atari. Praca w tekstowej konsoli z tekstowymi narzędziami, a nie jakieś pierdoikonki....

No b. ciekawe. Może mi przytoczysz moją wypowiedź, z ktorej wynika, że nie wiem, co to jest DMA albo bus mastering. Pośmiejemy się razem.

Jak to ci już naświetlił Pecuś, to nie jest tak, że ja nie wiem, co to jest we/wy na przerwaniach, ale tak, że ty nie masz pojęcia o tym, jak działa SIO w Atari, oraz do czego jest linia Interrupt na złączu SIO.

Więc źle zrozumiałeś tekst. I, notabene, zauważ, łaskawco, iż różnica pomiędzy tobą a sporą częścią dyskutantów tutaj polega na tym, że oni po prostu wiedzą (z teorii i praktyki) to, co ty dopiero musisz przeczytać z mozolnie wyszukiwanych w sieci tekstów, które na dodatek raz za razem opacznie rozumiesz, bo nie masz podstaw:

(ROTFL)

Nie zastanawia cię ten fenomen?

Przegrałeś.

No co ty powiesz :) Gdyby nie ty, nikt tutaj by na to nie wpadł. A tak btw. w którym miejscu jest napisane, że SIO generuje "timeouty i opoźnienia" przy użyciu timerów Pokeya?

LOL, "powinno się udać asynchroniczne WE/WY zrobić". I ty mi zarzucasz, że terminologii nie rozumiem.

Ostatnio edytowany przez drac030 (2008-04-17 14:45:59)

Moze Ci sie uda takie procedury zrobic. Tyle ze innym juz sie udalo, chocby tworcom atari....
Widzisz, nawet nie wiesz, ze systemowe procedury transmituja dane asynchronicznie, lub tez nie rozumiesz pojecia transmisji asynchronicznej.
Tak, czy inaczej trudno sie z lajkonikiem rozmawia.

Raz piszesz o asynchronicznym We/Wy a  raz o procedurach asynchronicznych - zdecyduj sie. W przypadku Atari asynchroniczne procedury We/Wy nie maja wiekszego sensu (szczegolnie w trybach szybkiej transmisji). Przy szybkosci komunikacji ze stacja dyskow rzedu 80-100kbps (a niektore turba taka maja), procedury obslugujace sama transmisje, musza byc specjalnie optymalizowane, by wogole mialy czas sie wykonac i nie gubic danych. Robienie w tym czasie czegos innego wymaga cudu - ale Ty jestes u nasz specjalista od cudow. czekam wiec na pierwszy program. Ja swoje juz napisalem i mialem okazje spotkac sie z tymi problemami.
Najpierw napisz JAKIKOLWIEK loader do CZEGOKOLWIEK na atari, chetnie pomoge, choc w zasadzie ja mam swoj loader i niby czemu mam czas marnowac - bo dla mnie to marnotrastwo czasu.

P.-S. Oczywiscie i to bez wiekszych problemow mozna zrownoleglic transmisje i inne operacje przy normalnej szybkosci transmisji (tylko kto teraz taka stosuje), przykladem oryginalne dyskowe gry Lucasfilmu. Tam jest co prawda "odwrotnie" (kto wie to zrozumie), ale to dziala.

Ostatnio edytowany przez Pecus (2008-04-18 08:01:46)

Pecuś, nie nerwujsja... Szkoda nerwów dla kogoś, kto tylko teoretyzuje, miesza i myli pojęcia, nie jest w stanie wychwycić ironii i sarkazmu, do tego ma postawę życzeniowo-roszczeniową co do softu i upgrade'ów (do tego jeszcze na jego warunkach). Bojkot jego postów i tyle. :)

Gdy czytam ten wątek, to przypomina mi się taki przypadek:
W okresie zimnej wojny Amerykanie usilnie pracowali nad dwuprzepływowymi silnikami rakietowymi do zastosowań ogólnie znanych. Wielokrotne próby kończyły się fiaskiem, więc uczeni NASA uznali to za technologicznie niemożliwe. Jakie było ich zdziwienie, gdy jeden z nich wynalazł taki silnik. U Rosjan w magazynie. Co więcej, było ich ponad 100 i leżały tam od blisko 20 lat. Sprzedane zostały na pniu. Rosjanie nie wiedzieli, że się nie da, więc zrobili...
Dajcie więc naszemu nowemu koledze szansę, udostępnijcie posiadane w archiwach informacje, a nie piszcie, że się nie da. A nuż?...