76

Flashowalny będzie oraz pewnie xxl szykuje jeszcze jakąś niespodziankę czy inne dodatki.
Będzie fajnie.

77

IMHO ilość osób które kupią karta "Doom na Atari" zapewne będzie większa, niż tych którzy zainstalują VBXE i wgrają odpowiedni rdzeń. W przypadku karta klientem może być ktoś kto grę kupi na Allegro, wyciągnie Atari z szafy i sobie zagra -  a takich jest sporo. Do VBXE trzeba już prawdziwego (świadomego) atarowca...
Ale fakt, że ilość ludzi którzy są obydwa te rozwiązania oprogramować jest tak samo znikoma - Nie wiem jak z tym sobie poradzi nosty. Może trzeba do tematu podejść komercyjnie? Zwłaszcza, że i tak takiej gry nie da się wystawić w formie pliku do ściągnięcia. No cóż, pozostaje tylko trzymać kciuki  :-)

78

Czekam na MortalKombat :)

79 Ostatnio edytowany przez cougar (2012-09-04 12:20:41)

nie trzeba robic sidcarta na sterydach,nie musi być nawet flashowalny (gra nie musi być nawet bootowana z epromu) - moze byc dysk, sio2SD, siec.... cokolwiek...zaraz ludziom puszczają wodze fantazji i chcieliby tam upchnąć drugiego pokeya albo inne cudo, to musi być tanie, proste, dobrze opisane API, otwarty firmware to wystarczy. Moze być darmowy w wersji z drogą grą(eprom) dla tych którzy chcą wypróbować swoje chęci w tworzeniu dedykowanego oprogramowania jak i drogi w wersji developerskiej flash po to by tam wgrywać sobie cokolwiek i by działało to jako sidcart gdyby projekt okazał się jedynie gwiazdą sezonu 2012, patenty na popularyzację są o wiele większe niż VBXE bo samo rozwiązanie jest efektowne, przyjemne proste i co najważniejsze TANIE!, jedynym warunkiem jakie musi stanowić jest jeden prosty spójny standard o otwartej architekturze, reszta sama będzie się robić.

Kiedyś ktoś w Atari wpadł na pomysł by napisać grę obsługiwaną przez pistolet, zaraz drugi dodał: to zróbmy konsole i tak powstało XEGS. Skończyło się na tym, że o grze i pistolecie wszyscy zapomnieli a XEGS dalej pozostał tym samym czym był 10 lat wczesniej. Warto przemyśleć dobrze zanim prace nad kontynuacją projektu pójdą w złym kierunku.

80 Ostatnio edytowany przez xxl (2012-09-04 12:48:29)

> Może trzeba do tematu podejść komercyjnie?

hehe. wiesz kto ma prawa do asteroida ? :D nie ma mowy o tym zeby sprzedawac asteroida na atari :-)

mam dwa hardcorowe pomysl, na goraco :D

1. wierna kopia (bardzo wierna) asteroida: na karcie nie bedzie plikow gry. pierwsze uruchomienie carta pojawi sie menu w menu wybierasz ktore pliki przeniesc do pamieci carta (wsadzisz dyskietke z plikami asteroida z M.A.M.E) - obslugiwane sio2pc, sio2sd, stacje dyskow SIO, atari zapisze pliki w karcie i od teraz masz juz zaprogramowanego karta z gra asteroids:)
http://www.youtube.com/watch?v=vi5S1aYio_U

2. rozbudowana wersja, podchodzaca juz bardziej pod stardusta oczywiscie nie zmieniajac ewentualnie tylko podrasowac silniczek oryginalnego asteroida. dostaniemy cos mniej wiecej takiego:
http://atari.pl/video-asteroids-nosty.mp4
ale wtedy mozna to juz normalnie rozprowadzac.

mam nadzieje Nosty nie obrazi sie o udostepnienie jego filmiku :-)

http://atari.pl/hsc/ad.php?i=1.

81 Ostatnio edytowany przez syscall (2012-09-04 17:44:10)

Nie rozumiem porownan z vbxe. Przeciez te urzadzenia (vbxe vs tomek) maja zupelnie inny target.

Ja to widze jako fajny model biznesowy ;) Gry trzeba bedzie kupowac :)

Ogolnie to jestem przeciwny robieniu z tego 'general purpose' programowalnego akceleratora dla end usera.
Bo zaraz powstanie milion wersji - kazda niekompatybilna ze soba :) albo czesto sie zmieniajace api.

Rozwazajmy tylko dwie wersje -> platforma do gier (developer dostaje karta, api, ewentualnie sam pisze wsad, i robi gierke. zamyka 'programowalnosc' wydaje gierke, finito. 1 cart - 1 game.
Druga opcja -> koprocesor + FFT/LINEAR dla demokoderow. Jedno udokumentowane API. jeden wsad. standard :)
Czyli gry na swoich kartach, i jeden SLUSZNY kart dla demokoderow.

No i pozdro :)

"Was powinny uzbrojone służby wyciągać z domów do punktów szczepień, a potem zamykać do pi* za rozpowszechnianie zagrożenia epidemicznego" - Epi 2021
"Powinno się pałować tylko tych co tego nie rozumieją. No i nie szmatki i nie chirurgiczne tylko min FFP3, to by miało jakiś sens. U mnie we firmie, to jak przychodzi bezmaskowiec, to stoi w deszczu przed firmą" - Pin 2021

82

conrad napisał/a:

Wg mnie najważniejsze by się pojawiło - z grą/grami które wykorzystają możliwości karta. A opcja uniwersalności nich toczy się obok jako dodatkowy bonus z którego - w przyszłości - może się coś urodzi.

Mniejszy ból w czasie porodu wystąpi, jeśli będzie można było normalnie programować to z poziomu Atari ;)-

Kontakt: pin@usdk.pl

83

ja jebie, starfoxa z nesa przeportujecie! szacun!

84 Ostatnio edytowany przez mono (2012-09-04 14:17:07)

Efekt porażający! Nosty - gdyby była wersja z możliwością flashowania romu tego microchipa, to byłoby świetnie - gry mógłbyś puszczać jak dotąd z dodatkowym wkładem dla pica tak, jak to jest w przypadku vbxe :)
Jeśli dobrze zrozumiałem, to urządzenie działa tak, że sekwencyjne odczyty z tych samych rejestrów (np. $d500) powodują otrzymywanie kolejnych danych (kolejne bajty wyniku w załączonym przez Ciebie przykładzie na mnożenie, lub też zawartość kolejnych linii ekranowych kiedy antic adresuje urządzenie). Czy Twoje rozwiązanie będzie poprawnie działać z trybem adresowania (zpg,x) ?

Edit: BTW ponieważ mnożenie (jak i dodawanie) jest przemienne, to nie ma czegoś takiego, jak mnożna i mnożnik, a są wyłącznie czynniki mnożenia (analogicznie dodajna, dodajnik - składniki).

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

85

mono: a niby jak by mial to wykryc? z jego p. widzenia beda to 2 odczyty/zapisy, widz do 2 kolejnych komorek ramu, bo na bank przy kazdej operacji inkrementuje wskaznik internal ramu.
ale rownie na bank mozna dopisac wersje, zmieniajaca to zachowanie po wydaniu jakiejs komendy, by inkrementowalo co drugi zapis.

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

86

.. z analizy tematu (dzięki Draco) wynika, że "samodzielna" wersja TOMKA-8 nie będzie miała żadnego problemu z praktycznie dowolną wersją Sparta DOS X, jeśli TOMEK-8 będzie korzystał z połowy strony $D5 i jeśli będzie miał przełącznik wyboru, czy używać górnej, czy dolnej połówki. Jedynym wyjątkiem jest TurboFrezzer 2005, który zajmuje po części jedną połówkę i jeden bajt z drugiej ;)- Na to jednak raczej nic się nie poradzi.

czyli gitara :)

oto dokładniejsze dane:

* side $d5e0
* siccart $d500
* ultimate $d5e0
* sdx256 $d5c0
* tf2005 $d540 - $d580
* atarimax $d500 - $d580

... pomijając fakt, że nie wszystko jest przelotowe. Są jednak przypadki (miałem takiego wynalazka), który miał dwa złącza carta :) - po prostu jedno dolutowałem sobie sam, bo brakowało :D

Kontakt: pin@usdk.pl

87 Ostatnio edytowany przez xxl (2012-09-04 20:50:23)

i tylko dlatego ze rejestry sparty sa gdziebadz na stronie d5 trzeba dorabiac elektronike bo nie mozna po bozemu zarezerwowac stale adresy a dodatkowo po stronie oprogramowania robic sprawdzanie gdzie znajduja sie obecnie rejestry karta :-) oczywiscie gdy program na karcie zapisany jest na epromie i podpiety od 8000 lub a000 to nie mozna uzyc samomodyfikacji kodu tylko albo umiescic ten rejstr na stronie zero albo przekopiowac program do ram ... hehe, programu antica tez by nie mozna bylo umiescic w romie... ziew... obliczac mozliwe do uzycia znaki w pamieci atrybutow w przypadku 256 zestawow, ziew... :D ogolnie  konfigurowac caly podsystem komunikcacji z kartem

mnie omina te "udogodnienia"

http://atari.pl/hsc/ad.php?i=1.

88

.. a cała "elektronika", to prawdopodobnie jeden słicz i kawałek drutu. Gratulacje :)

... to jest dla opcji NIEZINTEGROWANEJ z grą na carcie, jeśli będzie to np. gra i tomek8 w jednym, to żadne ograniczenia praktycznie nie istnieją. Tam będziesz sobie mógł zrobić wszystko, a komputera użyć jako czystej kartki papieru wywalając wszystkie Twoim zdaniem zbędne unowocześnienia zaprojektowane przez konstruktorów firmy Atari :P. "Samodzielna" wersja najpewniej posłuży w celach użytkowych, czyli może być skierowana przede wszystkim do użytkowników dos'a. Można użyć tego jako playera do muzyczek, zpaczować OS i np. pakiet FP, itd. ite sre. Nikt Cię przecież nie zmusza do operowania na wersji, która być może powstanie w dalszej kolejności. Nieprawdaż?

Marudzisz XXL ;)-

Kontakt: pin@usdk.pl

89

> wywalając wszystkie Twoim zdaniem zbędne unowocześnienia zaprojektowane przez konstruktorów firmy Atari

a jakie to unowoczesnienia konstruktorow firmy atari ?

> Można użyć tego jako playera do muzyczek, zpaczować OS i np. pakiet FP, itd. ite sre

albo generator kodu dla 6502... zastosowan jest wiele wiem ;-)
nie bardzo chce mi sie teraz wstac i sprawdzic ale po co wymieniles karty ze sparta, ktore sa nieprzelotowe? przeciez i tak trzeba je bedzie usunac

http://atari.pl/hsc/ad.php?i=1.

90

mono napisał/a:

Jeśli dobrze zrozumiałem, to urządzenie działa tak, że sekwencyjne odczyty z tych samych rejestrów (np. $d500) powodują otrzymywanie kolejnych danych (kolejne bajty wyniku w załączonym przez Ciebie przykładzie na mnożenie, lub też zawartość kolejnych linii ekranowych kiedy antic adresuje urządzenie).

Dokladnie tak! Brak dekodowania adresow wymusza dyscyplinę u programisty Atari. Musi on trzymac sie protokołów
komunikacji. Nie moze nastapic zaden przypadkowy odczyt ze strony $D5xx bo urzadzenia sie rozsynchronizują.
Ale to sie sprawdza. Te animacje z dema zostawilem kiedys wlaczoną na całą noc i rano w dalszym ciagu działała.

Co do wykorzystania rozkazow, ktore wykonuja np dwa odczyty to tak jak napisal Jell sam cartridge nie ma jak sie tego domyslec. Musialbys miec frimeware ktory "wie", o tym ze uzyjesz takich rozkazow.

91 Ostatnio edytowany przez Pin (2012-09-04 22:21:50)

xxl napisał/a:

a jakie to unowoczesnienia konstruktorow firmy atari ?

Mowa o tym, jak traktujesz pamięć komputera Atari - głównie jak czystą kartkę papieru olewając większość oferowaną przez system i nadmieniam też, że w przypadku carta zawierającego wszystko, czyli dopałkę i grę w jednym możesz robić co chcesz i żaden baran taki jak ja nie będzie Ci niczego wytykał ;)- :D - kupi po prostu karta i będzie grał :)

xxl napisał/a:

nie bardzo chce mi sie teraz wstac i sprawdzic ale po co wymieniles karty ze sparta, ktore sa nieprzelotowe? przeciez i tak trzeba je bedzie usunac

Masz rację - celowo wymieniłem i takie. Wszystko ma na celu zapewnienie kompatybilności w różne strony, bo jestem zwolennikiem standaryzacji, która ma na celu nie doprowadzania użytkownika do szewskiej pasji. Mam też na względzie sytuacje, w których powstają nowe rozszerzenia i które mogą wymagać, by coś znalazło się w innym miejscu i raczyło poprawnie zadziałać.

Podam Ci teraz przykład, jak można pominąć problem związany z "nieprzelotowością" karta SDX. Podłączasz nowy kontroler Karin Maxi. I co? - no i masz po podłączeniu kontrolera dwa dodatkowe złącza ECI. Z czego się one składają - wiesz chyba doskonale ;) -

Kontakt: pin@usdk.pl

92

> Wszystko ma na celu zapewnienie kompatybilności w różne strony, bo jestem zwolennikiem standaryzacji

i ta standaryzacja w przypadku sparty oznacza brak standardu co do reg.sterujacych (sa "gdzies" na d5 - albo i nie bo taka wersja tez jest) i to inni maja sie dostosowac obcinajac mozliwosci katra?

ja Ci podam tez przyklad. generator kodu dla 6502 jesli bedziesz ograniczal (dlugosc) i przenosil rejestry karta to wiesz jak bedzie wygladala konfiguracja programu zeby raczyl w koncu dzialac? pomijajac to co wczesniej napisalem dodaje: wszystkie odwolania do generatora kodu tez trzeba bedziue zmieniac i podobnie przenosic weszystko do ramu.
kolejny przyklad: minimalny obszar rejestrow czytania dla antica to 48 bajtow pomznoz przez 4 ... albo dowal kupe elektroniki zeby to jakos pomiescic. przy czym 48 bajtow przy generowaniu kodu 6502 to smiech na sali i nie warto nawet o tym myslec rowniez dlatego ze trzeby by konfigurowac prog. w karcie zeby dawal wlasciw eadresy - nie wykonalne. penwie mozna z projektu zrobic obrzyna przycinajac mozliwosci zeby dzialal jako tako ze sparta :-)

http://atari.pl/hsc/ad.php?i=1.

93 Ostatnio edytowany przez nosty (2012-09-04 22:49:38)

Dobra, sluchajcie, mam juz chyba jasnosc co robic i w jakiej kolejnosci.

Przed chwilą rozmawialem z Pinem, ktory powiedzial mi o kilku zastosowaniach carta w wersji standalone, o ktorych wogole nie pomyslalem.
I choc mnie wciaz najbardziej interesuje idea "invisible upgrade" (jak to ktos napisal na forum atariage), czyli gry na cartridgu ze wspomaganiem, to rozumiem tez potrzebe stworzenia rozszerzenia w wersji uniwersalnej. Boje sie tylko kto napisze na to frimeware w asemblerze PIC24, bo ja jeszcze dlugo moge okazac sie za cienki :/

Plan jest taki: skoncze carta z obecnym procesorem. Wbrew pozorom jest jeszcze sporo do zrobienia. Bardzo licze na pomoc Sebana w kwestii doprecyzowania schematu, ukladu resetu i zasilania. Ma on wielkie doswiadczenie z mikrokontrolerami Microchipa i juz zadeklarowal swoją pomoc, wiec wszystko bedzie OK.
Ja skoncze szybko prosty, uniwersalny frimeware, nastawiony glownie na obsluge duszkow softwarowych w najpoplularniejszych trybach graficznych, oraz inne funkcje graficzne i tekstowe. Do tego dorzuce kilka przydatnych rozkazow matematycznych, operacji bitowych itp. Zobaczymy co sie da zrobic. Moze, przy moich obecnych umiejetnosciach, nie bedzie to super wydajne, czyli np operacje beda 100x szybsze niz na Atari, a nie 200x ;) Ten cartridge bedzie mial mozliwosc flashowania z poziomu Atari (najlepiej) badz PC.  I takie carty wyprodukuje w niewielkiej ilosci i zaoferuje je wraz z dokumentacją naszym atarowskim programistom.
Jesli ktos bedzie chcial pisac gre wykorzystującą ten cart to w miare mozliwosci bede poprawial frimeware, dodawal nowe rozkazy na zyczenie itp. Mam nadzieje, ze pierwsza wydaną gra bedzie Asterodis arcade XXL'a w wersji delux.

Nastepnie kupie zestaw uruchomieniowy dla drozszego, mocniejszego procesora (70MIPS, 56KB RAM, 512KB flash). I zaczne prace nad wersją standalone, kompatybilną ze Spartą itp. Tu bedzie mozna bawic sie w przelaczniki, bardziej rozbudowaną elektronikę itd. Choc nie sądze zebym podjal sie tego to sam, bo nie czuje sie dobrze w tych obszarach. Mam nadzieje ze uda mi sie zainteresowac pomyslem ktoregos z naszych czolowych elektronikow-konstruktorow, kto przejmie ten projekt i zrobi to profesjonalnie.

Jednoczesnie, gdyby ktos chcial poeksperymentowac z frimeware, napisac wlasny lepszy, czy dodac jakies rozkazy, to chetnie zbuduje i wyporzycze cart developerski, pozwalajacy tworzyc i debugowac frimeware. Wykorzystuję do tego tani uklad developerski Microchipa o nazwie Microstick II. W tej chwili czekam na zamowione czesci do kolejnych prototypow.

Przy okazji chcialem podziekowac XXL'owi za pomysly i entuzjazm, Sebanowi za pomoc w elektronice i dzielenie sie wiedzą, oraz Sikorowi za przetlumaczenie info na AtariAge.

94

nosty: w tre miga wrzucaj obecna wersje zrodel do githuba. tj. tego, czym obecnie programujesz microchipa. i nie wazne jaki jest stopien zaawansowania, jak malo/duzo komentarzy/dokumentacji - po prostu wrzucaj co masz i nie tlumacz ze sie wstydzisz, bo nie masz czego. wrecz przeciwnie - juz masz czym sie pochwalic, a kod pokazujacy realizacje bersenhama to tez przyklad jak cokolwiek na tym rysowac. taki przyklad znaczy wiecej niz fizyczne posiadanie carta do developowania ;)

jak bedziesz potrzebowal wsparcia finansowego przy robieniu egzampli egzemplarzy dla programistow - daj znac, raczej pomoge ;)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

95 Ostatnio edytowany przez Pin (2012-09-04 23:32:29)

xxl napisał/a:

i ta standaryzacja w przypadku sparty oznacza brak standardu co do reg.sterujacych (sa "gdzies" na d5 - albo i nie bo taka wersja tez jest) i to inni maja sie dostosowac obcinajac mozliwosci katra?

jak sobie wyobrażasz player do muzyczek działający bez dos'a? - dobra, powiedzmy, że to nie tylko sparta istnieje na tym świecie. Ok. Ile widziałeś ostatnio na zlocie komputerów wyłącznie ze stacją dyskietek? Dobra, używamy Mydosa i dowolny dysk twardy; mamy player, muzyczki ... i zonk. weszło 61 muzyczek na 16MB (ATR / cokolwiek), oraz player, dos.sys i dup.sys.... i Error. Brakło miejsca na katalog. Dobra - no to robimy podkatalogi .... eghm - 500 chiptune'ów i podział po 64 pliki na katalog.... masakra. Czyli co - ze względów zdrowotnych powracamy do Sparta DOS X ;)-

Co do standardu - został w przypadku cartów ustalony na $D5 i nikt już nie ma na to wpływu, co było. Co do przyszłości to jedno jest pewne; można na nią wpływać :)

Co do przykładów o których mówisz, to nikt Ci tego nie zabroni robić i cały czas staram Ci się to wyłuszczyć. To już mantra chyba jest :) - możesz programować co chcesz i na czym chcesz i jak chcesz. Wątpię jednakże, iż jesteś osobą zainteresowaną, by zrobić coś na TOMEK-8 w wersji standalone i co będzie uniwersalne i zadziała: na dowolnym dosie / osie / srosie itd. - chodzi o programy przede wszystkim (jak dla mnie) użytkowe, być może coś więcej. Wyjdzie w praniu. Jeśli to dla Ciebie zła idea, to tak, jak pisałem już wielokrotnie - możesz przecież pisać wyłącznie na carta nie sugerując się żadnymi ograniczeniami i zrobisz to co zamierzasz i co będziesz chciał tym sposobem osiągnąć. W Caldridge'u będzie dopał, będzie gra, nie będzie ograniczeń, będzie wszystko. Jaki problem?

Nie miej też za złe, że ktoś używa 65c816, Sparty X, HDD, Stereo, covox'a, grzebienia itd. bo przypominam, że bronisz opcji urządzenia, które w pierwszej wersji stanowi procek o możliwościach obliczeniowych równych 40mips, który co, jak ... czy to bardziej wygląda jak "standardowe Atari" ? ;)- Czy po prostu chcesz podłączyć procek 40 mips pod XC12? :D

Kontakt: pin@usdk.pl

96

> jak sobie wyobrażasz player do muzyczek działający bez dos'a?

jeden taki napisalem


> ... i zonk. weszło 61 muzyczek na 16MB (ATR / cokolwiek)

ja to bym olal smieszne ograniczenie 16mb, przeszedl na FAT Filesystem i dogral xbiosa na sio2sd :D


Pin... wyluzuj :D piekne jest to, ze kazdy moze sobie uzywac co chce, tragedia by byla gdybysmy nie mieli wyboru :D

http://atari.pl/hsc/ad.php?i=1.

97 Ostatnio edytowany przez Pin (2012-09-05 00:00:24)

xxl napisał/a:

jeden taki napisalem

Nie myl Playera do muzyczek z Music Collection, błagam ;) (jeśli to ten program(/y) o którym(/ch) myślę.)

... a tak przy okazji, dla przykładu sprawdziłem ile mam muzyczek na HDD podłączonym bezpośrednio do Atari: niecałe 3000 sztuk. Dlatego więc szczególnie często mówię o SDX mając na względzie zastosowanie użytkowe, gdyż żaden inny system nie udźwignie sensownie takiej masy danych ;)-

Ok, wystarczy tej dywagacji o standaryzacji ;)-

Kontakt: pin@usdk.pl

98 Ostatnio edytowany przez xxl (2012-09-05 00:07:38)

> Nie myl Playera do muzyczek z Music Collection, błagam  (jeśli to ten program(/y) o którym(/ch) myślę.)

SlightSID Player to nie music colletion :-)


> ... a tak przy okazji, dla przykładu sprawdziłem ile mam muzyczek na HDD podłączonym bezpośrednio do Atari: niecałe 3000 sztuk. Dlatego więc szczególnie często mówię o SDX mając na względzie zastosowanie użytkowe, gdyż żaden inny system nie udźwignie sensownie takiej masy danych -

niezle, ja na FATcie mam 3979 plikow muzyczeki atari jakos sobie radzi bez sdx

a jak juz porownujemy czlonki to czy Twoj HDD robie bibibi jak moje sio2sd ?

http://atari.pl/hsc/ad.php?i=1.

99

xxl napisał/a:

SlightSID Player to nie music colletion :-)

dobra, tego nie widziałem i nic nie mogę powiedzieć.

xxl napisał/a:

niezle, ja na FATcie mam 3979 plikow muzyczeki atari jakos sobie radzi bez sdx

Chętnie zobaczę, jak to działa :)

Kontakt: pin@usdk.pl

100 Ostatnio edytowany przez mono (2012-09-05 04:19:28)

nosty napisał/a:

Brak dekodowania adresow wymusza dyscyplinę u programisty Atari. Musi on trzymac sie protokołów
komunikacji. Nie moze nastapic zaden przypadkowy odczyt ze strony $D5xx bo urzadzenia sie rozsynchronizują.
Ale to sie sprawdza. Te animacje z dema zostawilem kiedys wlaczoną na całą noc i rano w dalszym ciagu działała.

Co do wykorzystania rozkazow, ktore wykonuja np dwa odczyty to tak jak napisal Jell sam cartridge nie ma jak sie tego domyslec. Musialbys miec frimeware ktory "wie", o tym ze uzyjesz takich rozkazow.

A ja bym proponował inne rozwiązanie.
1. Obszar adresowany przez antic, jak wiadomo nie będzie wymagał żadnych cudów i można założyć, że podwójne odczyty się nie zdarzą. Można więc wydzielić obszar np. $d500..$d52f, w którym pojawiałaby się pamięć ekranu do odczytu przez antic.
2. Wszystkie procedury ułatwiające żywot programiście niech korzystają z osobnych komórek. Dzięki temu nie zmuszamy go do dyscypliny (i znajomości niuansów 6502), a dajemy możliwość korzystania z dowolnego trybu adresowania jaki mu w danej chwili się zamarzy. Twój kod do mnożenia wyglądałby tak:

    lda #$40  ;rozkaz mnozenia
    sta $D530
    lda factorA
    sta $D531
    lda factorB
    sta $D532
    lda $D533    ;lsb wyniku
    ldy $D534    ;msb wyniku

Nie ma niespodzianek.

Edit: adresy

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