Wiadomość wysłana przez: Nitro__ w 13 Lutego 2011, 16:41
Ja podziekuje, kazdy scenowiec ma stacje 15xx lub 1541-Ultimate.
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 19:07
Szczerze mowiac specyfika innych kartow/drive-ow, nie ma tu znaczenia. Mowimy o transmisji kernalowskiej ktora jest wlasnie taka jak jest, ale w zalozeniu wspolpracuje ze WSZYSTKIMI urzadzeniami przeznaczonymi do c64. Zreszta kazde urzadzenie zewnetrzne ktore nie ma zaimplentowanej komunikacji w sposob \"kernalowski\", zwyczajnie nie jest urzadzeniem do c64 (czyt. do dupy z takim urzadzeniem) - standardowy protokol jest po to aby byl jasny dla wszystkich. Truboloadery to dopiero dodatki opierajace sie o konkretna specyfike urzadzenia.
I teraz... \"wystarczy\" skupic sie na oprogramowaniu czesci kernalowskiej (a nie urzadzenia) i wszystko bedzie zawsze chodzic.
Oczywiscie sprawa nie jest latwa, bo tam sa odpowiednio duze opoznienia w oczekawniu na sygnal drugiego urzadzenia (czesto nie potrzebnie), ale latwo \"przegapic\" - stad SEI oraz przeszkadzaja sprites by nie zabieraly cyklow(glownie w polaczniu z badline).
Teraz druga sprawa - pochwale - jak zakupilem sd2iec, od razu rzucila mi sie prostota przenoszenia danych (karta sd), a nie te kombinacje z kablami, programami do trasmisji przy okazji walki z systemem - i to czesto skazanymi na porazke. Pomyslalem ze szkoda byloby marnowac takiego urzadzenia. Chcialem zeby moje programy umialy doczytywac i bezposrednio z tego urzadzenia.
Oczywiscie w pierwszej chwili napotkalem na problemy ktory wypisales, ale udalo mi sie napisac taki maly \"substytut\" kernela, ktory nie dosc ze zajmuje niecale $100 bytes, to jest szybszy i pozwala na wyswietlanie kilku sprites - a co najwazniejsze wspolpracuje rowniez z innymi urzadzeniami (a nie tylko z sd2iec) - mozna...
Dziala to na zasadzie nasluchu, a
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Raf w 13 Lutego 2011, 19:48
_________________
www.vulture.c64.org
www.c64power.com
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 19:51
| Raf napisal: |
| ale jest przeciez jiffydos :P |
wlasnie.. tyle ze on tez wylacza sprites
no i to jest ingerencja hardwerowa - mowimy o loaderach, a nie systemach
![\"Wink\"](\"images/smiles/icon_wink.gif\"){kind=icon}
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Kisiel w 13 Lutego 2011, 20:02
_________________
\"... taka choroba. Zreszta obrazki, ktore robisz tez cos o tym mowia.
Proponuje odwrocic proporcje, zamiast byc 100% scenowym trollem, skup sie bardziej na poprawieniu warsztatu...\"
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 20:24
| kisiel napisal: |
| Skull skad wziasc Twoje programy? Dla mnie nie jest problem bad lines. |
Hehe, w sumie racja, czlowiek sie wymadrza, a nie popiera dokumentami - no coz, programy sa zwyczajnie \"nieskonczone\".
ale z racji tego, ze coraz ciezej mi przysiasc do c64, mozliwe ze nie skoncze, i robie to czego chcialem uniknac, dam przyklad nieskonczonego:
tylko mala uwaga - to nie jest zaden release, muzyka w menu jest -ale nie bedzie uzyta w wersji finalnej (brak zgody autora/ zreszta mam juz inna \"nawet\" lepsza ale jeszcze nie podmienilem).
Ze szczeg. technicznych - loader - jak nie wykryje 1541 - to jedzie tym co opisalem powyzej.
| game.rar | |||
| :Opis: | | ![\"\"](\"images/icon_clip.gif\"){kind=icon} Pobierz | |
| :Nazwa zalacznika: | :game.rar | ||
| :Rozmiar: | :66.18 KB | ||
| :Pobran: | :Plik sciagnieto 95 raz(y) |
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Nitro__ w 13 Lutego 2011, 20:36
Loader krill\'a czyta jeden track w ok. 2 sekundy, do tego mamy gratisowo depak plikow spakowanych Level Crusherem, ktory doslownie czyni cuda jesli chodzi o transfer.
Gra za to zapowiada sie wiecej niz swietnie
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 20:39
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Nitro__ w 13 Lutego 2011, 20:50
![\"Smile\"](\"images/smiles/icon_smile.gif\"){kind=icon}
O to chodzi, aby widz nie musial wciskac warpa w emu(nie mowiac o realnym sprzecie) ani podziwiac obrazkow czy wlokacych sie przejsc przez wieki. Oraz aby kolejny efekt nie byl popychadlem z ladowaniem w tle, tylko trzymal opadnieta szczeke widza na podlodze
Przykladem swietnego dema, ktore jest zarzynane wlasnie przez wolny loader jest Snapshot, kod partow jest na bardzo wysokim poziomie, ale przerwy pomiedzy nimi sa dlugie oraz nudne.
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 21:11
Sprobuj napisac loader.
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Nitro__ w 13 Lutego 2011, 21:24
http://www.pagetable.com/?p=568
Czas rastra jest do dowolnej regulacji, przeciez to istota IRQ loaderow, w IRQ wykonujemy nasz kod przez dowolny okres czasu, po skonczeniu IRQ loader zaczyna ladowac az do przerwania przez kolejne IRQ lub zaladowania calego pliku.
Im mniej efekt zajmuje, tym gorzej chodzi, speedcode szczegolnie bardziej zaawansowany zjada mnostwo miejsca.
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 21:31
Moze zdzwi Cie fakt, ze czas loadingu (w przykladzie) wcale nie bylby krotszy jakbym mial zastosowac np. krilla - po prostu chcialem zeby to akurat tyle trwalo (nawet program ma specjalne opoznienia bo wczytywanie niekiedy za krotko trwa ! ).
W demach jest po prostu roznie...
_________________
Bo pecet to zwykly banan...
Wiadomość wysłana przez: Kisiel w 13 Lutego 2011, 21:48
_________________
\"... taka choroba. Zreszta obrazki, ktore robisz tez cos o tym mowia.
Proponuje odwrocic proporcje, zamiast byc 100% scenowym trollem, skup sie bardziej na poprawieniu warsztatu...\"
Wiadomość wysłana przez: Nitro__ w 13 Lutego 2011, 21:52
We wspolczesnych demach sytuacja zmienia sie o 180 stopni, publicznosc po EOD, Desert Dream i innych wspolczesnych demach nie bedzie zadowolona z dlugich loadingow wraz z marnymi efektami podczas nich.
Wiadomość wysłana przez: Kisiel w 13 Lutego 2011, 22:05
_________________
\"... taka choroba. Zreszta obrazki, ktore robisz tez cos o tym mowia.
Proponuje odwrocic proporcje, zamiast byc 100% scenowym trollem, skup sie bardziej na poprawieniu warsztatu...\"
Wiadomość wysłana przez: Skull w 13 Lutego 2011, 23:09
Wiadomość wysłana przez: Nitro__ w 14 Lutego 2011, 17:08
Co do ladowany speedcode vs. generowany, to jesli nie mowimy o eor fillerze czy tam jeszcze czyms prostym to ladowanie bedzie szybsze, nie mowiac o pominieciu bolu pisania takiego generatora, przykladem jest demo Exotic Excitement camelotu, przerwy miedzy plasmami sa na generowanie skomplikowanego speedcode\'u i zajmuja kolo 15 sekund.
P.S. Nie bijcie za offtop, wydziele watek jak wroce.
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 07:43
Ale powtorze jeszcze raz - ja podalem tylko przyklad, wlasciwie namiastke (przy tworzeniu tego \"substytutu\" glownie chodzilo mi o to aby nie korzystac kernala w romie), jak widac po JiffyDos-ie potencjal jest. Oczywiscie w demach trzeba byc bardziej \"elastycznym\", ale i loader Krill\'a przeciez nie zasuwa z pelna predkoscia w takich produkcjach.
No niech tam te SD2IEC -to sprzet wspolczesny/\"nie retro\", ale szkoda takich stacji jak 1581 i innych drive-ow powstalych w czasach 1541. Loadery uniwersalne to takze furtka dla nowych urzadzen.
Wiadomość wysłana przez: fenek__ w 15 Lutego 2011, 10:04
Uproszczenie, ktore moze pozwoli zrozumiec mechanizm od czego zalezy \"szybkosc\" loadera.
Najpierw o loaderach ktore czytaja pliki z przeplotem z jakim zostaly zapisane na dyskietce. Czyli loader szuka kolejnych sektorow pliku.
Zakladam, ze po stronie c-64 caly rastertime jest przeznaczony dla loadera. Przy transmisji dwubitowej przeslanie 256 bajtow powinno miescic sie w ramke.
Predkosc dzialania loadera po stronie stacji, to szybkosc dzialania kodu odczytu sektora w GCR i konwersji danych GCR->C-64 i przeslanie danych do C-64.
Najwazniejszy jednak jest ten czas uplywajacy po wczytaniu sektora do pamieci stacji dyskow !!!.
Dyskietka caly czas sie obraca, a czas uplywa i tu pojawia sie sedno.
Ten czas mozna sobie przeliczyc na to ile sektorow ucieknie pod glowica, ktora nie odczytuje danych !!!. No i dla mnie przy tych zalozeniach jest
to logiczne, ze szybszy jest loader ktoremu uciekna 4 sektory od tego
ktoremu ucieknie 8 czy 10 sektorow !.
Jezeli zapisze plik na dyskietce z przeplotem 4 i loader wyrabia sie z predkoscia przeplotu 4 to plik zostanie wczytany 2xszybciej niz dla loadera wyrabiajacego sie z przeplotem 8 dla pliku zapisanego z przeplotem 8.
Teraz, zeby nie bylo tak cacy to wiadomo, ze po stronie C-64 nie mamy wolnego calego rastertime\'u. Wplynie to na predkosc transmisji danych ze stacji do C-64 a co za tym idzie pod glowica bedzie uciekac wieksza ilosc sektorow !!! Takze super-szybki loader nie bedzie juz taki szybki jak nam sie wydaje jezeli pliki na dysku nie zostana zapisane z odpowiednim przeplotem !!!. Moze byc tak, ze dla loader\'a ktory wyrabia sie z wczytywaniem z przeplotem 4 nalezy pliki zapisywac z przeplotem 6, 8, 10 itp. trzeba dobrac przeplot pliuk recznie zeby otrzymac 100% efektywnosc dzialania loadera.
Lopatologicznie, jak zapisze plik z przeplotem 4 i mam obciazony rastertime i glowicy ucieknie 6 sektorow to loader i tak sie posra bo bedzie czekal jeden obrot na to zeby zlapac sektor danych.
I tu Skull cos dla Ciebie czego ja dluuuuuugo nie rozumialem.
Loader jest szybki, plik jest zapisany z takim przeplotem, ze loader zapierdala i nie traci czasu na pelne obroty, ale mimo to stacja czeka! na kolejny sektor danych.
I tu ktos wpadl na pomysl, zeby w to oczekiwanie po stronie C-64
wrzucic dekranczowanie danych !!! Tu trzeba tez pamietac ze dane
w c-64 sa umieszczane liniowo bajt za bajtem i dlatego mozliwy jest dekrancz.
Nawet niech wszystkie pliki zostana zapisane z przeplotem 4 dla loadera 4 to jezeli w trakcie wczytywania loader traci ten jeden obrot 0,2 s to jest to 10 ramek dla c-64 do dekranczowania (dokladniej 10 obciazonych ramek).
Dekranczowane sa wczytane dane w C-64, jak stacja zlapie sektor to wczytuje dane/konwertuje, C-64 nadal moze dekranczowac dane.
Stacja daje sygnal, ze ma przeslac dane, C-64 przerywa dekrancz i odbiera dane ze stacji. To juz nie jest taka prosta petla odbior danych.
Trzeba sobie uswiadomic, ze taka prosta petla co tylko odbiera dane
ze stacji jest bezczynna jezeli stacja czeka na synchronizacje/zlapanie
sektora z danymi ktory jej uciekl pod glowica.
Inna sprawa jest loader, ktory potrafi wczytywac pliki bez wzgledu na przeplot z jakim zostaly zapisane. Tu potrzebny jest szybki sam w sobie loader, ale potrzebny jest skaner sektorow nalezacych do pliku.
W wypadku gdy rastertime jest obciazony i dla loadera o predkosci wczytywania 4 pod glowica ucieknie 6 sektorow, to loader sprawdza
czy ten sektor pod glowica nalezy do wczytywanego pliku. Skoro
nalezy do pliku to stacja go wczytuje i musi obliczyc przeslac blok danych pod okreslony adres w pamieci w C-64.
Takze w takim wypadku w C-64 dane nie sa umieszczane liniowo tylko blokami i w przestrzeni pamieci gdzie ma byc wczytany plik sa dziury.
Tutaj nie wiem czy jest jakis loader ktory od razu potrafi takie dane
dekranczowac.
Taki loader jest \"najlepszym\" rozwiazaniem, mozna go jeszcze oszukiwac
i zapisywac pliki tak aby na jednej sciezce byly zapisane dane tylko jednego pliku.
Jezeli wczytujemy plik zkranczowane to po wczytaniu trzeba je jeszcze zdekranczowac.
Dlatego wychodzi na to, ze loader z dekranczerem moze byc najszybszy.
Tylko trzeba wiedziec z czego sie korzysta i jak przygotowac dane.
Tylko, ze sa efekty ktore maja zmienne uzycie rastertimeu, przydalby sie
file kopier ktory potrafilby nagrywac pliki z przeplotem zmiennym w czasie. np.
1 sektor danych
2 sektor danych, +4 w stosunku do 1
3 sektor danych, +6 w stosunku do 2
itp.
Jezeli opisalem oczywiste rzeczy i kazdy to wie i rozumie to sorry.
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 10:47
Oczywiscie ze najlepszy turboloader uniwersalny, nie bedzie mial szans z szybkimi loaderami na 1541 (w koncu wtedy ulepszone \"sterowniki\" transmisji dzialaja i po stronie c64 i po stronie c1541), pytanie tylko czy te superszybkie loadery sa az tak potrzebne w demach (co innego kopiery) - bo jesli nie to warto skupic sie na dobrymi loaderami tylko po stronie c64 - zysk jest jasny - kompatybilnosc.
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 00:00
| Cytat: |
| \"wstawia\" dane szybciej niz JEDNA petla powtarzajaca wpisywane dane (dzialajaca w tle) to cos tu jest nie tak - wynikaloby, ze wg. twojego toku rozumowania - np. szkoda czyscic ekran skoro loader Krill-a zrobi to szybciej |
Mowilem, zacznij pisac dema
Speedcode\'y moga byc proste w rodzaju eor fillera:EOR xxxx
STA xxxx
czy tez kodu czyszczacego:
STA xxxx
STA xxxx
I w tych przypadkach ofcoz generator zrobi swoja robote szybciej i bedzie prosty. Ale moga byc tez diablo skomplikowane jak ten z Exotic Excitement, polecam zapoznanie sie z whitepaperem:
http://noname.c64.org/csdb/release/download.php?id=119834
Pewnie i mozna by i zaczac generator optymalizowac, moze nawet napisac generator generatora
, ale ja podziekuje za takie atrakcje, przyznaje szczerze, ze jestem spaczony KickAssemblerem, i tylko przyparty do muru napisze generator bardziej skomplikowany niz powyzsze proste przyklady.| Cytat: |
| ale szkoda takich stacji jak 1581 i innych drive-ow powstalych w czasach 1541. |
? Loader krill\'a w pelni obsluguje 1571 i 1581 tj. dyski dwustronne i 3,5 dla 1581. Przekopiowalem przed chwila testowo Black Spark(zero modyfikacji) na D81, demko odpalilo, radiale zajmujace cala pamiec wczytaly sie bez problemu na czas, potem niestety zwis, albo loader jest za wolny, albo bug, albo pliki trzeba jakos specjalnie ulozyc. Jakby sie jakis koneser stacji 1581 znalazl, to jak widac rzecz jest do szybkiego zrobienia.
| Cytat: |
| pytanie tylko czy te superszybkie loadery sa az tak potrzebne w demach (co innego kopiery) |
Powody dla ktorych ja za hiper uniwersalne loadery podziekuje podalem wczesniej, szybkosc, elastycznosc, brak uzerania sie z kompatybilnoscia.
Aha, i wciaz efekty liczone na stacji sa poletkiem slabo zbadanym, trzeba to zmienic
Wektory na drive\'ie wszyscy znamy, zna ktos jeszcze jakies inne party liczace cos na stacji?
P.S. Na poczatku zabaw z loaderem pytalem krill\'a o interlave, a ten doradzil mi nie bawic sie w to z powodu minimalnych zyskow przy ladowaniu skompresowanych plikow wiec dyskietka trackma byla tworzona przez CC1541 przy domyslnych opcjach.
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 14:43
| Nitro napisal: |
Mowilem, zacznij pisac dema |
| Nitro napisal: |
| ...przyznaje szczerze, ze jestem spaczony KickAssemblerem, i tylko przyparty do muru napisze generator bardziej skomplikowany niz powyzsze proste przyklady. |
no i tu jest pies pogrzebany, dobrze ze sie przyznales - \"wystarczy\" przerobic metakod z kicka na assembler (a czy ja mowie ze to latwe? jak cale programowanie)[/quote]
Wiem ze c64+1541 to standard scenowy, ale wynika to raczej jak widac z wygodnictwa.
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 15:23
| Cytat: |
| A sie tych dem zes napisal, ale spokojna twoja rozczochrana - pisze sie i dema, tyle ze wolno |
Nie, po prostu przerabialem omawiane tu tematy, loader krill\'a, loader wegi\'ego - wg. autora najszybszy na swiecie oraz skomplikowane speedcode\'y i imho moge powiedziec, ze cos tam o tym wiem
| Cytat: |
| no i tu jest pies pogrzebany, dobrze ze sie przyznales - \"wystarczy\" przerobic metakod z kicka na assembler (a czy ja mowie ze to latwe? jak cale programowanie) Wiem ze c64+1541 to standard scenowy, ale wynika to raczej jak widac z wygodnictwa. |
Jak juz mowilem chodzi o szybkosc, jakbym mial wstawic do kolejnego dema plasme z walkowanego Exotic Excitement, to wole uzyc loadera aby w ok. dwie-trzy sekundy zaladowac ok. 10kb gotowego speedcode\'u, ktorego generator napisalem wygodnie i przyjemnie w C++.
Niz pisac ok. 60kb generator, zobacz sam:
http://noname.c64.org/csdb/release/download.php?id=119833
i czekac 15s na generowanie speedcode\'u.
Klaryfikujac owe przyparcie do muru, mialem na mysli sytuacje, kiedy w jakims efekcie generator skomplikowanego speedcode\'u bylby drastycznie szybszy od loadera, zaden praktyczny przyklad nie przychodzi mi do glowy.
Nie wspomne juz o o nowoczesnych efektach, gdzie generacja speedcode\'u jest poza zasiegiem C64, jak Phong Shading.
Wiadomość wysłana przez: fenek__ w 15 Lutego 2011, 16:25
![\"Cool\"](\"images/smiles/icon_cool.gif\"){kind=icon}
No i nie znam zadnego jezyka procz assemblera, bo to tylko hobby.No jedynie w Lifework jest procedura wyswietlania FLIcomboAFLI, ktora jest wczesniej generowana/deaasemblowana/recznie debugowana i cyklowana i rozbita po dziurach w pamieci i laczona JMPami i ostatecznie
zapisana w pliku glownym kolekcji.
Meczy mnie inny problem nie tyle predkosci loadera co tego, ze jak chce wczytac plik za pomoca Kernala to z pamiecia RAM od $e000-$ffff musze
sie pozegnac na czas wczytywania ?
Jak to jest z SD2IEC, bo nie do konca rozumiem. Rozumiem, ze szybkie loadery nie dzialaja, ale czy jezeli po stronie stacji napisze kod ktory korzysta tylko z DOSu stacji np. rozkazy wczytujace sektory do danego bufora to taki program moge rozkazami Kernala Memory-Write przeslac do stacji - do SD2IEC i go uruchomic ?
Czy cos takiego dziala ? Jezeli tak to czy moge po stronie stacji dopisac
procedure transmisji 2bitowej i czy SD2IEC to pociagnie ?
Jezeli cos takiego dziala to faktycznie mozna zrezygnowac z szybkiego loadera i w wypadku wykrycia SD2IEC podmienic loader w stacji.
Co do kompatybilnosci, nawet jak cos takiego przejdzie z SD2IEC to o mnie i uzytkownikach IDE64 i tak nikt nie pomysli.
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 17:03
| Cytat: |
| Ja tam speedcode ZAWSZE generuje w czasie rzeczywistym a generatory koduje w assemblerze na c64, ale moje efekty sa/byly malo nowoczesne No i nie znam zadnego jezyka procz assemblera, bo to tylko hobby. |
Good joke z brakiem nowoczesnosci
Ogolnie mam wielki respekt dla ludzi kodujacych/linkujacych bez dobrodziejstw crossdev\'u, watpie czy bym pisal cokolwiek gdyby nie istnialy tak dobre narzedzia - KickAss, VICE, szybki loader i nie uzywal technik jak ponizej ulatwiajacych zycie. Ot. i moje poglady, kodera, ktory nie napisal linijki kodu na realnym sprzecie Jesli znasz assembler, to znasz wszystkie pojecia programistyczne potrzebne do skorzystania z dobrodziejstw KickAssemblera oraz prototypowania efektow.
Co do tego pierwszego, to manual wszystko wyjasnia, ogolnie jezyk skryptowy jest bardzo prosty, np wyswietlarka koali:
| Cytat: |
.const KOALA_TEMPLATE = \"C64FILE, Bitmap=$0000, ScreenRam=$1f40, ColorRam=$2328, BackgroundColor = $2710\" .var picture = LoadBinary(\"picture.prg\", KOALA_TEMPLATE) .pc = $0801 \"Basic Program\" :BasicUpstart($0810) .pc =$0810 \"Program\" lda #$38 sta $d018 lda #$d8 sta $d016 lda #$3b sta $d011 lda #0 sta $d020 lda #picture.getBackgroundColor() sta $d021 ldx #0 !loop: .for (var i=0: i<4: i++) { lda colorRam+i*$100,x sta $d800+i*$100,x } inx bne !loop- jmp * .pc = $0c00 .fill picture.getScreenRamSize(), picture.getScreenRam(i) .pc = $1c00 colorRam: .fill picture.getColorRamSize(), picture.getColorRam(i) .pc = $2000 .fill picture.getBitmapSize(), picture.getBitmap(i) |
Przyklad speedcode\'u ofcoz wylacznie edukacyjny.
To pierwszy krok w umilaniu sobie pracy, skrypt do generacji speedcode\'u przez KickAss\'a pisze sie chwile i masz efekt w pelnej chwale, zmiana parametrow/poprawki to formalnosci.
Jak rezultat Ci odpowiada, to KickAss nie zabroni Ci napisania generatora kodu
ale najpierw polecam spakowanie i zobaczenie jak szybko loader laduje gotowca i porownanie tego z orientacyjnym czasem dzialania generatora.Jak napisanie generatora bedzie potrzebne, to KickAss rowniez ulatwia to zadanie, zobacz sobie tutorial cruzer\'a, akapit \"optimising the speedcode\" i jego makra do robienia generatorow.
http://codebase64.org/doku.php?id=base:speedcode
Drugim krokiem zwiekszajacym przynajmniej w moim przypadku produktywnosc jest prototypowanie efektow tj. pisanie prototypu w C++ ktory dziala identycznie na poziomie algorytmicznym jak przyszly kod na C64, tj. tabelki sinusow, 8\'mio bitowe zmienne itd. Szczegolnie w przypadku efektow mocno matematycznych ta technika jest zbawieniem.
Profitami sa: blyskawiczna mozliwosc zobaczenia efektu w dzialaniu, latwe debugowanie, kombinowanie nad optymalizacja oraz zabawa parametrami oraz finalnie bardzo dobry speedcode, ktorego generator np. sprawdza, czy sasiednie piksele korzystaja z tego samego punktu na teksturze, proces mozna rozszerzyc na caly LUT.
Jakbys byl zainteresowany, to moge podeslac jakis przyklad na PW, nic nie szkodzi, ze nie znasz C++, zrozumiesz to w doslownie chwile.
Pisze tak bezposrednio do fenka, ale jak ktos chcialbym zobaczyc o co chodzi w prototypowaniu efektow, to ofcoz rowniez pomoge.
| Cytat: |
| Jak to jest z SD2IEC, bo nie do konca rozumiem. Rozumiem, ze szybkie loadery nie dzialaja, ale czy jezeli po stronie stacji napisze kod ktory korzysta tylko z DOSu stacji np. rozkazy wczytujace sektory do danego bufora to taki program moge rozkazami Kernala Memory-Write przeslac do stacji - do SD2IEC i go uruchomic ? Czy cos takiego dziala ? Jezeli tak to czy moge po stronie stacji dopisac procedure transmisji 2bitowej i czy SD2IEC to pociagnie ? Jezeli cos takiego dziala to faktycznie mozna zrezygnowac z szybkiego loadera i w wypadku wykrycia SD2IEC podmienic loader w stacji. Co do kompatybilnosci, nawet jak cos takiego przejdzie z SD2IEC to o mnie i uzytkownikach IDE64 i tak nikt nie pomysli. |
SD2IEC nie ma w srodku emulatora procesora 6502 wiec nie mozna napisac zadnego kodu do niej. Jest po prostu zaprogramowana na sztywno do obslugi kilku protokolow, jesli wykryje standardowy IEC, to sle powoli bajty standardowo, jesli wykryje protokol fastloadera AR, to wysyla dane w formacie fastloadera AR itd.
| Cytat: |
| Meczy mnie inny problem nie tyle predkosci loadera co tego, ze jak chce wczytac plik za pomoca Kernala to z pamiecia RAM od $e000-$ffff musze sie pozegnac na czas wczytywania ? |
Plus jeszcze przestrzen cartow jesli rozwiazanie ma byc generyczne, tj. obslugiwac i IDE64 o ile ten ma jakis fastloader podpinany do KERNEL\'a. Ofcoz mozna tez napisac wlasny mini loader korzystajacy powiedzmy z protokolu AR, ktory obsluguje SD2IEC, ale czy taki IDE64 tez? Wiec znowu wracamy do kompatybilnosci z jedna konkretna stacja.
Wiadomość wysłana przez: Kisiel w 15 Lutego 2011, 18:17
A ten loader krilla obsluguje bursta ?
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 18:32
| Cytat: |
| Nitro, to sama przyjemnosc klepac w turboassembler, pisanie na PC to juz nie ten klimat... |
Pozwole sobie zdecydowanie zaprzeczyc
Ale do wszystkiego ofcoz mozna przywyknac i sie przyzwyczaic, choc potem coz sie dziwic, ze ludzie czasu nie maja, szczegolnie koderzy.| Cytat: |
| A ten loader krilla obsluguje bursta ? |
Nie, zapotrzebowanie chyba bylo zerowe
Wiadomość wysłana przez: Kisiel w 15 Lutego 2011, 18:53
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 19:04
w przykladzie, to gdzie jest ten speedcode bo nie zauwazylem. Te $D800 ? Czy masz na mysli konwerter obrazka (zreszta koala ma juz swoj template \"gotowiec\").
Z SD2IEC widac ze nie miales stycznosci, bo ogolnikowo pochlonales kilka informacji (zreszta czuje ze nie tylko w tym temacie), traktujac to jak urzadzenie w rodzaju joysticka.
Jesli chodzi o AR i sd.. to niestety mylisz sie - wszechwladny ekszon sobie swietnie radzi najlepiej z 1541 (chyba macie cos wspolnego), ale tu sie szybko konczy, dobrze, ze nie podejmuje glupich krokow i od razu zwraca sie do kernala z prosba o transmisje. O dziwo jego okpiwany konkurent Final 3, sobie juz swietnie radzi z szybkim wczytywaniem (a przeciez nie wysyla kodu do sd2iec) i nie potrzebuje tu zadnych JiffyDos, a przeciez zostal stworzony lata swietlne informatyki wczesniej.
Fenek wlasnie, w tym rzecz, ze skopiowalem sobie procedury kernala, obcialem to co uwazalem za zbedne i przeszkadzajace np. w wyswietlaniu spriteow i takim \"malym\" gowienkiem (bo wyszlo tego 100$) wczytuje sobie w kazde miejsce pamieci (bo te $100 jest dowolnie relokowalne) i nie uzywam niczego oprocz rejestrow VIC-a (oczywiscie nie obowiazkowo). Tyle ze to jest na razie marna namiastka uniwersalnego turboloadera - w kazdym razie da sie.
Powiem szczerze, ze podniosles mnie na duchu, piszac o tym generowaniu speed code - myslalem, ze juz tylko ja walcze o wolne bajty w c64.
Co to Kickasm-a to jest ok. Sam sie na niego przerzucam, jedak jest mocno rozbudowanym kompilatorem z wielkim pakietem ulatwien jak wspomnial Nitro (i jest nadal rozwijany), trzeba korzystac z dobrodziejstw ALE w umiejetny sposob.
Nitro ubezpiecz Krill\'a bo jak niedaj panie mu sie noga podwinie...
Wiadomość wysłana przez: Kisiel w 15 Lutego 2011, 19:48
![\"Razz\"](\"images/smiles/icon_razz.gif\"){kind=icon}
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 19:59
| kisiel napisal: |
| AR swietnie dziala z karta CF, FC3 nie sprawdzalem.... wiec sie odpimpkaj od AR |
A masz JiffyDos-a ?
U mnie na orginalnym romie AR wczytuje z sd w normalu
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 20:18
| Cytat: |
| w przykladzie, to gdzie jest ten speedcode bo nie zauwazylem. Te $D800 ? |
Tak, ta petla:
| Cytat: |
| .for (var i=0: i<4: i++) { lda colorRam+i*$100,x sta $d800+i*$100,x } |
Zassembluje sie do
lda adres_color_ram+0
sta $d800+0
lda adres_color_ram+$100
sta $d800+$100
itd do $300
Podkreslam, ze jest to tylko przyklad edukacyjny jak sie ogolnie generuje speedcode za pomoca KickAssa.
| Cytat: |
Z SD2IEC widac ze nie miales stycznosci, bo ogolnikowo pochlonales kilka informacji (zreszta czuje ze nie tylko w tym temacie), traktujac to jak urzadzenie w rodzaju joysticka. Jesli chodzi o AR i sd.. to niestety mylisz sie - wszechwladny ekszon sobie swietnie radzi najlepiej z 1541 (chyba macie cos wspolnego), ale tu sie szybko konczy, dobrze, ze nie podejmuje glupich krokow i od razu zwraca sie do kernala z prosba o transmisje. O dziwo jego okpiwany konkurent Final 3, sobie juz swietnie radzi z szybkim wczytywaniem (a przeciez nie wysyla kodu do sd2iec) i nie potrzebuje tu zadnych JiffyDos, a przeciez zostal stworzony lata swietlne informatyki wczesniej. |
Cytat z, tresc identyczna z moimi slowami:
http://www.c64-wiki.com/index.php/sd2iec_(firmware)
| Cytat: |
| Are fastloaders supported? In general, no. Fastloaders consist of a code portion running on the C64 and of code running on the floppy. sd2iec cannot emulate a complete 1541 since this would imply emulating a whole 6502 processor, several additional circuits, and the floppy\'s mechanism. A microcontroller\'s resources are just not enough for that (it\'s not only about processing power and timing but also memory requirements). This can be done using an FPGA though - see 1541 Ultimate. For sd2iec, it is possible to add special support for individual fastloaders to the firmware only (which basically means reimplementing the fastloader\'s code formerly running on the floppy for the ATMega controller). |
Pomylil mi sie AR z FC3, ot i cala tajemnica dzialania FC3
| Cytat: |
| 2008-05-02: sd2iec 0.7 release including support for the Final Cartridge 3 fastloader among many other small changes. |
Aha, dalej tajemnica szybszego ladowania za pomoca procedury KERNAL\'a niz w przypadku 1541:
| Cytat: |
x64 (true drive emulation) 1.0x 380 Bytes/Sec 1.0x 400 Bytes/Sec C64DTV with sd2iec-based device(1) 1.7x 650 Bytes/Sec 1.6x 650 Bytes/Sec (1) No speed enhancements of the C64DTV are used here so expect performance to be the same using a C64. VICE(plus)/x64(dtv) emulates the 1541 timing including mechanics. As you can see, sd2iec speed is quite a bit faster even without any fastloader since no mechanic latency exists and sd2iec data processing is much faster. Note that speeders that do all processing in the floppy are limited to about 6x speed. These speeders run much faster with the sd2iec since computing power is not an issue there. The theoretical maximum speed of the CBM bus with a floppy that does not let the C64 wait ever is estimated at about 20-25k/Sec. Speed between test 1 and test 2 on the sd2iec differs because of speedloader setup time. |
Wiadomość wysłana przez: Skull w 15 Lutego 2011, 20:25
Wiadomość wysłana przez: Kisiel w 15 Lutego 2011, 20:41
Teoretyzujac, piszesz procke do kernala ktora komunikuje sie z sd2iec we wlasciwie sobie znany sposob (np. korzystajac z 8-bit parallel) i AR w niczym nie przeszkadza. Zysk w programach uzywajacych normala... bezcenny
Softa zawsze mozna podwedzic z IDE64
Wiadomość wysłana przez: zielok__ w 15 Lutego 2011, 21:30
| skull napisal: |
| Powiem szczerze, ze podniosles mnie na duchu, piszac o tym generowaniu speed code - myslalem, ze juz tylko ja walcze o wolne bajty w c64. |
Skull nie martw sie ja takze generuje speedcode w realtimie bo tak naprawde chyba nigdy nie stworzylem az tak skomplikowanego speedcodu aby jego generacja byla wolniejsza od ladowania. Zreszta w demie \"Portal\" przy obracanym obiekcie (260 punktow) speedcode (ten od mnozenia macierzy i malowania punktow) generuje podczas wykonywania speedcode do wymazywania tych punktow ktore wczesniej namalowal. I dzieje sie to 50 razy na sekunde.
Wiadomość wysłana przez: Nitro__ w 15 Lutego 2011, 22:08
I tak ekran bylby czarny(prawie), aby byl sync z muzyka
Ale to stary podpasiony efekt, do innych sobie generatorow nie wyobrazam.
Heh, ale nam sie dyskusja old vs. new wywiazala
Wiadomość wysłana przez: zielok__ w 15 Lutego 2011, 22:25
| Nitro napisal: |
Ale to stary podpasiony efekt, do innych sobie generatorow nie wyobrazam. |
A mozesz napisac co to za efekty? (najlepiej z przykladami) Bo ciekawy jestem.
Wiadomość wysłana przez: suchy w 15 Lutego 2011, 22:55
| Nitro napisal: |
...Heh, ale nam sie dyskusja old vs. new wywiazala. |
... warto czasem wsadzic kija w mrowisko
![\"Idea\"](\"images/smiles/icon_idea.gif\"){kind=icon}
PS Czytam z ogromnym zainteresowaniem
Wiadomość wysłana przez: Nitro__ w 16 Lutego 2011, 20:40
| Cytat: |
| A mozesz napisac co to za efekty? (najlepiej z przykladami) Bo ciekawy jestem. |
Np. wspomniany Phong, speedcode do niego spelnia definicje speedcode\'u ale do jego wygenerowania potrzebny jest PC, bo dane potrzebne do generacji oraz sam speedcode nie zmieszcza sie w pamieci o optymalnosci nie mowiac. Wracam tez do EE, sciagnij sobie zrodla i zobacz na generator kodu.
Dalej wezmy na warsztat klasyczny table distorter.
Po obliczeniach distort tabelki, ktorych chyba nikt nie robi w realtime, dostajemy dane - punkt na ekranie, punkt na teksturze.
Spoko, mozna na C64 napisac generator kodu do tego, wypluje on taki kod dla kazdego punktu na ekranie:
LDA punkt_na_teksturze
STA punkt_na_ekranie
LDA punkt_na_teksturze
STA punkt_na_ekranie1
LDA punkt_na_teksturze
STA punkt_na_ekranie2
itd.
Ale nie jest to optymalne rozwiazanie, optymalny generator bedzie laczyl punkty korzystajace z tego samego punktu na teksturze:
LDA punkt_na_teksturze
STA punkt_na_ekranie1
STA punkt_na_ekranie2
STA punkt_na_ekranie3
Aby to zrobic potrzeba brute force\'a tabelki, co zajeloby c64 wiecej niz sporo czasu - patrz BF Exotic Excitement, generator rowniez by sie skomplikowal lekko.
Moglbym jeszcze rzucic czyms znacznie ciekawszym, ale nie chce sie wystrzeliwac z amunicji, rzuce tylko ogolnikowo: tekstury
P.S. U snerg\'a w world rekordowym kalejdoskopie tez generatora kodu nie ma
Na jego czas ladowania tez nie narzekalem Z 18KB, ktore part zajmuje cruncher robi 9KB: 2-3s ladowania.
Wiadomość wysłana przez: zielok__ w 16 Lutego 2011, 22:36
Phong na torusie to czesto jest prekalkulowany i dzieki odpowiedniemu trickowi wydaje sie, ze nie jest. Na innych obiektach jakos nie przypominam sobie (no co moja pamiec jest dobra tylko krotka:))
Mam tylko jedna uwage bo ladujac z decrunchem efekt gdy nie generujemy speedcodu to musimy miec mnostwo wolnej pamieci aby to sie zmiescilo. Przy generacji zazwyczaj nie ma takich wymagan pamieciowych.
Podsumowujac zgadzam sie, ze ladowanie speedcodu moze byc czasem korzystne ale to wszystko zalezy od indywidualnej sytuacji.
ps. czy da sie w Kickass korzystac w makrach z danych ladowanych z plikow zewnetrznych?
Wiadomość wysłana przez: Nitro__ w 17 Lutego 2011, 21:59
| Cytat: |
| wystarczy sprawdzic kilka punktow obok czy nie zawieraja tego samego punktu tekstury a nie trzeba sprawdzac wszystkich. |
Trzeba aby byla pelna optymalnosc, przykladowo tunel - symetria pozostalych trzech cwiartek wzdluz pierwszej cwiartki.
Przy tunelu akurat latwo to zauwazyc i mozna napisac madry generator, ale prawdziwie uniwersalnym rozwiazaniem jest brute force, ktory na PC jest czysta formalnoscia.
| Cytat: |
| Mam tylko jedna uwage bo ladujac z decrunchem efekt gdy nie generujemy speedcodu to musimy miec mnostwo wolnej pamieci aby to sie zmiescilo. Przy generacji zazwyczaj nie ma takich wymagan pamieciowych. |
Decrunch jest na biezaco podczas ladowania, w niektorych przypadkach generator i dane do niego zajmuja duzo miejsca, a jeszcze trzeba drugie tyle na speedcode, np. wspomniany distorter.
| Cytat: |
| ps. czy da sie w Kickass korzystac w makrach z danych ladowanych z plikow zewnetrznych? |
Oczywiscie, jest rowniez fajny system szablonow co i gdzie jest w pliku, sprawdz manual, rozdzial 8.4
Np:
| Cytat: |
| .var dataTemplate = \"XCoord=0,YCoord=$100, BounceData=$200\" .var file = LoadBinary(\"moveData\", dataTemplate) XCoord: .fill file.getXCoordSize(), file.getXCoord(i) YCoord: .fill file.getYCoordSize(), file.getYCoord(i) BounceData: .fill file.getBounceDataSize(), file.getBounceData(i) |
Nie ma zadnych przeszkod, aby wszystkiego powyzej w makrach.
Wiadomość wysłana przez: digger w 20 Lutego 2011, 21:30
Po 15 latach rzeczy sie delikatnie mowiac zmienily. Personalnie przychylam sie do opcji Nitra (kompresowalny speedcode) –: latwo wygenerowac w KickAssie, przy tym zabawa w skomplikowany generator na C64 to mega mordega –: ja juz nie mam na to czasu, sorry Noipoco.Ladowanie plus rownoczesna dekompresja +1!
Wiadomość wysłana przez: zielok__ w 20 Lutego 2011, 22:01
ps. Zreszta ja to dziwny jestem bo sinusy i fonty takze generuje w trakcie wykonywania:)
sp2. Wizualizacji w processingu nie robie glownie dlatego, ze jednak specyfika c64 jest inna i musialbym i tak to pisac jeszcze raz (wiec szkoda czasu:))
Wiadomość wysłana przez: Kisiel w 20 Lutego 2011, 22:51
Wiadomość wysłana przez: zielok__ w 21 Lutego 2011, 07:08
Wiadomość wysłana przez: digger w 21 Lutego 2011, 09:03
Wiadomość wysłana przez: zielok__ w 21 Lutego 2011, 10:20
Przydaje sie to glownie w intrach typu 1024 bajtow ale w demie tez moze byc czasem przydatne (wszystko bedzie zalezec od specyficznej sytuacji)... Zreszta inaczej niemozliwe byloby zmieszczenie ditherowanej tablicy znakow w takim intrze. Technike te bedzie mozna zobaczyc w moim intrze ktore przygotowalem na Forever.