Dokładnie, Sikor, olej czyjeś tam narzekania, jak mu za drogo, to niech sobie gdzie indziej kupi taniej i to koniec tematu.

Moje jedyne pytanie dotyczy .ds - czy jego działanie zostanie poprawione zgodnie z tym, co pisałem ostatnio mailem. Przeszkadza mi to, bo zamiast ".ds rozmiar" muszę używać ".byte" co niepotrzebnie zwiększa rozmiary binarki.

Od biedy możesz liczyć na buforowanie ścieżek, jeśli masz SDX (ale chyba nie ma tego w bieżącej wersji sterownika, trub będzie wiedział lepiej).

Co do błędów: chyba na razie nie wiadomo więcej, niż jest napisane tu: http://atariki.krap.pl/index.php/Indus_ … Bwietlacza

Może się mylę, ale wydaje mi się, że już 10 lat temu wszystkie części WDC chodziły na co najmniej 10 MHz, a poza tym 6521 różni się jakimś szczegółem konstrukcyjnym od 6520. Z punktu widzenia softu są w stu procentach identyczne.

Wracamy na chwilę do tematu: jak zauważyła innuendo, wersja plikowa nie działa zbyt stabilnie. Dotyczy to pliku również bez mojej poprawki, oraz w ogóle bez poprawek. Wersji Fandala nie sprawdzałem, bo jest spakowana, ale przypuszczam, że jest to dokładnie to samo, co wszyscy mają, tylko przepuszczone przez jakiś cruncher (i też nie działa na VBXE).

"Niestabilność" objawia się pojawianiem się na ekranie różnych śmieci podczas gry (tzn. zbędnych obiektów, często nieruchomych), trudnościami z przechodzeniem między etapami (mimo zabicia wszystkiego program jeszcze na coś czeka i trzeba rozbić własny statek, żeby ruszyło dalej) itp.

Przyczyną jest ta sama procedura, którą już tu dwa razy poprawiano. Ściągnąłem z atarimanii dump carta i się okazało, że zakres zerowania pamięci w oryginale wcale nie jest $C000-$E9FF (jak w rozpowszechnionym u nas pliku), tylko $0200-$E9FF. Innymi słowy, abstrahując od zerowania rejestrów I/O i cokolwiek bezsensownego zerowania ROM-u, gra przede wszystkim oczekuje, że wyzerowana będzie cała dostępna pamięć RAM.

Śmieci w RAM-ie są przypuszczalną przyczyną wspomnianych przeze mnie powyżej zakłóceń.

Wersja z poprawką to uwzględniającą (zrobiona na świeżo ze wspomnianego dumpa):

http://drac030.krap.pl/gyruss-fix.zip

Można sobie wyobrazić, acz ANTIC nigdy nie jest całkowicie "wyłączony", pewnie będzie trochę przeszkadzał (objaw: poziome rozciągnięcie obrazu z lewej strony).

Nie grzebałem w tej grze, ale z tego co kiedyś przypadkiem zauważyłem w jej środku ;) wygląda mi, że to jest tryb GR. 12 (czyli ANTIC 4). Być może jeszcze nieco podrasowany.

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.

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

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

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

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

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.