No tak, sorry, zaćmienie. Ale dalej nie rozumiem, po co zapisujesz jakieś wartości przed odczytem numeru wersji?

Poza tym, zdaje się, odczytanie $10 spod CORE_VERSION nie gwarantuje, że ta wartość jest tam utrzymywana przez VBXE, a nie coś innego.

Aha, czyli zapis zera do VIDEO_CONTROL nie ma związku z wykrywaniem. OK, ale moja wersja i tak jest lepsza, tzn. ona wykrywa VBXE, a nie przypadkowe urządzenie, które pod CORE_VERSION ma $10, oraz wykryje tez VBXE nawet, gdy wartość CORE_VERSION się w przyszłości zmieni :)

Tzn. czy FX czy nie? No, własnie nie bardzo wiem, czemu, skoro rdzeń GTIA nic nie daje ponad to, co mamy w GTIA, tzn. dla softu to zero różnicy, czy jest VBXE z rdzeniem GTIA czy normalne GTIA only.

Nie kumam. Jesli uzależniamy działanie programu od tego, czy jest FX, czy go nie ma, i w jakiej wersji, to wystarczy wykryć FX (<lans>moim sposobem</lans>), a potem odczytać CORE_VERSION, i już wiemy, co mamy. Jeśli FX sie nie da wykryć, to znaczy ze nie mamy jego możliwości do dyspozycji i tyle; niewazne, czy z powodu załadowania rdzenia GTIA w VBXE czy z powodu braku VBXE.

FX na pewno jest w tej chwili jedynym rdzeniem, który warto wykrywać, jesli program ma dodać jakies możliwości. Zapewne z tego powodu zostanie na długo standardowym rdzeniem VBXE, ale to szczegół[1]. Ważne jest to, że nawet jeśli powstanie więcej rdzeni, np. SuperCandle 3DFX core ;), to i tak pojedynczy program będzie pisany pod konkretny rdzeń, a nie pod pięć. Więc - dla konkretnego programu - wystarczy wykrycie tego własnie konkretnego rdzenia, right?

Wiemy już, jak wykryć FX, może ta metoda powinna być jakoś jeszcze ulepszona, ale na razie nie ma specjalnego powodu. Inne rdzenie, gdy powstaną, powinny zapewnić mozliwość specyficznego dla siebie wykrycia (albo zgodność wstecz z FX). Wtedy program, gdy będzie chciał skorzystać nie z "Electron FX", ale z "CandleSuper 3DFX", zaaplikuje metodę wykrywania tego drugiego i ewentualnie przeładuje rdzeń albo powie userowi, żeby to zrobił.

Natomiast problem z tym, że user ma VBXE, a soft mu mówi, że nie ma, bo załadwano zwykły rdzeń GTIA, jest rozwiązac bardzo prosto: poprawiając komunikat na "VBXE not present or no FX core loaded" :)

Po prostu nie bardzo widzę sens wykrywania czegoś, co zachowuje się tak, jakby tego nie było (czyli rdzeń GTIA VBXE). Mniej więcej tak, jakby chcieć wykrywać software'owo Freddy'ego.

Przypisy:

[1] dobrze by było, gdyby FX był takim standardem nawet jeśli będzie 15 innych rdzeni, bo w przeciwnym wypadku grozi nam, że każdy program będzie dystrybuowany ze stukilowym rdzeniem do sflaszowania...

No zgoda, totez napisałem, że może metoda wymaga ulepszenia. Mój sposób wykrywa rdzeń FX VBXE istniejący, i w razie, kiedy powstanie coś, co jest zgodne częściowo z FX, a nim nie jest, ten rdzeń zostanie wykryty jako FX. Temat jest otwarty, ale jednak częściowo zalezy od projektanta rdzenia "nie-FX", jak uniknąć takich konfliktów.

Za to twój sposób wykrywa rdzeń FX albo dowolne inne coś, co ma $10 pod CORE_VERSION.

Może po prostu uznać wartość CORE_VERSION za wartośc magiczną, gdzie $10 będzie oznaczało defaultowy FX, taki jak jest teraz, a każda inna, jakiś inny rdzeń, niekoniecznie kompatybilny. Np. $1x - FX lub rdzeń zgodny z nim wstecz. Każda inna wartość (albo brak MEMAC A): rdzeń niezgodny z FX. A?

Challenge/response jest zbyt upierdliwa. W takich zastosowaniach jak mówj driverek, muszę się zmieścić z kodem inicjującym w max. 768 bajtach, a już teraz zajmuje mi to 648. Koniecznośc negocjacji z mikrokontrolerem może sprawić, że się nie zmieszczę.

"FX" pod CORE_VERSION i CORE_VERSION+1 ma pewną wadę: nie przekazuje numeru wersji rdzenia FX (mało prawdopodobny, ale wyobrażalny jest rdzeń FX "plus", zgodny wstecz, ale jednak mogący cos nowego, przydałoby się go móc łatwo odróżnić od starego).

Już lepsza jest ta wartość, niech sobie CORE_VERSION = $10 oznacza FX (a kazda inna wartość - rdzeń niezgodny z FX), a CORE_VERSION+1 - numer rewizji. Tylko co na to electron, który ostatnio twierdził, że w FPGA miejsca brakuje, cytuję, "masakrycznie".

Poczekamy, co electron powie, jak dla mnie może być.

BTW. w ogóle nie bardzo wiem, po co jest rdzeń "GTIA only", skoro FX go zawiera w całości.

Co do przydatności, trudno mi cokolwiek oceniać, bo nie pisuję gierek. Może to się komus przyda.

Co do magicznego numeru na rozpoznanie FX-a: może po prostu $10 i $xx (w tym drugim miejscu dowolna inna liczba, obecnie $FF) będzie oznaczało FX? To nie wymaga interwencji electrona. A jeśli ktoś napisze nowy rdzeń, to mu FX nie będzie przecież miejsca zajmował i może ustawić pod CORE_VERSION dowolną inną liczbę.

Nie widzę w tym (w tej "dowolnej innej liczbie", bo jak mniemam do tego się odnosi twoje "a szkoda") nic złego, wystarczy stworzyć listę rdzeni razem z kodami identyfikacyjnymi dostepną publicznie (np. w Atariki) i po sprawie.

Nudzą mnie, nic na to nie poradzę :)

Proponuję rozpoznawać rdzenie po odczytanej z kontrolera vbxe nazwie. Np. FX10B8R. Tak jak robi to konfigurator.
Z kolei obecność vbxe po tym, czy wogóle kontroler odpowiada. Jest jeszcze nieszczęsne 6s startu, kiedy kontroler nie odpowiada.