Miło, że ktoś to wreszcie wyjaśnił we w miarę przystępny sposób.

Z wprowadzeniem tych klawiszy jest pewien kłopot - o ile pamiętam, standardowy OS w przypadku takiej nietypowej wartości w KBCODE, się wiesza.

Dokładniej, POKEY sprawdza stan każdego kolejnego klawisza co 1 skanlinię obrazu. Zaczyna od A = 3f, i co skanlinię sprawdza stan kolejnego klawisza: S = 3e, G = 3d, Caps = 3c itp.

A co tu można zmienić? POKEY sprawdza stan linii BSC (a raczej stan nóżki KR2) tylko w określonych momentach - raz sprawdza gdy aktualnie skanuje klawisz w 2. linii matrycy (wykrycie Break), raz w trakcie skanowania 6. linii matrycy (Shift) i raz w trakcie skanowania 8. linii matrycy (Control). W innych chwilach ta linia jest ignorowana.

"Upakowanie" to wynika w prostej linii z faktu, że przeskanowanie całej matrycy zajmuje 64 skanlinie czasu. Upakowanie będzie różne w zależności od tego, które grupy klawiszy są wciśnięte, ale cały cykl powtarza się co 64 skanlinie.

Nazywa się to key ghosting i można je zauważyć także bez wyłączania DEBOUNCE. Spróbujcie w BASICu nacisnąć naraz np. klawisze Control, K i 8, i powiedzcie czemu kursor przeskoczył do następnej linii :)

Akurat "tryb zwykły" to jest właśnie "tryb debounce" - w tym sensie, że w zwykłym trybie funkcja DEBOUNCE POKEY-a jest włączona ;)

Dodam jeszcze, że:
- Po wyłączeniu DEBOUNCE przerwanie klawiatury jest generowane nie tylko raz, po naciśnięciu klawisza, ale za każdym razem, gdy POKEY w trakcie skanowania matrycy natrafi na naciśniętą grupę klawiszy. Czyli np. gdy naciśnieta jest grupa AS, przerwanie leci co 64 skanlinie; gdy naciśnięte jest więcej grup - odpowiednio częściej. (zob. "Upakowanie") W każdym razie nie trzeba sprawdzać aktywnie stanu KBCODE - wystarczy przechwytywać IRQ klawiatury.
- Ficzer był wykorzystany w konsoli 5200, gdzie konstrukcja joysticków (naciśnięcie każdego klawisza powoduje de facto zwarcie 2 sąsiednich punktów na matrycy POKEY-a) zniosła wymóg naciskania "grup klawiszy". OS 5200 domyślnie wyłącza DEBOUNCE i mamy za darmo wykrywanie wielu klawiszy joysticka naciśniętych naraz (aczkolwiek nie wszystkich kombinacji :( ).

Pajero, na przyszłość zapisuj obrazki w PNG. JPEG nie nadaje się do rysunków schematycznych.

Na niektóre pytania odpowiedzi są w Resjestry POKEY-a oraz w dokumentacji
9. Wszystkie bity w IRQST poza 3. (XMTDONE) są zatrzaskowe. Tylko skasowanie danego bitu IRQEN powoduje zresetowanie odpowiedniego bitu w IRQST (poza bitem XMTDONE).
10. Tak, ale wyjątkiem znowu jest bit XMTDONE - nawet gdy przerwanie jest zablokowane, jego wartość może zostać przez POKEY zmieniona.

W 65C02 i następnych zostało to poprawione, zatem wg twórców był to błąd.

Ten z trójkątnymi przyciskami to Cheetah Marketing Mach1+, a ten drugi to Cheetach 125+ - ale w Polsce chyba były dostępne tylko podróbki no name (na Jacquesa zdjęciu widać, że oba pudełka są "podróbkowe").

Sam miałem 2 joysticki 125+; niestety brat je kiedyś komuś pożyczył i słuch o nich zaginął. Ma ktoś z was jednego (albo dwa) na sprzedaż?

Dobre!

Na wkładkach w moim posiadaniu nie ma słówka CNTR, i czcionki są inne. Były dwie rewizje? ;)

Przecież mój dump ma dokładnie takie parametry. Zapewne użyłeś a8cas-convert z domyślnymi parametrami. Ustaw --stop-bit-deviation=0.1.

Automatu który bezbłędnie skonwertuje wszystkie taśmy _bez ingerencji użytkownika_ stworzyć się nie da. Ja u siebie rozwiązałem problem tak, że w szczególnie wrednych przypadkach użytkownik będzie musiał dostroić parę parametrów.

Wieczorkiem.

A co to będzie?

Wiesz co? Sprawa jest śliska. Skoro do odtworzenia oryginału jest to zbędne, to można by przyjąć założenie, że ta informacja nie powinna być w pliku CAS. Proponuję taką "granicę abstrakcji": w pliku CAS znajdują się tylko informacje niezbędne do odtworzenia oryginalnej kasety (można wtedy się kłócić, czy opisy w blokach FUJI są zgodne z tym podejściem, ale na razie to pominę). Taka granica jest w jakiś sposób naturalna.

Poza tym, emulator i tak musi sam podjąć decyzję, jak interpretować dane z taśmy. Mamy przecież taki przypadek użycia:
- kaseta nagrana w Turbo A
- magnetofony w Turbo A tłumaczą zbocze opadające na sygnał 1 DATA_IN
- user wczytuję kasetę na magnetofonie dla Turbo B i oprogramowaniu, które pozwala na magnetofonie Turbo B wczytywać programy z kaset w Turbo A
- magnetofony w Turbo B tłumaczą zbocze opadające na sygnał 0 DATA_IN
Wtedy bit sugestii w CAS jest nie tylko niepotrzebny, ale i dezorientujący.

Z jakichś powodów technicznych jeszcze tego nie zrobiłem - ale jakby co, to chcę po prostu usunąć informację o długościach bloków z formatu HEX (czyli drugą liczbę z linii "data" i "fsk "). A co sobie każdy z nas będzie zrzucać do komentarzy, to już oczywiście bez znaczenia. Acha, i znak komentarza ";" ma nie być wymagany, jeśli komentarza nie ma w ogóle.

Rozumiem że zmiana polegała wyłącznie na zdefiniowaniu parametrów (częstotliwości, długości) tego turba? Ciekaw jestem, czy nie dałoby się tego jakoś zautomatyzować.

EDIT: Już. Konwertujemy z --stop-bit-deviation=0.3.

A bo nie zrobiłem nic spektakularnego, czym możnaby się pochwalić.

Dziś natomiast wypuściłem wersję 1.1, z dodaną możliwością dostrajania parametrów konwersji WAV->CAS z poziomu wiersza poleceń. Zostało to wymuszone przez jedną wredną kasetkę o nazwie Miecze Valdgira 2. Jest ona zabezpieczona za pomocą rekordów, w których środku zmieniany jest baudrate! Żeby poprawnie obsługiwać takie rekordy, musiałem przepisać na nowo spory kawałek kodu.

To chyba będzie wymagać rozszerzenia RAM.

Gdzieś ktoś pisał.

A do sprawdzenia że DOS się załadował, to nie wystarczy sprawdzić flagi BOOT? ($09) ?

!00% wykrywalność błędów by wystarczyła :)

Racja. Niech blok będzie wyglądał tak: FUJI <nazwa>
Sądzę że nie ma potrzeby zapisywania długości bloku, tak jak w blokach "data" / "fsk ". Prawdę mówiąc, noszę się z zamiarem usunięcia zapisywania długości także z bloków "data"/"fsk ", i przeniesienia tej wartości do komentarza na końcu linii (po ";"). Dzięki temu nie trzeba będzie pamiętać o zmianie długości bloku w przypadku ręcznego poprawiania HEX-a. Masz coś przeciwko?

Jak działa nie gorzej niż w "oryginalnym" Atari800, to jest dobrze. Może Spy vs Spy ma custom loader albo jakieś zabezpieczenie. Widziałem w Green Beret takie coś: po wczytaniu program sprawdza wartość RTCLOCK - jeśli jest za mała (gra z patchem wczytuje się parę sekund, więc wartość wychodzi za mała), to wpada w nieskończoną pętlę. Moze w SVS też coś namieszali - w każdym razie dzięki.

A nawiasem mówiąc, Spy vs Spy to błędny dump - na końcu rekordów kończących części nagrania, znajdują się nadmiarowe śmieci. Nie przeszkadza to we wczytywaniu, ale ja jestem pedant. Dely, załączam poprawioną wersję CAS-a:
http://students.mimuw.edu.pl/~tk197881/ ... vs_spy.cas
Od dawna leży tam też poprawione Kissin' Kousins (wersja w TPP ma błędy):
http://students.mimuw.edu.pl/~tk197881/ ... ousins.cas

Przydają się, żeby zapisać IRG dłuższe niż 65,535 sek.

Masz magnet przerobiony na AST? Rób foty do Atariki! :)

Ale jak wczytywałem na emulatorze, to np. Tiger Attack wczytywał się z błędami przy polaryzacji "najpierw zbocze opadające, potem rosnące". Rozumiem że to błąd emulacji?

W AST to może i działa, ale pamiętam, że nierzadko zdarzało się, że program w BUT wczytywał się bez widocznych oznak błędu do samego końca, po czym program leciał w krzaki. Zupełnie jak Hacker pod emulatorem.

Liczę na to, że w którymś momencie konwersja do CAS będzie potrafiła przynajmniej pokazywać miejsca, gdzie dane nie są 100% pewne. Wtedy będzie można zajrzeć do WAVa oczami :) i odgadnąć właściwe dane.

Nie rozumiem. Czy chcesz przez to powiedzieć że obrazy WAV które posiadasz są nieprawidłowo zgrane? Zawierają inne dane niż fizyczne kasety?

Wiesz w którym miejscu? Możesz podać numer sampla? Przyjrzę się temu dokładniej.

Blinky ma jakiś custom loader, więc to prawdopodobne.

Dzięki za przekonwertowanie plików, zajmę się nimi i tym Humanoidem jak będę miał czas. Na razie chcę się skupić bardziej na dokończeniu feature'ów dot. wczytywania w normalu (SIO patch itp.)

EDIT: A oto i nowa wersja A8CAS. Nowości:
- obsługa SIO patcha do wczytywania i zapisu kaset (na razie tylko w formatach CAS i HEX);
- obsługa WAV-ów z falą prostokątną;
- nowa opcja "Turbo system->Blizzard".

FUJI, weź zobacz czy nowa wersja działa z blokami "data" długości 0. Wygląda na to że poprawiłem, ale to Ty ten błąd znalazłeś :)

Poza tym, wrzuciłem na serwer kilka nowych plików AST. Miłej zabawy ;)

Dzięki. Aczkolwiek efekt jest dla mnie raczej bezużyteczny - chodziło mi o to, żeby mieć w ręku plik BUT ze 100% zweryfikowaną zawartością, który ładuje się poprawnie pod emulatorem, żeby na jego podstawie usprawnić proces wczytywania oryginalnego WAV-a. Teraz w sumie mogę sam go sobie przygotować, bo po ostatniej aktualizacji a8cas-tool zaczął działać bez problemu.

Brak weryfikacji podczas odczytu to jedna z bolączek systemu AST.

Trochę się zmieniło od tamtego czasu - dorobiłem coś na kształt twojego latch - zmiana sygnału wykrywana jest dopiero gdy różnica między kolejnymi samplami jest większa niż "x" (konfigurowane przez użytkownika). Jednak efekty są nadal mierne - o ile pozwala to czytać AST oraz "prostokątnego" Blizzarda, to w przypadku Blizzardowych WAV-ów jitter jest nadal za duży (bo Blizzard ma krótsze impulsy niż AST). Muszę wymyślić mniej naiwne rozwiązanie. Aczkolwiek chcę uniknąć odwołać do ecasound i ladspa w źródłach liba8cas.

Prawdopodobnie skończy się to tak, że użytkownik będzie najpierw konwertował WAV do pliku CAS (podczas zapisu do CAS można dokonać bardziej dokładnej analizy) i używał emulatora tylko z CAS-ami, a wczytywanie z WAV-ów pozostanie kiepawe.