Przejdź do treści forum
atari.area
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
PiST 0.11.0 Środowisko programistyczne PiST dla Atari ST doczekało się nowej wersji 0.11.0.
bm800xl 0.5.9 Emulator bm800xl dla Raspberry Pi zyskał szybszy start, scanlines i pełne stany pamięci.
xasm 3.3.0 i wtyczka do VSCode Po czteroletniej przerwie powraca asembler skrośny xasm.
CAS2Audio 1.1.0 Odtwarzaj obrazy taśm CAS na telefonie z Androidem.
Gearlynx 1.2.37 Nowa wersja emulatora Atari Lynx Gearlynx 1.2.37 przynosi poprawki i optymalizacje.
Opcje wyszukiwania (Strona 27 z 53)
Przyjrzałem się jeszcze raz ostatnio zamieszczonym zdjęciom i przypomniałem sobie, że gdzieś miałem GTIA w takiej starej obudowie. Odszukałem go. Ma datę produkcji 8351 i opisaną wadę. Wada ujawnia się po ok. 30 sekundach od włączenia. Wygląda to tak, jakby przyczyną było zbyt duże opóźnienie pomiędzy wejściem OSC a wyjściem FO0. Żeby to zwalczyć, wystarczy pozostawić w powietrzu wyjście FO0 z GTIA, a do wejścia FO0 ANTIC-a doprowadzić bezpośrednio sygnał OSC. Przynajmniej w posiadanym przeze mnie egzemplarzu to działa. Znalazłem też jeden GTIA z datą produkcji 8442 (taką samą, jak egzemplarz, o którym wspominał Drac030), ale nie wykazuje wady nawet po podgrzaniu do 100°C.
Jak masz VBXE to chyba masz problem z głowy?
Oscylator. W XL dostępny sygnał taktujący ma 3,54M. Przynajmniej dwa razy za mało.
Jak komuś ten prążek bardzo przeszkadza, niech wywali CD4050 i wstawi na to miejsce 74HC174. Parę ścieżek trzeba przerwać i poprowadzić inaczej, doprowadzić sygnał zegarowy bezpośrednio z oscylatora 14,18MHz - i nie ma prążka.
Recepta dotyczy z oczywistych względów tylko XE. W XL tak prosto się nie da.
seban napisał/a:ps1) nigdy tego nie sprawdzałem ale również sam CD4050 może mieć różne czasy propagacji sygnału w zależności od projektu krzemu. Nie wiem czy CD4050 jest zaprojektowany tak aby każda z bramek buforujących miała identyczny czas propagacji.
Większe znaczenie ma fakt, że zarówno czas propagacji, jak i czas przejścia ze stanu niskiego do wysokiego jest w układzie CD4050 znacząco dłuższy niż ze stanu wysokiego do niskiego. Różnica sięga kilkudziesięciu ns. Ale to nie tłumaczy zjawiska, bo szerokość takiego ciemnego prążka na dużym, 24" monitorze miałaby wtedy zaledwie ok. 0,5mm. Ponieważ wymiana układu na szybki 74HC4050 nie daje zauważalnej poprawy, winą należy obciążyć GTIA.
mgr_inz_rafal napisał/a:Zamiana płyt nie stanowi dla mnie co do zasady problemu, lecz haczykiem może okazać się zamontowane na niej Ultimate. Czy dysponujesz płytą z tym rozszerzeniem?
Niestety, nie. Innego komputera do zamiany miejscami GTIA nie masz?
Na pierwszym zdjęciu wada jest wyraźnie widoczna, ale już piąte zdjęcie (półtorej godziny późniejsze) jest w porządku. Czy to znaczy, że po dłuższym czasie wada znika?
Do SV pozostało zaledwie dwa miesiące. Nie wiem, czy w tym czasie zdążyłbym coś zrobić, a po zamontowaniu VBXE to już nie byłoby to samo. Może, żeby nie tracić sposobności rozgryzienia problemu, po prostu zamienilibyśmy się płytami? Wysłałbym Ci jedną z moich, a Ty zamontowałbyś ją w obudowie zamiast swojej i odesłał mi tą drugą?
drac030 napisał/a:Odgrzewam kotlet: napisał do mnie wczoraj człowiek ze skargą, że SysInfo pokazuje mu zły obraz w teście GTIA
Ciekawe, czy tego człowieka dałoby się namówić do wysłania komputera do Polski w celu zbadania?
UMC robiło procesory dla Atari, z oznaczeniem UM6502I. Według schematów sporządzonych przez Jera, procesor w 7800 jest ten sam, co w XL/XE, więc możesz go śmiało użyć.
POKEY jest w porządku. O ile pamiętam, to wina systemu operacyjnego. Gra została napisana pod 400/800 i na serii XL/XE wychodzi to tak, jak w drugim linku. Musisz najpierw wgrać jakiś emulator starego systemu i będzie dobrze.
W wyniku dekodowania otrzymuje się 17-bitowe słowa o wartości zależnej bezpośrednio od koloru i luminancji piksela, ale także od napięcia na nóżce CADJ, napięcia zasilającego i aktualnej temperatury GTIA. Trudno to traktować jako wzorzec. Raczej jako adres mapy kolorów stworzonej wg arbitralnie założonej palety.
Z nowych wziąłbym Siglenta. Większy ekran, większa pamięć przebiegu przy niższej cenie. Sam w domu używam Hanteka DSO1200 i jestem z niego bardzo zadowolony, ale jest wyraźnie droższy od obu w/w. Analogowe odradzam. Możliwość obejrzenia zapamiętanego przebiegu po jednorazowym wyzwoleniu jest bardzo przydatna.
Przebiegi wziąłem z układu "powielacza" zmontowanego dokładnie według schematu z Twojej strony. Najprostszą metodą "naprawy" wydaje mi się dołożenie małego potencjometru wieloobrotowego i podstrojenie częstotliwości (przy odłączonym Phi2) na minimalnie (0,5-1%) mniejszą od 4xPhi2. Ale nie wydaje mi się, żeby to mogło działać w 100% niezawodnie z każdym zasilaczem i przy różnych temperaturach. To już chyba lepiej by było zrobić prymitywny mnożnik asynchroniczny na bramkach EXOR, jak na załączonym rysunku. Ja bym tu jednakowoż sięgnął po PLL => pewność i zaufanie. :)
toriman1 napisał/a:hej willy - no właśnie nie jest to glitch tylko "ten typ tak ma" a wygląda tak jakby ze 4 takty z generatora na 74132 mieściły się w jednym takcie Phi2. Nic dziwnego, że niektóre kostki mogą "wymiękać" choć bardziej stawiałbym na to, że PLS105 może mieć problemy gdy bramki będą podukowały coś bardziej niestrawnego dla logiki freezera na wejściu taktującym niż ten 'głupawy' zegar... Mimo wszystko dosyć zabawnie o wygląda :)
Zabawnie wygląda to dopiero na trochę szybszym oscyloskopie. :)
toriman1 napisał/a:Matthias Reihl to opisał podając częstotliwość x4 systemowa ale musiałbym to po prostu zmierzyć aby mieć pewność :)
Albo się mylił, albo celowo wprowadzał w błąd, albo wartości elementów na schemacie są niewłaściwe. NXP dla HCT132 podaje zależność 1/0.67RC. Wychodzi 17,64MHz.
Simius - wszelkie przeróbki, dorabianki itp. są naprawdę bez sensu :) szkoda czasu na to - są rzeczywiście już lepsze ale i trochę droższe sprzęty. To jest tylko w zasadzie działający vintage ;)
A to już jak uważasz. Rady dawać nic nie kosztuje. :)
Co do zakupu 82S105 w Chinach - nie widziałem ich oferty (nie znalazłem) Alibaba? Aliexpress? Za bardzo Chińczykom nie ufam po lekturze postów na forach. Potrafią pakować zupełnie inne struktury w scalaki. Przykładem może być commodore'owski SID.
Aliexpress. Też słyszałem, ale na tych kilku scalakach, które dotychczas nabyłem, jeszcze się nie naciąłem. Są też procedury reklamacyjne. Sprzedawczyk nie dostaje pieniędzy, dopóki nie potwierdzisz, że jesteś zadowolony z towaru. :)
Jakby to kogoś interesowało, to widze, że 82s105 są ciagle do nabycia w Chinach po 3USD/szt. Tylko za wysyłkę przez UPS liczą sobie 30USD, więc dopiero zakup większej liczby ma jakiś sens.
8bit napisał/a:"Co ciekawe - ma olbrzymie znaczenie producent układu 74HCT132. Jest to spory problem, ponieważ układ ten pracuje w powielaczu częstotliwości zegara Phi2 i układy nie wszystkich producentów spełniają swoje zadanie."
Nic dziwnego, bo to prosty generator, o częstotliwości pi razy oko 10x systemowa, a tylko kluczowany dla zachowania jakiej takiej synchronizacji w zakresie cyklu. Jak sobie troche odjedzie od zaplanowanej częstotliwości, to może np. regularnie generować glitche, które mogą robić różne niezaplanowane zadania. A częstotliwość można określić tylko w przyblizeniu i dla różnych producentów będzie inna. Proponowałbym zastąpić ten układ pętlą fazową 74HC/HCT4046 z dekadą 74HCT390 i skończą się problemy. Na wypadek jednak, gdyby ktoś z tego pomysłu chciał skorzystać, dodam tylko, że nadają się wyłącznie PLL-e Philips/NXP, Texas Instruments i Motorola/ON Semiconductors. Nie zadziałają natomiast Fairchild i National Semiconductors. Przyczyny można znaleźć porównując dokumentację poszczególnych producentów.
No właśnie. Z tego powodu i z powodu braku prostego synchronizmu częstotliwości nośnej PAL i zegara systemowego, na początek miałem zamiar zająć się rozkodowaniem NTSC. Ale natychmiast okazało się, że NTSC w ogóle się do tego nie nadaje, ponieważ ma tę nieprzyjemną wadę, że sygnał koloru dla obiektów o szerokości jednego cyklu, przy niektórych kolorach w ogóle nie jest generowany.
Sygnały AN0...AN2 są wykorzystywane, bo niosą informację o początku ramki, potrzebną do do zerowania przerzutnika parzystości linii. Identyfikacja parzystości linii jest niezbędna, ponieważ przesunięcie fazy danego koloru w systemie PAL jest inne w liniach parzystych, a inne w nieparzystych.
seban napisał/a:@Simius:
Ja zapytałem o to, bo w przypadku VBXE obrazki w trybach mieszanych tracą nasycenie kolorów, dopiero rdzeń z emulacją dekodera PAL (uśredniający nasycenie kolorów z dwóch sąsiednich linii) pozwala przywrócić odpowiednie nasycenie kolorów.
Pytanie zadałem bo pomyślałem że skoro brak w Twoim rozwiązaniu uśredniania kolorów,z dwóch linii efekt będzie taki sam jak w przypadku VBXE bez emulacji uśredniania PAL.
Efekt będzie ten sam.
Ale w tym wypadku mniemam iż to właśnie było Twoim założeniem z powodu chęci uzyskania większaj ostrości i wyrazistości obraz.
Takie było założenie, choć w przypadku tych trików efekt nie jest zgodny z zamiarami programisty.
xxl napisał/a:- czy teoretycznie jest mozliwa kontrola "od ktorego miejsca w romie" bedzie zaczynala sie definicja kolorow?
- czy to musi byc rom
- ile bajtow zajmuje definicja jednego koloru
- Nie. Paleta jest programowana na stałe i nie ma do niej dostępu podczas pracy.
- Nie. Może być FLASH. A właściwie to już jest. :)
- 16
Znalezione posty [ 651 do 675 z 1,305 ]