c64scene.pl

Witam wszystkich

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

Pozdro
Joodas

Teraz chyba wszyscy używają loadera Krilla:

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

Ale nie wiem, czy prosty.

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

Badal ktos loadera Dekadence?

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.

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.

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?

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

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?

Nie znam się.

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

Podobno nowe demo Arise bedzie uzywac loadera Wegiego.

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

No to Wegi ogarnal juz loader Krilla

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

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.

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)

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

Nitro pisze: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

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