1

Od pewnego czasu przechodzę powtórną fascynację Atari (poprzednia była za dzieciaka), wgłębiam się w architekturę, oficjalne i nieoficjalne dokumentacje... Parę tygodni już czytam i postanowiłem wreszcie poeksperymentować pod emulatorem w oczekiwaniu na kabel do telewizora.

Ponieważ w dzieciństwie nie miałem stacji dyskietek (była za droga), spędziłem setki godzin na wgrywaniu gier i programów z kaset. Dzisiaj chciałbym powrócić do tego tematu, ale już od strony programistycznej :)

Ale do rzeczy. Sprawa tyczy się Atari 800 XL. Jak podaje Atari Technical Reference Notes, proces bootowania z kasety wygląda następująco:

- czytany jest pierwszy rekord (128 B) z kasety; pierwsze 6 bajtów to nagłówek
- z nagłówka wydobywane są informacje: bajt 0 jest ignorowany, bajt 1 powinien zawierać liczbę rekordów, bajty 2 i 3 adres, pod który skopiowany będzie program, a bajty 4 i 5 adres procedury inicjalizacyjnej programu
- czytane są pozostałe rekordy
- jsr do początku programu + 6 (tu powinna znaleźć się procedura, która ustawi carry clear w przypadku braku błędu i zrobi rts)
- jsr do procedury inicjalizacyjnej (tej wskazanej w nagłówku)
- jsr poprzez wektor zawarty w DOSVEC, aby przekazać kontrolę naszemu programowi

W oparciu o ten opis napisałem program:

    opt h-
    org $2000

cassette
    dta 0    ;ignorowany
    dta [end-cassette+127]/128    ;liczba rekordow
    dta a($2000)    ;adres, pod ktory program bedzie skopiowany
    dta a(init)    ;adres inicjalizacji

_boot
    clc    ;powiedzmy monitorowy, ze nie bylo bledu
    rts    ;powrot do monitora
    
init
    ;wylacz silniczek magnetofonu
    lda #$3C
    sta PACTL

    mwa #start DOSVEC    ;ustaw DOSVEC na poczatek naszego programu
    
    rts    ;powrot do monitora
    
start
    //... (poczatek wlasciwego programu)
    //...

end = *

I w zasadzie to działa, ale... po tym jak wykona się rts w procedurze init, atari odgrywa swoją "pieśń startową" czyli słynne "trrrr", która trwa ok. 5 sekund, po czym dopiero następuje skok do mojego programu przez wektor spod DOSVEC. Jeżeli usunę tę instrukcję (rts), to program uruchamia się od razu.

Z tego co pamiętam większość gier i programów wgrywało się z kasety w ten sposób, że nie było przejścia przez fazę "trrrr", tylko gra/program uruchamiał się od razu po wczytaniu. I tu pojawia się pytanie: co się tak naprawdę dzieje podczas "trrrr" i po co w ogóle jest ten dźwięk? Czy mogę bezpiecznie pominąć powrót do monitora, odzyskać bajty ze stosu resetując wskaźnik stosu i przejść do programu od razu?

2 Ostatnio edytowany przez mono (2016-10-15 23:26:26)

http://atariki.krap.pl/index.php/Progra … y_na_RESET
Szczegółowo opisane są niuanse związane z BOOT-em.

Edit: Pokrótce:
1. bootblock+6 to kod inicjalizacji programu - tutaj inicjalizuje się pamięć, rozpakowuje kod, generalnie robi rzeczy przygotowawcze które powinny się wykonać tylko raz, a nie są potrzebne np po resecie.
2. bootblock+4 to adres pod którym rozpoczyna się program - tutaj OS skacze również po RESET bo tej wektor przepisywany jest do CASINI/DOSINI.
Zawyczaj gry używają właśnie tego wektora do wejścia w główny kod programu.

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

3

No dobra, czyli jeśli wierzyć artykułowi z linka, można pominąć rts z inita. Ale nadal nie wiem co robi OS podczas tych 4-5 sekund (oprócz generowania tego dźwięku) i czemu trwa to tak długo?

4

To robi: http://atariki.krap.pl/index.php/ACX

KMK
? HEX$(6670358)

5 Ostatnio edytowany przez mono (2016-10-16 16:13:51)

Jeśli pominiesz RTS z inita, to nie zakończy się procedura RESET (WARMST=1, DOSINI nieustawione), poza tym będziesz musiał wyłączyć silnik magnetofonu sam. To nie jest dobra praktyka, choć oczywiście będzie działać.

Edit: ACX ładuje sterowniki bezpośrednio z urządzeń podłączonych do Atari. Relokowalne sterowniki, które będą się ładować na MEMLO. Stąd gry które ładują się do pamięci samodzielnie zazwyczaj uruchamiają się na DOSINI/CASINI żeby przypadkiem coś nie nadpisało im kodu.

Edit 2: Nie zwróciłem uwagi że mówisz o procedurze init z Twojego kodu - tak można go pominąć i wszystko będzie jak należy :)

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

6

OK, dzięki za pomoc. Przez wasze odpowiedzi wczoraj kolejne kilka(naście) godzin przesiedziałem na grzebaniu w różnych dokumentach... Ostatecznie opis ładowania handlerów z "nowych" urządzeń peryferyjnych znalazłem tu: http://www.atarimania.com/documents/1200XL_addendum.pdf

Niestety lektura tego dokumentu odpowiedziała na jedno pytanie, ale postawiła kilka kolejnych :D Np. na stronie 21 mamy informację o pollingu urządzeń peryferyjnych "starego" typu. Jest tam wspomniany polling typu 0, 1, oraz 2. W Mapping The Atari (http://www.atariarchives.org/mapping/appendix12.php pod opisem DVSTAT) jest napisane, że dokładniejsze informacje na ten temat są w 400/800 hardware manual. Niestety jakoś nic tam o tym nie znalazłem :( Wiecie coś na ten temat?

7

Wiemy http://atariki.krap.pl/index.php/Lista_ … _specjalne

KMK
? HEX$(6670358)

8

Dzięki! Ciekawy jestem czy informacje na temat TYPE 2 POLL autor tego artykułu wydobył metodą inżynierii wstecznej, czy opierał się na jakimś dokumencie.

Przy okazji, wypiszę tutaj listę źródeł, które mi się przydały gdy rozkminiałem niuanse związane z bootem atari (w razie gdyby jakiś nowicjusz taki jak ja znalazł ten wątek przez google):

  • siospecs.pdf

  • sweet16

  • de re atari

  • atari roots

  • altirra hardware reference manual

  • CO16555 - Atari Home Computer Technical Reference Notes

  • Mapping The Atari - Revised Edition

  • Atari XL Addendum - Atari Home Computer System - Operating System Manual - Supplement to ATARI 400/800 Technical Reference Notes

Ciekawa rzecz - Sweet 16 Supplement 3 (Handler Loader)  odwołuje się do "Atari Home Computer System Serial Input/Output Interface User's Handbook Part II" przy opisie pollingu typu 0,1 i 2. Niestety znalazłem tylko Part 1 tego dokumentu (siospecs.pdf). Ma ktoś dostęp do Part 2?

9

To już pytanie do Curta Vendela z Atari Museum i jego graciarni pełnej niezeskanowanych materiałów prosto od inżynierów Atari. Zapowiadał udostępnienie skanów co najmniej 7 lat temu (jak nie więcej), ale zawsze wymigiwał się różnymi wymówkami (brak czasu, stan zdrowia, rodzina itp.).

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

Terry Pratchett - Równoumagicznienie

10

frost napisał/a:

Dzięki! Ciekawy jestem czy informacje na temat TYPE 2 POLL autor tego artykułu wydobył metodą inżynierii wstecznej, czy opierał się na jakimś dokumencie.

Na pewno przytoczona nazwa "TYPE 2 POLL" świadczy o zastosowaniu czystej inżynierii wstecznej. Jest niewyobrażalne, żeby ją zaczerpnięto z jakiejś dokumentacji.

Jeśli widzisz sprzeczności pomiędzy materiałem Atariki a dokumentacją Atari, nie krępuj się i je wskaż. Na pewno zostanie to wzięte pod uwagę.

KMK
? HEX$(6670358)

11

Nie do końca rozumiem Twój sarkazm. Moje pytanie jest podyktowane ciekawością - jeżeli dane zawarte w tabelce są oparte na jakimś dokumencie, to z chęcią go przeczytam. Nie chodzi o samą nazwę, tylko o opisany mechanizm.

12

A ja nie do końca rozumiem, skąd można było powziąć przypuszczenie, że tekst jest oparty na inżynierii wstecznej, skoro zawiera informacje (typu nazw komend), których metodą inżynierii wstecznej zdobyć się nie da.

Info do Atariki zostało wpisane lata temu - konkretnie, ponad 8 lat temu. I owszem, przeważnie to ja to wszystko napisałem, ale nie pamiętam (wybacz, 8 lat), na podstawie jakich źródeł. Dlatego, jeśli widzisz nieścisłości, proszę, byś je wyliczył, zamiast bić pianę.

KMK
? HEX$(6670358)

13

Ale moje przypuszczenie nie dotyczy przecież samej nazwy komendy, tylko opisanego mechanizmu. Często jest tak, że dokumentacja nie wnika w szczegóły, które potem są odkrywane metodą prób i błędów, pomiarów, analizy zdisasemblowanego kodu, itp.

Nie wiem, czemu oskarżasz mnie o bicie piany, wydaje mi się, że mogłeś błędnie odebrać moje słowa jako atak. Może przyczynił się też do tego mój nieoptymalny dobór słów. Zaręczam, że wszystkie moje pytania były podyktowane tylko i wyłącznie inżynierską ciekawością i fascynacją 8-bitowymi komputerami. Po prostu lubię czytać oryginalną dokumentację, nie ma w tym żadnego ukrytego zarzutu.

14

Dobrze, zastanowiłem się też chwilę nad tą dyskusją i doszedłem do wniosku, że dobór sformułowań z mojej strony nie był fortunny. Jeśli poczułeś się urażony, to przepraszam.

Z dokumentacją jest ten problem, że - o ile się w tym orientuję - nie dysponujemy żadną ostateczną wersją, a raczej dokumentacją z różnych stadiów rozwoju tej koncepcji, stąd zdarza się, że poszczególne dataszity sobie czasami przeczą. Tekst w Atariki jest raczej syntezą wszystkich dostępnych danych (w tym analizy kodu XL OS-u) niż bazuje na jakimś konkretnym dokumencie.

Jak mówię, jeśli znajdują się w nim nieścisłości, nie krępuj się z ich wskazaniem. Ewentualna dokumentacja z wymienionych powyżej względów nie jest tu ostateczną instancją.

KMK
? HEX$(6670358)

15

frost napisał/a:

I w zasadzie to działa, ale... po tym jak wykona się rts w procedurze init, atari odgrywa swoją "pieśń startową" czyli słynne "trrrr", która trwa ok. 5 sekund, po czym dopiero następuje skok do mojego programu przez wektor spod DOSVEC. Jeżeli usunę tę instrukcję (rts), to program uruchamia się od razu.
Z tego co pamiętam większość gier i programów wgrywało się z kasety w ten sposób, że nie było przejścia przez fazę "trrrr", tylko gra/program uruchamiał się od razu po wczytaniu. I tu pojawia się pytanie: co się tak naprawdę dzieje podczas "trrrr" i po co w ogóle jest ten dźwięk? Czy mogę bezpiecznie pominąć powrót do monitora, odzyskać bajty ze stosu resetując wskaźnik stosu i przejść do programu od razu?

To komputer próbuje bootowanie z dyskietky.