Za bezpodstawne krytyczne uwagi biję się w pierś i przepraszam! Napisałem trochę emocjonalnie, bo wcześniejsze posty też takie były. W kwestię kradzieży źródeł nie będę wnikał, bo nie mam intencji bronić autora ani nie ma to znaczenia w wykorzystaniu samego emulatora.
Tak z pewnej perspektywy, to porównywanie obu emulatorów jest bardzo trudne, bo mają odmienne założenia. Atari800 powstawał w zamierzchłych czasach, gdy wydajność miała znaczenia i poświęcono dla niej czytelność, podczas gdy w atari++ wydajność została poświęcona dla czytelności. W rezultacie jak atari800Win zjada tak mało procesora, że taskinfo nawet nie chce pokazać ile, to atari++ potrafi zjeść nawet 7%, ale nie wydaje mi się, żeby dziś stanowiło to problem. Dla mnie atari800 przedstawia się jako bardzo stabilny i dojrzały projekt, w którym nie ma miejsca na eksperymenty i zwykły "szary człowiek z ulicy" nie ma nawet odwagi nic tam dopisać. Z drugiej strony atari++ po pobieżnym zapoznaniu się z architekturą jest bardzo czytelny i podatny na modyfikacje i eksperymentowanie w nim jest bardzo proste. Dodanie GTIA Upgrade wymagało kilku dni zapoznawania się z architekturą i dosłownie kilku godzin pisania. Przyznam się, że mam już w fazie testów emulację 65c816 + liniowy ram (pisałem parę tygodni wieczorkami, bo dużo rozkazów :P), a puszczenie high-ramu na wyższym zegarze ze zgodnością z WARPem wymaga kilku żmudnych (bo znowu dużo rozkazów) ale prostych modyfikacji.
W rezultacie przeznaczenie obu emulatorów może być także różne. Na atari800 można odpalać stare gierki, ale uważam, że współczesnym hardwarowym rozwiązaniom jakie mamy teraz na scenie przyda się support nawet kosztem tego, że jakiś pixel zasyfi, pokey zapierdzi albo nie odpali się stara gierka.

Jak włączysz tryby GTIA, to będzie kaszanka. Dopałka nic nie zmienia w tej kwestii. Tryby GTIA nawet "przeszkadzają" jej, bo spowalniają zmiany rejestrów. Obrazki prezentowane przez TeBe nie wykorzystują GR.9/10/11 i nawet na padniętym GTIA będą wyświetlane poprawnie.

Pojęcie trudności jest względne: w atari800 byłoby to bardzo trudne (zbieżne do "niemożliwe"), podczas gdy w atari++ to tylko pare godzin kodowania.

A to dziwne, bo powinno być wolniejsze, bo wymaga przeparsowania tego co wrzuciliśmy do środka, a wszelkie Add* dodają tylko określone elementy. A w ogóle IE, skąd on pochodzi, ma jeszcze outerHTML ale jest zbyt hardkorowy i się nie przyjął ;)

Pod maską ciasno :/ Czy tu się zmieści?

I jeszcze pytania:
Czy da się wykryć dopałkę? Domyślam się, że jak będzie mapowanie pod $d02x to jakimiś trikami się da, w związku z tym co rejestry dopałki zwracają przy odczycie (unknown? $00? $ff?)

mikey: a ja tam się cieszę, że autor ofiaruje się lutować ustrojstwo. Jakby wypuścił od razu schematy na zasadzie "macie lutujcie sobie", to powstałyby dwie (niekompatybilne ze sobą) sztuki i na tym koniec.

Nie za bardzo rozumiem to ostatnie zdanie o centrowaniu. Jeżeli scrolling ustawimy na 0:0, to czy YPOS jest tożsame z offsetem w pamięci duszków przy rozdzielczości jednoliniowej podzielone przez 1,2,4 albo 8 w zależności od wysokości zmian, a XPOS jest tożsame z poziomą pozycją duszka (HPOS) podzieloną przez 2 albo 4 w zależności od tego czy zmiany są co pół albo co cały znak?

Oczywiście. O błędach w BCD informowałem już w wersji 1.51, ale poprawka w 1.52 zmieniła je tylko na inne. Te dane mam nadzieje pomogą w uzyskaniu dobrej emulacji.

Skoro już jesteśmy przy BCD miałbym małą prośbę. Żeby definitywnie przekonać się jak to jest z tymi flagami napisałem program, który wykonuje wszystykie 32896 możliwe dodawania dwóch liczb ośmiobitowych w BCD i zapisuje wynik wraz z flagami (700 kB). Programik jest tu. Wersja BCDD.XEX zapisuje wynik na D:, BCDH.XEX na H:, a BCDP.XEX na P:. Potrzebuję ochotnika, który uruchomi ten program na atari z 6502 i prześle mi wynik na laoo(at)icomp.pl. Chodzi mi o wynik na 6502, bo na 65c816 już sprawdziłem u siebie, a drugiej atarki nie mam. Sprawdziłem też na atari++ z emulacją 6502 jak i 65c02, na atar800win oraz na UltraXE. Każdy emulator robi to inaczej :)

Oczywiście jakby ktoś w komputerze miał 65c02 (podobno ostatnie modele atari mają. Prawda to w ogóle?) to też byłbym wdzięczny.

Nie jestem pewien w czym oryginalnie SoTe skompilował SAPa, ale podejrzewam, że w VS 2005. Na maszynie developerskiej skompilowane w nim programy działają pięknie, ale ich deployment potrafi napsuć człowiekowi krwi. Dużo krwi. Sesja z google zaoowocowała jakimś rozwiązaniem [które jest nieaktualne, bo niżej jest lepsze].

======== EDIT =========

Udało mi się skompilować statycznie. Pliczki są większe, ale nie wymagają msvcrt80.dll. Paczuszka jest tu.

Feedback mile widziany :)

Reasumując to nie wina .NETa, tylko najnowszego visuala, który aż kipi od nowoczesnych technologii, które wymagają conajmniej windowsa 2000 i z którymi są same problemy. Pewnie jakby skompilować to w jakimś np VC++ 6.0 to by poszło bez problemu nawet na win98, ale legalne to by już nie było ;)

Napewno normalne to nie jest. Napis pochodzi z SELF TESTu, ale na niego to nie wygląda. Jak masz aparat, to zrób fote, (albo filmik, jeśli efekt jest "dynamiczny").