Właśnie mi uświadomiłeś że nie pamiętam czy ja w ogóle sprawdzam przepełnienie bufora, sprawdzę bo naprawdę nie pamiętam :D

EDIT: tak dla uścislenia, bufor programu wyświetlany po starcie, np. MEM: $E800 oznacza maksymalny rozmiar bloku jaki na raz można wczytać do pamięci. Anty *AJEK wczytuje do tego bufora do momentu aż nie wystąpi następny blok poprzedzony tonem "synchronizującym". Gdy tylko taki blok się uda wczytać, program zatrzymuje silnik/odczyt z taśmy i nagrywa zawartość bufora na dysk, po czym wznawia odczyt i tak do końca pliku.

EDIT2: zajrzałem do źródeł, obliczam co prawda długość bloku do wczytania, ale zupełnie ignoruję fakt że dane mogą się w buforze nie zmieścić, efekt przy przepełnieniu bufora będzie taki że gdy ostatni bajt bufora zostanie zapełniony ($FFFF <--- koniec RAM po OS-ROM), to program zacznie mazać od początku pamięci (od adresu $0000) i nastąpi spektakularna klapa i zamazanie istotnych zmiennych na stronie zerowej, jeżeli to jakimś cudem nie spowoduje "zwiechy", to następnym obszarem do zamazania będzie stos ($0100-$01FF) a zamazanie tego obszaru już na pewno doprowadzi do katastrofy i nieuchronnej zwiechy systemu.

Prawdę mówiąc nawet nie mam pomysłu jak sprawdzać dodatkowe warunki, format Speedy2700 daje niewie czasu na operacje ponieważ strumień bitów leci bezustannie i dodawanie nowych instrukcji w trakcie odczytu strumienia (np. sprawdzanie końca bufora) zmienia zależności czasowe pętli odczytującej dane... i może być tak że to co będzie się wczytywało ze standardowym loader-em Speedy2700 nie będzie chciało się czytać w Anty *AJEK. Pomyślę jak to rozwiązać, może coś mi wpadnie do głowy.

Tak naprawdę należałoby wiedzieć jakim buforem dysponował "*AJEK COPY", jest szansa że "Anty *AJEK" uruchomiony bez DOS, z buforem na poziomie $E800 ma większy bufor na dane niż ten którym dysponował "*AJEK COPY".

Seban - myślę, że rozwiązanie z obsługą H pod Altirą rozwiązuje już problem bufora. Uruchamiając Twoją wersję antyajek copy pod Dosem, przy około 30 zestawach turbo 2000, problem miałem dosłownie z 4 plikami. Dotyczyło to gier, które swoją objętością osiągały rozmiar około 55-56KB. Nie porównywałem bufora pod różnymi dos'ami, po prostu ze względu na fakt, że cały czas używam Toms'a 720, najczęściej sięgam po Mydos'a i DOS'a II+D. A mamy przecież dzisiaj jeszcze lekkie rozwiązanie jakim jest Light Dos.

Każdy z tych 4 problematycznych plików, bez problemu udało się wyłuskać pod Altirą i obsługą H: z mapowaniem na D1.
Także skuteczność programu na ten moment wynosi 100%. Bo nawet te 4 pliki przy innym sposobie uruchomienia programu udało się wyłuskać.

Hej!

Tak na szybko i nieco w biegu... udało się wprowadzić poprawki i dodać dodatkowe opcje:

- optymalizacja pętli czytającej bloki danych, udało się zaoszczędzić trochę cykli! dzięki temu...
- sprawdzane jest przepełnienie bufora (próba wczytania za długiego pliku skończy się błędem $9E (158 dec) - "OUT OF MEMORY"
- dodane sterowanie silnikiem
- w release jest już ATR zawierający BW-DOS w wersji 1.30 wraz z Anty *AJEK.
- poprawiono drobny błąd przy zaokrąglaniu MEMLO do granicy strony.
- drobna poprawka w procedurze wyboru interface z którego program będzie czytał dane

do pobrania tutaj: "Anty *AJEK Copy v.1.5"

bufor dostępny z poziomu BW-DOS wynosi: 53504 bajtów ($D100)
bufor dostępny bez ładowania DOS wynosi: 59658 bajtów ($E900)

ale jak pisałem wcześniej, wielkość bufora oznaczy tylko i wyłącznie ograniczenie maks. wielkości pojedynczego bloku, tzn. jeżeli program będzie się składał z 10 bloków po 50 kB, to nie będzie dla programu problemem, on przetwarza dane sekwencyjnie. Czyta wszystko do momentu wystąpienia kolejnego tonu synchronizującego.