Tak właśnie chciałem zrobić. I pewnie tak zrobię. Jeszcze się tylko zastanowię nad tym czy wybrać atari basic czy turbo i zabieram się do roboty.

Gryzie się z punktem 1 (programujemy w Atari Basic, a w tym przypadku byłoby to programowanie w kodzie maszynowym).

Witam,

Post o tym konkursie miałem zainicjować ja, ale niestety w trakcie długiego weekendu byłem w rozjazdach po rodzinie i znajomych i nie stało czasu...

Na początek krótkie wyjaśnienie. Na pomysł zrobienia dema w czystym atari basicu wpadłem ja i to już z jakiś miesiąc temu. Stwierdziłem po prostu, że chciałbym się sprawdzić w tym, w czym nigdy niczego nie napisałem. Od razu uprzedzam. Moje demo w atari basicu na Ornetę powstanie, a wszystkich trolli, jeleni i inną leśną zwierzynę płową mam w głebokim poważaniu.
W Opalenicy o swoim pomyśle powiedziałem Sikorowi i on się jemu bardzo spodobał. Stwierdził, że warto zrobić pod to osobną konkurencję. W sumie rozumiem dlaczego. Jest wiele osób, które chciałoby coś zrobić na atarkę, ale widząc dema z gatunku Reditusa czy Numena, wolą nic nie robić, chociażby dlatego, aby nie narazić się na drwiny z gatunku: a takiego torusa to my ze szwagrem w '45 zrobiliśmy.
Narzekacie, że jest mało dem na atarkę? No bo niewielu coś robi, większość nie umie, reszta nie ma czasu. Basic demo compo przeznaczone byłoby dla tych, co nie potrafią/nie umieją/nie chcą pisać super dem w assemblerze. Chcą po prostu coś stworzyć. Więcej osób programuje w Basicu niż w asmie. Literatury na ten temat jest w bród. Moja idea jest taka: niech każdy kto chce coś napisać na atari robi to. Program w Basicu wcale nie musi kojarzyć się z tandetą (i nie jest to wcale przytyk do różnych produkcji z ostatnich party).

Jeśli chodzi o regulamin to są generalnie 2 pomysły:
1) Czysty basic - muzyka na SOUND i doczytywanie plików za pomocą GET #1,A:POKE 32768+I,A w pętli.
Wady: muzyka w ten sposób robiona będzie niestety bardzo słaaabiutka. Zerowa przyjemność dla uszu. Nieprzyjemność raczej. A co do doczytywania plików w ten sposób, to zwykłe wczytanie obrazka 8KB trwałoby z minutę. Też średnia przyjemność.
Dlatego opowiadamy się za pomysłem:
2) Muzyka w CMC. Dlatego, że player CMC ma od razu na starcie procedurkę odgrywania muzyki przeznaczoną do wywoływania z basic-a. Dlatego programista basicowy korzystając z tego playera nie musi znać ani jednego rozkazu w asmie. A takie było założenie tego konkursu.
Doczytywanie plików: też odpowiednia procedurka, ale krótka: A=USR(ADR("napis")), gdzie napis to: małe h, cudzysłów w negatywie, znak trefla, duże L, duże V, małe d w negatywie. Czyli na ludzkie: PLA, LDX #16, JMP E456. Blok danych IOCB przygotowywało by się już z basica.

A zatem ogólny regulamin (proszę poprawić jak coś jest nie tak):
1) Konkurs jest przeznaczony dla programistów w języku Atari Basicu znajdującym się w oryginalnym ROMie każdego Atari, programowanie w innych językach zabronione.
2) Program nie może zmieniać: stosu, obszaru DOS-u, obszaru programu w Basicu oraz obszaru od $a000 (poza rejestrami sprzętowymi)
3) Jedyne programy maszynowe, które program może wywoływać to player CMC (oryginalny z CMC lub poprawiony przeze mnie) oraz procedurkę wywołania CIO przedstawioną powyżej.
4) Cały program może się składać z kilku mniejszych programów uruchamiających się kolejno za pomocą RUN "D:PROG2.BAS". W takim jednak przypadku, trzeba wyraźnie określić, który plik trzeba uruchamiać jako pierwszy nazywając go START.BAS albo RUN.BAS albo nazwą dema.
5) Wczytywanie plików należy robić bez podawania numeru stacji, tak aby można było wszystkie pliki skopiować do jednego katalogu i uruchamiać stamtąd.
6) Zabroniona jest jakakolwiek modyfikacja plików programu. W szczególności taka, która prowadzi do niemożności wylistowania tekstu programu. Jest to bowiem konieczne do sprawdzenia zgodności z regulaminem.
7) Program musi się odpalić pod dowolnym DOS-em o memlo nie więcej niż $2000 oraz na oryginalnym Atari (jeden POKEY, RAM nie więcej niż 128KB).

Jakieś inne pomysły?

Tę uwagę odrzucamy jako niezorganizowaną.

W TMC 2.0 jest już jedna tablica od świętego. Miałabyż być i druga?

Nie tylko ten problem. Generalnie nie masz ograniczeń co do tworzenia programu. Możesz dowolnie umieszczać tablice, wskaźniki itp.

Player CMC z 2019 bajtów rozrósł się do 3503 (wliczając kod relokatora) :)

Nie widzę powodu aby miałby się wykładać. Nigdzie nie zakładam, że rozkazy następują w określonej kolejności. Właściwie nigdzie nie zakładam, że jakiekolwiek rozkazy występują :)
Tablica fixupów jest generowana na podstawie wzorca skompilowanego pod $8000 oraz 256 próbek testowych skompilowanych pod adresy od $4000 do $40ff.

A gdyby było do wyboru tylko starszy bajt adresu lub nie adres to można się bez kompilatora obyć?
Innymi słowy:
Pokaż mi jaka jest twoja metoda relokacji, która działa przy przesunięciach o x*256 bajtów a nie działa przy innych.

Tobie chodzi chyba nie o ładowanie do granicy strony, a o relokację o wielokrotność 256 bajtów.
A jak generujesz tablicę fixupów?
No i dlaczego nie może ona obejmować zarówno starszych jak i młodszych bajtów adresów?
A w ogóle to ja proponuję zrobić relokator na podstawie źródeł QA. Ładujemy plik .asm i go assemblujemy od MEMLO.

Kurcze pieczone, kolejny po chińsku gada.

Po pierwsze, to lda $ff,x da tryb zerostronicowy i nic ze stosu nie przeczytasz.
Wymuszenie trybu długiego też nie jest w pełni poprawne, bo stos mógł się nam "zawinąć".
A najbardziej prawidłowo jest zapewne:
dex
lda $100,x
...
inx
lda $100,x
Po drugie, to przesunięcie może być większe od 255.
No i szybkość i czytelność tego rozwiązania jest dyskusyjna (lekko mówiąc).

Metoda użyta przez gości z Avalonu jest całkiem sensowna, bo zamiast stosowania takich karkołomnych sztuczek wystarczy pisać:
lda dane_addr
sta vec
lda dane_addr+1
sta vec+1

bądź:
mwa dane_addr vec
:D

Oczywiście to nie wystarczy aby program po zrelokowaniu dobrze działał. Musi być napisany tak, aby nigdzie nie zakładał, że np. jakaś tablica zaczyna się od początku strony. Trzeba też uważać na program Antica. No i pamięci ekranu w trybie graficznym praktycznie nie można relokować (chyba, że z wyrównaniem do 4KB). Ciekawe też rzeczy będą się działy jeśli program załadowany pod $8000 zrelokuje się pod $4000 i zacznie korzystać z banków. A jeśli stosujemy zmiany kolorów w linii za pomocą cyklowania, to też trzeba uważać, bo rozkazy skoku warunkowego i ładowanie indeksowe mogą się nagle wydłużyć o 1 cykl :)