Właśnie udało mi się całe slave.com (a ściślej nie program, tylko to co on robi) upchnąć w ROM-ie interfejsu. Z ta wersją ROM-u podpięcie - i odpięcie - dysku slave nie będzie wymagać żadnych wygibasów, wystarczy reset (albo media change).

Przyznam, że dość długo dumałem nad tym twoim zdaniem i im dłużej o tym myślę, tym bardziej jestem pewien, że ja nie tyle byłem niechętny do współpracy, co po prostu poprosiłem Lizarda, żeby udzielił ci wszelkich informacji. Ale może pamięć mnie zawodzi. Faktem jest natomiast, że przez kilka lat - jakieś sześć ostatnich - nic już nie robiłem na ośmiobitowym Atari i nie zanosiło się, bym do tego wrócił ...

To się prosi o sprostowanie. Dysk do adresowania LBA nie potrzebuje 80 przewodowej taśmy. Takie taśmy przeznaczone są do współpracy z dyskami pracującymi w trybie Ultra ATA od 100 w górę. Dodatkowe przewody nie przenoszą żadnych sygnałów, robią tylko za ekran i są połączone z masą. Złącze jest przecież ciągle takie samo -  40 stykowe. Dodatkowe bity adresujące numer logicznego sektora nie mają nic wspólnego z dodatkowymi liniami w kablu. Wszystko dzieje się na poziomie rejestrów kontrolera. W 48 bitowym LBA rejestry kontrolera określające adres są zorganizowane jako dwubajtowe FIFO, mieszczące w sobie 16 bitową liczbę, której starsze 8 bitów jest określone przez pierwszy wpis do rejestru, a młodsze 8 bitów przez drugi. Kolejny (trzeci) wpis do rejestru powoduje utratę pierwszego i przesunięcie drugiego na pozycję dotychczas zajmowaną przez pierwszy.
Po trzecim zapisie sytuacja wygląda zatem tak, że młodsze 8 bitów określone jest przez trzeci wpis, a starsze 8 bitów przez drugi.
Znaczenie rejestrów jest nastepujące: (adresy podane dla interfejsu KMK/JZ):

$d112 (sector count) - liczba sektorów do odczytu (bity 0...15)
$d113 (sector number) LBA bity 0...7 (ostatni wpis) i 24...31 (poprzedni wpis)
$d114 (cylinder low) LBA bity 8...15 i 32...39
$d115 (cylinder high) LBA bity 16...23 i 40...47

$d116 (device/head - bez FIFO - pojedynczy zapis)
bity 0...3 - nie używany
bit4 (DEV) - wybór dysku
bit5 - nie używany
bit6 (LBA) - ustawiony oznacza tryb LBA
bit7 - nie używany

Mam nadzieję, że wyjaśnienie jest wystarczająco czytelne. ;-)

Coś się wymyśli, np. do adresowania 4 najstarszych bitów ( 24 - 28 ) użyłem bitów B3-B0 w bajcie statusu bloku DCB ($0303) - kontroler i tak patrzy tylko na 7 bit - B7=1 - zapis, B7=0 - odczyt a w pozostałych urządzeniach - np. jakaś FDD niema 28 bitowegoi adresowania. Zresztą HiDOS i tak sam bezpośrednio odwołuje się do rejestrów kontrolera, więc chyba niezgrzeszyłem, a z blokiem PERCOM - przyznaję - o tym zapomniałem coś wymyślę, jeśli nie, to zostanie 8GB, ale może jednak... zaraz w chacie bede myślał. Podobnie jest z blokiem IOCB - instrukcje NOTE i POINT mają ograniczenie takie samo jak w SpartaDOS'ie, a używając bezpośrednio procedur CIO wchodzących w HiDOS niema ograniczeń - pełne 32-bitowe adresowanie - max. rozmiar pliku to 4GB, katalog również jest traktowany jak plik, więc i on też ma ograniczenie długości do 4GB, co daje ok. 134 milionów wpisów na jeden podkatalog - 4GB / 32 bajty dla pojedynczego wpisu daje dokładnie 134,217,728 wpisów. Cóż - Lizard mówił bez ograniczeń - to proszę bardzo - ja chciałem zrobić do ok. 65,536 wpisów z numeracją, ale na żądania Lizarda numeracja znikła i ograniczenie też

a po co ma sie marnować ? Skoro można ją wykożystać?

Tego że poprzez CHS można zaadresować więcej niż 8GB niewiedziałem - bynajmnioej tak wynikało z posiadanej dokumentacji którą posiadam (150MB w pdf-ach), jednak moge się mylić... Tak samo jest z wykożystywaniem 80-żyłowego kabla. Do tej pory myślałem że transfer przyspiesza, bo wykożystuje dodatkowe linie, a to że one służą jako erkran  :? przyznaję niewiedziałem...

owszem - to w 48-bitowym adresowaniu. A w 28bitowym (bez FIFO) bity 0...3 tego rejestru zapisują bity 24...28 odnośnie numeru sektora.
Ponadto bity, które za tu przedstawioe jako nieużywane, winny być ustawione, ale niemam pojęcia czemu. DEV (=0 - MASTER, =1 - SLAVE)

Mam też poytanie - gdyż doczytałem w posiadanej dokumentacji co do zapisu FIFO (w dokumentacji określono to jako HUB:1 i HUB:0) - czy aby zaadresować LBA w 48 bitach w podany wyżej sposób (FIFO) jest konieczna przeróbka sprzętowa interfejsu KMK/JŻ czy też to też jest ograniczenie programowe?

Jeśli trzeba, to tabele partycji moge przyszykować do 64 bitów - lecz zrobiłem tak, aby zachować 100% zgodność z istniejącymi wersjami biosu
Reszta jest do przemyślenia - bede myślał jak mi komp z naprawy wróci - ma wrócić na początku listopada - znalazł się elektronik, który zrobi mi ram (niech bozia w dzieciach mu to wybagrodzi) :D

Zapomniałem o jednym: PERCOM ma oczywiście jeszcze liczbę ścieżek (bajt 0). Co prawda wtedy formatter SpartaDOS-u zgłupieje, ale dla dysków powyżej 16 MB i tak jest bezuzyteczny ...

Przeróbka nie jest konieczna, ale zobaczymy, czy komukolwiek potrzebna będzie obsługa dysków ponad 128GB.

Zdaje się, że ograniczenie do 1423 wpisów katalogu w Sparcie wynika z tego, że katalog może mieć tylko jeden sektor na mapę. W sumie racja, że jeśli katalog ma być plikiem, to dlaczego mapa ma mieć tylko 1 sektor.

1424*23=32752
32752/256=127,9375 sektora

W jednym sektorze mapy pliku (katalogu) mieści się informacja o 126 sektorach, więc mapa katalogu może zająć maksymalnie dwa sektory. Nadal utrzymuję, że ograniczeniem jest wielkość katalogu do 32kB.

Ja zawsze mam rację, tylko nikt mne nie słucha. :evil: