401

(24 odpowiedzi, napisanych Programowanie - 8 bit)

Znalazł się! Przykład skrolowania MWP wrzucił kiedyś na AtariAge Analmux, ale później go skasował. Ale wczoraj wrzucił go tam ponownie. W załączonym ZIP-ie MWP jest użyte w demku "Super Mario Clone & Hardsynth Tune". Źródeł nie ma, więc pozostaje Ci analiza pod monitorem w emu.

402

(52 odpowiedzi, napisanych Emulacja - 8bit)

jury napisał/a:

(...) a, i dlaczego uważasz że nie będzie dzwięku? nie wystarczy wywalić --disable - sound z tamtej linijki? :D

Tak, wystarczy, ale może Petr celowo to tam dodał, bo np. z dźwiękiem się nie kompilowało. Sprawdź :)

jellonek napisał/a:

no jakis czas temu wypadlem z listy (serwer na ktorym odbieralem maillisty padl na pol roku) ale moze ponownie sie dopisze i przynajmniej pod debiana poprawki zapodam

Dzięki, przydałoby się.

403

(52 odpowiedzi, napisanych Emulacja - 8bit)

Mono, Cosi, dziękuję.

Cosi napisał/a:

2. a) bez problemu się zmienia; przy okazji zauważyłem, że tryb 1280x800 to nie jest 1280x800, tylko coś mniejszego (pewnie dlatego, że mam "maintain aspect ratio 4:3"), ale ten tryb najbardziej mi pasuje; największy to 1024x768 (oryginalna rozdziałka mojego LCD to 1280x800)

Czyli masz monitor o proporcjach 15:10? Jeśli tak to powinieneś na taką wartość ustawić opcję "Host display aspect ratio". Wtedy opcja "Keep aspect ratio=authentic" (polecam) będzie działać poprawnie. W tej chwili zapewne masz "Keep aspect ratio" ustawione na "1:1" czyli kwadratowe piksele.

Cosi napisał/a:

3. rozdzielczość zmienia się skokowo; przy powiększaniu okna są problemy z przejściem do trybu 1280x800 (czasem nie wskakuje); po zmaksymalizowaniu zawartość okna cyklicznie mruga

Skokowe powiększanie wynika z tego, że opcja "Stretch" jest ustawiona na "fit screen - integer". Oznacza ona, że wysokość okna jest zawsze równa wielokrotności 240 pikseli. Spróbuj przestawić na "fit screen - full".
Co do tego mrugania: czy podczas mrugania pojawia się coś na standardowym wyjściu?

Cosi napisał/a:

4. w oknie Basica - w trybie turbo 360% (nie działa dźwięk), bez turbo 66-80%, zauważalne opóźnienie kliku klawiszy; w tle chodził Firefox; przełączanie akceleracji nie zmienia tych wartości
Self Test - w trybie turbo 360%, bez turbo 44-51%
(...)
POPRAWKA:
Nie wiem, czym było spowodowane to ślimaczenie się emulatora. Po restarcie nawet przy uruchomionym FF wyniki są takie (testy na grze Hans Kloss :D):
bez akceleracji:
normal - 102%, turbo - 340%
z akceleracją:
normal - 102%, turbo - 120%

Ciekawe. Zupełnie jakby emulacja dźwięku spowalniała emulator. Może przyczyną była inna aplikacja odtwarzająca dźwięk?

jury napisał/a:

Chciałbym sobie wersję 2.1.0 skompilować pod TOSa na MC68060. (...) Co to oznacza, jakoś mi tak "brzęczy" żeby to "puścić" zamiast ./configure?

Tak, zamiast ./configure i make. Ale do wersji falconowej to chyba nikt dawno nie zaglądał, nie wiem nawet czy to się skompiluje. A poza tym, i tak nie będzie dźwięku.

jellonek napisał/a:

paczka pod debiana sie nie buduje jak trzeba (ze wzgledu na to ze x11 i curses nie buduja sie, ze wzgledu na brak wsrod linkowanych plikow funkcji obslugujacych sound)...
inna sprawa ze control file tez dosc mocno zaniedbany ;)

Oj przydałyby się ręce do roboty :) Target X11 dawno już powinien być deprecated.

404

(52 odpowiedzi, napisanych Emulacja - 8bit)

No to w ramach podziękowań mógłbyś przetestować działanie akceleracji OpenGL w emulatorze :) i dać znać czy coś się sypie.

1. Jeśli w menu brakuje opcji "Display settings -> Video mode settings -> Hardware acceleration", to znaczy że podczas configuracji/kompilacji nie było zainstalowanych plików nagłówkowych OpenGL. Pakiet nazywa się libgl-mesa-dev czy jakoś tak (jak używasz non-free sterowników graficznych, to należy zainstalować odpowiednio inny pakiet).
2. Ustaw ww. "Hardware acceleration" na "On" i pobaw się dostępnymi opcjami w menu "Video mode settings", przede wszystkim:
a) "Fullscreen resolution"
b) "Fulscreen: Yes/No" (Alt+F)
c) spróbuj też poprzełączać "Hardware acceleration" kilka razy - doszły mnie słuchy że się sypie na niektórych kartach graficznych.
3. W trybie nie-fullscreen pobaw się zmianą rozmiaru okna.
4. Włącz "Display settings -> Show percents of Atari speed" a następnie włącz Turbo (F12) i zobacz ile procent prędkości wyciąga emulator. (Uwaga: w zależności od karty graficznej na wynik może mieć wpływ włączenie/wyłączenie synchronizacji pionowej w xorg.conf.)

405

(52 odpowiedzi, napisanych Emulacja - 8bit)

Cosi napisał/a:

(...) tak jak pisałem - problem powtarza się również w wersji 2.0.3, która przed reinstalacją działała prawidłowo.

Rozumiem. Przyczyny moga być różne - ja podejrzewam że zaszła jakaś zmiana w sterownikach dźwięku ALSA, która spowodowała "zmniejszenie" tolerancji na błędy w Atari800. Miałem taką sytuację na swoim SoundBlasterze 128PCI jakieś 2-3 lata temu - po aktualizacji jądra dźwięk w A800 zaczął się sypać.

BTW jaką masz kartę dźwiękową?

Cosi napisał/a:

Na dodatek ta sama wersja 2.0.3 w wersji dosowej (pod Dosboksem) działa bez problemów.

W każdej wersji emulatora (SDL, DOS, X11) podystemy dźwięku dzielą stosunkowo mało kodu - więc akurat takie testy niewiele mówią, niestety.

Cosi napisał/a:

Dlatego właśnie wydawało mi się, że może coś jest nie tak z SDL, ale jeżeli tak, to dziwi mnie cisza na ten temat w Internecie - nie znalazłem ani jednego posta na temat jakichkolwiek problemów podobnych do moich.

Atari800 w ogóle mało kto używa.

Cosi napisał/a:

Tak czy inaczej, może w wolnej chwili spróbuję skompilować najświeższą wersję. Będę do tego niestety potrzebował paru browarów, bo make ma na mnie uczulenie i jeszcze nigdy nie zdarzyło mi się nim niczego skompilować bez niespodzianek.

Zainstaluj pakiety autoconf, libsdl1.2-dev, no i oczywiście gcc i libc6-dev (chyba o niczym nie zapomniałem) i powinno być OK.
Potem:
cd atari800/src
./autogen.sh
./configure --target=sdl --enable-seriosound
make
i możesz uruchamiać emulator:
./atari800

406

(52 odpowiedzi, napisanych Emulacja - 8bit)

Ale MIDI (Adlib/SoundBlaster, nie mówię o General MIDI) jest w DB emulowane i przechodzi przez podsystem dźwięku SDL. Poza tym DN3D sampli też używa. Więc wskazówka jednak adekwatna.

Cosi, ja bym sugerował ściągnięcie i kompilację najnowszej wersji Atari800 z CVS-a (pytaj o pomoc bez krępacji) i sprawdzenie czy tam jest wszystko dobrze. Od czasu wydania wersji 2.1.0 system dźwięku został poważnie zmodyfikowany, poprawiono sporo błędów (np. poprawnie działa odgrywanie sampli :) ), więc pewnie i Twój błąd nie będzie już występował.

407

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

XLFriend również.

408

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

Invasion (Bulldog Software).

409

(24 odpowiedzi, napisanych Programowanie - 8 bit)

MWP opiera się na podobnej idei, co "zwykłe" scrollowanie. Normalnie mamy obszar 4KB pamięci "zawijający się" (znana właściwość ANTIC-a). Załóżmy że mamy displaylistę z 1 rozkazem LMS na początku i HSCROL+VSCROL włączonym we wszystkich liniach. Dzięki własności zawijania się, przy przesuwie w dowolny z 4 kierunków wystarczy że zmienimy adres w LMS o +1/-1/+48/-48 (zakładając zwykłą szerokość ekranu) i wkopiujemy w pamięć ekranu 1 kolumnę albo 1 wiersz danych. Nigdy nie trzeba wkopiowywać za jednym razem danych całego ekranu. Problemem jest tylko to, że marnujemy 4KB RAM podczas gdy na ekranie wyświetlany jest tylko ~1KB (25*48B).

Idea MWP jest taka, żeby dodać jeszcze 1 rozkaz LMS do displaylisty, aby zasymulować w ten sposób zawijanie się pamięci ekranu nie co 4KB, tylko np. co 1KB (można wybrać dowolną wartość), aby nie marnować RAM-u. Położenie tego rozkazu LMS w displayliście będzie się zmieniać w miarę scrollowania. Ot i cała filozofia.

xxl napisał/a:

z tego co zrozumialem to element graficzny 'klocek' moze byc maksymalnie 2 bajty szeroki?

Nie ma żadnych ograniczeń tego typu. Gdzie to wyczytałeś?

410

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

Bajtek 2/91, s.10:
"Nieco bardziej różnią się od siebie stacje dysków stosowane do ?małych" Atari. Jest ich wiele, więc zajmę się tylko tymi, które występują w Polsce w większych ilościach. Są to: Atari 1050, Atari XF551, LDW Super 2000, California Access 2001 oraz będąca jeszcze w opracowaniu California Access 2002."

Autor - oczywiście Zientara.

Zachodzę w głowę, w jaki sposób stacja będąca w opracowaniu występuje gdziekolwiek w większych ilościach.

411

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

Panie, pics or it didn't happen.

412

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

A to CA2002 w ogóle istnieje?

413

(24 odpowiedzi, napisanych Programowanie - 8 bit)

Ciekawym sposobem skrolowania jest "MWP". Omija problem granicy 4KB, display list zawiera tylko 2 LMS-y (z czego 1 "ruchomy"), nigdy nie trzeba kopiować całego ekranu a tylko 1 wiersz/kolumnę, a pamięć ekranu zajmuje 25*48 bajtów.

414

(27 odpowiedzi, napisanych Programowanie - 8 bit)

nosty napisał/a:

Myslalem ze emulatory (przynajmniej A800win) sa juz prawie perfekcyjne... Sie tak dziwie, bo znam pewnego programiste Atari, z naprawde scislej czolowki, ktory nie ma real Atari i koduje swoje najlepsze gry na emulatorach :wink:

Atari800WinPLus? Kulą w płot żeś trafił, jest to najmniej dokładny emulator z dostępnych. Przesiądź się na bardzo dokładną Altirrę.

Teraz jest 13:52. O 13:11 wysłałem posta w tym wątku (korzystając z pola "Szybka odpowiedź"). Godzina widoczna przy moim poście jest poprawna (zakładając że mam dobrze ustawioną strefę czasową w profilu).

Chwilę później (dokładniej mówiąc, o 13:43) zauważyłem, że w innym wątku pojawił się post Candle'a z godziną 14:43, a w jeszcze innym  - post z godziną 14:00. Wygląda jakby forum ustawiało nieprawidłowe daty/godziny dla niektórych postów.

Sytuacja jest niezależna od tego, jaką mam ustawioną strefę czasową w profilu, oraz od tego czy jestem zalogowany.

EDIT: przy niniejszym poście widzę z kolei godzinę 14:54, co jest bzdurą.

EDIT: o przepraszam, coś mi się pomieszało. Miałem włączony czas letni w profilu. <facepalm>

416

(2 odpowiedzi, napisanych Programowanie - 8 bit)

Henry's House to żadna rewelacja. Bohater jest z 2 duszków + bit 5 GPRIOR, reszta duchów idzie na niektóre przeszkadzajki. Tło to ANTIC 4 z przerwaniami DL co parę linii trybu - przy nieruchomym polu gry zrobić coś takiego to banał. Kolorów jest tyle ile trzeba - faktycznie wydaje Ci się, że jest za dużo.

417

(1 odpowiedzi, napisanych Emulacja - 8bit)

Zamiast File->Attach tape... używaj Atari->Tape recorder...

418

(13 odpowiedzi, napisanych Bałagan)

mazi napisał/a:

Owszem, w tym przypadku jestesmy skazani na microsoft

E tam, pod Linuksem też działa.

419

(22 odpowiedzi, napisanych Bałagan)

Pójdzie pójdzie - Win98 wcale nie jest bardzo wolniejszy od 95-tki. Tylko zajmuje więcej miejsca na dysku. Ale do starych gier zmiana systemu nie jest potrzebna.

Twój komputer to standardowy PC/AT z lat 90-tych. Porty PS/2 pojawiły się w IBM PS/2 już w 1987, ale zaczęły być popularne w architekturze AT (której nb. PS/1 przedstawicielem nie jest) dopiero w połowie lat 90.

W takiej sytuacji zrobiłbym to co sugerował Dely - zobacz co ma do powiedzenia na temat myszy Menedżer urządzeń. Ale przedtem sprawdź jeszcze czy w autoexec.bat albo config.sys nie są ładowane sterowniki myszy. Jak są to je wywal.

420

(22 odpowiedzi, napisanych Bałagan)

W Windows 95 kursor jest normalnie widoczny nawet gdy mysz nie jest podłączona - pozostaje przez cały czas na środku ekranu.

Sprawdź, czy po odłączeniu myszy i restarcie kursor się pojawia. Powinno też wyskoczyć ostrzeżenie o braku myszy.

Sprawdź też ustawienia kursora we właściwościach myszy - może ktoś Ci zrobił głupi dowcip.

421

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

Tu coś było.

422

(31 odpowiedzi, napisanych Emulacja - 8bit)

geo650 napisał/a:

Dźwięk SDL nie jest zbyt dobrze obsługiwany, bo tnie i szarpie a także jest opóźniony: np. melodyjka z SELF TEST nie gra się płynnie, a "jąka się" i wybrzemiewa jeszcze po wyjściu do głównego menu. Ciągle słychać także okresowe pykanie z głośnika, coś jakby pętla bufora cyklicznie odtwarzanego była krzywo zamknięta.

Domyślam się dlaczego. Funkcja SDL_OpenAudio() pobiera w 1. parametrze _proponowany_ rozmiar bufora dźwięku, ale funkcja ta może ten rozmiar zaakceptować albo nie. W 2. parametrze zwraca ona rzeczywisty rozmiar bufora, który udało się uzyskać. W Atari800 ten 2. parametr jest ignorowany - bufor ma ustalony na sztywno rozmiar 1024 sampli. Zobacz atari_stl.c/SoundSetup(), wywołanie SDL_OpenAudio(&desired, &obtained).

Wydaje mi się, że SDL_OpenAudio zwraca rozmiar większy niż 1024 sample, a Atari800 to ignoruje i przy każdym  wywołaniu SoundCallback wypełnia tylko 1024 pierwsze sample bufora, i stąd pykanie.

423

(31 odpowiedzi, napisanych Emulacja - 8bit)

Spróbuj przekierować standardowe wyjście błędów do jakiegoś pliku. Może dzięki temu dowiemy się w którym momencie emulator się wysypuje. (Zapewne na otwieraniu video SDL).

424

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

pajero napisał/a:

To akurat jest wciąż FELER sprzętowy w POKEYu - jego część pochodna, niegroźna i też nieznana.

To nie jest feler POKEY-a tylko efekt uboczny tego, że klawiatura jest matrycowa.

mono napisał/a:

Ale takie zachowanie jest typowe dla każdej klawiatury matrycowej i oidp występuje nie tylko w atari, ale np również w c64.

W pecetach i innych komputerach też.

pajero napisał/a:

najważniejszym Felerem braku tej linii jest - brak reakcji na wciskanie parunastu kombinacji klawiszy z Control+Shift

Nic nie stoi na przeszkodzie żeby na klawiaturze przy Shifcie i Controlu wstawić diody, eliminując w ten sposób key ghosting dla tych klawiszy. Tak się robi w drogich klawiaturach pecetowych i klawiaturach muzycznych.

EDIT: A oto efekt mojego zeszłorocznego hackowania emulatora Atari800 - emulowane jest działanie bitów 0 i 1 rejestru SKCTL (czyli DEBOUNCE) oraz key ghosting. Dodatkowo dodana jest możliwość przemapowania klawiszy.

Jak ktoś ma w PC-cie dobrą klawiaturę, która wykrywa naciśnięcie więcej niż 3 klawiszy naraz, to emulator to ładnie obsłuży. W przeciwnym wypadku można obejść problem, mapując klawiaturę (Input configuration->Keyboard bindings) żeby użycie jednego klawisza PC-towego powodowało naciśnięcie kilku klawiszy Atari.

425

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

pajero napisał/a:

Nie, dla procki KBGBYT ($F2FD) korzystającej z tablicy KEYDEF ($FB51)  "nowe"  klawisze oznaczone są wartością $80 (czyli: not used). Tak w OS-XL czy QMEGach

OK, wierzę.

pajero napisał/a:

Szkoda, że nie jest to stabilne i nie zaczyna się od wartości $3f od góry ekranu. Tylko faluje jak diabli.

Powtarza się stabilnie co 64 skanlinie :) Poza tym, mamy IRQ klawiatury, więc stabilność nie powinna być potrzebna.

pajero napisał/a:

A szkoda. Trochę dziwne ograniczenie w budowie Pokeya.

Dziwne jak dziwne. Każda nowa funkcja to większe skomplikowanie układu.