Podłączenie do TV jest przez Composite Video czy RGB+CS, jeśli to drugie to jak wygląda sam sygnał Composite? Masz możliwość podpięcia pod monitor RGB+HV (SC-1224/Commodore 1084S)?

Sprawdzenie jest dość trudne, a działanie może zależeć od wersji TOSu. W jaki sposób chcesz sprawdzać poprawność działania mechanizmu detekcji zmiany dysku?

W TOSie 2.6 specyficzne zachowanie sygnału WP nie jest aż takie ważne. Atari ST nie wykorzystuje ani sygnału RD ani DC.

Drugie moje podejście do HxC - po modyfikacji (a właściwie poprawieniu błędu myfriendów) wyświetlacz OLED działa z HxC, Jeff w międzyczasie poprawił co nieco w obsłudze obrazów .ST i obecnie jest całkiem OK, choć nadal nieco wolniej niż prawdziwy flop :( Zdałem mu obszerny raport z "placu boju", więc jest nadzieja na dalsza poprawę. Ostatnio zareagował szybko.

Miałem problemy, bo najwyraźniej obraz znaleziony w necie był uszkodzony. Tym razem jest ok i działa na 2Mbit kości, razem z 2.06D.

Trudno ją nazwać współczesną ale da się ją kupić - A4-TECH X6-60D.

Próbowałem wgrać HxC i szybko się do niego zniechęciłem w pierwszym podejściu. Po pierwsze nie działa wyświetlacz OLED... tzn. działa i gdzieś w dziale o Amigach na forum HxC jest opisane, że trzeba zmienić jeden rezystor SMD na płytce wyświetlacza, ew. ustawić opóźnienie jego startu. W FF domyślnie takie ustawienie jest włączone, tu trzeba wejść do menu i je ustawić (bo plik konfiguracyjny jest binarny i nie można go sobie wyedytować na PC). Problem w tym jak wejść do menu, skoro wyświetlacz nie działa... ano trzeba podłączyć wyświetlacz tekstowy albo zrobić upgrade firmware i wtedy Gotek się zrestartuje i wyświetlacz będzie działał do kolejnego wyłączenia zasilania. Swoją droga to ustawiłem to opóźnienie, a i tak wyświetlacz się nie włączał. Drugi problem, ani wersja stabilna ani alfa 3.1.1.2a nie wyświetlała w ogóle obrazów .ST, tylko .HFE. Zdenerwowało mnie to na tyle, że wróciłem do FF (i straciłem licencję za 12€). Cała moja "przygoda" z HxC trwała około godziny... ale może jeszcze do niego wrócę.
Na obronę HxC muszę jednak napisać, że Jeff (autor) naprawił problem niewyświetlania plików .ST, a problem z OLED dotyczy tylko wyświetlaczy DIY-MORE (niestety te są najpopularniejsze) i jest winą ich producenta... myfriendy dały nie taki rezystor/kondensator i wyświetlacz pozostaje w stanie resetu przez prawie 3s od włączenia zasilania. Żeby działał poprawnie trzeba 100x zmniejszyć wartość rezystora R3 lub kondensatora C8 tworzących obwód RC układu resetującego. Najprościej wymienić R3 na 4k7 [472] lub 5k6 [562] (oryginalnie jest 560k [564]).

Przestrzegam, że zmieniając bootloader HxC na inny bezpowrotnie tracimy licencję na HxC. Teoretycznie na bootloader HxC można wgrać m.in. FlashFloppy ale są to buildy specjalnie pod HxC, oparte o stare wersje kodów źródłowych.

Mógłbym: http://www.atari.org.pl/forum/viewtopic.php?id=15042

Zajmuje się tym mikrokontroler HD6301V1 w klawiaturze. Nie wiadomo co siedzi w jego firmware.

Na wyjściu transoptorów szczelinowych jest coś co bardziej przypomina sinus niż prostokąt, dopiero komparatory formują z tego prostokąt, wyznaczając próg odcięcia (bardzo analogowy próg - konkretne napięcie). Ten przebieg prostokątny ciężko nazwać transmisją cyfrową, to po prostu przebieg prostokątny o zmiennej częstotliwości. W transmisji cyfrowej częstotliwość zazwyczaj jest stała. Tu nie są przesyłane żadne bity. To nie jest PWM, ani PDM...

Ciekawe czy dla Atari szerokość tych impulsów ma znaczenie? O ile odczyt nie jest realizowany przez przetwornik u=f(f) i trafia na ADC, wystarczy generować sygnał PDM (łatwiejszy do generowania, ze względu na stałą szerokość impulsów, a tylko różny czas przerwy). Zapewne "logika" patrzy tylko na zbocze narastające i przesunięcie fazowe pomiędzy dwoma sygnałami z pary.

ATMega wcale taka szybka nie jest, robiłem kiedyś na niej (328P @ 16MHz) generator sekwencji cyfrowych, a dokładnie to symulator sygnału czujnika położenia wału korbowego w silniku spalinowym - czyli coś bardzo podobnego, ale tylko jeden czujnik i szału z szybkością nie było. Oczywiście można stosować jakieś triki w stylu użycia SPI do generowania impulsów - wtedy jest dużo szybciej.

Zmierzam do tego, że każde przetwarzanie sygnału trwa, każda transmisja cyfrowa również.

Myszka PS/2 standardowo wysyła 100 ramek na sekundę, każda ramka to 3 bajty danych. Do każdego bajtu dochodzi nagłówek i stopka w ilości 3 bitów (czyli ramka ma 33 bity). Transmisja szeregowa, synchroniczna z zegarem 10kHz (czyli 5000bps). Zatem samo opóźnienie transmisji musi wynieść co najmniej 6,6ms.

P.S.
Zarówno PIC jak i ATMega to 8-bitowe procesory RISC, przy tym samym zegarze mają podobną wydajność... tyle, że PICe zwykle programowało się w assemblerze, a AVRy w C albo nawet C++ (ich assembler raczej nie zachęca do pisania w nim).

Adapter zrobiłem w/g opisu na tej stronie:
https://www.chzsoft.de/site/hardware/di … -atari-st/

Każdy adapter będzie miał jakiś tam lag, oryginalna myszka Atari była praktycznie analogowa, tu trzeba zdekodować ramkę i przekształcić ją na odpowiednią sekwencję impulsów - to musi trwać.

Wybrałem na ATMega8, bo akurat miałem taki w pudełku z częściami. Poza tym nie wymaga żadnych elementów zewnętrznych. Dałem gniazdo USB, zamiast PS/2 - wiele myszek USB jest dwusystemowa.