Przejdź do treści forum
atari.area forum
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
FujiNET firmware v1.5.0 Nowa wersja firmware, która wprowadza szereg ulepszeń i poprawek.
Prima Aprilis Compo 2025 Wystartowała nowa edycja Prima Aprilis Compo, w której obowiązuje jedno wyzwanie - piszemy wyłącznie w Atari BASIC.
maxYMiser FM v1.67 Nowa wersja trackera.
Echa Forevera 23 Wyniki konkursów dla platformy Atari.
Atari Font Maker V1.16.14.4 Narzędzie do projektowania zestawów znaków dla Atari właśnie otrzymało aktualizację
Opcje wyszukiwania (Strona 45 z 49)
jer napisał/a:E tam, zaraz zmieniać MMU. A wyciągnąć nogi danych ROMU z druku i podłączyć przez 244 lub 245 sterowane R/W. Lebo multipleksem jakowymś...
Kiedyś tak zrobiłem karta SRAM do ST. Z lenistwa zrobiłem na switchu zapis/odczyt. Działało jakiś czas.
Po co aż tyle roboty? Nie lepiej odciąć jedną nogę ROM-u (-OE) i podłączyć ją do odwróconego w fazie R/-W ?
Połączenie ze sobą dwóch wyjść NMOS o przeciwnych stanach spowoduje przepływ prądu o natężeniu rzędu 30-40mA. W omawianej sytuacji taki stan będzie trwał mniej więcej połowę czasu. Nic strasznego. W życiu nie zdarzyło mi się uszkodzenie jakiegokolwiek układu cyfrowego przez zwarcie ze sobą wyjść. Zresztą w celach naukowych możesz wykonać eksperyment polegający na odczytaniu zawartości $C000, wykonaniu EOR #$FF i zapisie z powrotem w nieskończonej pętli. Można się założyć o każde pieniądze, że nic się nie stanie.
Zapewne przyjęli założenie, że ewentualne zapisy, które przecież nie wiążą się z niebezpieczeństwem dla układów, mogą być zignorowane. Dodatkowe wejście MMU to konieczność zastosowania większego (i droższego) układu. W czym Ci to konkretnie przeszkadza?
Zapewne krótkotrwały konflikt na magistrali danych. Przewidujesz coś innego?
To nie PBI czegoś wymaga, tylko urządzenie do niego podpięte. Krótkie zakłócenie podczas odczytu zwykłego rejestru, czy pamięci, wywołane zbyt wczesną zmianą adresu w stosunku do mocno obciążonego FI2, przejdzie niezauważone. To samo przy odczycie pamięci FIFO (np. w twardym dysku), skrupulatnie liczącej cykle dostępu, spowoduje utratę danych (lub rozmnożenie przy zapisie), bo policzy zakłócenie jako kolejny cykl. Żeby tego uniknąć, można ustabilizować magistralę adresową (i R/-W) wokół FI2, czyli zapamiętać w rejestrze jej stan w odpowiedniej chwili. Odpowiednia chwila to taka, która: po pierwsze - występuje w nieaktywnej fazie sygnału FI2 (kiedy jest on jeszcze w stanie niskim), po drugie - kiedy adres na magistrali jest już na pewno wystawiony. Zbocze wpisujące stan magistrali do rejestru trzeba jakoś wygenerować z FI2, a w tym celu trzeba je opóźnić o (pi razy oko) 100 nanosekund. Najprościej asynchronicznie - obwodem RC.
Pecus napisał/a:Ja sie zastanawiam po co tyle elektroniki w tym :)
Odpowiedź po roku to może trochę późno, ale lepiej niż wcale. ;) Być może już na to wpadłeś, ale wypada mi sprawę wyjaśnić. Dwa przerzutniki widoczne na schemacie tworzą rejestr przesuwający, który opóźnia sygnał na wejściu szeregowym o dwa cykle bitrate. W tym czasie komputer dokonuje pomiaru prędkości transmisji i ustawia POKEY do odbioru.
Kto właściwie ściga za użycie nielegalnych skoków? Pytam, bo samemu zdarzało mi się kiedyś korzystać z PUTLINE i teraz trochę się boję. ;-)
Jeśli ktoś chce drogą prostego eksperymentu przekonać się o pochodzeniu prążków, niech przetnie krótką, grubą ścieżkę na spodniej stronie płyty, łączącej 9 nóżkę układu CD4050 (masa) przez przelotkę ze ścieżką masową ANTIC-a i CPU, a następnie krótkim kabelkiem połączy tę nóżkę z polem masy po lewej stronie scalaka (np. górne wyprowadzenie kondensatora C51, albo górne lewe wyprowadzenie potencjometru R38) - i zaobserwuje różnicę w wyglądzie prążków.
Żadne poprawki bazujące na dostrzeżonych różnicach w schemacie między seriami XL i XE nie zlikwidują prążków na ekranie. Prążki biorą się z powodu wadliwego projektu płyty a konkretnie - braku wystarczającej separacji między masą części cyfrowej a masą analogową. Trzeba by chyba wyrzucić na osobną płytkę cały tor video od CD4050 poczynając (dobrze wymienić go na szybszy 74HC4050), a na gnieździe monitora kończąc. Zasilanie i masę doprowadzić przez dławiki i może wtedy obraz byłby gładki.
Wymiana jest możliwa, ale na stację 360k, a ta, którą wkładasz, to 1.2M.
tokugawa napisał/a:Dręczy mnie pytanie - jak w temacie:
Po jakim czasie Atari (zwykłe najprostsze 65XE, jestem nowy tutaj :) nie mam modów itd) czyta dane z D0-D7 po wystawieniu adresu na liniach adresowych ?
Lub parafrazując "Ile mam czasu po pojawieniu sie adresu na wystawienie danych na porcie cartridge'a ?
Masz na to przynajmniej 400ns, a realnie więcej - nawet do 500ns.
Opis sygnałów i dokładne timingi znajdziesz tutaj:
http://www.ortodoxism.ro/datasheets/UMC/mXyztwtz.pdf
Od razu dementuję - nie jest to prawda.
Nie jest prawdą, że wersja SECAM produkuje pseudo-kolor z sygnałów luminancji PAL-owskiego GTIA.
W rzeczywistości jest tam inny generator obrazu, FGTIA, zawierający cyfrową część enkodera SECAM. Na płycie znajduje się część analogowa - przetwornik D-A i modulator. Liczba dostępnych kolorów (128) jest mniejsza od wersji PAL (256) za sprawą braku najmłodszego bitu luminancji, wykorzystywanego tylko w tzw. trybach GTIA.
Na sposób analogowy można to zrobić, tylko że to niewiele lub w ogóle nic nie da w porównaniu do podłączenia do wejścia S-Video telewizora. Ostre krawędzie kolorowych elementów obrazu, brak smużenia, zakłóceń i prążków w tle - to da się osiągnąć tylko cyfrowo. Można by, jak to kiedyś zrobił Electron, zastąpić GTIA funkcjonalną kopią na FPGA, ale ZTCP w jego rozwiązaniu nie było PMG i trybów wielokolorowych, a to jednak dość istotne.
Gdzieś u kogoś, w jakimś sejfie musi leżeć dokładna dokumentacja do ANTIC-a, GTIA i POKEY-a. Pytanie - komu trzeba postawić i ile piwa, żeby to wydostać. W końcu chyba nikt już z tym nic więcej nie zrobi.
Po mojemu można by było tak:
1. Generator z pętlą fazową 16*4,433MHz
2. Czterobitowy licznik binarny, taktowany sygnałem z generatora i zerowany narastającym zboczem sygnału 4,433MHz
3. Poczwórny przerzutnik typu D, do którego wpisywany byłby stan w/w licznika narastającym zboczem sygnału koloru z GTIA
4. Dekoder przekształcający stany 0...15 na wyjściu przerzutników na odpowiadające im stany linii RGB.
5. Zsumowanie z sygnałem luminancji (+ewentualna synchronizacja)
Wynik trudno przewidzieć, bo o kolorze decydują różnice czasowe na poziomie czasów propagacji układów TTL.
Do podwojenia częstotliwości odchylania poziomego wystarczy buforowanie 1 linii. Chyba, żeby ze względu na ergonomię celowe okazało się generowanie obrazu na 62,5kHz/100Hz. Wtedy dopiero trzeba by buforować ramkę.
W porządku. Gdzie mam wpłacić?
Pomyślałem o czymś jeszcze - nie ma tam u Ciebie więcej takich "bambusów", mających na zbyciu trochę sprzętu? Jeśli mi wyjdzie to, co planuję (podwojenie częstotliwości linii, czyli standard VGA i to w znacznie prostszym układzie), może znajdzie się jeszcze paru chętnych.
FGTIA ma tylko 3 bity luminancji, w związku z czym wyświetla tylko 8 stopni jasności.
Zrobione. Zdjęcia i schemat układu można sobie pobrać stąd. Wyszły dość kiepsko, bo odbiornik TV LCD wprowadził zbyt dużo własnej inwencji w obróbce sygnału, a z CRT trudno zrobić poprawne zdjęcia. W rzeczywistości wygląda to lepiej, w szczególności jeśli chodzi o odtwarzanie kolorów (zwłaszcza zawierających zieleń). Drobny grzebień, widoczny szczególnie na granicy kolorów czerwonego i niebieskiego, wynika z niedobranych czasów propagacji w torze bezpośrednim i opóźnionym. Na schemacie rolę tę wypełnia układ U12, którego z lenistwa i pośpiechu nie zamontowałem. Ogólnie największy fragment układu to rejestr przesuwny pełniący funkcję pamięci jednej linii koloru. Kto chce, może spróbować to zrealizować przy pomocy mikroprocesora AVR. Trzeba tylko znaleźć kwarc o częstotliwości 1,5*14,31818MHz (dość trudny do zdobycia) lub podwoić częstotliwość kwarcu 10,7MHz (do kupienia bez trudu). To, co wyjdzie wykorzystać wprost do sterowania procesora (6 cykli zegarowych na cykl koloru akurat wystarcza - odczyt z pamięci [2], zapis do portu [1], odczyt z portu [1], zapis do pamięci [2]), a po podzieleniu przez 1,5 - do taktowania FRED-a (żeby było synchronicznie).
Wartości rezystorów w obwodzie matrycowania sygnałów z grubsza obliczyłem i zastosowałem bez eksperymentalnego dobierania. Efekt jest zadowalający, choć pewnie można byłoby to jeszcze nieco poprawić.
Bitman, sprawdziłeś, ile wyniesie wysyłka?
Przyjmę z wdzięcznością. Podaj na @ numer konta i sumę.
Tydzień temu osobiście kupowałem. Na placu samochodowym, pierwsza alejka patrząc od strony Kasprowicza. Goście, oprócz złącz, handlują koszulkami termokurczliwymi i najłatwiej namierzyć ich właśnie po workach z tymi koszulkami.
Jest jeszcze inna możliwość. Wysyłkowo:
http://www.tme.pl/katalog/index.phtml
Po lewej stronie: złącza>złącza audio,video>złącza din audio
Giełda Wolumen, niedziela, 2PLN za sztukę.
Dobra wiadomość - jest (w miarę) prosty sposób na dorobienie do atarynki prawdziwego wyjścia RGB, dzięki któremu obraz kolorowy powinien być ostry jak brzytwa.
Zła wiadomość - dotyczy to, niestety, wyjątkowo rzadko spotykanych komputerów w wersji SECAM z układem FGTIA (CO20120) na pokładzie. Układ ma tę zaletę, że, w odróżnieniu od GTIA, nie dokonuje kompletnego wewnętrznego kodowania sygnału koloru, pozostawiając modulację FM układom zewnętrznym. Sam robi tylko multipleksowanie sygnałów R-Y i B-Y co linię obrazową i wyprowadza wynik na 3-bitowe wyjście. Uzupełnienie układu 228-stopniowym rejestrem przesuwnym, przełącznikiem, matrycą RGB i buforami wyjściowymi wystarcza do uzyskania pełnowartościowego sygnału kolorowego RGB. Pewnym minusem w stosunku do obrazu w systemie PAL jest o połowę mniejsza (128) paleta kolorów, a to za sprawą nieobecności w FGTIA najmłodszego z czterech bitów jasności.
Jakis czas temu wpadł mi w ręce lekko zdewastowany SECAM-owski egzemplarz 130XE (prezent od jednego z forumowiczów), który szczęśliwie udało się zreanimować. Poleżakował sobie trochę na półce, ale w najbliższych dniach mam nadzieję zmontować, co trzeba. Jeśli wszystko pójdzie zgodnie z przewidywaniami, zrobię kilka zdjęć demonstracyjnych. Schemacik dla chętnych też się znajdzie (jeśli tacy będą). Póki co na francuskim ebay-u trudno o 8-bitowe atari, na allegro.pl też nigdy nie zauważyłem takiej wersji. Jak ktoś znajdzie, niech się pochwali. :)
drac030 napisał/a:toriman napisał/a:Ja nie wiem nawet jakie wymiary ma KMK/IDE :/
Uśmiejesz się, ale ja też nie. To znaczy, nie mam oryginalnego interfejsu pod ręką.
Płytka bez złącza - 120x90,6mm. Ze złączem - 139x90,6mm. Pudełko - 129x94x25,5mm
toriman napisał/a:P.S. Nogę Antica można spokojnie odciąć przy statykach a na MMU podać na stałe H na nóżce REF~ ;)
i problem wstrzymywania jest załatwiony...
Ale problem konfliktu adresów na magistrali pozostaje, bo ANTIC nic nie wie o tym, że ma przestać odświeżać pamięć i w cyklach odświeżania nadal będzie wysyłał adres.
Sygnał EXTSEL odcina tylko i wyłącznie RAM, zarówno dla CPU, jak i ANTIC-a. Jest aktywny wszędzie tam i tylko tam, gdzie następuje jakiekolwiek odwołanie do RAM - także w obszarze odłączonego przez PORTB OS lub Basic i w obszarze pakietu zmiennoprzecinkowego odłączonego sygnałem MPD. W tym ostatnim przypadku należy zwrócić uwagę na konflikt z modułami rozszerzeń wykorzystującymi procedury NEWDEV (Karin Maxi, KMK/JZ itp.).
Znalezione posty [ 1,101 do 1,125 z 1,206 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.042 sekund, wykonano 27 zapytań