Odp: VBXE, detekcja i dalsza obsluga
patrzaj wyzej
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
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.
zeby wyeliminowac przypadkowa wartosc, zero i tak wylacza ewentualne funkcje vbxe wiec kaszki sobie nie narobie, a odczytac to sie odczyta, to co potrzeba
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 :)
cud bi...
aczkolwiek - nadal malo to daje
wole jakis patent na wykrycie dokladnej wersji rdzenia - sam wiesz czemu...
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.
ale mamy fx in potentia!
tj ktos pracuje z gtia po boocie, na liscie rdzeni ma i fx'a
detectuje sobie vbxe - oho, jest, fajnie, no ale jaki rdzen? acha - taki, wersja? - acha, taka, ok, blitter dziala tak i tak - fajnie, xdl dziala w ten a ten sposob - niefajnie, przeladuj rdzen
jakie mam rdzenie w pamieci vbxe? acha, takie, ok, wybierz rdzen z banku x i zabootuj vbxe
jaki mam rdzen? acha, no to dzialam dalej...
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.
ale ty wcaz uparcie zakladasz ze fx jedynym rdzeniem jest
ponadto co odczytujesz z core_version? majora tylko, minor juz niet
sam zreszta zlapales sie na to, ze to nowy dodatek i przed tym, nie bylo nawet mowy o majorze
a poza tym co to za robota z niewykrywaniem vbxe jesli rdzen = gtia?
sory user, nie masz vbxe (user sie w tym momencie patrzy tepo w swoje kupione za ciezko zapracowane kupisze vbxe i na ekran w RGB ktory twierdzi ze nie ma vbxe) bo rdzen fx sie nie wykryl?
ta vbxe ktora dostalem dla delego defaultowo miala wybrany rdzen gtia, wiec pierwsze co trzeba bylo zrobic, to wgrac rdzen i zmienic aktywny na fx'a
jednorazowe?
nie sadze!
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...
Nie jest wazne, czy FX jest jedynym czy nie jedynym rdzeniem ktory warto wykryc, wazne jest to, ze to co wykrywasz, to rdzen ktory definiuje akces do swojej pamieci tak jak fx, nie musi byc FX'em
wolalbym odpytac pic'a/atmege o to, jaki rdzen zaladowala i jakie rdzenie ma na liscie i moze zaladowac, niz zabawa w ciuciubabke z rdzeniem, ktory moze posiadac czesc funkcjonalnosci/mechanizmow rdzenia fx, a nim nie byc
a co do standardu rdzenia fx - w tym momencie starszy soft (czytaj przyklady) nie dzalaja na nowym fx'ie bo sie blitter zmienil
i ta grozbe, ktora dostrzegasz - mozna wykozystac, a nie sie jej lekac
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?
Ostatnio edytowany przez drac030 (2009-04-13 14:15:46)
trzeba by poprosic electrona zeby zamiast na 0dx40 i 0dx41 bylo $10 i $ff pojawilo sie 'F' i 'X'
ale wole metode challage i resposne - vide odpytanie pomocniczego mikrokontrolera - w koncu konfigurator to robi
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".
w takim razie moze taki format:
40 - 10
41 - 07
major shr 4.minor
jesli cos jest <$10 to rdzen specjalny - np gtia only
edit:
co do braku miejsca:
jak oceniasz przydatnosc wykrywania kolizji miedzy overlayem a duchami gtia?
Ostatnio edytowany przez Candle (2009-04-13 14:30:14)
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.
gtia only jest bo powstal jako pierwszy
jest plan, by uczynic go opencore - tj z dostepnymi zrodlami jako devpack dla osob chcacych pisac nowe rdzenie
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ę.
a szkoda!
tymczasem electronu wroci dopiero wieczorem i pewnie nic madrego dzis nie napisze..
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.
sprecyzuje: szkoda ze nie piszesz gier
Nudzą mnie, nic na to nie poradzę :)
po co wykrywać kolizję między duchami GTIA a Overlayem? bardziej przydatna jest detekcja kolizji pomiędzy duchami Overlay
aktualnie problematyczna jest dostępność grafik 256 kolorowych i osób potrafiących taką grafikę spłodzić, albo brak czasu u takowych osób
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.
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.089 sekund, wykonano 10 zapytań ]