1

Mialbym propozycje do rozwazenia. Czy nie uwazacie, ze byloby fajnie miec oprocz standardowego directory na dysku, takze taki dodatkowy pozwalajacy na dlugie nazwy plikow i przechowywanie roznych innych informacji o nich, takich jak autor czy data powstania ?
Przydac mogloby sie to do roznych programow uzytkowych, np. przegladarek obrazkow czy odtwarzaczy muzyczek.

Np. SAPplayer na Atari Epiego moglby wykorzystywac takie dodatkowe directory, co byloby znacznie czytelniejsze dla uzytkownika.

Wyobrazam sobie, ze mogloby to byc rozwiazane jak nastepuje:
- w standardowej dyskietce mamy 4 sectory directory dla, w sumie, 64 plikow;
- pierwsze 2 to standardowe directory, tutaj nic nie zmieniamy, kolejne 2 to juz te "specjalne"; oznacza to, ze mozemy wykorzystac taka dyskietke, w ktrorej wypelnione sa tylko pierwsze dwa sektory directory, a pozostale 2 sa puste lub zawieraja zbedne dane;
- pierwsze kilka bajtow pierwszego sektora "specjalnego" directory zawiera jakis charakterystyczny ciag znakow mowiacy nam, ze mamy wlasnie z nim do czynienia (mozna zalozyc, ze zostanie opracowane kilka roznych formatow takich "specjalnych" directory);
- kolejne bajty to juz wlasciwe directory z pelnymi nazwami i innymi charekterystykami plikow obecnych na dysku, zgodnymi z danym formatem; to jak te dane zostana uporzadkowane zalezec juz bedzie od danego formatu;

Co wazne, moglibysmy przy pomocy dodatkowych programow przerabiac juz istniejace dyski ze zbiorami, oczywiscie tych, ktore spelnialyby wymog wolnych 2 ostatnich sektorow dorectory.
Tak przerobiony dysk nie czynilby zadnych komplikacji dla zwyklych dosow.
Oczywiscie istniaja ograniczenia takiego rozwiazania, a zwiazane jest to przede wszystkim z dostepnym obszarem pamieci dysku do wykorzystania.

1. directory ma 8 sektorow
2. jezeli podzielimy na pol, to te drugie directory bedzie mialo niewiele dluzsze nazwy od pierwszego (o 5 bajtow dluzsze)
3. nie pojdzie na twardzielu, sparta itd.
4. dos caspera mial cos takiego miec w sobie o ile pamietam i o ile ktos pamieta od tym dosie :)

3

64 pliki to juz czasami malo na tak krotkie pliki, jak fonty czy muzyka, a jeszcze to ciac?
Np. w DD w sektorach katalogu wykorzystuje sie tylko po 128 bajtow. Mozna wykorzystac reszte i miec np. 27 znakowe nazwy zamiast 11 znakowych (nie wiem skad Tavasco wyssal te +5).
Jesli chodzi o sapemu, niech lepiej czyta zwykly plik tekstowy - bedzie przenosnie.

https://www.youtube.com/watch?v=jofNR_WkoCE

> (nie wiem skad Tavasco wyssal te +5).

Nie bralem pod uwage sektorow 256, zeby bylo identycznie bez wzgl. na format (single, medium). Te +5, to bajty w drugim katalogu, ktorych nie bedziemy uzywac do statusu, adresu pierwszego sektora i dlugosci pliku.

5

Mialbym propozycje

a nie latwiej zamiast takiego karkolomnego sposobu poprostu zarezerwowac np. rozszerzenie .ico  :lol:  i np. program.act / program.ico i w pliku .ico. znajduje sie wszystko co chcesz autor itp. zadziala z kazdym dosem, "napiszesz se" multiprzegladarke albo filemastera i bedziesz szczesliwy, ktos inny wpadnie na pomysl ze .ico moze miec nie tylko plik ale rowniez podkatalog, urzadzenie a: b: ram :-) kolejny wymysli "okienkowa" nakladke na sparte albo mydosa i bedziemy w domu :-) hehe

http://atari.pl/hsc/ad.php?i=1.

6

Dzieki za odzew i przepraszam za pomylke w podaniu liczby sektorow zajmowanych przez directory.
Sprawa rozwiazania lokowania dlugich nazw na dysku jest moim zdaniem dosc istotna dla dobrego dzialania roznych uniwersalnych przegladarek, playerow, itp. uzytkow.
Co do pomyslu tworzenia plikow tekstowych (.ico) opisujacych kazdy plik oddzielnie, to wydaje mi sie, ze w zwiazku z ograniczona liczba miejsc na nazwy plikow na dysku, to nie ma szans powodzenia, ale to tylko moje zdanie.
Natomiast stworzenie globalnego rejestru pelnych nazw plikow na dyskietce, wraz z ewentualnymi dodatkowymi informacjami, i zapisanie go w osobnym pliku, to rozwiazanie bardzo, mysle, trafione.

Jeszcze jedna rzecz, nazwy wcale nie musialyby miec okreslonej liczby bajtow np. 27, ale tyle ile potrzebuja, a wiec mozna byloby zaoszczedzic sporo miejsca z tej przestrzeni dysku na dlugie wpisy nazw plikow.
Jesli chodzi o dyski SD, to chyba jednak 32 wpisy w directory powinny wystarczyc, natomiast w DD mozna byloby sprobowac wykorzystac te drugie polowki sektorow directory.

Programy wykorzystujace te drugie directory, wedlug mnie, powinny miec mozliwosc odczytywania takze tradycyjnego directory.

Przepraszam za chaos w poscie, ale pospiech...

7

A nie wiem, czy ktoś pamięta o czymś takim jak INICJALIZERY - np. SPEED 3.x albo nieśmiertelny MicroDos - tam "duży dir" mieścił się na początku dysq lub w niewykorzystanych sektorach directory i były jak najbardziej długie nazwy. Można było sobie wpisać np. MONTEZUMA`S REVENGE :D. Może mały comeback??? :P

I Ty zostaniesz big endianem...

8

Rowniez plugin .ATR do Total Commandera ma mozliwsc pokazywania plikiow z bardzo dlugimi nazwami  (komentarzami?), ale ja jeszcze nie widzialem tego w praktyce. :)

9

... że tak powiem pisałem (a może jeszcze to zrobie) filemanagera pod SDX/MyDOS i myślałem o zapisaniu długich nazw w osobnym pliku ... ,lecz po tym jak nie mogę się doczekać aż Lizard(lub/Epi) napisze mi jedną prockę bardzo mi potrzebną do ukończenia tegoż badziewia ciężko jest powiedzieć ile to jeszcze potrwa. Jak to wygląda - najlepiej wie chyba Lewis - widział to w Koceranach. Engine opiera się na okienkach w tr. txt + obsługa muszy, lub dowolnego urządzenia sterującego (Trakball, tablet, joy, etc...) - lecz całość ma sens WYŁĄCZNIE PRZY DOŚĆ SZYBKIM TWARDZIELU!!! (eee .. KMK?) (to się też tyczy długich nazw) - ..tak jak każdy system okienkowy, a szczególnie zważając, iż prog jest pisany przeze mnie ... zajmuje dużo miejsca i działa na granicy przyzwoitości - to jeśli chodzi o szybkość działania całości.
Ale przynalmniej ma jakiś design ... trochę windowy .. lecz jak sądzę większości to pewnie by nie przeszkadzało.
:D  :D  :D  :D

uważam, że w tym miejscu (z tego miejsca) liczą się przynajmniej dobre chęci - robie to na tyle na ile mi to wychodzi; czasem lepiej, czasem gorzej (czyli nie-lepiej) .. :D  :D

Kontakt: pin@usdk.pl

10

1. AFAIK BiboDOS 6.4 używał 256 bajtów na katalog (to dawno bylo więc mogę się mylić).
2. Co do plików z opisami plików to było to już kiedyś stosowane w czasach BBSów - descript.ion, index.lst itp zawierające po prostu parami:

FILENAME.EXT Dłuższa nazwa lepiej opisująca plik

Tak więc nie będzie to pierwsze takie rozwiązanie ;) Osobiście jestem za plikiem - wtedy można łatwo to poprawić dowolnym edytorem i nie będzie to zależne od DOSa.