No cóż. Telefony bez klawiszy nie są konsolami do gier, a na ekranie nie ma szans na dobre sterowanie.
Niech ktoś wymyśli "stację dokującą" (taką trzymaczkę jak do auta na gps) rozmawiającą z fonem po bluetooth z klasycznymi klawiszami padowymi, to wtedy to miałoby sens.

@pasiu - uff ;)

@Pin - We flaszu jest kupę miejsca. Nada się dowolny program potrafiący wołać zewnętrzne procedury w asemblerze. Oczywiście idealnie byłoby aby to był kod 816 działający w jakimś wysokim banku korzystający w minimalnym stopniu z pamięci podstawowej, ale jeżeli pogodzimy się ze zniszczeniem zawartości pamięci Atari po uruchomieniu konfiguratora, to praktycznie nie ma żadnych ograniczeń.

A ja polecę desktopa z trzema monitorami, bo na laptopie to można sobie atari-area przeglądać, a nie programować...

Chłopaki biją się, kto pomoże z pisaniem softu i nie wiem komu mam dać tę devoperską Atarkę. Muszę przeprowadzić jakąś eliminację, żeby zostawić najlepszego...

Ale czad. Tempo wyświetlania podaje w ramkach a nie fpsach. PCtowcy chyba nie są w stanie operować tą jednostką.

Zgłoś się na programistę, a sam sprawdzisz ;)

To tak się zmieniły obyczaje, że na party-place spać już nie można?

Nie wydaje mi się, żeby Pasiu myślał o jakimś oficjalnym sposobie na detekcję Rapidusa. Mniej więcej aktualny spis rejestrów new device jest tu, a aktualna wersja ROMu new device od adresu $d820 ma 32 bajty napisu wg takiego szablonu (to przykład z ostatniej kompilacji).

dta d'     Build 101 (2014-01-21)     '

Jak komuś bardzo byłoby to potrzebne, to jest trochę miejsca, żeby dodać gdzieś jakąś stałą sekwencję precyzyjniej definiującą, że mamy do czynienia z Rapidusem.

Disclaimer: Chciałbym się tu przyznać, że opóźnienia Rapidusa wynikają także z mojej winy, bo mam mało czasu / siły na pisanie firmware'u, ale wydaje mi się, że do super podstawowej wersji niewiele zostało do dodania.

Na Atari napisano program grający w go (chyba jest u Kaza). Nie udało mi się z nim zagrać, bo trochę denerwowało mnie sterowanie, ale wątpię, żeby był "mocny".

Ale jaja. Wygląda na to, że tak. Atari planowało zastosowanie w 400/800 procesora inspirowanego 6502, który nawet nie byłby binarnie zgodny z 6502 (zgodność miała być tylko na poziomie kodu źródłowego, tak jak 6809 kontra 6509), i wykorzystywałby wszystkie 256 opcedów. Niestety SY nie dał rady i zostali przy 6502. Wg mnie kult 6502 z jego nielegalami trochę na tym cierpi, bo nie był to upgrade, albo extension, tylko całkowita zamiana.

Miał być to procesor pseudo 16-bitowy i autor podał definicję procesora pseudo 16-bitowego, jako o "wewnętrznie 16-bitowym układzie rejestrów, jednak zewnętrznie używającym szyny 8-bitowej". Autor artykułu sam jednak nie wie, czy to procesor 8 czy 16-bitowy - w jednym miejscu pisze, że to wg niego najmocniejszy 8-bitowiec na rynku, a w inny miejscu, że będzie można wkładać do APPLE II 16-bitowy procesor.
Koncepcja jest zbliżona do 65c816 chociażby ze względu na tryby pracy (ustawiane w rejestrze Q) zamiast osobnych instrukcji 8 i 16 bitowych tak jak w 6809. Ale zestaw instrukcji wydaje mi się słabiutki... taki jakiś "z dupy". Jakieś dziwne przesłania, zamiany, dedykowane push/pull, szalone rotacje i nawet opcody na przerwania (BR1-BR5). Mam pewne wątpliwości, czy ten zestaw nie jest jakimś hoaxem, bo trzeba być chyba na jakiś kwasie, żeby tracić kompatybilność z 6502 dla czegoś tak chaotycznego.
Ja się cieszę, że to nie wylądowało w Atarkach.

Holly shit. Próbowałem przebrnąć przez tę książkę. Wydaje się jakby była dla dzieci, ale nie dajcie się zwieść pozorom. Za pierwszym razem odpłynąłem jak zobaczyłem operator <*>, potem monady rozłupały mi czaszkę, a za trzecim razem wymiękłem na zipperach.