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.

Z tą czytelnością / wydajnością byłem nieprecyzyjny. W czasach powstawania atari800 nie można było sobie pozwolić na taką architekturę, jaka jest w atari++, bo nie było komputerów, na których by to poszło. Sytuacja się zmieniła. Emulator powstał. Nie taki wierny jaki atari800, ale to już jest kwestia osobomiesięcy spędzonych nad kodem. Jego plusem jest spójność i łatwość modyfikacji i nie uważam, że autor przesadził z obiektowością. Jest poprostu konsekwentny. To nie jest kod w C tylko C++ i to dobry C++.  A żeby projekt sie nie zawalił i nie trzeba było go łatać, nie można sobie pozwolić na haki oszczędzające trochę czasu procesora.
A poza tym kod nie jest rozwijany w Visual Studio. W porcie windowsowym pomagał ktoś inny.

Jak wiesz projekt Atari800 nie ma nadmiaru developerów, którzy tylko czekają na pomysł, żeby mieć co robić. Ja i Perry jako osoby najlepiej znające emulator od środka napisaliśmy kawał TODO, ale nie zawłaszczamy sobie prawa do zrealizowania wszystkiego własnymi siłami (jakby mało było tego, co dotychczas zrobiliśmy). Chętnie natomiast weźmiemy udział w dyskusji, poradzimy, podpowiemy, itp.

Właśnie dotknąłeś istotnej kwestii - łatek vs starannego projektu i napisania od nowa. Przepisałem na nowo znaczną część Atari800 i dlatego jestem krytyczny w stosunku do łatek, które chociaż trochę burzą porządek, bo wiem, że jeśli niskim nakładem pracy wprowadzi się je dzisiaj, to kiedyś nadejdzie czas, żeby je posprzątać (a autor łatki prawdopodobnie będzie już nieosiągalny).