kabelek mam na com1, tryb RI.. i coś nie mogę się dogadać.

winxp, fizyczny com (nie usbcoś_tam)

czyli co, bo nie widzę?

Teraz zwykle kabelki mają DSR.

Przypomniało mi się, że HIAS opisał kiedyś na AtariAge problem z sygnałem RING i z fizycznymi portami szeregowymi:
http://atariage.com/forums/topic/251089 … try3557722

Chodzi o to, że chip 16550 generuje "event" o akywnym sygnale RI nie w momencie jego narastania, ale opadania.
Kabelek SIO2PC w wersji RI ma podpiętą linię COMMAND właśnie do RI.
Narastające zbocze sygnału RI mówi nam, że za chwilę na linii DATA OUT pojawi się Command Frame.
"Nowy" RespeQt nie jest jednak "budzony" narastającym zboczem i ignoruje opadające zbocze, więc Twój kabelek nie działa...
(wersja RespeQt dla Linux-a i OSX-a stosuje "polling" i będzie działać z RI, natomiast wersja dla Windows jest "event driven" dla handshake-u CTS/DSR/RI).

Rozwiązanie:
Handshake: "NONE" lub "SOFTWARE"

Ciekawostka:
Z AspeQt i ze starszymi wersjami RespeQt Twój kabelek SIO2PC/RI będzie działał pod Windows ze względu na błąd w oprogramowaniu.
Zdarzenia związane ze stanem linii sygnałowych generowane są zarówno dla narastających, jak i dla opadających zboczy (z wyjątkiem wspomnianego sygnału RI z UART-em 16550).
Aktualna wersja RespeQt oczekując na Command Frame ignoruje notyfikacje o opadającym zboczu.

Błąd w starszych wersjach polegał na tym, że opadające zbocze powodowało, że AspeQt/RespeQt traktował wtedy dane na DATA OUT jako potencjalny Command Frame.
Następujący scenariusz kopiowania pliku z emulowanego dysku D2 (plik test.atr) na fizyczną dyskietkę w stacji D1 spowodowałby sformatowanie D2!
Błąd uaktywni się jeśli mamy kabelek SIO2PC w wersji CTS/DSR lub SIO2PC/USB w dowolnej wersji (CTS/DSR/RI).

Polecenie kopiowania pliku COPYME.BIN powoduje:
1) ATARI ustawia COMMAND LINE, żeby wysłać do D2 polecenie odczytu sektora dyskietki
2) Narastające zbocze sygnału "budzi" RespeQt, który odczytuje komendę odczytu sektora
3) RespeQt wysyła sektor do ATARI (nie przejmując się opadającym sygnałem Command Line)
3) ATARI odczytuje sektor dyskietki i znowu ustawia COMMAND LINE, tym razem, żeby wysłać do D1 polecenie zapisu sektora dyskietki
4) Narastające zbocze sygnału "budzi" RespeQt, który odczytuje komendę zapisu sektora, ale ponieważ adresowana jest ona do D1, więc ją ignoruje i czeka na kolejne zbocze sygnału.
5) BŁĄD!!! Opadające zbocze sygnału "budzi" RespeQt ponownie, który odczytuje dane wysyłane przez ATARI, traktując je jako Command Frame.
Tak naprawdę jest to Data Frame (przeznaczone dla dysku D1) zawierające sektor dykietki do zapisu.
W większości przypadków RespeQt stwierdzi, że nie zgadza się suma kontrolna i nic złego się nie wydarzy.
Jeśli jednak sektor danych przypadkowo zawierałby dane, które mogą zostać zinterpretowane jako Command Frame (np. 32 21 20 20 53) to tak się właśnie stanie.
W tym przypadku RespeQt wykona "komendę", czyli sformatuje ($21) dysk D2 ($32).

Dla kabelka SIO2PC/RI z UART-em 16550 problem jednak nie wystąpi, ponieważ dla każdej komendy SIO, AspeQt i starsze wersje RespeQt są "budzone" tylko raz.
Można by do kolejnej wersji RespeQt dołożyć handshake "RI (falling edge)", ale nie ma chyba takiej potrzeby, ponieważ Handshake: "NONE" powinien załatwić sprawę.

ATARI 65XE + SIO2BT

Rozumiem.
Jakbym wydał 50$ na licencję softu, to też bym chciał go dalej używać.

ATARI 65XE + SIO2BT

Dlaczego  xex'y wczytuje mi  z predkoscia 57600bps a atr'y tylko z 19200 ?
I polskie literki troche nie teges.. :)

Skoro Pin pisze publicznie, że wraca do APE, to chyba wydał ;)

Co do polskich liter, to nie mam pojęcia. Problem pojawił się chyba od wersji Qt 5.X (z Qt 4.X było wszystko OK).
Co do xex i 57600 - wytłumaczenie jest proste:
Dla plików XEX domyślnie włączony jest High-Speed Loader (można go wyłączyć w ustawieniach w zakładce emulacja).
Dla plików ATR nie. Albo musisz użyć spatchowanego OS-a, albo ATR z Hi-Speed loaderem.

ATARI 65XE + SIO2BT

Podsyłaj, zdam relacje z placu boju.

OK. To podsylam linka:
http://abbuc.de/~montezuma/RespeQt-r4-falling-edge.zip
Jak znajdziesz chwilkę, to przetestuj.
W załączniku screenshot pokazujący checkbox, który trzeba zaznaczyć.

Dzięki za cenną informację, będą zmiany w RespeQt ;)

ATARI 65XE + SIO2BT

Jest. W menu "Dysk" wybierz opcję "Nowy obraz dysku", potem zaznacz "Własny", wpisz liczbę 65535 sektorów i z listy rozwijalnej wybierz "512 B / sektor".

Da się nawet zrobić ATR-a o wielkości ~512 MB. :)

Dzięki za test.
A przy ustawieniu "NONE" nic się kompletnie nie dzieje?

Szybciej niż x3 się pewnie nie da, bo mamy opóźnienie związane z tym, że RespeQt "budzi się" opadającym zboczem Command Line.
W tym momencie Command Frame jest już dawno wysłany i RespeQt odczytuje dane z bufora. Mija więc trochę więcej czasu zanim odpowiedź RespeQt dotrze do ATARI (w porównaniu z sytuacją kiedy reagujemy na rosnące zbocze).
Czy z APE albo z AspeQt udało Ci się wyciągnąć więcej niż x3?

Co do "pierdzenia" po wieczny czas - w programie jest pętla w której RespeQt przełącza się (w przypadku problemów) pomiędzy ustawioną prędkością, a standardową 19200, próbując dostosować się do ATARI. Kiedyś RespeQt poddawał się po iluś tam próbach, ale ktoś zmienił to na pętlę nieskończoną.

ATARI 65XE + SIO2BT

W APE nie da się ustawić niczego w wersji custom. Są tam po prostu prędkości x1, x2, x3 i tyle.

Co do ustalania prędkości w momencie, gdy się to nie udaje to zrobił bym ten timeout jednak bo jedynym skutecznym sposobem na przerwanie tego stanu rzeczy jest reboot Atarki.

Jedna jeszcze rzecz BAARDZO by się przydała. SWAP ATR (chyba że jest a ja go tu nie widzę).

Miło też, że napędy kończą się na O:

EDIT:

Co do ustalanego ręcznie dzielnika: ustawienie nawet na 11 nie działa (czyli poniżej prędkości 3x sio). Sprawdzane na zaznaczonej opcji "opadającego", oraz "RI", oraz "NONE"

32MB faktycznie działa, trzeba pomęczyć teraz Pajero o obsługę tego we wtyczce do TC.