1

Temat: filesystem dla atr i ataridos

Proudly presents dwa narzędzia dla Linuxa/Unixa pozwalające na pracę z obrazami dyskietek kompatybilnymi z Atari DOS.
Są to dwa filesystemy zaimplementowane z użyciem biblioteki FUSE.

1. ATRFS
Pozwala na zamontowanie obrazu dysku ATR (w wersji APE lub SIO2PC) jako ciągły plik w filesystemie.

$ atrfs exemplum.atr mountpoint

Rozpoznaje to oczywiście rodzaj atra, a za pomocą opcji można go zmusić do traktowania sektorów 1..3 dysku DD jako 256b (zazwyczaj samo się zorientuje że ma taki obraz).

2. ATARIDOSFS
Pozwala na zamontowanie pliku z obrazem dysku (np. partycji dysku Atari XL/XE w przyszłości, lub pliku udostępnianego przez ATRFS) z systemem plików kompatybilnym z Atari DOS:
- Atari DOS 1,
- Atari DOS 2,
- Atari DOS 2.5,
- My DOS.

$ ataridosfs image mountpoint

Tutaj też detekcja następuje samoczynnie, ale parametrem -o dos można wymusić konkretny rodzaj DOSa (zazwyczaj niepotrzebne).
Po zamontowaniu w mountpoint pojawia się struktura katalogów tak, jak ją widać na Atari. Można kopiować pliki, tworzyć katalogi, usuwać, zmieniać nazwy, zabezpieczać pliki/katalogi, przesuwać aż do chwili kiedy skończy się miejsce na obrazie.

Ponieważ to wersja prealfabeta to należy uważać z wielodostępem, bo prawdopodobnie skaszani dysk.

Instalacja
Należy dociągnąć pakiety:
- libfuse-dev
- fuse-utils
np za pomocą:

$ sudo apt-get install libfuse-dev fuse-utils

oraz wykonać:

$ mkdir atari8fs-0.3
$ cd atari8fs-0.3
$ wget http://mono.i-demo.pl/fuse/atari8fs-0.3.tar.gz
$ tar zxf atari8fs-0.3.tar.gz
$ make clean all install

Paczka dostępna tutaj.

Enjoy i send bugs&requests please.

P.S. Jak tego użyć z konkretnym atrem, żeby mieć pliki w katalogu widzianym przez system:

$ mkdir images ataridisk
$ atrfs exemplum.atr images
$ ataridosfs images/exemplum ataridisk  

i w ataridisk są pliczki.
Koniec pracy:

$ fusermount -u ataridisk
$ fusermount -u images
$ rmdir ataridisk images

UWAGA miłośnicy okienek
Pliki można sobie kopiować dowolnym okienkowym managerem. Wcale NIE TRZEBA używać konsoli i cp, mv, truncate, rm, mkdir, rmdir, stat.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

2

Odp: filesystem dla atr i ataridos

Instalacja dla FreeBSD:

1) cd /usr/ports/sysutils/fusefs-kmod

2) su

3) make && make install

4) kldload /usr/local/modules/fuse.ko

5) ctrl/d

a dalej jak powyżej, mkdir atari8fs itd.

PS. czekamy na moduł obsługujący FS Sparty :)

Ostatnio edytowany przez drac030 (2011-10-22 17:15:10)

KMK
? HEX$(6670358)

3

Odp: filesystem dla atr i ataridos

Skoro apt-get to i paczkę (deba) mógłbyś zrobić... :)

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

4

Odp: filesystem dla atr i ataridos

@Amun-Ra: Zbadam temat. Póki co na własną rękę można użyć checkinstall i podać odpowiednie dane.
@drac030: Dzięki za procedurę instalacji. FS dla Sparty w planach :)

Czy znalazłby się ktoś, kto przetłumaczyłby na języki obce (w tym en) README i *.man (będą w następnej wersji)?

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

5

Odp: filesystem dla atr i ataridos

Co robi pierwszy program?

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

6

Odp: filesystem dla atr i ataridos

Plan jest taki, żeby atari8fs składało się z:
- modułu kernela obsługującego tablicę partycji APT i udostępniającego w systemie partycje Atari z CF/SD/MMC/HDD,
- filesystemów ataridosfs i spartadosfs obsługujących konkretne FSy Atari,
- filesystemów atrfs, dcmfs, xfdfs, profs (zacząłem od najpopularniejszego) montujących obrazy dysków dostępnych w plikach o wymienionych formatach w takiej postaci, jak będzie ją udostępniał kernel obsługujący APT.
Tak więc atrfs służy tylko do udostępnienia obrazu dyskietki zapisanej w formacie .ATR, jako ciągłego pliku (może nie powinien to być FS - liczę na jakieś sugestie) i udostępnia w strukturze stat informację o parametrach "nośnika". Sam ataridosfs (a w przyszłości również spartadosfs) ma korzystać z gołego ciągłego pliku. Najlepiej gdyby działało to tak, jak montuje się obrazy .img (loop), ale póki co nie wiem jak to działa i muszę się naumieć.
Te FSy można by zaimplementować jako moduły kernela, ale wybrałem FUSE bo gdyby ktoś w przyszłości napisał jego implementację dla windowsa (+ obsługę APT), to mogłoby to działać też i tam.

Edit: Może się okazać, że FUSE nie było dobrym pomysłem dlatego kod jest napisany w C, żeby można było łatwiej go wsadzić do modułu kernela.

Edit 2: Potem można by też zdefiniować reguły dla udeva do automatycznego montowania zasobów z Atari z nośników wymiennych - wtedy user nie musiałby już kompletnie nic robić z linii poleceń.

Ostatnio edytowany przez mono (2011-10-24 15:16:18)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

7

Odp: filesystem dla atr i ataridos

mono napisał/a:

Plan jest taki, żeby atari8fs składało się z:
- filesystemów ataridosfs i spartadosfs obsługujących konkretne FSy Atari,
- filesystemów atrfs, dcmfs, xfdfs, profs (zacząłem od najpopularniejszego)

Robię coś podobnego. Z racji użytego języka (Python) moduł odpada. Ale od tego w sumie jest fuse.

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

8

Odp: filesystem dla atr i ataridos

Co to APT i ciągły plik?

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

9

Odp: filesystem dla atr i ataridos

APT: http://drac030.krap.pl/APT_spec.pdf
Ciągły plik to zwykły regularny plik - kernel udostępnia zaś widziane partycje, jako urządzenia w strukturze /dev/.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

10

Odp: filesystem dla atr i ataridos

Zgłaszałem już swoje uwagi autorowi, ale skoro program jest dostępny publicznie, to niech i uwagi będą.
To powinna być biblioteka w Ć, żeby było łatwo dołączać ją do innych programów w różnych językach. Montowanie z FUSE lub kernelem to bardzo szczególny przypadek, tak samo zły, jak graficzny interfejs usera w MakeATR czy pluginie do TC. Obsługa obrazów i filesystemów ma już bazylion implementacji, w każdej inne błędy i ograniczenia. Tymczasem mogłaby siedzieć w bibliotece, zakodowana raz a dobrze, i nie byłoby problemu ze zrobieniem z tego narzędzia obsługiwanego z wiersza poleceń, z interfejsem graficznym, jako elementu emulatora komputera lub stacji dysków, wtyczek do obsługi archiwów, systemów plików, etc., omg., wtf.
Jeśli chciałbyś to zrobić w ten sposób, to chętnie pomogę w kodowaniu i/lub testowaniu.

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

11

Odp: filesystem dla atr i ataridos

@epi: Masz rację. I dałoby się to bez problemu zrobić. Po prostu zacząłem to robić w C i tak już zostało :P Warto to zrefaktorować do Ć.
A jak tam z działaniem Ć we FreeBSD?

Edit: A kod na pewno będzie refaktorowany.

Ostatnio edytowany przez mono (2011-10-24 16:25:19)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

12

Odp: filesystem dla atr i ataridos

Czemu akurat miałoby nie działać we FreeBSD? Jak jest mono, to translator zadziała. Od tego momentu masz kod w C/Javie/(lub innym języku), a z tym chyba nawet we FreeBSD sobie umiesz poradzić, nie? ;)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

13

Odp: filesystem dla atr i ataridos

Ja nie umiem :) Ale znam kogoś, kto potrafi :P.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

14

Odp: filesystem dla atr i ataridos

Po ponad 6 latach możnaby z tym ruszyć ;) Ja jestem starej szkoły i proponuję zacząć od analizy i projektu w wiki (np. Trac jak w przypadku FAIL), zamiast szybko coś naklepać a potem refaktoryzować.

Ostatnio edytowany przez Fox (2011-10-24 17:25:06)

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

15

Odp: filesystem dla atr i ataridos

Kiedyś zacząłem dłubać Kolejną Zabugowaną i Niedokończoną Implementację Obsługi Obrazów I Filesystemów (tm), więc z pewną nieśmiałością proponuję wykorzystać miejsce, w którym siedzi ona obecnie, do zebrania sił i zrobienia czegoś nowego. Wiki jest tutaj: https://github.com/epi/xedisk/wiki

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

16

Odp: filesystem dla atr i ataridos

ten konkretny temat to nie calkiem to o co mi chodzilo ale moze przerodzi sie w cos na czym mi zalezy ... wiec tak niesmialo dodam, ze aby uszczesliwic usera to oprocz operacji na plikach jednak zapis i odczyt sektora tez byl.

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

17

Odp: filesystem dla atr i ataridos

epi napisał/a:

Tymczasem mogłaby siedzieć w bibliotece, zakodowana raz a dobrze, i nie byłoby problemu ze zrobieniem z tego narzędzia obsługiwanego z wiersza poleceń, z interfejsem graficznym, jako elementu emulatora komputera lub stacji dysków, wtyczek do obsługi archiwów, systemów plików, etc., omg., wtf.

Epi, ale po co komu "wtyczka do obsługi archiwów", "narzędzie z interfejsem graficznym" albo "obsługiwane z wiersza poleceń"? To co napisał mono likwiduje zapotrzebowanie na dedykowane narzędzia tego typu, bo przecież celem tego wszystkiego jest możliwość skopiowania danych na i z ATR-a (oraz ewentualnie innych typów obrazów), tudzież na rzeczywisty dysk Atari i z takowego. Fuse i programy mono pozwalają to zrobić przy użyciu ogólnych file managerów (np. cp & spółki, mc, desktopów pod X11) - więc żaden makeATR, franny itp. ani pluginy jakiekolwiek nie są już potrzebne.

Co do emulatorów, pewnie taka biblioteka by się im przydała, tylko - ile powstaje nowych emulatorów rocznie?

KMK
? HEX$(6670358)

18

Odp: filesystem dla atr i ataridos

xxl: To akurat jest najławiej zrobić.
drac030: No jasne, tylko trzeba jeszcze zamontować przed i odmontować po - jak pokazał mono, sześć dodatkowych poleceń do wykonania. Czasem możesz użyć skryptu, czasem nie. Czasem masz system, dla którego FUSE nie istnieje, np. Windows.
IMHO to niepotrzebne komplikowanie, skoro wystarczy otworzyć plik i wyciągnąć z niego lub zmienić w nim trochę bajtów. Jednym z "front-end"-ów takiej biblioteki może być również program używający FUSE, więc nic nie tracisz.

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

19

Odp: filesystem dla atr i ataridos

> To co napisał mono likwiduje zapotrzebowanie na dedykowane narzędzia tego typu, bo przecież celem tego wszystkiego jest możliwość skopiowania danych na i z ATR-a (oraz ewentualnie innych typów obrazów), tudzież na rzeczywisty dysk Atari i z takowego.

wystarczy sprobowac skopiowac na taki dysk kilka gier oraz inicjalizer i okaze sie ze jest to niemozliwe.

napisalem, ze ten program nie calkiem odpowiada moim potrzebom ale licze na to ze Mono spojrzy na temat oczyma Epiego i Foxa.

@epi: nie mowie ze trudne, napisalem tylko czego potrzeba zeby narzad byl uniwersalny.

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

20

Odp: filesystem dla atr i ataridos

epi napisał/a:

drac030: No jasne, tylko trzeba jeszcze zamontować przed i odmontować po - jak pokazał mono, sześć dodatkowych poleceń do wykonania.

Primo, nie sześć, jeno trzy: 2 x mount, 1 x umount.

Secundo: zgodzę się, że "2x mount" jest kłopotliwe i należałoby je uprościć przez redukcję do 1 polecenia. Można do tego ułożyć skrypt, który będzie konkretnie montował obrazy dyskietek, bez ruszania reszty funkcji. Bo docelowo, gdy chodzi o rzeczywisty dysk, pierwszy mount odpada.

Czasem możesz użyć skryptu, czasem nie.

Ale ja szczerze mówiąc w ogóle nie rozumiem tych obiekcji, przecież postępowanie z tymi obrazami pod Fuse jest (prawie) dokładnie takie samo, jak z flopami, CD-ROM-ami i cokolwiek się pod Unixem montuje. Czy to taka różnica, montować z /dev a montować z innego katalogu?

Czasem masz system, dla którego FUSE nie istnieje, np. Windows.

No wybacz, ale co to jest za argument ;) Niech Microsoft zrobi.

IMHO to niepotrzebne komplikowanie, skoro wystarczy otworzyć plik i wyciągnąć z niego lub zmienić w nim trochę bajtów.

A moim zdaniem to jest właśnie uproszczenie. Oddzielny program (typu franny) będzie po prostu bardziej upierdliwy w użyciu (jak bardzo, można łatwo sprawdzić używając zdalnie scp :P ). No i tu faktycznie masz 'n' nowych poleceń więcej, bo wszystkie czynności na systemie plików (ls, cp, rm, mv, chmod, i co tam się komu jeszcze zamarzy) musisz robić specjalnymi poleceniami, wpisując pewno jakieś opcje w linii komend. A jak zechcesz użyć mc albo interfejsu graficznego, to ... wget http://napisz.se. Faktycznie, uproszczenie jak diabli.

Dalej nie widzę _konieczności_ przekształcania tego na bibliotekę.

Choć oczywiście, dla zabawy, czemu nie, ostatecznie wszystko tu robimy dla zabawy (przyjemnej i pożytecznej ;) ).

Jednym z "front-end"-ów takiej biblioteki może być również program używający FUSE, więc nic nie tracisz.

A nie wątpię. Tylko wątpię w sens wkładania dodatkowej pracy celem przekształcenia tego w taką bibliotekę.

Poza tym, znając życie, projekt utknie w połowie i nie będziemy mieli ani jednego ani drugiego. Więc optowałbym za tym, żeby autor sobie dalej spokojnie pracował wg własnej koncepcji, a jeśli znajdzie współpracownika w osobie np. epiego, który przekształci to wszystko w bibliotekę, to też dobrze, byle to nie blokowało postępów pierwszego z frontów.

xxl napisał/a:

wystarczy sprobowac skopiowac na taki dysk kilka gier oraz inicjalizer i okaze sie ze jest to niemozliwe.

Domyślam się, że chodzi ci o ten "inicjalizer". Otóż wkopiowanie takowego - tak jak to już napisał epi - jest przy obecnym rozwiązaniu nawet bardziej możliwe niż przez ową "bibliotekę"; bo tam trzeba byłoby do tego napisać program, a tu wystarczy skrypt.

Ostatnio edytowany przez drac030 (2011-10-24 21:47:00)

KMK
? HEX$(6670358)

21

Odp: filesystem dla atr i ataridos

> Domyślam się, że chodzi ci o ten "inicjalizer".

ten to znaczy ktory bo nie wiem.

> Można kopiować pliki, tworzyć katalogi, usuwać, zmieniać nazwy, zabezpieczać pliki/katalogi, przesuwać aż do chwili kiedy skończy się miejsce na obrazie.

do boot sektorow nie mozna zapisywac plikow. ale jesli jest inaczej prosze o przyklad. nie mozna manipulowac na katalogu - np. wkopiowac wlasny.

po co? jesli skupic sie na zwyklym kopiowaniu plikow z/do atr to faktycznie po nic. :-)

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

22

Odp: filesystem dla atr i ataridos

xxl napisał/a:

> Domyślam się, że chodzi ci o ten "inicjalizer".

ten to znaczy ktory bo nie wiem.

Przeczytaj własny post (nr 19), to się może dowiesz.

> Można kopiować pliki, tworzyć katalogi, usuwać, zmieniać nazwy, zabezpieczać pliki/katalogi, przesuwać aż do chwili kiedy skończy się miejsce na obrazie.

do boot sektorow nie mozna zapisywac plikow. ale jesli jest inaczej prosze o przyklad.

atrfs udostępnia plik ATR jako urządzenie blokowe ( FYPI: http://pl.wikipedia.org/wiki/Urz%C4%85dzenie_blokowe ), po to jest. Więc sektory tegoż są zapisywalne tak samo jak wszystkie inne sektory urządzeń blokowych.

nie mozna manipulowac na katalogu - np. wkopiowac wlasny.

po co? jesli skupic sie na zwyklym kopiowaniu plikow z/do atr to faktycznie po nic. :-)

Skoro po nic, to problem solved. W przeciwnym wypadku wydaje mi się, że albo pomyliłeś wątki, albo nie bardzo wiesz, o czym piszesz.

KMK
? HEX$(6670358)

23

Odp: filesystem dla atr i ataridos

Napisałem o sześciu poleceniach, odwołując się do postu nr 1. Proste narzędzie konsolowe może to zrobić w 1 poleceniu, bez pisania skryptów. Ponadto może przy robieniu jednego ATRa wydajność nie ma znaczenia, ale jak będziesz miał ich więcej, to zauważysz różnicę.
Łatwiej zrobić bibliotekę, niż przekonać M$. A nawet jak go przekonasz, to są inne platformy, na których ktoś mógłby chcieć się dobrać do obrazów dysków. Dobrze napisana biblioteka może się nawet skompilować z cc65 i uruchomić na małym Atari.
Rozumiem Twoje podejście i sam stosuję je wtedy gdy piszę program dla siebie lub dla kolegi. Mając jednak na względzie szersze grono użytkowników, proponuję prostą zasadę inżynierii oprogramowania, która mówi, że dodatkową pracę należy powierzyć programiście, a nie użytkownikowi - ten ostatni, jeśli w ogóle się jej podejmie, najczęściej wykona ją źle, a programista może to zrobić raz a dobrze. Ponadto napisanie biblioteki wymaga przemyślenia API, a to z dużym prawdopodobieństwem wpłynie dodatnio na jakość kodu i możliwości jego rozbudowy. Samo przekazanie wywołań między FUSE a biblioteką to zadanie na jedno piwo.

Ostatnio edytowany przez epi (2011-10-24 22:18:59)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

24

Odp: filesystem dla atr i ataridos

> Skoro po nic, to problem solved. W przeciwnym wypadku wydaje mi się, że albo pomyliłeś wątki, albo nie bardzo wiesz, o czym piszesz.

ten konkretny po nic ale jak wczesniej pisalem moze projekt przerodzi sie w cos co bedzie i mi uzyteczne :-)

mozliwe ze autor podejmie korzystna decyzje. trzy osoby maja uwagi a jedna jest zadowolona... ja bym sie zainteresowal 75% userow ;-)

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

25

Odp: filesystem dla atr i ataridos

Ponadto może przy robieniu jednego ATRa wydajność nie ma znaczenia, ale jak będziesz miał ich więcej, to zauważysz różnicę.

Zgodzę się, że przy generowaniu ATR-ów w większych liczbach nie można ręcznie montować i odmontowywać, ale to też da się załatwić w miarę prostym skryptem, którego ułożenie pewnie potrwa krócej niż wywrócenie istniejącego kodu do góry nogami.

Mając jednak na względzie szersze grono użytkowników, proponuję prostą zasadę inżynierii oprogramowania, która mówi, że dodatkową pracę należy powierzyć programiście, a nie użytkownikowi - ten ostatni, jeśli w ogóle się jej podejmie, najczęściej wykona ją źle, a programista może to zrobić raz a dobrze

W teorii zapewne masz rację, w praktyce obawiam się, że skończy się to "Kolejną Zabugowaną i Niedokończoną Implementacją Obsługi Obrazów I Filesystemów (tm)", tym razem w wersji Pro. Albo tak, jak skończyło się tu http://www.atari.org.pl/forum/viewtopic.php?id=3630, co przypomniał Fox.

trzy osoby maja uwagi a jedna jest zadowolona...

Tia, a z tych czterech osób dwie nawet nie widziały, jak to działa, a jedna z tych dwóch ewidentnie nawet nie ma o tym bladego wyobrażenia. Bezcenne.

Ostatnio edytowany przez drac030 (2011-10-24 22:35:54)

KMK
? HEX$(6670358)