Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Gearlynx 1.2.15 Emulator Atari Lynx doczekał się ważnej aktualizacji z wieloma nowymi funkcjami.
STOS BASIC V5.5 Alpha Popularny język programowania dla Atari ST powraca po ponad 30 latach w nowoczesnej wersji.
Command & Conquer na Atari ST Kultowy RTS Command & Conquer zmierza na Atari ST. Zobacz niesamowity port legendarnej strategii.
Altirra 4.50 test 13 Avery Lee udostępnił kolejną wersję testową najdoskonalszego emulatora Atari.
CT60 TOS 1.03e Po blisko 21 latach ukazała się oficjalna aktualizacja CT60 TOS do wersji 1.03e.
atari.area forum » Posty przez mono
Reasumujac: jest moc. Ciekawe, czy kolejna wersja emulatora ZX działająca na Rapidusie i VBXE będzie wspierała Sonari?
Ależ wspiera. Należy mu tylko skonfigurować adres.
Edit: W pliku ZX.CFG należy dodać linijkę:
AY=$D560Na filmie @Artu2tu zauważyłem, że są problemy z generatorem szumów. Podczas prób z prototypem SONari od Torimana zdarzyło mi się użyć kiedyś wadliwego AY, który nie generował szumów. Tak więc problem może leży w wadliwym układzie.
1. ZuluGula - 1szt.
2. pancio.net - 1szt.
3. Cobol - 1 szt.
4. atarixegs - 1 szt.
5. Sikor - 2 sztuki
6. Pin - 1szt - ale raczej pod warunkiem, że będzie to cart z przelotem
7. Mono - 2 szt.
http://www.virtualdub.org/downloads/Alt ... Manual.pdf
ad.1. czas który zabiera antic jest uzależniony od trybu dl
ad.2. licznik danych antica jest 12-bit
ad.3. wystarczy o ile nie wyłączasz przerwań vblk
ad.4. nie widziałem
@Mono, nie wiem na ile tam ten Twój soft już jest gotowy, ale może dał byś jakiś kawałek testowego programiku, który zrobi cokolwiek, żeby chłopaki mogli posprawdzać jak już złożą?
http://mono.atari.pl/psgplay/psgplayh.atr
Odpalamy:
PSGPLAYH /A $D560 SPEJS@Mono: czy w takim razie dla wygody użytkowników Twoje programiki mogły by jako domyślny przyjmować adres bazowy $D560 zamiast obecnego $D500?
Ma się rozumieć - jak zwykł mawiać Miś Uszatek.
Adres żeby ustawić, to trzeba zlutować _tylko_jedno_ z połączeń na tej "drabince". Moja sugestia jest taka, żeby poprosić Mono o wytyczne, bo to on pisze soft. Mono jak czytasz, to proszę, wypowiedz się tu:-)
Moje programiki można konfigurować podając adres karty za pomocą /A adres, więc docelowy adres urządzenia nie jest wielkim problemem. Domyślnie przyjmowany jest adres bazowy $D500.
Jeśli dobrze widzę adres bazowy SONari może być skonfigurowany za pomocą jumperów SJ3..10 (wg schematu http://raven1.magix.net/sonari/SONari_stereo.pdf) co $20 bajtów. Ponieważ SlightSID siedzi sobie w obszarze $D500..$D542, to może niech adres bazowy SONari byłby w $D560? To będzie Y3 (czyli SJ6) zwarty?
Edit: Pamiętajcie jeszcze o SJ1 i SJ2 jak nie chcecie żeby programy wypisywały Wam że znalazły AY a macie wsadzone YM :)
@Impuls: Zerknij na kolejną odsłonę rodziny 65 czyli na 65C816 i od razu humor Ci się poprawi. Tego procesora możesz używać z Rapidusem.
EDIT2: sprawdziłem wersję XEX, po 28 levelu który ma "?" jako układ bloków do rozbicia... następuje level 29 z dwoma rzędami klocków u góry, po czym odpala się level 30 i to jest już kaszana i śmiecie na ekranie.
sprawdzę zatem oryginał na carcie. Sprawdziłem oryginał na carcie, odpalony na real sprzęcie. Gra zachowuje się dokładnie tak samo... sieczka na 30-levelu.Czyżby autor założył że nikt nie dotrze tak daleko?
EDIT3: LOL... autor popełnił błąd w kodzie ;) zakładał że poziomów będzie 49... jednak poziomów w grze umieścił 29... poziom 30 faktycznie nie istnieje... po poprawce w kodzie gry po przejściu 29 poziomu... gra po prostu startuje od nowa tzn. od poziomu nr 1 :) nie ma żadnego zakończenia, nawet napisu "congratulations" :D
Niesamowite - Nexuss na carcie, choć też zepsuty. Ale odkrycie jest fajne - wielkie dzięki za podrążenie tematu i za poprawkę!
Ja też chętnie nabyłbym taki zamiennik lub też dwa.
Zanabyłem drogą kupna 130XE SECAM od Bitmana i stwierdzam, że FGTIA poprawnie generuje wszystkie sprajty i obsługuje kolizje (testowane na SysInfo2), ma 8 odcieni i zarówno tryby ANTIC-a, jak i GTIA wyświetla poprawnie.
Podłączone i sprawdzone. Monitor ma proporcje 4:3 a do tego co Panowie pisali http://www.atari.org.pl/forum/viewtopic ... 38#p241338 podzielę się swoimi wrażeniami:
1. Atari 130XE PAL obraz z wyjścia VBXE (RGB) podłczone przez SCART - obraz stabilny i ostry, nic nie drży. Sygnałów composite video ani chroma/luma nie testowałem, bo nie mam kabelków.
2. Atari 130XE SECAM obraz z wyjścia monitorowego (video output) podłączony przez SCART - obraz stabilny i ostry, kolory chyba poprawne bo nieco inne niż w PAL.
Nie zaobserwowałem opóźnień.
Więc ten monitor (LG FLATRON M1917A) chyba można spokojnie polecić do VBXE.
Dzięki Panowie. Poczytałem wątki, w których pisaliście o różnych modelach. Niestety LG M1721A nie udało się namierzyć, ale zamówiłem LG FLATRON M1917A i zobaczymy jak się będzie sprawować. Obadam rzecz jak już przyjdzie i zdam relację.
No bardzo ładna inwitka. Gratulacje Lisu!
Tak czułem niestety. Szkoda. Ale zrobię w wolnej chwili jednak test, bo kto wie - może wszyscy będziemy zaskoczeni :) Dzięki.
No i niestety kolejny monitorek (tym razem Commodore 1084, wcześniej Phillips 8833) odszedł do Krainy Wiecznych Łowów.
Używałem go głównie do działań z VBXE i pomyślałem, że może spróbuję się zaopatrzyć w jakiś monitor LCD tym razem. CRT są już leciwe i niestety będą wysiadać coraz częściej (jakkolwiek zakupię jakiś CRT na pewno, ale chciałbym mieć jakiś sprzęt co do którego nie będę musiał się obawiać że lada dzień i ten przeniesie się na łono Abrahama).
Moja idealna wizja:
1. Obsługa PAL, NTSC i SECAM.
2. Obsługa interlace zarówno standardowego (mruganie naprzemienne ramkami parzystymi), jak i Rybagsowego (ramki parzyste i nieparzyste).
3. Wejście RGB, wejście obsługujące sygnał ze standardowego gniazda monitorowego Atari.
4. Proporcje ekranu 4:3.
5. Małe opóźnienie bo miło byłoby gdyby dało się na nim grać.
Oczywiście liczę się z tym, że może ideał nie jest możliwy do spełnienia.
Czy możecie mi jakiś model polecić?
Wszystko to znajdziesz u Zientary w "Procedurach Wejścia/Wyjścia": http://tajemnice.atari8.info/ksiazki/index.html
Można spojrzeć do "Procedur interpretera BASIC-a" w jaki sposób realizowane jest LOCATE - wydaje mi się, że x i y należało wstawić do COLCRS i ROWCRS po czym wykonać GET (PLOT analogicznie, ale z PUT-em). Ale głowy nie dam.
Pin do ściągnięcia zasobów z internetu używa Atari :] Serio.
W ramach świątecznego prezentu, proponuję odbanować Bezrobottnego :)
Chciałbyś wprowadzić na forum element baśniowy?
Ale Święty Mikołaj był 2 tygodnie temu. Teraz CHOINKA :)
Zdrowych i spokojnych oraz szczęśliwego nowego!
Dziękuję, płytki dotarły całe i zdrowe.
I teraz pytanie o program, który posłuży do przeprowadzenia tego eksperymentu. Wstępnie wydaje mi się, że program, którego kod wstawiłem w pierwszym wpisie w tym wątku (korzystający z joysticka i operujący na rejestrach cieniach) będzie odpowiedni. Można go zmodyfikować, aby zmieniał także (albo wyłącznie -- fotorezystor będzie umieszczony przy górnej krawędzi ekranu) kolor ramki. Joystick nie będzie tu elementem, w stosunku do którego cokolwiek mierzymy, a jedynie wyzwalaczem zmiany koloru tła (można też co sekundę zmieniać kolor tła, o czym pisałeś). Jeśli dobrze rozumiem, to ponieważ w tym programie operujemy na rejestrach cieniach, to synchronizujemy się z powrotem pionowym i dzięki temu pozbywamy się problemu związanego z niepewnością, gdzie była plamka w momencie zmiany koloru tła.
Tak jest. W tym przypadku cienie będą doskonałe.
Przykładowy program zmieniający kolor co 1s z czarnego na biały:
RTCLOK = $12
COLBAKS = $2C8
ldx #$00
ldy RTCLOK+2
blink:
tya
clc
adc #50
tay
sync:
cpy RTCLOK+2
bne sync
stx COLBAKS
txa
eor #$0F
tax
jmp blinkTestujesz i sterujesz rejestry cienie, które są aktualizowane na przerwaniu VBLK. To powoduje, że od fizycznej zmiany stanu joysticka do aktualizacji rejestru PTRIG może minąć prawie cała ramka czyli 312 linii skanningowych (PAL). Następnie na podstawie cienia ustawiasz stan rejestru cienia dla koloru COLOR2 - zostanie on zaktualizowany dopiero przy następnym VBLK - czyli po kolejnych prawie 312 liniach skanningowych. Co więcej sterujesz COLPF2 a więc obszar tła w trybie GR.0 a więc kolor zieniany jest w ograniczonym obszarze. Więc przy Twojej metodzie pomiaru miną min 1 a max 2 ramki ekranu w reakcji na wychylenie joystickiem.
Ile to może zabrać czasu? 114 cykli na linię * 312 linii skanningowych / 1773447 Hz = 20 ms. To jest czas trwania ramki w PAL.
Proponuję użyć rejestrów hardwareowych, wtedy na natychmiastową zmianę stanu joysticka będzie można natychmiast zmienić kolor tła ekranu. Proponuję też wyświetlać ekran pusty i zmieniać kolor ramki ekranu w reakcji nie na wychylenie joysticka, ale na stan przycisku.
RTCLOK = $12
TRIG0 = $D010
COLBAK = $D01A
DMACTL = $D400
NMIEN = $D40E
NMIRES = $D40F
lda RTCLOK+2
sync:
cmp RTCLOK+2
beq sync
lda #$00
sta DMACTL
sta NMIEN
sta NMIRES
loop:
ldx #$00
lda TRIG0
bne skip
ldx #$0F
skip:
stx COLBAK
jmp loopMonitor CRT powinien dać opóźnienie od 0 do 20 ms, ponieważ fotorezystor bada punkt na ekranie, przez który przebiegnie plamka (pewnie jakiś obszar) a przecież wciśnięcie przycisku mogło się zdarzyć w pierwszej linii skanningowej, a badanie plamki w ostatniej. Reakcja na zmianę stanu przycisku odbywa się w ciągu 12 cykli CPU więc w ok. 7us i to właściwie powinien być najkrótszy obserwowalny czas reakcji CRT.
Wydaje mi się, że w ten sposób dałoby się precyzyjniej określić opóźnienie LCD, ale cudów nie oczekiwałbym - podejrzewam, że czas reakcji skróci się o 20..50 ms.
Przerwania NMI wyłączam ze względu na odświeżanie rejestrów hardwareowych na podstawie rejestrów cieni na VBLK.
Edit: Może nie prościej, ale czy nie lepiej byłoby zamiast testować stan joysticka badać skok sygnału luminancji a element światłoczuły ustawić na górze ekranu? I mrugać wtedy ekranem co np. 1s?
A mógłbyś powiedzieć gdzie ten czeski sklepik?
atari.area forum » Posty przez mono
Wygenerowano w 0.114 sekund, wykonano 17 zapytań