Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Battle Tank - gra 3d na AVR

mi_ma 12 Maj 2008 07:23 15320 47
  • Battle Tank - gra 3d na AVR

    Większość starszych elektroników pamięta czasy 8-bitowców, a wspomnienie dawnych gier często wywołuje łezkę w oku. Często staram się wyszukać jakieś projekty pozwalające przywrócić życie starym poczciwym grom, które niekiedy sa o niebo lepsze od nowych wypasionych graficznie produkcji.

    Oto projekt zaimplementowania Battlezone (Atari 1980) na AVR. Wyjaśniając niektórym: w battlezone kierowaliśmy czołgiem w pseudo trójwymiarowym środowisku. Grafika była wektorowa, ale na tamte czasy pozwalała naprawdę poczuć przestrzeń i dobrze się bawić. Oryginał pracował na procesorze 1Mhz 8-bit Motorola 6502 MCU. Autorzy postanowili wykorzystać mikrokontroler 8-bitowy Atmega32 pracujący na 16 Mhz. Schemat i program potrzebny do budowy projektu dostępny jest na stronie źródłowej.

    Battle Tank - gra 3d na AVRBattle Tank - gra 3d na AVR

    Źródło http://instruct1.cit.cornell.edu/courses/ee47...ojects/s2008/jk459_mmi4/jk459_mmi4/index.html


    Fajne! Ranking DIY
  • CControls
  • #2 12 Maj 2008 10:45
    michal512
    Poziom 14  

    Czy jest gdzies film pokazujący dzialanie gry ??

  • #3 12 Maj 2008 11:54
    Konrad_0x42
    Poziom 10  

    mi_ma napisał:
    Oryginał pracował na procesorze 1Mhz 8-bit Motorola 6502 MCU


    1. Mos Technologies a nie Motorola
    2. CPU a nie MCU

  • #4 12 Maj 2008 12:11
    Jacek31
    Warunkowo odblokowany

    He.. He.. Fajny projekt, choć schemat ideowy jest trochę okrojony.
    Moim zdaniem zamiast 2 CPU ATMega32 wystarczyło zastosować ATMega128 i po sprawie. Procesor ten ma dość mocy obliczeniowej i funkcji sprzętowych aby to uciągnąć. Orginał miał przynajmniej z 32 x mniej mocy obliczeniowj i działało.

  • #5 12 Maj 2008 13:42
    willyvmm
    Poziom 26  

    Jacek31 napisał:
    Orginał miał przynajmniej z 32 x mniej mocy obliczeniowj i działało.
    I specjalizowane układy odpowiedzialne za generowanie dźwięku i obrazu. Nie zapominaj o tym !!

  • #6 12 Maj 2008 13:48
    ozman
    Poziom 21  

    Jacek31 napisał:
    Orginał miał przynajmniej z 32 x mniej mocy obliczeniowj i działało.



    Tak ale w oryginale procesor nie zajmował się generowaniem obrazu w pal tylko był do tego osobny układ. Generowanie palu na AVR zajmuje dużo mocy i zostaje mało czasu na inne obliczenia.

  • #7 12 Maj 2008 14:35
    bartek96
    Poziom 12  

    Heh, sam parę ładnych lat temu jako zapalony amigowiec napisałem taką grę na w asemblerze. Wszystko 3D, grafika rastrowa oczywiście, no ta satysfakcja, kiedy wystrzelony pocisk po locie po prajektorii balistycznej trafiał w wysnaczony punkt :) Wszystko działało na Amidze 500+ z prockiem 68000, tylko kurcze nie pamietam teraz jakim zegarem on był taktowany.

    pozdro B.W.

  • CControls
  • #8 12 Maj 2008 14:38
    androot
    VIP Zasłużony dla elektroda

    bartek96 napisał:
    Heh, sam parę ładnych lat temu jako zapalony amigowiec napisałem taką grę na w asemblerze. Wszystko 3D, grafika rastrowa oczywiście, no ta satysfakcja, kiedy wystrzelony pocisk po locie po prajektorii balistycznej trafiał w wysnaczony punkt :) Wszystko działało na Amidze 500+ z prockiem 68000, tylko kurcze nie pamietam teraz jakim zegarem on był taktowany.

    pozdro B.W.


    A500: 7,14MHz

  • #9 13 Maj 2008 12:17
    Jacek31
    Warunkowo odblokowany

    A co za problem kupić układ scalony do syntezy obrazu na PAL. Kosztuje nawet nie 10zł. Na upartego można wziąć nawet RAMDAC z starej karty VGA ISA lub nawet starą kartę w całości. Budowa i programowanie tych układów jest proste, trzeba tylko kupić slot ISA.
    Dla zainteresowanych bardziej, budowę i programowanie karty VGA i SB16 opisano w książce: "Tworzenie gier 2D i 3D w języku Turbo Pascal"

  • #10 13 Maj 2008 13:46
    HeloMelo
    Użytkownik obserwowany

    bartek96 napisał:
    Heh, sam parę ładnych lat temu jako zapalony amigowiec napisałem taką grę na w asemblerze. Wszystko 3D, grafika rastrowa oczywiście, no ta satysfakcja, kiedy wystrzelony pocisk po locie po prajektorii balistycznej trafiał w wysnaczony punkt :) Wszystko działało na Amidze 500+ z prockiem 68000, tylko kurcze nie pamietam teraz jakim zegarem on był taktowany.

    pozdro B.W.


    Zawsze bede mial szacunek dla takich ludzi.



    Konstrukcja bardzo fajna i prosta poza jezykiem i ze znajomoscia jezyka bo to nie takie latwe jak sie samemu w domu robi a nie gdzies na fabryce co pisza programy we pieciu... O satysfakcji nie wspominam :)

  • #11 14 Maj 2008 00:38
    janosikow
    Poziom 13  

    [quote="Jacek31"]A co za problem kupić układ scalony do syntezy obrazu na PAL. Kosztuje nawet nie 10zł. Na upartego można wziąć nawet RAMDAC z starej karty VGA ISA lub nawet starą kartę w całości. Budowa i programowanie tych układów jest proste, trzeba tylko kupić slot ISA.
    Dla zainteresowanych bardziej, budowę i programowanie karty VGA i SB16 opisano w książce: "Tworzenie gier 2D i 3D w języku Turbo Pascal"[/quote]

    A masz może tą książeczkę w wersji elektronicznej ? Bo ciężko dostać...

  • #12 14 Maj 2008 12:18
    Jacek31
    Warunkowo odblokowany

    Książkę pana Piotra Besta „Tworzenie gier 2D i 3D w języku Turbo Pascal” wydało wydawnictwo Helion ( WWW.helion.pl ) . Przykłady programów można było sobie ściągnąć z tej strony, lecz bez książki to mało praktyczne, bo w przykładach jest dużo asemblera procesora 8086 i koprocesora numerycznego 8087, który jest tam opisany.
    Niestety książka jest już tam nie dostępna, wydana została w 2002r. Nie mam wersji elektronicznej, a skanowanie zajęłoby masę czasu, i plik końcowy byłby olbrzymi.
    Gdyby jednak było chętnych kilka osób, mogę zeskanować z niej rozdziały o karcie VGA i SB16.

  • #13 15 Maj 2008 00:28
    tplewa
    Poziom 38  

    Jacek31 napisał:
    Książkę pana Piotra Besta „Tworzenie gier 2D i 3D w języku Turbo Pascal” wydało wydawnictwo Helion ( WWW.helion.pl ) . Przykłady programów można było sobie ściągnąć z tej strony, lecz bez książki to mało praktyczne, bo w przykładach jest dużo asemblera procesora 8086 i koprocesora numerycznego 8087, który jest tam opisany.
    Niestety książka jest już tam nie dostępna, wydana została w 2002r. Nie mam wersji elektronicznej, a skanowanie zajęłoby masę czasu, i plik końcowy byłby olbrzymi.
    Gdyby jednak było chętnych kilka osób, mogę zeskanować z niej rozdziały o karcie VGA i SB16.


    Moim zdaniem troche przesadzasz. Nie ma sie co czepiac do tego projektu jeden zapewnia zapewne generowanie obrazu drugi obliczenia.

    Sam RAMDAC da ci nie wiele bo i tak musisz do niego dostarczyc dane. A moze sie okazac ze nagle musisz przeslac 3 x 8 bit i generowac synchro.
    Co zajmie ci 3 x OUT = 3 cykle na piksel (he he chyba przeginam AVR i TrueColor), mozna uzyc innych trybow i wystarczy przeslac mniej danych.

    Ale np. dla 320x200 256k masz do przeslania 64000 bajtow. Generujac obraz w AVR mozesz wiele uproscic i sterowac przetwornik na rezystorkach jednym OUT. A bity na piksel ograniczyc do 3 - masz wtedy obraz w 3 kolorach.

    Do tego obsluga grafiki zje ci kupe cykli na inne pierdoly. Stare karty nie generuja same obrazu i trzeba im przeslac dane do wyswietlenia. W wypadku 2 x Atmega wolne cykle w ukladzie generujacym obraz mozna uzyc jeszcze do jakis innych celow.

    Natomiast zrobienie czegos takiego na jednej 128 tez bedzie trudne bo nie zostanie ci wiele cykli na obsluge klawiszy itp. Takie cos mozna robic na jednym procku jak np. demko ktore bylo w tym dziale gdzie masz odtwarzane scisle przewidziane wczesniej efekty i nie potrzeba komunikowac sie z uzytkownikiem.

    Nieraz warto przemyslec pewne sprawy, AVR to niestety nie PC czy nawet ATARI lub C64 - tam poza prockiem bylo sporo specjalizowanych ukladow.

    Natomiast w przypadku AVR tracisz duzo cykli na obsludze skokow, instrukcji typu sbi cbi itd. Wiec zaczyna robic sie trudno...

    A jak chceszcos z 3D na PC to moge ci pokazac pare fragmentow z Engine 3D jaki kiedys pisalem na P90 (3D z kamera, lustra, itp. w True Color wszystko importowane z *.3ds)... Pelna optymalizacja lacznie z liczeniem cyklii obsluga koproca i innymi mykami typu skracanie potrzebnych mnozen itp.

  • #14 15 Maj 2008 12:00
    Jacek31
    Warunkowo odblokowany

    Hm jak znajdę czas to poszukam szczegółów konstrukcyjnych tego ATARI. Może miał specjalizowany układ graficzny, ale wątpię, że z lokalną pamięcią graficzną i DMA. To zastosowano dopiero w A500. Więc procesor musiał obsługiwać to programowo, jak w C64 (te samo CPU co ATARI) i ZX80. Sprzętowo może obsługiwał grafikę 2D, może nawet rysowanie linii i wielokątów, ale to nawet programowo można zrobić bardzo wydajne. Wszystko jest kwestia optymalizacji programu. Nie czepiam się projektu, tylko chce pokazać, że można to zrobić też inaczej. Jak są dwa układy scalone to nie ma dla mnie znaczenia czy to dwa procesory, czy jedno CPU i układ graficzny (specjalizowany czy zrobiony na FPGA). Projekt mnie zainteresował, bo w kursie C w EDW był przykład prostego silnika 3D, (co prawda na wyświetlaczu z N3310, ale tam i tak trzeba robić masę rzeczy programowo, a właściwie wszystko) i udało się uzyskać dla prostej animacji przy zegarze 8MHz (ATMega 162) ok 10-12 FPS. Nie wiem tylko ile obiektów sceny obsługiwał silnik. A niektóre ATMegi można taktować 20MHz, bez przetaktu, a nieniego też są podatne. Ale przy współpracy z zewnętrznym RAM ich wydajność znacząco spada.

  • #15 15 Maj 2008 14:49
    tplewa
    Poziom 38  

    FPGA to troche inna sprawa bo w jednej kosci mozesz i dac kilka procesorow do tego niezalezny hardware itp.

    Wszystko zalezy z jaka dokladnoscia musisz generowac sygnaly synchronizacji i wysylac do tego dane. Normalnie w PC miales pamiec obrazu
    o odpowiedniej organizacji ktora musiales wypelnic i fakt brak jakiejkolwiek sprzetowej akceleracji. Swojego czasu byly problemy nawet z przepisywaniem bufora pamieci na PC w wiekszych trybach aby uzyskac rozsadna ilosc FPS. Zmienily to dosc mocno rozkazy MMX i potem juz karty z akceleracja.

    Odnosnie malego ATARI to miales ANTIC ktory poza wyreczeniem procesora z generowania synchra i calej tej sprawy mial bajery wspomagajace w stulu "duszki" itp. Na uC jednoukladowych trzeba sobie upraszczac (obraz na malej liczbie bitow) i robic calosc troche inaczej niz na komputerach.

    AVR-y owszem sa szybkie ale w wielu zastosowaniach robi sie "ciasno".
    Akurat robie teraz taka wmiare prosta pierdole, od ATMEGA128 sampluje sobie dzwiek (96kHz 16bit) + wysyla to do PC i generuje w tym czasie sygnal MLS, i pare pierdulek.

    Dziala to z kwarcem 12.288MHz bo latwo wylazi 96kHz, wiec przerwanie musisz generowac co 128cykli i cala procedura musi zajac ponizej 128cykli. Mi zajela okolo 105... sam widzisz ile pozostaje, a calosc jest bardzo mocno zoptymalizowana i praktycznie zostaly wolne 3 rejestry
    (rezygnowalem z ld, st bo bym sie nie zmiescil) i trace w kilku miejscach czas na nop-y bo musze np. wyrownac ilosc cykli na rozgalezieniach programu...


    Ot taka pierdola gdzie w PC takie sprawy robi lepsza karta dzwiekowa :)

    Z obrazem video jest podobnie i nie ma co odnoscic tego to komputerow stacjonarnych z wyjsciem Video....

  • #16 15 Maj 2008 18:38
    Jimi Hendrix
    Poziom 19  

    Jacek31 napisał:
    Książkę pana Piotra Besta „Tworzenie gier 2D i 3D w języku Turbo Pascal” wydało wydawnictwo Helion ( WWW.helion.pl ) . Przykłady programów można było sobie ściągnąć z tej strony, lecz bez książki to mało praktyczne, bo w przykładach jest dużo asemblera procesora 8086 i koprocesora numerycznego 8087, który jest tam opisany.
    Niestety książka jest już tam nie dostępna, wydana została w 2002r. Nie mam wersji elektronicznej, a skanowanie zajęłoby masę czasu, i plik końcowy byłby olbrzymi.
    Gdyby jednak było chętnych kilka osób, mogę zeskanować z niej rozdziały o karcie VGA i SB16.


    Byłbym bardzo wdzięczny, w szczególności za rozdział na temat VGA.
    W przykładach jest również dosyć ciekawa bibioteka obsługująca tryb graficzny 13h.

    Pozdrawiam

  • #17 15 Maj 2008 19:39
    tplewa
    Poziom 38  

    Jimi Hendrix napisał:
    Jacek31 napisał:
    Książkę pana Piotra Besta „Tworzenie gier 2D i 3D w języku Turbo Pascal” wydało wydawnictwo Helion ( WWW.helion.pl ) . Przykłady programów można było sobie ściągnąć z tej strony, lecz bez książki to mało praktyczne, bo w przykładach jest dużo asemblera procesora 8086 i koprocesora numerycznego 8087, który jest tam opisany.
    Niestety książka jest już tam nie dostępna, wydana została w 2002r. Nie mam wersji elektronicznej, a skanowanie zajęłoby masę czasu, i plik końcowy byłby olbrzymi.
    Gdyby jednak było chętnych kilka osób, mogę zeskanować z niej rozdziały o karcie VGA i SB16.


    Byłbym bardzo wdzięczny, w szczególności za rozdział na temat VGA.
    W przykładach jest również dosyć ciekawa bibioteka obsługująca tryb graficzny 13h.

    Pozdrawiam


    Poczytaj o przerwaniu INT 10 to wszystko, ale lepiej uzywac VESA. Z tym ze to zadziala ci tylko pod DOS-em jak ma byc konkretnie. Pod Windowsem pozostaje ci DirectX lub OpenGL.

    Choc aby cos zrobic konkretnie to musisz uzyc jakis Pmode (Protect Mode) i LFB (linear frame buffer)...

    Inaczej to tylko jakies kreski sobie porysujesz :), a do tego wystarczy przerwanie INT 10h

    Tu masz przyklad obslugi VESA w ASM pod PMODE/W (fragment starego 3D engine - sorry za nazwy etykiet ;) )...

    Jak masz jakies pytania odnosnie VGA itp. w PC to PW

  • #18 15 Maj 2008 23:02
    Jacek31
    Warunkowo odblokowany

    Jimi Hendrix fajnie piszesz tylko, jeżeli nasi koledzy są początkujący to niewiele im przyjdzie z tego, co proponujesz. Twoje informacje są ciekawe, ale to jak na razie masa puzzli, które w dodatku są z kilku różnych układanek. Prawda niestety jest taka, że aby dojść do wyższych metod programowania, trzeba zaczynać właśnie od tych śmiesznych kropek i kresek, aby poznać podstawy. Z drugiej strony niekoniecznie trzeba od razu pisać w dużych rozdzielczościach, a lepiej zaczynać od czegoś małego, niż od razu się zgubić w dużym projekcie.
    Wszystko przychodzi z czasem i praktyką. Opanują podstawy, spodoba się im to pujdą pewnie dalej aż dojdą do DIRECTX. I kto wie może stworzą coś nowego i ciekawego. A zasypywanie ich masą rozbieżnych informacji na pewno im nie pomorze, tylko zrazi.

  • #19 15 Maj 2008 23:05
    Paprykarz
    Poziom 11  

    Jacek31 napisał:
    Hm jak znajdę czas to poszukam szczegółów konstrukcyjnych tego ATARI. Może miał specjalizowany układ graficzny, ale wątpię, że z lokalną pamięcią graficzną i DMA. To zastosowano dopiero w A500. Więc procesor musiał obsługiwać to programowo, jak w C64 (te samo CPU co ATARI) i ZX80. Sprzętowo może obsługiwał grafikę 2D, może nawet rysowanie linii i wielokątów, ale to nawet programowo można zrobić bardzo wydajne. Wszystko jest kwestia optymalizacji programu. Nie czepiam się projektu, tylko chce pokazać, że można to zrobić też inaczej. Jak są dwa układy scalone to nie ma dla mnie znaczenia czy to dwa procesory, czy jedno CPU i układ graficzny (specjalizowany czy zrobiony na FPGA). Projekt mnie zainteresował, bo w kursie C w EDW był przykład prostego silnika 3D, (co prawda na wyświetlaczu z N3310, ale tam i tak trzeba robić masę rzeczy programowo, a właściwie wszystko) i udało się uzyskać dla prostej animacji przy zegarze 8MHz (ATMega 162) ok 10-12 FPS. Nie wiem tylko ile obiektów sceny obsługiwał silnik. A niektóre ATMegi można taktować 20MHz, bez przetaktu, a nieniego też są podatne. Ale przy współpracy z zewnętrznym RAM ich wydajność znacząco spada.


    Wybacz, ale nie wiesz o czym mówisz. Mylisz pojęcia generowania danych do wyświetlenia i generacji samego sygnału wideo. Przy sygnale PAL w maksymalnej rozdzielczości musisz zmieniać sygnał luminacji z prędkością ok. 6MHz, C64 nie był w stanie tego zrobić (1MHz, 1us na cykl procesora).
    Co prawda, wiele można było osiągnąć manipulując rejestrami VIC-a (układ graficzny c64) w trakcie wyświetlania obrazu, ale jak wspomniałem dane do wyświetlenia (reprezentacja w pamięci) oraz generowanie samego sygnału to dwie różne sprawy.

  • #20 15 Maj 2008 23:42
    Jimi Hendrix
    Poziom 19  

    Jacek31 napisał:
    Jimi Hendrix fajnie piszesz tylko, jeżeli nasi koledzy są początkujący to niewiele im przyjdzie z tego, co proponujesz. Twoje informacje są ciekawe, ale to jak na razie masa puzzli, które w dodatku są z kilku różnych układanek. Prawda niestety jest taka, że aby dojść do wyższych metod programowania, trzeba zaczynać właśnie od tych śmiesznych kropek i kresek, aby poznać podstawy. Z drugiej strony niekoniecznie trzeba od razu pisać w dużych rozdzielczościach, a lepiej zaczynać od czegoś małego, niż od razu się zgubić w dużym projekcie.
    Wszystko przychodzi z czasem i praktyką. Opanują podstawy, spodoba się im to pujdą pewnie dalej aż dojdą do DIRECTX. I kto wie może stworzą coś nowego i ciekawego. A zasypywanie ich masą rozbieżnych informacji na pewno im nie pomorze, tylko zrazi.


    To tryb graficzny 320x200 / 256 kolorów, mieszczący się w jednym segmencie pamięci (0A000h). Większość DOS-owych gier była w nim programowana.

    tplewa: dzięki za VESA, ale dużych rozdzielczości nie potrzebuję.

    Szczerze mówiąc, to wszystkie moje obecne działania prowadzą do podłączenia starej, 8-bitowej grafiki ISA (ktoś podłączał?) do szybkiego mikrokontrolera z rdzeniem 8051 (DS89C450). Myślę, że przy tych 33 MIPSach da radę już jakieś sensowne demko napisać. Jakieś tam doświadczenie z assemblerem x86 i 8051 mam, więc to chyba nie problem.

    Szukam również przykładów jak oprogramować kartę VGA bez użycia przerwań (nie będę miał 10h na uC).

    Pozdrawiam serdecznie

  • #21 15 Maj 2008 23:54
    tplewa
    Poziom 38  

    Jacek31

    tylko obsluga DirectX czy OpenGL to calkiem inna bajka niz standardowych trybow VGA. Taka zabawa w sumie za wiele nie zmieni...

    Fakt tryb 13h (320x256 256kolorow) ma pewna zalete... pixel jest kodowany na jednym bajcie i bardzo to ulatwia sprawe. Ale jak mowilem tutaj nie ma jakiejs filozofii, dajesz

    mov ah,0
    mov al,13h
    int 10h

    i masz odpalony tryb... Przy obecnej szybkosci komputerow takie zabawy moga przyniesc zgubne skutki :) bo nawet nie zoptymalizowany kod bedzie smigal szybko. Jak sie nie nauczysz optymalizacji kodu to potem nawet akcelerator 3d wiele nie pomoze.

    Kolejna sprawa to nawet w tych prostych trybach pod dosem trudno sie bylo obyc bez protect mode, a ucznenie sie teraz pisania pod jakis Pmode (Tran, PMODE/W, EOS) jest troche bez sensu... to juz nie ta epoka...


    Zaczac zabawe trzeba by od nauki programowania i to na bardzo dobrym poziomie, pozostawiajac z boku Turbopascala itp. Potem duzo matematyki
    bo to jest bardzo potrzebne w grafice 3d (glownie macierze)...

    Prawde mowiac jak ktos zaczyna najlepiej odrazu brac sie za DirectX jesli chcemy programowac pod Windows... Ewentualnie OpenGL (mi sie pod OpenGL pisze przyjemniej), bedzie sporo latwiej. I nie mowie tutaj odrazu o pisaniu gry - tylko zabawy w stylu eysowania prostych elementow...

    Dodano po 6 [minuty]:

    Jimi Hendrix napisał:


    tplewa: dzięki za VESA, ale dużych rozdzielczości nie potrzebuję.

    Szczerze mówiąc, to wszystkie moje obecne działania prowadzą do podłączenia starej, 8-bitowej grafiki ISA (ktoś podłączał?) do szybkiego mikrokontrolera z rdzeniem 8051 (DS89C450). Myślę, że przy tych 33 MIPSach da radę już jakieś sensowne demko napisać. Jakieś tam doświadczenie z assemblerem x86 i 8051 mam, więc to chyba nie problem.

    Szukam również przykładów jak oprogramować kartę VGA bez użycia przerwań (nie będę miał 10h na uC).

    Pozdrawiam serdecznie


    VGA z PC pod u-C to nie najlepsze rozwiazanie...

    Lepiej zrobic na czyms innym kontroler obslugujacy taki tryb :) np. FPGA

    Mozna pomyslec lepiej o jakims gnacie z ATARI lub C64 bedzie latwiej...

    Za VGA z PC mozna by sie brac majac jakiegos 16bitowca przynajmniej aby to mialo sens...

  • #22 16 Maj 2008 00:54
    Jimi Hendrix
    Poziom 19  

    tplewa napisał:
    Jacek31
    VGA z PC pod u-C to nie najlepsze rozwiazanie...

    Lepiej zrobic na czyms innym kontroler obslugujacy taki tryb :) np. FPGA

    Mozna pomyslec lepiej o jakims gnacie z ATARI lub C64 bedzie latwiej...

    Za VGA z PC mozna by sie brac majac jakiegos 16bitowca przynajmniej aby to mialo sens...


    Dlaczego nie? Zaadresuję to jako pamięć i zobaczymy co z tego wyjdzie. Cudow się raczej i tak nie spodziewam.

    Pozdrawiam

  • #23 16 Maj 2008 01:14
    tplewa
    Poziom 38  

    Jimi Hendrix napisał:
    tplewa napisał:
    Jacek31
    VGA z PC pod u-C to nie najlepsze rozwiazanie...

    Lepiej zrobic na czyms innym kontroler obslugujacy taki tryb :) np. FPGA

    Mozna pomyslec lepiej o jakims gnacie z ATARI lub C64 bedzie latwiej...

    Za VGA z PC mozna by sie brac majac jakiegos 16bitowca przynajmniej aby to mialo sens...


    Dlaczego nie? Zaadresuję to jako pamięć i zobaczymy co z tego wyjdzie. Cudow się raczej i tak nie spodziewam.

    Pozdrawiam


    To zobacz ile masz do zaadresowania:

    320 * 200 = FA00 = 0b1111101000000000

    i to jest tylko sama pamiec obrazu, a gdzie reszta ???

    Bedziesz musial zrobic jakos bankowanie itp. bedzie to upierdliwe...

    ale dobra z tym sobie poradziles... chcesz zapisac sobie obraz...

    Nie wiem ile temu prockowi zajmuje zapis do pamieci...
    w AVR-ach np. st zajmuje 2 cykle do tego musisz jeszcze przelaczac banki... w sumie z ladowaniem do rejestru ldi czyli 3 cykle.

    Ty dalej masz redzen 51 czyli musiz uzyc akumulatora i bedzie to wiecej cykli procesora... Ale liczmy ze niech to bedzie zakladane 3 cykle :)

    3 * 64000 = 192000 cykli procesora na ramke... i to tylko wypelnianie stala wartoscia. Gdzie rysowanie zwlaszcza ze bedzie to utrudnione (bankowanie)...

    A pamietaj ze powinienes przepisac cale dane do pamieci karty w momencie wygaszania bo bedzie ci migac niesamowicie...

  • #24 16 Maj 2008 09:19
    Jacek31
    Warunkowo odblokowany

    Oj pomyliłem pana Jimi Hendrix z Tplewa w moim ostatnim poście. Przepraszam. Zakrenciłem się.

    Dodano po 28 [minuty]:

    Jak chcesz wykorzystywać procesory DS. to jest taka fajna maszynka jak DS80C390. Tu masz podstawowe parametry:
    80C52 compatible
    - 8051 instruction-set compatible
    - Four 8-bit I/O ports
    - Three 16-bit timer/counters
    - 256 bytes scratchpad RAM
    - High-Speed Architecture
    - clocks/machine cycle (8051=12)
    - Runs DC to 40 MHz clock rates
    - Frequency multiplier reduces EMI
    - Single-cycle instruction in 100 ns
    - 16/32-bit math coprocessor
    - 4 kB internal SRAM usable as
    program/data/stack memory
    - Enhanced memory architecture
    - Addresses up to 4 MB external
    - Defaults to true 8051 memory compatibility
    - User-enabled 22-bit program/data counter
    - 16-Bit/22-bit paged/22-bit contiguous modes
    - User-selectable multiplexed / nonmultiplexed
    memory interface
    - Optional 10 bit stack pointer
    - Two full-function CAN 2.0B controllers
    - message centers per controller
    - Standard 11-bit or extended 29-bit
    identification modes
    - Supports DeviceNet, SDS, and higher layer
    CAN protocols
    - Disables transmitter during autobaud
    - SIESTA low power mode
    - Two full-duplex hardware serial ports
    - Programmable IrDA clock
    - High integration controller includes
    - Power-fail reset
    - Early-warning power-fail interrupt
    - Programmable watchdog timer
    - Oscillator-fail detection
    - 16 total interrupt sources with 6 external
    - Available in 64-pin QFP, 68-pin PLCC
    Jest to bardzo rozbudowane CPU, o udoskonalonym rdzeniu 8051 I możliwości adresowania do 4MB RAM, z koprocesorem 16/32bit (prostym mnożenie, dzielenie i parę tam innych, ale zawsze to coś) Ale nie wiem czy w ktoś w Polsce go sprzedaje. Tak na dobrą sprawę to połowa płyty głównej PC XT w jednym scalaku. Co zaś się tyczy problemu z buforem graficznym dla karty VGA, to żaden problem? Do 51 można spokojnie podłączyć 128KB RAM (np. SR621024D), tylko wtedy najstarszy bit adresu musisz podłączyć do jakiegoś wolnego pinu procesora. Za jego pomocą będziesz się przełanczał między 1 i 2 strona pamięci. Wtedy uzyskasz 64KB na bufor VGA i 64KB na dane dla siebie. Do płynnej animacji wystarczy ci jak uzyskasz 15 FPS dla przesyłania danych obrazu, inna sprawa że można stosować sztuczkę z przeplotem,

  • #25 16 Maj 2008 17:17
    tplewa
    Poziom 38  

    Cytat:
    tylko wtedy najstarszy bit adresu musisz podłączyć do jakiegoś wolnego pinu procesora. Za jego pomocą będziesz się przełanczał między 1 i 2 strona pamięci. Wtedy uzyskasz 64KB na bufor VGA i 64KB na dane dla siebie.


    Ot wlasnie wspomnialem o bankowaniu :) To idzie zrobic na kazdym procku :)

    I tak to uproscilem bo aby to mialo sens musisz miec 2x 64000 bajty.

    Jeden obszar to odwzorowanie karty graficznej i drugi jakas twoja pamiec.
    Na twoejej pamieci robisz operacje (rysujesz) i przepisujesz w trakcje powrotu plamki. Tak sie to robi na PC, inaczej nawet majac 25fps to bedzie wygladalo kiszkowato (jak zaczniesz rysowac na pamieci karty).

    Kolejna sprawa to musisz uzywac arytmetyki 16 bitowej do rysowania co zje ci na 8bitowcu kolejne cykle. Te przepisanie pamieci to tez jak wspomnialem mocno uproscilem - napisz procke przepisujaca pamiec i policz ile ci to zajmie cykli na przepisanie jedneko pixela i calej pamieci.

    Jak dla mnie nie tedy droga bo mozna to zrobic inaczei i lepiej niz uzywajac VGA... to bedzie poprostu armata na muche...

    P.S.

    Dallas dosc czesto bajeruje :) wiele procesorow ktore reklamowali - nigdy nie powstalo :) Kiedys tak mialem zobaczylem reklame i chcialem kupic - i co sie okazalo ze takiego procesora nie ma. Mial byc wypuszczony na rynek, a nie wypuscili :)

  • #26 16 Maj 2008 18:05
    Jimi Hendrix
    Poziom 19  

    Oczywiście musi być te bankowanie.
    Jako moją pamięć RAM wykorzystalem pamięc cache z jakiejś płyty głównej 486. Działa bez problemu.

    MOVX ma w tym mikrokontrolerze możliwość regulacji od dwóch do dziewięciu cykli - jeden cykl maszynowy na megaherc.

    Obecnie czekam tylko na gniazdo ISA i zaczynam kombinować. Będę mieć wobec tego trzy banki pamięci - mój RAM, VGA RAM i VGA I/O.

    Mam pytanie - czy kartę muszę jakoś zainicjować? Czy wystarczy wybrać rejestrem tryb 13h i zapisywać do pamięci?

    Pozdrawiam

    ps. jakby mi to nie wystarczylo to zamowie sampla tego DS80C390 i zobaczymy.

  • #27 16 Maj 2008 21:03
    tplewa
    Poziom 38  

    Jimi Hendrix napisał:
    Oczywiście musi być te bankowanie.
    Jako moją pamięć RAM wykorzystalem pamięc cache z jakiejś płyty głównej 486. Działa bez problemu.

    MOVX ma w tym mikrokontrolerze możliwość regulacji od dwóch do dziewięciu cykli - jeden cykl maszynowy na megaherc.

    Obecnie czekam tylko na gniazdo ISA i zaczynam kombinować. Będę mieć wobec tego trzy banki pamięci - mój RAM, VGA RAM i VGA I/O.

    Mam pytanie - czy kartę muszę jakoś zainicjować? Czy wystarczy wybrać rejestrem tryb 13h i zapisywać do pamięci?

    Pozdrawiam

    ps. jakby mi to nie wystarczylo to zamowie sampla tego DS80C390 i zobaczymy.


    Musisz inicjowac z tego co pamietam miedzy innymi rejestry odblokowania karty (3C3h), rejestry PEL itp. ale dokladnie nie pamietam bo bawilem sie tym gdzies w okolicach 96 roku :) Poszukam moze mam gdzies stare zrodla...

  • #28 17 Maj 2008 16:57
    Jacek31
    Warunkowo odblokowany

    Tylko do tego DS80C390 poszukaj sobie najpierw odpowiedniego kompilatora C, bo ma rozszerzoną listę instrukcji (Obsługa 4MB przestrzeni adresowej w trybie liniowym i koprocesor). Zwykłe mogą go nie obsługiwać w pełni. A układ ten jest trochę wolniejszy od DS80C450, bo na jeden cykl maszynowy potrzebuje 4 taktów zegara, więc jego wydajność jest większa 3x od zwykłej 51. To ogólnie konstrukcja trochę starsza od 450.
    Nie za bardzo rozumiem problemy, jakie ma kolega tplewa z tymi buforami, :?: bo wystarczy jeden, a kopiowanie do pamięci lokalnej karty to żaden problem, rozwiązuje to prosta sztuczka polegająca na wysyłaniu zawartości bufora w dwóch etapach (po połowie) w czasie powrotu pionowego. Mam tak działający program w TP ( z wspomnianej książki) i działa to bez zarzutu tak w 2D jak i 3D.:idea:

  • #29 17 Maj 2008 19:50
    tplewa
    Poziom 38  

    Jacek31 problem ilosci cykli i napisalem ze jeden bufor to odwzorowanie pamieci karty w przestrzeni adresowej, a drugi to bufor w ktorym rysujesz.

    Wysylanie po polowie napewno dobrze nie wyglada. Nawet kiedys na "scenie PC" bys mial gwizdy za cos takiego w demku :)

    Nie wiem po co to robic na PC w dodatku gdzie tryb 320x200 256 w okresie Pentium nie byl problemem, problemem zaczely robic sie tryby TrueColor.
    Zauwaz ze w PC miales juz kiedys rejestry EAX, EBX czyli zobacz ile bajtow (pixeli) mozesz przeslac za jednym zamachem.

    W screen.asm masz przyklad kopiowania duzego buforu z instrukcjami MMX (dodane opisy):

    Code:

    MMX_COPY:
       mov   esi,[BuforEkranu2] ; Bufor gdzie rysujesz
       shr   ecx,4
       mov   edi,[LFB] ; LFB - linear frame buffer (czyli liniowo odzwierciedlona pamiec karty VGA)
       call   Wait_Vrt
    pxxxxxxxmmx:
       movq1   mm0,[esi]
       movq1   mm1,[esi+8]
       movq1   mm2,[esi+16]
       movq1   mm3,[esi+24]
       movq1   mm4,[esi+32]
       movq1   mm5,[esi+40]
       movq1   mm6,[esi+48]
       movq1   mm7,[esi+56]
       
       movq2   [edi],mm0
       movq2   [edi+8],mm1
       movq2   [edi+16],mm2
       movq2   [edi+24],mm3
       movq2   [edi+32],mm4
       movq2   [edi+40],mm5
       movq2   [edi+48],mm6
       movq2   [edi+56],mm7

       add   esi,64
       add   edi,64
       dec   ecx
       jnz   pxxxxxxxmmx      
       emms   
       ret


    to jest moje rozwiazanie gdzies z roku 1997 - pierwsze procki z MMX...
    Wiec ta kasiazka to raczej rewelacja nie jest jak tam teraz kopiuja na dwa loop-y.

    Niestety 51 to nie PC, nie dosc ze na kazdy przeslany bajt musisz zmieniac banki itp. to troche tych danych jest do przeslania. Do tego przesylasz po bajcie :) Taki problem tez byl na PC dlatego uzywalo sie VESA i odpalalo LFB aby nie trzeba bylo przelaczac bankow.
    Do tego poza przesylaniem (wyswietlaniem) fajnie by bylo aby procek cos robil... A narysowanie jakiejs sceny w 256 kolorach i takiej rozdzielczosci na 51 to bedzie troche rysowania. Natomiast aby rysowac kreski to takie rozwiazanie mija sie z celem bo mozna to zrobic bez VGA.

    Dlatego mowie ze lepiej tutaj wziasc jakis 16 bitowy procek np. ARM-a...

  • #30 17 Maj 2008 22:30
    Jacek31
    Warunkowo odblokowany

    ARM-y bezproblemowo obecnie dostępne w Polsce tak przy okazji są 32-bitowe, a nie, 16 (co nie znaczy, że takich nie było czy nie ma), ale tylko najsilniejsze mają dość zasobów i możliwość obsługi zewnętrznego RAMu który potrzebujemy. Pozostaje jeszcze kwestia, co nasz kolega chce uzyskać? Może chce dowieść, że 51 da rade uciągnąć kartę VGA i nie zależy mu na MMX, 1024x768 16bit kolor. Nie musi chcieć przenosić na to obrazu Quke czy Doom. Natomiast gierkę, która była inspiracją tego tematu, powinno się dać uciągnąć na takim CPU. Brak tekstur, tylko grafika typowo na wektorach to nie takie trudne, ja coś takiego (animowana głowa, ogólnie prościutkie, ale na moją ówczesną wiedze sądze niezłe) skleciłem w TP jak jeszcze chodziłem do szkoły, bez asemblera i śmigało na P60, no i nie musi koniecznie wykorzystywać 320x240 z 256 kolorami, karta VGA ma jeszcze kilka innych trybów, wcale nie mniej ciekawych
    Dla kolegi który kombinuje z VGA.
    Funkcjia 13h jest funkcją BIOSu w PC, a nie rejestrem w karcie graficznej.
    Musisz sobie najpierw poszukać opis rejestrów karty VGA. Na podstawie ich znajomości oprogramujesz (zrobisz sterownik) do niej.