loadery

[joodas]

Witam wszystkich

Z jakimi loaderami najlepiej zapoznac sie na komcia? Jakie jest w miare prosty do zrozumienia i opanowania?

Pozdro
Joodas

[kotrobot]

Teraz chyba wszyscy używają loadera Krilla:

http://noname.c64.org/csdb/release/?id=78348

Ale nie wiem, czy prosty.

[DJ Gruby]

W Attitude używam loadera HCLa. W Pieces II wykorzystałem loader Cadavera. Do dema Arsenic skompilowałem loader Krilla. Dwa pierwsze funkcjonują bez najmniejszych problemów... Z ostatnim trzeba było trochę powalczyć, żeby przystosować go do użytku (ale było warto!).

[joodas]

Badal ktos loadera Dekadence?

[kmeg]

Loader Krill'a jest modny ale trzeba się z nim okonfigurować więc na start nie polecam. Może coś bardziej klasycznego czyli bezprzeplotowca KM'a (dostępny w oryginalnej wersji TASS'a)?
http://noname.c64.org/csdb/release/?id=3955

Prosty, bezproblemowy i całkiem szybki.

[zielok]

Ja zgodzę się z Kmeg'iem. Loader KM jest całkiem szybki, mało zajmuje i jest prosty w obsłudze.

Loader Krill'a na start jest bardzo problematyczny. Ja początkowo nie mogłem go właśnie okonfigurowac tzn. wszystko poustawiałem jak trzeba ale przy kompilacji loader'a wywalał błąd. Próbowałem z Nitro dojść czemu nie działa i nic z tego nie wyszło. Napisałem więc do Krilla i tu także mieliśmy problemy. Po prostu mój komputer miał jakiś problem (Cygwin i cała reszta była ustawiona prawidłowo). W końcu udało się go skompilować i jest zauważalnie lepszy niż loader KM ale początek może zniechęcić.

Na start spróbuj loader KM a potem jak będziesz czuł potrzebę to polecam loader Krill'a.

[brush]

Ja zawsze używałem albo loadera KM'a albo taki stary loader o którym w warszawie mówiono "Loader Radwar'u" (w origonie użyłem).

Pytanie do wszystkich użytkowników Krill'i, Dekadency, HCL'i itp.

Jaka one daja wartość dodaną ponad to co ma loader KM'a?

[kotrobot]

This is the current development version, considered to be stable for some years now. It comes with no strings attached.

This loader features, among other things:
- asynchronous 2-bit+ATN transfer protocol, allows for arbitrary interruptions (IRQs, sprites, badlines), in this version with only 1 drive on the bus
- support for 1541, 1541-C, 1541-II, 1570, 1571, 1581
- works with exotic drives implementing the necessary KERNAL I/O calls, e.g. IDE64, MMC64, netload, VICE without true drive emulation
- PAL/NTSC compatible
- loads uncompressed files
- loads compressed files, supports Exomizer, Pucrunch, ByteBoozer, Taboo LevelCrush
- nominal loading speed is 3.5 kB/s for uncompressed files and 6 kB/s for compressed files (1541)
- in-memory decompression of files
- loads via directory (2-16 filename characters), track/sector, or directory index
- loads to $D000-$DFFF
- easy and glitchless VIC bank switching while loading
- any values written to $DD00 allowed when loader is idle
- optional polled loading and non-blocking loading using CIA timer NMIs
- progress indication interface
- customizable in functionality and size, needs <$0100 bytes for basic loading uncompressed functionality after installation

Some planned features for future versions:
- real documentation
- web-based build service
- more than 1 drive on the bus using the 2-bit+ATN transfer protocol
- other transfer protocols
- IFFL loading
- custom drive-code API for uploading own routines to the drive CPU
- streaming
- saving functionality using the custom drive-code API
- CMD FD/HD support
- dynamic linkage for easy loader swapping and updating with existing binary releases
- support for D64-compatible fast file formats
- +4 target

[brush]

Maaaan...

DODANA wartość Z całej listy na oko widze tylko to:

- any values written to $DD00 allowed when loader is idle
- optional polled loading and non-blocking loading using CIA timer NMIs

Co mógłbym określić jako plus.

Pytanie więc czy to wszystko czy też się nie znam?

[kotrobot]

Nie znam się.

[brush]

OK.

Nawet mi się nie kompiluje po poustaiwaniu opcji. Loader KM'a jakoś tak po prostu działał


make -C src
ca65 -t c64 -D PLATFORM=64 -I ../../shared -I ../include -o ../build/intermediate/zp-resident.o resident/zp-resident.s
resident/zp-resident.s(239): Error: Constant expression expected
resident/zp-resident.s(239): Error: Constant expression expected
make[1]: *** [../build/intermediate/zp-resident.o] Error 1
make: *** [loader] Error 2

[Sebaloz/Lepsi.De]

Podobno nowe demo Arise bedzie uzywac loadera Wegiego.

[wackee]

Pfhaahahahaha...
Sebaloz, masz równie kiepskie plotkarskie źródła jak pamięć wewnętrzną (ang. internal flashka memory) z której streamujesz raporty.

[Sebaloz/Lepsi.De]

No to Wegi ogarnal juz loader Krilla

[wackee]

Seba, strzelasz celnie jak pijany kowboj po zjeździe z Brokeback Mountain.

[Nitro]

brush: loader Krilla obsługuje jak dla mnie przede wszystkim skompresowane dane - drive w czasie, kiedy czeka na obrót dyskietki na żądane miejsce nie stoi bezczynnie, tylko depakuje dane, rezultaty przynajmniej w przypadku mojego dema były doskonałe.
Ale mileage may vary, mamy z Wegim argument co do użyteczności tej techniki
Dalej Krill na tegorocznym Revision wspominał, że kończy system ring bufferowania danych.

[zielok]

Powody dlaczego uzyłem loadera Krilla:
- loader Krilla na poczatku wczytuje katalog i można ładować po nazwach a nie trzeba po trackach aby nie było skoku do tracka 18.
- Loader Krilla szybciej ładuje dane z dekompresja w czasie ładowania od loadera KM (przy uzyciu w obu przypadkach crunchera od MMS)

Z rzeczy które nie były mi chyba potrzebne to można wyświetlać sprity i ladować (nie trzeba ich wyłaczac gdy jest transmisja)

[brush]

Nitro, Zielok - przekonaloscie mnie.
To moze juz w mailu w gronie Esm sobie wyjasnimy jak drania skompilowac

[wegi]

brush: loader Krilla obsługuje jak dla mnie przede wszystkim skompresowane dane - drive w czasie, kiedy czeka na obrót dyskietki na żądane miejsce nie stoi bezczynnie, tylko depakuje dane, rezultaty przynajmniej w przypadku mojego dema były doskonałe.
Ale mileage may vary, mamy z Wegim argument co do użyteczności tej techniki
Dalej Krill na tegorocznym Revision wspominał, że kończy system ring bufferowania danych.

ech nitras nitras to wykminię Ci to na przykładach:

mówimy o pełnym obciążeniu obu procków jednocześnie więc wyobraźmy sobie sytuację, która nie jest rzadkością podczas dekompresji a więc decruncher otrzymał informację która mówi:

najpierw wyobraźmy sobie, że do ramu zaczytaliśmy blok maksymalnie 254 bajtów i w tym bloku dajmy na to jest info dla decrunchera - od tego miejsca skopiuj 350 bajtów (nie decrunchuj tylko SKOPIUJ!) - cóż się dzieje?
decruncher zaczyna kopiować i robi to tak błyskawicznie, że w stacji dyskietka nie odkręciła się więcej niż 360/21 stopni czyli raptem o 1 sektor. dla zobrazowania załóżmy że odczytywany jest sektor 0 to w tym momencie głowica jest w okolicach 9tego (tyle zajęło dekodowanie i transmisja) lub dalej w zależności od loadera i czasu rastra pozostawionego dla niego. Co dalej? Ano decruncher dotarł na koniec danych zaczytanego bloku i czeka na refill buffer - i poczeka około 0.2 sec aż przyjedzie Twój sektor #8 - najczęstszy przeplot A Ty będziesz żył w błogiej nieświadomości jak to sobie decrunchujesz w locie - w locie ale "z czkawką".

Drugi piękny przykład - decruncher doynaxa wyrabia się przy przeplocie #$0a - co z tego jak masz nagrane z 8 mulaście sobie "in a fly" decrunchujesz.

Trzeci przykład - plik który się kiepsko popakował np. poditherowana grafika - wówczas masz dla decrunchera niemal same rozkazy kopiowania lub nawet od razu po 1000 i więcej bajtów w sumie lecisz na czkawce przez cały plik.


Powyższe przykłady tracą zdolność w sytuacji, gdy dla loadera jest pozostawione mało czasu rastra - wówczas można powiedzieć, że decrunch jest optymalny - wiadomo, że i tak potrwa DŁUGO jak się na to dało mało czasu rastra.

W przypadku loadera omijającego przeplot - masz stratę około 0.01 sec/sector - tyle da uśredniony scanning i rozkład sił na dwa procki - po zaczytaniu tym sposobem możesz decrunchować w ramie bez "czkawki" - przykłąd - error 23, DT, ILTC - w sumie wyjdzie prawie na to samo - ciut szybciej dało nointerleave.
Co do ILTC można sporo zarzucić do linkingu ale w DT jest super...
@zielok
"- loader Krilla na poczatku wczytuje katalog i można ładować po nazwach a nie trzeba po trackach aby nie było skoku do tracka 18. "

Rozumiem, że chodziło iż po zaczytaniu jednorazowo katalogu można sobie stworzyć tabelkę ze start track i sector i ładować po trackach

[wegi]

@Nitro - nakreśl mi może na czym miałoby to ringbufferowanie polegać