Loader krill'a obsługuje ładowanie awaryjne za pomocą procedur KERNAL'a, ale korzystanie z tej funkcjonalności jest mocno kłopotliwe, podczas ładowania trzeba włączyć KERNAL oraz obszar carta, dbać o wektory i zmagać się z procedurami ładującami z różnych cartów, większość z nich będzie się wywalała jeśli na ekranie będą sprite'y więc kompatybilność bonusowo uderza w design.
Ja podziękuję, każdy scenowiec ma stację 15xx lub 1541-Ultimate.
Loadery do stacji IEC-only
sam widzisz , że używasz gotowych rozwiązań (loader Krill-a) zresztą nie jesteś sam. Gdyby Kirll, napisał szybszą procedurę standardową (tą która jest właśnie w kernalu - to i dema chodzące na innych drivach by były częstsze - ale niestety, Krill to tylko jeden człowiek.
Szczerze mówiąc specyfika innych kartów/drive-ów, nie ma tu znaczenia. Mówimy o transmisji kernalowskiej która jest właśnie taka jak jest, ale w założeniu współpracuje ze WSZYSTKIMI urządzeniami przeznaczonymi do c64. Zresztą każde urządzenie zewnętrzne które nie ma zaimplentowanej komunikacji w sposób "kernalowski", zwyczajnie nie jest urządzeniem do c64 (czyt. do dupy z takim urządzeniem) - standardowy protokół jest po to aby był jasny dla wszystkich. Truboloadery to dopiero dodatki opierające się o konkretną specyfikę urządzenia.
I teraz... "wystarczy" skupić się na oprogramowaniu części kernalowskiej (a nie urządzenia) i wszystko będzie zawsze chodzić.
Oczywiście sprawa nie jest łatwa, bo tam są odpowiednio duże opóźnienia w oczekawniu na sygnał drugiego urządzenia (często nie potrzebnie), ale łatwo "przegapić" - stąd SEI oraz przeszkadzają sprites by nie zabierały cyklów(głównie w połączniu z badline).
Teraz druga sprawa - pochwalę - jak zakupiłem sd2iec, od razu rzuciła mi sie prostota przenoszenia danych (karta sd), a nie te kombinacje z kablami, programami do trasmisji przy okazji walki z systemem - i to często skazanymi na porażkę. Pomyślałem że szkoda byłoby marnować takiego urządzenia. Chciałem żeby moje programy umiały doczytywać i bezpośrednio z tego urządzenia.
Oczywiście w pierwszej chwili napotkałem na problemy który wypisałeś, ale udało mi się napisać taki mały "substytut" kernela, który nie dość że zajmuje niecałe $100 bytes, to jest szybszy i pozwala na wyświetlanie kilku sprites - a co najważniejsze współpracuje również z innymi urządzeniami (a nie tylko z sd2iec) - można...
Działa to na zasadzie nasłuchu, a
Szczerze mówiąc specyfika innych kartów/drive-ów, nie ma tu znaczenia. Mówimy o transmisji kernalowskiej która jest właśnie taka jak jest, ale w założeniu współpracuje ze WSZYSTKIMI urządzeniami przeznaczonymi do c64. Zresztą każde urządzenie zewnętrzne które nie ma zaimplentowanej komunikacji w sposób "kernalowski", zwyczajnie nie jest urządzeniem do c64 (czyt. do dupy z takim urządzeniem) - standardowy protokół jest po to aby był jasny dla wszystkich. Truboloadery to dopiero dodatki opierające się o konkretną specyfikę urządzenia.
I teraz... "wystarczy" skupić się na oprogramowaniu części kernalowskiej (a nie urządzenia) i wszystko będzie zawsze chodzić.
Oczywiście sprawa nie jest łatwa, bo tam są odpowiednio duże opóźnienia w oczekawniu na sygnał drugiego urządzenia (często nie potrzebnie), ale łatwo "przegapić" - stąd SEI oraz przeszkadzają sprites by nie zabierały cyklów(głównie w połączniu z badline).
Teraz druga sprawa - pochwalę - jak zakupiłem sd2iec, od razu rzuciła mi sie prostota przenoszenia danych (karta sd), a nie te kombinacje z kablami, programami do trasmisji przy okazji walki z systemem - i to często skazanymi na porażkę. Pomyślałem że szkoda byłoby marnować takiego urządzenia. Chciałem żeby moje programy umiały doczytywać i bezpośrednio z tego urządzenia.
Oczywiście w pierwszej chwili napotkałem na problemy który wypisałeś, ale udało mi się napisać taki mały "substytut" kernela, który nie dość że zajmuje niecałe $100 bytes, to jest szybszy i pozwala na wyświetlanie kilku sprites - a co najważniejsze współpracuje również z innymi urządzeniami (a nie tylko z sd2iec) - można...
Działa to na zasadzie nasłuchu, a
Bo pecet to zwykły banan...
Hehe, w sumie racja, człowiek się wymadrza, a nie popiera dokumentami - no cóź, programy są zwyczajnie "nieskończone".kisiel pisze:Skull skąd wziąść Twoje programy? Dla mnie nie jest problem bad lines.
ale z racji tego, że coraz ciężej mi przysiąść do c64, możliwe że nie skończe, i robię to czego chciałem uniknąć, dam przykład nieskończonego:
tylko mała uwaga - to nie jest żaden release, muzyka w menu jest -ale nie będzie użyta w wersji finalnej (brak zgody autora/ zresztą mam już inną "nawet" lepszą ale jeszcze nie podmieniłem).
Ze szczeg. technicznych - loader - jak nie wykryje 1541 - to jedzie tym co opisałem powyżej.
- Załączniki
-
- game.rar
- (66.18 KiB) Pobrany 459 razy
Bo pecet to zwykły banan...
Hmm, około 10 sekund na jedną ścieżkę na realnej stacji i IEC device'ach, zdecydowanie nie ma mowy, żeby go użyć w dynamicznym demie.
Loader krill'a czyta jeden track w ok. 2 sekundy, do tego mamy gratisowo depak plików spakowanych Level Crusherem, który dosłownie czyni cuda jeśli chodzi o transfer.
Gra za to zapowiada się więcej niż świetnie
Loader krill'a czyta jeden track w ok. 2 sekundy, do tego mamy gratisowo depak plików spakowanych Level Crusherem, który dosłownie czyni cuda jeśli chodzi o transfer.
Gra za to zapowiada się więcej niż świetnie
Napisz demo, to pogadamy 
O to chodzi, aby widz nie musiał wciskać warpa w emu(nie mówiąc o realnym sprzęcie) ani podziwiać obrazków czy wlokących się przejść przez wieki. Oraz aby kolejny efekt nie był popychadłem z ładowaniem w tle, tylko trzymał opadniętą szczękę widza na podłodze
Przykładem świetnego dema, które jest zarzynane właśnie przez wolny loader jest Snapshot, kod partów jest na bardzo wysokim poziomie, ale przerwy pomiędzy nimi są długie oraz nudne.
O to chodzi, aby widz nie musiał wciskać warpa w emu(nie mówiąc o realnym sprzęcie) ani podziwiać obrazków czy wlokących się przejść przez wieki. Oraz aby kolejny efekt nie był popychadłem z ładowaniem w tle, tylko trzymał opadniętą szczękę widza na podłodze
Przykładem świetnego dema, które jest zarzynane właśnie przez wolny loader jest Snapshot, kod partów jest na bardzo wysokim poziomie, ale przerwy pomiędzy nimi są długie oraz nudne.
Niee, im wolniejszy loader, tym się bardziej ładowanie wlecze, jego jedyną ewentualną zaletą może być rozmiar, tu fajny przykład takiego malucha:
http://www.pagetable.com/?p=568
Czas rastra jest do dowolnej regulacji, przecież to istota IRQ loaderów, w IRQ wykonujemy nasz kod przez dowolny okres czasu, po skończeniu IRQ loader zaczyna ładować aż do przerwania przez kolejne IRQ lub załadowania całego pliku.
Im mniej efekt zajmuje, tym gorzej chodzi, speedcode szczególnie bardziej zaawansowany zjada mnóstwo miejsca.
http://www.pagetable.com/?p=568
Czas rastra jest do dowolnej regulacji, przecież to istota IRQ loaderów, w IRQ wykonujemy nasz kod przez dowolny okres czasu, po skończeniu IRQ loader zaczyna ładować aż do przerwania przez kolejne IRQ lub załadowania całego pliku.
Im mniej efekt zajmuje, tym gorzej chodzi, speedcode szczególnie bardziej zaawansowany zjada mnóstwo miejsca.
... podałem tylko przykład żeby pokazać że można.. - to jak widać nie jest demo
Może zdzwi Cie fakt, że czas loadingu (w przykładzie) wcale nie byłby krótszy jakbym miał zastosować np. krilla - po prostu chciałem żeby to akurat tyle trwało (nawet program ma specjalne opóźnienia bo wczytywanie niekiedy za krótko trwa ! ).
W demach jest po prostu różnie...
Może zdzwi Cie fakt, że czas loadingu (w przykładzie) wcale nie byłby krótszy jakbym miał zastosować np. krilla - po prostu chciałem żeby to akurat tyle trwało (nawet program ma specjalne opóźnienia bo wczytywanie niekiedy za krótko trwa ! ).
W demach jest po prostu różnie...
Bo pecet to zwykły banan...
-
k.
Mówię, dema a gry to dwa różne światy, w grach szybkość wczytywania nie jest priorytetem, nawet dla efektu je spowalniasz, choć imho to wczytywanie trwa za długo.
We współczesnych demach sytuacja zmienia się o 180 stopni, publiczność po EOD, Desert Dream i innych współczesnych demach nie będzie zadowolona z długich loadingów wraz z marnymi efektami podczas nich.
We współczesnych demach sytuacja zmienia się o 180 stopni, publiczność po EOD, Desert Dream i innych współczesnych demach nie będzie zadowolona z długich loadingów wraz z marnymi efektami podczas nich.
-
k.
Polecam wejście na IRC'a, poproszenie krill'a o aktualny loader, i zabawę ładowaniem skompresowanych plików jak masz wątpliwości co do szybkości. Jakbyś chciał go użyć, to kompatybilność z SD2IEC i innymi fake'ami jak już mówiłem dostaniesz o ile zasady podane wcześniej.
Co do ładowany speedcode vs. generowany, to jeśli nie mówimy o eor fillerze czy tam jeszcze czymś prostym to ładowanie będzie szybsze, nie mówiąc o pominięciu bólu pisania takiego generatora, przykładem jest demo Exotic Excitement camelotu, przerwy między plasmami są na generowanie skomplikowanego speedcode'u i zajmują koło 15 sekund.
P.S. Nie bijcie za offtop, wydzielę wątek jak wrócę.
Co do ładowany speedcode vs. generowany, to jeśli nie mówimy o eor fillerze czy tam jeszcze czymś prostym to ładowanie będzie szybsze, nie mówiąc o pominięciu bólu pisania takiego generatora, przykładem jest demo Exotic Excitement camelotu, przerwy między plasmami są na generowanie skomplikowanego speedcode'u i zajmują koło 15 sekund.
P.S. Nie bijcie za offtop, wydzielę wątek jak wrócę.
Pliki i tak się kompresuje, by mniej zajmowały na dysku - jeżeli twierdzisz, że depacker (choćby "znakowiec", który przy dapaku ma jednak klika różnych warunków "tworzenia" danych) + do tego loader (jak dwubitowy to oczywiście ściśle wycyklowany z przerwaniami rastra), "wstawią" dane szybciej niż JEDNA pętla powtarzająca wpisywane dane (działająca w tle) to coś tu jest nie tak - wynikałoby, że wg. twojego toku rozumowania - np. szkoda czyścić ekran skoro loader Krill-a zrobi to szybciej
Ale powtórze jeszcze raz - ja podałem tylko przykład, właściwie namiastkę (przy tworzeniu tego "substytutu" głównie chodziło mi o to aby nie korzystać kernala w romie), jak widać po JiffyDos-ie potencjał jest. Oczywiście w demach trzeba być bardziej "elastycznym", ale i loader Krill'a przecież nie zasuwa z pełną prędkością w takich produkcjach.
No niech tam te SD2IEC -to sprzęt współczesny/"nie retro", ale szkoda takich stacji jak 1581 i innych drive-ów powstałych w czasach 1541. Loadery uniwersalne to także furtka dla nowych urządzeń.
Ale powtórze jeszcze raz - ja podałem tylko przykład, właściwie namiastkę (przy tworzeniu tego "substytutu" głównie chodziło mi o to aby nie korzystać kernala w romie), jak widać po JiffyDos-ie potencjał jest. Oczywiście w demach trzeba być bardziej "elastycznym", ale i loader Krill'a przecież nie zasuwa z pełną prędkością w takich produkcjach.
No niech tam te SD2IEC -to sprzęt współczesny/"nie retro", ale szkoda takich stacji jak 1581 i innych drive-ów powstałych w czasach 1541. Loadery uniwersalne to także furtka dla nowych urządzeń.
Bo pecet to zwykły banan...
To ja się wtrącę na chwilę. Moja wiedza o stacji i loaderach jest zerowa nie wiem jak je napisać ale mam pojęcie jak one działają i proszę przeczytać całość tekstu.
Uproszczenie, które może pozwoli zrozumieć mechanizm od czego zależy "szybkość" loadera.
Najpierw o loaderach które czytają pliki z przeplotem z jakim zostały zapisane na dyskietce. Czyli loader szuka kolejnych sektorów pliku.
Zakładam, że po stronie c-64 cały rastertime jest przeznaczony dla loadera. Przy transmisji dwubitowej przesłanie 256 bajtów powinno mieścić się w ramkę.
Prędkość działania loadera po stronie stacji, to szybkość działania kodu odczytu sektora w GCR i konwersji danych GCR->C-64 i przesłanie danych do C-64.
Najważniejszy jednak jest ten czas upływający po wczytaniu sektora do pamięci stacji dysków !!!.
Dyskietka cały czas się obraca, a czas upływa i tu pojawia się sedno.
Ten czas można sobie przeliczyć na to ile sektorów ucieknie pod głowicą, która nie odczytuje danych !!!. No i dla mnie przy tych założeniach jest
to logiczne, że szybszy jest loader któremu uciekną 4 sektory od tego
któremu ucieknie 8 czy 10 sektorów !.
Jeżeli zapiszę plik na dyskietce z przeplotem 4 i loader wyrabia się z prędkością przeplotu 4 to plik zostanie wczytany 2xszybciej niż dla loadera wyrabiającego się z przeplotem 8 dla pliku zapisanego z przeplotem 8.
Teraz, żeby nie było tak cacy to wiadomo, że po stronie C-64 nie mamy wolnego całego rastertime'u. Wpłynie to na prędkość transmisji danych ze stacji do C-64 a co za tym idzie pod głowicą będzie uciekać większa ilość sektorów !!! Także super-szybki loader nie będzie już taki szybki jak nam się wydaje jeżeli pliki na dysku nie zostaną zapisane z odpowiednim przeplotem !!!. Może być tak, że dla loader'a który wyrabia się z wczytywaniem z przeplotem 4 należy pliki zapisywać z przeplotem 6, 8, 10 itp. trzeba dobrać przeplot pliuk ręcznie żeby otrzymać 100% efektywność działania loadera.
Łopatologicznie, jak zapisze plik z przeplotem 4 i mam obciążony rastertime i głowicy ucieknie 6 sektorów to loader i tak się posra bo będzie czekał jeden obrót na to żeby złapać sektor danych.
I tu Skull coś dla Ciebie czego ja dłuuuuuugo nie rozumiałem.
Loader jest szybki, plik jest zapisany z takim przeplotem, że loader zapierdala i nie traci czasu na pełne obroty, ale mimo to stacja czeka! na kolejny sektor danych.
I tu ktoś wpadł na pomysł, żeby w to oczekiwanie po stronie C-64
wrzucić dekranczowanie danych !!! Tu trzeba też pamiętać że dane
w c-64 są umieszczane liniowo bajt za bajtem i dlatego możliwy jest dekrancz.
Nawet niech wszystkie pliki zostaną zapisane z przeplotem 4 dla loadera 4 to jeżeli w trakcie wczytywania loader traci ten jeden obrót 0,2 s to jest to 10 ramek dla c-64 do dekranczowania (dokładniej 10 obciążonych ramek).
Dekranczowane są wczytane dane w C-64, jak stacja złapie sektor to wczytuje dane/konwertuje, C-64 nadal może dekranczować dane.
Stacja daje sygnał, że ma przesłać dane, C-64 przerywa dekrancz i odbiera dane ze stacji. To już nie jest taka prosta pętla odbiór danych.
Trzeba sobie uświadomić, że taka prosta pętla co tylko odbiera dane
ze stacji jest bezczynna jeżeli stacja czeka na synchronizację/złapanie
sektora z danymi który jej uciekł pod głowicą.
Inną sprawą jest loader, który potrafi wczytywać pliki bez względu na przeplot z jakim zostały zapisane. Tu potrzebny jest szybki sam w sobie loader, ale potrzebny jest skaner sektorów należących do pliku.
W wypadku gdy rastertime jest obciążony i dla loadera o prędkości wczytywania 4 pod głowicą ucieknie 6 sektorów, to loader sprawdza
czy ten sektor pod głowicą należy do wczytywanego pliku. Skoro
należy do pliku to stacja go wczytuje i musi obliczyć przesłać blok danych pod określony adres w pamięci w C-64.
Także w takim wypadku w C-64 dane nie są umieszczane liniowo tylko blokami i w przestrzeni pamięci gdzie ma być wczytany plik są dziury.
Tutaj nie wiem czy jest jakiś loader który od razu potrafi takie dane
dekranczować.
Taki loader jest "najlepszym" rozwiązaniem, można go jeszcze oszukiwać
i zapisywać pliki tak aby na jednej ścieżce były zapisane dane tylko jednego pliku.
Jeżeli wczytujemy plik zkranczowane to po wczytaniu trzeba je jeszcze zdekranczować.
Dlatego wychodzi na to, że loader z dekranczerem może być najszybszy.
Tylko trzeba wiedzieć z czego się korzysta i jak przygotować dane.
Tylko, że są efekty które mają zmienne użycie rastertimeu, przydałby się
file kopier który potrafiłby nagrywać pliki z przeplotem zmiennym w czasie. np.
1 sektor danych
2 sektor danych, +4 w stosunku do 1
3 sektor danych, +6 w stosunku do 2
itp.
Jeżeli opisałem oczywiste rzeczy i każdy to wie i rozumie to sorry.
Uproszczenie, które może pozwoli zrozumieć mechanizm od czego zależy "szybkość" loadera.
Najpierw o loaderach które czytają pliki z przeplotem z jakim zostały zapisane na dyskietce. Czyli loader szuka kolejnych sektorów pliku.
Zakładam, że po stronie c-64 cały rastertime jest przeznaczony dla loadera. Przy transmisji dwubitowej przesłanie 256 bajtów powinno mieścić się w ramkę.
Prędkość działania loadera po stronie stacji, to szybkość działania kodu odczytu sektora w GCR i konwersji danych GCR->C-64 i przesłanie danych do C-64.
Najważniejszy jednak jest ten czas upływający po wczytaniu sektora do pamięci stacji dysków !!!.
Dyskietka cały czas się obraca, a czas upływa i tu pojawia się sedno.
Ten czas można sobie przeliczyć na to ile sektorów ucieknie pod głowicą, która nie odczytuje danych !!!. No i dla mnie przy tych założeniach jest
to logiczne, że szybszy jest loader któremu uciekną 4 sektory od tego
któremu ucieknie 8 czy 10 sektorów !.
Jeżeli zapiszę plik na dyskietce z przeplotem 4 i loader wyrabia się z prędkością przeplotu 4 to plik zostanie wczytany 2xszybciej niż dla loadera wyrabiającego się z przeplotem 8 dla pliku zapisanego z przeplotem 8.
Teraz, żeby nie było tak cacy to wiadomo, że po stronie C-64 nie mamy wolnego całego rastertime'u. Wpłynie to na prędkość transmisji danych ze stacji do C-64 a co za tym idzie pod głowicą będzie uciekać większa ilość sektorów !!! Także super-szybki loader nie będzie już taki szybki jak nam się wydaje jeżeli pliki na dysku nie zostaną zapisane z odpowiednim przeplotem !!!. Może być tak, że dla loader'a który wyrabia się z wczytywaniem z przeplotem 4 należy pliki zapisywać z przeplotem 6, 8, 10 itp. trzeba dobrać przeplot pliuk ręcznie żeby otrzymać 100% efektywność działania loadera.
Łopatologicznie, jak zapisze plik z przeplotem 4 i mam obciążony rastertime i głowicy ucieknie 6 sektorów to loader i tak się posra bo będzie czekał jeden obrót na to żeby złapać sektor danych.
I tu Skull coś dla Ciebie czego ja dłuuuuuugo nie rozumiałem.
Loader jest szybki, plik jest zapisany z takim przeplotem, że loader zapierdala i nie traci czasu na pełne obroty, ale mimo to stacja czeka! na kolejny sektor danych.
I tu ktoś wpadł na pomysł, żeby w to oczekiwanie po stronie C-64
wrzucić dekranczowanie danych !!! Tu trzeba też pamiętać że dane
w c-64 są umieszczane liniowo bajt za bajtem i dlatego możliwy jest dekrancz.
Nawet niech wszystkie pliki zostaną zapisane z przeplotem 4 dla loadera 4 to jeżeli w trakcie wczytywania loader traci ten jeden obrót 0,2 s to jest to 10 ramek dla c-64 do dekranczowania (dokładniej 10 obciążonych ramek).
Dekranczowane są wczytane dane w C-64, jak stacja złapie sektor to wczytuje dane/konwertuje, C-64 nadal może dekranczować dane.
Stacja daje sygnał, że ma przesłać dane, C-64 przerywa dekrancz i odbiera dane ze stacji. To już nie jest taka prosta pętla odbiór danych.
Trzeba sobie uświadomić, że taka prosta pętla co tylko odbiera dane
ze stacji jest bezczynna jeżeli stacja czeka na synchronizację/złapanie
sektora z danymi który jej uciekł pod głowicą.
Inną sprawą jest loader, który potrafi wczytywać pliki bez względu na przeplot z jakim zostały zapisane. Tu potrzebny jest szybki sam w sobie loader, ale potrzebny jest skaner sektorów należących do pliku.
W wypadku gdy rastertime jest obciążony i dla loadera o prędkości wczytywania 4 pod głowicą ucieknie 6 sektorów, to loader sprawdza
czy ten sektor pod głowicą należy do wczytywanego pliku. Skoro
należy do pliku to stacja go wczytuje i musi obliczyć przesłać blok danych pod określony adres w pamięci w C-64.
Także w takim wypadku w C-64 dane nie są umieszczane liniowo tylko blokami i w przestrzeni pamięci gdzie ma być wczytany plik są dziury.
Tutaj nie wiem czy jest jakiś loader który od razu potrafi takie dane
dekranczować.
Taki loader jest "najlepszym" rozwiązaniem, można go jeszcze oszukiwać
i zapisywać pliki tak aby na jednej ścieżce były zapisane dane tylko jednego pliku.
Jeżeli wczytujemy plik zkranczowane to po wczytaniu trzeba je jeszcze zdekranczować.
Dlatego wychodzi na to, że loader z dekranczerem może być najszybszy.
Tylko trzeba wiedzieć z czego się korzysta i jak przygotować dane.
Tylko, że są efekty które mają zmienne użycie rastertimeu, przydałby się
file kopier który potrafiłby nagrywać pliki z przeplotem zmiennym w czasie. np.
1 sektor danych
2 sektor danych, +4 w stosunku do 1
3 sektor danych, +6 w stosunku do 2
itp.
Jeżeli opisałem oczywiste rzeczy i każdy to wie i rozumie to sorry.
Zgadza się Fenek, ale nie chodzi tu tylko o idee działania najwydajniejszych turboloaderów (t.j. z decrunchem), zresztą gdyby był wegi to jeszcze dokładniej podałby możlwie przeploty i wariacje odczytów.
Oczywiście że najlepszy turboloader uniwersalny, nie będzie miał szans z szybkimi loaderami na 1541 (w końcu wtedy ulepszone "sterowniki" transmisji działają i po stronie c64 i po stronie c1541), pytanie tylko czy te superszybkie loadery sa az tak potrzebne w demach (co innego kopiery) - bo jeśli nie to warto skupić się na dobrymi loaderami tylko po stronie c64 - zysk jest jasny - kompatybilność.
Oczywiście że najlepszy turboloader uniwersalny, nie będzie miał szans z szybkimi loaderami na 1541 (w końcu wtedy ulepszone "sterowniki" transmisji działają i po stronie c64 i po stronie c1541), pytanie tylko czy te superszybkie loadery sa az tak potrzebne w demach (co innego kopiery) - bo jeśli nie to warto skupić się na dobrymi loaderami tylko po stronie c64 - zysk jest jasny - kompatybilność.
Bo pecet to zwykły banan...