Z XLPaint MAX-em UltraXE w ogóle mam problemy. Jak i z wersją 8 tak i 16 bitową. Linia rysuje się jakoś z boku. Niezłe. Pierwszy raz coś takiego widze :)
A800Win+ i Atari++ radzą sobie bez problemu z 8 bitową...

jellonek:
spoko spoko. draco wypuści emulator z80 pod warpa/f7, to i motywacja się znajdzie ;) A poza tym w TODO czytamy

[...]
   - CPU upgrades (65816, etc)
[...]

więc to tylko kwestia czasu ;)

alex:

Przy odpowiednio dużej determinacji wszystko się da, tylko wymagałoby to rewolucji w źródłach. Sam procesor i pamięć byłoby pewnie nawet prosto, ale np emulacja WARPa (szybszy zegar w wysokiej pamięci) albo F7 (dodatkowe cachowanie zerowego banku) wymagałaby znajomości źródeł na poziomie 0xF'a, a nawet wspomniana linijka w TODO jest zbyt nisko, aby liczyć na szybką interwencję w kwestii WARPów :)

Uważam poprostu, ża są emulatory, w których można zrobić to szybciej i łatwiej ;)

O... zaczyna się ciekawa dyskusja. Ciekawe ilu atarowców ma komp na strychu, ilu chłodzenie wodne, a ilu gąbeczki pod twardym dyskiem, żeby nie rezonował...

Cóż, niektórzy nie są maniakami wyciszania kompa i wyłączają w nocy komputery ;)

dely: u mnie zżera 10% proca, to dużo? Pozatym naciśnij tab i będziesz mógł dragować  zawartość :)
A oprogramowanie oficjalnie dawane przez producentów kart sscie IMHO bardziej: okrągłe okienka, mnóstwo butonów, suwaków, ikonek i innych wodotrysków tylko po to, żeby interfejs "fajnie" wyglądał... nie trawie takiego oprogramowania. Przykład na załączonym obrazku:

lol

Ja tak czytam po kilka razy i nie rozumiem co takiego złego jest w pisowni jellonka? Chodzi o interpunkcję, polskie znaki czy może jeszcze coś innego?

Aż podłączyłem Atarke do kompa przez karte TV, zrobiłem GR.15 i POKE 559,35 ustawiłem pamięć ekranu na śmieci, policzyłem pixelki i wyszło mi 176 nie licząc paska śmieci po prawej :)

Odgrzebuje, bo ostatnio zerknąłem do niego i muszę powiedzieć, że jestem pozytywnie zaskoczony.
Jakie są dowody, że kod atari++ jest zżynany z atar800? Z tych fragmentów kodu które czytałem, to jest on zupełnie inny. Nie wykluczam, że mogła zostać wyrżnięta jakaś trudniejsza procedurka, no ale bez przesady, w "zywcem przeniesione pliki, ze zmienionym naglowkiem" trudno mi uwierzyć: atari800 to czyste C napisany w sposób przypominający wynik działania obfuscatorów (IMHO ma szanse na wysokie miejsce w IOCCC ;) ), a atari++ napisany jest bardzo czysto obiektowo i widać, że na początku był projekt, a nie radosne programowanie, dzięki czemu rozszerzanie go o cokolwiek nie sprawia żadnych trudności. Najnowsze dema chodzą i jedyne co zauważyłem, to że dźwięk faktycznie trochę pierdzi (co dowodzi, że przynajmniej POKEY nie był wyrżnięty ;P). A jakie są inne ciężkie winy, że tak jest jechany i skazany na banicję?

No! To już zaczyna mieć ręce i nogi! Pomysł z nienadpisywaniem adresu rejestru jest super. A wiadomo już czym dokładniej będą różniły się te tryby, czy to jeszcze w fazie opracowywania?

Rozumiem, że jak GTIA jest w trybie OFF, to nic na ekranie się nie wyświetla (nie ma bombardowania). To stanowi jednak pewien problem w przypadku renderowania w czasie rzeczywistym, bo mamby do dyspozycji tylko czas powrotu plamki na zmianę pamięci, czyli niewiele. Bez tego, to można tyko sprzętowo dopalić graph2font :) Upgrade byłoby znacznie atrakcyjniejsze, gdyby było jakieś podwójne buforowanie: wyświetla się zawartość jednego fragmentu pamięci, a zapisujemy do drugiego i gdy gotowe jakimś rejestrem przełączamy...

Czyli licznik zwiększy się w momencie zapisania czegoś do $d025? Cóż, pofantazjować można: jakbyście projektowali upgrade 2.0, to fajne byłoby np poświęcenie adresów $d080-$d0bf w ten sposób, że zapisana tam wartość, to "wartość", a młodsze 5 bitów byłoby odrazu "młodszym adresem rejestru". Zawsze trochę dopali :) (chociaż na 65c816 teraz też jest szybko)

O cholera. To aż tak źle? To może i dobrze, że 6502/65816 nie ma mnożenia ani dzielenia, bo odczytanie z tablicy jest o wiele szybsze ;)

Na wikipedii piszą, że 68010 ma cache na dwie instrukcje i w rezultacie jest 10% szybsza :)