Wiadomość wysłana przez: zielok__ w 03 Marca 2009, 20:18
A wiec chcialbym sie dowiedziec czy tak ja to sobie rozplanowalem ma sens czy gdzie jakis fatalny blad popelniam lub ewentualnie mozna to zrobic lepiej.
Zalozenia - wektory na znakach (czyli 128px x 128px)
1) Robie tablice o wielkosci 256 bajtow na SIN i COS - Oczywiscie uwzgleniam tu 360 stopni, tablice do perspective projection (takze o wielkosci 256 bajtow)
2) wartosci punktow i katy obroty wokol oi trzymam w jednym bajcie (oczywiscie na kazda wartosc)
3) wykonuje dzialanie czyli
punkt*cos,x - kazda z wartosci jest 8 bitowa wynik uzyskuje 16 bitowy
punkt*sin,x - tak samo jak wyzej
otrzymane wartosci 16 bitowe odejmuje (lub dodaje w zaleznosci od tego wokol ktorej robie osi)
4) otrzymana wartosc zamieniam na 8 bitowa (aby moc robic nastepne przeksztalcenia mnozacz dwie 8 bitowe wartosci) - i tutaj sie zastanawiam czy nie strace na dokladnosci
5) obracam wokol osi ktore potrzbuje stosujac punkt 3 i 4
6) nastepnie robie perspective projection stosujac tablice wykonana w punkcie 1 mnozac punkt X (czy Y). W tym przypadku znowu mnoze dwie wartosci 8 bitowe i biore tylko wyzszy bajt.
Zrobilem sobie te obliczenia w Excelu (aby sprawdzic czy nie bedzie za duzych zaokraglen) i wynik wyglada na zadawalajacy (minimalne odchylenia)
Resumujac chcialbym wiedziec zanim zaczne to pisac na c64 czy tak jak chce to zrobic jest ok? A moze da sie zrobic to lepiej?
Wiadomość wysłana przez: Nitro__ w 03 Marca 2009, 21:05
Wiesz, jest pewna seria artykulow, gdzie opisane jest robienie wektorow w praktycznie wszystkich aspektach(chociaz sa dosyc stare, jest miejsce na optymalizacje, aktualne osiagniecia), pytanie czy chcesz sobie psuc zabawe
![\"Wink\"](\"images/smiles/icon_wink.gif\"){kind=icon}
Wiadomość wysłana przez: zielok__ w 03 Marca 2009, 21:36
| Nitro napisal: |
| Teoria chyba w porzadku, ale z szybkoscia tego moze byc srednio, pewnie twoje procedury mnozenia wcinaja troche czasu, jak widze po opisie -> 16 bitowy wynik. |
Hmm, tutaj to raczej bym sie nie martwil aby pomnozyc dwie 8 bitowe liczby i uzyskac 16 bitowy wynik to w skrocie - odczytanie z tablicy wartosci, nastepnie odejmowanie, zapis, odczyt z tablic, odejmowanie i zapis w komorce. I wtedy juz mamy wynik mnozenia w 16 bitach... Czyli szybko
![\"Smile\"](\"images/smiles/icon_smile.gif\"){kind=icon}
| Cytat: |
| Wiesz, jest pewna seria artykulow, gdzie opisane jest robienie wektorow w praktycznie wszystkich aspektach(chociaz sa dosyc stare, jest miejsce na optymalizacje, aktualne osiagniecia), pytanie czy chcesz sobie psuc zabawe |
Narazie nie chce psuc sobie zabawy. Sam algorytm moim zadaniem wydaje sie niezly (wszystko w miare optymalnie wyglada w zalozeniach). Oczywiscie jak napisze kod to on juz napewno bedzie mogl zostac mocno zooptymalizowany ale jednak 12 lat przerwy robi swoje.
ps. Chociaz daj moze linka do tej serii artykulow. Moze cos ciekawego tam zobacze....
Wiadomość wysłana przez: prezes__ w 04 Marca 2009, 09:34
![\"Very](\"images/smiles/icon_biggrin.gif\"){kind=icon}
Wiadomość wysłana przez: smiglo .::.__ w 05 Marca 2009, 09:51
Wiadomość wysłana przez: Nitro__ w 05 Marca 2009, 17:11
| Cytat: |
Hmm, tutaj to raczej bym sie nie martwil aby pomnozyc dwie 8 bitowe liczby i uzyskac 16 bitowy wynik to w skrocie - odczytanie z tablicy wartosci, nastepnie odejmowanie, zapis, odczyt z tablic, odejmowanie i zapis w komorce. I wtedy juz mamy wynik mnozenia w 16 bitach... Czyli szybko Smile |
Myslalem, ze moze mnozysz bez tablic.
| Cytat: |
| Narazie nie chce psuc sobie zabawy. Sam algorytm moim zadaniem wydaje sie niezly (wszystko w miare optymalnie wyglada w zalozeniach). Oczywiscie jak napisze kod to on juz napewno bedzie mogl zostac mocno zooptymalizowany ale jednak 12 lat przerwy robi swoje. ps. Chociaz daj moze linka do tej serii artykulow. Moze cos ciekawego tam zobacze.... |
Mimo wszystko jeszcze raz zapytam, czy chcesz ten art, moze lepiej skoduj po prostu swoj sposob, a jesli napotkasz problemy/skonczysz, to dam Ci link.
Wiadomość wysłana przez: zielok__ w 05 Marca 2009, 18:50
| Nitro napisal: |
Mimo wszystko jeszcze raz zapytam, czy chcesz ten art, moze lepiej skoduj po prostu swoj sposob, a jesli napotkasz problemy/skonczysz, to dam Ci link. |
Ok.. pobawimy sie
Jak skoduje dwie wersje to porownam.Apropo to w c++ na PC juz napisalem (oczywiscie przyjmujac dokladnosc tak jak na c64 i stosujac te same dzialania). Dziala w pelni zadawalajaco (tj. wektory sa dokladne na 8bitowych tablicach sinusow zreszta calosc napisalem tak jak pisalem w pierwszym poscie). Teraz pozostaje napisac to na c64.
Druga wersja to bedzie zastosowanie macierzy obrotu itd, ktore to powinny przyspieszyc jeszcze sprawe.
Wiadomość wysłana przez: wegi w 13 Lipca 2009, 23:40
Wiadomość wysłana przez: zielok__ w 14 Lipca 2009, 10:47
Wiadomość wysłana przez: zielok__ w 08 Maja 2010, 18:58
| zielok napisal: |
| Ja to wiem, ze tak najlepiej tylko, ze nigdy stacji nie kodowalem |
A jednak nie
Stacja z powodu malej ilosci pamieci i braku miejsca nie pozwoli szybko przeliczyc wielu punktow. Owszem dla kilkunastu punktow da pewnie przyspieszenie ale czym wieksza ilosc punktow do przeliczenia tym obliczanie w stacji dyskow bedzie proporcjonalnie wolniejsze.
Wiadomość wysłana przez: Kisiel w 08 Maja 2010, 19:04
Wiadomość wysłana przez: Nitro__ w 08 Maja 2010, 19:09
Wiadomość wysłana przez: leming__ w 08 Maja 2010, 21:07
Wiadomość wysłana przez: Kisiel w 08 Maja 2010, 21:19
Wiadomość wysłana przez: zielok__ w 08 Maja 2010, 22:01
| kisiel napisal: |
| IMHO z pozycji kodera to lepiej policzyc w stacji i rysowac w komciu. |
IHMO nie...
Policz dla DOWOLNEGO obiektu skladajacego sie powiedzmy z 40 punktow obroty w 3 osiach w stacji lub komodorku...
Komcio to juz dawno przeliczy i namaluje a stacja nie zwroci jeszcze wyniku obliczen...
Gdyby stacja miala wiecej pamieci to mozna zrobic lepsze tabelki dla mnozen i wtedy bylaby szybsza.
Wiadomość wysłana przez: Nitro__ w 08 Maja 2010, 22:30
Chociaz proponuje tez poznac sposob na plotery, ponad 256 dotsow w ramce, choc bez perspektywy, to chyba jest standardem teraz, a nie zmudne mnozenia(patrz notke do EoD).
Wiadomość wysłana przez: zielok__ w 09 Maja 2010, 08:36
\"Mnozenie\" trzeba zawsze wykonac (tylko nie jest takie zwykle matematyczne mnozenie bo byloby za wolne tylko uzyskujemy od razu wynik - kilka cykli na mnozenie (ktore jest zwyklym dodawaniem wartosci:))) bo inaczej raczej nie da sie przeliczyc punktow.
Zreszta to \"mnozenie\" u mnie wyglada tak:
lda $xxxx
adc $yyyy
adc $zzzz
- tu \"mnoze\" trzy wartosci 8bitowe ze znakiem i uzyskuje wynik 8 bitowy ze znakiem (oczywiscie odpowiednio pomniejszego do przestrzeni 8 bitow)
W gwoli wyjasnienia to inne techniki optymalizacyjne takze mi sa znane (np. obliczenie niektorych punktow na podstawie innych - gdzie uzyskujemy przeksztalcenie punktu w trzech osiach wraz z rzutowaniem w kilku cyklach)
Co do EOD to nie wiem jak to tam jest rozwiazane (nie chce mi sie /nie umiem/ analizowac czyjegos kodu) ale sadze, ze jest to podobnie jak u mnie.
Oczywiscie mozemy na karb stacji przerzucic kilka(nascie) punktow i wtedy mamy maksymalna wydajnosc tylko to co pisze Kisiel , ze lepiej policzyc w stacji i malowac komciem jest wprowadzaniem w blad bo w stacji nie da sie za duzo punktow policzyc.
Wiadomość wysłana przez: Jacek31 w 09 Maja 2010, 09:57
Wiadomość wysłana przez: Nitro__ w 09 Maja 2010, 11:54
Wspomniane arty, nazywaja sie \"A Different Perspective\":
http://www.ffd2.com/fridge/chacking/c=hacking8.txt
http://www.ffd2.com/fridge/chacking/c=hacking9.txt
http://www.ffd2.com/fridge/chacking/c=hacking10.txt
Choc jak widac moga sluzyc tylko i wylacznie celom edukacyjnym, wszystko sie rozwinelo.
Wiadomość wysłana przez: zielok__ w 15 Maja 2010, 20:46
ps. Przeliczam juz 380 punktow na frame (teraz biore sie jeszcze za generacje speedcode (bo na razie to dziala w petli)
Wiadomość wysłana przez: fenek__ w 23 Maja 2010, 16:58
| zielok napisal: |
Zreszta to \"mnozenie\" u mnie wyglada tak: lda $xxxx adc $yyyy adc $zzzz - tu \"mnoze\" trzy wartosci 8bitowe ze znakiem i uzyskuje wynik 8 bitowy ze znakiem (oczywiscie odpowiednio pomniejszego do przestrzeni 8 bitow) |
Ja tylko pytam z czystej ciekawosci, rozumiem ze wczesniej liczysz macierz 9 elementow ? Ja cos takiego robilem do obracania prostych obiektow, wektory \"cartoon/crayon\" w sweet infection.
Na mala ilosc wierzcholkow u mnie dodawanie wygladalo tak samo tylko
parametry odwolywaly sie tylko do strony zerowej.
Czy mozesz miec dowolne wspolrzedne punktow obiektu w 3d czy obiekt wyglada jak we wszystkich demach jakby byl \"przyciagniety\" do \"siatki 3d\".
Pytalem o macierz, bo jak sie ma obliczona 9 elementowa macierz to mozna za pomoca tablic skalowania przeskalowac jedna macierz na
X macierzy (max. 27) i umiescic 28 macierzy 9 elementowych na stronie zerowej. Wtedy wszystkie obroty mozna zrobic na dodawaniach 8 bitowych 3 cyklowych adc $xx a nie adc $xxxx ale obiekt musi byc \"przyciagniety\" do siatki 3d okreslonej przez przeskalowane macierze.
offtop:
Serio mnie to interesuje, ja bardziej sie zastanawiam nad pojsciem w to co pokazal Graham w jednym dentrze zeby tego nieszczesnego sinusa rozszerzyc do 512 bajtow i 16 bitow lub wiecej.
Osobiscie uwazam ze ploty ktore zapierdalaja w jedna ramke powinny miec wartosci delt na katach mniejsze niz 1,4 stopnia.
Wiadomość wysłana przez: fenek__ w 23 Maja 2010, 17:06
| Nitro napisal: |
... proponuje tez poznac sposob na plotery, ponad 256 dotsow w ramce, choc bez perspektywy, to chyba jest standardem teraz |
Jeszcze sie odniose do tego choc moglem wyzej. Takie plotery kojarze z pierwszego ich wydania Oneder/Oxyron. Czy ja juz nie dowidze czy obiekty sa nadal \"kwadratowe\" przylegajace \"do siatki\" ?!?
Faktem jest ze robiac obiekty z odbijaniem mozna wtedy siatke wykorzystac na pol lub 1/4 obiektu \"zwiekszajac\" efektywnie dokladnosc calego tak utworzonego obiektu.
Wiadomość wysłana przez: zielok__ w 23 Maja 2010, 18:06
| fenek napisal: |
Ja tylko pytam z czystej ciekawosci, rozumiem ze wczesniej liczysz macierz 9 elementow ? Ja cos takiego robilem do obracania prostych obiektow, wektory \"cartoon/crayon\" w sweet infection. Na mala ilosc wierzcholkow u mnie dodawanie wygladalo tak samo tylko parametry odwolywaly sie tylko do strony zerowej. |
Optymalizacja w moim kodzie poszla juz oczywiscie duzo dalej tj takze korzystam ze strony zerowej. Aktualnie mam osiagniete przeliczenie 260 punktow na ramke z malowaniem, czyszczeniem, double bufferem na fullscreenie. Oczywiscie zostaje jeszcze spory zapas cykli (na muzyke i jeszcze troche).
Macierz z racji rezygnacji z perspektywy ma 6 elementow (nie ma wiecej potrzeby). Zrezygnowalem z wyliczania \"Z\" i obliczania perspektywy czyli wyglada to tak (pseudokod)
x\'=x*matrix[0][0] +y*matrix[0][1] +z*matrix[0][2]
y\'=x*matrix[1][0] +y*matrix[1][1] +z*matrix[1][2]
x\' i y\' zawieraja juz wspolrzedne do namalowania punktu 2d
| fenek napisal: |
| Czy mozesz miec dowolne wspolrzedne punktow obiektu w 3d czy obiekt wyglada jak we wszystkich demach jakby byl \"przyciagniety\" do \"siatki 3d\". |
Hmm tego nie rozumie.
Z mojego rozumowania wychodzi, ze moge miec dowolne (oczywiscie w odpowiedniej skali).
Tylko, ze w EOD czy OneDer takze te obiekty wygladaja dla mnie normalnie.
| fenek napisal: |
| Pytalem o macierz, bo jak sie ma obliczona 9 elementowa macierz to mozna za pomoca tablic skalowania przeskalowac jedna macierz na X macierzy (max. 27) i umiescic 28 macierzy 9 elementowych na stronie zerowej. Wtedy wszystkie obroty mozna zrobic na dodawaniach 8 bitowych 3 cyklowych adc $xx a nie adc $xxxx ale obiekt musi byc \"przyciagniety\" do siatki 3d okreslonej przez przeskalowane macierze. |
A teraz chyba zrozumialem to wczesniejsze:) Ja poszedlem w innym kierunku i u mnie wyglada to tak
Mam obliczona macierz i \"mnoze\" z kazdym elementem macierzy wszystkie mozliwe wartosci x,y lub z (w zaleznosci z ktorym elementem \"mnoze\"). Tutaj sa dodatkowe optymalizacje czyli licze tylko wartosci x,y i z dodatnie bo ujemne uzyskuje przy wyliczniu zamieniajac adc na sbc
Reasumujac, to obiekty mam tak samo jak we wszystkich demach przyciagniete do siatki 3d. (no chyba, ze nie zrozumialem)
Twoje rozwiazanie wyglada ciekawie i dla testow chyba je zrobie (moze bedzie szybsze).
| fenek napisal: |
| offtop: Serio mnie to interesuje, ja bardziej sie zastanawiam nad pojsciem w to co pokazal Graham w jednym dentrze zeby tego nieszczesnego sinusa rozszerzyc do 512 bajtow i 16 bitow lub wiecej. Osobiscie uwazam ze ploty ktore zapierdalaja w jedna ramke powinny miec wartosci delt na katach mniejsze niz 1,4 stopnia. |
Ano zapierdzielaja
Ja jestem po testowej analizie (i o ile nie popelnilem gdzies bledu) to takie rozwiazanie nie spowoduje znacznego spowolnienia (ale bedzie wolniej )Ja popelnilem pare bledow przy projektowaniu... Najpierw zrobilem przeliczanie bez macierzy (osiagnalem bodajze 16 punktow - ale z perspektywa) potem uzylem macierzy, rezygnacja z perspektywy (i tak nie widac, ze jej nie ma), zamiast lda $xxxx uzylem strony zerowej i mnostwo innych optymalizacji. Moglem to skodowac zdecydowanie szybciej gdybym na poczatku dokladnie to przemyslal
Wiadomość wysłana przez: fenek__ w 24 Maja 2010, 11:08
>
Czyli robisz to sensowniej bo wyliczasz wartosci dla wspolrzednych obiektu tak jak zostal zdefiniowany a mi chodzi oto ze mam wrazenie ze obiekty
sa najpierw zdefiniowane w 3D a potem ogranicza sie \"wszystkie mozliwe wartosci\" x,y,z tak zeby bylo ich jak najmniej i zmienia sie wartosci zdefiniowanego obiektu.
Moze to tylko moje wrazenie, chyba sie blizej temu przyjrze.
edit: oka juz sie przyjrzalem juz kumam, ze jednak w EoD jest opisane ze wspolrzedne dotow sa od siebie niezalezne
Wiadomość wysłana przez: Klax__ w 11 Października 2010, 14:23
| zielok napisal: | ||
A jednak nie Stacja z powodu malej ilosci pamieci i braku miejsca nie pozwoli szybko przeliczyc wielu punktow. Owszem dla kilkunastu punktow da pewnie przyspieszenie ale czym wieksza ilosc punktow do przeliczenia tym obliczanie w stacji dyskow bedzie proporcjonalnie wolniejsze. |
Zawsze mozna dolozyc 32kB ramu wedlug mojego pomyslu
Wiadomość wysłana przez: booker__ w 11 Października 2010, 14:26
![\"Cool\"](\"images/smiles/icon_cool.gif\"){kind=icon}
Wiadomość wysłana przez: Kisiel w 11 Października 2010, 16:39
Podkrec procka podkrec procka
Wiadomość wysłana przez: Jacek31 w 13 Października 2010, 13:15
Skoro stacja ma za malo RAMu ale jest za to szybka to moze dobrym rozwiazaniem bylo by stworzenie do niej biblioteki czasochlonnych operacji graficznych, i wykorzystywac ja jako kooprocesor graficzny, ktory nie liczyl by calosci tylko \"rownolegle\" do C64 bardziej wymagajace elementy.
Oczywiscie wymaga to stworzenia nowej koncepcji, i pewnie wykorzystanie przerwan oraz synchronizacji, ale powinno byc wykonalne.
Wiadomość wysłana przez: fenek__ w 13 Października 2010, 16:44
o zbudowanie macierzy z np. 3 stacji dyskow 1541 i c-64.
Wykorzystac to do wykonywania obliczen 3d np. punktu.
Z c-64 wysyla sie wierzcholek w 3d (wsp.X, Y, Z) do stacji rX.
W stacji rX wykonywane sa procedury obrotu wierzcholka wokol
osi X. Po wykonaniu obliczen nowe wspolrzedne przesylane sa do stacji rY.
W stacji rY wykonywane sa procedury obrotu wierzcholka wokol osi Y.
( w tym samym czasie z c-64 przekazywane sa wspolrzedne x,y,z kolejnego
wierzcholka do stacji rX).
Kolejno nowe wspolrzedne ze stacji rY wedruja do stacji rZ gdzie wykonywane
sa procedury obrotu wierzcholka wokol osi Z. W tym czasie nastepuje przeslanie
danych ze stacji rX do stacji rZ i danych z c-64 do stacji rX.
Po obliczeniach ze stacji rZ wedruja dane do c64 i ten rysuje dota.
czyli: rZ->c64, rY->rZ, rX->rY
To tak mniej-wiecej.
Wiadomość wysłana przez: Kisiel w 13 Października 2010, 17:20
Moze lepiej zamiast 1541, uzyc czegos innego ?
Wiadomość wysłana przez: Jacek31 w 13 Października 2010, 17:33
Najpierw nalezalo by rozebrac silnik graficzny pod katem pamieciozernosci i nakladow obliczeniowych poszczegolnych jego elementow. Jezeli teraz wezmiemy pod lupe ten ulubiony teksturowany na drewniana skrzynie szescian, zbudowany z trojkatow, to mamy 12 poligonow skladajacych sie z 3 wspolrzednych, czyli 36 wektorow do obliczenia/ przeliczenia. Tekstura zeby miala jakis sens musi miec rozmiar 64x64 pixele czyli 4096 punktow do przeliczenia/sciane (maksymalnie), z korekta perspektywy dochodza do tego dodatkowe operacje dzielenia/pixel (ale tu mozna sprytnie oszukiwac akurat). juz tu widac ze obliczenia na wektorach, czyli cala geometria w przestrzeni 3D to zasadniczo maly ulamek obliczen, natomiast teksturowanie jest strasznie czasochlonne, nie dla tego ze jest skomplikowane, ale ze trzeba przeliczyc mase elementow.
Ja bym wiec z C64 zrobil Vertrx Shader, a z stacji dyskow Pixel Shader.
No dobra ale jak w stacji zmiescic teksture i program? wystarczy tylko program, ktory policzy na podstawie przeslanych wspolrzednych 3D po transformacjach (np. obrot, skalowanie itd.) co trzeba wysle do C64, adres pixela w teksturze ktory trzeba skopiowac i adres pamieci obrazu gdzie go trzeba skopiowac.
Oczywiscie ja to uproscilem, ale powinno sie to tak dac.
Wiadomość wysłana przez: Klax__ w 13 Października 2010, 18:23
| kisiel napisal: |
| niestety to bedzie \"zrzut kompo\"... bo kto ma 3 stacje, trzeba by sie zrzucic Moze lepiej zamiast 1541, uzyc czegos innego ? |
Niektorzy maja 3 stacje
A czy dodatkowa pamiec (o ktorej wczesniej wspomnialem) w stacji nie bylaby pomocna? Tu sa chyba wektorki na stacji liczone http://noname.c64.org/csdb/release/?id=820
Wiadomość wysłana przez: Kisiel w 13 Października 2010, 19:19
Wiadomość wysłana przez: Skull w 13 Października 2010, 19:26
warto uruchomic i poczytac komentarze. Niezbyt wysublimowania wektorowka, a nawet nie osiaga pelnej plynnosci - gdzie tu mowa o srodowisku 3D.
Oczywiscie jako ciekawostka to jest to ok, ale glownie cala rzecz \"przepada\" przy synchronizacji komunikacji, obsluga tego, to wlasnie waskie gardlo - ktore w rezultacie daje gorsze efekty niz dobra kalkulacja wektorow na samym c64 (Andropolis).
![\"Crying](\"images/smiles/icon_cry.gif\"){kind=icon}
Wiadomość wysłana przez: fenek__ w 14 Października 2010, 07:22
stacje mozna wykorzystac do generowania adresu jmp $xxxx.
Bity 7 i 6 $dd00 to chyba byl stan ze stacji.
W c64 byl kod rozdzielony na adresy $000x, $400x, $800x, $c00x
(jak sie korzysta z $000x to dwa banki VICa w plecy 0 i 1) i wykonuje
sie w krotkich liniach po 2 rastry (generuje tez te linie)i konczy instrukcja jmp ($ddff).
Mlodszy bajt pobierany jest z $ddff (chyba to nie bylo stabilne)
a starszy z $dd00. Stacja generuje adresy procedur ktore maja byc
wywolane przez c64 modyfikujac bity 7 i 6 $dd00 i generuje ten starszy bajt kodu.
Cos podobnego do jmp ($d011) z synchronizacja do lini rastra,
mlodszy bajt z $d011 i starszy z $d012.
Wiadomość wysłana przez: Skull w 14 Października 2010, 08:22
Ale co masz na mysli :
| fenek napisal: |
| ) i wykonuje sie w krotkich liniach po 2 rastry (generuje tez te linie)... |
Teoretycznie tez jest w CIA, Serial Port Interrupt.
Wiadomość wysłana przez: Kisiel w 14 Października 2010, 08:45
| skull napisal: |
| sorry ale dla mnie te wykorzystanie mocy drive-a, aby podniesc znaczaco wydajnosc to mzonki (shadery heheheh). Na poczatku roku Wegi sie w to bawil http://noname.c64.org/csdb/release/?id=87341, warto uruchomic i poczytac komentarze. Niezbyt wysublimowania wektorowka, a nawet nie osiaga pelnej plynnosci - gdzie tu mowa o srodowisku 3D. Oczywiscie jako ciekawostka to jest to ok, ale glownie cala rzecz \"przepada\" przy synchronizacji komunikacji, obsluga tego, to wlasnie waskie gardlo - ktore w rezultacie daje gorsze efekty niz dobra kalkulacja wektorow na samym c64 (Andropolis). |
Co do mozliwosci stacja-c64 warto zaznajomic sie z realtime demko by Victor/ESM, na ktoryms northcie to bylo.
Co do waskiego gardla, istnieje cos takiego w komciu jak USERPORT i sprzecik CIA 6526 ktory umozliwia sprzetowe potwierdzenie odbioru. Teoretycznie mozna przesylac tym portem 80kB/s, nie uwazam to za waskie gardlo. Ja w moim komciu mam wersje bursta na 10 kabli, jedyny program co uzywal ten patent to bodaj burstnibbler oraz jakis system load (nie pamietam). Standard 8 kabelkow, jest dziwny bo trzeba jeszcze potwierdzac softwarowo odbior / nadanie... lub robic to synchronicznie.
Wiadomość wysłana przez: Skull w 14 Października 2010, 09:48
| kisiel napisal: | ||
Co do mozliwosci stacja-c64 warto zaznajomic sie z realtime demko by Victor/ESM, na ktoryms northcie to bylo. Co do waskiego gardla, istnieje cos takiego w komciu jak USERPORT i sprzecik CIA 6526 ktory umozliwia sprzetowe potwierdzenie odbioru. Teoretycznie mozna przesylac tym portem 80kB/s, nie uwazam to za waskie gardlo. Ja w moim komciu mam wersje bursta na 10 kabli, jedyny program co uzywal ten patent to bodaj burstnibbler oraz jakis system load (nie pamietam). Standard 8 kabelkow, jest dziwny bo trzeba jeszcze potwierdzac softwarowo odbior / nadanie... lub robic to synchronicznie. |
Kisiel mowisz o szybkosci transmisji - co w tym przypadku pelni role drugorzedna: moze byc i 1MBajt/s, najwazniejsza jest obsluga wyslij-odbierz, a to sie wiaze albo z opoznieniami (czekaniem) i po jednej i po drugiej stronie (a im test czestszy tym wlasnie zabiera wiecej mocy proca im zadszy tym wieksze sa czasy oczekiwania)- wlasnie wtedy \"cala para w gwizdek idzie\".
Nie mowie tez ze taki uklad nie przyspiesza obliczen - niestety jest to nieduzo wiecej.
Brakuje sprzetowego bufora danych.
Wiadomość wysłana przez: Kisiel w 14 Października 2010, 00:00
Wiadomość wysłana przez: Skull w 14 Października 2010, 14:02
| kisiel napisal: |
| ... c64 rysuje ramke i nie czeka na stacje ... |
i to jest caly problem - NIE CZEKAC
Wiadomość wysłana przez: fenek__ w 14 Października 2010, 15:39
| skull napisal: | ||
|
No jak zwykle moje skroty myslowe o ktorych mysle a zapominam opisac.
To mialo mniej-wiecej znaczyc, ze bylyby to maksymalnie 4 rozne porcje kodu do wykorzystania w efekcie ktory caly czas wywoluje na ekranie
krotkie linie. Taki kod zajmowal dwie linie rastra i te kombinacje ze skokiem i uzyciem stacji zastosowane sa z powodu braku cykli w rastrach na generowanie adresu kodu dla kolejnej lini ekranu. Uff...
Wiadomość wysłana przez: Skull w 14 Października 2010, 16:08
| fenek napisal: | ||||
No jak zwykle moje skroty myslowe o ktorych mysle a zapominam opisac. To mialo mniej-wiecej znaczyc, ze bylyby to maksymalnie 4 rozne porcje kodu do wykorzystania w efekcie ktory caly czas wywoluje na ekranie krotkie linie. Taki kod zajmowal dwie linie rastra i te kombinacje ze skokiem i uzyciem stacji zastosowane sa z powodu braku cykli w rastrach na generowanie adresu kodu dla kolejnej lini ekranu. Uff... |
Hehe jeszcze bardziej zagmatwales - ale domyslam sie, ze chodzi o samo wyjscie z irq (-s) (czyli z tych krotkich linii-efektow), ktore \"przy okazji\" sprawdza czy \"doszlo\" cos ze stacji.
Jesli cos doszlo, to wektor skoku jmp($xxxx) skierowany jest na procedurke odbioru danych ze stacji [np. jmp($c0xx)], a gdy nie, to skierowany na kontynuacje samego wyjscie z przerwania [np. jmp($80xx)]. Z tym, ze to \"przekierowanie\" wektora ustawia sama stacja poprzez rejestr $1800($dd00)
- to o to chodzi ??
Wiadomość wysłana przez: Kisiel w 14 Października 2010, 16:47
Wiadomość wysłana przez: Skull w 14 Października 2010, 17:46
Wiadomość wysłana przez: fenek__ w 14 Października 2010, 19:38
Umiesz to sensownie i zrozumiale opisac, tak ze jak czytam to nawet
sam rozumiem
o co mi chodzi.