1,551 Odpowiedź przez drac030

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

xxl: nie, nie zgadzam się na przenosiny do innego wątku, zwłaszcza pod obraźliwym tytułem. Ale nie widzę przeszkód, żebyś się tam produkował.

xxl napisał/a:

przydaje ale w FX i wynika to z wady vbxe z FX jesli chcemy miec dostep do pamieci ekranu w jednym kawalku na raz to jedyny sposob a tak wlasnie sugerujesz tu:

To był przykład, nie przywiązuj się tak do niego. Lowres przydaje się też z innych względów, np. dlatego, że pamięć ekranu jest w ogóle o połowę mniejsza niż w stdresie (czyli można jej zmieścić więcej w VRAM-ie, jeśli komu to potrzebne); albo że bez kombinowania ma się rozdzielczość 160 albo 128 pikseli - jak wyżej, kompromis między jakością a wymaganiami pamięciowymi lub szybkościowymi ze strony Atari (np. szybkość ładowania danych z pamięci masowej).

Ręczne przełączanie rdzeni kładzie całą ideę na łopatki. Jeśli przed uruchomieniem każdego programu trzeba będzie ręcznie przełączyć rdzeń na inny (a niekoniecznie jest tak, że gdzieś tam ktoś trzeci nie myśli teraz o napisaniu swojego rdzenia do grafiki wektorowej na przykład), czyli uruchomić FC i zbootować nowy rdzeń rozwalając dotychczasową konfigurację (czyli np. SpartaDOS rezydujący w pamięci ext rdzenia R albo sterowniki siedzące w VRAM-ie), to jest to najlepszy powód, żeby pozostać przy FX-ie.

Idź do forum: Sprzęt - 8bit

1,552 Odpowiedź przez drac030

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

mono napisał/a:

po czym go łaskawie włączyć, a po zakończeniu działania przywrócić stary.

Razem z zawartością VRAM-u? :P

Ale ok, jeśli wypracuje się system, w którym przełączanie się między rdzeniami będzie w miarę automatyczne, tj. rozpoznanie bieżącego rdzenia, wybór wymaganego, boot, a potem przywrócenie i boot poprzedniego przed wyjściem z programu (ewentualnie rebootem), to nie miałbym zastrzeżeń.

Jest jedno ale: programiści mają problem z zapisaniem i przywróceniem wektora VBL - to sądzisz, że ci sami programiści nie będą mieli problemu z przywróceniem rdzenia VBXE?

Idź do forum: Sprzęt - 8bit

1,553 Odpowiedź przez drac030

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

xxl napisał/a:

dlatego rozpisywanie sie osob, ktore nie beda tego uzywac to tylko zaciemnianie tematu

Niezupełnie (i nie, nie pozbędziesz się mnie tak łatwo). Powstanie alternatywnego rdzenia automatycznie zmniejsza target dla obydwu, gdyż (wg tego co mówisz) część softu będzie chodzić tylko na jednym, a część tylko na drugim. Co automatycznie czyni korzystanie z VBXE upierdliwym (konieczność przełączania rdzeni, gdyż np. nie będzie już można uruchomić programu dla tego drugiego rdzenia spod DOS-u i konsoli, która wymaga rdzenia FX - i na odwrót).

ale do tego sie ustosunkuje:
> zauważ, to CPU, żeby można było uniknąć mapowania trybu do przestrzeni adresowej 6502, musiałoby być co najmniej złożoności normalnego procesora typu 6502 albo Z80. Już nie mógłby to być uproszczony procesorek pomocniczy, gdyż w takim wypadku konieczność mapowania VRAM-u do dostepu dla 6502 ciągle by zachodziła, a tu możność zmapowania jej w jednym kawałku - to zaleta.

dlaczego ograniczac mozliwosc mapowania?

Nikt tego nie proponuje - to właśnie ty twierdziłeś, że konieczność mapowania pamięci obrazu do przestrzeni adresowej 6502 to wada. Teraz, jak widzę, już tak nie twierdzisz. A więc tu się zgadzamy: tryb lowres się przydaje :)

Idź do forum: Sprzęt - 8bit

1,554 Odpowiedź przez drac030

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

xxl napisał/a:

a uporem maniaka wracam do tego conajmniej od wersji w ktorej pojawil sie memacA w takiej postaci jak jest teraz...

...

xxl napisał/a:

@draco30 z tym trybem 160 i jego zaleta, ze miesci sie w pamieci ktora bezposrednio moze adresowac 6502. przedstawiasz wade vbxe jako zalete. gdyby w vbxe byl cpu z dostepem do calej pamieci vbxe to nawet bys nie pomyslal o trybie 160.

Pomyślałbym, bo on mi się przydał wcale nie ze względu na to, że mieści się w pamięci. Przeciwnie, wystarczyło okno 8k. Ale możność zmapowania trybu grafiki bezpośrednio do pamięci, tak żeby miał do tego dostęp 6502 (dokładnie tak jak w przypadku trybów standardowych) *oraz* blitter, to jest zaleta, bo nie trzeba bankować RAM-u (przynajmniej dla mnie jest to zaleta, bo ja nie lubię bankowania).

"Gdyby w VBXE był CPU" - no ale nie ma. W standardowym Atari też wielu rzeczy nie ma, a jednak programy powstają, bo programiści umieją wykorzystać to co jest zamiast przykrajać sprzęt do własnych umiejętności/pomysłów.

Co do CPU, z twoich słów wynika, zdaje się, że dążysz do tego, żeby zrobić z VBXE oddzielny komputer - w takim układzie, zauważ, to CPU, żeby można było uniknąć mapowania trybu do przestrzeni adresowej 6502, musiałoby być co najmniej złożoności normalnego procesora typu 6502 albo Z80. Już nie mógłby to być uproszczony procesorek pomocniczy, gdyż w takim wypadku konieczność mapowania VRAM-u do dostepu dla 6502 ciągle by zachodziła, a tu możność zmapowania jej w jednym kawałku - to zaleta.

Ogólnie dyskusja jest akademicka, bo jak nadmienił electron, w rdzeniu nie ma miejsca na nowe rzeczy.

PS. Aha i jeszcze jedno:

powtarzam kolejny kolejny raz, nie chce zmieniac standardu ktorym jest FX. chce rdzenia 'na zlecenie' z funkcjami jak opisalem - byc moze jakiemus programiscie tez sie przyda...

Łatwym do przewidzenia skutkiem będzie to, że soft będzie wykorzystywał tylko to, co działa w obu rdzeniach. Albo nie będzie powstawał wcale (vide postawa tebego, ja szczerze mówiąc też już w pewnej chwili miałem dość, kiedy się okazało, że blitter zmienia się z wersji na wersję - na szczęście się ustabilizował i mi przeszło).

Idź do forum: Sprzęt - 8bit

1,555 Odpowiedź przez drac030

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

Jacques napisał/a:

Wystarczy proste ucięcie spekulacji, że od strony np. FX będzie 100% kompatybilności pomiędzy V1, V2, V3 i już każdy będzie szczęśliwy ;)

Też jestem za tym, tzn. za stabilizacją rdzenia. Ta nastąpiła kilka wersji temu, tzn. od 1.20 rdzenie robią to samo. I z tego co pamiętam, electron z candlem już parę razy "ucinali spekulacje", ale mimo tego, jak widać, xxl raz za razem wraca do tematu (chciałoby się napisać, że "z uporem maniaka").

Kontrowersję, w której ktoś chce coś z rdzenia usunąć, a ktoś inny (np. ja) uważa, że wszystko się tam może przydać i niczego usuwać nie trzeba[1], można rozwiązać tylko w jeden sposób: budując nową kartę z większym FPGA. Tylko że to oczywiście grozi nowym koncertem życzeń.

Co do V3, pamiętam że coś o tym było mówione, ale być może było to tylko taki chwilowy pomysł (chyba electrona ale głowy nie dam) i być może tylko w kontekście powiększenia miejsca na rdzeń VGA. Nie chcę tu rozsiewać plotek, więc przyjmijmy, że nic takiego nie zaszło.

[1] Też mi się kiedyś wydawało, że np. tryb lowrez (160 pix w 256 kolcach) jest niepotrzebny. Do czasu, kiedy mi się jednak przydał. Ma ważną zaletę: pamięć obrazu (w 160x192) zajmuje tylko 30 KB, przez co od biedy można ją w całości zmapować do pamięci Atari.

Idź do forum: Sprzęt - 8bit

1,556 Odpowiedź przez drac030

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

Ja osobiście jestem zadowolony z rdzenia FX takiego jakim jest, blitter mi odpowiada. Oczywiście fajnie byłoby mieć super-hiper MPU (wiadomo, że twór procesoropodobny byłby *zapewne* elastyczniejszy), ale nie zamiast blittera. Najwyżej oprócz. A na oprócz, jak wyżej napisano, nie ma miejsca.

Czy nie można z tym poczekać do (obiecywanej na ostatnich Głuchołazach) wersji 3.0 z większym FPGA?

Idź do forum: Sprzęt - 8bit

1,557 Odpowiedź przez drac030

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

Czy nie jest tak że:

1) w FPGA brakuje miejsca i było już tłumaczone, że nawet usunięcie blittera (skądinąd już używanego przez istniejący soft) nie zwolni go tyle, żeby zrealizować MPU?

2) zastąpienie blittera przez MPU spowoduje spadek wydajności, gdyż obecnie blitter potrzebyje 1 cyklu na odczyt bajtu i jednego na zapis, a MPU potrzebowałby jeszcze cykli na odczyt rozkazów?

Tak tylko pytam.

Idź do forum: Sprzęt - 8bit

1,558 Odpowiedź przez drac030

(13 odpowiedzi, napisanych Software, Gry - 8bit)

A sorry, nie zauważyłem. :)

Co gierka robi: na wstępie zeruje obszar od $C000 do $E9FF (czyli zeruje rejestry sprzętowe, ale trudno powiedzieć, po co z takim rozmachem). Patch ogranicza to do $C000-$D4FF - co polega na zmianie 1 bajtu.

Idź do forum: Software, Gry - 8bit

1,559 Temat przez drac030

(13 odpowiedzi, napisanych Software, Gry - 8bit)

Przynajmniej u mnie. Tzn. odpala się i słychać, że gra działa, ale niestety nic nie widać - czarny ekran. Co przypadkiem dziś odkryłem (innuendo chciała w to pograć). Binarkę mam od dely'ego.

Poprawiona wersja do ściągnięcia stąd:

http://drac030.krap.pl/pl-fixes.php

PS. Nie działało też z wsadzoną Spartą X, a przynajmniej z Maxflaszem 8. Poprawiłem to przy okazji.

Idź do forum: Software, Gry - 8bit

1,560 Odpowiedź przez drac030

(60 odpowiedzi, napisanych Sprzęt - 16/32bit)

marekp: a że tak z ciekawości zapytam, dlaczego nie chcesz tych doców (HYP, STG) odpalać na ST?

Idź do forum: Sprzęt - 16/32bit

1,561 Odpowiedź przez drac030

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

pilat23: no tak, TBXL ci się nie wgra, jeśli w pamięci jest kart Atari BASIC-a (a jest, bo Self Test daje 40 kwadratów). Może na początek napraw klawiaturę, jak Candle radzi, a potem zobacz, czy złe nie odeszło.

Idź do forum: Sprzęt - 8bit

1,562 Odpowiedź przez drac030

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

Candle: to nie jest "sprawa wtórna", skoro kolega utrzymuje, że po fizycznym odłączeniu klawiatury BASIC też się nie pojawia:

niestety po odlaczeniu calkowicie klawiatury jest to samo. Zielony ekran testu.

No chyba że odłączona klawka ma ten sam skutek, co wciśnięty OPTION - nie mogę teraz sprawdzić :)

Idź do forum: Sprzęt - 8bit

1,563 Odpowiedź przez drac030

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

Nie zawracaj sobie głowy testem, on nie sprawdza klawiatury an zawartości ROM-u.

Idź do forum: Sprzęt - 8bit

1,564 Odpowiedź przez drac030

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

Jeśli chodzi o klawiaturę, to jest to (o ile mi wiadomo) typowa przypadłość. Przez klawiaturę idzie zasilanie do czerwonej diody sygnalizującej włączony prąd (lewy donly róg klawiatury), w chińskich klawkach niestety powoduje to w końcu uszkodzenie folii dla klawiszy konsoli. Przypuszczam, że uszkodzenia START i RESET też się możesz wkrótce spodziewać.

Koledzy pewnie udzielą rad, co można z tym zrobić oprócz wymiany folii.

Gorzej z BASIC-em. Czy masz pośród programów jakiś DOS i Turbo BASIC XL?

Idź do forum: Sprzęt - 8bit

1,565 Odpowiedź przez drac030

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

Sprawdzisz w końcu te klawisze? Mam na myśli SELECT i OPTION.

Idź do forum: Sprzęt - 8bit

1,566 Odpowiedź przez drac030

(25 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

No tak, racja, Adam chciał DD. Ale on ma Falcona, DD czy HD, nie pamiętam, żeby była jakaś różnica inna niż taka, że DD nie dało się sformatować na 1,44 (acz bywały wyjątki i tu, por. sławne "sznurki"). Natomiast HD na 720k - jak najbardziej, czemu nie.

Idź do forum: Kupię / Sprzedam / Zamienię Atari

1,567 Odpowiedź przez drac030

(25 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Y, w sklepach nie ma? Jeszcze w zeszłym roku paczkę Verbatimów kupiłem w papierniczym.

Idź do forum: Kupię / Sprzedam / Zamienię Atari

1,568 Odpowiedź przez drac030

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

pilat23 napisał/a:

Klawisz option raczej dziala bo tylko wcisniecie start option razem wlaczenie i wylaczenie komputera daje dzwiek do wgrywania z kasety wiec option napewno dziala

Rozumiem: po prostu tego nie sprawdziłeś na żadnej grze.

@mono: chciałem odpisać dokładnie to samo, co pirx, alem został ubieżon...

Idź do forum: Sprzęt - 8bit

1,569 Odpowiedź przez drac030

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

No to wygląda na to, że masz po pierwsze zwaloną klawiaturę (klawisze SELECT i OPTION nie działają albo wykazują działanie szczątkowe - dlatego działają ci w grach, jak twierdzisz). A po drugie, jak już jellonek napisał, przypuszczalnie kaszanę zamiast BASIC-a w ROM-ie - dlatego READY się nie pokazuje nawet przy odłączonej klawiaturze.

Idź do forum: Sprzęt - 8bit

1,570 Odpowiedź przez drac030

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

"Podświetlenie ustawione na memory, ale nic się nie da zrobić" - czy to podświetlenie miga?

Idź do forum: Sprzęt - 8bit

1,571 Odpowiedź przez drac030

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

Ale klawisze START/SELECT/OPTION ci działają w ogóle? Możesz to łatwo sprawdzić, bo gry się wczytują.

Idź do forum: Sprzęt - 8bit

1,572 Odpowiedź przez drac030

(20 odpowiedzi, napisanych Scena - 16/32bit)

grey/msb napisał/a:

32 lata dzisiaj mi stuknęły...

Wszystkiego najlepszego... btw. to tacy młodzi już mówią? :P

Idź do forum: Scena - 16/32bit

1,573 Odpowiedź przez drac030

(8 odpowiedzi, napisanych Software, Gry - 16/32bit)

jury: wywal nfs.xfs, jeśli go masz :)

Idź do forum: Software, Gry - 16/32bit

1,574 Odpowiedź przez drac030

(60 odpowiedzi, napisanych Fabryka - 8bit)

xxl napisał/a:

no wlasnie nieprawda, cala rozmowa sie wlasnie zaczyna od tego (w moim rozumieniu) obsluga filesystemu na zewnatrz a nie po stronie atari liczyc sektor xxx pozniej oblicz kolejny adres sektora, zaladuj xxx a pozniej jeszcze yyyy

> Obchodzi, jeśli ma pamięć masową, do której nie sięga wyobraźnia autora programu (e.g. całodyskowy SynFile vs stacja 720k).

nie! przykladowo siegam do bajtu yyyy otwartego pliku a nie obliczam gdzie ten bajt lezy czaly czas pamietajac jaki jest filesystem, laduje sektor i dopiero dana yyyy. !!!

No i tu własnie fundamentalnie błądzisz, bo DOS jest po to, żeby nie trzeba było (= żeby program użytkownika nie musiał) pamiętać, jaki jest filesystem, ani liczyć sektorów. Fakt, że niektóre DOS-y tego nie zapewniają świadczy tylko o tym, jak są prymitywne i gdzie powinny wylądować. Na szczęście Atari jest tak zrobione, że można sobie DOS wybrać.

eeee, ladujac do podstawowej pamieci atari w tych adresach to sie nic nie stanie ale jesli zaladujesz do pamieci vbxe w tych adresach to zwis... w pierwszym i drugim przypadku nie ma tam programu sdx, niestety to bug do poprawy.

Jak już o tym była mowa, to nie jest żaden bug, SDX nie będzie poświęcać ~40 cykli przy _każdym_ przełączeniu banków (a robi to _bardzo_ często) na zachwywanie stanu MEMAC A, skoro bez większego wysiłku (i tylko przy ładowaniu danych) może to zrobić sam program.

Idź do forum: Fabryka - 8bit

1,575 Odpowiedź przez drac030

(60 odpowiedzi, napisanych Fabryka - 8bit)

xxl napisał/a:

oczywiscie, sterownik taki moze zajac z 2kb ramu i moc obsluzyc rozne rodzaje nosnikow, rozne wielkosci, ramdysk, alokacje pamieci, nowe funcje (nie tylko pamiec masowa), byc odpornym na zmiane filesystemow

Opisujesz SpartaDOS X. Niestety, tego (zwł. obsługi ramdysku i alokacji pamięci, buforów I/O) raczej się nie zmieści w 2 KB. Sama obsługa tego protokołu to nieco ponad 1 KB kodu, a to nie jest "goły" moduł, tylko sterownik obudowany całym DOS-em (który np. załatwia wyżej wspomniane buforowanie).

Dodam że SDX jest tak skonstruowane, że od biedy można byłoby w ten sposób w ogóle przekierować całą obsługę dysków na zewnątrz przez taki sterownik. Tylko nie ma po co, lokalny twardy dysk jest o wiele lepszy.

xxl napisał/a:

co usera obchodzi jak skladowane sa dane?

Obchodzi, jeśli ma pamięć masową, do której nie sięga wyobraźnia autora programu (e.g. całodyskowy SynFile vs stacja 720k).

xxl napisał/a:

daleko szukac, to tez jest wada, zalozmy ze konfiguruje memacA na $4000 i przeprowadzam ladowanie do pamieci VBXE... oooopsss, sparta sie zawiesila :( potrzebna aktualizacja dosa

Nie, po prostu musisz uważać, gdzie i jak ładujesz dane. Przy ładowaniu tak samo nie możesz nadpisać inicjalizera, wektorów przerwań, rejestrów I/O - a przy twoim pomyśle, sterownika oraz "zaalokowanej pamięci", którą ma on wg ciebie serwować. Przy ładowaniu danych pod ROM też trzeba to robić w określony sposób (mimo że tych sposobów może być kilka). Więc takie uważanie to (nie powinno być) nic nowego. Ot takie podstawy tego, co powinien umieć koder.

Idź do forum: Fabryka - 8bit