c64scene.pl

"wstawią" dane szybciej niż JEDNA pętla powtarzająca wpisywane dane (działająca w tle) to coś tu jest nie tak - wynikałoby, że wg. twojego toku rozumowania - np. szkoda czyścić ekran skoro loader Krill-a zrobi to szybciej

Mówiłem, zacznij pisać dema Speedcode'y mogą być proste w rodzaju eor fillera:
EOR xxxx
STA xxxx
czy też kodu czyszczącego:
STA xxxx
STA xxxx
I w tych przypadkach ofcoz generator zrobi swoją robotę szybciej i będzie prosty. Ale mogą być też diablo skomplikowane jak ten z Exotic Excitement, polecam zapoznanie się z whitepaperem:
http://noname.c64.org/csdb/release/down ... ?id=119834
Pewnie i można by i zacząć generator optymalizować, może nawet napisać generator generatora , ale ja podziękuje za takie atrakcje, przyznaje szczerze, że jestem spaczony KickAssemblerem, i tylko przyparty do muru napisze generator bardziej skomplikowany niż powyższe proste przykłady.

ale szkoda takich stacji jak 1581 i innych drive-ów powstałych w czasach 1541.

? Loader krill'a w pełni obsługuje 1571 i 1581 tj. dyski dwustronne i 3,5 dla 1581. Przekopiowałem przed chwilą testowo Black Spark(zero modyfikacji) na D81, demko odpaliło, radiale zajmujące całą pamięć wczytały się bez problemu na czas, potem niestety zwis, albo loader jest za wolny, albo bug, albo pliki trzeba jakoś specjalnie ułożyć. Jakby się jakiś koneser stacji 1581 znalazł, to jak widać rzecz jest do szybkiego zrobienia.

pytanie tylko czy te superszybkie loadery sa az tak potrzebne w demach (co innego kopiery)

Powody dla których ja za hiper uniwersalne loadery podziękuje podałem wcześniej, szybkość, elastyczność, brak użerania się z kompatybilnością.
Aha, i wciąż efekty liczone na stacji są poletkiem słabo zbadanym, trzeba to zmienić
Wektory na drive'ie wszyscy znamy, zna ktoś jeszcze jakieś inne party liczące coś na stacji?

P.S. Na początku zabaw z loaderem pytałem krill'a o interlave, a ten doradził mi nie bawić się w to z powodu minimalnych zysków przy ładowaniu skompresowanych plików więc dyskietka trackma była tworzona przez CC1541 przy domyślnych opcjach.

Nitro pisze: Mówiłem, zacznij pisać dema

A się tych dem żeś napisał, ale spokojna twoja rozczochrana - pisze się i dema, tyle że wolno

Nitro pisze:...przyznaje szczerze, że jestem spaczony KickAssemblerem, i tylko przyparty do muru napisze generator bardziej skomplikowany niż powyższe proste przykłady.

no i tu jest pies pogrzebany, dobrze że się przyznałeś - "wystarczy" przerobić metakod z kicka na assembler (a czy ja mówię że to łatwe? jak całe programowanie)[/quote]

Wiem że c64+1541 to standard scenowy, ale wynika to raczej jak widać z wygodnictwa.

A się tych dem żeś napisał, ale spokojna twoja rozczochrana - pisze się i dema, tyle że wolno

Nie, po prostu przerabiałem omawiane tu tematy, loader krill'a, loader wegi'ego - wg. autora najszybszy na świecie oraz skomplikowane speedcode'y i imho mogę powiedzieć, że coś tam o tym wiem

no i tu jest pies pogrzebany, dobrze że się przyznałeś - "wystarczy" przerobić metakod z kicka na assembler (a czy ja mówię że to łatwe? jak całe programowanie)
Wiem że c64+1541 to standard scenowy, ale wynika to raczej jak widać z wygodnictwa.

Jak już mówiłem chodzi o szybkość, jakbym miał wstawić do kolejnego dema plasmę z wałkowanego Exotic Excitement, to wolę użyć loadera aby w ok. dwie-trzy sekundy załadować ok. 10kb gotowego speedcode'u, którego generator napisałem wygodnie i przyjemnie w C++.
Niż pisać ok. 60kb generator, zobacz sam:
http://noname.c64.org/csdb/release/down ... ?id=119833
i czekać 15s na generowanie speedcode'u.

Klaryfikując owe przyparcie do muru, miałem na myśli sytuację, kiedy w jakimś efekcie generator skomplikowanego speedcode'u byłby drastycznie szybszy od loadera, żaden praktyczny przykład nie przychodzi mi do głowy.

Nie wspomnę już o o nowoczesnych efektach, gdzie generacja speedcode'u jest poza zasięgiem C64, jak Phong Shading.

Ja tam speedcode ZAWSZE generuje w czasie rzeczywistym a generatory koduje w assemblerze na c64, ale moje efekty są/były mało nowoczesne No i nie znam żadnego języka prócz assemblera, bo to tylko hobby.
No jedynie w Lifework jest procedura wyświetlania FLIcomboAFLI, która jest wcześniej generowana/deaasemblowana/ręcznie debugowana i cyklowana i rozbita po dziurach w pamięci i łączona JMPami i ostatecznie
zapisana w pliku głównym kolekcji.

Męczy mnie inny problem nie tyle prędkości loadera co tego, że jak chcę wczytać plik za pomocą Kernala to z pamięcią RAM od $e000-$ffff muszę
się pożegnać na czas wczytywania ?

Jak to jest z SD2IEC, bo nie do końca rozumiem. Rozumiem, że szybkie loadery nie działają, ale czy jeżeli po stronie stacji napiszę kod który korzysta tylko z DOSu stacji np. rozkazy wczytujące sektory do danego bufora to taki program mogę rozkazami Kernala Memory-Write przesłać do stacji - do SD2IEC i go uruchomić ?
Czy coś takiego działa ? Jeżeli tak to czy mogę po stronie stacji dopisać
procedurę transmisji 2bitowej i czy SD2IEC to pociągnie ?
Jeżeli coś takiego działa to faktycznie można zrezygnować z szybkiego loadera i w wypadku wykrycia SD2IEC podmienić loader w stacji.
Co do kompatybilności, nawet jak coś takiego przejdzie z SD2IEC to o mnie i użytkownikach IDE64 i tak nikt nie pomyśli.

Ja tam speedcode ZAWSZE generuje w czasie rzeczywistym a generatory koduje w assemblerze na c64, ale moje efekty są/były mało nowoczesne No i nie znam żadnego języka prócz assemblera, bo to tylko hobby.

Good joke z brakiem nowoczesności Ogólnie mam wielki respekt dla ludzi kodujących/linkujących bez dobrodziejstw crossdev'u, wątpię czy bym pisał cokolwiek gdyby nie istniały tak dobre narzędzia - KickAss, VICE, szybki loader i nie używał technik jak poniżej ułatwiających życie. Ot. i moje poglądy, kodera, który nie napisał linijki kodu na realnym sprzęcie

Jeśli znasz assembler, to znasz wszystkie pojęcia programistyczne potrzebne do skorzystania z dobrodziejstw KickAssemblera oraz prototypowania efektów.
Co do tego pierwszego, to manual wszystko wyjaśnia, ogólnie język skryptowy jest bardzo prosty, np wyświetlarka koali:

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

Przykład speedcode'u ofcoz wyłącznie edukacyjny.
To pierwszy krok w umilaniu sobie pracy, skrypt do generacji speedcode'u przez KickAss'a pisze się chwilę i masz efekt w pełnej chwale, zmiana parametrów/poprawki to formalności.
Jak rezultat Ci odpowiada, to KickAss nie zabroni Ci napisania generatora kodu ale najpierw polecam spakowanie i zobaczenie jak szybko loader ładuje gotowca i porównanie tego z orientacyjnym czasem działania generatora.
Jak napisanie generatora będzie potrzebne, to KickAss również ułatwia to zadanie, zobacz sobie tutorial cruzer'a, akapit "optimising the speedcode" i jego makra do robienia generatorów.
http://codebase64.org/doku.php?id=base:speedcode

Drugim krokiem zwiększającym przynajmniej w moim przypadku produktywność jest prototypowanie efektów tj. pisanie prototypu w C++ który działa identycznie na poziomie algorytmicznym jak przyszły kod na C64, tj. tabelki sinusów, 8'mio bitowe zmienne itd. Szczególnie w przypadku efektów mocno matematycznych ta technika jest zbawieniem.
Profitami są: błyskawiczna możliwość zobaczenia efektu w działaniu, łatwe debugowanie, kombinowanie nad optymalizacją oraz zabawa parametrami oraz finalnie bardzo dobry speedcode, którego generator np. sprawdza, czy sąsiednie piksele korzystają z tego samego punktu na teksturze, proces można rozszerzyć na cały LUT.
Jakbyś był zainteresowany, to mogę podesłać jakiś przykład na PW, nic nie szkodzi, że nie znasz C++, zrozumiesz to w dosłownie chwilę.
Pisze tak bezpośrednio do fenka, ale jak ktoś chciałbym zobaczyć o co chodzi w prototypowaniu efektów, to ofcoz również pomogę.

Jak to jest z SD2IEC, bo nie do końca rozumiem. Rozumiem, że szybkie loadery nie działają, ale czy jeżeli po stronie stacji napiszę kod który korzysta tylko z DOSu stacji np. rozkazy wczytujące sektory do danego bufora to taki program mogę rozkazami Kernala Memory-Write przesłać do stacji - do SD2IEC i go uruchomić ?
Czy coś takiego działa ? Jeżeli tak to czy mogę po stronie stacji dopisać
procedurę transmisji 2bitowej i czy SD2IEC to pociągnie ?
Jeżeli coś takiego działa to faktycznie można zrezygnować z szybkiego loadera i w wypadku wykrycia SD2IEC podmienić loader w stacji.
Co do kompatybilności, nawet jak coś takiego przejdzie z SD2IEC to o mnie i użytkownikach IDE64 i tak nikt nie pomyśli.

SD2IEC nie ma w środku emulatora procesora 6502 więc nie można napisać żadnego kodu do niej. Jest po prostu zaprogramowana na sztywno do obsługi kilku protokołów, jeśli wykryje standardowy IEC, to śle powoli bajty standardowo, jeśli wykryje protokół fastloadera AR, to wysyła dane w formacie fastloadera AR itd.

Męczy mnie inny problem nie tyle prędkości loadera co tego, że jak chcę wczytać plik za pomocą Kernala to z pamięcią RAM od $e000-$ffff muszę
się pożegnać na czas wczytywania ?

Plus jeszcze przestrzeń cartów jeśli rozwiązanie ma być generyczne, tj. obsługiwać i IDE64 o ile ten ma jakiś fastloader podpinany do KERNEL'a. Ofcoz można też napisać własny mini loader korzystający powiedzmy z protokołu AR, który obsługuje SD2IEC, ale czy taki IDE64 też? Więc znowu wracamy do kompatybilności z jedną konkretną stacją.

Nitro, to sama przyjemność klepać w turboassembler, pisanie na PC to już nie ten klimat...
A ten loader krilla obsługuje bursta ?

Nitro, to sama przyjemność klepać w turboassembler, pisanie na PC to już nie ten klimat...

Pozwolę sobie zdecydowanie zaprzeczyć Ale do wszystkiego ofcoz można przywyknąć i się przyzwyczaić, choć potem cóż się dziwić, że ludzie czasu nie mają, szczególnie koderzy.

A ten loader krilla obsługuje bursta ?

Nie, zapotrzebowanie chyba było zerowe

Nitro ty jesteś z nowej szkoły, dla nas przyzwyczajanie się do emulców, krossów to inne czasy. Pewnych rzeczy nie zrobisz na emulcu i PC nigdy. Ja i parę innych osób kodujemy, pakujemy, ... na real sprzęcie. Ty musisz się do tego przyzwyczaić, inna szkoła.

Nitro synu niepokorny,
w przykładzie, to gdzie jest ten speedcode bo nie zauważyłem. Te $D800 ? Czy masz na myśli konwerter obrazka (zresztą koala ma już swój template "gotowiec").
Z SD2IEC widać że nie miałeś styczności, bo ogólnikowo pochłonąłęś kilka informacji (zreszta czuje że nie tylko w tym temacie), traktując to jak urządzenie w rodzaju joysticka.
Jeśli chodzi o AR i sd.. to niestety mylisz się - wszechwładny ekszon sobie świetnie radzi najlepiej z 1541 (chyba macie coś wspólnego), ale tu sie szybko kończy, dobrze, że nie podejmuje głupich kroków i od razu zwraca się do kernala z prośbą o transmisje. O dziwo jego okpiwany konkurent Final 3, sobie już świetnie radzi z szybkim wczytywaniem (a przeciez nie wysyła kodu do sd2iec) i nie potrzebuje tu żadnych JiffyDos, a przeciez został stworzony lata świetlne informatyki wcześniej.

Fenek właśnie, w tym rzecz, że skopiowałem sobie procedury kernala, obciąłem to co uważałem za zbędne i przeszkadzające np. w wyświetlaniu spriteów i takim "małym" gówienkiem (bo wyszło tego 100$) wczytuje sobie w każde miejsce pamięci (bo te $100 jest dowolnie relokowalne) i nie używam niczego oprócz rejestrów VIC-a (oczywiście nie obowiązkowo). Tyle że to jest na razie marna namiastka uniwersalnego turboloadera - w każdym razie da się.
Powiem szczerze, że podniosłeś mnie na duchu, pisząc o tym generowaniu speed code - myślałem, że już tylko ja walczę o wolne bajty w c64.
Co to Kickasm-a to jest ok. Sam się na niego przerzucam, jedak jest mocno rozbudowanym kompilatorem z wielkim pakietem ułatwień jak wspomniał Nitro (i jest nadal rozwijany), trzeba korzystać z dobrodziejstw ALE w umiejętny sposób.
Nitro ubezpiecz Krill'a bo jak niedaj panie mu sie noga podwinie...

AR świetnie działa z kartą CF, FC3 nie sprawdzałem.... więc się odpimpkaj od AR

kisiel pisze:AR świetnie działa z kartą CF, FC3 nie sprawdzałem.... więc się odpimpkaj od AR

A masz JiffyDos-a ?

U mnie na orginalnym romie AR wczytuje z sd w normalu

w przykładzie, to gdzie jest ten speedcode bo nie zauważyłem. Te $D800 ?

Tak, ta pętla:

.for (var i=0; i<4; i++) {
lda colorRam+i*$100,x
sta $d800+i*$100,x
}

Zassembluje się do
lda adres_color_ram+0
sta $d800+0
lda adres_color_ram+$100
sta $d800+$100
itd do $300
Podkreślam, że jest to tylko przykład edukacyjny jak się ogólnie generuje speedcode za pomocą KickAssa.

Z SD2IEC widać że nie miałeś styczności, bo ogólnikowo pochłonąłęś kilka informacji (zreszta czuje że nie tylko w tym temacie), traktując to jak urządzenie w rodzaju joysticka.
Jeśli chodzi o AR i sd.. to niestety mylisz się - wszechwładny ekszon sobie świetnie radzi najlepiej z 1541 (chyba macie coś wspólnego), ale tu sie szybko kończy, dobrze, że nie podejmuje głupich kroków i od razu zwraca się do kernala z prośbą o transmisje. O dziwo jego okpiwany konkurent Final 3, sobie już świetnie radzi z szybkim wczytywaniem (a przeciez nie wysyła kodu do sd2iec) i nie potrzebuje tu żadnych JiffyDos, a przeciez został stworzony lata świetlne informatyki wcześniej.

Cytat z, treść identyczna z moimi słowami:
http://www.c64-wiki.com/index.php/sd2iec_(firmware)

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

Pomylił mi się AR z FC3, ot i cała tajemnica działania FC3

2008-05-02: sd2iec 0.7 release including support for the Final Cartridge 3 fastloader among many other small changes.

Aha, dalej tajemnica szybszego ładowania za pomocą procedury KERNAL'a niż w przypadku 1541:

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.

no może zbyt optymistycznie jednak do tego podeszłem.

Co do normala i AR, to jest właśnie w nim piękne, jak nie kmini co to włącza normal, a normalny normal działa wielokrotnie szybciej niż oryginalny action.
Teoretyzując, piszesz prockę do kernala która komunikuje się z sd2iec we właściwie sobie znany sposób (np. korzystając z 8-bit parallel) i AR w niczym nie przeszkadza. Zysk w programach używających normala... bezcenny Softa zawsze można podwędzić z IDE64

skull pisze:
Powiem szczerze, że podniosłeś mnie na duchu, pisząc o tym generowaniu speed code - myślałem, że już tylko ja walczę o wolne bajty w c64.

Skull nie martw się ja także generuje speedcode w realtimie bo tak naprawdę chyba nigdy nie stworzyłem aż tak skomplikowanego speedcodu aby jego generacja była wolniejsza od ładowania. Zresztą w demie "Portal" przy obracanym obiekcie (260 punktów) speedcode (ten od mnozenia macierzy i malowania punktów) generuje podczas wykonywania speedcode do wymazywania tych punktów które wcześniej namalował. I dzieje się to 50 razy na sekundę.

Zachęcony dyskusją spojrzałem na makra cruzer'a, mój speedcode do radiali, i można by go w miarę bezstresowo wygenerować, biorąc pod uwagę linking docelowy(przejście z intro obrazka) byłbym ok. 1-1,5 sekundy do przodu biorąc pod uwagę czas generacji trzech prawie identycznych SC dla 128 kropek oraz do tego szkieletu SC je czyszczącego, do którego poprzednie zapisują coordsy.
I tak ekran byłby czarny(prawie), aby był sync z muzyką
Ale to stary podpasiony efekt, do innych sobie generatorów nie wyobrażam.
Heh, ale nam się dyskusja old vs. new wywiązała

Nitro pisze: Ale to stary podpasiony efekt, do innych sobie generatorów nie wyobrażam.

A możesz napisać co to za efekty? (najlepiej z przykładami) Bo ciekawy jestem.

Nitro pisze: ...Heh, ale nam się dyskusja old vs. new wywiązała.

... warto czasem wsadzić kija w mrowisko

PS Czytam z ogromnym zainteresowaniem

A możesz napisać co to za efekty? (najlepiej z przykładami) Bo ciekawy jestem.

Np. wspomniany Phong, speedcode do niego spełnia definicję speedcode'u ale do jego wygenerowania potrzebny jest PC, bo dane potrzebne do generacji oraz sam speedcode nie zmieszczą się w pamięci o optymalności nie mówiąc. Wracam też do EE, ściągnij sobie źródła i zobacz na generator kodu.

Dalej weźmy na warsztat klasyczny table distorter.
Po obliczeniach distort tabelki, których chyba nikt nie robi w realtime, dostajemy dane - punkt na ekranie, punkt na teksturze.
Spoko, można na C64 napisać generator kodu do tego, wypluje on taki kod dla każdego 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 rozwiązanie, optymalny generator będzie łączył punkty korzystające z tego samego punktu na teksturze:
LDA punkt_na_teksturze
STA punkt_na_ekranie1
STA punkt_na_ekranie2
STA punkt_na_ekranie3
Aby to zrobić potrzeba brute force'a tabelki, co zajęłoby c64 więcej niż sporo czasu - patrz BF Exotic Excitement, generator również by się skomplikował lekko.

Mógłbym jeszcze rzucić czymś znacznie ciekawszym, ale nie chce się wystrzeliwać z amunicji, rzucę tylko ogólnikowo: tekstury

P.S. U snerg'a w world rekordowym kalejdoskopie też generatora kodu nie ma Na jego czas ładowania też nie narzekałem Z 18KB, które part zajmuje cruncher robi 9KB: 2-3s ładowania.

Dzięki za info aczkolwiek przy distorterze spokojnie da się to zrobić (jeśli myślimy o tym samym efekcie:)). wystarczy sprawdzić kilka punktów obok czy nie zawierają tego samego punktu tekstury a nie trzeba sprawdzać wszystkich.

Phong na torusie to często jest prekalkulowany i dzięki odpowiedniemu trickowi wydaje się, że nie jest. Na innych obiektach jakoś nie przypominam sobie (no co moja pamięć jest dobra tylko krótka:))

Mam tylko jedna uwagę bo ładując z decrunchem efekt gdy nie generujemy speedcodu to musimy mieć mnóstwo wolnej pamięci aby to się zmieściło. Przy generacji zazwyczaj nie ma takich wymagań pamięciowych.

Podsumowując zgadzam się, że ładowanie speedcodu może być czasem korzystne ale to wszystko zależy od indywidualnej sytuacji.

ps. czy da się w Kickass korzystać w makrach z danych ładowanych z plików zewnętrznych?