Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Bubble Bobble dla Atari 8-bit Wersja ta bazuje na edycji BBC Micro, jednak została napisana niemal od podstaw, by maksymalnie wykorzystać możliwości Atari.
Silly Venture 2024WE - wyniki Ponad sto prac wzięło udział w compo SV2024WE
Trwa Silly Venture 2024 w Gdańsku! Party się rozpoczęło, zajrzyj po link do streamów.
Flop 68 Po dwuletniej przerwie wraca Flop!
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
atari.area forum » Posty przez Krótki
!!! Dzięki Seban! Nie masz Ty albo Dely czasem schematu tego carta? Przydałoby się go zaemulować.
Z tego co widzę, kartridż ma 4 banki po 8 KB. Po starcie mapuje pierwsze 8 KB pod $A000-$BFFF, a potem dokonuje zapisów pod $D580, przełączając kolejne banki. Czwarty zapis odłącza kartridża.
ROM działa pod emulatorem z mapowaniem Ultracart, które jest bardzo podobne (4x8 KB, zapis/odczyt na stronie $D5 przełącza banki 0->1->2->3->wył.->0->...), ale nie mam pewności czy oba mapowania są identyczne.
Nie każdy, kto gada o ... piłce nożnej jest namiętnym futbolistą. Ja np. nie uważam Cię za tępego gimbusa tylko dlatego że ripostujesz rodem ze szkolnej ławki.
Dla mężczyzn to jest jak się w niego gra, a nie jak się nim masturbuje.
Bujasz, Sikor. WKC było wydane w jednej tylko wersji, całodyskowej, która nie używała XE RAM. Tak samo IK, które miało jedno wydanie na dyskietce i jedno na kasecie. Reszta to piraty.
Z gier które używają XE RAM ale też działają bez niego, to jeszcze Bop'n'Wrestle (na 130XE nie doczytuje notorycznie grafiki postaci podczas gry), i Artefakt przodków (muzyka na 130XE).
Myślę że sami się "przekręciliśmy", mogliśmy coś źle podliczyć.
Z obecnych był jeszcze Simius.
Mnie też się podobało. Poznałem nowych "współhobbystów", podyskutowałem na kilka ciekawych tematów. Jedzenie i obsługa też bardzo dobra.
Wielkie dzięki! Za parę dni zabiorę się za analizę, i wtedy powiem coś konstruktywnego.
Póki co zwrócę tylko uwagę, że coś chyba pomieszałeś z plikami - 7v-pal-1 i 9v-pal-1 są identyczne.
9 woltów? GTIA.PDF mówi, że napięcie na DEL powinno być od 3 do 8. Albo źle rozumiem, albo coś sobie spalisz :-)
Tu nie chodzi o sam monitor, ale o sygnał z Atari. Linie są wyraźnie widoczne przy S-video, przy composite słabo lub wcale.
To ja się zastanawiam, jak to jest technicznie możliwe, żeby sygnał, jakikolwiek on by nie był, po zdemodulowaniu mógł w jakiś sposób wpływać na ostrość wiązki elektronów w monitorze. Po prostu bardzo jestem ciekaw.
EDIT: Flashjazzcat, maybe the D1/D2 indeed don't contain the delay line? These monitors were apparently produced starting in 1992 and intended for the Amigas, and the delay line is not needed for this purpose. No service manual online, but there's a schematic of the D1 out there - maybe someone who knows how to read it :-) would be able to find out whether the delay line is there at all.
Dziękuję za udostępnienie wyników.
Witam.
1. Dziwactwo, sygnał burst w naprzemiemmnnych liniach jest nieco przesunięty w fazie.
Żadne dziwactwo - z tego co wiem, w PAL faza bursta w liniach z "odwróconą fazą" jest o 90° opóźniona w stosunku do linii "zwykłych" - tylko dzięki temu odbiornik odróżnia linie zwykłe od "odwróconych".
2. W naprzemiennych liniach wg standardu PAL, sygnał chroma powinien być przesunięty o 180°
Niezupełnie. W liniach PAL faza chromy jest nie przesunięta o 180°, lecz "odwrócona w czasie" - w sensie takim, że jej przesunięcie powoduje zmianę barwy w "odwrotną" stronę niż w liniach zwykłych.
Z pomiarów wynika że kolejne stopnie linii opóżniającej kodującej kolor mają opóźnienie ca. 16ns. (ca. 20ns dla NTSC wg. dostepnej dokumentacji)
To nie tak. Opóźnienie jest zależne od napięcia przyłożonego do nóżki DEL, a w konsekwencji - od ustawienia potencjometru regulacji koloru. Przy czym w service manualach do komputerów NTSC można wyczytać, że prawidłowym ustawieniem jest takie, w którym kolory 1 i 15 są identyczne. Odpowiada to opóźnieniu ok. 19,95ns pomiędzy każdymi dwoma kolejnymi kolorami.
W PAL jest tak samo - potencjometrem reguluje się opóźnienie. Tylko że zależności są bardziej skomplikowane; w szczególności nożka DEL daje różne opóźnienia dla kolorów w liniach parzystych i nieparzystych. Algorytm będący zgrubnym przybliżeniem rzeczywistości wrzuciłem w tym poście (Altirra fazy kolorów wylicza bardzo podobnie).
Domyślam się, że podczas swoich badań nie dotykałeś się do potencjometru koloru. Szkoda, bo byłoby to dla nas niezwykle pouczające.
Skoro piszesz, że w razie potrzeby możesz powtórzyć analizę, to mam do Ciebie prośbę: tutaj taki oto programik, który wyświetla 2 linie (parzystą i nieparzystą), w każdej wyświetla wszystkie 15 chrominancji. Czy mógłbyś zrobić z tych 2 linii oscylogram taki jak wcześniej załączyłeś? Ale nie jeden, tylko wiele, każdy przy innym ustawieniu potencjometru koloru - od jednego ustawienia krańcowego do drugiego. Pozwoli mi to być może na odtworzenie dokładnego algorytmu generowania kolorów. W NTSC to zostało już zrobione dawno, w PAL jeszcze nie.
10 GRAPHICS 11
20 FOR I=0 TO 14:COLOR I+1
30 PLOT I*5,0:DRAWTO I*5+3,0
40 PLOT I*5,1:DRAWTO I*5+3,1
50 NEXT I
60 GOTO 60Badanie działania GTIA najlepiej przeprowadzać, podając na wejście PAL nie sygnał podnośnej koloru, a sygnał OSC ;) (analogicznie do pierwowozoru NTSC).
Dlaczego tak jest najlepiej?
Chętnie bym taką kalibrację przeprowadził dla próby nawet w domowych warunkach, ale nie mam pojęcia skąd wytrzasnę generator i GEM pattern :)
Może po prostu wyświetl sobie naraz wszystkie 15 chrominancji i poreguluj aż zaczną się uśredniać tak, że obszary o tym samym kolorze staną się jednolite. Ale uważaj, ten service manual to jest do modelu P1, nie D1.
Możliwe, że w monitorze dpilawa uśrednianie jest po prostu źle wyregulowane. Service manual opisuje procedurę regulacji PAL delay line, powinno wystarczyć skalibrowanie.
Rozdzielenie sygnału na luminancję i chrominancję powoduje ostrzejszy obraz, brak artefaktów, ale co za tym idzie - widoczne także linie sygnału - co druga ma zawartość, reszta jest, a przynajmniej powinna być, pusta. I jest to zjawisko normalne, przeplot czyli interlacing.
No, w przypadku Atari to raczej chodzi o brak przeplotu, nie?
W sygnale Composite sygnały zakłócają się na tyle, że rozbicie na linie przestaje być widoczne.
Oberzyj w takim razie rsz_composite-1084s.jpg z postu 7. który przeczy Twoim słowom.
Niby czemu rozbicie na skanlinie miałoby być widoczne przy Y/C, a przy composite już nie? W obu przypadkach sprowadza się to do wiązki elektronów rysującej poszczególne linie na ekranie.
O! A kręciłeś podczas badania potencjometrem? To mnie najbardziej w tym wszystkim interesuje, jak regulacja wpływa na sygnał.
No ale wiesz o co mi chodzi; <laik>takie coś, co pozwoli podejrzeć fazę sygnału chrominancji w przełożeniu na przestrzeń kolorów YUV</laik>.
A ja mam na to własną hipotezę:
PAL-owski GTIA generuje różne kolory w parzystych i nieparzystych liniach. Normalnie to nie jest widoczne, bo PAL-owskie telewizory mają układ uśredniający chrominancję każdych 2 kolejnych linii. Wystarczy jednak wyświetlić obraz na którym sygnał chrominancji jest wyłączony w co drugiej linii, aby owo uśrednianie przestało mieć znaczenie.
Polecam Wam uruchomić programik z podlinkowanego postu. Wyświetla on wszystkie 15 chrominancji, z tym że na lewej połowie włączone są tylko nieparzyste linie ekranu, a na prawej tylko parzyste. Barwa niektórych chrominancji jest inna po lewej stronie niż po prawej! Sądzę że będzie to widoczne na każdym telewizorze - ja obserwuję to nawet przy połączeniu przez RF. (Dodatkowo namawiam do pokręcenia potencjometrem regulacji kolorów, tym od spodu, żeby wzmocnić efekt.)
Wracając do PAL-owskiego uśredniania chrominancji - zostało ono wprowadzone aby wyeliminować wadę systemu NTSC, w którym zakłócenia w eterze powodowały zmianę barwy transmitowanego obrazu. Rzecz w tym, że ta funkcja ma sens jedynie przy odbiorze sygnału telewizyjnego "z powietrza" - przy transmisji po krótkim kablu, jak w przypadku połączenia komputer-monitor, takie zakłócenia nie występują.
Możliwe więc hipotetycznie, że np. Twój monitor nie ma wbudowanej funkcji uśredniania chrominancji, bo po co. Dzięki temu na ekranie widoczne są prawdziwe kolory produkowane przez GTIA.
Apropos, czy ma ktoś z Was dostęp do wektorskopu? Chciałbym kiedyś sprawdzić, jak właściwie wygląda sygnał koloru z wyjścia monitorowego, i pomierzyć dokładnie jakie barwy produkuje PAL-owski GTIA.
Sądząc po odstępach między literami, jest to raczej MINI-SOFT.
Popieram, między literą N a tym znakiem nie ma miejsca na poziomą belkę litery T - to musi być I.
Wielkie dzięki Seban za dumpa i zdjęcia.
Kartridż to faktycznie chamski hack karta Turbo 2000F firmy MUEL. Tak chamski, że nawet nie chciało się autorowi usunąć opcji (I)nfo z menu - usunął ją jedynie z ekranu, naciśnięcie I nadal działa.
Widzę przełącznik dwupozycyjny oraz przycisk, zgadza się? Do czego służą? Domyślam się, że kartridż sam się odłącza po jakimś czasie od startu komputera, a ten przycisk służy do ponownego załączenia kartridża, ale do czego jest przełącznik?
Dump tego kartridża jest już na mojej "liście wszystkich kartridży", na poz. z CRC 67d2d2e0. Ale dumpa i tak warto zrobić:
1. Nigdy nie wiadomo, czy Twój kartridż nie jest przypadkiem jakąś inną wersją różniącą się niewidocznymi szczegółami,
2. A nawet jeśli jest taki sam, to posiadanie 2 niezależnych dumpów pozwoli zweryfikować ich poprawność.
Zrób dumpa, proszę.
EDIT: Przyjrzałem się skrinszotowi. Twój kartridż jest jednak inny od tego już znanego.
EDIT2: Fota etykiety jest niewyraźna. Tam jest MINI-SOFT, MINE-SOFT, czy MINC-SOFT?
Zdziwisz się ponownie - Prehistoriki mamy dwa różne.
A że gra się jebie - może to zły crack? Jakby ktoś miał oryginalne wydanie kasetowe, to mogę pomóc zgrać do formatu CAS.
XXL - Prawdziwy hardcore'owiec muzykę pisze w bejziku ;)
OT: Richard Munns pisał w bejziku. Dokładniej w TBXL, przy czym utwory w postaci źródłowej, odtwarzane pod BASIC-iem, grały wolniej niż docelowo w ASM - najwyraźniej mistrz sobie w głowie je przyspieszał podczas tworzenia :-)
Bankowanie jest opisane u Jindrousha oraz w źródłach Atari800 w DOC/cart.txt. Powinno Ci to wystarczyć.
Jak pisalem np przy szerokosci 16 pixeli (tryb 2-kolorowy) danych jest 2x za duzo. Zobacz zalaczony plik 16x16. Po odrzuceniu 62 bajtow naglowka powinienem dostac 32 bajty - po 2 dla kazdej linii. A jest 64 bajty: po 4 dla kazdej linii :P
BMP jako format zaprojektowany "pod" 32-bitowego Intela ma tę cechę, że liczba bitów na każdą linię jest wielokrotnością 32. Po prostu odrzuć nadmiarowe bity w każdej linii i będzie dobrze.
Tu słychać trochę więcej.
Mazi: No, w SBF też się odkłada. Poczekasz wystarczająco długo, a zapełni cały ekran.
atari.area forum » Posty przez Krótki
Wygenerowano w 0.028 sekund, wykonano 37 zapytań