There is also this 3-sector-DOS ->link<- written by C.Strotmann several years ago. Do not know the memlo of this DOS. It supports multiple files (up to a max. of 8 files / only one dir. sector!), but loading/reading only...
ok. to jest wlasciwie wersja ostateczna, optymalizowac mozna pewnie jeszcze o pare bajtow ale to juz by byly uproszczenia...
to tyle jesli chodzi o minimalistyczny DOS:
- czytanie - zapis (do istniejacych plikow) - funkcja specjalna BINARY LOAD - funkcja specjalna POINT - dowolny format i gestosc dla filesystemu rodziny Atari DOS (MyDOS, BiboDOS, TopDOS) - MEMLO = $930 - DOS zajmuje $130 (304 bajty) - w calosci miesci sie w BOOT SECTORS - jesli BASIC wylaczony to automatycznie uruchamia plik "D:AUTORUN"
Ja tego nie rozumiem. dos w $130 bajtach, z (uproszczonym) zapisem, z binloaderem? Czad.
Jak czytam dowolny kod xxl-a - to go nijak nie rozumiem :)
Zapostulował bym jeszcze o dosa z możliwością zapisu do nieistniejącego pliku kosztem długości, nawet do $180. Wówczas można już na tym pracować natywnie.
to jest dos do gamedevu, tworzenie plikow jest srednio potrzebne - jesli wogole. zreszta niestety brak miejsca w bootsektorze na kolejne funkcjonalnosci.
Zachęcony informacją z pierwszego postu (potrafi zapisać plik o dowolnej długości) postanowiłem to sprawdzić.
Chyba nie rozumiem jak działa zapis. Myślałem że ponieważ program nie tworzy nowych plików, wystarczy stworzyć kilka kontrolnych plików np. L1,L2,L3,... o minimalnej długości 2 sektorów i zawsze zapisywać do tych plików. Niestety zapis zostaje obcięty do tych dwóch sektorów. Reszta jest wyrzucana na ekran. Podejście drugie. Może pliki powinny być dużo dłuższe i program jakoś ominie nadmiarowe sektory. Nic z tego xbootDOS wczytuje wszystko do końca starej mapy. Dodatkowo miesza stare dane z nowymi i robi błędy w pliku. Co robię źle? Potrzebna dokumentacja i jakiś manual. Program nie radzi sobie też z innymi językami na cartridge'u. sprawdzone na ACTION!, BASICXE. Bez zapisu xbootDOS jest mało przydatny.
Testowane pod Linuksem na atari800 4.2.0 Pliki zapisane w DOS 4.3T SD L1 to plik action nadpisany basic'iem L2 to plik którym nadpisałem L3 to plik ACTION!
1. nie mogles uruchomic tego z innymi cardrydzami. sciagnij xBootDOSa jeszcze raz - jest poprawiony, bedzie dziala z Action i Basicami XL/XE, Altirra Basic itd.
2. zapisujesz komenda LIST a ladujesz komenda ENTER i wychodza Ci smieci - tak, to jest prawidlowe zachowanie poniewaz zapisales LISTem do wiekszego pliku w ktorym juz cos bylo - te pozostale dane nie zostana skasowane i dlatego tak masz.
jak zapiszesz komenda SAVE (stokenizowane) to podczas ladowania LOAD bedziesz mial ok i smieci sie nie pojawia.
3. jesli bedziesz zapisywal wiecej danych do pliku o zbyt malym rozmiarze to dostaniesz komunikat z bledem end of file
jeszcze jedno, (chyba to Cie zmylilo) do pliku ktory poczatkowo mial np. 10 bajtow i miescil sie w 1 sektorze nie zapiszesz 20 bajtow (mimo, ze w sektorze jest jeszcze sporo wolnego miejsca)
Problem cardridge'a wygląda na rozwiązany. @ Do pliku który początkowo miał np. 10 bajtów i mieścił się w 1 sektorze nie zapiszesz 20 bajtów Byłem pewien że w granicach sektora możemy zapisać wszystko.
Tylko Basic w stokenizowanym pliku zna jego długość (dlatego w C: nie czeka na ostatni blok). Wszystkie inne programy czekają na EOF. Czy nie dało by się kontrolować długości pliku bez ruszania mapy dysku (jakiś znacznik EOF w nadmiarowych sektorach należących do danego pliku). To mocno by zwiększyło funkcjonalność programu i wszystkim by szczęka opadła. Pomyśl o tym.
Za bardzo nie wiem co to oznacza "jak stworzysz odpowiedniego "templata"". Ale nic to jedziemy dalej. Program zapisuje na dysku więcej niż wczytuje. W przykładowym atr masz 3 pliki L1,L2,L3 spróbuj wczytać pod ACTION!. plik D:L3 zapisać go i ponownie wczytać może być pod tą samą nazwą to sam zobaczysz.Nadal nie potrafi rozpoznać miejsca końca krótszego pliku i wczytuje całość. Po którymś teście wyrzucił error 136 i nadpisał częściowo bootblok.
Może napisanie DOSa w bootsektorach to za ambitne zadanie? To moja ostatnia odpowiedź w tym temacie. Chyba nie nadaję się na betatestera. Powodzenia
No dobrze, ale na czym polega "rozszerzanie/skracanie pliku bez ruszania VTOC"? Linki w sektorach zawsze wskazują na kolejny sektor na dysku, ale kontrolujesz rozmiar pliku za pomocą znacznika zajętości sektora?
Tak, pomysł jest bardzo ciekawy. Ciekawe jak sobie poradzą loadery i same DOS-y z takimi plikami. Ale w ten sposób można by rezerwować miejsce pod pliki o maksymalnej zadanej długości na etapie tworzenia pliku.
Edit: To jeszcze uściślając parę kwestii.
Podczas zapisu idziemy po linkach i aktualizujemy znacznik zajętości sektora. Czyli wszystkie sektory w pliku są zajęte na max do momentu kiedy trafimy na sektor częściowo zajęty, albo pusty, albo kiedy link jest pusty (wtedy nie ma więcej miejsca na zapis). Uważałbym na sytuację kiedy kończymy zapis z sektorem zapełnionym na max, bo wtedy następny sektor (o ile aktualny link nie jest 0) musi mieć znacznik wypełnienia ustawiony na 0 (szczególnie w przypadku kiedy nadpisujesz plik który był wcześniej dłuższy).
Podczas odczytu bierzemy dane z sektora do momentu kiedy znacznik zajętości jest mniejszy niż max lub kiedy link jest pusty.
Mógłbyś podczas tworzenia pliku markować taki rodzaj pliku ("sticky"? że niby przyklejony jest do sektorów na dysku) w statusie jakimś bitem lub kombinacją? Tak żeby zachować kompatybilność z już istniejącymi filesystemami.
Edit 2: A może jednak zostawić status pliku w spokoju? Chociaż pewnie wszystkie disk cleanery i inne disk fixery będą raportować błąd w pliku. I tak będą pewnie raportować błąd kiedy status będzie zmieniony.
