loadery

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
joodas
Posty: 321
Rejestracja: 05 wrz 2009, 11:42
Grupa: Albion Crew

loadery

#1 Post autor: joodas »

Witam wszystkich

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

Pozdro
Joodas

kotrobot
Posty: 2362
Rejestracja: 06 lis 2008, 13:55
Grupa: URDAD

#2 Post autor: kotrobot »

Teraz chyba wszyscy używają loadera Krilla:

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

Ale nie wiem, czy prosty.
Olo forum atakuje. Żadnej litości nie czuje.

DJ Gruby

#3 Post autor: 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
Posty: 321
Rejestracja: 05 wrz 2009, 11:42
Grupa: Albion Crew

#4 Post autor: joodas »

Badal ktos loadera Dekadence?

Awatar użytkownika
kmeg
Posty: 468
Rejestracja: 08 wrz 2009, 15:33
Grupa: Albion Crew

#5 Post autor: 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
Posty: 438
Rejestracja: 07 lis 2008, 21:23
Kontakt:

#6 Post autor: 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
Posty: 254
Rejestracja: 20 kwie 2009, 10:32
Grupa: Elysium

#7 Post autor: 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?
Elysium vs Arise. Czym byłoby dobro bez zła?

kotrobot
Posty: 2362
Rejestracja: 06 lis 2008, 13:55
Grupa: URDAD

#8 Post autor: 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
Olo forum atakuje. Żadnej litości nie czuje.

brush
Posty: 254
Rejestracja: 20 kwie 2009, 10:32
Grupa: Elysium

#9 Post autor: 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?
Elysium vs Arise. Czym byłoby dobro bez zła?

kotrobot
Posty: 2362
Rejestracja: 06 lis 2008, 13:55
Grupa: URDAD

#10 Post autor: kotrobot »

Nie znam się. ;)
Olo forum atakuje. Żadnej litości nie czuje.

brush
Posty: 254
Rejestracja: 20 kwie 2009, 10:32
Grupa: Elysium

#11 Post autor: 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
Elysium vs Arise. Czym byłoby dobro bez zła?

Awatar użytkownika
Sebaloz/Lepsi.De
Posty: 3949
Rejestracja: 14 wrz 2008, 00:02

#12 Post autor: Sebaloz/Lepsi.De »

Podobno nowe demo Arise bedzie uzywac loadera Wegiego.
__________________________
Socjopatyczna Legia Commodore

Awatar użytkownika
wackee
Posty: 1606
Rejestracja: 05 paź 2008, 23:05
Grupa: Arise
Kontakt:

#13 Post autor: wackee »

Pfhaahahahaha...
Sebaloz, masz równie kiepskie plotkarskie źródła jak pamięć wewnętrzną (ang. internal flashka memory) z której streamujesz raporty.
Arise - keeping your eyes wide open since 1991.

Awatar użytkownika
Sebaloz/Lepsi.De
Posty: 3949
Rejestracja: 14 wrz 2008, 00:02

#14 Post autor: Sebaloz/Lepsi.De »

No to Wegi ogarnal juz loader Krilla :)
__________________________
Socjopatyczna Legia Commodore

Awatar użytkownika
wackee
Posty: 1606
Rejestracja: 05 paź 2008, 23:05
Grupa: Arise
Kontakt:

#15 Post autor: wackee »

Seba, strzelasz celnie jak pijany kowboj po zjeździe z Brokeback Mountain.
Arise - keeping your eyes wide open since 1991.

Awatar użytkownika
Nitro
Posty: 1544
Rejestracja: 03 wrz 2008, 20:23
Grupa: Black Sun

#16 Post autor: 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
Posty: 438
Rejestracja: 07 lis 2008, 21:23
Kontakt:

#17 Post autor: 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
Posty: 254
Rejestracja: 20 kwie 2009, 10:32
Grupa: Elysium

#18 Post autor: brush »

Nitro, Zielok - przekonaloscie mnie.
To moze juz w mailu w gronie Esm sobie wyjasnimy jak drania skompilowac :)
Elysium vs Arise. Czym byłoby dobro bez zła?

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#19 Post autor: wegi »

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

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#20 Post autor: wegi »

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

ODPOWIEDZ