Chyba, ze akurat ten zwrot notorycznie przewija się w moim tekscie ;>

Problem rozwiązany.

Pomysl Grzybsona sprawdzil sie najlepiej. Dzieki.
Wystarczyło wydzielic teksty do osobnego pliku. Taki plik konwertuje ASCII na ATASCII z konwersją polskich znaków, a nastepnie ponownie ATASCII do ASCII, wybierając konwersję _tylko_ znaków konca linii.

W ten sposob mam plik, ktory po wlaczeniu do asemblera (przez ins) skompiluje mi sie z poprawnymi atarowski polskimi znakami.
A pod windą mogę go dalej edytować, i dopisywać kolejne teksty, bo znaki konca linii mam windowsowe, a zamiast poskich znakow widzę kwadraciki (jednym wyjątkiem jest wielkie "Ń", które powoduje pod windą złamanie linii - ale tej litery praktycznie nie używam).

thx!

Uuuu! Ta cena jest mooocno przesadzona.
M.U.L.E. pojawia sie stosunkowo często i cena jeszcze niedawno wynosiła średnio ~$70. Teraz pewnie już ciut wyżej będzie.
Choć z drugiej strony - kryzys, więc kto wie ;)

Ja swoją kopię wycziłem w zestawie. Wiesz, na fotce nie było, ktos tylko wymienił małym drukiem w opisie softu z zestawu.

powodzenia!

No ja jestem za tym, żeby ogłoszenie zostawić jako przyklad dla odwiedzających nas nieraz spamerów-amatorów, jak się robi profesjonalny PR ;)
I ze oplaca sie czasem bardziej wysilic wstawiajac bajer na kolejnym forum, a nie tylko w kółko ctrl+c ctr+v tekstu "Hej! Znalazlem zupełnym przypadkiem zajefajną stronke..." ;)

Nawet klikłem se w link ;P

XXL - skomentuję to tak: "nie ma bunkrów ale i tak jest zajebiście!" ;)
Reszta na priva pójdzie.

Gra prosta i fajna - wersja we flashu do której link przysłałes wygląda jakby była przerabiana z Atari ;)

UPDATE:

Po wstępnym oblukaniu zmieniam zdanie - albo mocno utrudnisz grę (choć nie wiem jak - bez gruntownej zmiany zasad to chyba niemożliwe) albo będzie to gra dosłownie na kwadrans.
Po rozkminieniu o co wogóle chodzi (bo instrukcji nie chciało mi się czytać) przeszedłem jednym ciągiem do 30 (słownie TRZYDZIESTEJ) planszy bez straty życia , popijając pifko. A nie jestem jakimś geniuszem wyobraźni przestrzennej. Dalej grać mi się nie chciało.

Gra jest za prosta i trudniejsza raczej nie będzie - większość plansz przeszedłby pewnie komputer wg prostego algorytmu...

Ja myślałem o fizycznym, zewnętrznym zmiksowaniu sygnałów Video obrazów wygenerowanych w opisany sposób przez dwa komputery.
Mielibysmy 2x więciej duchów i sporo więcej kolorów (min 8, albo 10 a ze zmieszania jeszcze dodatkowe).

Candle - a bo to dwie atarki polożone jedna na drugiej zajmują tak duzo miejsca? ;)

Lepszy cwaniak, co? ;)
Zgaduje: wymyśliłeś, ze procek na cartridgu mogłby np... liczyc bardzo precyzyjnie w ktorym momencie zmienic rejestry kolorków? :D

Wczoraj sie nad tym zastanawialem, ale niestety cart ma dostep tylko do konkretnych 16kB pamieci + strona $D5xx. I na pewno do niczego wiecej.
uC z cartridga moglby jednynie zmieniac jakies rejestry na stronie $D5xx w odpowiednim momencie. Ale czy to Ci cos da?

Candle, poczekamy - zobaczymy.
Zenon i tak to zrobi :) Przynajmniej do etapu prototypu, zeby sprzadzic "czy to da sie".
Moze ktos cos uzytecznego potem z tego wyciągnie.

Skoro tak mówisz... Ja sie malo znam, ale wydaje się, że z punktu widzenia programisty i procesora Atari byłyby to duchy sprzętowe.
Atari definiuje ducha, pozycje itp, a resztę robi dodatkowy sprzęt (Weronika). Widzę to pewną analogię do współpracy z GTIA. Zerknij na poniższy "case study" użycia Weroniki:

Szybki pomysł jak zrobić obsługę duużych i licznych duchów za pomocą Weroniki:

Na cartridgu mamy szybki mikrokontroler (uC) z własnym programem (rdzeniem) w ROM i obsługą zewnętrznej pamięci SRAM (np. 64kB) (_oprócz_ dostępu do 8kB dzielonych z Atari). Przy odpowiednio szybkim procesorze wystarczy po prostu duża liczba obsługiwanych portów. Sprawdziłem - są takie Atmelki.
W rdzeniu uC znajduje się program specjalizowany wyłącznie do rysowania, przesuwania i obsługi kolizji duchów. Przy czym musi to oczywiście robić na pamięci ekranu zorganizowanej zgodnie z jakimś trybem (lub trybami) Atari.
Dla uproszczenia załóżmy obsługe wyłącznie jednego trybu graficznego.
Rdzeń rozumie też oczywiście polecenia dotyczące animacji duchów przekazywane mu z Atari.

Wazne: cartridge jest tak skonstruowany, że nie tylko wahadłowo dzielimy między procesorem i uC obszar 8kB, ale mamy też możliwość przekazywania do/z uC danych za pomocą niektorych rejestrów strony $D5xx. To jest mozliwe i potrzebne, bo idea jest taka, że dzielony wahadłowo obszar 8kB będzie pamięcią ekranu, a strona $D5xx będzie służyła do wysyłania danych i polecen między 6502 a uC.
Gdyby było to za trudne, to można obejść to wymaganie: Jeśli pamięć ekranu zajmowałaby mniej niż 8kB (np zrezygnowalibyśmy z wyświetlania kilku linii), to mamy pełny komfort: możemy zrezygnować z komunikacji przez stronę $D5xx i wykorzystać do przekazywania danych fragment 8kB obszaru pamięci, który jest już poza widoczną na ekranie pamięcią obrazu. Nie potrzeba tego wiele - wystarczy nam kilkadziesiąt bajtów.

Pamięć robocza SRAM (do której dostęp ma oczywiście tylko uC na cartridgu) zawierać będzie obszary:
(A) 8kB - pamiec tla,
(B) XkB - definicje duchow,

Oczywiście są one zgodne z trybem graficznym Atari, który obsługujemy. Załóżmy, że pamięć ekranu zajmuje w tym trybie 8kB.

Wyobraźmy sobie na początek dla uproszczenia grę, w której tło jest stabilne (bez scrola) a poruszają się po nim animowane obiekty. Takimi grami sa np. Bomb Jack albo World Karate.

Grę piszemy w taki sposób, że procesor w Atari nie zapisuje niczego do pamięci ekranu! Całą budowę ekranu przerzucimy na uC na cartridgu. Trzeba mu tylko dostarczyć odpowiednie dane.

A obsluga gry i duszków dziala tak:
1. Na poczatku Atari przekazuje do carta tło danej planszy oraz definicje duchow (wszystkie obiekty w różnych fazach ruchu). Można to zrobić przez stronę $D5xx albo przez wspóldzieloną pamięć. Będzie to ciut wolne, ale na czasie nam tu specjlanie nie zależy - gra się jeszcze nie zaczęła. uC odbiera te dane umieszcza je w obszarze SRAM przeznaczonym na tło (A) i duchy (B).
2. Atari ustala pozycje, widocznosc, animacje, priorytety i inne parametry duchow.
3. Pamięć ekranu zostaje ustawiona na współdzielnony obszar 8kB cartridga.
4. uC wykonuje polecenia Atari dotyczące duchów nakladajac duchy na tlo i zapisujac do 8kB "połówki" dzielonej pamięci do której akurat na dostęp. Ma na to 1/50 sekundy - czas ramki.
W tym czasie wykrywa rowniez kolizje duchow. Będzie je mógł później przekazać do Atari przez odpowiednie rejestry strony $D5xx.
5. W czasie przerwania VBI Atari wysyła polecenie zamiany wspóldzielonych połówek 8kB. Na ekran trafia właśnie przygotowany obraz. A od tego momentu uC może zająć się przygotowaniem kolejnej klatki wg przekazanych przez Atari nowych pozycji i faz animacji duchów.

I tak w kółko.

To po krotce tyle.
Jak pisałem - nie ma sensu, żeby procesor Atari sam modyfikował pamięć obrazu bo te zmieny i tak zostaną "przykryte" po 1/50 sekundy przez kolejną klatkę przygotowaną przez uC.

Witam po dlugiej nieobecnosci.
Ponieważ mialem mozliwosc dyskutowania z Zenonem jego pomyslu, a takze konsultowania sie z XXL'em i Sebanem na bardzo podobny temat, pozwolę sobie na slowo komentarza.

Mam wrazenie, ze wiekszość komentatorów nie załapała co jest najważniejsze w pomyśle Zenona. Otóż najmniej ważne jest jaki procesor będzie na carcie! Najważniejszy jest pomysł na "wahadłową" zamianę dwóch 8kB banków pamięci między procesorem głównym a koprocesorem, przy czym ta zamiana jest sterowana zawsze przez 6502 komputera.

Pomysł koprocesora jest bowiem stary jak świat, ale "wąskim gardłem" był właśnie dostęp do pamięci (lub też wymiana danych między procesorem głównym a koprocem). W grę wchodziła dotąd albo fizyczna zamiana procesora w komputerze na mocniejszy, albo pomysł z pamięcią dwuportową.
Zrobiłem rozeznanie i pamięci dwuportowe są albo nieosiągalne albo baaardzo drogie.
Ja miałem jeszcze jeden pomysł: sprzętowa emulacja pamięci dwuportowej przez szybki procesor na carcie (np. Atmel). Ale po konsultacji z Zenonem i Sebanem pomsł wydał się za trudny w implementacji.

Tymczasem Zenon wymyślił genialny bufor: każdy z dwóch procesorów widzi naprzemiennie jeden z dwóch 8kB obszarów pamięci. I to jest istota jego pomysłu. Reszta to szczegóły, które mogą się zmieniać w konkretnych implementacjach.

Co nam to daje? Ano możemy sobie przyłączyć do tego interfejsu dowolny procesor. Jeśli będzie to 816 to będzie on uniwersalnym koprocesorem, a jego program będzie mu podawany w 8kB pamięci.
Ale, wbrew temu co napisał Candle może to być przecież mikrokontroler np AVR. Dlatego, że wcale nie musi on czytać swojego programu z zewnętrznego RAM'u dzielonego z Atari! Może mieć w swoim ROM'ie program (nazwijmy go "rdzeniem") a z Atari wymieniać jednynie dane.
Ograniczeniem będzie tu brak uniwersalności. Ale w ten sposób możemy sobie zrobić zależnie od potrzeb carta z rdzeniem wykonującym szybkie obliczenia matematyczne, albo z rdzeniem realizującym wieeelkie i liczne sprzętowe duchy.

Ja wręcz zastanawiałem się czy Weronika nie powinna być jednynie buforem obsługującym podmiane 8kB banków pamięci + złącze. I w to złącze możnaby sobie wstawiać płytkę z procesorem, byle potrafił on dostosowac swoją pracę do zasady działania Weroniki.
Wiem, że brzmi to dośc mgliście, ale myślałem nad tym od kilku miesięcy i uważam, że jest to możliwe.

A weźcie pod uwagę, że dzielimy tylko 8kB pamięci. A obszar cartridga w RAM'ie Atari ma 16kB. Czyli pozostałe 8kB z obszaru cartridga może zawierać zwykłą bankowaną pamięć gdzie może być umieszczona gra. Taki cart zawierałby wszystko co programiście i graczowi do szczęścia potrzebne. Np grę wymagającą sprzętowych duchów i procesor, który je realizuje.

A propos sprzętowych duchów, to dla mnie jest to najbardziej pociągający temat do implementacji w tym nowym cartridgu. W kolejnym poście postaram się dokładnie opisać jak mogłyby one działać na Weronice.

Z rozmów z Zenonem zarysowała się niestety też jedna dośc poważna wada: konieczność użycia dośc dużej ilości układów cyfrowych - co najmniej kilkanaście. Może to oznaczać, że cart nie wejdzie w standardową obudowę, oraz co gorsza koszt tych układów może być wiekszy niż mikrokontrolera. Ale może da się te układy cyfrowe troche jeszcze zredukować albo nawet zastąpić jakąś programowalną logiką...? Kto wie.

W sumie to ma tylko wartosc edukacyjna...

Ja mialem takie fajne cwiczenie na studiach: dostalismy plytkę z najrozniejszymi bramkami i gniazdami typu "bananek" i kłębek kabli z banankowymi koncówkami. Sercem i najbardziej skomplikowanym elementem plytki byl prosty sumator nczy coś a la w podobie.
Do tego bylo kilkanaście LED'ow i  jakieś 16 bajtów pamięci (już nie pamiętam jak zrobionych). Szczegóły mi się zatarły.

Zadanie (na cały semestr) polegało na tym, żeby łącząc banankami zrobić z tego procesor, opisać rozkazy jego asemblera i napisać kilkunastobajtowy program który cokolwiek sensownego robi.

Dla połowy grupy był to horror, dla drugiej połowy najlepszy fun na studiach ;)