Odp: Wyjście HDMI do A8 (PoC)
jak uwazasz, mozesz tez przekompilowac jajco zwiekszajac rozdzielczosc scheludera, ale chyba to nie jest twoj problem
synchronicznie - raczej ciezko, chocby ze wzgledu na to vga (60hz)
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!
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
jak uwazasz, mozesz tez przekompilowac jajco zwiekszajac rozdzielczosc scheludera, ale chyba to nie jest twoj problem
synchronicznie - raczej ciezko, chocby ze wzgledu na to vga (60hz)
Tam nie ma śladu linuxa, wszystko w asemblerze napisane. Procedura obsługi przerwania i rysowania na ekranie (tylko dane antica) to raptem 17 intrukcji w asemblerze w tym 1 skok warunkowy, włączone L1 cache dla danych i dla instrukcji + predykcja skoków. I to by się zgrabnie wyrabiało gdyby nie to że GPU co jakiś czas zatrzymuje CPU pewnie żeby pobrać dane z RAM.
W miarę cykliczne występowanie tego zjawiska widać na screenie. Każda linia jest synchronizowana od lewej strony. Zgodnie z tym jak ANTIC dane śle.
to zrob sobie test - wylacz gpu
gpu zawsze ma priorytet nad cpu jesli chodzi o dostep do ramu, ale to co widac na tym obrazku jest zbyt malo regularne by zgonic wine na gpu
W załącznku wynik testu.
Jak widać ani jednego zgubionego pixela. Potwierdza to moją tezę.
(GPU a właściwie Framebuffer został zainicjowany dopiero po zakończeciu przechwytywania)
Ostatnio edytowany przez willy (2013-02-15 22:13:56)
ok, kilka sekund po submicie moj post sie zdezaktualizowal ;)
Ostatnio edytowany przez jellonek (2013-02-15 22:14:41)
Za każdym razem się na tym łapię. Myli mnie to że trzeba załącznik jeszcze potwierdzić po jego wybraniu.
patrzac na efekt testu - rada candlea rozwiazala problem?
Nie tyle rozwiązała, co potwierdziła źródło problemu.
Da się to oczywiście obejść, ale była by to już sztuka dla sztuki, przekombinowany układ itd.
Kilka ostatnich dni poświęciłem na zapoznanie się ze specyfikacją cyfrowej transmisji danych (DVI/HDMI) oraz zapoznałem się przynajmniej z podstawami vHDL'a oraz z możliwościami FPGA. To jest wręcz stworzone do tego celu.
Od przyszłego tygodnia zaczynam od nowa. Tym razem biorę się za FPGA :)
inaczej piszac - poprzedni eksepryment jedynie zachecil do dalszego zglebiania tematu, podczas gdy wiekszosc ludzi by zniechecil ;)
i o to wlasnie chodzi by sie bawic, a za tem i isc dalej tam, gdzie innym wydaje sie ze nie ma po co ;)
Pytanie do @Candle
Brnę powoli do przodu, i trafiłem na pewną nieścisłość, albo coś namieszałem.
GTIA czyta dane z Antica na dodatnim czy ujemnym zboczy sygnału OSC ? Wg. datahseet GTIA jest to dodatnie zbocze, A w próbie z RPI wyszło mi że na ujemnym, na dodatnim nie wszystko szło jak trzeba.
pcnt to licznik, ktory przy wskazaniu "111" oznacza opadajace zbocze fi2, projekt pracowal na 14mhz, najbezpieczniej bylo dane pobierac w srodku cyklu
Atari_GTIA: process(RUN,CLK_IN,PCNT,AN)
begin
if RUN='1' then
if falling_edge(CLK_IN) and PCNT(1 downto 0)="10" then
BGND<='1';
BLANK<='0';
if AN(2)='0' then
case AN(1 downto 0) is
when "00" => BGND <='1';
when "01" => BLANK <='1';
when "10" => BLANK <='1';
MONO <='0';
when "11" => BLANK <='1';
MONO <='1';
end case;
ANB<=ANB(1 downto 0) & "00";
else
BGND<='0';
if PRIOR(6)='1' then
MONO<='0';
end if;
ANB<=ANB(1 downto 0) & AN(1 downto 0);
end if;
end if;
end if;
end process;
Dzięki, czyli na dodatnim.
acha, ale nie na OSC tylko na FP0
Chyba jednak OSC (przynajmniej wg. dostepnej dokumentacji). W załączeniu 2 linijki z 20 strony pdf'a.
Pozatym rozpisałem sobie na oscylogramie ø2/osc twój licznik, i pcnt - x10 pokrywa się z rosnącym zboczem OSC.
Ostatnio edytowany przez willy (2013-02-23 22:42:31)
a skad antic wie co jest na osc?
GTIA generuje sygnał FØ0 dla Antica, aby ten wystawiał dane na czas (Antic.pdf strona 39 na samym dole tabeli). Jest to przesunięty w fazie OSC.
Ostatnio edytowany przez willy (2013-02-23 22:42:14)
Mały update:
Nie będzie to HDMI tylko DVI-D.
Prace trwają. Od dzisiaj jestem oficjalnie bezrobotny więc będę miał więcej czasu :)
HDMI byloby lepsze, zwlaszcza z dzwiekiem :/
Z HDMI jest taki problem że trzeba płacić za specyfikację ... itd. Poza zasięgiem. (10k$ rocznie + jakieś centy od każdego urządzenia)
Ale ... da się to obejść. Dołożyć kodek, i wpleść dane w ramki video. Jest to niezgodne ze specyfikacją właściwie, nie można nazwać tego HDMI :D i trzeba użyć złącza DVI - Ale działa jak HDMI. Tak robią tańsi producenci kart graficznych.
Sygnały DVI i HDMI są fizycznie zgodne, przejściówki są pasywne. Przy tych rozdzielczościach i częstotliwościach nie ma potrzeby używania EDID itd.
Nie wiem jeszcze jak te dane wpleść pomiędzy video, ale nie wszystko na raz. Jest to owszem w planach, ale to nie na teraz.
Ostatnio edytowany przez willy (2013-03-21 14:04:40)
No to dawaj DisplayPort, na pohybel HDMI ;) A tak !
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.086 sekund, wykonano 16 zapytań ]