1,201 Ostatnio edytowany przez takron27 (2025-05-29 13:38:02)

> "Możesz użyć dowolnego DOS-a który Ci odpowiada, wybieraj takiego który ma niskie MEMLO"
ha, żebym miał taką wiedzę... jeśli bw-dos generalnie się do tego dobrze nadaje, to sobie na taki przejdę.

> "Narzędzie "OFFLOAD" [...] aby pokazać że po konwersji powstaje plik .XEX o prawidłowej strukturze i że nic nie jest uszkodzone."
;-D ok, to nie użyję, bo mogę nie wiedzieć 'co ja paczę' i co wskazuje na błąd a co nie.

> "Atari800 + FUJI [...] gradacja przewijania nie była jakaś mocno zgrubna (1 sekunda nagrania?)"
bardzo dobrze pamiętasz. ale jak dla mnie nie musisz przerabiać z tego powodu antyajka. dla mnie nie ma dużego problemu powycinać początki wave, tyle miejsca na dysku jeszcze mam,  nie sądzę żeby więcej niż kwadrans mi zajęło wycięcie per kaseta maraudera (21-22 nagrania). tak że luz..

ED.:
a.d. najnowszego antyajka:
jeśli będzie za mało pamięci na dekodowany program, to co, antyajek zgłosi jakiś błąd/komunikat? czy to że nie podsumuje 'kodem 01' zakończenia tworzenia xexa ?

1,202 Ostatnio edytowany przez seban (2025-05-29 20:20:08)

takron27 napisał/a:

jeśli będzie za mało pamięci na dekodowany program, to co, antyajek zgłosi jakiś błąd/komunikat? czy to że nie podsumuje 'kodem 01' zakończenia tworzenia xexa ?

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".

1,203 Ostatnio edytowany przez takron27 (2025-05-30 08:14:33)

>" [...] 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"."
no, tylko tego pod atari800-mod-fuji nie zrobię. tzn mogę uruchomić xexa antyajka, pod d1 podmontować pusty atr z dosem, dalej, wybieram zapis na d1 i określam nazwę tworzonego xexa, wybieram rodzaj/podłączenie turbo,  'magnetofon nie rusza' i za moment error $82 . (atari800modfuji)

ed. odnalazłem trochę skitraną (za bardzo jak dla mnie) opcję włączenia/obsługi H pod atari800.

ed2. udało mi się zapisac/stworzyć xexa na h:, ale musialem antyajka odpalić z atra z dosem. nie mam pomysłu jak to ustawić żeby nie było tej potrzeby.

ED3.
ok, wymyśliłem ;D do katalogu gdzie podmontowane H1:, skopiować dos.sys i dup.sys.
i działa.
pojemność $E800 bufora dla antyajka.

1,204

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ć.

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,205

no i ok,
choć nadal trochę niepokoi mnie stwierdzenie:
> "Część programów może się uruchamiać po takiej konwersji i można nie być świadomym uszkodzenia "kawałka" zapisanego zbioru."
(post: https://www.atari.org.pl/forum/viewtopi … 96#p321596 )
przypuszczam że dla swojego spokoju przepuszczę swoje ripy przez aktualnego antyajka; bo albo to, albo 'z rozpędu' zrzucanie trzech taśm zestawów sonixa w turbo2000 które mam (to na 99% nie pojawiało się w żadnym wątku).

ale,
pytanie trochę w temacie. do sygnału ajka świetnie spawę robienia xexa załatwia antyajek.
a co ze standardowym zapisem w t2000kso; jak najprościej zrobić xexa z takich wave? jakiś kopier uruchomiony na emulatorze który by umiał magnetofon w turbo i zapis na pliku dysku atr, albo też jest coś z obsługą h ?

1,206

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.

1,207

fajnie, dzięki:)

1,208

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.

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,209

ok, dzięki za podpowiedzi. przypuszczam że najtrudniejsze nagranie na tych moich sonixach to by było 'hobby tronic demo '90', które już Piguła przerobiłeś, na dodatku do maraudera17.
seban, dzięki, funkcja motor-control, wydaje się załatwiać sprawę ustawienia wave po loaderze ajka. pierwsze tytuły już się zrobiły. najs:)

1,210

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

1,211

leży w tym katalogu:
https://drive.google.com/drive/folders/ … drive_link
wśród kilku innych plików - dem które onegdaj dograłem na końcu zestawu #17 maraudera. one wszystkie są w normalnym t2000kso (bo tylko takie coś potrafiłem kopiować).
co do nagrania HT'90 to brzmi brzydko;D ale atari800 potrafi to poprawnie wczytać.

1,212 Ostatnio edytowany przez seban (2025-05-31 21:53:06)

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.

Post's attachments

hobby_tronic_90.zip 103.37 kb, liczba pobrań: 9 (od 2025-05-31) 

Tylko zalogowani mogą pobierać załączniki.

1,213

dzięki za info, 'będzie bawione' choć trochę później; teraz dokańczam wyłuskiwanie xexów ze swoich ripów maraudera; jednak trafiają się pojedyncze tytuły (1-2 na kasetę) których md5 różni się od tych zrobionych antyajkiem 1.5, choć 1.2 nie zgłasza problemu; ale zakładam że tamte wcześniejsze jakoś są uszkodzone mimo że się uruchamiają.

co to Twojego skryptu, to cieszy mnie fakt, że różnymi metodami i Ty i Piguła otrzymaliście do tego HT'90 xexy identyczne, ze zgodnym md5:)

1,214

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

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

1,215

uicr0Bee napisał/a:

@Seban rozpoznajesz co to? Warto dodać do niniejszego "serialu"? W sensie nabyć.

seban napisał/a:

[...]wszystko wskazuje na to że jest to co myślałem, czyli Blizzard w wersji "one chip", o której była już mowa tutaj: Blizzard  - One Chip[...]

uicr0Bee napisał/a:

Znów upadło moje postanowienie że już takich nie kupuję... Ale to już ostatni raz ;-)
Już do  mnie jedzie,

Po tym jak paczka dotarła, to tylko :) trochę ponad miesiąc poleżała zanim się za nią wziąłem. Magnetofon wczytuje kasety nagrane w Turbo Blizzard.
@Seban, odkładam do następnej transzy i czeka cierpliwie.

Moje skany czasopism i książek z epoki: https://chomikuj.pl/uicr0Bee ; https://archive.org/details/@uicr0bee
Potrzebujesz dyskietki? Proszę: http://www.atari.org.pl/forum/viewtopic.php?id=18887
<-- Kontakt prywatny proszę przez "E-mail", a nie "PW".

1,216

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

https://raw.githubusercontent.com/seban-slt/t2k_handler/refs/heads/main/scr/t2k_hnd_no_dos.png

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.

1,217 Ostatnio edytowany przez QTZ (2025-07-24 05:37:00)

Hej!

Wielkie dzięki za ten program :)

...Na razie nie mam jednak czasu go przetestować/używać...

Póki co przeczytałem readme i poprawiłem dostrzeżone błędy - plik do porównania i wykorzystania wedle uznania w załączniku.

Kopiowanie blokami umożliwiał już program "Kopiarka" W. Zabołotnego, brakowało trybu który umożliwiałby kopiowanie plików w całości do/z pamięci. No i nie można ich było bezpośrednio uruchomić spod DOS-a - myślę, że teraz jest to możliwe. Możliwe powinno być też używanie Turbo, stacji dyskietek i normalu naprzemiennie np. z poziomu Basic-a!

Także LOAD i SAVE są bardzo potrzebne i to nie tylko do normalu. Są niezbędne też gdy nie ma możliwości podłączenia kilku urządzeń jednocześnie (przełączamy przewód SIO do odczytu i zapisu) - co jak przypuszczam mało kto może zrobić z biegu (nie posiadając splittera / kabla/kabli).

[Dlatego też kiedyś zmodyfikowałem "Kopiarkę" i używałem jej jako prymitywnego handlera T: (zawiesza się przy dłuższych plikach, nie jest odporny na reset)].

Wg readme przy funkcji COPY należy podać nazwę pliku do zapisu zanim magnetofon znajdzie nazwę pliku który będzie odczytywał.

Ja większość kaset mam nie opisanych i zawierają mnóstwo małych plików m.in. w Basic-u, trudno więc przewidzieć jakie będą nazwy kolejnych plików (podobnie gdy przed właściwym programem jest loader).

Wiele nazw w Turbo KSO mam zapisanych w negatywie lub z innymi znakami niedopuszczalnymi przez DOS-y (i Windows-y) [jest to jeszcze większym problemem przy kopiowaniu programami rozpoznającymi sygnał na PC].

Dlatego też proste przeniesienie nazwy odczytanej z Turbo byłoby problematyczne. Nazwy też często się powtarzają bo zapisywałem kopie na wypadek gdyby się coś nie wczytywało.

Być może wygodniej byłoby gdyby program kopiujący sugerował nazwę do zapisu po zaakceptowaniu nazwy z taśmy i od razu zamieniał inverse w normalne znaki, jak i zamieniał znaki niedopuszczalne? (można np. użyć wielu kropek) Lub chociaż, żeby wyświetlał nazwę oryginału (nie wiem czy tak jest w przypadku @) i dopiero wtedy umożliwiał wpisanie nazwy do zapisu? (tylko gdy odczyt w turbo - blokami)

Mogłaby to być osobna komenda... sam nie wiem trochę to udziwnienie. Mogłaby wtedy też być komenda do seryjnego kopiowania - turbo -> dysk. ...tak luźno się zastanawiam... Oryginalnie w Turbo KSO można przerwać wczytywanie naciskając Start+Select+Option.

Ewentualnie można nawet mając podłączone razem turbo i inne urządzenie po prostu używać LOAD i SAVE - wtedy podamy nazwę świadomie.

A co się stanie gdy użyję samego T: / T1: / T2: (bez żadnego znaku i nazwy) przy odczycie jak i zapisie? Ciekawe co się stanie jak się użyje copy z DOS-a i jako docelowy plik *.*?

Ciekawostka: w KSO zauważyłem, że jako 'TAK' z jakichś przyczyn działa też klawisz '4' i jest to całkiem wygodne (być może jeszcze jakiś/-kieś inny/-e, których nie zauważyłem).

Code3 - to nazwa grupy, od której narzędzia brały nazwę? OK, znalazłem: http://atariki.krap.pl/index.php/Code3 ;)

Nie chcę obiecywać, kiedy, ale z pewnością ten handler sprawdzę w działaniu i być może wrócę do kopiowania moich plików z kaset :) Może też kiedyś zrobię przewód łączący magnetofon i SIO2PC/SIO2SD...

Jeszcze raz Dzięki Seban :)

Post's attachments

readme_t2k_corrected_by_qtz.md 19.7 kb, liczba pobrań: 3 (od 2025-07-24) 

Tylko zalogowani mogą pobierać załączniki.

1,218

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!

1,219

+ można dodać przy odczycie ustawianie SioOut=0 aby można było z magnetofonu Blizzarda skorzystać do odczytu.

- to turbo ma tego samego buga co blizzard a mianowicie jeśli liczba danych jest równa 3072 (lub wielokrotność) to ostatni blok jest nadawany ponownie (w blizardzie wielokrotność 1024) Czyżby ktoś kopiował kod handlera w zamierzchłych czasach?



Przebadałem trochę to turbo=handler. Na początki częstoliwości: pilot 1032Hz, "1" 2049 Hz, "0" 4125 HZ
Kolejność połówek sinusoid odwtotna niż w Blizzardzie (najpierw górna, potem dolna)
Przebieg na nagraniu analizera.
Jak chcecie porównać z normalem lub blizzardem to w iinym poście dokładnie wszystko umieściłem.

https://www.atari.org.pl/forum/viewtopi … 53#p318653