2,151

(17 odpowiedzi, napisanych Programowanie - 8 bit)

Nie musisz XDL przepisywać, wystarczy mieć dwie (albo pięc, albo ile tam) i zmieniać wskaźnik.

2,152

(25 odpowiedzi, napisanych Bałagan)

Lt_Bri napisał/a:

To ja się może spytam tak, co z takiego - http://tiny.pl/zrwr - urządzenia można wydłubać i wstawić do atarki ew. jakiejś "przystawki" do atarki?

SID-a możesz wydłubac, reszta raczej się nie nada do Atari.

2,153

(25 odpowiedzi, napisanych Programowanie - 8 bit)

tebe napisał/a:

można te 16KB bloki spakować

To taki specjalny ficzer, żeby się dłużej ładowało. Nostalgia za XC12 itd.

Co do ściezki, nie potrzeba podawać pełnej, jeśli egzek ładujący i plik danych są w tym samym katalogu, to wystarczy podać "D:nazwapliku".

2,154

(55 odpowiedzi, napisanych Programowanie - 8 bit)

Drugiego bajtu magicznego nie musisz specjalnie wsadzać, wystarczy przyjąć, że $10, $FF = rdzeń FX. Jeśli ktoś zrobi inny rdzeń, to na pewno starczy mu miejsca na inny bajt magiczny.

2,155

(55 odpowiedzi, napisanych Programowanie - 8 bit)

Napisałem wyżej:

1) jest to długie

2) nie widzę sensu

Kompletnie nie rozumiem, w czym skomplikowany odczyt stringu "FX108RB"... czy jak tam, jest lepszy od prostego odczytu dwubajtowej wartości magicznej spod konkretnych dwóch adresów. Zamierzamy mieć więcej niż 65536 rdzeni?

2,156

(55 odpowiedzi, napisanych Programowanie - 8 bit)

electron napisał/a:

Proponuję rozpoznawać rdzenie po odczytanej z kontrolera vbxe nazwie. Np. FX10B8R. Tak jak robi to konfigurator.

Nie, to masakra. Po co tak komplikować?

2,157

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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

2,158

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,159

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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ę.

2,160

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,161

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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".

2,162

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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?

2,163

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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...

2,164

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,165

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,166

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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 :)

2,167

(55 odpowiedzi, napisanych Programowanie - 8 bit)

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.

2,168

(55 odpowiedzi, napisanych Programowanie - 8 bit)

beq. Ten warunek nigdy nie będzie spełniony, pod $dx40 masz $FF, chyba że czegoś nie wiem.

2,169

(55 odpowiedzi, napisanych Programowanie - 8 bit)

A po co wykrywać core GTIA?

Co do detekcji FX: http://atariki.krap.pl/index.php/Wykrycie_VBXE

Twojej procedury nie rozumiem, co robi makro (czy też pseudorozkaz) bre?

Poza tym odczyt spod $dx40 zawsze ma dawać $FF wg instrukcji VBXE, a bez VBXE też, więc nie bardzo wiem, jak to ma działać...

2,170

(40 odpowiedzi, napisanych Programowanie - 8 bit)

Fajne, fajne... zaraz obejrzym i skrytykujem ;)

EDIT: nie no, luksus, teraz tylko zrobić z tego biblioteczkę do wkompilowania do własnego programu i można działać.

2,171

(10 odpowiedzi, napisanych Sprzęt - 8bit)

zaxon napisał/a:

3. Skoro pracujecie nad sdx to rownie dobrze mozna dolozyc myide, khym khym

Przecież ci tłumaczę, jak chłop krowie na rowie, że to by oznaczało kolejny, piąty build (oprócz intSDX, TF i dwóch Maxflaszy), a czasu ledwie starcza nam na te cztery. Jakbyś nie wiedział, one się trochę różnią kodem, miejsca na karcie już prawie nie ma, a wszystko (toolsy na CAR: tzn.) trzeba ręcznie upychać, wobec czego synchro wszystkich zajmuje czasem kilka godzin. Krótko: nie, nie "równie dobrze", oznacza to kawał dodatkowej roboty.

4. bo maja i uzywaja jako prostego wgrywadelka a to moze wiecej jakby sie specjalisci zabrali

To nie moja wina. Jak podepniesz twardziel przez port joya, bo tak taniej, to też będziesz chciał, zeby wszystkie DOS-y poprzerabiać pod to? Przecież to jest crazy.

Zresztą, był gość, który chciał napisać sterownik MyIDE pod SDX, ładowany tak jak RAMDISK.SYS. Ale jakoś mu się zwiędło in the process.

5. Drac030 staram sie sam dochodzic do rozwiazan i nie chce truc glowy bez potrzeby ale fajnie by bylo to jednak jakos zgrac, sdx int siedzi pod d5xx podobnie jak myide i tu jest tez kolizja

Przecież nikt mu (autorowi MyIDE) nie kazał tego robic tak, żeby z niczym nie działało. Zrobił, to niech teraz supportuje.

PS. Wersja "wewnętrzna" MyIDE siedzi na $D1xx, więc nie "koliduje" (tylko ROM z OS-em trzeba wymienić jak wyżej). Support dla wersji kartridżowej w ogóle odpada.

PS2. Dopiero teraz zajrzałem do wskazanego przez ciebie wątku. Ten Kyle to autor sterownika, nigdy go nie doprowadził do końca, bo mu sie MyIDE zepsuło, kiedy słyszałem o nim ostatni raz, chciał sobie fundnąć IDEa. Inny z posterów, bfk+, ma MIO, a MyIDE zapewne wyrzucił do kosza... no i tak to pewnie jest z tą większością, dwa lata temu MyIDE to był na AAge główny temat, a teraz od bardzo dawna panuje cisza.

2,172

(10 odpowiedzi, napisanych Sprzęt - 8bit)

zaxon:

1) ideolo: SDX nie trzeba dostosowywać do współpracy z żadnymi pamięciami masowymi, które są zrobione jak należy, vide: (w kolejności starszeństwa) MIO, BlackBox, KarinMaxi, KMK/JŻ IDE. Niech więc autor MyIDE "dostosuje" swoje "rozwiązanie" do obowiązujących standardów, a wszystko będzie działać jak należy.

2) wzgląd praktyczny: ani trub ani ja nie mamy MyIDE i ja nie zamierzam, a o ile mi wiadomo, trub również nie, tworzyć kodu bez możliwości jego przetestowania na miejscu.

3) wzgląd jeszcze bardziej praktyczny: w tej chwili mamy 4 buildy SDX, których synchronizacja zajmuje zwykle kupę czasu, wobec czego nie zamierzamy dodawać sobie piątego.

4) polityka społeczna: czytam prawie codziennie AAge i jakoś o MyIDE od jakiegoś czasu słuch zaginął, więc nie przejmowałbym się rzekomą "większością"

5) żebyś nie pozostał taki kompletnie bez pomocy: jak wymienisz ROM na "MyIDE OS" (czy jak się to tam nazywa), to SDX powinno działać, jeśli załadujesz sterownik SIO z opcją /A (DEVICE SIO /A w CONFIG.SYS - pod 4.42) :)

tebe napisał/a:

jeśli IOBoard Candla pozwoli na transfery większe niż 19200 można pokusić się o bardziej rozbudowany sposób łączenia Atari z PC, np. Atari będzie robić za terminal a obliczenia przejmie PC

No ale po co, skoro terminal można zapuścić na emulatorze :P

nosty napisał/a:

Na real Atari to jednak sporo trudniejsze...

E tam. Kwestia odpowiednich toolsów. Pewnie, że jakbym miał gołe 800XL + XC12, to bym tak robił, ale na atarce spoko się da wygodnie kodować, trzeba tylko chcieć (a nie, jak niektórzy, przykleić się do nieużywalnego QA i z tego powodu prędzej przesiąść się na peceta niż na lepszy asembler).

nosty napisał/a:

Za odpowiedź: "pisz se pod Atari" dziekuje od razu swiatecznym "Bóg zapłać" ;P

A co jest żłego w pisaniu na Atari? To np. http://atariki.krap.pl/index.php/The_Fi … _Processor jest bardzo wygodny edytor. A ostatnio istnieje tez The Last Word http://www.atari8.co.uk/lastword/lastword.htm dość podobny, tylko lepszy...