Biorę 33. Powinno starczyć dla każdego :)

OK. To był mój pomysł, to ja zrobię ten zakup. Kupię te 3 zestawy po minimalnej liczbie sztuk i będę rozdawał u Vasca :)

@perinoid ja nam najprawdopodobniej poucza od jedynki, bo dwójka ciężko wchodzi i jest wyższy. Tylko, że kupiłem używany, co widać. Ten akurat trochę drogo, ale na jakiś większy zakup zza wielkiej wody mógłbym się pisać.

Jak szukasz miejsca, to pewną opcją może być popsucie paru znaków w miedzynarodowym generatorze. I tak nikt z niego nie korzysta.

Pewnie jeden rabin powie tak, drugi rabin powie nie i pies jest pogrzebany pod słowem "whatever" z drugiego akapitu. Założę się, że Windows i Linux mają inne algorytmy mierzenia obciążenia CPU, zresztą, mówiąc o linuksie to co można mieć na myśli? To co drukuje TOP? Tak na chłopski rozum, to ja bym strzelał w 100%, bo "typowy" algorytm wyobrażam sobie jako samplujący w określonych odstępach co robi każdy z rdzeni, Jeżeli rdzeń nie jest w idlu to znaczy że jest używany, a w opisanej przez Ciebie sytuacji raczej do idla nie przejdzie.

Podejrzewam, że większość woli qwerty, bo ümlauty kolą oczy, ale niestety podaż jest niewielka. Nie myślałeś o transplantacji? Na OLX wiszą teraz dwie angielskie atarki.

No, czegoś takiego to się nie spodziewałem. Taki trochę steampunkowy klimat.

@Cyprian: Dzięki, z TOSem nie będzie problemu, bo sam mam 2.06, poza tym jestem na liście oczekujących na UltraTOS. Więc jest do ogarnięcia cache i 16 MHz. Blitter trochę mnie niepokoi żeby się coś nie rozjechało. No i do sprawdzenia ten _memtop.

To, że kompilatory istnieją, to jedno, a jaki generują kod, to drugie.  Problem jest wielowarstwowy, ale chyba kwintesencją mogłoby być to, że języki programowania ewoluowały razem z procesorami w swoistym sprzężeniu zwrotnym i współczesny kod w C, taki jak się robi go zgodnie ze sztuką nijak ma się do możliwości 6502, za to świetnie współgra z możliwościami współczesnych procesorów. Ja jestem pod wielkim wrażeniem jakie cuda potrafi wygenerować Clang na x64, arm, czy riscv, ale podejrzewam, że backend na 6502 mógłby nie być już taki spektakularny, gdyż 6502 może nie spełniać minimalnych wymagań maszyny na jaką Clang jest w stanie cokolwiek sensownego wygenerować. Jako konkretne problemy można wymienić chociażby kwestie zarządzania pamięcią na tymczasowe zmienne lokalne (naturalny jest stos, który na 6502 trzeba emulować, bo sprzętowy jest mały i trudno dostępny), popularne wzorce adresowania pamięci (które nie mają wsparcia w 6502 przez jego dość specyficzne tryby adresowania), czy rozmiar operandów (dla 6502 nawet 16-bitów jest trudne i pisząc w asemblerze unika się tego sztuczkami, na które niekoniecznie możne sobie pozwolić kompilator nie znający kontekstu i tego co programista miał na myśli).

@mormon
Oczywiście da się zrobić tak jak zaproponowałeś. Tak się nie robi tylko dlatego, że programując w asemblerze nie używa się do tego stosu, a programując w języku wysokiego poziomu nie używa się do tego stosu sprzętowego, bo jest niebezpiecznie mały.

Warunkiem de facto koniecznym do stosowania 6502 w takich nietrywialnych miejscach jest istnienie dobrego kompilatora C, tak jak wspomniał Seban. Ja żadnego nie znam. Wiem o istnieniu komercyjnych kompilatorów C, ale nie mam zielonego pojęcia jakiej one są jakości, bo na oczy żadnego nie widziałem. Nawet WDC ma swój kompilator

O... jak pisałem tego posta, to odkryłem, że narzędzia programistyczne od WDC są dostępne za free: https://wdc65xx.com/WDCTools

Co do wymiany TOSu, to może lepiej poczekać na te cudo?  http://www.atari.org.pl/forum/viewtopic.php?id=17277

"Przełączanie" TOSów będzie w nim programowe, więc odpada problem z przełącznikami.