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... (???)
) jak i ubicie jest zbliżone do LC,BB,Doynax (Doynax średnio 2% lepiej).
), ale czemu nie może tego pykać linker? Przecież to są rzeczy proste.