ZX+3 formatuje dyski tak samo jak w CPC tyle że o 2 dodatkowe ścieżki 40 i 41 więcej, co w CPC w niczym nie przeszkadza. Baaa nawet można to wykorzystać wpisując POKE &A8A8,255:POKE &A895,188 w przypadku stacji A, lub POKE &A8E8,255:POKE &A8D5,188 w przypadku stacji B.
Co sprawia że Amsdos widzi te 2 ścieżki czyli 9KB ekstra, jako dostępne dla komendy SAVE. Więc jeśli mamy już pełny dysk, a ilość nazw plików (64) jeszcze nie wykorzystaliśmy, to po sformatowaniu tych 2óch ścieżek i wpisaniu tych POKE-ów można wcisnąć na dysk jeszcze kilka KB. Aha najpierw trzeba wpisać CAT by rozpoznał format dyskietki, a potem te 2 POKE-i. Bo przed CAT nie będzie umiał rozpoznać że to dysk DATA.
Do odczytu nie potrzeba żadnych POKE, sam sobie znajdzie ten/te plik/i na dalszych ścieżkach.
Jeśli mamy gęsty napęd taki z 80 ścieżek, możemy pójść krok dalej i wykorzystać w identyczny sposób prawie 57 ścieżek, wpisując w 2go POKE 255 zamiast 188. Co da nam dysk DATA 254K. Nieźle co?
Czemu tylko 57 i czemu ostatnia z nich nie jest wykorzystana w pełni? Przez to że jednostka alokacji ma 1KB, a w katalogu jej numer jest jednobajtowy. Mamy 4,5K na ścieżce to łatwo policzyć.
Oczywiście wpierw te dalsze ścieżki muszą być sformatowane. Ale komenda SAVE tak średnio się nadaje do kopiowania plików innych niż Basicowe zwłaszcza gdy nie znamy ich numerów startowych. Można by się posiłkować komendami do kopiowania w RSX. Choć to ciągle nie to.
Ale skoro już mamy 80 ścieżek w stacji i Amsdosa, to można by zamiast zmieniać tego 2go POKE użyć taki POKE &A89D,40 To sprawi że ścieżki od 0 do 39 uzna za zarezerwowane, i od teraz katalog widzi na ścieżce 40 i kolejne jego sektory aż do ścieżki 79 to nasz nowy dysk 178K. Tak jakby drugi na tej samej stronie dyskietki.
W tym przypadku by widział katalog na ścieżce 40 trzeba wpisać POKE także do odczytu. Musiałbym napisać prosty program kopiujący pliki ze ścieżek 0-39 na te 40-79. Po czym te pierwsze kasujemy i mamy znowu wolne, a pliki z dalszych ścieżek mamy dostępne po POKE &A8A8,255:POKE &A89D,40 w przypadku stacji A, lub POKE &A8E8,255:POKE &A8DD,40 w stacji B. Natomiast sam ten pierwszy POKE gdy zamiast 255 wpiszemy 0, przywraca rozpoznawanie standardowych dysków czyli ścieżki 0-39.
Musiałbym kiedyś przysiąść i poszukać jeszcze POKE do programowego zmieniania strony dysku i zrobić elegancki programik co przerzuca pliki na te dalsze ścieżki, po czym wyświetla MENU z np 20ma grami na dysku 3.5" zamiast 5ma, które się zwykle maks mieszczą na stronie zwykłej 3". W zależności od tego w jakim rejonie dysku dana gra się mieści sam wpisuje właściwe POKE-i. Tak przygotowany dysk będzie się równie dobrze spisywał niezależnie od tego czy mamy zmienionego Amsdosa na coś innego czy nie. Trzeba by kiedyś przygotować kilka takich dysków, bo fajnie by było mieć wszystkie lepsze samochodówki, nawalanki, platformowki... itd. itp. na jednym takim tematycznym dysku, prawda?
Choć nie wszystkie gry, będą chodzić z tych dalszych ścieżek, a z demek to niemal żadne, ale mogą zostać na tych standardowych, a dalsze ścieżki na tych samych dyskach wykorzystać tak jak tu opisałem.
Natomiast by Amsdos widział dyski Paradosa (796K) lub PC-DOSa (720K), to trzeba wklepać aż kilkanaście POKE-ów, bo tam są inne numery sektorów, inna ich ilość, inne odstępy między nimi, oraz inna jednostka alokacji, ale o tym innym razem gdy znowu znajdę nieco słomy do mojego zapału.
Pod tym postem:
http://speccy.pl/forum/index.php/topic,844.msg14135.html#msg14135- dodałem dsk na którym jest RD.BAS który (łącznie z plikiem RAMDISK.BIN) daje dodatkowe komendy:
|FORMAT, |COPY, |TYPE, oraz |M co umożliwi formatowanie i kopiowanie plików w Basicu.
Programik sam po polsku na przykładach podpowiada składnię tych komend.
