Moja własna karta graficzna retro od podstaw

Рет қаралды 3,296

Күн бұрын

Пікірлер: 67

@tyramisiu 7 ай бұрын

I popracuj nad dźwiękiem, trafiły mi się dwa filmy po rząd (Twój jak drugi) gdzie mowa jest tylko w lewym kanale i już zacząłem kombinować dlaczego mi prawa słuchawka nie działa.

@tmfmikro 7 ай бұрын

Ok. Wydawało mi się, że już wyeliminowałem problem. Niestety na YT nie można reeksportowac filmu, żeby go poprawić. Next time.

@phill2k 7 ай бұрын

Super pomysł, czekam na kolejne odcinki.

@pmcpmc9753 7 ай бұрын

Super. Czemu ja wcześniej nie znałem Twojego kanału. Od razu SUB

@_Jan_Ko_ 7 ай бұрын

Temat jest na tyle interesujący dla mnie że poszedł sub z dzwonkiem. Nawet mam plan powielać kroki z filmów w domu. Jestem ciekaw co z tego wyniknie... bo jest potencjał.👍

@tmfmikro 7 ай бұрын

Super. To liczę na feedback.

@programistrz1971 7 ай бұрын

Świetny pomysł, bardzo mi się podobają te założenia (że nie robisz przy pomocy FPGA). Trzymam kciuki za sukces projektu i już się nie mogę doczekać pierwszego z serii odcinków. :) Dla mnie, prócz możliwości wykorzystania tego z procesorem MOS 6502, interesowałoby też wykorzystanie takiej karty graficznej w 8-bitowych procesorach AVR oraz 32-bitowych ESP32. Pozdrawiam serdecznie!

@tmfmikro 7 ай бұрын

Interfejs będzie uniwersalny, tylko trzeba się liczyć z tym, że ta karta to będzie 100-140 układów scalonych - oczywiście w wersji ze wszystkimi bajerami. Żeby tylko wyświetlać odbraz to pewnie w 40 się zmieścimy. Wersja min to jakieś 20. Ale to tak na oko, bo zobaczymy jakie będą problemy w trakcie budowy.

@karol555-h 7 ай бұрын

Zapowiada się bardzo ciekawie

@elektrodatv 7 ай бұрын

Ciekawy pomysł i dość trudne założenia, cykl będzie miło oglądać szczególnie gdyby udało się utrzymać regularność. Dobrze byłoby później zobaczyć co się stanie gdy zdejmiesz hamulec i wykorzystasz FPGA oraz co tylko chcesz aby wycisnąć maksimum z nowszych technologii😀

@tmfmikro 7 ай бұрын

Dobry pomysł, żeby na koniec to zaimplementować w FPGA. Na razie większym wyzwaniem jest liczba scalakow.

@NorbertKroszka 7 ай бұрын

W fpga jest moc. Można poszaleć. Zrobiłem parę implementacji ... Dobrze że będzie na ttlach łatwiejsze do zrozumienia.

@tmfmikro 7 ай бұрын

@@NorbertKroszka Oczywiście, FPGA wymiatają. Ale też taki projekt dla współczesnego FPGA to pikuś - nie ma zabawy, bo to jest do ogarnięcia w VHDLu w weekend. To też pokazuje jak bardzo wszystko poszło do przodu - rzeczy które kiedyś były wyzwaniem, dzisiaj robi się hobbystycznie.

@TymexComputing 7 ай бұрын

Bardzo fajny projekt! - szczególnie spodobało mi się nakreślenie planu (jak i kamieni milowych) ale takze wskazanie że później plan zostanie ulepszony o trudniejsze elementy np. DRAM. = Odnośnie pytań: - uda się zbudować bo był np. adapter PGC IBM z rozdz. 640x480 256 kolorów - nie musiała być taka toporna i NIE BYŁA bo te kolory w tamtych czasach były naprawdę super :) te pastelowe C64 też - a popularne monitory nie pozwalały na VGA SVGA itp = Co do sugestii 12:21 to jeśli można zasugerowałbym żeby w duchu zielonego ładu, który mam nadzieję zostanie wkrótce rozpędzony, użyć układów CMOS zamiast TTL - S, HS na C, HC - 1cm^2 płytki w technologii TTL zużywa bodajże 0,1 Watta :) = może dodatkowo tryb znakowy :) dla tych co nie są grafikami = Co do wspierania operacji 2D to super pomysł :) tylko że chyba potrzebne będzie specjalistyczne oprogramowanie żeby z tego skorzystać - bo tamto nie korzystało :) na pewno można wymienić takie operacje jak - przesunięcie prostokąta i jego maski - grafika warstwowa (składanie albo chociaż sama maska wyświetlania) - obrót :) - może nie taki matematyczny bo nie zachowuje pikseli ale super obrót można osiągnąć przez tzw. kopnięcie poziome, pionowe i jeszcze raz poziome (skewed rotation) - skalowanie prostokątów

@TymexComputing 7 ай бұрын

Tutaj lista operacji 2D wspieranych w PGC, blitting to operacja do tworzenia maskowanego sprite'a: =================================== Command (ASCII mode) Command byte (HEX mode) Parameters Notes BLKMOV (BK) DF (6 words) A screen-to-screen blit. The first four words define the rectangle to copy; the last two give its new location. BKVMOV (BKV) DD BLINK (BL) E5 BLKRD (BKR) DA (4 words) Screen-to-memory blit. The four words give the opposite corners of a rectangle; all bytes in that rectangle are returned to the caller. Unlike IMAGER, the result is not RLE-compressed. BLKWR (BKW) DB BUTRD (BRD) 54 BUTTBL (BTB) 79 BUTTON (BUT) 78 CONVPV (CPV) AD CONVVP (CVP) AE COPROC (CP) 6B DSPSIZ (DSP) 4D IMGSIZ (IS) 4E width,height, unknown (3 words) Sent at initialisation. Followed by three words; the first two look like they define the framebuffer width and height, but I don't know what the third does. IPREC (IP) E4 LINFUN (LF) EB mode (1 byte) LINFUN is present on the PGC but only supports modes 0 (paint) or 1 (invert). The IM-1024 also accepts 2 (XOR) and 3 (AND). LUT8 (L8) E6 ink, r, g, b (4 bytes) Define an ink in the palette using 8-bit RGB (the PGC uses 4-bit RGB). This is quite a common extension among PGC clones. LUT8RD (L8RD) 53 ink (1 byte) Read back a palette register and return its 8-bit R/G/B values. LOCCUR (LC) 1E LOCMAP (LM) B4 LOCXH (LX) 6C MPOLY (MP) 23 MPOLYR (MPR) 24 NULL 00 OCOLOR (OC) D4 PAN (PA) B7 x,y (words) Sets the origin of the viewable part of the screen. For a 1024×800 display with a 1024×1024 framebuffer, the values passed are (0,-112). This seems to cause the bottom 800 lines to be displayed; that is, -112 corresponds to an offset of 224 lines. PICK (PK) 56 PLINE (PL) 36 1 byte count, then 2 * count words Draw a polyline linking the specified points. PLINER (PLR) 37 Presumably as PLINE, but with coordinates relative to the current drawing position. PVEC (PV) 25 PVECR (PVR) 26 RBAND (RB) E1 READP (RP) 55 none Read the pixel at the current location. Returns a single byte giving the colour. TESTER F3 X2CUR 1E XHAIR (XH) E2 XMOVE (XM) E3 XVMOVE (XV) 1D

@tmfmikro 7 ай бұрын

Właśnie zależy mi na klimacie z początku lat 80-tych, stąd chcę użyć układów S, LS. Wiem, że są prądożerne, ale to też jest dodatkowe wyzwanie. Nie tylko prądy, jakie płyną przez PCB, ale także ich gorsze drivery wyjść - jednak sygnał cyfrowy ze współczesnych scalaków to miód w porównaniu z bałaganem jaki produkują te starocie. To też jest wyzwanie, bo trzeba zadbać, żeby to jakoś działało. BTW, dzięki za tą listę funkcji - nie trafiłem na te karty - wiem, że istniały wtedy zaawansowane rozwiązania, ale to były raczej piekielnie drogie zabawki.

@krzysztofgoebiowski2958 6 ай бұрын

Jak to wyjdzie to jesteś Kozak i moim GURU! Jakieś 10-15 lat temu chciałem zrobić prostą kartę graficzną dla MCU typu AVR z różnymi ficzerami. Wciągnąłem książkę Anatomia PC autorstwa Piotra Metzgera. Chodziło o to że każdy praktycznie ma jakiś starty monitor LCD w domy. Wyświetlacz TFT z kontrolerem to była dość droga sprawa (zwłaszcza powyżej 10" ). Całość miała być napędzana na FPGA. Na początku sięgnąłem po SRAM tutaj ograniczeniem była prędkość kości (100MHz) więc rozdziałka jaką dał bym radę wysterować to 800x600 x 8 bit per pixel. Trochę słabo. Należy pamiętać że też trzeba uzyskać czas na zapis do tej pamięci ponieważ nie tylko czytamy. Potem sięgnąłem po DRAM w trybie burst read/write (bez burst read/write będzie wolniej niż na SRAM bo walnie nas czas RAS to CAS ) i zrobienie cache RAM L1 w samym FPGA . Jedna kość była odczytywana druga zapisywana. Potem zrobiłem podliczenie ile kosztuje FPGA + PCB wyszło że gra nie warta świeczki ponieważ Raspberry wjechało z HDMI i full HD za grosze. Trzymam kciuki i czekam na kolejny odcinek

@tmfmikro 6 ай бұрын

Dawno temu też miałem koncepcje, żeby zrobić kontroler do matryc LCD na FPGA. Ale oczywiście sensu to wielkiego, poza zabawa i nauka, nie ma. Bo były kontrolery typu SSD... Niestety bez jakiejkolwiek akceleracji. Dopiero układy serii ft8xx zmieniły sytuację radykalnie. A dzisiaj... Masz kontroler w niektórych armach.

@krzysztofrudnik4745 6 ай бұрын

W latach 80-tych było sporo książek o systemach mikroprocesorowych i było w nich sporo schematów kontrolerów graficznych, zwykle generujących sygnał TV.

@grzeniu9972 7 ай бұрын

super, dzialaj

@PiRX 7 ай бұрын

Fajne wyzwanie ! Czy tylko u mnie brak prawego kanału na filmie ?

@tmfmikro 7 ай бұрын

Oo, sprawdzę. Może źle wyeksportowalem.

@TymexComputing 7 ай бұрын

Brak prawego :) ale za to obraz jest stereowizyjny - napisy mi pływają przed oczami np. 4:35

@tmfmikro 7 ай бұрын

@@TymexComputing zawsze trzeba znaleźć jakieś pozytywy :)

@marekjakimowicz 7 ай бұрын

Seria będzie bardzo interesująca. Mam tylko nadzieję, że kolejnych filmach dźwięk będzie lepszy, bo w tym się trudno słucha.

@tmfmikro 7 ай бұрын

Ogólnie walczę z dźwiękiem. Masz jakiś pomysł czego użyć?

@marekjakimowicz 7 ай бұрын

@@tmfmikro W sumie nie. Wydaje mi się, że jeśli ścieżka audio z mikrofonu jest mono, to program do montażu powinien to dobrze wkomponować w obraz.

@FerroART Ай бұрын

Zaraz ktoś pewnie powie - " Panie! i poco to Panu potrzebne?! Jest chociaż z tego jakiś PINIĄDZ? Nie ma ? A idź Pan w ### i zajmij się czymś pożytecznym! " ☝️Nie identyfikuję się z tą grupą komentujących 😬 Ja rozumiem dlaczego to zbudowałeś i sam bym chętnie to samo uczynił, ale niestety jestem zbyt głupi żeby takie coś stworzyć, moim zdaniem gdyby więcej było takich twórców na KZbin, to świat byłby piękniejszy 😬 Szacun za cierpliwość i umiejętności, bez których nie zbudował by takiego cacka, czekam na aktualizację projektu, życzę sukcesów i pozdrawiam 👊

@tmfmikro Ай бұрын

Spoko, już tak ktoś napisał :) Dzięki za miłe słowa. Tak naprawdę najtrudniejsze jest zacząć, potem okazuje się, że to wszystko nie jest tak trudne, jak się początkowo wydawało.

@FerroART Ай бұрын

@@tmfmikro A jak! Początki bywają trudne hehe, później już tylko z górki 😬 👊

@fakturyok 7 ай бұрын

W latach 80 tych skorzystałem z gotowego układu generującego wideo. Wykorzystałem go w swojej pracy magisterskiej. Układ korzystał z osobnej pamięci - ale stosunkowo łatwo dało się adoptować oprogramowanie z ZX Spectrum. Do swojego komputera przeniosłem assembler i disassembler oraz kompilatora Pascala. W zasadzie bez zmiany kodu z tego co pamiętam. Wystarczyło opracować procedurę obsługi ekranu taką samą jak w ZX Spectrum. Ale układ ten dawał o wiele lepszy obraz i większą rozdzielczość. Niestety obecnie nie pamiętam jak się on nazywał. Pamiętam że uład ten był "sprowadzony" za pomocą "prywatnego" importu. A były to jeszcze czasy komuny. I jakoś udało się to rozliczyć na politechnice :). Chyba to był jakiś układ Texas'a

@tmfmikro 7 ай бұрын

Jest sterownik TI, to kompletny układ graficzny ale ma swoje ograniczenia. Głównie bardzo wolny dostęp do vram.

@fakturyok 7 ай бұрын

@@tmfmikro Pewnie i tak, ale nie używał on pamięci operacyjnej komputerka. No i były to inne czasy. Nie wiem z resztą czy jakaś inna firma nie produkowała wówczas jakiegoś innego lepszego układu. Ale jestem ciekawy jak będzie wyglądała tutaj ta karta wideo. Z tego co pamiętam to były projekty korzystające ze standardowych układów TTL dla Spectrum tak by nie trzeba było korzystać z ULA.

@Marek_Bogdanowicz 7 ай бұрын

A gdzie ten link do książki, co? ;)

@tmfmikro 7 ай бұрын

Ok, link w opisie uzupełniony. Dzięki za czujność :)

@Marek_Bogdanowicz 7 ай бұрын

@@tmfmikro o mały włos ;) a widzowie by nie kupili książki ;). Pozdro!

@johnymnemonic4657 7 ай бұрын

To było wsparcie sprzętowe.VIC w C64 jest sprzętowym układem generacji grafiki.Musiał mieć dostęp do ramu,gdzie były dane o obrazie.Obsługiwał sprajty.Układy te wspomagały sprzętowo wolne procesory w 8-bitowcach.Paleta była określana na 4 bitach.Obsługa 16 kolorów 0-15,C-64,ZX-Spectrum.

@tmfmikro 7 ай бұрын

VIC-II z C64 był nawet lepszy. Ale ciągle były to wolne układy, bez wsparcia sprzętowego dla grafiki rastrowej z wyjątkiem prostych spritów. Dlatego jest pole do ulepszeń :)

@peterf983 7 ай бұрын

Dawaj!

@McArti0 6 ай бұрын

Pytanie tylko czy wejdzie tu drzwiami 6845 i czy w latach 80tych taka karta był by droższa od mieszkania w PL

@tmfmikro 6 ай бұрын

@@McArti0 6845 zdecydowanie nie. To byłby niezły pomysł, ale pójście na łatwiznę. Co do ceny - trudno powiedzieć. Proste chipy TTL nie były drogie, ale w Polsce był problem z dostępnością. Liczę, że łącznie to będzie ok. 100-150 scalakow w wersji wypasnrj. Ok. 30 w wersji podstawowej.

@MALAHOR18 6 ай бұрын

Tak z ciekawosci nagrywasz to w mono?

@tmfmikro 6 ай бұрын

To nagrałem w mono i przez pomyłkę wyeksportowakem jako stereo. Stąd jest jeden kanal teraz nagrywam stereo

@NorbertKroszka 7 ай бұрын

Użył bym dwie pamięci statyczne oddzielone buforem 3 stanowym. Do jednej zapisujemy swobodnie dane a po zakończonej operacji oddzielamy linie zapisu i adresu od zewnątrz i włączamy zapis w drugiej pamięci która wysyła dane do wyświetlacza wraz z buforem który te pamięci teraz ma za zadanie połączyć by działały na wspólnych liniach. W ten sposób dane z jednej pamięci będą zapisywane do drogiej w trakcie wyświetlania ramki obrazu. By uprościć układ synchronizacji można 2 bity pamięci użyć do synchronizacji a resztę 6 bitów do wyświetlania obrazu po 2 na kolor. W projekcie tym używałem licznika głównego z resetem końca obrazu i wyzwalaniem zapisu i wyzwalaniem końca zapisu. To było najprostsze układowo co zrobiłem co dawało obraz. Maksymalna szybkość zapisu to 30 klatek na sekundę czyli co druga ramka. Zaletą był brak artefaktów . Pamięci do VGA640 x 480 to dwie 512kB 10ns

@tmfmikro 7 ай бұрын

Super pomysł. Ja chciałbym to trochę inaczej zrealizować - jak widziałeś docelowo planuję użyć pamięci DRAM z lat 80-tych, czyli czasy dostępu rzedu 150-250ns. Tym bardziej kwestia konfliktów zapisu do VRAM przez MCU i odczytu przez układ graficzny bedzie istotna. Mam pewien pomysł na rozwiązanie problemu, ale to jeszcze dosyć odległy etap. Generalnie oczywiście jakieś buforowanie, aczkolwiek może niekoniecznie 1:1, bo to zużywa ogrom pamięci. Z drugiej strony ówczesne CPU nie były na tyle szybkie, żeby zapisywac pamięć co takt, więc może tu jest jakaś możliwość na robienie przeplotu. No i sama specyfika DRAM - nie są szybkie, ale operacje w ramach jednego rzędu są jakieś 2x szybsze niż dostęp losowy RAS/CAS. Oczywiście SRAM 10ns rozwiązuje wszystkie problemy, ale to trochę oszukiwanie - jak użycie FPGA :)

@NorbertKroszka 7 ай бұрын

@@tmfmikro w tamtych czasach używano chyba rejestrów prezesuwnych i obraz był o niskiej rozdzielczości. Będzie trudno. Ale dla edukacji może być to o tyle ciekawy projekt że dużo rozwiązań będzie zaprezentowanych i ciekawostek. Wątpię czy w szkołach przekazują taką wiedzę... Będziemy monitorować postępy w projekcie. Jestem za...

@tmfmikro 7 ай бұрын

@@NorbertKroszka Rejestry przesuwne to podstawa. Bardziej mnie martwi Pixel clock dla VGA - wychodzi 40 na na Pixel, dosyć sporo dla starych TTL. Będzie zabawa.

@NorbertKroszka 7 ай бұрын

@@tmfmikro jeszcze jedno. Bawiąc się wyświetlaniem obrazu na monitorze VGA zauważyłem że nie jest ważna ilość pikseli tylko sygnały synchronizacji a dokładniej czasy hs i vs. Trzeba być w tych czasach dość skrupulatnym w obliczeniach. Oczywiście robię to teraz na fpga bo nie chce mi się lutować prototypów na ttlach.

@tmfmikro 7 ай бұрын

@@NorbertKroszka Czasy są istotne, aczkolwiek jest pewna tolerancja. Natomiast monitory bardzo nie lubią jittera - jakiekolwiek, nawet drobne przesunięcia położenia kolejnych impulsów są w stanie kompletnie rozwalić obraz - znaczy nic się nie wyświetla, bo część cyfrowa uznaje, że sygnał się nie nadaje.

@zbikzbik305 7 ай бұрын

Ciekawe oczywiście, choć na Twoim kanale chętniej bym widział programowanie sam i programowanie xmega/sam w C++

@tmfmikro 7 ай бұрын

Będzie i to.

@tyramisiu 7 ай бұрын

Zabrakło jednego punktu - musi korzystać z monitora dostępnego w latach 80. Na końcu cyklu przyda się podsumowanie dotyczące dostępności na tamte czasy tego rozwiązania dla każdego. I obyś nie korzystał z ChataGPT przy projektowaniu tej karty, bo wtedy też tego nie było.

@tmfmikro 7 ай бұрын

Oczywiście. Zaczynam od composite. Monitora z tamtych czasów nie mam. ale crt VGA jeszcze się znajdzie.

@michalp.1484 7 ай бұрын

dźwięk tylko w kanale lewym - koszmarnie się tego słucha na słuchawkach, tym większa szkoda, że treść tak ciekawa, że nie da się wyłączyć 🙂

@tmfmikro 7 ай бұрын

Następnym razem będzie ok.

@macosm7818 7 ай бұрын

O i to jest temat. Szkoda, ze niema tanich, prostych w użyciu i udokumentowanych układów graficznych z wyjściem HDMI do wykorzystania w układach z prostymi MCU.

@tmfmikro 7 ай бұрын

Jakiś czas temu pojawiło się rozwiązanie softwarowe tego problemu - RPi Pico potrafi generować obraz w standardzie HDMI.

@macosm7818 7 ай бұрын

@@tmfmikro Tak widziałem, ale tam są dość spore ograniczenia. Podobnie ESP32 może generować dość dobrze sygnał VGA, a dzięki dwóm rdzeniom zostaje trochę mocy obliczeniowej na sprawnie działającą aplikacje. Jest taki projekt VGA32, który oferuje całkiem ciekawe i sprawnie działające GUI okienkowe.

@macosm7818 7 ай бұрын

@@tmfmikro Są różne bardzo tanie konwertery VGA czy tam CVBS itp. na HDMI, a to oznacza, że prosta karta graficzna 1080p 32bit 60Hz nie stanowi żadnego wyzwania dla współczesnego przemysłu półprzewodnikowego. Jedyne czego brak to pewnie zapotrzebowania.

@tmfmikro 7 ай бұрын

@@macosm7818 Z VGA problem jest o tyle prostszy, że tam są o wiele niższe częstotliwości - z VGRA radzi sobie w miarę nawet zwykły AVR, XMEDA generuje obraz w Hi-Res. W HDMI masz problem związany z minimalną częstotliwością sygnałó cyfrowych i transmisją różnicową. W RPi są dwa rdzenie i PIO, więc może generować HDMI i jeszcze zostaje sporo mocy. ESP32 też będzie ok, bo ma nawet wyższe taktowanie.

@macosm7818 7 ай бұрын

@@tmfmikro Ale bez kilku MB SRAM i mechanizmu DMA praktycznie sprzętowo "wyrzucającego" dane z bufora na ekran to i tak zostaje proste rysowanie grafiki na zasadzie algorytmów. 640x480 w 24 bit to już prawie 1MB na bufor ramki.