Loadery do stacji IEC-only

[Skull]

akurat w tych przykladach co wymieniles, smiem watpic ze sa az tak szybkie loadery - ale skoro Ty wczytujesz speedcode zamiast generowac - to moze inaczej podchodzisz do tego tematu.

[Nitro__]

Polecam wejscie na IRC\'a, poproszenie krill\'a o aktualny loader, i zabawe ladowaniem skompresowanych plikow jak masz watpliwosci co do szybkosci. Jakbys chcial go uzyc, to kompatybilnosc z SD2IEC i innymi fake\'ami jak juz mowilem dostaniesz o ile zasady podane wczesniej.

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.

[Skull]

Pliki i tak sie kompresuje, by mniej zajmowaly na dysku - jezeli twierdzisz, ze depacker (chocby \"znakowiec\", ktory przy dapaku ma jednak klika roznych warunkow \"tworzenia\" danych) + do tego loader (jak dwubitowy to oczywiscie scisle wycyklowany z przerwaniami rastra), \"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  

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.

[fenek__]

To ja sie wtrace na chwile. Moja wiedza o stacji i loaderach jest zerowa nie wiem jak je napisac ale mam pojecie jak one dzialaja i prosze przeczytac calosc tekstu.

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.

[Skull]

Zgadza sie Fenek, ale nie chodzi tu tylko o idee dzialania najwydajniejszych turboloaderow (t.j. z decrunchem), zreszta gdyby byl wegi to jeszcze dokladniej podalby mozlwie przeploty i wariacje odczytow.

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.

[Nitro__]

                   

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.

[Skull]

                   

Nitro napisal:

Mowilem, zacznij pisac dema

A sie tych dem zes napisal, ale spokojna twoja rozczochrana - pisze sie i dema, tyle ze wolno

                   

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.

[Nitro__]

                   

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.

[fenek__]

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.
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.

[Nitro__]

                   

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.

[Kisiel]

Nitro, to sama przyjemnosc klepac w turboassembler, pisanie na PC to juz nie ten klimat...
A ten loader krilla obsluguje bursta ?

[Nitro__]

                   

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

[Kisiel]

Nitro ty jestes z nowej szkoly, dla nas przyzwyczajanie sie do emulcow, krossow to inne czasy. Pewnych rzeczy nie zrobisz na emulcu i PC nigdy. Ja i pare innych osob kodujemy, pakujemy, ... na real sprzecie. Ty musisz sie do tego przyzwyczaic, inna szkola.

[Skull]

Nitro synu niepokorny,
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...

[Kisiel]

AR swietnie dziala z karta CF, FC3 nie sprawdzalem.... wiec sie odpimpkaj od AR