Hehe, nie dawało mi to spokoju więc sprawdziłem. Mój cas jest nieczuły na odwracanie polaryzacji ze względu na dobór szerokości impulsów. Turgen przy domyślnych ustawieniach dla częstotliwości 44100 daje 24 sample na impuls pilota, 14 na jednkę i 8 na zero. Zauważyłem, że przy zapisie Blizzarda w emulatorze wychodzi inaczej - 22 sample na impuls pilota, 11 na jedynkę i około 7.5 na zero. Ułamków nie da się zapisać, przy 7 na realnym sprzęcie są błędy, dla 8 jest ok. Więc ja ustawiam 22,11,8 i przy tych wartościach procedury są nieczułe na odwracanie polaryzacji (poza tym brzmi bardziej podobnie do prawdziwych nagrań). Albo to przypadek, albo właśnie tak miało być w zamierzeniu twórców Blizzarda, to dośc logiczne, że do tego powinni dążyć. Przy 24,14,8 polaryzacja ma znaczenie.
Zmieniłem impulsy na 22,11,8,8 i faktycznie gry wygenerowane w Turgenie wczytują się niezależnie od tego czy w emulatorze 'Invert polarity...' ustawię na Yes lub No. Jest jednak drobna różnica przy zmianie tego ustawienia. Widać to w programie do ustawiania głowicy 'Head set' z carta BLZ_40_rozbrojony.rom Dla odwróconych impulsów są poprawne dwa paski 4kHz i 5,5kHz a dla nieodwróconych impulsów są cztery paski jeden obok drugiego. System turbo mam wtedy ustawiony na Auto Turbo. Testowałem to na piku wav wygenerowanym w Turgenie bez odwracania impulsów. Program 'Head Set' pewnie coś sobie inaczej interpretuje przy zmianie polaryzacji impulsów.
Tak, bo to że działa przy tych konkretnych parametrach to jest jednak zbieg okoliczności, można by rzec bug spowodowany za małą dokładnością. Jak się ustawi częstotliwośc 1.77 MHz (opcja "CPU clock" w emulatorze), to plik wynikowy się zachowuje normalnie, ze złą polaryzacją nie działa. A to jest przecież zapis z dokładnością do cyklu zegara. Szerokości impulsów w samplach przeliczone na 44100 Hz powinny być około:
Ułamkowych sampli zapisać się nie da, nieparzystych wartości nie da się też podzielić równo na dwie połówki impulsów, więc sobie jakoś tam wychodzi, a efektem ubocznym jest działanie przy obu polaryzacjach. Sumy połówek zer i połówek jedynek akurat wychodzą takie, że w odpowiednich miejscach dają zero a w odpowiednich jeden. Pewnie jak by przeanalizować wszystko dokładnie, to by się dało ustalić, dlaczego tak się dzieje.
Ile osób ma zewnętrzny adapter z obsługą Blizzarda ?
Z Turbo KSO, kiedyś używałem kaset, dziś głównie adaptera. Prawdopodobnie inni też korzystają z adaptera kasetowego z magnetofonem w turbo jakie posiadają.
Nie chce mi się, wybacz.
Oczywiście wybaczam. Trzeba będzie uważać. Super, że w ogóle wyciągnąłeś ten loader, chyba któregoś dnia sobie Blizzarda zmontuję :)
Po naciśnięciu reset lub wywolaniu reset w inny sposób ROM wraca na swoje miejsce i "znika" microloader.
Wcale nie znika - restartuje się, w manualu jest napisane, że w przypadku błędu można ponowić próbę wczytywania (wtedy się przydaje interakcja) W The Goonies przełącza się na C również w innej sytuacji, chyba po wystąpieniu błędu transmisji, więc wygląda na to, że coś w samej grze się przełącza.
jak się używa karta, to po co ładować loader z kasety ?
Można mieć kartridż bez tego loadera; nie musimy wiedzieć co wczytujemy. Może lepiej, tak jak w KSO nagrywać wersję xex i wczytywać z KOS-u z kartridża? Nie wiem czy to dobry pomysł i czy jest to do zrobienia, ale może wersja boot powinna dodatkowo wyłączać kartridż?
Wszystkie czesci blizzardowe maja nazwy.
Tak jakby sygnał w normalu powodował złe odczytanie nazwy i zawieszenie. Próbowałem osobne pliki i jest tak samo.
Wygenerowałem nowy plik boot przy pomocy Turgena (standardowe parametry) i jest dobrze, więc prawdopodobnie Blizard tak reaguje na plik cas (normal) wygenerowany Twoim sposobem. Prawdopodobnie wstrzeliłeś się w bug-a w Blizzardzie :)
Ciekawe czy na Atari też Blizzad się tak zachowuje?
Co do ustawień parametrów sygnału, to ja bym nagrał sygnał z Turbo na Atari i próbował dobrać tak parametry, żeby generowany sygnał był jak najbliższy oryginałowi.
Standard - Fixed discontinuities in the signal caused by resetting phase after each block. In SVN already.
All Turbo Systems - Inverting the polarity of pulses was not working for waveforms other than square. In SVN already.
New pulses - Fixed pulses for Turbo Blizzard. Set to T4410,4410,22,12, 8, 8, 0. This is reported to work with real hardware and FUJI's version of atari800-a8cas emulator. Does not work with latest version of Krotki's atari800-a8cas emulator. In SVN already.
2. Generator Enhancements
Turbo Blizzard - Prepending of the Microloader 3.0 and Short KOS either as a Turbo Blizzard file or as a standard cassette boot file. Adding new Binary convertors for conversion with one of the loaders.
KSO Turbo 2000 - Prepending of the L1 and L2 loaders. Either as a KSO Turbo 2000 File or a standard cassette boot file. By the way, who will hack the loaders to support both joystick port and SIO port :-) ?
3. Decoder Enhancements
Turbo Blizzard - Update of widths of pulses
KSO Turbo 2000 -A new option that will allow to decode files with a loader. There will be a new file format option ("Natural File Format"| File with a loader"). No automatic detection yet (if ever).
@baktra: Proponuję by oprócz Microloader'a 3.0 dodać również Short KOS (do wyboru jako loader przy konwertowaniu na Turbo Blizzard). Mam przekonwertowane ponad 100 gier z czego większość wczytuje się przez Short KOS. Tylko nieliczne wymagają Microloadera. SHORT KOS ładuje pliki DOSowe i jeśli w czasie wczytywania pliku ukaże się komunikat - FORMAT ERROR - plik taki należy załadować MICROLOADEREM.
@QTZ: Microloader podmienia wektor skoku do procedur obsługi magnetofonu w tablicy HATABS ($031a), a naciśnięcie reset przywraca tę tabelę do wartości domyślnych. Co prawda microloader podmienia jeszcze dodatkowe zmienne (CASINI, DOSINI...), które powodują, że po resecie HATABS powinna być uaktualniona, ale Goonies też te same zmienne podmienia przy instalacji swojej obsługi reset. Więc naciśnięcie reset dezaktywuje microloadera, wracają standardowe procedury obsługi magnetofonu. Po błędzie wczytywania dzieje się widocznie to samo. Nie zmieni się tego bez modyfikacji gry. Aha, i jeszcze - pierwszą rzeczą, którą sprawdza GOONIES.1 jest to, czy jakiś cartridge jest włożony lub basic włączony. Jeżeli tak, to się po prostu wiesza. Więc nie można wczytywać z włożonym jakimś innym cartridge-em. Niemodyfikowany Microloder wyłącza cartridge-a, dlatego że wie, jak go wyłączyć, inne karty mogą nie dać się wyłączyć w ten sam sposób.
One day, I will take source code of the Turbo Blizzard's T: handler and extract a routine that loads a blizzard block to a particular address.
On the top of that, I will build a microloader that is not using a T: device. One source will be compilable to multiple variants - different placement of the 1 KB block. If only I had enough time for games like that. This I have done for Czechoslovak Turbo 2000 - Kilobyte blocks and Czech B-TAPE. Loads lots of games (because the loader is small).
@xtrem007 As there is a .xex or .bot file with short KOS, adding short KOS is possilble. List of TODOs updated.
Edit: Na szybko przetestowałem na grze "Amaurote+ RC2 (2013)(Husak, Jakub)(US)[enhanced].xex" która jako jedna z niewielu wymaga Microloadera. W Turgenie przy wyborze i sprawdzeniu loadera Short KOS prawidłowo otrzymałem komunikat, że "Binary file will destroy loader". Po wybraniu Microloadera [ml] gra wygenerowała i wczytała się poprawnie. Inne gry wymagające Short KOS przy użyciu wygenerowanego loadera [sk] wczytują się poprawnie. Wygląda na to, że wszystko działa poprawnie:)
To są dobre wieści. Dziękuję. Te udoskonalenia przejdą do następnego wydania.
Co mnie dotyczy, jest licencja. Mam kod źródłowy wszystkich ładowarek dostarczonych z systemem Turgen. Te dwa są wyjątkiem. To prawdopodobnie coś niezgodnego z GNU GPL.
@Baktra W jednym z moich projektów potrzebowałem użyć zewnętrznego programu innego producenta (freeware, ale bez możliwości dołączenia do własnego projektu) i rozwiązałem to tak, że jeżeli mój program nie znajduje odpowiedniego exe-ka w swoim katalogu to wyświetla pytanie czy użytkownik chce go ściągnąć z serwera producenta automatycznie, czy zrobi to manualnie (podany jest adres). Następnie exe-k jest pobierany i uruchamiany (lub sprawdzane jest czy użytkownik taki plik umieścił manualnie), sprawdzam jeszcze klucz w rejestrze odpowiedzialny za zaakceptowanie licencji i jeżeli nie jest ustawiony proszę o zaakceptowanie licencji i dalej już wszystko działa bez interakcji z użytkownikiem.
Jednak w tym przypadku mam nadzieję, że nie będzie to potrzebne.
@FUJI Dzięki za odpowiedź, a co z bug-iem w Blizzardzie (brak nazwy po normal-u)? Nie to żebym prosił o poprawkę (choć może było by fajnie żeby po latach coś zostało ulepszone), ale ciekawe co się dzieje i czy tak jest też na Atari? No i jeżeli to wina parametrów sygnału to przydałyby się nowe cas-y :) Jeżeli nie robisz ich w jakiś specyficzny sposób, to mogę sam takie przygotować - np. jeżeli to możliwe zgrać do jednego pliku cas kopierem na emulatorze. Problemem dla mnie jest połączenie kilku plików w jeden cas, kiedyś Krótki opisał jak to zrobić jego programem - łącząc pliki hex, ale nie wiem czy to zadziała z Blizzardem?
Przy okazji można spróbować z Winter88, którą zgrałem z obrazu kasety od Sebana (nie uploadowałem).
@QTZ To nie bug w Blizzardzie, takie zachowanie jest spodziewane i tak się będzie działo też na prawdziwym sprzęcie. Serduszko to znak atascii o kodzie 0. To znaczy, że wszystkie bity danych i bity sumy kontrolnej w bloku z nazwą są odczytywane jako bity 0. Dlatego też nie ma błędu odczytu - suma kontrolna się zgadza. Nazwa ma zawsze 76 bajtów długości, normalnie na końcu są niewidoczne spacje uzupełniające długość do 76, tutaj widać wszystkie 76 serduszek. Wspominałem nie raz, że procedury odczytu Blizzarda dopasowują się do prędkości transmisji. Służy do tego pierwszy, długi sygnał pilotujący. 2048 kolejnych impulsów jest wykorzystywane do obliczenia spodziewanych szerokości impulsów dla zer i jedynek. Przy włączonym obwodzie turbo sygnał w normalu jest interpretowany jako sygnał turbo i traktowany jako ten długi pilot, na podstawie którego robione są obliczenia. Wychodzi tak, że jedynki powinny być dłuższe niż te zapisane na taśmie (czy w pliku cas), więc wszystkie impulsy są potem odczytywane jako zera.
Turbo jak najbardziej można obrabiać w plikach hex tak jak normal. a8cas-util.pl, zwałaszcza po ostatnich poprawkach, akurat Blizzarda potrafi już przerabiać we wszystkie strony. Może też kilka plików raw/cas/hex/wav przekonwertować od razu do jednego pliku cas/hex/wav.
Do programu a8cas-convert z paczki a8cas-tools od jakiegoś czasu powoli dorabiam obsługę turbo. Coś mi jeszcze przeliczanie częstotliwości nie działa. Jak będzie co pokazać to wrzucę do wątku o AST multicartridge, żeby było w jednym miejscu.
Błąd jest bo się zawiesza... (z Twoimi cas-ami, bo jak już pisałem, jak wygenerowałem nowy wav-e to nie było tego problemu, sprawdzę jeszcze raz w wolnej chwili...).
Moim zdaniem to dość dziwne żeby determinować prędkość transmisji do sygnału pilotującego nazwę programu?! W Turbo K.S.O. w ogóle ten pilot nie ma znaczenia (tylko w sensie przerwy, aby magnetofon zdążył się rozkręcić gdy pliki są nagrane jeden za drugim), liczy się tylko "miejsce" z nazwą i dopiero później dane i tak jest logicznie. Odczyt i pomiar powinien być przeprowadzany dopiero po odnalezieniu nagłówka programu. Chyba jeden z kopierów Blizzarda ma opcję do wydłużania sygnału w locie, czyli sugeruje to, że każdy blok może być innej długości, czyli pomiar powinien odbywać się na bieżąco.
Gdy pominiemy jakiś program lub ustawimy taśmę w nieodpowiednim miejscu to będzie "odczytywany" fragment poprzedniego (poprzednich) pliku, który nie powinien mieć znaczenia, bo on nas nie interesuje. A w Turbo K.S.O. mam kasety z muzyką i audycjami z radia...
@QTZ Taka chyba uroda Turbo Blizzard. Na "atariki" piszą: ..."Plik" zapisany w formacie Turbo Blizzard składa się z bloku synchronizującego i bloków danych. Blok synchronizujący to 3072 impulsy sygnału pilotującego i 2 impulsy odpowiadające bitowi "0" na końcu. Podczas odczytu znalezienie 2048 kolejnych impulsów sygnału pilotującego oznacza początek "pliku", a dalsze 95 impulsów wykorzystywane jest do kompensacji zmian prędkości spowodowanych zmianami prędkości przesuwu taśmy. Podobnie jak przy standardowym zapisie magnetofonowym przy korekcie wykorzystywany jest licznik linii obrazu. Korekta polega na odpowiedniej modyfikacji kodu handlera - zmianie wartości ładowanych do akumulatora w trybie natychmiastowym. Wartości te wykorzystywane są do odpowiedniego ustawienia liczników Pokeya. Reszta bloku synchronizującego jest omijana (do momentu wykrycia znacząco krótszego impulsu). Zasadniczo występują dwa typy bloków danych: blok nazwy pliku i blok właściwych danych. W "pliku" znajduje się jeden blok nazwy (zaraz za blokiem synchronizującym) i jeden lub więcej bloków danych. W bloku nazwy kolejno występują: 302 impulsy sygnału pilotującego (potrzebne jest 36 do wykrycia bloku) 2 impulsy odpowiadające bitowi "0" - określające koniec sygnału pilotującego i początek właściwych danych 76 bajtów nazwy "pliku" (dowolne znaki możliwe do wyświetlenia na urządzeniu E:). Jeżeli nazwa jest krótsza, to reszta bloku wypełniona jest spacjami. Długość prawdopodobnie ma związek z ilością znaków mieszczącą się w jednej linii trybu graficznego 0 (38 przy zachowaniu 2-znakowego marginesu). 1 bajt sumy kontrolnej 1 bajt dodatkowy (ignorowany przy odczycie), najprawdopodobniej chroniący koniec bloku przed uszkodzeniem (ostatni poziom i zbocze sygnału są niepewne, ostatni bit jest nieczytelny) W bloku danych mamy: 302 impulsy sygnału pilotującego (potrzebne jest 36 do wykrycia bloku) 2 impulsy odpowiadające bitowi "0" - określające koniec sygnału pilotującego i początek właściwych danych 2 bajty określające ilość znaczących bajtów w bloku. Mogą przyjmować wartość 1024 ($400) lub mniejszą. Niezależnie od tej wartości blok zawsze ma długość 1024 bajtów. Liczba w bajcie starszym różna od $04 (czyli np. dla niepełnych rekordów) oznacza ostani blok "pliku". 1024 bajty danych 1 bajt zawsze równy 0 (przeznaczenie nieznane) 1 bajt sumy kontrolnej. Suma kontrolna zawsze obejmuje wszystkie bajty bloku (2 bajty długości, 1024 bajty danych i bajt 0 za nimi). 1 bajt dodatkowy (ignorowany przy odczycie), najprawdopodobniej chroniący koniec bloku przed uszkodzeniem (ostatni poziom i zbocze sygnału są niepewne, ostatni bit jest nieczytelny) Bity w bajcie są zapisywane w kolejności od najstarszego do najmłodszego (odwrotnie niż przy zapisie standardowym). Jednobajtowa suma kontrolna jest obliczana przez dodawanie bez przeniesienia (czyli modulo 256, podczas gdy przy zapisie standardowym stosuje się dodawanie z przeniesieniem). Przerwy między blokami: przed zapisem bloku synchronizującego pozostawiana jest cisza trwająca w przybliżeniu 2.5 s (potrzebna na rozpędzenie silnika i stabilizację obrotów) między blokiem synchronizującym i blokiem nazwy odstęp trwa w przybliżeniu 0.1 s między blokiem nazwy i pierwszym blokiem danych odstęp trwa minimum 2 s; po zapisaniu bloku nazwy silnik magnetofonu jest wyłączany i ponownie włączany przed zapisem pierwszego bloku danych. Po odczycie bloku nazwy silnik też może być zatrzymywany, żeby dać możliwość potwierdzenia wczytania "pliku", więc odstęp jest konieczny. odstępy między kolejnymi blokami nie są ściśle zdeterminowane i zależą od oprogramowania korzystającego z handlera. Minimalne obserwowane przerwy mają długość 0.08 s. Programy kopiujące pozwalają ustawić krótsze lub dłuższe przerwy, ewentualnie wstawiają dłuższe przerwy, gdy wykryją konieczność uruchomienia procedur inicjujących program pomiędzy blokami nagrania. Zbyt krótkie przerwy w pewnych granicach może skompensować sygnał pilotujący następnego bloku. przed ostatnim blokiem odstęp jest dłuższy o 0.4 s.
@xtrem007 To mój tekst, więc nie można go tu użyć do popierania moich twierdzeń ;P.
@QTZ Masz jednak trochę racji. Moje wyjaśnienia są poprawne, ale nie uwzględniają sposobu, w jaki obecnie działa emulacja odczytu plików cas i hex. Jak przekonwertujesz mój plik cas do wav, to już tego efektu z serduszkami nie zobaczysz. Zapomniałem o jednej rzeczy. W przypadku plików cas i hex sposób dekodowania zapisu na sygnały 0 i 1 zależy od tego, z jakim typem bloku mamy do czynienia. Bloki "data" są zawsze dekodowane jako zapis FSK, niezależnie od tego, czy tryb turbo jest włączony czy nie. Podobnie bloki pwm* są zawsze dekodowane w trybie turbo, niezależnie od tego czy turbo jest włączone w menu czy nie. Dlatego w emulatorze zapis FSK jest przez procedury Blizzarda wykrywany jako powolny pilot Blizzarda, co prowadzi do efektu, który opisałem. Myliłem się więc, że na prawdziwym sprzęcie będzie to samo. Nie jestem w stanie na szybko ocenić, jak duże zmiany w liba8cas i/lub w emulatorze są potrzebne, żeby emulacja jeszcze lepiej przystawała do rzeczywistości. Ale na pewno jest to wykonalne. Kiedyś :P.
Skomplikowane... to znaczy, że jak ustawimy taśmę dokładnie na nazwę, to program będzie się wczytywał ze standardowymi wartościami, a jak przed pilotem to się te wartości ustawią? Bardzo dziwnie rozwiązane... Muszę potestować...
Ale cieszę się, że moje rozważania przyczynią się do poprawek w emulatorze, nawet jeżeli to nastąpi "kiedyś" :)
Mam wiele kaset z programami w Blizzardzie i na realnym sprzęcie tego problemu z serduszkami nie zauważyłem. To chyba zależy jakie są te inne "piski" nagrane przed pilotem. Wkładam kasetę, puszczam w dowolnym momencie i zawsze bez problemu znajduję nazwę. Nigdy mi się nie zdarzyło by pilot FSK600 lub zapis w normalu został rozpoznany i wyrzucił jakieś serduszka.
@QTZ Nie, to tak nie działa, nie czytałeś opisu przytoczonego przez xtrem007. Najpierw musi być ten długi "sygnał synchronizujący" jak go nazwałem, ponad 2000 impulsów. Przed blokami nazwy i blokami danych jest tylko 300 impulsów pilota, które zostaną potraktowane jako śmieci i wczytywanie się nie zacznie.
@xtrem007 Też nie czytałeś uważnie. Napisałem
Myliłem się więc, że na prawdziwym sprzęcie będzie to samo.
Napisałem, też, że jak się przekonwertuje cas na wav, to efekt serduszek na emulatorze też nie wystąpi, bo pliki wav są obsługiwane inaczej niż cas. Na prawdziwym sprzęcie można zasymulować ten efekt zmieniając szerokość impulsów pilota. Wygeneruj sobie z Turgena plik w Blizzardzie po zmianie parametrów impulsów np. na T4410,30,11,8,8,0. Powinieneś zobaczyć serduszka przy wczytywaniu przez adapter lub z taśmy.
Tak, ładowarka mierzy szerokość impulsów sygnału pilota. Z szerokości impulsu sygnału pilotującego uzyskuje się tolerowaną szerokość krótkiego i długiego impulsu.
Problem stwarzał tylko loader L2. W międzyczasie pomyślałem, że mogłaby być opcja zgrywania bloków bez nagłówka - tzn. gdyby został znaleziony blok to żeby był odczytany i kolejne aż do końca pliku, dłuższej przerwy lub wystąpienia błędu i zapisywane jako jeden plik (obecnie każdy blok można zgrywać do osobnych blików). Dalej odczyt do nowego pliku. To może być pomocne aby odczytać fragmenty na których część coś zostało nagrane. Podobnie w przypadku wystąpienia błędu przydałaby się opcja, żeby próbować odczytać dalszą część bloku nie przejmując się błędem. Przydałaby mi się taka opcja, do plików tekstowych np. lst, czy nieskompresowanej grafiki :) Obecna opcja chyba nic nie daje?
Edit: Coś mi ten update nie działa. Czy wystarczy dograć ten plik? - wtedy chyba nic się nie zmienia - plik nie jest zablokowany. Czy zamienić istniejący? - wtedy mam błąd o KBlockPlugin...
Edit: OK, działa podmieniony z powyższą wersją 8.6.9 dev :)
Edit: Nie testowałem jeszcze w działaniu bo muszę coś najpierw zgrać, ale czy opcja "File with a loader" nie oznacza, że pliki bez loadera będą pomijane? Przecież na ogół nagrane pliki są mieszane raz z L1, raz z L2, a najczęściej bez, więc wydaje się to niewygodne... ale sprawdzę w działaniu i zobaczę jak to jest...
Edit: Z nową opcją zgrało jakby fragmenty plików... chyba pominęło pierwsze bloki...
Nie wiem czy potrzebnie tłumaczę:
Loadery Turbo K.S.O. niczym się nie różnią strukturą od innych programów tzn. mają blok z nazwą, kod mieści się w jednym bloku danych, więc jest to również blok końcowy, czyli kopier wczyta go jak każdy inny plik i tak samo zapisze. Uruchomiony Loader1 po wczytaniu uruchomi się i rozpocznie poszukiwanie bloku z nazwą i wczyta pierwszy znaleziony plik - również z blokiem z nazwą i blokiem lub blokami danych, czyli standardowy plik i tu dekoder nie powinien nic robić.
Różnica jest przy Loaderze2, który sam jest zwykłym plikiem, czyli też da się odczytać kopierem (1 blok danych - nie tworzy całości z zapisanymi danymi do wczytania), jednak po uruchomieniu od razu oczekuje danych (nie może być za nim nagrany blok nazwy, bo będzie błąd), więc plik nagrany za nim ma pominięty blok z nazwą, a poza tym się nie różni od innych plików - kopier tych danych nie znajdzie, ale wystarczy po odczytaniu loadera wymienić kasetę, odczytać dowolną nazwę, zmienić z powrotem kasetę i odpowiedzieć "T" i plik się wczyta (również ma blok końcowy).
Więc Turgen powinien tak jak opisałem powyżej odczytywać dane również gdy nie znajdzie bloku z nazwą. A już na pewno jak rozpozna, że odczytał Loader2, wtedy z automatu powinien odczytywać następujące po nim bloki aż do końca pliku, dla ułatwienia może ustawić nazwę na nazwę loadera + .L2_data czy jakoś podobnie (jeżeli będzie rozpoznawał L1 to też może dla ułatwienia odpowiednio rozszerzyć nazwę pliku; i nazwę samego loadera). Nie powinien natomiast niczego pomijać.
Opcje to ja bym sobie wyobrażał tak, że "odczytuj dane bez nagłówka (bloku z nazwą) tylko gdy zostanie wykryty znany Loader2" (rozmiar i suma kontrolna się zgodzi i ew. dodatkowo bardziej zaawansowane wykrywanie np. na podstawie kodu który pomija nagłówek) lub "zawsze gdy zostaną znalezione dane bez nagłówka" - wtedy tak jak opisałem powyżej.
Przepraszam za wadliwą wersję. Będę musiał dokonać więcej aktualizacji Turbo Decodera. Nowe opcje będą następujące: "Auto Detect", "Natural Format", "File without header".
Z drugiej strony pliki z użyciem ładowarek L1 i L2 są prawidłowo dekodowane, gdy wybrano "File with a loader".
Turbo Long i Universal Copy to kopiery a nie loadery... nie rozumiem...
Uważam, że "auto detect" - czyli odczytywanie plików z nagłówkiem (nazwą) i bez, ale za loaderem 2 - powinno być standardowo, a dodatkowe odczytywanie *wszystkich* "zagubionych bloków" jako opcja. Wszystko jest przecież "natural format"...
What I did. I took two programs from the KSO Turbo 2000 utilities disk (they happen to be copiers) and copied them with Auto Copy from disk to tape selecting the L1 and L2 loaders. Then I decoded it with the "File with loader" option.
I will explain how the "File with loader" option works:
1. Read KSO Turbo 2000 header 2. Read single block and completely ignore it (because it is presumed to be a loader) 3. Keep reading the blocks and save the data to a file.
So, when you select the "File with loader" option, the loader is never saved anywhere, it is just skipped.
And I don't think files copied with the L1 and L2 loader option are in natural format. The natural format implies a header. And the header is not present for the file after the loader.
The "Auto Detect" enhancement will work as follows: 1. Read KSO Turbo 2000 header 2. Read single block. If the block contains a known loader, completely ignore the block, otherwise process the block 3. Read all blocks until EOF and save
Co do naturalności formatu: Autocopy jest programem narzędziowym Turbo K.S.O. i wraz z loaderami jest tego samego autora co całe turbo, więc mimo, że kopier turbo nie ma opcji odczytu plików bez bloku nazwy, jest to przewidziane - więc standardowe. Autocopy ma opcję weryfikacji więc powinien odczytywać pliki zapisane z Loaderem 2.
Ciekawe czemu loader 2 jest tak pomyślany, a loader 1 inaczej? Ciekawe też o co chodzi z Autocopy 3.0 - jest to wersja zabezpieczająca - czyli nagrywa z jakimś zabezpieczeniem?
Uważam, że auto-detekcja loadera 2 powinna być domyślna (opcjonalnie można pomijać loadery - wtedy też detekcja L1), a zapis "luźnych" fragmentów (bez bloku nazwy i / lub zakończonych blokiem końca lub dłuższą przerwą - niestandardowe) opcjonalnie.
Maybe something similar like this?:
(Autodetect loader 2 by default, cannot be set to off) [ ] always read data if just after one block file (presume it may be loader 2 like) - read data without name block, but only if found after one block file, otherwise read as usual (if name found read as usual) [ ] read all possible data - read data with or without headers anywhere on tape - save series of blocks as one file (close file on end or if signal is missing for some time - I think 2 seconds maybe [or custom]? or if new block / file is detected)
[x] skip known Turbo K.S.O. loaders
[ ] when error is found read whole block, save and continue read the file (but set ".error" extension) - if another block is recorded in place of error this will be nice to detect that...
Może przesadzam, ale takie rozwiązanie chyba wyczerpuje różne przypadki nagranych plików na poprzednich w przypadkowych miejscach :) (zdecydowanie niestandardowe, ale mam i tak nagrane kasety, bo jak się coś nie wczytywało, to w to miejsce nagrywało się coś innego zostawiając fragmenty "spod spodu", które też może warto odzyskać...)
I have released a beta version of Turgen System 8.6.14. ->link<-
This beta version has support for additional sampling rates - 48000 Hz and 96000. You can select the sampling rates using the Tools>Preferences dialog in the "Audio Output" and "Wave Output sections".
Of course, to exploit the new sampling rate, the repository of pulses (pulses/pulses.list) must be updated. The pulse repository record shipped with this beta version for Turbo Blizzard was already updated as follows to take advantage of the new sample rate.
