Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
atari.area forum » Posty przez Krótki
XLFriend również.
Invasion (Bulldog Software).
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.
z tego co zrozumialem to element graficzny 'klocek' moze byc maksymalnie 2 bajty szeroki?
Nie ma żadnych ograniczeń tego typu. Gdzie to wyczytałeś?
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.
Panie, pics or it didn't happen.
A to CA2002 w ogóle istnieje?
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.
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>
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.
Zamiast File->Attach tape... używaj Atari->Tape recorder...
Owszem, w tym przypadku jestesmy skazani na microsoft
E tam, pod Linuksem też działa.
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.
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.
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.
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).
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.
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ż.
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.
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ę.
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.
A szkoda. Trochę dziwne ograniczenie w budowie Pokeya.
Dziwne jak dziwne. Każda nowa funkcja to większe skomplikowanie układu.
Zajrzyj do FAQ (link gdzieś tu na górze strony) oraz tu. Daj znać jak nie pomoże.
Miło, że ktoś to wreszcie wyjaśnił we w miarę przystępny sposób.
Zaproponowałem przypisanie "nowych" klawiszy nie wraz ze wzrastającą liczbą kodu klawiszy, ale tak aby ułatwić ich przyszły montaż.
Z wprowadzeniem tych klawiszy jest pewien kłopot - o ile pamiętam, standardowy OS w przypadku takiej nietypowej wartości w KBCODE, się wiesza.
Ważną informacją jest, że POKEY podaje kody wszystkich wciśnięć w trakcie jednej ramki, czyli co parę linii. I tak w kółko. Odczytywać więc stany musimy, np. na przerwaniu DLI.
Dokładniej, POKEY sprawdza stan każdego kolejnego klawisza co 1 skanlinię obrazu. Zaczyna od A = 3f, i co skanlinię sprawdza stan kolejnego klawisza: S = 3e, G = 3d, Caps = 3c itp.
Powyżej napisałem o feler'ze linii z klawiszami Shift i Control. Jak widać z matrycy, pozostają nieobsadzone 5 kombinacje (wliczając w to Break). Zwieranie wolnych linii z BSC nie robi na POKEYu żadnego wrażenia..... A może Wam się uda to zmienić?
A co tu można zmienić? POKEY sprawdza stan linii BSC (a raczej stan nóżki KR2) tylko w określonych momentach - raz sprawdza gdy aktualnie skanuje klawisz w 2. linii matrycy (wykrycie Break), raz w trakcie skanowania 6. linii matrycy (Shift) i raz w trakcie skanowania 8. linii matrycy (Control). W innych chwilach ta linia jest ignorowana.
"Upakowanie" kodów w linie skaningowe zależy od ilości "grup" wciskanych na raz. Dokładnie tego nie sprawdzałem. Bo nie jest to stałe jak na fotce - radzę odpalić program - po to go pisałem, by nie było takich pytań.
"Upakowanie" to wynika w prostej linii z faktu, że przeskanowanie całej matrycy zajmuje 64 skanlinie czasu. Upakowanie będzie różne w zależności od tego, które grupy klawiszy są wciśnięte, ale cały cykl powtarza się co 64 skanlinie.
Akurat tu trafiłeś w następne ograniczenie.
.....to jest przypadek wystąpienia pary (ZX) oraz pionowo przecinających się kolumn (Q A)
Nazywa się to key ghosting i można je zauważyć także bez wyłączania DEBOUNCE. Spróbujcie w BASICu nacisnąć naraz np. klawisze Control, K i 8, i powiedzcie czemu kursor przeskoczył do następnej linii :)
między trybem zwykłym, a debounce
Akurat "tryb zwykły" to jest właśnie "tryb debounce" - w tym sensie, że w zwykłym trybie funkcja DEBOUNCE POKEY-a jest włączona ;)
Dodam jeszcze, że:
- Po wyłączeniu DEBOUNCE przerwanie klawiatury jest generowane nie tylko raz, po naciśnięciu klawisza, ale za każdym razem, gdy POKEY w trakcie skanowania matrycy natrafi na naciśniętą grupę klawiszy. Czyli np. gdy naciśnieta jest grupa AS, przerwanie leci co 64 skanlinie; gdy naciśnięte jest więcej grup - odpowiednio częściej. (zob. "Upakowanie") W każdym razie nie trzeba sprawdzać aktywnie stanu KBCODE - wystarczy przechwytywać IRQ klawiatury.
- Ficzer był wykorzystany w konsoli 5200, gdzie konstrukcja joysticków (naciśnięcie każdego klawisza powoduje de facto zwarcie 2 sąsiednich punktów na matrycy POKEY-a) zniosła wymóg naciskania "grup klawiszy". OS 5200 domyślnie wyłącza DEBOUNCE i mamy za darmo wykrywanie wielu klawiszy joysticka naciśniętych naraz (aczkolwiek nie wszystkich kombinacji :( ).
Pajero, na przyszłość zapisuj obrazki w PNG. JPEG nie nadaje się do rysunków schematycznych.
Nie wiem, cytowałem Atariki.
Właściwie to jest ciekawa sprawa. W żadnej dostępnej literaturze nie ma informacji o tym, że w 6502 IRQ ma prioryter nad NMI - co więcej, źródła twierdzą coś wprost przeciwnego. Np. 6502.org:
Note also that if an NMI and an IRQ hit at the same time, the NMI has the higher priority and will get serviced first.
W dyskusji na AtariAge mówili, że nie jest to problem samego procesora, tylko specyficznej architektury Atari, i że nie występuje on w innych komputerach używających 6502. Być może powodem ignorowania NMI przez procesor jest fakt, że ANTIC umie zatrzymać zegar CPU.
Więc może informacje w Atariki są nieścisłe.
EDIT: A wystarczyło doczytać do końca :) Faktycznie chodzi o to, że jeśli CPU już zaczyna obsługiwać IRQ i w tym momencie na nóżkę NMI procesora przyjdzie sygnał, i jeśli dodatkowo sygnał ten jest krótszy niż 3 cykle, to przerwanie NMI zostanie zignorowane. Natomiast wszystko będzie dobrze jeśli sygnał NMI będzie dłuższy.
Tyle że w przypadku Atari, ANTIC ustawia linię NMI tylko na 2 cykle. Co więcej, podobno stara dokumentacja do 6502 mówi, że minimalny czas trwania sygnału NMI to właśnie 2 cykle. Można więc powiedzieć, że błąd jest nie tyle w procesorze, co w dokumentacji :)
A ponieważ 65C02 jest procesorem CMOS o zupełnie innej konstrukcji, to problem został w tym procku rozwiązany może nawet nieświadomie.
Na niektóre pytania odpowiedzi są w Resjestry POKEY-a oraz w dokumentacji
9. Wszystkie bity w IRQST poza 3. (XMTDONE) są zatrzaskowe. Tylko skasowanie danego bitu IRQEN powoduje zresetowanie odpowiedniego bitu w IRQST (poza bitem XMTDONE).
10. Tak, ale wyjątkiem znowu jest bit XMTDONE - nawet gdy przerwanie jest zablokowane, jego wartość może zostać przez POKEY zmieniona.
nie wiem czy to jest blad
W 65C02 i następnych zostało to poprawione, zatem wg twórców był to błąd.
Korekta czy poprawka tu nie będzie pasować - przecież nie każde revision zapisane w systemie kontroli wersji zawiera w sobie poprawkę, równie dobrze może to być dodanie nowej funkcji do programu.
Słowo "wersja" też nie oddaje idei - revisions to zmiany przyrostowe, ułożone w ścisłym porządku i wywodzące się jedna z drugiej - każda następna zastępuje poprzednią. A słowo "wersja" nie ma w sobie tego wymogu bycia w uporządkowanej kolejności, zastępowania. Samochód w wersji kabrio nie zastępuje auta w wersji kombi.
Koniec końców, zostaliśmy przy rewizji bo wszyscy intuicyjnie to słowo rozumieją, a przecież o to w gruncie rzeczy chodzi.
Ten z trójkątnymi przyciskami to Cheetah Marketing Mach1+, a ten drugi to Cheetach 125+ - ale w Polsce chyba były dostępne tylko podróbki no name (na Jacquesa zdjęciu widać, że oba pudełka są "podróbkowe").
Sam miałem 2 joysticki 125+; niestety brat je kiedyś komuś pożyczył i słuch o nich zaginął. Ma ktoś z was jednego (albo dwa) na sprzedaż?
atari.area forum » Posty przez Krótki
[ Wygenerowano w 0.098 sekund, wykonano 14 zapytań ]
