Mazi, a może nie masz, za przeproszeniem, czopków :)

UPS. Sorki, pomyłka.

@Adam. Nie da rady. Oba projekty są kompletnie różne technicznie, oraz mają trochę inną filozofię.
Kompatybilność odpada tym bardziej. Weronika ma procesor zgodny z 6502, ktory można pewnie dowolnie oprogramować, a Tomek jest na PIC'u i oddaje programiście Atari zestaw gotowych rozkazów (takie API).

Są dla siebie oczywiście pewną konkurencją, ale to nic złego w naszym atarowskim "rynku". Od przybytku głowa nie boli. Każde rozwiązanie ma swoje plusy i minusy.

PS. Teraz chociaż rozumiem, czemu Konop kilkukrotnie, uprzejmie odmawiał, kiedy próbowałem go namówić do bliższego zainteresowania się Tomkiem :)

Wow! Rewelacja. A byłem przekonany, że projekt padł.
Pięknie wykonane.
A do czego to dziwne złącze w lewym górnym?

qba - Czy masz na myśli, że miałbym napisać sobie jakiś rodzaj języka i pisać w nim program w RAM? :)

@mono - nie może. Przecież to by rozwiązało mój problem :)
Nawet organizacja pamięci jest inna i kłopotliwa: w pamięci RAM adres parzysty to słowo (16-bit), a w pamięci programu adres to 24 bity.

Można jedynie podmapować część pamięci programu (paczkę 32KB) do obszaru widzianego jako RAM, w celu odczytania danych tam przechowywanych.
Ale nie można w żaden sposób odpalić kodu z RAM'u.

Czyli automodyfikacje odpadają i to był mój problem.
Budowa rozwiązania pośredniego trwa.

Myślałem, że rozmawiamy o regulaminie compo Forti.

Przeciez xB to znacznie upraszczając po prostu loader. A przy okazji przykład świetnej koderskiej roboty, o ile potrafię to ocenić przy moim marnych umiejętnościach.
Każdy może sobie napisać swój dowolny loader, co było chyba bardzo popularne przy całodyskach. Mając swój loader ma się w poważaniu dosy, OS itd. prawda? 
Nie wyobrażam sobie możliwości, że przyniosę na compo dyskietkę (fizyczną bądź ATR), którą należy tylko wsadzić w stanardową stację podłączoną pod SIO (bądź emulator tejże) i moja praca nie zostanie dopuszczona bo nie odpala się z jakiegoś egzotycznego HDD podłączonego do Atari pod jeszcze bardziej egzotyczne złącza :P

PS. Zresztą ciekaw jestem jak to umieścisz w regulaminie? Jeśli napiszesz wprost, że "nie można wystawiać prac korzystających z xB" to będzie to jawna i bezsensowna dyskryminacja i np. ja, choć xB nie używam, takie compo zbojkotuję i będę namawiał do bojkotu innych. W imię zasad.

Bo z tego co zrozumiałem z 600-postowej dyskusji, to w tym, że demo na SV nie poszło nie było żadnej winy xB. Po prostu autor dema użył dziwnego formatu dyskietki (co uniemożliwiło jej standardowe kopiowanie) i spartolił obsługę błędów ładowania. Czyż nie?
Jeśli tak, to Twoja chęć nieuznawania xB na compotach to nawet nie jest walka z tym konkretnym rozwiązaniem, ale chęć dowalenia personalnie XXL'owi. A na to zgody być nie może.

Kuba, przeceniasz mnie ;) Faktycznie nie pomyślałem o makrach, bo na Atari praktycznie nigdy ich nie używam (tak samo jak prawie żadnych pseudorozkazów - lubię widzieć czysty i cały kod).
Pomysł słuszny i dobry.

Właściwie już wiem jak to zrobię: cudów nie ma, pójdę na kompromis. Najczęściej używane opcje będą wydzielone do osobnych wersji procedur, żeby działaly najwydajniej. Makra pomogą utrzymać spójność kodu. Będzie tego kilka wersji.
Reszta opcji będzie w zbiorczej, wolniejszej procedurze z warunkami, operującej na buforze linii.

Dzięki za pomoc.

To nie tak. Kilkukrotnie wydłużyłby się czas wykonania, jeśli stworzyłbym jedną uniwersalną procedurę, a warnunki wstawił w sam środek pętli kopiującej. Tak jest najwygodniej, ale i najmniej wydajnie.

Zrobienie warunków poza pętlami i przekierowywanie do jednej z np. 60 procedur jest wydajne, ale poza rozwleczeniem kodu, mocno kłopotliwe. Co jeśli znajdę błąd? Będę go musiał poprawiać we wszystkich procedurach. Co jeśli zmienię format obiektów?
Taki kod jest cholernie klopotliwy w "utrzymaniu". I nieelegancki :P

Polacy jak co roku, w ten świąteczny czas z radością zapominają urazy i wybaczają sobie dawne krzywdy, aby wspólnie cieszyć się i bawić :D

@tebe - ale nie o to chodzi. Ja wiem jak zrobić te wszystkie operacje w asemblerze PIC'a. Bardziej lub mniej optymalnie. Chodzi mi tylko o to co opisałem: że albo postawię na wydajność a wtedy będę miał 64 prawie identyczne procedury, trudne w serwisowaniu, albo zunifikuję wszystko kosztem wydajności.

A propos tego co napisałeś o odbiciach, to spróbuj takie pomysły zastosować w asm Atari :) Ja w PIC'u też piszę w asemblerze więc sam rozumiesz...

Co do mojego podstawowego problemu to właśnie testuję sposób, który może być złotym środkiem: bufor linii, to którego najpierw przepisuję linię obiektu robiąc w locie odpowiednie operacje (inwersja, odbicie poziome, przesunięcie bitowe), a następnie tę linię nakładam na ekran w odpowiednim trybie (XOR, OR, AND). Specyfika asemblera PIC'a jest taka, że może się to okazać optymalnym i dość uniwersalnym rozwiązaniem. Uniwersalny bufor linii się przyda, gdybym chciał w przyszłości dopisać kolejne operacje, jak np skalowanie poziome obiektu.
Zobaczymy jak to wyjdzie wydajnościowo.
Mam tylko wrażenie, że wynajduję od nowa blitter ;) a przecież ktoś już kiedyś musiał stanąć przed identycznymi problemami.

Wczoraj robiłem testy nowych procedur rysujących (maksymalnie szybkich, bez obcinania obiektów na brzegach, bez odbić, inwersji itp.) dla 4-kolorowego duszka.
W czasie kiedy antic nie rysuje obrazu udało mi się narysować 120 duszków o wymiarach 8 bajtów x 16 linii, w trybie z maską niezależną od kolorów (dokładnie jest to operacja: (maska AND obiekt) OR (INV(maska) AND tło)  ). Przy czym połowę czasu zajęło Atari na samo wysyłanie rozkazów rysowania do PIC'a.
Śmiesznie to wyglądało na ekranie :)