Tak, taki kabelek powinien zadziałać.

Panowie, gdyby to trzeba było tylko przekonwertować, to bym nie miał problemu. Trzeba go jeszcze wyedytować - pododawać strzałki z wymiarami.

Ghostlink działa, ale ostatni raz spradzałem to w okolicach Win95/98. Ciekawym (i znacznie szybszym) rozwiązaniem jest też PARCP, ale wymaga innego kabla i nie mapuje dysków, lecz ma własny interfejs.

Z tym kabelkiem to nie wiem, ale na wyjściu słuchawkowym powinieneś mieć wszystko. Jest jeszcze kwestia matrycy połączeń, ale domyślnie wszystko jest włączone. Jeśli mimo wszystko jest nie tak - ktoś coś w tym Falconie grzebał i modyfikował.

Ściągij ze strony Draca źródła jego programów pod MiNTa - tam to jest.

Hddriver to cały pakiet który składa się z kilku programów, HD-Util to jego część, tak więc jest to nadal HD-driver. Co do obsługi - nikt wcześniej w wątku nie zająknął się o jaką dokładnie obsługę chodzi, tak więc semantycznie, logicznie i erystycznie jestem w prawie ;D

Zacznijmy od tego że wszyscy się mylicie ;)

HDDriver obsługę FATu ma po części, bo potrafi utworzyć takową partycję.
Używanie "TOS & Windows combined" nic nie pomoże. To jest specjalna opcja pozwalająca utworzyć dysk z pojedynczą partycją którą będzie mógł czytać i TOS i Windows, dzięki jakimś sztuczkom z tablicami partycji które portafi robić hdriver.

Aby dysk z PC był czytelny pod MiNTem, należy przede wszystkim włączyć dla niego w HDDriverze byteswapping. Następnie można podzielić go na partycje (z PCtową tablicą partycji), a potem najlepiej pod MiNTem utworzyć na tych partycjach systemy plików. Problem polega na tym, że aktualnie używane pod Linuksami programy mkfs.ext2 tworzą je z parametrami których MiNT nie obsługuje. W drugą stronę (tzn system plików założony pod MiNTem i czytany pod Linuksem) powinno być ok.

Co do byteswappngu, to nie tylko Atari ma z tym problem, i jest to po prostu dziura w specyfikacji ATA/ATAPI - każdy robi po swojemu.

Ja jakoś też przegapiłem, można się dopisać?

Bo Falcon ma obsługę 32 bitowego transferu :)

Dodatkowo odkryłem jedną nieudokumentowaną sprawę: rejestr pamięci do którego podpięty jest rejestr danych ATA, jest podpięty nie w jednym miejscu, ale rozciąga się aż (chyba, bo dokładnie nie sprawdzałem) do następnego rejestru sprzętowego. Dobrze kombinując z ASM można by było z tego zrobić taki tryb pseudo-DMA, ale nie wiem czy to tylko mój Falcon tak ma, czy wszystkie.

Candle: komunikacja TOS<->driver jest załatwiana przez
1) XHDI (specyfikacja dostępna do ściągnięcia z sieci, jest chyba na stronie HDDrivera)
2) tzw protokół rwabs - polega zasadniczo na podpięciu się w odpowiednich miejscach w systemie operacyjnym.

Zasadniczo lepsze jest używanie XHDI.

Dodam jeszcze że kiedyś napisałem podstawy sterownika IDE dla falcona (tzn miałem obsłużony odczyt/zapis i wykrywanie urządzeń) ale jako że jestem kiepski z assemblera (bo całość była w C) na tym się skończyło (tzn. nie miałem podpięcia do XHDI).

Dla ciekawskich: falcon odsługuje tylko tryby PIO i transfer raw miałem na poziomie 10MB/s (przy kodzie w C, zoptymalizowany ASM pewnie by dał rade jeszcze trochę wyżyłować).

Driver jest potrzebny bo jedyne co TOS potrafi zrobić to odczytać pierwszy sektor dysku (i to dopiero TOSy od 2.x) i zbootować się z niego. Odczytaniem reszty dysku (z podziałem na partycje) zajmuje się driver. TOS zleca mu odczyt/zapis sektorów a sam piluje takich spraw jak FS.

mnie pasuje 24 grudzień :)