Loadery do stacji IEC-only

[Skull]

                   

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

[Nitro__]

                   

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.

[Skull]

no moze zbyt optymistycznie jednak do tego podeszlem.

[Kisiel]

Co do normala i AR, to jest wlasnie w nim piekne, jak nie kmini co to wlacza normal, a normalny normal dziala wielokrotnie szybciej niz oryginalny action.
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

[zielok__]

                   

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.

[Nitro__]

Zachecony dyskusja spojrzalem na makra cruzer\'a, moj speedcode do radiali, i mozna by go w miare bezstresowo wygenerowac, biorac pod uwage linking docelowy(przejscie z intro obrazka) bylbym ok. 1-1,5 sekundy do przodu biorac pod uwage czas generacji trzech prawie identycznych SC dla 128 kropek oraz do tego szkieletu SC je czyszczacego, do ktorego poprzednie zapisuja coordsy.
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

[zielok__]

                   

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.

[suchy]

                   

Nitro napisal:

...Heh, ale nam sie dyskusja old vs. new wywiazala.

... warto czasem wsadzic kija w mrowisko    

PS Czytam z ogromnym zainteresowaniem  

[Nitro__]

                   

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.

[zielok__]

Dzieki za info aczkolwiek przy distorterze spokojnie da sie to zrobic (jesli myslimy o tym samym efekcie:)). wystarczy sprawdzic kilka punktow obok czy nie zawieraja tego samego punktu tekstury a nie trzeba sprawdzac wszystkich.

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?

[Nitro__]

                   

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.

[digger]

Zajebista dyskusja, duzo sie dowiaduje z tego rozgrzebanego mrowiska 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!

[zielok__]

Ej no, nie przesadzajmy z ta mega mordega przy generowaniu speedcodu. Ja przy pisaniu generatora nie spedzilem nigdy dluzej niz gora 20 minut. Zazwyczaj zdecydowanie wiecej czasu mi zajmuje zooptymalizowanie procedury ktora uzyje w speedcodzie (a to takze w KickAss wystepuje). Widocznie nie napisalem mega skomplikowanego speedcodu:)

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:))

[Kisiel]

@zielok a do generacji sinusow (albo jakis takich) uzywasz procedur FP w basicu?

[zielok__]

Nie, czysty asm (czyli nie wywoluje zadnych procedurek z kernala)