c64scene.pl

Angażując się w kwestie linkingu postanowiłem zrobić coś w miarę moich umiejętności solidnego i kompleksowego...

1. Loader - z tym nie powinno być problemu
2. D64 maker rozmieszczający optymalnie pliki - i tutaj jest już spora baza z trackmolinkera
3. Cruncher

Cruncher w założeniu miał być czymś pośrednim pomiędzy level crusherem a exomizerem. Tzn. aby dawał w miarę możliwości ubicie podobne lub lepsze od levelcrushera i depack przynajmniej z 30% szybszy przy użyciu tablicy 48 bajtów zamiast ponad 160ciu (exo). Przyznam, że w przypadku "wrednych" plików wyniki zaskoczyły mnie samego. W każdym razie cruncher działa zgodnie z założeniami tzn - w przypadku plików nie do "stablicowania" wyniki są podobne do pozostałych cruncherów, odbiegają do 5% średnio na korzyść exomizera w kwestii ubicia, jak i w przypadku plików "wrednych" dla level crushera daje lepsze ubicie (liczone w kilobajtach) przy jeszcze szybszym depacku. Założenia zostały osiągnięte depack jest szybszy (może być jeszcze szybszy ) jak i ubicie jest zbliżone do LC,BB,Doynax (Doynax średnio 2% lepiej).

Jeżeli są chętni do pomocy w uskutecznieniu tego dzieła to zapraszam. Liczę na Zieloka, Brusha, Wacka, Nitra i innych osób o których nie wiem, że starają się coś linkować. Może ESM nie poskładało jeszcze na 100% swego najnowszego dzieła i da się namówić do pomocy w stworzeniu tego rodzimego produktu, może i wykorzystaniu go. W każdym razie liczę conajmniej na owocną dyskusję - zapraszam do współpracy śląc końcowoświąteczne pozdrowienia
Proszę tylko nie wysnuwać życzeniowych bajek w stylu, niech ubija wszystko 2 razy lepiej, ładuje 2 razy szybciej a decruncher z loaderem niech zajmuje <100 bajtów

Gratki za chęci tyle na razie powiem, na więcej nie mam atm czasu, mam pełne ręce roboty z PC'towym demem, które o ile niebo nie spadnie mi na głowę wyjdzie jutro

Ja jestem zawsze chętny do testów czy coś

Tak też i rewelacja - myślę, żeby coś stworzyć pod użytek - widząc Twoje samozaparcie w linkowaniu B3 nie mam wątpliwości, że będzie dobrze:)
Wacek za to, że przebrnąłeś przez to u mnie respect masz:)

Pytania mam takie:

Czego brakowało Ci przy linkingu B3?

Czego oczekiwałbyś od takiej platformy linkującej?

Zostawiłem Ci do B3 przykład ładujący parta, z otwartymi borderami, śmigającymi po nich sprajtami w trakcie loadingu, w trakcie depaku dalej bordery pootwierane aż do przejścia w efekt - nie użyłeś - czymu?

Jak mówiłeś przeszedłeś na crossplatformę, pokompiluj i pouruchamiaj przykłady z trackmolinkera - ja kończę estetykę crunchera, gotowcami mógłbym sypnąć, ale nie chodzi o to, żeby się chwalić, tylko ustalić wspólnie czego chcemy. Szkoda, że wcześniej się nie dało...

Potem może obgadamy ideę deterministycznego ładowania jak masz ochotę?

wegi pisze:Czego brakowało Ci przy linkingu B3?

Wiesz, pamiętaj że ja korzystywałem z bardzo hardkorowego zestawu (loader Senseia + packer WVLa) bez żadnej automatyzacji. Więc brakowało mi rzeczy które na pewno już na dzisiaj nie są żadną rewelacją, tzn. głównie właśnie tej automatyzacji (pewnie dużo setupów to ma).

Fajnie by było mieć plik txt (albo narzędzie z GUI) w którym manualnie skryptuję sobie zawartość kompilowanego D64, na zasadzie:

1. tu wgraj START.EXE.PRG, dołącz INIT pod $4000, dołącz LOAD pod $C800, całość crunchuj z JMP $0900
2. następnie plik docelowy Z1: połącz plik 1000.ZAKv1.PRG pod $1000 oraz plik 2000.BITMAPAv2.PRG pod $2000, całość scrunchuj
3. następnie plik docelowy D2: połącz plik 6000.DATA.PRG pod $4100, scrunchuj, dołącz depacker pod $4000 z depackiem docelowym pod $6000
4. zrób z tego DEMOv1.D64

Niech narzędzie będzie w stanie rozróżnić/obsłużyć pliki plain i normalne
Niech narzędzie wykrywa wszelkiego rodzaju błędy, z naciskiem na overlapping plików przy ładowaniu/depakowaniu
Niech narzędzie dobiera optymalny przeplot
Niech sprawdza czy całość zmieści się w ogóle na stronie
Niech będzie w stanie oszacować po zbudowaniu D64 loading tajmy poszczególnych plików (zgrubnie z założeniem że w ramce jest irq z muzyką na #$17 linijek i nic więcej) plus opcjonalnie skalkulować czas: load + decrunch vs sam load niespakowanego, większego pliku - żeby oszacować czy pakowanie ma sens (jeżeli szybkość jest priorytetem)
Niech loader radzi sobie z $d011, $d000, sprajtami, ramkami etc.
Niech loader ma w opcji decrunch w locie w stacji, z narzędziem które policzy mi ile na tym potencjalnie zyskam/stracę

Nie wiem czy to dużo na pewno przy składaniu miałem tego więcej...

Wiesz, pamiętaj że ja korzystywałem z bardzo hardkorowego zestawu (loader Senseia + packer WVLa) bez żadnej automatyzacji. Więc brakowało mi rzeczy które na pewno już na dzisiaj nie są żadną rewelacją, tzn. głównie właśnie tej automatyzacji (pewnie dużo setupów to ma).

Po pierwsze nie odpowiedziałeś, czemu nie użyłeś przygotowanego do B3 loadera
Loader Senseia chyba jednobitowy był i to dawało największe opóźnienia
Packer WVLa to hitowy packer dający średnio 10% gorsze wyniki od cruncherów przy ponad 2krotnie większej szybkości depacku!

IMHO LZWVL to kolejny przykład dla Nitra - jak znam życie jego testy wykazałyby, że czas depacku jest dłuższy od używanego przez niego normalnie zestawu (sory Nitro czekam aż się włączysz do dyskusji) - z czego to wynika?

Wziął by to po staremu streamowo z czego by wyniknęło, że ładował 10-20% więcej danych co wydłużyło czas ładowania z depakiem w locie. Stwierdziłby - po co mi to byle co - ja już mam swój typ i po co się męczyć i dowodzić, że jest gorzej albo to samo...


Fajnie by było mieć plik txt (albo narzędzie z GUI) w którym manualnie skryptuję sobie zawartość kompilowanego D64, na zasadzie:

Coś w tę deseń robi trackmolinker, który dołączyłem Ci wraz ze skompilowanymi d64 z partem do B3. Kompiluje na dysk od tracka 1go pliki wskazane w skrypciku zapisuje je z przepl. 4 (dlaczego 4 wyjaśniłem w helpie)
Dołączyłem Ci Trackmolinkera - wystaczyło dodawać mu pliki z GUI do skryptu albo z edytora textowego i tworzyłby Ci D64

1. tu wgraj START.EXE.PRG, dołącz INIT pod $4000, dołącz LOAD pod $C800, całość crunchuj z JMP $0900
2. następnie plik docelowy Z1: połącz plik 1000.ZAKv1.PRG pod $1000 oraz plik 2000.BITMAPAv2.PRG pod $2000, całość scrunchuj

Troszeczkę mieszasz mi i się gubię - te rzeczy załatwia kompilator i polecenia include i binary
crunchowanie to linia poleceń osobnych dla crunchera - wygląda to tak, że to co masz pocrunchowane zaincludować - musisz mieć pocrunchowane wcześniej, a wynikowy plik crunchować po kompilacji.


3. następnie plik docelowy D2: połącz plik 6000.DATA.PRG pod $4100, scrunchuj, dołącz depacker pod $4000 z depackiem docelowym pod $6000
... Praktycznie depaker jest w jednym miejscu (wygodnym) w całym demie i odwołanie do niego z podaniem parametrów rozwiązuje sprawę. Wielokrotne powielanie depakera dla każdego parta jest rozrzutnością czasu ładowania, miejsca na dyskietce i ramu C64. Oczywiście są sytuacje wyjątkowe i może się tak zdarzyć, natomiast optuję za rezygnacją z permanentnej podmiany depakera.

4. zrób z tego DEMOv1.D64
To robi Trackmolinker - powtarzam dołączyłem go wraz z linią komend dla niego

Niech narzędzie będzie w stanie rozróżnić/obsłużyć pliki plain i normalne
... Tu coś dziwne jest dla mnie - a gdybym odpowiedział tak:
Ty nie robisz TOOLSA Ty robisz DEMO - więcej DETERMINISTYKI - doskonale wiesz, jaki ładujesz kolejny plik czy plain czy crunched, mało tego - przed rozpoczęciem ładowania wiesz, gdzie chcesz go załadować, jaki jest długi, i gdzie masz dla niego miejsce - wszystko to wiesz z góry przecież! Można np. zrezygnować z load adrsu i od samego początku mieć po 254 bajty danych w odczytywanym bloku...


Niech narzędzie wykrywa wszelkiego rodzaju błędy, z naciskiem na overlapping plików przy ładowaniu/depakowaniu
Cruncher testuje overlap i podaje bezpieczny load adres przesuwając go o 1 bajt za overlap - pełna kontrola tego jest

Niech narzędzie dobiera optymalny przeplot - tu mogą być problemy, bo będzie on wynikał z kilku warunków oprócz empiryki dochodzi jeszcze sytuacja wymieszania na jednej ścieżce danych z ponad jednego pliku z różnymi przeplotami

Niech sprawdza czy całość zmieści się w ogóle na stronie
Trackmolinker pokazuje ilość bloków w użyciu to już jest

Niech będzie w stanie oszacować po zbudowaniu D64 loading tajmy poszczególnych plików (zgrubnie z założeniem że w ramce jest irq z muzyką na #$17 linijek i nic więcej) plus opcjonalnie skalkulować czas: load + decrunch vs sam load niespakowanego, większego pliku - żeby oszacować czy pakowanie ma sens (jeżeli szybkość jest priorytetem)
Zgrubnie można to szacować, chociaż naprawdę, to kwestia tylko uruchomienia skompilowanego pliku...

Niech loader radzi sobie z $d011, $d000, sprajtami, ramkami etc.

Uściślijmy - $d011, $D000 TAK, sprajty - TAK da się i to przejść używając ATN do synchronizacji - ma to swoje wady i zalety
Tak naprawdę, nie słyszałem wielkiego larum, że np. EOD nie chodzi na 1570/71 a nie chodzi...
Borderów loader nie otwiera - to robi Twój program


Niech loader ma w opcji decrunch w locie w stacji, z narzędziem które policzy mi ile na tym potencjalnie zyskam/stracę
decrunch w locie stacji... jest to do zrobienia, raczej jako dodatkowy loader - podmieniany na zasadzie drivecalca w ILTC
Decrunch zabierze miejsce na tablice, spowolni loader plus większa ilość bajtów do transmisji - takie pomysły sprawiają, że resztki moich włosów jeżą się mi na głowie, ale staram się mieć openmajnda

Nie wiem czy to dużo na pewno przy składaniu miałem tego więcej...

Dwa pytania do wszystkich - jakich używacie loaderów ? Tzn jak jest realizowany load? - do czego zmierzam - jest zagwozdka z overlappingiem czyli np pakujemy program od obszaru $2000 do $fff0 i akurat overlap wyniósł ze 20 bajtów co oznacza nie tylko ładowanie POD I/O, nadpisanie wektorów od $fffa ale także przejście na $00 i $01...
Taki program daje się depakować przy użyciu stałego bufora odczytywanego bloku np pod $0200 i flajowego decrunchu
Następne pytanie - co z ładowaniem pod IO - jak realizuje to loader bo:
Albo ma na stałe w kodzie dec $01 sta ($xx),y inc $01, co wydłuża czas ładowania dla plików nieładowanych pod I/O, albo dane są relokowane z bufora np. na zasadzie depaku, lub po prostu taki load z dodatkowym buforem odczytanego bloku, albo opcja w kodzie ładowania pod I/O lub nie, co wydłuży kod loadera... (???)

Dżizas nie zakminiłem jeszcze jednego - decrunch w drivie owocowałby qrewskimi opóźnieniami, bo driv byłby zajęty wysyłeniem i decrunchowaniem a dopiero potem mógłby zacząć szukać kolejnego sektora, dekodować go i wysyłać. Natomiast jest to wykonalne gdyby była taka konieczność...

wegi pisze:Po pierwsze nie odpowiedziałeś, czemu nie użyłeś przygotowanego do B3 loadera

Na to pytanie mogę Ci odpowiedzieć ale na privie

Loader Senseia chyba jednobitowy był i to dawało największe opóźnienia

Dwubitowy.

Packer WVLa to hitowy packer dający średnio 10% gorsze wyniki od cruncherów przy ponad 2krotnie większej szybkości depacku!

Wiem, użyłem go z polecenia i faktycznie jest to zajebisty packer do dem, jego szybkość to mistrzostwo świata.

Coś w tę deseń robi trackmolinker

Ja kumam, ale widzisz jak już się okazało że składamy na loaderze Senseia, to do trackmolinkera nie zaglądałem. Właśnie dlatego napisałem że pewnie większość tych rzeczy jest

2. następnie plik docelowy Z1: połącz plik 1000.ZAKv1.PRG pod $1000 oraz plik 2000.BITMAPAv2.PRG pod $2000, całość scrunchuj
Troszeczkę mieszasz mi i się gubię - te rzeczy załatwia kompilator i polecenia include i binary crunchowanie to linia poleceń osobnych dla crunchera - wygląda to tak, że to co masz pocrunchowane zaincludować - musisz mieć pocrunchowane wcześniej, a wynikowy plik crunchować po kompilacji.

No to w takim razie potrzebny jest cruncher "z dziurami". W sytuacji wtórej składam demo gdzie sekunda różnicy w te lub we wte jest wiecznością, czasem decydowałem się na wrzucenie kilku scrunchowanych segmentów do jednego fizycznego pliku na dysku, żeby zaoszczędzić na seek time.

... Praktycznie depaker jest w jednym miejscu (wygodnym) w całym demie i odwołanie do niego z podaniem parametrów rozwiązuje sprawę.

To jest idealna sytuacja, która nie zawsze jest możliwa. Vide part, który na dysku zajmuje 8 bloków, a po uruchomieniu generuje speed kod od $0400 do $fff0 z jedną dziurą na #$ff bajtów gdzie _może_ zmieścisz LOAD. Albo jak masz party z kompletnie różnymi rozplanowaniami pamięci Wtedy depacker w ładowany pliku to mus

Niech narzędzie będzie w stanie rozróżnić/obsłużyć pliki plain i normalne
... Tu coś dziwne jest dla mnie - a gdybym odpowiedział tak:
Ty nie robisz TOOLSA Ty robisz DEMO - więcej DETERMINISTYKI - doskonale wiesz, jaki ładujesz kolejny plik czy plain czy crunched

Nie zrozumieliśmy się
Nie chodziło mi o pliki crunched i uncrunched, tylko plain i normal.
Pliki "normalne" to pliki w których 2 pierwsze bajty to load address ($00 $10 na przykład), pliki "plain" to pliki bez tych dwóch bajtów. Jak składasz D64 do kupy za pomocą StarCommandera (jak ja to robiłem), który nie potrafi skonwertować jednego an drugie, i generalnie korzystasz tylko z normalnych, za wyjątkiem tego że cruncher WVLa obsługuje tylko pliki plain (!!!), to wiedziałbyś o czy mówię. Jeżeli miałem pliki "wielokrotnie złożone" tak jak pisałem, gdzie łączyły się scruchowane dane z kilku partów lub kilku segmentów pamięci, plus niescrunchowany kod, to jeżeli poprawiłem jeden z tych składowych plików to musiałem:
* wyciągnąć plik z D64
* odpalić edytor hex
* wgrać plik
* wyciąć dwa pierwsze bajty
* zapisać plik
* scrunchować LZWVLem
* opdalić edytor hex
* władować plik
* dołożyć dwa pierwsze bajty
* zapisać plik
* a na końcu mozolnie poskładać plik z podmienieniem jednego zcrunchowanego segmentu (a pliki do niektórych partów miały np. po 20 kolejnych wersji)

Cruncher testuje overlap i podaje bezpieczny load adres przesuwając go o 1 bajt za overlap - pełna kontrola tego jest

To fajnie, ale moje marzenie to linker który to sprawdza pomiędzy partami gdzie sobie w skrypcie definiujesz: jak wychodzę z parta 2 to na ekranie mam $2000-$4000, przerwania pod $0f00, zak siedzi pod $1000-$2000, load pod $0e00, depack pod $0d00 i to są zakazane obszary pamięci. Teraz jak ustawię w loadzie następnego parta cokolwiek co mi zahaczy o te obszary to linker wywala błąd.
W B3 i innych demach między innymi właśnie do tego przydaje się zasrany Excel (o którym chyba utworzę osobny temat tak dla frajdy ), ale czemu nie może tego pykać linker? Przecież to są rzeczy proste.

Niech narzędzie dobiera optymalny przeplot - tu mogą być problemy, bo będzie on wynikał z kilku warunków oprócz empiryki dochodzi jeszcze sytuacja wymieszania na jednej ścieżce danych z ponad jednego pliku z różnymi przeplotami

Ciężko napisać do tego algorytm? Przecież ty to masz na pewno w głowie Jakby zrobić to co dalej napisałem tzn. żeby w GUI wyświetlało szacowane czasy loadu/depacku itd. to to by mogła być część tego mechanizmu liczącego: jeżeli zostawisz ten plik tutaj to będziesz miał 8 sekund, ale jeżeli przesuniesz go manualnie na początek następnej ścieżki, to zyskasz 2 sekundy.

Zgrubnie można to szacować, chociaż naprawdę, to kwestia tylko uruchomienia skompilowanego pliku...

Nie ma nic gorszego przy składaniu dema, niż ciągłe odpalanie go bez końca od początku. Jest to strasznie wyczerpujące i dlatego tak wiele osób wymięka przy linkowaniu (ja byłem bliski). Myślisz że dlaczego Offence robi dema na spację? Bo nie chcą zgłupieć odpalając bez końca czterech stron dysku od początku. Tak ja wiem - part requestery i te rzeczy, no ale synchronizacja z zakami się marzy, nie?
I teraz jak robisz tak jak ja w B3 tzn. optymalizujesz po czym odpalasz żeby sprawdzić czy ci się load time skrócił o sekundę czy nie po 15x, to wiesz o czy mówię. A mierzenie tych czasów nie jest proste, przydaje się stoper w komórce - jakby ktoś kiedyś skompilował mi vajsa z RTC na overlayu, zerowanym na kliknięcie. to bym go chyba ozłocił

Niech loader radzi sobie z $d011, $d000, sprajtami, ramkami etc.
Uściślijmy - $d011, $D000 TAK, sprajty - TAK da się i to przejść używając ATN do synchronizacji - ma to swoje wady i zalety

B3 jest na loaderze który ma problemy z tymi wszystkimi rzeczami

Borderów loader nie otwiera - to robi Twój program

Tak, ale chciałbym loader który sobie z tym radzi

decrunch w locie stacji... jest to do zrobienia, raczej jako dodatkowy loader - podmieniany na zasadzie drivecalca w ILTC
Decrunch zabierze miejsce na tablice, spowolni loader plus większa ilość bajtów do transmisji - takie pomysły sprawiają, że resztki moich włosów jeżą się mi na głowie, ale staram się mieć openmajnda

Wiesz o co głównie chodzi? O sytuację w której naprawdę już nie ma gdzie wgrać do obszaru A-B, żeby z niego decrunchować do C-D. Ja miałem takich sytuacji co najmniej dwie i naprawdę, jaka wtedy jest żonglerka segmentami w pamięci to nie jesteś w stanie pojąć. Wtedy loader z decrunchem w stacji może być TEORETYCZNIE wolniejszy, ale za względu na brak przerzucania dużych obszarów w pamięci oraz wyszukiwaniu kilku plików, ostatecznie może być szybszy. Tylko fakt, pewnie dynamiczne przełączanie tego w trakcie dema to marzenie ściętej głowy

albo opcja w kodzie ładowania pod I/O lub nie, co wydłuży kod loadera... (???)

No tak, ale faktycznie - o ile wydłuży? Kilka bajtów? Pytam bo nie wiem. A faktycznia opcja przełączania tego przed skokiem do LOAD to znowu byłaby bajka. Przynajmniej dla mnie

wegi pisze:decrunch w drivie owocowałby qrewskimi opóźnieniami, bo driv byłby zajęty wysyłeniem i decrunchowaniem a dopiero potem mógłby zacząć szukać kolejnego sektora, dekodować go i wysyłać. Natomiast jest to wykonalne gdyby była taka konieczność...

ale dlaczego decrunch w locie musi odbywac sie akurat w stacji?

poza przerwaniem wrzucam sobie jsr loading do wykonania w stacji

a co ramke albo nawet kilka razy na ramke wykonuje sobie na przerwaniach jsr decrunch (tak jak granie muzyki)

stacja odczytuje dane i bez zadnego decrunchu zapisuje w buforze (wielkosc do wyboru np $0f00-0fff)

procedura decrunch sprawdza czy cos jest w buforze i wykonuje iles operacji (do wyboru)

szkoda tylko ze stacja nie bedzie miala co robic czekajac na kolejny sektor

nie da sie chyba zrobic wywolywania procedury decrunch na przemian raz w stacji i raz na c64, ale moze ktos o tym nie wie i to zrobi

ps. to chyba jest ten ring buffering wymyslony przez HCL, ktory ma zrobic Krill.

Seba wacek - najpierw powiedzcie mi jak tak ładnie partialnie cytować - najpierw dam znać na jedno.
Wacek sytuacja z B3 się nie powtórzy, gdzie składasz party niekompatybilne ze sobą - pisząc demo nawet jak zmieniasz standad - po prostu o TYM WIESZ - ja np. w ILTC miałem party w jednym standardzie, mało tego - gdybym go zmienił - PO PROSTU WIEM DOKŁADNIE jak go zmieniłem i robię sobie 1 plik include dla całego dema z parametrami do każdego parta. W tym pliku miałem takie info jak start adres każdego parta, strat track, sector... bez potrzeby zaczytywania katalogu mieszania w nim - on includował mi się do każdego parta i pobierał potrzebne informacje. Ciut więcej deterministyki Wacku. Weź mi jeszcze raz Seba wykmiń ten ringbuffering bo jak dla mnie jest to jakaś chyba nazwa prostej rzeczy owinięta w wysoki poziom abstrakcji i otoczkę szumnej nazwy...

Partialny cruncher... trudno mi się odnieść do czegoś takiego w mojej opinii może się zmienić o kilka bajtów overlap - scanner po prostu nie wykryje sekwencji najczęściej i doda informację dla decrunchera - "przekopiuj x bajtów" zajmie to z 15-20 bitów w infostreamie, czasem znajdzie pare sekwencji to skróci go o parę bajtów... Nie przyswoiłem jeszcze Waszych postów - imo wszystkie te zabawy z hex edytorem wyjaśnia cruncher w którym możesz ustawić, czy zapisuje load adres, czy chcesz go zmienić i podać inny, jaki wybierasz depack adres, czy rezygnujesz z podania depack adresu, czy rezygnujesz z load adresu etcetera. Jeżeli jest burdel, że masz jakiegoś parta, zwolniłeś np. 8KB a masz do dogrania 10 KB - w trackmolinkerze masz opcję SPLIT FILE - możesz to dogrywać partialnie...

Najpierw powiedzcie jak mam tak ładnie cytować bo się bałagan zrobi

Na górze przycisk CYTUJ

I potem to co ma być cytowane formatujesz jako:
co daje:

wacek pisze:Tu cytat

Ja klikam CYTUJ u gory kazdego posta do ktorego chce sie odniesc,
otwiera sie okienko z tekstem zaczynajacym sie
od 'nawias kwadratowy' quote="wegi 'nawias kwadratowy'
Seba wacek....
a konczacym na 'nawias kwadratowy' /quote 'nawias kwadratowy'

Zaznaczam calosc, wrzucam do notatnika, wycinam to co niepotrzebne,
a na koncu pod wyrazeniem " /quote " dopisuje swoje glupotki

Miedzy cytowanymi zdaniami wrzucam wyrazenia " quote="wegi "
i " /quote " jesli chce cos zacytowac ze srodka.

Pocwicz sobie, zobacz co wyjdzie, posty na forum mozesz edytowac - przycisk zmien.

wegi pisze:Wacek sytuacja z B3 się nie powtórzy, gdzie składasz party niekompatybilne ze sobą

Najlepsze efekty są niekompatybilne z niczym, a ja nadal takie chcę mieć

W tym pliku miałem takie info jak start adres każdego parta, strat track, sector... bez potrzeby zaczytywania katalogu mieszania w nim - on includował mi się do każdego parta i pobierał potrzebne informacje.

No to właśnie taki skrypt do linkera jest potrzebny.

Weź mi jeszcze raz Seba wykmiń ten ringbuffering

Seba bredzi.
Ring buffering to nic innego jak zdefiniować sobie na przykład że bufor to jest w pamięci obszar od $1000 do $1fff i ten obszar jest z punktu widzenia kodu zaloopowany - jego koniec jest początkiem. Czyli załóżmy że loader wgrywa dane do pamięci ciurkiem do $1fff, a potem zamiast do $2000 to wgrywa do $1000 i tak dalej.

imo wszystkie te zabawy z hex edytorem wyjaśnia cruncher

Chodzi mi o to, że nie możesz LZWVLowi powiedzieć, że plik który nim kranczujesz ma z przodu 2 bajty load adresu. LZWVL traktuje te 2 bajty jako pierwsze 2 bajty danych, więc plik wynikowy jest zwalony. To jest jego największa wada która powoduje mus odpalania hex edytora

Sebaloz/Lepsi.De pisze:stacja odczytuje dane i bez zadnego decrunchu zapisuje w buforze (wielkosc do wyboru np $0f00-0fff)

procedura decrunch sprawdza czy cos jest w buforze i wykonuje iles operacji (do wyboru)

Czy chodzi np o to, żeby stacja pracowała "na zakładkę"? Tzn. żeby pobierała po odczytaniu ostatniego bloku czytanego pliku pierwszy blok następnego pliku i czekała kiedy będzie mogła wysłać dane?
A bufor jest w ramie C64 i zajmuje 256 bajtów? Czy $0fff bajtów?

[quote="wackee]
Seba bredzi.
Ring buffering to nic innego jak zdefiniować sobie na przykład że bufor to jest w pamięci obszar od $1000 do $1fff i ten obszar jest z punktu widzenia kodu zaloopowany - jego koniec jest początkiem. Czyli załóżmy że loader wgrywa dane do pamięci ciurkiem do $1fff, a potem zamiast do $2000 to wgrywa do $1000 i tak dalej.

imo wszystkie te zabawy z hex edytorem wyjaśnia cruncher

Chodzi mi o to, że nie możesz LZWVLowi powiedzieć, że plik który nim kranczujesz ma z przodu 2 bajty load adresu. LZWVL traktuje te 2 bajty jako pierwsze 2 bajty danych, więc plik wynikowy jest zwalony. To jest jego największa wada która powoduje mus odpalania hex edytora
- mówisz, że nie ma opcji poinformowania LZWVLa, że jest plik PRG z loadadresem?
[/quote]

No i co z tym ringbuferem - tzn. masz part fenkowy i gdzie on będzie, albo... co płynnie ma się zminejszać/zwiększać? Oprócz ilości operacji do kontroli pozostawałby raczej "actual depack adress" bo nie wiesz czy spotkasz np. zdecrunchuj 3 bajty o offsecie 2954 albo np. skopiuj 1350 bajtów wciśniętego wackowego scrunchowanego rusunku...
Taki ring buffering to w pewnym sensie zaczytywanie po 1m sektorze danych z driva - to co pisałem o pominięciu overlap poza $ffff...

Ale jakieś co badania były z tym? Może to i ciekawa rzecz...

"Chodzi mi o to, że nie możesz LZWVLowi powiedzieć, że plik który nim kranczujesz ma z przodu 2 bajty load adresu. LZWVL traktuje te 2 bajty jako pierwsze 2 bajty danych, więc plik wynikowy jest zwalony. To jest jego największa wada która powoduje mus odpalania hex edytora"

- on zdaje się dał źródła do niego - odpalić dev c++ (kilka mega do ściągnięcia), zmienić aby ignorował pierwsze 2 bajty i przekompilować. Zielok zna wszystkie języki programowania by Ci zrobił...

Nawet wiem kto polecił LZWVL

Dzięki za wyjaśnienie ringbufferingu

wegi pisze:Weź mi jeszcze raz Seba wykmiń ten ringbuffering bo jak dla mnie jest to jakaś chyba nazwa prostej rzeczy owinięta w wysoki poziom abstrakcji i otoczkę szumnej nazwy...

Przy rozmowie Nitra z Krillem na Revision nie bylem, bo lezalem pijany przed wejsciem na party place

wegi pisze:"przekopiuj x bajtów" zajmie to z 15-20 bitów w infostreamie, czasem znajdzie pare sekwencji to skróci go o parę bajtów...

Myslalem zeby stacja decrunchowala jakies prostsze sekwencje zamieniajac je na najprostsze instrukcje kopiuj. Nie wiem tylko jak to ogarnac, bo nie koduje stacji ani cruncherow. Ale wtedy chyba musialby byc byc dwa bufory, jeden w pamieci stacji, a drugi w pamieci c64.

Stacja zapisuje dane do pamieci c64 np 3 bajty na 0f00, 0f01, 0f02 i ustawia znacznik poczatku na #$00 (0f00) i znacznik konca na #$02 (0f02). Procedura decrunch odczytuje znacznik poczatku #$00 (0f00), wykonuje instrukcje w tym przypadku 3 bajty, zmienia znacznik poczatku na #$02 (0f02). Jesli nie ma co decrunchowac to rts. Jak dojdzie do konca bufora to kolejne np 3 bajty zapisuje do $0fff, potem $0f00, $0f01 (jesli znacznik poczatku jest wiekszy od znacznika konca #$01 czyli dane zostaly zdecrunchowane do pamieci c64).

wackee pisze:

Weź mi jeszcze raz Seba wykmiń ten ringbuffering

Seba bredzi.

Wacek, daruj sobie takie teksty w moim kierunku. Z tego co tutaj powypisywales, z Twojego skladania dema (pewnie robiles najlepiej jak potrafiles), ale mozna by sie z tego nabijac calymi dniami. Jakos tego nie robie, wiec daruj sobie wycieczki osobiste, bo to chyba ma byc projekt ponad podzialami?

Szkoda ze na poczatku nie wyjasniles Wegiemu co to jest ringbuffering i jak moglby byc wykorzystany podczas ladowania z decrunchem, bo z samym tematem ringbufferingiem to kazdy koder sie spotkal np na stosie.

wegi pisze:

Sebaloz/Lepsi.De pisze:stacja odczytuje dane i bez zadnego decrunchu zapisuje w buforze (wielkosc do wyboru np $0f00-0fff)
procedura decrunch sprawdza czy cos jest w buforze i wykonuje iles operacji (do wyboru)

Czy chodzi np o to, żeby stacja pracowała "na zakładkę"? Tzn. żeby pobierała po odczytaniu ostatniego bloku czytanego pliku pierwszy blok następnego pliku i czekała kiedy będzie mogła wysłać dane?
A bufor jest w ramie C64 i zajmuje 256 bajtów? Czy $0fff bajtów?

Zostanmy w obrebie jednego pliku. Stacja odczytuje np 3 bajty z dysku, jesli moze to cos zdecrunchuje i do pamieci c64 zapisuje juz 3 albo wiecej bajtow (max 256 bo tyle ma przykladowy bufor od $0f00 do $0fff). Potem stacja odczytuje kolejne bajty z tego samego pliku na dysku i jesli w buforze c64 jest miejsce to zapisuje, a jesli nie ma tyle miejsca to czeka az bufor sie zwolni (sprawdzajac znacznik).

Sebaloz/Lepsi.De pisze:Wacek, daruj sobie takie teksty w moim kierunku.

Nie bądź taki delikatny, a poza tym to będę robił co będę chciał i chuj Ci do tego Jakoś nie zauważyłem żebyś się pytał kogokolwiek czy możesz go obrażać w swoich postach lub wypisywać plotki i inne pierdoły. Naprawianie świata zawsze zaczynamy od siebie

Z tego co tutaj powypisywales, z Twojego skladania dema (pewnie robiles najlepiej jak potrafiles), ale mozna by sie z tego nabijac calymi dniami.

Ależ proszę bardzo, nabijaj się, byle merytorycznie, jestem całkiem ciekaw co znajdziesz tam takiego zabawnego. Nie to żeby Twoja opinia na jakikolwiek temat miała dla mnie znaczenie.

Szkoda ze na poczatku nie wyjasniles Wegiemu co to jest ringbuffering

Najpierw przeczytałem to co Ty napisałeś, a po stwierdzeniu że jednak nie wyjaśniłeś Wegiemu o co chodzi, sam napisałem wyjaśnienie. Powyżej masz podziękowanie, że napisałem tak że można zrozumieć (powtarzam, tak zabełkotałeś że ja również Twojego wyjaśnienia nie pokumałem).

i jak moglby byc wykorzystany podczas ladowania z decrunchem

Nie wiem, więc nie piszę. Polecam tę filozofię.

wegi pisze:on zdaje się dał źródła do niego - odpalić dev c++ (kilka mega do ściągnięcia), zmienić aby ignorował pierwsze 2 bajty i przekompilować. Zielok zna wszystkie języki programowania by Ci zrobił...

<joke>
Zielok jeszcze kiedyś to mi pomagał, ale teraz już mi nie pomoże ze względu na barwy klubowe
</joke>

Dzięki za wyjaśnienie ringbufferingu

np.

Ten plik to nemezis dla cruncherów - najgorszy plik z ILTC pod względem podatności na ubicie. Faktycznie miał 105 bloków i mulasty depak. Teraz może mieć 78. Ta wersja ma dołożony msx, initloader, grafike... W demie zajmowała obszar od $4700 do $ff01 - spakowany miał jak mówię 105 bloków. Te wyniki są dla wersji uruchomieniowej - robiąc crunchera obserwowałem ten plik i kombinowałem przy scanerze... W sumie wymyśliłem jeszcze parę kruczków w scanerze co by go jeszcze trochę skracały, ale cruncher dawał potem gorsze wyniki w innych plikach. Jest on spakowany exomizerem, level crusherem, byteboozerem i doynaxa cruncherem na który zwracam szczególną uwagę - polukajcie sobie - IRQ zlicza ramki na depak - dpaker nie jest jeszcze całkiem dopracowany...