1

(402 odpowiedzi, napisanych Fabryka - 8bit)

zdebel napisał/a:

Brak loga obniża opłatę, ale jej nie likwiduje.

Odwrotnie, umieszczenie loga na opakowaniu i materiałach promocyjnych obniża opłatę.

Jest to zależne od szerokości playfielda ustawionej w DMACTL:

1) Dla wąskiego playfielda (128 color clocków) po włączeniu hscrolla linia ma tyle co normalny playfield (160 color clocków).
2) Dla normalnego playfielda (160 color clocków) po włączeniu hscrolla linia ma tyle co szeroki playfield (192 color clocków).
3) Dla szerokiego playfielda (192 color clocków) po włączeniu hscrolla szerokość się nie zmienia.

Dla trybu antic 4 jest to odpowiednio 32, 40 i  48 bajtów.

Tak, biorę to pod uwagę. Z tego co piszesz, wychodziło by że stosuje się opcję nr 1. Jeśli dobrze rozumiem spowoduje to, że Antic będzie pobierał dane sprzed początku ekranu, jeżeli dojedziemy do lewej krawędzi obrazu. Biorąc pod uwagę to, że licznik pamięci ekranu w Anticu zawija się na granicy 4kB musimy umiescic poczatek ekranu nie na granicy 4k, ale nieco dalej (przynajmniej jeden bajt dalej, a jesli chcemy korzystać z wyższych wartości HSCROL, to kilka bajtów). Mam rację?

W momencie, gdy włączam horizontal scroll w display liście, a HSCROL ustawiony jest na 0, dana linia trybu przesunięta jest o 16 color clocków w lewo względem tego co wyświetlane jest gdy horizontal scroll jest wyłączony. Przy każdym zwiększeniu HSCROLa o 1, linia przesuwana jest w prawo o 1 color clock. Przy maksymalnym ustawieniu, czyli HSCROL=15, pierwszy color clock linii jest "za" lewą krawędzią ekranu (linia jest wyświetlana począwszy od drugiego color clocka).

Jak standardowo rozwiązuje się ten problem? Do głowy przychodzą mi 2 rozwiązania:

1) ustawienie LMS na poprzedni bajt i niedopuszczenie wartości HSCROLa, które powodowałyby wyświetlenie danych sprzed początku pamięci ekranu
2) wyłaczenie horizontal scroll w DL

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.

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.

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?

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?

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?

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?