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ł.👍
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.
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😀
@@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.
Ś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!
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.
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 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.
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
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.
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.
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
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
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.
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.
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ń :)
@@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.
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
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 :)
@@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...
@@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.
@@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.
@@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.
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.
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 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.
@@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.
@@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.
@@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.
Super pomysł, czekam na kolejne odcinki.
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ł.👍
Super. To liczę na feedback.
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.
Ok. Wydawało mi się, że już wyeliminowałem problem. Niestety na YT nie można reeksportowac filmu, żeby go poprawić. Next time.
Super. Czemu ja wcześniej nie znałem Twojego kanału. Od razu SUB
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😀
Dobry pomysł, żeby na koniec to zaimplementować w FPGA. Na razie większym wyzwaniem jest liczba scalakow.
W fpga jest moc. Można poszaleć. Zrobiłem parę implementacji ... Dobrze że będzie na ttlach łatwiejsze do zrozumienia.
@@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.
Zapowiada się bardzo ciekawie
Ś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!
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.
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
Jest sterownik TI, to kompletny układ graficzny ale ma swoje ograniczenia. Głównie bardzo wolny dostęp do vram.
@@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.
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.
Ogólnie walczę z dźwiękiem. Masz jakiś pomysł czego użyć?
@@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.
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
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.
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.
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
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
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.
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.
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ń :)
Fajne wyzwanie ! Czy tylko u mnie brak prawego kanału na filmie ?
Oo, sprawdzę. Może źle wyeksportowalem.
Brak prawego :) ale za to obraz jest stereowizyjny - napisy mi pływają przed oczami np. 4:35
@@TymexComputing zawsze trzeba znaleźć jakieś pozytywy :)
Dawaj!
A gdzie ten link do książki, co? ;)
Ok, link w opisie uzupełniony. Dzięki za czujność :)
@@tmfmikro o mały włos ;) a widzowie by nie kupili książki ;). Pozdro!
Pytanie tylko czy wejdzie tu drzwiami 6845 i czy w latach 80tych taka karta był by droższa od mieszkania w PL
@@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.
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
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 :)
@@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...
@@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.
@@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.
@@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.
Tak z ciekawosci nagrywasz to w mono?
To nagrałem w mono i przez pomyłkę wyeksportowakem jako stereo. Stąd jest jeden kanal teraz nagrywam stereo
Ciekawe oczywiście, choć na Twoim kanale chętniej bym widział programowanie sam i programowanie xmega/sam w C++
Będzie i to.
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.
Oczywiście. Zaczynam od composite. Monitora z tamtych czasów nie mam. ale crt VGA jeszcze się znajdzie.
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.
Jakiś czas temu pojawiło się rozwiązanie softwarowe tego problemu - RPi Pico potrafi generować obraz w standardzie HDMI.
@@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.
@@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.
@@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.
@@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.
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ć 🙂
Następnym razem będzie ok.
super, dzialaj
Moja RTX 4080 Super po prostu wyśmiewa się z tego widea
I po co to , i na co to komu .
Pewnie po nic. Natomiast na co - dla zabawy lub edukacji.