Emulator NES Qwen kompiluje logikę CPU Nintendo do około 1 GB wag

Projekt emulatora NES Qwen, nesformer, według swojego repozytorium umieszcza procesor Nintendo w 933 MB skompilowanych wag modelu. Jego demonstracje obejmują Super Mario Bros., lecz zewnętrzne oprogramowanie nadal rysuje ekran i obsługuje kontrolery. To rozróżnienie ma znaczenie: jest to eksperyment z programowanym obliczaniem wewnątrz architektury modelu, a nie chatbot uczący się gier Nintendo.

Deweloper Drew Breunig udostępnił projekt za pośrednictwem Hacker News, gdzie nagłówek opisywał działające Nintendo w około 1 GB wag Qwen. Repozytorium przedstawia węższe, a zarazem ciekawsze twierdzenie. Kompilator konstruuje logikę procesora, a generowane tokeny prowadzą jego wykonanie naprzód. Opublikowane wyniki wymagają niezależnego odtworzenia, ale projekt udostępnia kod i jasno określone ścieżki weryfikacji.

Punktem odniesienia jest Qwenputer, wcześniejszy eksperyment Divyansha Agrawala polegający na osadzeniu procesora w architekturze Qwen. Oba projekty stawiają twórcom systemów AI pytanie: które operacje powinny należeć do obliczeń modelu, a które do konwencjonalnego oprogramowania? Nesformer uwidacznia to pytanie poprzez znane gry, jednocześnie dokumentując istotne ograniczenia szybkości i kompatybilności.

Emulator NES Qwen uruchamia CPU, a host uzupełnia konsolę

Główne twierdzenie nesformer dotyczy procesora Nintendo i jego pamięci, a nie każdego komponentu kompletnej konsoli. Ta granica definiuje zarówno osiągnięcie, jak i jego ograniczenia.

Projekt podaje, że umieszcza rdzeń procesora 6502 konsoli NES wewnątrz checkpointu modelu zgodnego z Qwen, czyli zapisanej kolekcji parametrów modelu. Umieszcza również pamięć roboczą i dane programu z kartridża w zmieniającym się stanie wewnętrznym modelu.

Rozróżnienie między parametrami a stanem ma znaczenie. Parametry określają zachowanie maszyny; stan przechowuje informacje zmieniające się podczas działania gry. Nazywanie wszystkiego „wagami” sprowadza te różne odpowiedzialności do atrakcyjnego nagłówka.

Według projektu skompilowanego CPU model generuje tokeny, czyli dyskretne symbole wyjściowe, reprezentujące zapis wykonania procesora. Symbole te opisują operacje, a nie zwykły tekst konwersacyjny.

Program hosta zapewnia otaczające zachowanie konsoli. Renderuje grafikę, przetwarza dane z kontrolera i dostarcza zdarzenia związane z synchronizacją obrazu. Wejście i wyjście przekraczają tę granicę poprzez zapis wykonania.

Taki układ daje modelowi istotną rolę, nie umieszczając jednocześnie całego systemu Nintendo w jego wnętrzu. Sam ruchomy ekran ukrywałby ten podział. Opis architektury w repozytorium umożliwia jego sprawdzenie.

Implementacja procesora obejmuje wszystkie 151 oficjalnych opcode’ów, czyli zakodowanych instrukcji wskazujących procesorowi, jaką operację ma wykonać. Obejmuje arytmetykę, rozgałęzienia, flagi procesora i zachowanie stosu.

Udokumentowany układ pamięci obejmuje 2 KB roboczej pamięci RAM, którą działająca gra może zmieniać. Obejmuje również 32 KB pamięci ROM programu z kartridża, czyli zapisanych danych programu.

Program z kartridża jest ładowany do stanu, gdy rozpoczyna się wykonanie. W konsekwencji projekt podaje, że obsługiwane gry mogą korzystać z tych samych skompilowanych wag bez przebudowy procesora dla każdego tytułu.

To istotna różnica względem przygotowywania osobnej animacji dla każdej demonstracji. Zamierzonym artefaktem jest wielokrotnego użytku implementacja procesora o ograniczonym zakresie kompatybilności.

Opublikowany przykład Super Mario Bros. przedstawia łatwo rozpoznawalną scenę. Dołączone gry testowe stanowią bardziej użyteczny punkt wyjścia do weryfikacji, ponieważ ich pliki i informacje licencyjne towarzyszą projektowi.

Działania kontrolera mogą podążać za skryptem określającym moment naciskania przycisków. Udokumentowana sekwencja Mario rozpoczyna grę, przesuwa postać w prawo i wykonuje skok w zaplanowanych odstępach.

Nie jest to dowód, że agent AI nauczył się grać w Mario. To twierdzenie, że skompilowana logika procesora może wykonywać instrukcje gry przy otrzymywaniu zdefiniowanych wejść.

Rola Nintendo ogranicza się tu do celu sprzętowego i odniesienia do gry. Repozytorium przedstawia niezależny eksperyment, a nie produkt Nintendo ani zapowiedziane partnerstwo z Qwen.

Publikacja zmienia więc to, co deweloperzy mogą zbadać: publiczna implementacja łączy parametry modelu, zachowanie procesora i widoczny wynik gry. Jej znaczenie opiera się na tym możliwym do sprawdzenia połączeniu.

Skompilowana logika zmienia wymowę demonstracji dla AI

Istotnym mechanizmem jest celowa konstrukcja: skompilowane wagi nesformer kodują zachowanie procesora bez trenowania modelu, by samodzielnie je odkrył.

Trenowanie zwykle dostosowuje parametry za pomocą przykładów i procesu optymalizacji. Kompilacja tłumaczy określony projekt na inną wykonywalną reprezentację. Repozytorium nesformer podaje, że jego kompilator wylicza parametry bezpośrednio.

To odróżnia projekt od proszenia wstępnie wytrenowanego chatbota o naśladowanie procesora. Kompilator dostarcza reguły, a architektura modelu dostarcza aparat matematyczny, który je wykonuje.

Wyniku nie należy odczytywać jako dowodu, że konwersacyjny model Qwen potajemnie rozumie sprzęt Nintendo. Demonstracja nie dowodzi też, że zwykłe generowanie języka stało się dokładnym substytutem oprogramowania.

Zamiast tego bada, czy te same elementy architektury mogą wspierać celowo określoną maszynę cyfrową. Jest to pytanie o reprezentację i wykonanie, którego szersze implikacje nadal wymagają eksperymentów.

Kluczowym komponentem jest Gated DeltaNet, mechanizm modelu utrzymujący zmieniającą się wewnętrzną macierz pamięci. Nesformer wykorzystuje ten stan do przechowywania informacji maszyny pomiędzy kolejnymi generowanymi tokenami.

Jego projekt przypisuje lokalizacje pamięci do wierszy w tych macierzach. Starannie skonstruowane odczyty i aktualizacje pozwalają rejestrom procesora, pamięci roboczej i danym z kartridża zajmować te lokalizacje.

Rejestr, czyli niewielka lokalizacja pamięci używana bezpośrednio przez procesor, musi zachowywać dokładną wartość, dopóki instrukcja jej nie zmieni. Przybliżone odtworzenie doprowadziłoby do uszkodzenia wykonania.

Kompilator mapuje również dekodowanie instrukcji i arytmetykę na warstwy modelu. Przejście w przód, czyli obliczenie tworzące następne wyjście, przesuwa zakodowaną maszynę przez jej zapis wykonania.

Projekt informuje, że większość instrukcji wymaga jednego tokena. Niektóre potrzebują dłuższych zapisów, a udokumentowana średnia dla kodu gier wynosi od 1,1 do 1,3 tokena na instrukcję.

Ta zależność łączy znaną miarę wydajności modelu z konwencjonalnym obciążeniem obliczeniowym. Szybsze generowanie tokenów ma znaczenie, ponieważ sekwencja tokenów realizuje wykonanie procesora, zamiast jedynie opisywać je później.

Qwenputer zapewnił bezpośredni fundament techniczny. Opis obliczeń wewnątrz modelu Agrawala, opublikowany 22 października 2026 roku, opisuje kompilowanie logiki procesora i użycie stanu wewnętrznego jako pamięci.

Porównanie Qwenputer vs nesformer zaczyna się zatem od ciągłości. Nesformer ponownie wykorzystuje wcześniejszą technikę kompilatora i pamięci, następnie celuje w procesor NES i łączy go z zachowaniem hosta specyficznym dla konsoli.

Ich otaczające projekty różnią się. Agrawal opisuje zachowanie oryginalnych wag językowych Qwen przy jednoczesnym dodaniu mechanizmu obliczeniowego. Nesformer publikuje mniejszy checkpoint skupiony na procesorze, z odmiennym układem warstw.

To rozróżnienie zapobiega mylącemu wnioskowi dotyczącym rozmiaru. Pobranie nesformer nie dowodzi, że kompletny konwersacyjny model Qwen wraz z kompletnym Nintendo mieści się w rozmiarze sugerowanym przez nagłówek.

Ustala bardziej ograniczoną tezę: wybrane komponenty architektury Qwen mogą obsługiwać skompilowany projekt procesora. To, czy stanie się to użyteczne w ogólnych produktach AI, pozostaje otwartym pytaniem inżynieryjnym.

Konwencjonalne wykonanie pozostaje punktem odniesienia dla użyteczności

Nesformer tworzy alternatywę architektoniczną, lecz jego opublikowana wydajność pozostawia konwencjonalne oprogramowanie praktycznym standardem uruchamiania gier.

Bezpośrednie porównanie dotyczy wykonywania instrukcji w zwykłym kodzie emulatora i wyrażania ich wykonania poprzez operacje modelu. Widoczny rezultat nie przesądza, która droga jest użyteczna.

Emulator, czyli oprogramowanie odtwarzające zachowanie innej maszyny, ma tu już jasno określone zadanie. Musi dokładnie uruchamiać kompatybilne programy i dostarczać ich wyniki z akceptowalną szybkością.

Nesformer dodaje kolejny cel: wykonywanie procesora poprzez reprezentację parametrów zgodną z modelem. Cel ten wyjaśnia eksperyment nawet wtedy, gdy konwencjonalne wykonanie pozostaje wydajniejsze.

Repozytorium podaje około 1650 tokenów na sekundę dla domyślnego zoptymalizowanego silnika na jednym rdzeniu procesora. Dla prostszego silnika numerycznego podaje około 210.

Jego standardowa ścieżka Transformers ma według doniesień osiągać około 10 tokenów na sekundę. Transformers to biblioteka oprogramowania do uruchamiania modeli, używana do ładowania i wykonywania opublikowanego checkpointu.

Liczby te opisują różne ścieżki wykonania. Nie należy łączyć ich w jedno twierdzenie o wydajności standardowego modelu ani traktować jako kontrolowanego porównania na nieokreślonym sprzęcie.

Domyślny silnik pomija bloki, których parametry wynoszą zero. Ma to znaczenie, ponieważ większość parametrów checkpointu wynosi zero, co czyni jego strukturę wyjątkowo odpowiednią dla wyspecjalizowanego wykonania.

Repozytorium opisuje również pomijanie powtarzających się pętli bezczynności, gdy nie wykonują one zapisów do pamięci ani wejścia-wyjścia. Pętle te oczekują na następne istotne zdarzenie wyświetlania.

Optymalizacja ta ogranicza niepotrzebną pracę, lecz powinna należeć do każdego wyjaśnienia danych dotyczących szybkości. Host pomaga unikać powtarzania obliczeń, które nie zmieniłyby widocznego zachowania.

Nawet z tymi optymalizacjami projekt podaje działanie od 150 do 290 razy wolniejsze niż oryginalna konsola. Jego szacunek dla 600 klatek wynosi około 25 minut.

W udokumentowanym przykładzie te 600 klatek reprezentuje 10 sekund czasu NES. Demonstracja dotyczy zatem ostatecznego wykonania, a nie responsywnego zastąpienia normalnej gry.

To nakłada praktyczny ciężar na zwolenników obliczeń wewnątrz wag modelu. Muszą oni wskazać korzyści uzasadniające dodatkową pracę wykonawczą i złożoność integracji.

Potencjalne korzyści wymagają pomiaru, a nie założeń. Utrzymywanie operacji wewnątrz obliczeń modelu jest właściwością architektoniczną; nie poprawia automatycznie opóźnień, niezawodności ani użyteczności.

Bezpośrednia presja dotyczy twierdzeń badawczych i projektowania ewaluacji, a nie istniejących firm tworzących emulatory. Nesformer nie dostarcza dowodów, że konwencjonalnym emulatorom grozi wyparcie.

Deweloper rozważający podobny mechanizm powinien porównać kompletne ścieżki. Ładowanie stanu, postęp wykonania, obsługa wejść i odczytywanie wyjść wpływają na wynik, którego doświadcza użytkownik.

Porównanie Qwenputer vs nesformer wzmacnia potrzebę precyzji. Różne cele procesorów, komponenty otaczające i silniki wykonawcze uniemożliwiają proste rankingi oparte na rozmiarze checkpointu lub nagłówkowej przepustowości.

Na razie konwencjonalna droga zapewnia zarówno praktyczną alternatywę, jak i zachowanie referencyjne. Nesformer zasługuje na uwagę, ponieważ umożliwia zbadanie innej drogi, nie dowodząc jednak, że powinien zastąpić obecną.

Testy są bardziej miarodajne niż animacja Mario

Najmocniejszym dowodem jest wielowarstwowe porównanie projektu z zachowaniem referencyjnym, choć opublikowane wyniki nadal pochodzą od autora.

Animacja z gry potwierdza, że pojawiło się coś rozpoznawalnego. Nie ujawnia jednak, czy instrukcje wykonały się poprawnie, czy system referencyjny dostarczył korekt ani jakie oprogramowanie wygenerowało każdą klatkę.

Dokumentacja Nesformer rozdziela te kwestie. Opisuje testy procesora referencyjnego, skompilowanego obwodu, zapisanego punktu kontrolnego oraz dłuższych sekwencji wykonania.

Rozróżnienie zaczyna się od referencyjnego CPU, konwencjonalnej implementacji używanej jako oczekiwany wynik. Wadliwa referencja mogłaby sprawić, że zgodność wyników będzie mniej znacząca.

Repozytorium informuje o porównaniu tej referencji z nestest, testem zgodności procesora zawierającym oczekiwane zapisy wykonania. Twierdzi, że referencja odpowiada 3 348 instrukcjom w obsługiwanym zakresie.

Informuje również o porównaniu z py65, innym emulatorem procesora, obejmującym 5,7 miliona instrukcji kodu gry. Zapewnia to dodatkową weryfikację implementacji referencyjnej.

Skompilowany obwód otrzymuje następnie własne porównania. Dokumentacja zgłasza zgodność w nestest oraz dla 283 610 pozycji z sekwencji startowych dwóch gier.

Wyniki te dotyczą zachowania określonego obwodu. Same w sobie nie dowodzą, że zapisany model zapewnia identyczne wyniki we wszystkich silnikach wykonawczych.

Repozytorium zgłasza więc osobny test standardowych Transformers, obejmujący 2 651 pozycji z nestest i Full Game. Informuje o braku niezgodności w tej próbce.

Kontroler standardowego punktu kontrolnego pokazuje, jak działa to porównanie. Ładuje model, inicjalizuje stan maszyny i sprawdza przewidywane wyniki względem dostarczonej sekwencji referencyjnej.

Metoda ta wykorzystuje teacher forcing, czyli podawanie znanego poprzedniego wyniku na każdym etapie porównania. Testuje lokalne predykcje, nie ustanawiając równie długiego, nieprzerwanego autonomicznego uruchomienia.

Wykonanie swobodne zasila natomiast system jego własnymi wynikami. Błąd może zmienić późniejszy stan, więc zgodność w utrzymanej sekwencji odpowiada na inne pytanie weryfikacyjne.

Projekt zgłasza swobodne wykonanie Thwaite obejmujące 1 916 527 tokenów i 600 klatek. Podaje, że wszystkie 300 zapisanych klatek odpowiada wynikom referencyjnym.

W przypadku Full Game zgłasza 2 645 885 tokenów i 420 klatek. Dokumentacja mówi, że wszystkie 210 zapisanych klatek jest zgodnych.

Te liczby są konkretnymi twierdzeniami dotyczącymi dowodów, a nie uniwersalną gwarancją. Dotyczą określonych gier, sekwencji wejściowych, ścieżek wykonania i długości.

Testy weryfikacji procesora udostępniają automatyczne porównania dla referencji, obwodu, silników wykonawczych i optymalizacji pętli bezczynności. Ich dostępność umożliwia ukierunkowane odtworzenie wyników.

Czytanie testów różni się jednak od ich uruchamiania. Niniejsza analiza sprawdziła opublikowaną implementację i dokumentację; nie uruchomiła niezależnie punktu kontrolnego ani nie odtworzyła zgłoszonej wydajności.

To rozróżnienie powinno przetrwać dalsze przekazywanie informacji. Projekt dostarcza więcej dowodów niż niepoparte twierdzenie z mediów społecznościowych, ale publiczny kod i zgodność zgłaszana przez autora nie są równoznaczne z niezależną walidacją.

W przypadku emulatora NES Qwen kolejnym wiarygodnym krokiem byłoby szersze odtworzenie wyników z wyraźnie wskazanymi silnikami wykonawczymi. Większa animacja dodałaby mniej pewności niż udokumentowany zgodny ślad wykonania.

Nagłówek o 1 GB ukrywa zarówno rzadką reprezentację danych, jak i brakujący sprzęt

Rozmiar punktu kontrolnego jest rzeczywistym, zgłoszonym rozmiarem pliku, ale nie opisuje kompletnej konsoli ani całkowitego zapotrzebowania na pamięć podczas działania.

Repozytorium wymienia 466,6 miliona parametrów przechowywanych w bfloat16, formacie numerycznym wykorzystującym 16 bitów na wartość. Podaje wynikowy rozmiar parametrów na poziomie 933 MB.

Według dokumentacji tylko 9,3 miliona parametrów jest niezerowych. Projekt twierdzi, że ta regularność pozwala skompresować wagi do archiwum o rozmiarze 3,3 MB.

Są to różne wielkości. Pobrane archiwum, rozwinięty plik parametrów i pamięć zużywana przez uruchomiony proces odpowiadają na różne pytania operacyjne.

Przybliżony opis 1 GB w artykule dotyczy rozwiniętych wag. Nie powinien przekształcać się w twierdzenie, że kompletna aplikacja wymaga tylko tyle pamięci.

Rzadka struktura zmienia również interpretację wydajności. Wyspecjalizowany silnik, który omija bloki zerowe, wykonuje inną pracę niż implementacja przetwarzająca pełny układ parametrów.

Nie podważa to twierdzenia dotyczącego punktu kontrolnego. Oznacza, że zgodność, przechowywanie i efektywność wykonania wymagają odrębnych pomiarów zamiast jednego skompresowanego nagłówka.

Granica sprzętowa nakłada kolejne zastrzeżenie. Jednostka przetwarzania obrazu, komponent NES odpowiedzialny za zachowanie grafiki, pozostaje w oprogramowaniu hosta.

Jednostka przetwarzania dźwięku, sprzęt audio konsoli, również znajduje się poza wagami. Repozytorium podaje, że obecna implementacja nie generuje dźwięku.

Wierność grafiki także ma ograniczenia. Host renderuje linie skanowania, czyli poziome wiersze obrazu, i nie odtwarza efektów występujących w trakcie wiersza.

Dokumentacja opisuje również przybliżone zachowanie dla określonych warunków statusu sprite'ów. Sprite to osobno sterowany element obrazu używany dla postaci i innych poruszających się obiektów.

Obsługa kartridży jest ograniczona do NROM, prostego układu płytki bez przełączania banków programu. Przełączanie banków zmienia, do której części większego programu kartridża procesor ma dostęp.

Udokumentowany projekt Nesformer wykorzystuje stałą tablicę programu. Obsługa bardziej złożonych kartridży wymagałaby dodatkowego stanu i logiki wyboru adresów, a nie jedynie nowego tytułu na liście zgodności.

Ograniczenia wykonania wykraczają poza format kartridża. Nieobsługiwane nieoficjalne instrukcje zatrzymują system, a kod musi wykonywać się z pamięci kartridża, a nie roboczej pamięci RAM.

Projekt wymienia też brakujące zachowanie przerwań, czyli sygnałów powodujących reakcję procesora na zdarzenia sprzętowe. Niektóre obsługiwane zdarzenia działają, ale udokumentowany zakres jest niepełny.

Te ograniczenia kształtują znaczenie słowa „działający”. System może poprawnie uruchamiać określone gry w zdefiniowanym zakresie, pozostając nieodpowiednim dla szerszej biblioteki.

Uniemożliwiają również uogólnienie zgłoszonych testów na całe oprogramowanie Nintendo. Zgodność obsługiwanych instrukcji nie uzupełnia zachowania sprzętu, które implementacja wyraźnie pomija.

Skompilowane wagi nesformer najlepiej oceniać jako artefakt procesora połączony z częściową implementacją konsoli. Taki opis zachowuje nietypowy wkład projektu bez rozszerzania jego twierdzeń dotyczących zgodności.

Dla deweloperów użyteczne sceptyczne pytanie jest konkretne: które obserwowane zachowanie wynika ze skompilowanej logiki procesora, a które z założeń hosta? Repozytorium daje recenzentom punkt wyjścia.

Następne kroki to niezależne odtworzenie, szersza zgodność i szybkość całego systemu

Kolejne użyteczne dowody powinny zwiększać pewność, zakres pokrycia i zmierzoną praktyczność — w tej kolejności. Te sygnały są bardziej miarodajne niż kolejna fala zainteresowania.

Po pierwsze, warto obserwować niezależne odtworzenie opublikowanych porównań śladów wykonania. Wiarygodny raport powinien wskazywać punkt kontrolny, wejścia gry, silnik wykonawczy i metodę porównania.

Odtworzenie zachowania standardowych Transformers wzmocniłoby twierdzenie, że artefakt działa przez reklamowany interfejs modelu. Dłuższe swobodne porównania sprawdziłyby trwałą zgodność wykraczającą poza krótkie próbki zasilane referencją.

Niezgodność wymagałaby diagnozy, a nie natychmiastowego odrzucenia. Zachowanie numeryczne, inicjalizacja stanu, różnice między silnikami i nieobsługiwane funkcje to odrębne możliwe przyczyny o różnych konsekwencjach.

Po drugie, warto obserwować ulepszenia zgodności poparte testami zgodności. Dodatkowa obsługa kartridży byłaby znacząca, gdyby implementacja dokumentowała zachowanie pamięci i walidowała reprezentatywne programy.

Dźwięk i dokładniejsze taktowanie grafiki rozwiązałyby odrębne luki. Recenzenci powinni odróżniać przenoszenie większej części sprzętu do wag od ulepszania konwencjonalnej implementacji hosta.

Każda z tych zmian może poprawić aplikację, ale tylko pierwsza rozszerza zakres twierdzenia o obliczeniach wewnątrz wag. Jasne granice zachowają interpretowalność przyszłych porównań.

Po trzecie, warto obserwować kompletne pomiary wydajności na określonym sprzęcie. Użyteczne raportowanie obejmowałoby uruchamianie, wykonanie, pracę hosta oraz czas potrzebny do wygenerowania żądanej sekwencji gry.

Wzrost szybkości ograniczony do wybranego obliczenia wzmocniłby węższe twierdzenie. Szybsze kompletne wykonanie w obsługiwanych grach stanowiłoby silniejszy dowód praktycznego postępu.

Dyskusja deweloperska Breuniga przedstawia inną perspektywę na znaczenie projektu. Opisując rozwój wspomagany przez AI, przypisuje zasługi istniejącym materiałom referencyjnym, wcześniejszemu kompilatorowi i testom zgodności.

Przychylni komentatorzy podkreślali wartość tych kontroli referencyjnych. Sceptyczni uczestnicy kwestionowali efektywność tłumaczenia kodu na operacje modelu zamiast bezpośredniego wykonywania zwykłego kodu.

Żadna z tych reakcji nie rozstrzyga kwestii inżynieryjnej. Razem wskazują bezpośrednią wartość projektu: eksperyment z widocznymi wynikami, wyraźnymi granicami i zachowaniem, które inni deweloperzy mogą sprawdzić.

Dla inżynierów podkreśla to również wartość utrzymywania przeszukiwalnej bazy wiedzy zawierającej specyfikacje, implementacje referencyjne i dowody testowe. Taki materiał wspiera zarówno przegląd, jak i wdrażanie.

Ocenę emulatora NES Qwen zacznij od ścieżki weryfikacji, a nie od animacji. Porównaj to, co oblicza punkt kontrolny, z tym, co dostarcza host, a następnie przeanalizuj zgłoszone ślady wykonania. Traktuj rozmiar pliku, pamięć podczas działania i szybkość kompletnej aplikacji jako odrębne kwestie. Jeśli śledzisz projekt, szukaj niezależnych zgodnych uruchomień, zanim uznasz opublikowane wyniki za ustalone. Następnie obserwuj, czy zgodność rozszerza się dzięki przetestowanemu zachowaniu procesora i kartridży, czy głównie przez zmiany w otaczającym oprogramowaniu. Te rozróżnienia pozwalają deweloperom docenić eksperyment, a zarazem podejmować trafne decyzje o jego znaczeniu. Który kolejny wynik najbardziej zmieniłby Twoją ocenę: niezależne odtworzenie, szersze pokrycie sprzętu czy zmierzona redukcja czasu kompletnego wykonania?