Zamiast odpowiedzi - a czemu nie przesiądziesz się na oficjalny port Atari800? Droid800 nie jest już rozwijany, bo autor stwierdził że oficjalny jest lepszy. Co prawda Google zdjęło oba emulatory z marketu, ale zobacz post 4.

O ile rozumiem (a nie jestem pewien, bo ogólnie Twoje wypowiedzi są dla mnie dość zawiłe), to wcale nie naprawiasz uszkodzonych bloków (bo nigdy nie dochodzi do poprawnego odczytania ich przez MagoTrans), a jedynie zmieniasz sumę kontrolną w uszkodzonych blokach (generuje ją dla Ciebie Hacker), aby wczytywały się bez zgłaszania błędu. Wątpię, czy rzeczywiście jest to cel, który chcesz osiągnąć (taśma nadal zawiera niepoprawne dane); poza tym jest prostszy sposób na taką "naprawę". Ostatnia liczba w wierszu "data" pliku HEX to suma kontrolna wyliczona z rekordu przez MagoTrans, jest ona zawsze poprawna. Wystarczy zmienić sumę kontrolną odczytaną (przedostatnia liczba w wierszu) w każdym uszkodzonym rekordzie na tą wyliczoną, aby "naprawić" rekord, a następnie przekonwertować HEX->CAS->WAV - będzie ten sam efekt.

A to właśnie przykład wypowiedzi zawiłej i niezrozumiałej. Piszę to w dobrej wierze, bo mam wrażenie że nie starasz się zadawać pytań w sposób umożliwiający odpowiedź na nie.
1. Nie sprecyzowałeś, jaki konkretnie masz "problem z odpaleniem", w którym momencie, po wykonaniu jakich kroków.
2. Nie napisałeś, czym się różni błąd "ukryty" od innych - nie wiadomo jak to rozumieć.

CAS2CAS to program DOS-owy, możesz go sobie odpalić pod DOSBox-em, ale jest on bezużyteczny jeśli w każdym wytworzonym przez Ciebie pliku CAS dany rekord (180. w powyższym przykładzie) zawsze jest uszkodzony.

1. Odpuść sobie, MagoTrans (a dokładniej WAV2CAS, z którego MagoTrans korzysta) po prostu ma błędy. Używaj zamiast niego a8cas-convert z pakietu a8cas-tools.
Atari800-a8cas i a8cas-convert są oparte na tej samej procedyrze odczytu taśmy, więc zasadniczo jeśli dany WAV poprawnie się wczytuje w Atari800-a8cas, to a8cas-convert będzie potrafił wytworzyć z niego poprawnego CAS-a.
2. Stary Atari800WinPLus miał mniej dokładną emulację magnetofonu, oraz więcej błędów w obsłudze CAS-ów; dzięki temu np. z sukcesem ładował CAS-y z niepoprawnie zapisaną długością początkowego pisku (przez to do dziś po necie krąży sporo takich błędnych CAS-ów). Ale jeśli CAS nie działa w 4.1 lub w Altirrze, to jest to zdecydowanie wina CAS-a, nie emulatora.

Patrz wyżej, w v7 paleta nie jest taka sama.

Tak, v8 wciąż korzysta z mojej felernej generacji palety.

To on tych ustawień nigdzie nie zapisuje? Parametry da się tak ustawić, żeby paleta była bardzo podobna do Jakub.act, ale jak ustawienia nie są zapisywane to faktycznie trochę bez sensu.

W v6 też jest Jakub.act.

Przypomniało mi się. Autor emulatora wykorzystał w v7 kawałek mojego kodu dodającego w Atari800 generowanie osobnych palet w systemach PAL i NTSC na podstawie parametrów takich jasność, kontrast, nasycenie itd. Generator palety PAL był wówczas jeszcze niezbyt dokładny, a na dodatek w GUI nie były dostępne opcje regulacji.

Czyli poprawka - w v7 paleta nie jest oparta na żadnym pliku .act.

Z pewnością tak jest, jak się używa MagoTransa. Pliki CAS/HEX wytworzone przez a8cas-convert zawierają 100% danych ze źródłowego WAV-a - nawet gdy te dane nie zostaną rozpoznane jako poprawny rekord. Przy czym takie CAS-y są obsługiwane tylko przez Atari800-a8cas, pod innymi emulatorami ich nie wczytasz.

To sprawdź, nie będziesz już musiał wymyślać rozwiązań nieistniejących problemów, typu "zapis przez głośniki w realu". Daj znać jak coś nie będzie działać.

Patrz wyżej: dobrze zrobiony CAS nie może być uszkodzony.

Czy dobrze rozumiem, że chcesz ładować do Hackera taśmę z uprzednio wyciętym uszkodzonym rekordem?

Altirra w ogóle nie obsługuje zapisu kaset. Jedynie Atari800 to umie, przy czym jedynie Atari800-a8cas umie zapisywać niestandardowe bloki.

Takiego obrotu spraw nie brałem pod uwagę.

*szelmowski uśmiech*
Butuje czy nie butuje, ważne żeby AUTORUN.SYS dało się załadować, choćby spod innego egzemplarza DOS-a.

No to się trochę pospieszyłem z dzisiejszymi zmianami w Atariki...
trub, a masz gdzieś te wersje GTSYNCa udostępnione?
A poza GTSYNC.COM, czy DOS w wersjach LDW jest identyczny z Indusowskim 2.35I1?

Bardzo dziękuję za fotkę. Ja akurat spodziewałem się że zmieni się cały ekran, ale nie wydało mi się to istotne. Zdjęcie będzie bardzo pomocne. W ilu CHR$ się pomyliłęś? Mam wrażenie że nie w jednym, ale nie mam pewności.

Z tym nie łapaniem synchronizacji to rzeczywiście jest tak jak napisałeś. Jestem w trakcie deasemblacji ROM-u XEP-a, z tego co już mam wynika że rzeczywiście startuje w trybie "10 linii/wiersz" i dopiero później się przełącza.

Przełączanie PAL/NTSC już jest dodane w emulatorze.

Za pomocą firmowego drivera i komend XIO też powinno się to dać zrobić. Z XEP80.DOC wynika, że wysłanie do XEP80 komendy "Master Reset" (XIO 22,#1,12,194,"E:") powinno zresetować urządzenie do domyślnego trybu 60Hz; następnie wysłanie komendy "Modify Text to 50 Hz Operation" (XIO 20,#1,12,215,"E:") powinno przęłączyć XEP-a w tryb PAL.

Oczywiście to wszystko hipoteza, nie mam jak tego przetestować.

Nadal twierdzę, że nie masz racji, ale chyba wiem dlaczego. Wg XEP80.DOC ostatni wiersz ekranu nie jest normalnie dostępny dla edytora (nie można do niego dotrzeć przez Control+starzałki, nie podlega przewijaniu), ale można na nim pisać skacząc do niego bezpośrednio, np. POSITION 0,24:? "ABCD";:POSITION 0,0. Podejrzewam, że u Ciebie 25. wiersz był zawsze pusty i nie zauważyłeś jego istnienia.

EDIT: W międzyczasie dokopałem się do inną fotkę z PAL-owskiego XEP-a, który też pokazuje 12 skanlinii. Oprócz tego znalazłem u Jera ROM-y XEP80; jeden z nich zawiera zestaw znaków. Definicja każdego znaku składa się z 16 bajtów, z których zawsze tylko 12 pierwszych jest wypełnione. Oznacza to, że linie 11. i 12. znaku nie są duplikatami linii 10., lecz są zczytywane z zestawu znaków (co widać na ww. zdjęciu na przykładzie przecinka).

No dobra, wygląda na to, że XEP80 można przełączać pomiędzy trybami 10/12 linii na znak; informacja jakoby było to 11 linii jest najwyraźniej błędna (zapewne pochodzi ze specyfikacji chipa NS405, gdzie liczba 11 linii/znak jest podana, ale dotyczy czegoś trochę innego).

Ale numer. Rzeczywiście, 12 linii bez wątpnienia, dziękuję za zdjęcie.

To ja dyskusję na temat XEP80 przenoszę do osobnego wątku.