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.

Dla KSO jest program turdysk. Ale ma też swoje ograniczenia. Dużych gier właśnie powyżej 50KB nie złapie.
Wtedy zostaje kopier z buforem 128KB, jest taki jeden dla T2000, ale zapisuje tylko albo w turbo, albo w normalu... wiec ja bawię się wtedy pod emulatorem i takie pozycje przenosze najpierw turbo-normal, a dopiero potem normal-dysk.

Możecie mi podesłać link do tego "Hobby Tronica '90" w wersji WAV/FLAC, chciałem sprawdzić mój stary skrypt do bezpośredniej konwersji z formatu Turbo KSO/2000/F zapisanego w postaci .HEX (atari8cas-util.pl) do .XEX. Naklepałem go kiedyś w jakimś pośpiechu i jest wręcz prymitywny, ale jeżeli miałby pomóc w konwersji to go oczywiście udostępnię.

Kiedyś o tym chyba gdzieś wspominałem, ale popełniłem handler "T:" który instalował się jako rezydent pod DOS (używałem w tamtych czasach) MyDOS 4.53 który miałem wbudowany w stację Toms 720. Sprawdzało mi się to doskonale, bo standardowe (3kB bloki) w Turbo KSO/2000/F można kopiować porcjami, tzn. czytasz rekord i zapisujesz od razu to od razu do drugiego otwartego pliku (np. na dyskietkę). Muszę tego poszukać, sądzę że gdzieś to przetrwało (o ile już tego kiedyś gdzieś nie wrzuciłem, ale to mogło być dawno temu i już nie pamiętam gdzie i czy w ogóle).

Hej!

Dzięki za linka, przetestowałem na nim czy ten mój stary skrypt (python) jeszcze działa, bo nie pamiętałem stanu w jakim go zostawiłem. Okazało się że działa bez większego problemu. W załączniku wynik działania programu (w archiwum wygenerowany plik .XEX oraz .HEX który został poddany konwersji. Z kolei do stworzenia pliku .HEX wykorzystałem a8cas-util autorstwa FUJI-ego.  Zresztą po więcej szczegółów i chyba miarę sensowny opis użycia tego mojego prymitywu można podejrzeć na GitHub, o tutaj: T2K Tools.

Mam nadzieję że się przyda, ja korzystałem z tego własnie przy konwersji do XEX-ów taśm zapisanych w standardowym formacie Turbo KSO/2000F/2001. Narzędzie jest naprawdę prymitywne, bo nie sprawdza poprawności danych zawartych w pliku .HEX, po prostu zakład że dostarczony plik .HEX nie zawiera błędów (uszkodzonych rekordów, rekordów z błędnym CRC). Tworząc go założyłem że "a8cas-util" wykona swoją robotę poprawnie, czyli podczas przetwarzania nie będzie żadnych błędów:

./a8cas-util.pl conv -t turbo2000 hobby_tronic_90.wav hobby_tronic.hex
Starting ecasound... started.
SUMMARY: Data blocks: 28 (0 Errors).
86 HEX blocks stored in file hobby_tronic.hex.

potem można wywowałać extract_t2k.py:

./extract_t2k.py hobby_tronic.hex
nazwa pliku T2K: "HOBBY TRO."

Przetwarzam blok nr 001 o długości 3072 bajtów.
Przetwarzam blok nr 002 o długości 3072 bajtów.
Przetwarzam blok nr 003 o długości 3072 bajtów.
Przetwarzam blok nr 004 o długości 3072 bajtów.
Przetwarzam blok nr 005 o długości 3072 bajtów.
Przetwarzam blok nr 006 o długości 3072 bajtów.
Przetwarzam blok nr 007 o długości 3072 bajtów.
Przetwarzam blok nr 008 o długości 3072 bajtów.
Przetwarzam blok nr 009 o długości 3072 bajtów.
Przetwarzam blok nr 010 o długości 3072 bajtów.
Przetwarzam blok nr 011 o długości 3072 bajtów.
Przetwarzam blok nr 012 o długości 3072 bajtów.
Przetwarzam blok nr 013 o długości 3072 bajtów.
Przetwarzam blok nr 014 o długości 3072 bajtów.
Przetwarzam blok nr 015 o długości 3072 bajtów.
Przetwarzam blok nr 016 o długości 3072 bajtów.
Przetwarzam blok nr 017 o długości 3072 bajtów.
Przetwarzam blok nr 018 o długości 3072 bajtów.
Przetwarzam blok nr 019 o długości 3072 bajtów.
Przetwarzam blok nr 020 o długości 3072 bajtów.
Przetwarzam blok nr 021 o długości 3072 bajtów.
Przetwarzam blok nr 022 o długości 3072 bajtów.
Przetwarzam blok nr 023 o długości 3072 bajtów.
Przetwarzam blok nr 024 o długości 3072 bajtów.
Przetwarzam blok nr 025 o długości 3072 bajtów.
Przetwarzam blok nr 026 o długości 3072 bajtów.
Przetwarzam blok nr 027 o długości 0268 bajtów.

Operacja zakończona, plik 'hobby_tronic.xex' o długości 80140 bajtów zapisano.

Mam nadzieję ze to pomoże w wyłuskiwaniu plików z nagrać zapisanych w standardowym formacie Turbo KSO/2000F/2001. I nie będzie trzeba już walczyć z kopierami, etc. Oczywiście poszukam jeszcze tego handlera "T:", mam nadzieję że gdzieś jeszcze mam źródła to może wrzucę do repo na GitHub, a jak nie to chociaż spróbuję namierzyć samą binarkę.

Miałem jeszcze parę innych prostych bash-owych skryptów do automatyzacji konwersji całych taśm, ale nie mogę tego teraz namierzyć, to było sporo czasu temu i nie sądziłem że komukolwiek to może być potrzebne i przydatne. Jak znajdę bedę wrzucał na GitHUB.

tego hobby tronic to byłem pewien na 100%, bo oglądałem je kilkukrotnie :)

Hej!

Obiecywałem udostępnić ten handler dla Turbo 2000 (KSO/F/2001) który współpracuje z DOS-em instalując urządzenie "T:" w systemie. Handler oczywiście znalazłem i miałem go w sumie tylko wrzucić, ale jak to zwykle ja... nie mogłem się powstrzymać i postanowiłem nieco dopracować ten "dirty hack" który kiedyś uskuteczniłem... przeniosłem zatem wszystko na PC i zacząłem poprawiać. Niestety mam taką wadę, że zawsze coś chce dopracować do jakiegoś wyobrażonego przez siebie ideału, ale to nigdy nie następuje bo zawsze coś można dorobić i ulepszyć. Tak też zacząłem robić i z tym projektem, który zaczął się rozrastać a ja spędzałem kolejne godziny na dodawaniu dodatkowych funkcjonalności. Jak tylko się zorientowałem że to nie ma najmniejszego sensu, powiedziałem STOP! Wydaje mi się ze obecna forma jest dość akceptowalna, zatem zapraszam zainteresowanych na stronę projektu na GitHub: T2K Handler - repozytorium na GitHub

Projekt jest public domain! Po szczegółowy opis funkcjonalności jak i "release" (czyli archiwum zip zawierające pliki .ATR i .XEX) zapraszam jak pisałem wyżej do repozytorium na GitHub. Mam nadzieję że przyda wam się to narzędzie do archiwizacji czy też nagrywania sobie kaset w systemie Turbo 2000, na prawdziwym sprzęcie z pod DOS (sterownik obsługuje zarówno odczyt jak i zapis). Jeżeli ktoś znajdzie jakieś błędy lub nieścisłości proszę o info, będę starał się poprawić w miarę możliwości czasowych.

Hej!

Dzięki wielkie za odpowiedź i rzeczowe komentarze! Powiem Ci że jeżeli chodzi o funkcjonalność COPY to też zastanawiałem się jak to rozwiązać, ale chciałem już wypuścić jakąś wersję w świat, aby mieć jakikolwiek "feedback" i widzę że to okazało się dobrym pomysłem. Dodam funkcjonalność kopiowania pierwszego napotkanego zbioru wraz automatycznym dostosowaniem nazwy. Być może dodam też coś w rodzaju "TAPE DUMP", aby kopiował wszystko jak leci na wskazany dysk/nośnik./ram-dysk, etc. dodatkowo będzie generowany będzie pewnie plik .LOG który będzie zawierał statusy operacji. Odczyt/Zapis w systemie turbo możesz przerwać normalnie klawiszem BREAK (zrezygnowałem ze START+OPTION+SELECT).

C3 Copy jak najbardziej pochodzi od Code3, nazwa pozostała ponieważ w źródłach miałem jakieś pierwotne wersje tego programu, postanowiłem przenieść to co już było i nieco rozbudować. W sumie skończyło się na przepisaniu praktycznie wszystkiego od nowa, ale nazwa pozostała.

T:, T1: T2:/ --> bez nazwy ... nie sprawdzałem w sumie :D ale wydaje mi się że przy odczycie będzie czekał na nazwę składającą się z samych "spacji", a przy zapisie zapisze "pustą" nazwę, jednak zweryfikuję to, bo przyznam że nie sprawdzałem :D

Jeżeli chodzi o pytanie o nazwę i T/N... to ja sprawdzam czy kod znaku nie jest >="T", wtedy każdy klawisz powyżej "T" akceptuję nazwę, tzn. odpowiedź użytkownika typu: "T","U","V","W","X","Y","Z"... będzie dawało taki sam efekt jakbyś nacisnął "T", to wynika z faktu uproszczenia procki sprawdzającej i aby można było wciskać zarówno "T" jak i "Y".

Z Twoich poprawek oczywiście skorzystam jak tylko trochę się odkopię z bieżących spraw. Dzięki, że chciało Ci się to przeczytać... ja byłem już tak "zmęczony" tym projektem że to "readme.md" naprawdę klepałem byle jak aby jak najszybciej to skończyć. Dopiero teraz widzę ile literówek i błędów zrobiłem!