51

To ja już wolałem dobrego sera - przynajmniej używał argumentów, które opierał na realiach i nie był nudny ;)

52

Pecus napisał/a:

A ja - biedny mis klepalem sobie rozne procedury transmisji przez lata - na przerwaniach, a szybkie bez (bo i tak sie nic w miedzyczasie zrobic nie dawalo). A teraz widze, ze zawsze robilem to zle i nie wiedzialem, ze oprogramujac obsluge przerwan pisze procedury nie oparte na przerwaniach - o ja glupiec ide sobie glowe rozbic o mur, i pokasuje z dysku te wszystkie programy, a moze poprosze wielu uzytkownikow by tez to zrobili, bo to nie ma prawa dzialac wg fachofcoof.

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

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

53 Ostatnio edytowany przez Zenon/Dial (2008-04-16 20:26:25)

Nigdy w to nie wątpiłem, zastanawiam sie tylko.....kiedy.
Trzęsę się ze strachu.... jak to dobrze że za bardzo nie znam się na Atarynce i że wypadnie na innych.
Tego o co prosisz nie mam.... a co jeszcze potrzebujesz?

54

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.

55 Ostatnio edytowany przez ArchieIl (2008-04-16 20:58:32)

Już mówiłem, że załatwiałby to loader (mowa o wersji softwarowej, w przypadku podmienionego ROM problemu nie widzę).

Mam +/- opracowany pomysł jak radzić sobie z takimi "wredotami".
W zasadzie biorę pod uwagę "patchowanie" takich programów w locie zostawiające handler exit na potrzeby OS-a w najgorszym razie. Każdy handler przerwań da się bowiem przejąć, a każdy program przynajmniej kilkaset bajtów wolnej pamięci zostawia.

Ale to tylko pomysł ostateczny. W normalnej sytuacji zostawałaby procedurka realizująca powrót do systemu ze starego oprogramowania.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

56

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?

http://atari.pl/hsc/ad.php?i=1.

57 Ostatnio edytowany przez ArchieIl (2008-04-16 21:32:48)

Mam powiedzieć prawdę?
Tylko nie zaplujcie monitorów ze śmiechu.

I tak i tak.
Podczas ładowania wprost ale biorę również pod uwagę wstępne podczas ładowania i późniejsze w trakcie działania. Przynajmniej na potrzeby dekompreserów.

Nie będę jednak ukrywać, że programy samodekopresujące się i samo relokujące wolałbym inaczej traktować niż patchowaniem wielostopniowym. Nie wiem tylko czy alternatywy będą akceptowalne bardziej niż metoda podstawowa.

Przede wszystkim wolałbym wbudować kompresję/dekompresję w system niż zdawać się na programy zewnętrzne. Szczególnie, że metody kompresji mogłyby być konfigurowalne w zależności od upodobań.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

58

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 ;)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

59 Ostatnio edytowany przez ArchieIl (2008-04-16 22:00:08)

ok.

W takim razie mogę trochę uszczegółowić jak sobie wyobrażam loader:

Program nie natywny oprócz podstawowego pliku posiadałby plik nazwa.cfg, w którym znajdowałaby się informacja dla loadera pozwalająca spersonalizować sposób jego obsługi oraz wymagania względem pamięci, przerwań itd. (coś w stylu *.pif z Windows)

Dzięki takiemu podejściu OS wiedziałby w jaki sposób należy przygotować Atari do załadowania danego programu (strona 0, stos, ROM-y itp.) i w jaki sposób zapewnić sobie przejęcie komputera po zakończeniu działania kodu.

Oczywiście w przypadku braku pliku cfg istniałaby domyślna konfiguracja decydująca o zachowaniach standardowych (konfigurowalna oczywiście).

Jako alternatywa dla pliku cfg istniałby również rozszerzony format podstawowy pliku, który dodawałby jedynie nagłówek zawierający informacje wstępne dla loadera.
Wolę jednak zapewnić nietykalność i uruchamialność oryginalnych gier, a na dodatek łatwą edycyjność konfiguracji stąd te oddzielne pliki cfg, a format rozszerzony bardziej ma sens w przypadku odczytu z magnetofonu ;-).

W cfg byłaby również ujęta procedura konieczna do zapewnienia powrotu z programu do OS-a. Od sytuacji typu: zostaw handler na VBI po binarny kod patchujący program na potrzeby procedury powrotnej.

Sam pomysł loadera może być wykorzystany nie tylko na potrzeby pozostałych opisanych tutaj rozwiązań dlatego go tutaj wklejam. Może np. w SDX takie rozwiązanie miałoby rację bytu.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

60

>> 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'.

http://atari.pl/hsc/ad.php?i=1.

61

Jeszcze do tego mieszanie pojec OS i DOS. W Atari (jak i BIOS w PC) OS nie obslugije wogole czegos takiego jak pliki, dzieki temu moze istniec wiele formatow dyskow. JAk sobie wyobrazasz obsluge plikow w takim razie i Twoj magiczny cfg?, jak ma go OS odczytac? Napisac bedzie trzeba i DOS, a do tego obslugujacy wszystkie znane formaty dyskowe atari (pisales ze ma czytac wszystko - tak??), czyli napisac trzeba Sparta DOS X ;) - powodzenia. Howk! (czy jak to sie tam pisze, nie wiem nie jestem dyplomowanym znawca jezyka indian polnocnoamerykanskich).

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

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

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.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

63

ArchieIl - jak skończysz to pisać, to daj znać :)

Kontakt: pin@usdk.pl

64

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

--
Dhor/M.E.C.

65

ArchieIl: powodzenia w pisaniu potrzebnego ci softu <- życzenia podlane mocnym sosikiem sarkazmu :P. By napisać nowy system operacyjny na Atarkę, trzeba mieć praktykę (i to bardzo dużą) w programowaniu i WIEDZĘ, przede wszystkim praktyczną. Teoretyzować każdy potrafi. Ja też zacytuję Foxa: "napisz se".

Też mi się marzy parę rzeczy na Atari, ale po pierwsze: nie mam wiedzy programistycznej; po drugie: nie mam takiejże praktyki; po trzecie: nie krytykuję tych, którzy się na pisaniu softu znają, a ośmielają się wytykać błędy w moim jakże wspaniałym rozumowaniu i epokowych pomysłach. :D

Najpierw coś (COKOLWIEK) napisz i przedstaw na AtariArea, a nie wyjeżdżaj z ideami, które inni będą "musieli" (wg twojego mniemania) realizować...

Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

Terry Pratchett - Równoumagicznienie

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

ArchieIl napisał/a:

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.

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.

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

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.

Znalazłem to: http://tajemnice.atari8.info/ksiazki/pw ? egowa.html i z tego wynika, że oryginalne procedury I/O używały polling.

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:

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.

(ROTFL)

Nie zastanawia cię ten fenomen?

Stawiam jednak, że dla Drac030 WE/WY po przerwaniach to polling z opóźnieniami odczytu portów sterowanym przerwaniami zegarowymi.

Przegrałeś.

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.

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?

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.

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

KMK
? HEX$(6670358)

67

drac030 napisał/a:
ArchieIl napisał/a:

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.

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

ok.

Asynchroniczne procedury WE/WY.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

68

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.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

69 Ostatnio edytowany przez ArchieIl (2008-04-18 07:54:55)

Stąd nie rozmawiam.

Jeszcze raz powtórzę, że mówiąc o asynchronicznym WE/WY miałem na myśli asynchroniczne PROCEDURY WE/WY, a nie przesyłanie danych po drucie asynchroniczne.

Moja wina, że nie zauważyłem wieloznaczności potencjalnej.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

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

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.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

71

Pecus napisał/a:

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.

Już kiedyś proponowałem (na grupach dyskusyjnych bodajże, a na pewno prywatnie pewnemu "królowi") zrobienie interfejsu IDE z transmisją bez udziału procesora Atari do momentu jej zakończenia.

Jeśli coś wyjdzie z "ParAOS" (roboczo od Parallel Atari OS) to i będziecie mieć presję żeby kogoś poświęcić do realizacji.

Acz może się okazać, że do tego czasu zostaną tylko zupgradowane Atarki, w których Atari służy za klawiaturę dla drugiego/upgradowanego procesora.

--
1985? - DA'Fuzz, 1987? - Meritum, 1989? - Atari 130XE, 1992 - PC/AT, 2008 - Atari 130XE + Meritum

72

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

Powszechnie wiadomo, że kamień potrafi myśleć. Na tym fakcie opiera się cała elektronika.

Terry Pratchett - Równoumagicznienie

73

> Jeśli coś wyjdzie z "ParAOS" (roboczo od Parallel Atari OS) to i będziecie mieć presję żeby kogoś poświęcić do realizacji.

poswiecaMY Ciebie.

> w których Atari służy za klawiaturę dla drugiego/upgradowanego procesora

ParAProc... tak, tez Ciebie poswiecaMY

jesli jeszcze raz bedziesz mowil z Elvisem da King wez dla mnie autograf.

http://atari.pl/hsc/ad.php?i=1.

74

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ż?...

75

Temat nie jest całkiem bezsensowny (patrz http://www.grush.one.pl/article.php?id=vm8bit ), szkoda tylko, że nie widzieliśmy ze strony autora ani jednej linii kodu potwierdzającej zdolność jego realizacji. :)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.