O, widzę, że już pojawił się pan Zenon, tak myślałem że na nim się skończy i zaraz będzie jasne. :)

Ja początkowo robiłem tak: ustawiałem pułapkę w kluczowym miejscu procedury systemu operacyjnego zimnego startu wykrywającej cartridge'a, "informowałem" OS, że linie RD4 i RD5 są w stanie 1, następnie wgrywałem zawartość EPROMA od adresu $8000 do $bfff a potem pozwalałem, żeby procedury same wykryły jakiego to cartridge'a w ten sposób "podłączono". Działałało to bez zarzutu i program się uruchamiał.
Próby z prawdziwym Atari robiłem tak: w do płytki gdzie miałem zaistalowaną pamięć 62256 podłączałem programator WillemProg i programowałem pamięć RAM. Następnie, nie odłączając +5V, przełączałem sygnały z płytki do cartridge'a w miejsce EPROMU, którego jeszcze wtedy nie było na cartridge'u. I działało, pamięć nie ulegała skasowaniu, ale niestety nie mogłem zrobić jednego kluczowego testu - wyłączyć komputera, włączyć i zabootować, bo wtedy pamięć mi się kasowała. Wychodziły tylko próby z podłączeniem do pracującego komputera.
+5V było doprowadzone przez cały czas, a \WE było w stanie 1, czyli nie pozwalałem na zapis do pamięci.
Wlutowałem prawdziwego EPROMA i wtedy okazało się że jest źle, booting się nie udaje, czyli pewnie zrobiłem jakiś drobny błąd.

Odpowiedź na ewentualne pytanie - tak, uwzględniłem fakt, że RAM i EPROM mają nieco inaczej wyprowadzone sygnały.

Tak, można. Kiedyś wykonałem prosty układ z Pokeyem podłączanym do PC-ta i z tego co pamiętam użyłem wtedy oscylatora 6MHz i dzieliłem częstotliwość przez 2. Wyszło 3 MHz i działało.

Turbo Blizzard miał przełącznik Turbo-Normal, który pozwalał na wczytywanie programów w obydwu trybach. Jeżeli przełącznika nie ma, to bez małej przeróbki się to nie uda.

Nie mam teraz pod ręką procedur komunikacyjnych systemu Toms Multi a większość stacji dysków rzeczywiście sygnału SIOAUDIO nie generuje. W najbliższym czasie zamierzam pobawić się trochę Pokeyem podłączonym do PC-ta, gdyż mam w domu jeden egzemplarz nieużywany do tej pory. Może mi się uda dokończyć model HDL tego ukłądu o czym rozmawialiśmy parę dni temu a wtedy będzie można wpisać do Atariki precyzyjne informacje o tym jak rzeczywiście sprawy wyglądają.

Fragment podany przeze mnie na początku dotyczył właśnie sampli i magnetofonu a wtedy sygnał SIOAUDIO pochodzi właśnie z prawej ścieżki taśmy. Sumowanie ma jednak jak najbardziej miejsce przy komunikacji z niektórymi stacjami dysków. Na przykład LDW 2000 generuje pewien sygnał na pin SIOAUDIO, ale np. XF-551 już nie. Pokey nie ma na niego wpływu, po nie wchodzi on do niego.

Sorry, chyba się pomyliłem. Nie jestem pewien czy Prolog był na małe czy duże Atari. Tym nie mniej język polecam.

Ciekawy pomysł - Atari z FORTH-em zamiast BASIC-a... Jednak mimo wszystkich zalet FORTH-a, nie byłoby to najlepsze rozwiązanie ze względu na jego złożoność... Atari BASIC jest jaki jest, ale programować w nim nauczyć się łatwo. Poza tym programy są bardzo czytelne.

Programowanie w FORTu polega na definiowaniu tzw. słów, które wykonują operacje stosowe oraz wywołują istniejące słowa utworzone w FORTHu lub w kodzie maszynowym. W praktyce oznacza to, że zasadnicza część definicji słowa - tzw. sekcja parametrów - składa się głównie z wywołań istniejących już słów. Wykonanie programu będzie zatem polegało na odczytaniu zapisanych adresów w sekcji parametrów i wykonaniu skoków w odpowiednie miejsca w celu wykonania słów, do których wykonywane słowo się odwołuje. Jest to więc proces rekurencyjny.
Dzięki temu właśnie FORTH jest bardzo szybki - kod wykonywany nie jest wprawdzie kodem maszynowym, ale wysoko przetworzonym kodem źródłowym, gotowym do szybkiego wykonania.

Tak naprawdę sposób wykonania słowa zależy od użytego kompilatora - jest to pojęcie FORTH-a i nie należy tego mylić ze zwykłymi kompilatorem. Jeden z najprostszych kompilatorów - dwukropek - działa właśnie tak jak to wyżej opisałem. Istnieją też kompilatory bardziej zaawansowane, pozwalające na definiowanie bardziej skomplikowanych słów.

Zabawa z FORTH-em jest super, pod warunkiem że przejdzie się przez początkowy etap nauki i zrozumie ogólnie jego zasadę działania. Ja używałem kiedyś Extended FIG-FORTHa, który spodobał mi się do tego stopnia, że napisałem 10 lat temu w Turbo Pascalu programik, który dekompilował wszystkie standardowe słowa tego dialektu. I pamiętam, że listing zajmował chyba z 5000 linii, a to wszystko mieściło się w 10 kilobajtach. Dlatego uważam, że forth bardzo oszczędza pamięć.

Ja pisałem kiedyś w Extended fig-FORTH-u korzystając z tego, że była do tego języka książeczka po polsku autorstwa J.Bieleckiego. Chyba największą zaletą tego języka jest wysoka oszczędność pamięci (lepsza niż dla programów w asemblerze), ale wadą jest to, że programy są nieczytelne, gdyż operują na stosie używając odwrotnej notacji polskiej. Dla wielu osób język ten jest przez to dość trudny do nauczenia.

Najciekawsze są takie właśnie rzeczy, bo zgrubnie opisać układ nie jest aż tak strasznie trudno. Mnie najbardziej interesują informacje na temat konkretnych rozwiązań hardware'owych, które zastosowano w tych układach. Tylko że niestety, bez dostępu do bardzo szczegółowej dokumentacji jest ciężko i pozostaje chyba taka metoda jaką widać na zdjęciach tutaj:

http://home.freeuk.com/fpgaarcade/atari_amiga.htm

czyli po jednej sondzie do każdej nóżki układu i dokładna analiza wyników...
Fajnie by było, gdyby kiedyś powstał Atarowski odpowiednik projektu C-ONE (http://c64upgra.de/c-one/)...