Bardzo honorowym wyjściem w sytuacji poprawiania czyjegoś programu, jest pozostawienie swojej pracy bezimienną. Jest to dla mnie postawa imponująca, ponieważ mają prawo oddziaływać w takim kimś różne ambicje związane z "pokazaniem się" tym wszystkim, na których opinii mu zależy.
Całkowite pomijanie zasług autora programu, jest z reguły nie do przyjęcia. Może się jednak, sądzę, zdarzyć i tak, że jakiś program, którego autorstwo jest niepodważalne i powszechnie znane, zostanie podpisany przez autora poprawek, w sytuacji, gdy te są znaczące i istotne dla działania samego programu. Chociaż godzi to w pewne dobre obyczaje, które winniśmy skrupulatnie przestrzegać, nie stanowi większego zagrożenia dla stwierdzalności rzeczywistego autorstwa danego programu.
Podsumowując, byłoby dobrze, żeby w podobnych wypadkach, kiedy autor poprawek pragnie zostać zidentyfikowany, albo wyraźnie zaznaczać w komunikatach programu, że się jest jedynie autorem pewnych jego poprawek, a nie całości, i nie dotykać podpisu autora, albo zawrzeć inforamcję o swoim autorstiwe w jakiejś dodatkowej dokumentacji dołączanej do programu z poprawkami.

Bardzo interesujące jest to urządzenie, szczególnie sposób jego działania. Tak jak Sajgon, przeglądnełem sieć w poszukiwaniu ATRki zawierającej odpowiednie oprogramowanie. Niestety także bezskutecznie. Chociaż coś chyba jednak znalazłem, mowa o BobTerm XEP80 driver. Sama strona też jest wielce interesująca i zawiera bardzo cenne materiały. http://www-users.rwth-aachen.de/mathy.v … /stuff.htm. Na stronie np. jest do sciągniecia gra multidash.
Duża część plików do atari na stronie jest spakowana ARCem. Co do multidasha, to nie udało mi się przy pomocy PCtowych archiwizerów bezbłędnie rozpakować go przy ich pomocy. Wnoszę stąd, że należy do tego celu posłużyć się atarowkim SuperARCem.
Chciałbym polecić też stronę prezentującą wygląd grafiki wyświetlanej poprzez to urządzenie. http://www.atarimagazines.com/v7n6/xep80slideshow.html

Mam też pewien pomysł (nie wiem jednak czy dobry), jak mozna spróbować wejść w posiadanie tejże dyskietki z oprogramowaniem do urządzenia. Znalazłem informację na bardzo dobrej stronie o atari: http://www2.asw.cz/~kubecj/atari.htm, że autor strony dysponuje tym urządzeniem. Sądzę, że jest duża szansa, że posiada także odpowiednią dyskietkę. Mail można pisać po polsku, mimo, że autor jest Czechem.  :D

Spox :)
Postaram się wyjaśnić, co po kolei należy zrobić. Tyle tylko, że nie mam doświadczenia w tworzeniu podobnych programów i mogę sugerować rozwiązania niekoniecznie najwłaściwsze.
Jeśli chcesz zrobić to tak, jak napisałeś, czyli najpierw wgrywa się ROBBO, a potem Twój trainer, który modyfikuje właściwą komórkę pamięci (domyślam się, że wzbogaciłeś go o własny ekran, możliwość wyboru gry z trainerem lub bez i może inne dodatki), to rzeczywiście prawdą jest, że należy szukać rozwiązania poprzez wymienione przez Ciebie adresy - wektory. Równie ważne jest jednak i to, żeby Twój trainer nie kolidował w pamięci z samą grą. Upewnij się, czy oby na pewno nie znajdzie się on w tej jego części, która powinna być pozostawiona do dyspozycji samej gry. To nie takie proste, nawet stwierdzenie obszarów do których gra jest wczytywana (po nagłówkach bloków) nie daje gwarancji, że wybrany obszar pamięci nie zostanie przez grę zagospodarowany. Żeby to definitywnie stwierdzić wymagana byłaby szczegółowa analiza kodu. Można też spróbować prostrzej metody, polegającej na podglądnięciu zawartości pamięci podczas samej zabawy grą jakimś freezerem, czy też pod emulatorem wywołując monitor pamięci. Znalezienie obszaru wolnego tym sposobem polegałoby na wyszukaniu wystarczająco długiego ciągu zer, ale i tutaj w wyborze wolnego obszaru pamięci na trainer, należy zachować ostrożność, ponieważ nie każdy taki obszar rzeczywiście jest do "wzięcia". Jednak jest to dość skuteczny sposób, który bym polecał.
Co zrobić, żeby wczytując Robbo, nie spowodować równocześnie jego natychmiastowego uruchoienia? Wystarczy pozbawić plik gry, stanowiący naprzemienny ciąg nagłowków i danych, tego z nich, który odnosi się do komórek pamięci RUNADR. Zwykle, i na pewno jest tak w przypadku gry Robbo, jest to osobny blok (nagłowek plus dane, na które składają się dwa bajty), który umieszczany jest na samym końcu pliku gry. Skada się z 6 bajtów: [e0 02 e1 02 xx yy]; yyxx to adres uruchomienia gry. Te 6 bajtów może być poprzedzone jeszcze dwoma bajtami FF, jeśli tak jest, to prawie na pewno to część nagłówka (równie dobrze mogłoby jej wogóle nie być, program działałby dokładnie tak samo), którą jednak też należy usunąć (zwykle jednak jej tam nie ma).
Po tej czynności łączysz grę z trainerem, (w sumie kolejność łączenia w przypadku takiego rodzaju trainera, nie gra roli, skoro i tak adresy nie kolidują ze sobą) i wstawiasz nagłowek [e0 02 e1 02 xx yy] (też w dowolnem miejscu pliku między blokami, ale ładnie jest umieścić go na samym końcu) z adresem uruchomienia swojego trainera - tam gdzie ma się rozpocząć jego wykonywanie. Sam trainer musi już skoczycz pod adres, który został usunięty w samej grze (blok z RUNADR) instrukcją najlepiej JMP yyxx. I to już chyba cała recepta na to jak ma wygładać prawidłowo działający trainer do gry, mam nadzieję, że choć trochę pomogłem. Powodzenia!

W temacie asma 6502, chciałbym powiedzieć, że bardzo rozsądnym posunięciem byłoby ściągnięcie instrukcji do najpopularniejszego asemblera w Polsce: Quick Assemblera (dostępnej tutaj w formacie PDF). Jest tam zawarty treściwy instruktaż dotyczący działania komputera, mikroprocesora i takiego narzędzia programistycznego jak asembler wogóle. Bardzo ważna pozycja dla każdego pragnącego zgłebić wiedzę dotyczącą programowania 8-bitowego atari od podstaw. Polecam! http://www.t16.ds.pwr.wroc.pl/~jacques/pliki/qa.zip
Warto też odwiedzać stronę elektronicznego archiwum kultowej gazetki Tajemnice Atari. Na zawartych tam lekcjach asemblera słynnego JBW i innych wartościowych artykułach, wychowała się i osiągnęła swoje szczyty cała scena małego atari po roku 1993. To w dużej mierze zasługa właśnie tej gazetki. Link: http://horror.mirage.com.pl/pixel/index.html

Jeśli konstruktorzy zdążą, to może muzyczka do dema mogłaby być już pod sida? :) Ciekawe tylko, czy regulamin konkursu przewiduje taką okoliczność... (to chyba pytanie do Vasca)

blackd0t: w sprawie, która Cię tak nurtuje, mogę jedynie powiedzieć, że osobiście bardzo wątpię w istnienie opisów poświęconych temu, jak wykonać podobne zabiegi z programem: dołączyć intro, znaleźć miejsce w kodzie odpowiedzialne za zmiejszanie liczby "żyć" w grach, itp. Na atari ludzi zajmujących się tym nie było zbyt wielu, dodatkowo było to już naprawdę dawno, bo nowe gry na nasz komputer w zasadzie nie powstawały od, powiedzmy, roku 1994. Zasadniczo też intra do gier pojawiały się bardzo sporadycznie. Hackerzy zwykle łamali zabezpieczenia przed kopiowaniem gry i przeważnie jeszcze podmieniali niektóre napisy pojawiające się na ekranie w miejscach creditsów. To wymagało najmniejszego nakładu sił, a zapotrzebowanie odbiorców na coś więcej raczej nie istniało.
Pytasz, jak to można zrobić. Podstawą jest dobra znajomość asemblera 6502, bo wiadomo, że inaczej nie napiszesz intra, oraz wiedza na temat, jak działa system operacyjny atari w zakresie wczytywania programów. Hackerzy zwykle dążyli do doprowadzenia postaci pliku z łamaną grą do postaci tzw. binarnej - zgodnej z wewnętrznym standardem systemu operacyjnego atari. Umożliwiało to użycie uniwersalnych loaderów wykorzystujących procedury zapisane w romie komputera oraz pozwalało użyć dowolnych programów operujących na takich plikach, jak choćby kopiery, deasemblery, itp. Ogólnie pliki binarne składają się z tzw. nagłówka lub większej ich liczby, oraz danych.  Pierwszy z nich rozpoczyna się dwoma bajtami $FF, co system sprawdza, by upewnić się, że ma do czynienia z właściwym sobie standardem postaci wczytywanego pliku. Następnie nagłówek posiada adres pierwszego i ostatniego bajtu danych/programu, w kolejności młodzy/starszy bajt adresu - razem 4 bajty. Potem mamy dane/program. System zapisuje te dane od miejsca w pamięci odczytanego z nagłówka bloku i tak aż do wyczerpania bajtów w bloku. Potem pojawia się kolejny blok, który może, ale już nie musi, posiadąć tzw. identyfikator (to te dwa bajty po $FF) i dalsze 4 bajty nagłówka określające adres kolejnego bloku danych. Jeśli coś zostanie zapisane do pewnych komórek pamięci: 02e2-02e3, pomiędzy wczytywaniem kolejnych segmentów programu nastąpi wywołanie programu od adresu zapisanego do tych komórkek pamięci. W ten sposób możesz przed wczytaniem bloków gry (lub między nimi) umieścić swój własny z programem.

Witamy Milosz!

Sądzę, że to, że się przedstawiłeś, było całkiem dobrym posunięciem z Twojej strony. Zyskałeś tym sympatię i sądzę, że długo na odpowiedź na swoje pytania czekać nie będziesz potrzebował. Muszę też zauważyć, że aktywność nowych osób na atarowskim forum musi pozytywnie wpłynąć na aktywność i nastawienie "weteranów", często znudzonych i sfrustrowanych brakiem nowych wydarzeń, poziomem zaangażowania i zainteresowania sprawami tutaj poruszanymi. Jak wszystko, tak i dzieje tego forum mają i mieć będą swoje lepsze i gorsze momenty. Obecnie chyba forum przeżywa kryzys i tym większa chwała tym kilku nowym osobom wśród nas, które tą nieprzyjemną sytuację ratują. Wasz entuzjazm jest wstanie udzielić się innym i skłonić ich do działania. Tak trzymać, a będzie lepiej!

Milosz, jeśłi chcesz wykorzystać to, co umiesz w asemblerze 6502, lub inne swoje zdolności, ale właśnie na małym atari, to możesz powiedzieć coś o tym na forum. Co prawda wielu z nas nie jest w zasadzie aktywnymi w tworzeniu na atari, ale nieliczni wciąż mają jakiś zapał do tego i jakieś mgliste plany z tym związane. Chcesz się w to włączyć, masz takie ambicje, marzenia...? To także do innych, którzy szukają wsparcia, motywacji, pomysłów - lub je mają, na jakieś produkcje. Warto się dzielić swoimi pomysłami.

Cieszy mnie bardzo, że w dyskusję w sprawie procesora 65816 włączył się Pasiu. Myślę, że uwagi i problemy przedstawione w treści jego wypowiedzi, pozwalają nam lepiej zdać sobie sprawę z niewątpliwego trudu i ogromu problemów pozostających wciąż do rozwiązania. Jednak nie z każdym stwierdzeniem zawarym w wypowiedzi Pasia, mogę się zgodzić.
Chciałbym poddać w wątpliwość sugestię, że programiści 8-bitowego Atari używali instrukcji nielegalnych procesora 6502. Po raz kolejny jako argumentu przeciwko takiemu przekonaniu, użyję przykładu emulatora Atari z procesorem 65816. Wyraźnie na jego przykładzie widać, że zdecydowana większość programów wykonuje się prawidłowo. Może warto byłoby zapytać poszczególnych koderów, czy rzeczywiście wykorzystywali nielegalne instrukcje przy pisaniu programów. Proponowałbym też sporządzić listę tych spośród programów Atari, które z nich korzystają. Wtedy mielibyśmy w tym wzgłędzie wystarczającą jasność.
System operacyjny dla karty Turbo-816 jest na stronie z emulatorem! Oprócz tego jest tam jeszcze inny rom, rozwinięty przez samego autora emulatora. Niestety, nie wiem, czy romy te są w pełni użyteczne - czy nie zawierają dyskwalifikujących je błędów. Nie wiem też, czy oferują "przekierowanie adresów", o których wspominał Pasiu. Niewątpliwym jednak faktem jest to, że prace nad zaadaptowaniem procesora 65816 do Atari, trwają i, co ważne, są dość zaawansowane. Skąd to mogę wiedzieć? Choćby stąd: http://www.myatari.net/issues/jun2001/8_16.htm. Może więc warto w te działania się jakoś włączyć?

Na temat programowania na Atari wyposażonego w procesor 65816, w bardzo szczegółowy i interesujący sposób, wypowiedział się autor następującego dokumentu: http://cerebro.xu.edu/~ryanr/atari/65816.html. Dokument ten pomoże także tym z nas, którzy chcieliby zapoznać się z działaniem nowych instrukcji procesora i sprawnie przyswoić sobie tą wiedzę. Wydaje mi się, że godny on jest największego zainteresowania.

Ostatnia kwestia. Czy procesor można na pewno zdobyć? Tak. Warunki nabycia układu nie są jednak mi znane. Możemy się chyba raczej spodziewać stosunkowo wysokiej ceny, stąd pomysł zorganizowania się w liczną grupę i próba negocjacji ceny. Producent układu:http://www.westerndesigncenter.com/

Odpowadam w sprawie pytania zawartego w ostatniej odpowiedzi z tego tematu.

Całkiem liczne rzesze osób zainteresowanych sceną małego Atari czerpie swą, pewnie dość ograniczoną wiedzę, z takich chociażby źródeł informacji jak archiwa stron internetowych czy płyty z atarowskim stuffem. Ich zapoznanie się z produkcjami sceny nastąpiło póżno, często więc starsze produkcje znane są gorzej od tych zupełnie nowych. Wydawać by się mogło, że przy tak licznej liczbie źródeł - choćby stron www poświęconych małemu Atari - dostęp do konkretnej produkcji nie powinien nastręczać poważniejszych trudności. Niestety, okazuje się, że wszyscy korzystają z tych samych kopii produkcji, nie dbając specjalnie przy tym, czy są one poprawnie przeniesione na Atari czy nie. To stosunkowo dziwna sytuacja, a Zin Barymag #1 nie jest tego odosobnionym przykładem. Spróbujcie uruchomić emulator Atari z Pantherem w stacji 1 i sprawdźcie, czy przypadkiem wasz emulator, czasem, nie poinformuje Was o zawieszeniu emulowanego Atari. Jaka jest tego przyczyna? Pierwszych 18-cie sektorów jest pustych.

Być może całkiem dobrym pomysłem byloby stworzenie listy produkcji, które w zasobach archiwów stron internetowych pojawiają się jedynie w swoich kalekich, niedziałających wersjach.