D:
Nie odważyłbym rozpoczynać dużego projektu w tym języku. Jest zbyt młody i zbyt mało powszechny (tylko trzy implementacje). Póki co wśród niezarządzanych języków nie widzę alternatywy do C++.

GC:
To półśrodek. Zarządza tylko pamięcią ignorując inne zasoby, o które trzeba dbać innymi mniej lub bardziej prymitywnymi metodami. Biblioteka standardowa C++ udostępnia zaś cały arsenał sprytnych wskaźników, które wystarczy tylko stosować, aby zapomnieć o wyciekach wszelkich zasobów.

No to i ja dorzucę swoje trzy grosze.

Programy pisze się dla ludzi. Maszynie jest wszystko jedno. To człowiek musi rozumieć program, aby móc go zmienić, gdy przestanie spełniać oczekiwania.

BASIC jakiego znamy z 8-bitowców jest językiem niestrukturalnym. Jest idealny do pierwszych kroków, ale nie wymusza, ani nawet  nie wspomaga struktury, przez co rozumienie programu jest bardzo trudne i modyfikowanie kosztowne. Nie mamy ani klarownego przypływu sterowania ani porządku w danych.

Języki strukturalne wspomagają strukturę wymuszając jasny przepływ sterowania, ale niestety o dane dbają tak samo, jak BASIC o sterowanie, czyli wcale. Większość energii zespołu jest pochłaniana na ręczne zarządzanie zasobami, ostrożną komunikację pomiędzy modułami i szukanie błędów kto komu nadepnął na stopę, a kto o czym zapomniał.

Języki obiektowe zaś chronią dane i w poprawnym projekcie to kompilator powie ci, że czegoś ci nie wolno (bo dobierasz się do cudzego obiektu i nie za bardzo wiesz jak, bo kolega nie napisał dokumentacji) i to kompilator automatycznie zwolni zasób, gdy nie jest ci już potrzebny. To nie moda. To odciążenie.

Języki deklaratywne są najbardziej wyrafinowane, bo w nich określamy tylko co mamy osiągnąć, a już sama maszyna dba o to, aby nam to dostarczyć, dlatego są najczęściej destynowane do specyficznych zastosowań (jak SQL czy HTML).

Inne paradygmaty jak języki funkcyjne czy logiczne (Prolog nie jest funkcyjny) mają wąskie zastosowania w rozwiązywaniu nietuzinkowych problemów wyuzdanymi algorytmami. Zastosowań mają mało, ale w tym, co robią, są diabelnie dobre.

Gdybyśmy wszyscy byli supermenami, to nie musiałoby powstać nic wyższego niż asembler. Człowiek jednak jest ułomny, a programy nieuchronnie błędne i musimy sobie pomagać, jak tylko potrafimy automatyzując co tylko się da, tak, aby jak najbardziej skupiać się na istocie problemu, a nie na technikaliach jego implementacji.

Jacques: Ja nie ryzykowałem i nie podpinałem swojego głównego konta. Podpiąłem specjalnie założony do tego drugi rachunek, na którym jest tylko tyle kasy ile trzeba.

Kilki rzeczy nie rozumiem...

Z tym przełączaniem banków jest tak jakie były pierwotne założenia? Przełączany obszar ($8000-$BFFF od strony atari) jest zdublowany i jeśli  RAMBANK_CFG == 0 to atari widzi wersję A, a kartridż wersję B, a w przeciwnym razie odwrotnie?
Jak działa te wstrzymanie procesora po włączeniu zasilania? Linia HALT? I po resecie jest zwalniana i już nigdy wstrzymywanie nie występuje aż do wyłączenia zasilania?
A jak działa RESET? Trzeba ustawić VER_CPU_RESET_PULSE_HIGH, po czym VER_CPU_RESET_PULSE_LOW i w tedy procesor startuje?

Ja też! Ja też!

Pecus ma dobrą myśl z tymi sprajtami. Asteroidy faktycznie się nie obracają, co bardzo upraszcza sprawę! Można pójść nawet odrobinę dalej: mieć zoptymalizowany kod na rysowanie każdego asteroida: sekwencja LDA # ORA (),y STA (),y + przesunięcia wskaźnika oraz zoptymalizowany kod na... mazanie danego asteroida. Statek można rysować klasycznie albo też mieć kilka zanimowanych klatek. To ma szanse na wyrobienie się w ramce-dwóch.

No i jak już mówimy o dopałkach, to wersja VBXE może mieć w swojej pamięć prerenderowane wszystkie elementy gry i w-OR-owywać je blitterem - wtedy na 100% zmieści się w jednej ramce. Mało tego - aby lepiej odwzorować oryginał o "nieskończenie wielkiej" rozdzielczości można użyć trybu 640x200 albo nawet 640x400 jak ktoś lubi migotanie :)

Można też pokusić się o wersję na 65c816, w której zoptymalizowana sekwencja rysująca może korzystać z fajnych szybkich trybów adresowania.

Potencjał jest całkiem spory.

A skąd akurat 15? ANTIC potrafi haltować CPU na o wieeele dłużej (np. w pierwszej linii wiersza tekstowego na całą jego szerokość).

No to właśnie mam zaczętego w SilverLight (stopień zaawansowania jest taki, że uruchamia się na nim SELF TEST), tylko że jest strasznie wolny i wymaga przeprojektowania kilku rzeczy, bo byłem zbyt optymistyczny co do jego wydajności ;)

No i tak to już jest. Napisałem VBXE. Zaimplementowałem interlace Rybagsa. I paczkę ściągnęło przez pół roku tylko 30 osób...

Ja niczego o takim dogadaniu nie wiem. Pasiu raczej nie ma czasu, bo nawet trudno się z nim skontaktować i pewnie ochota na inwestowanie w to energii też mu odeszła. Miast czekać proponuję szukać innego rozwiązania.

A ja nie wiem  jakiego WARPa mam. Chyba formalnie WARP4 "ustawiony" na 7 MHz (ze zworką na 14). Kiedyś chodził na 4 MHz (stąd nazwa) ale Pasiu mi coś podrasował i teraz chodzi na 7/14 MHz.

W atari odmierzać dokładny czas jest bardzo trudno, bo cykle procesora są bezustannie wywłaszczane przez pokaźną liczbę przeszkadzajek, więc liczenie cykli daje różne rezultaty w różnych warunkach. Proponowałbym dwa rozwiązania:
1) rejestr VCOUNT, który w systemie PAL co ramkę (1/50s) liczy od 0 do 155.
2) przerwania POKEYa. Jeśli się nie mylę, to jak to ma być opóźnienie, to nawet nie trzeba używać przerwań: można je wyłączyć przez SEI i pollować rejestr IRQST czekając na skasowanie bitu odpowiadającego danemu przerwaniu.