1,551

(60 odpowiedzi, napisanych Fabryka - 8bit)

Z mingw pewnie nie będzie problemu. Ale problem jest z tym rwaniem transmisji. Przyszło mi do głowy, że przyczyną może być to, na co się natknąłem na samym początku pod FreeBSD: za mała częstotliwość zegara schedulera. Na frebździe dało się ją łatwo zwiększyć i problemy minęły jak ręką odjął. Więc pytanie brzmi: czy pod Windows można jakoś zrobić to samo albo w jakiś inny sposób zapobiec wywłaszczeniom na dłuższe okresy. Bo APE jakoś przecież działa.

1,552

(60 odpowiedzi, napisanych Fabryka - 8bit)

Dla chętnych eksperymentalna wersja pod Windows: http://drac030.krap.pl/sio2bsd-win32.zip (skompilowana Cygwinem, ale działa również bez, niezbędne biblioteki są w środku).

Niestety, u mnie (na Win7) transmisja nie działa zbyt stabilnie, ciągle lecą jakieś błędy, nawet na 19200, nie mam pojęcia o co chodzi, a nie znam się na Windowsie ani Cygwinie na tyle, żeby cokolwiek nawet zgadywać.

Dobrze by było znaleźć jakiś przenośny (przynajmniej pomiędzy unixoidami) sposób na zaimplementowanie tego, o czym wyżej pisze mono, tzn. arbitralny dobór dzielnika częstotliwości na UART-a.

1,553

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

Sorry za podwójny post, ale: od dłuższej chwili nie mogłem się doliczyć, gdzie się podziewa ok. 40 cykli czasu w procedurze przerwania, która wg obliczeń powinna się wyrabiać, a się nie wyrabia. No i cóż: miałem błąd w przeliczaniu częstotliwości na wartość licznika Pokeya, dzięki czemu program grał za szybko (tzn. częstotliwość odtwarzania była większa niż powinna być). Po skorygowaniu tego wyniki się od razu polepszyły, tzn. np. max. częstotliwość odtwarzania na Pokeyu podskoczyła z 16 do 18,5 kHz.

Zapomniałem też napisać, że program przyjmuje parametry przez linię komend. UI jest wtedy nieaktywne. Parametry:

d2d [-m] fname.wav [fname2.wav fname3.wav ...] [addr]

gdzie:

* 'm' ma wartości z zakresu od 1 do 5 i wybiera "Replay mode" (takie jak pokazuje program przy uruchomieniu bez parametrów)
* 'fname*.wav' to pliki do odtwarzania. Jak widać można podać więcej niż jeden, powinny się wtedy odtworzyć po kolei.
* 'addr' to adres rejestru Covoxa (dla trybu -5)

Adres poprawionej binarki ten co powyżej.

EDIT: i dwa przykładowe wave'y, na 12 i na 16 kHz:

http://drac030.krap.pl/elitawav.zip

EDIT2: i wersja 0.8 pod tym adresem co powyżej. Chyba wyrabia 22 kHz na Covoksie (ale nie mam jak sprawdzić, czy rzeczywiście, w każdym razie się nie wiesza ani nie wylatuje komunikat, że disk too slow).

1,554

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

Odgrzewam temat. Nowe D2D, "przeportowane" na 6502 (na prośbę milionów użytkowników) i poprawione, jest do ściągnięcia stąd:

http://drac030.krap.pl/d2d6502.arc

W trybach odtwarzania 2 i 3 (WAVe'ów) program powinien się wyrabiać nawet na 16 kHz, acz to już na styk. Na Covoksie może pójdzie 19 kHz. Na 12 kHz wyrabia się z palcem. Procedury grające są oczywiście uproszczone do niemożliwości, tak więc zadanie zbyt dużej częstotliwości odtwarzania spowoduje zwis :)

Program w końcu (lepiej późno niż wcale) pozwala sobie zdefiniować adres rejestru Covoxa.

Skąd wziąć sample do testów:

1) bierzemy mp3 :)

2) przerabiamy na plik *.wav (np. mplayerem)

3) plik ten przerabiamy (np. programem Audacity) na 8-bit mono bez znaku z wybraną częstotliwością (np. 11 kHz)

4) kopiujemy sobie go na twardy dysk w Atari (program działa tylko z twardym dyskiem PBI, im szybszym tym lepszym)

5) gotowe

D2D automatycznie rozpozna nagłówek WAV i ustawi parametry odtwarzania, jeśli mu będą pasować.

1,555

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

Pin napisał/a:
jellonek napisał/a:

pin: mozesz konkretnie podac o ktora "reszte" ci chodzi? wymien z tytulow.


... no chyba Cię bóg opuścił, że z tego właśnie powodu podmienię vbxe z D6 na D7 i będę sprawdzał co i dlaczego nie działa. Dotknięcie czegokolwiek w tym kompie wymaga interwencji w NASA ;)-

Pin, nie musisz sprawdzać "dlaczego", wystarczy podać, co. Swoją drogą, warto byłoby mieć (tzn. ja bym chciał mieć) na takie okazje przełącznik na obudowie Atari, który przełączałby VBXE ze strony D6 na D7 albo odwrotnie. Oraz może jeszcze z jeden, który blokuje zapisy do rejestru konfiguracyjnego (przypadek Gyrussa na czarno).

1,556

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

Masz rację. Im więcej jest programów na FX tym mniejsze jest prawdopodobieństwo, że komukolwiek się będzie chciało *ręcznie* wybierać rdzenie przed uruchomieniem każdego kolejnego programu.

Offtopic: Rybags właśnie wypuścił kolejną gierkę, Spectipede. Jeśli chodzi o ilość tytułów, to chyba jest najwydajniejszym z koderów.

1,557

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

To pomysł mono. Poza tym to jedyny sposób, żeby uratować twoją koncepcję.

1,558

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

Na wyłączenie komputera przed zakończeniem programu lekarstwem jest defaultowy rdzeń, z którym VBXE będzie zawsze wstawać po włączeniu zasilania. To od biedy spowoduje, że nie trzeba będzie nic przywracać (tylko przełącznika szkoda).

Sprawdzenie rdzenia musiałoby zachodzić raz, przy ładowaniu programu, który z niego korzysta.

Co do biblioteki grafiki wektorowej, i że nie trzeba kolejnego rdzenia: to tylko tobie się tak wydaje. Sam jesteś niezadowolony z możliwości FX-a, a sądzisz, że wszyscy inni będą zadowoleni z rdzenia twojego pomysłu na tyle, żeby nie spróbować zrobić po swojemu czegoś, co potrzebują?

Co do reszty, sam widzisz, jak to komplikuje życie.

1,559

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

1,560

(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?

1,561

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

1,562

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

1,563

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

1,564

(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?

1,565

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

1,566

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

1,567

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

1,568

(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?

1,569

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

1,570

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

1,571

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

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

1,572

(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?

1,573

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

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

1,574

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

1,575

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

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