alex: Ja tu nie widzę żadnego uproszczenia.

W Atari800 wiekszosc dostepu do pamieci jest opakowana makrami zdefiniowanymi w memory.h, wiec zmiana organizacji pamieci nie powinna nastreczac wiekszych problemow. Nalezy tylko osobno uwzglednic dostep do kodu 6502 w cpu.c oraz dostep do roznych rodzajow danych w antic.c.

Swego czasu w Atari800 bylo tzw. Paged Memory, gdzie dla kazdej strony przestrzeni adresowej (256 bajtow)
byly wskazniki: funkcja odczytujaca, funkcja zapisujaca, wskaznik na pamiec. Obecnie mozna sobie przekompilowac Atari800 tylko z Paged Attrib, gdzie mamy funkcje: odczytującą i zapisującą dla każdej strony pamięci, które to tablice zastępują normalnie używaną tablicę attrib[65536] zawierającą wartości: RAM, ROM, HARDWARE.

Moje pomysły są dwa:

1. Dostęp do danych w dodatkowej pamięci zrobić przez funkcje, podobnie jak dostęp do chipów.
Możnaby użyć tego zarówno z Paged Attrib jak i bez. Kod w Anticu już uwzględnia inne od 6502 ustawienie dostępu do $4000-$7fff dla danych ekranu, wystarczy tam więc mała przeróbka. Stosunkowo niedawno dorobiłem możliwość kompilacji cpu.c tak, aby zamiast adresu PC trzymany był wskaźnik do pamięci.
O dziwo testy wykazały, że nieco spowalnia to emulację. Jednak przydałoby się, gdyby ustawiać ten wskaźnik
tak, aby wskazywał na pamięć rozszerzoną.

2. Użyć sprzętowego mechanizmu stronicowania, który powszechnie występuje w nowoczesnych prockach. Istnieje możliwość mapowania przestrzeni adresowej w pamięć fizyczną stronami o wielkości zazwyczaj 4 KB. A więc tutaj pasowałoby w sam raz. Niestety nie słyszałem, aby jakikolwiek system operacyjny (DOS nie jest systemem operacyjnym) był na tyle wspaniałomyślny, aby dawać procesowi użytkownika możliwość modyfikowania tablicy stron. Trzebaby więc wykombinować albo znaleźć jakieś dodatkowo instalowane sterowniki, które taką możliwość dadzą. Nie muszę chyba dodawać, że jest to rozwiązanie całkowicie nieprzenośne między systemami operacyjnymi i architekturami sprzętu.

Myślę, że Atari800 powinien pójść (patrz inny topic) - odpalisz sobie w nim sapemu.

Drac030: pewnie tak, ze względu na to, że wykonuje je część procka od generowania adresów, a nie ALU.

Alex: pewnie napisałeś do Stehlika, który czasem bywa zajęty;
http://cvs.sourceforge.net/viewcvs.py/* … TALL.wince

Jeśli chodzi o "3)" to raczej pobożne życzenia (czytaj: jeśli uda się wam to zrobić, to pogratuluję).

jellonek: dłuższy rozkaz na pewno trudniej załadować, w dodatku taki, który ma parametr

jellonek: w tym poście jest mowa o Atari800 a nie o Atari800Win PLus. Biblioteka na WinCE ZTCW obejmuje MFC, brakuje natomiast całkiem podstawowych funkcji libc w rodzaju strdup().
ARMy mają świetny zestaw instrukcji, jednak przewagami x86 mogą być superskalarność (nie wiem jak z tym w ARMach), zmienny przecinek (ZTCW ARMy zwykle go nie mają) oraz dostęp do niewyrównanych słów i "mała indiańskość", co przydaje się przy emulacji 6502.

Jak to co? Portuj:
http://www.cs.tut.fi/~albert/Dev/puzip/

Alex: co rozumiesz przez "najnowszą wersję Atari800" ? Jeśli Ci się mocno nie spieszy, to zaczekaj na 1.4.0, które wyjdzie wkrótce. W przeciwnym przypadku ściągnij sobie źródła z CVSa i ew. mailnij człowieka obecnie odpowiedzialnego za wersję WinCE.

Nosty: refresh na 3, ew. wyłączyć "HiFi Pokey" i może ew. użyć wersji nowszej od 1.3.6.
Jak sam zauważyłeś, PocketC64 jest komercyjny i pewnie nie odpala wielu demek (w odróżnieniu od Atari800).

http://sourceforge.net/tracker/index.ph … tid=428635

... oraz stopniowe wersje zrodel efektow, zeby bylo wiadomo, ze kod nie jest np. zwalony z komody. ;)
A tak powaznie, to jesli chodzi o grafike Anj zglosil swietny pomysl.

Jak pisałem, to problem nietechniczny.

65c02 ma w pojedynczych przypadkach rozkazy szybsze o cykl. Tak wiec kod wycyklowany dla 6502 moze nam sie rozjezdzac z obrazem. Poprawna obsluga nowych prockow to nie tylko nieuzywanie nielegalnych instrukcji. W Numenie nic sie nie kaszani na 65816?

Jedynym slusznym emulatorem malucha na wszystkie platformy jest Atari800. Jeśli dla kogoś jest zbyt wolny, to są trzy rozwiązania:
1. Nauczyc sie go dobrze konfigurowac.
2. Dolozyc staran, zeby byl lepszy, czyli dolaczyc do projektu. Nie trzeba umiec programowac, od lat projekt czeka po prostu na dobra dokumentacje.
3. Nie uzywac emulatora.
Z emulatorem jak z zegarkiem - ma byc dokladny, a nie szybki.

Jak dla mnie mogą zajmować nawet 6 stron. Jeśli komuś brakuje flopek, to ja mam w nadmiarze. :)

Czytając teraz wszystkie wypowiedzi zauważyłem dziwną zgodność swoich poglądów z Macgyverem, frasunek!
Music compo: zlikwidować "jeśli organizator wyrazi zgodę", dopuścić RMT i COMy.
Gfx compo: jedno. Czekam na odpowiedź Vasca na to, co pisałem w Syzygy, również ostatnio. Rozumiem, że gdy pojawi się konwerter np. PNG->MIC/GR8/INP/INT/CIN
(kwestia kilku minut), formaty te zostaną dopuszczone do Conversion Gfx compo. Oczywiście, PNG dopiero po wypuszczeniu przeglądarki PNG (to już troszkę więcej roboty). Albo wiem - chodzi o to, żeby taki konwerter trzymać w tajemnicy - wtedy będziemy wystawiać na Graphics compo, bo przecież Conversion Gfx compo ich nie dopuszcza. Proszę jeszcze raz zastanowić się nad sensem wymieniania formatów graficznych, szczególnie takich, które można łatwo skonwertować, jak np. MIC<>PIC czy GR8<>CPR.
Mikey: problem TIPa nie polega na braku narzędzi do rysowania na Atari, gdzie mamy tłum dobrych grafików. Problem polega na tym, że brakuje grafików potrafiących specjalnie przygotować obrazek wykorzystujący ten tryb.
Intro 256: wracanie do DOSu to bzdura. Nigdy tego nie było, a oznaczałoby stratę wielu cennych bajtów. Ewentualnie można napisać, żeby komp nadawał się do użytku po resecie. Zasadniczo jestem też przeciwny nieliczeniu nagłówków, ale ponieważ sam kiedyś z tego skorzystałem, ostatecznie to przeboleję. Trzeba sprecyzować, czy intro może się wczytywać na stos i/lub stronę zerową i czy może korzystać z tego, że pamięć jest wyzerowana (były z tymi sprawami problemy).
Intra&demo: zakaz używania nielegalnych rozkazów jest zły. Jeśli są to dlaczego ich nie wykorzystać? Np. efekt działa o ramkę szybciej jeśli mamy stare 6502 (czyli na XL i starych XE). Oczywiście program sam musi to wykryć i radzić sobie jakoś, jeśli nielegalnych rozkazów nie ma. Ogólnie nie widzę sensu wymieniania akurat nielegalnych rozkazów 6502, skoro nie ma mowy o 65CE02, 65816 i innych prockach. Moje zdanie jest takie: umiem wykryć dodatkowe możliwości i wykorzystać je - ok. Wymagam konkretnego rodzaju procka - źle.
"ze wszystkimi możliwymi 64 lub 128 bankami do wyboru" - to może być mocno niezrozumiałe. 128 banków ma rozszerzenie +2MB i teraz trzeba się zastanowić, czy domagać się możliwości wyboru dowolnych banków dostępnych w tym rozszerzeniu.
Wiąże się to z pewnym dodatkowym nakładem pracy i wydaje mi się, że jest to wciąż "wiedza tajemna".
Loadery: nie mam nic przeciwko nim, o ile są opcjonalne. Generalnie po to jest dodatkowa pamięć, żeby wczytać wszystko naraz. Jeśli ktoś chce napisać demo z efektami przy transmisji szeregowej, działające na 64 KB - proszę bardzo (chętnie bym zobaczył Overmind II), ale niech będzie możliwość wczytania z twardziela do pamięci 1 MB i wtedy efekty mogą być, gdy dane przepisują się z dodatkowej pamięci.
Gęstość medium: ok, wbrew pozorom niektórzy mają nieprzerobione 1050 (nie tyle w Polsce, co gdzie indziej).
Co do dem plikowych - generalnie dobry pomysł, ale tylko dla dem, które mieszczą się na jednej stronie medium.
"Jeśli demo posiada efekty podczas ładowania, nie może używać RAMu pod obszarem FPP - gdyż musi ruszać z HDD." - źle sformułowane - tak, jakby nie można użyć RAMu $d800-$dfff po wczytaniu dema. Chodzi o to, że sterownik SIO może się znajdować w tym obszarze i nie należy oczekiwać, że procedura SIO wczyta nam coś do tego obszaru. Ponieważ SIO jest w ROMie, to nie widzę większego sensu dla tego punktu, chyba że ktoś kopiuje OS do RAMu, a później robi JSR $e459, żeby wczytać w obszar FP - zwolennicy używania DOSów do wczytywania dem niech się wypowiedzą, czy można wczytywać dane bezpośrednio do pamięci pod ROMem i/lub rozszerzonej.