atarionline.pl Ograniczenia systemów plików - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

4. Programowanie / Programming  »   Ograniczenia systemów plików

W dół

Od 1 do 50 z 95

  1. <
  2. 1
  3. 2
  4. >
    • 1:
       
      CommentAuthormgr_inz_rafal
    • CommentTime6 Sep 2013 zmieniony
     
    Gierka, nad którą pracuje ma dwa główne założenia:
    1. Być dość obszerna
    2. Działać na stock 64kb Atari
    W związku z tym, sporo danych jest doczytywane z dyskietki.

    Ponieważ mimo wszystko chciałbym zmieścić się na jednej dyskietce zapytuję z jakimi niespodziankami mogę się spotkać jeśli liczba plików na dyskietce urośnie dość znacznie? Czy są jakieś limity na liczbę plików lub inne podobne?

    Acha, jak wygląda sprawa z jednostkami alokacji? Ile rzeczywistego miejsca na dyskietce zajmuje plik o wielkości 1 bajta?
    • 2: CommentAuthor0xF
    • CommentTime6 Sep 2013
     
    Standardowe DOSy obsługują 64 pliki w katalogu. MyDOS pozwala tworzyć katalogi, które też zawierają po 64 pliki lub podkatalogi.

    Plik jednobajtowy zajmuje jeden sektor (128 lub 256 bajtów) i zużywa 16 bajtów w katalogu dysku (które miejsce i tak jest zarezerwowane niezależnie od tego czy jest wykorzystane) oraz jeden bit w VTOC (to miejsce też jest zarezerwowane).

    Jeśli masz zamiar czytać kilka plików jeden po drugim, lepiej wrzucić to do jednego pliku. Zaoszczędzisz miejsca na dysku i czasu na przesuwanie głowicy. Oraz nerwów użytkownikowi, bo niektóre stacje bardzo głośno przesuwają głowicę.
    • 3: CommentAuthorseban
    • CommentTime6 Sep 2013 zmieniony
     
    Formaty Systemów Plików: ->link<- Coś musisz sobie wybrać :)

    Standardowy format to Dos 2.5: ->link<- -> ograniczenie do 64 plików na dysku.

    Ja polecałbym My-DOS: ->link<- (możesz tworzyć katalogi i potkatalogi, a w każdym z nich kolejne 64 pliki)

    Niektórzy polecą Ci Sparta-Dos: ->link<-
    • 4: CommentAuthorQTZ
    • CommentTime6 Sep 2013
     
    Trochę na ten temat w wątku o 64 Figurach pisał Mono
    ->link<-
  5.  
    O kurde, 64 pliki... A ja już mam 55 :) W samą porę zapytałem.

    Najciekawiej wygląda Sparta, bo nie ma ograniczenia 64 plików na katalog.

    @0xF
    Kilka plików mam małych, ale niestety kolejność odczytu zależy od poczynań gracza. Mimo to i tak je połączę i zrobię jakąś prostą metode indeksowania zawartości. To i tak powinno być szybsze niż skakanie głowicą. A do tego zaoszczędzę miejsce.
    • 6: CommentAuthorseban
    • CommentTime6 Sep 2013 zmieniony
     
    Jeżeli chcesz skakać po pozycji w środku jednego dużego pliku, to zapomnij o Dos 2.x / MyDos. Pozostaje Ci tylko sparta-dos.
    • 7:
       
      CommentAuthortdc
    • CommentTime6 Sep 2013
     
    Tak Sparta to bardzo ciekawy DOS jeśli chodzi o jego wykorzystanie w praktyce. Druga sprawa, że już dawno temu był jeśli nie jedynym to jednym z najlepszych DOSów dla małego Atari.
    • 8: CommentAuthorBluki
    • CommentTime6 Sep 2013 zmieniony
     
    MyDOS, jak wspomniał 0xF, pozwala na utworzenie do 64 podkatalogów (w praktyce należy przyjąć maks. 60 podkatalogów) , każdy z maksymalnie 64 plikami. Podkatalog (czyli taki folder) zajmuje 8 sektorów na dysku. Każdy podkatalog może zawierać następne 64 podrzędne podkatalogi z maks. 64 plikami, itd. W praktyce liczba podkatalogów i plików ograniczona jest tylko pojemnością dyskietki.

    Jednak najprostszym rozwiązaniem wydaje się połączenie wszystkich plików jeden i ewentualnie dodanie na dysku drugiego pliku zawierającego punkty wejścia do poszczególnych „podplików” w tym pierwszym, czyli numer sektora i bajtu oraz jeśli jest taka potrzeba długość „podpliku”. Takie rozwiązanie najlepiej wykorzystuje pojemność dyskietki. Nie traci się sektorów na podkatalogi i pliki które zajmują np. 10 bajtów, zajmują rzeczywiście tyle, a nie pełny sektor.

    seban:

    Jeżeli chcesz skakać po pozycji w środku jednego dużego pliku, to zapomnij o Dos 2.x / MyDos. Pozostaje Ci tylko sparta-dos.

    Nie widzę problemu aby „skakać” pod MyDOS-em w dowolne miejsce pliku zajmującego nawet całą dyskietkę. Sam takie rzeczy robiłem.
    • 9: CommentAuthorxxl
    • CommentTime6 Sep 2013
     
    duzo tez zalezy od nosnika na jakim "pozwolisz" graczom nagrywac ta gre. przykladowo sprawdz jaki filesystem mozna utworzyc na kartach.
    • 10: CommentAuthorseban
    • CommentTime6 Sep 2013 zmieniony
     
    @bulki: pewnie że się da, ale to co opisałeś powyżej (numer sektora i bajtu w sektorze) wskazuje iż chcesz użyć funkcji Note/Point. Ale to z prawdziwym "fseek" ma raczej niewiele wspólnego :) można powiedzieć iż to raczej dostęp na poziomie "RAW", do sektorów na dysku :)

    A wystarczy użyć Sparty/BeWe Dos/Real Dos i mamy normalny dostęp do dowolnego bajtu w pliku bez konieczności jeżdżenia głowicą w tą i w tamtą (no chyba że masz uruchomioną spartę a na dyskietce filesytem dos 2.x :P )
    • 11: CommentAuthorxxl
    • CommentTime6 Sep 2013
     
    piszac "pod" konkretnego DOSa (niestety z braku kompatybilnosci tychze) powinienes umiescic informajce dla gracza jakiego DOSa powinien uzyc aby zagrac w Twoja gre.
    userzy i tak w wiekszosci przypadkow beda kopiowac Twoja gre nie jako pliki ale calodyskowo... wiec czy nie latwiej dla Ciebie i gracza bedzie w tym wypadku gdy pominiesz filesystem? :D obydwa rozwiazania sa zle no ale pisanie pod DOS nie jest dobrym pomyslem, gorsze jest tylko pisanie pod konkretnego DOSa ;-)
    • 12: CommentAuthorwieczor
    • CommentTime6 Sep 2013
     
    Skoro gracze będą kopiować grę w większości całodyskowo, dysk może również zawierać odpowiedniego DOSa. Ten ułamek który zechce skopiować same pliki np. na HDD da sobie radę. Brak kompatybilności filesystemów nie przeszkadza tak długo jak używa się OSa do dostępu do plików. Więc to nie do końca jest prawda że oba rozwiązania są złe - bo raczej trudno napisać coś pod konkretnego DOSa (chyba że używa się cech niedostępnych w innych), pisze się pod DOSa. Rozwiązanie całodyskowe jest o wiele gorsze, bo nie pozwala Ci zmienić medium w ogóle.
    • 13: CommentAuthormono
    • CommentTime6 Sep 2013 zmieniony
     
    Jeśli nie potrzebujesz przesuwać się w obrębie pliku, a tylko czytać/zapisywać kompletne pliki, wtedy korzystaj z dowolnego DOSa.
    Jeśli ilość plików przekroczy 62 (DOS.SYS i AUTORUN.SYS) korzystaj z MyDOSa i podkatalogów.
    Jeśli nie chcesz mieć podkatalogów i planujesz skakać po pliku w tę i na zad, korzystaj ze SpartaDOS (może być wersja dyskietkowa czyli 3.2x) - funkcje NOTE/POINT działają tu w obrębie pliku, a nie dysku jak w DOS2.x.
    Sparta dyskietkowa dość mocno korzysta z pamięci pod ROMem (to samo DOS II+/D) więc zapomnij o niej jeśli jej potrzebujesz (SDX można konfigurować tak, żeby nie korzystała).
    Najfajniej byłoby gdybyś nie koncentrował się na całodysku i potrzebował jedynie czytać/pisać pliki - wtedy można będzie przenieść to sobie na hdd i odpalić stamtąd nawet pod MyDOSem. Możesz też próbować trzymać całość na kilku dyskietkach i po wykryciu, że dany plik nie istnieje w fs (błąd 170 przy próbie odczytu) prosić o zmianę dyskietki.
    Oczywiście możesz też skorzystać z xBIOS, ale tu xxl powie Ci najwięcej i najtreściwiej.

    Edit: stylistyka
    • 14: CommentAuthorxxl
    • CommentTime6 Sep 2013
     
    wieczor> Brak kompatybilności filesystemów nie przeszkadza tak długo jak używa się OSa do dostępu do plików.

    mylisz sie. czasem te same funkcje (kolega o nich wspomnial) na roznych dosach dzialaja roznie.


    wieczor>Więc to nie do końca jest prawda że oba rozwiązania są złe

    tu sie zgodze, nie oba sa zle. jedno jest gorsze od drugiego. tylko nie wiem czy pisanie pod konkretnego dosa czy pisanie calodysku.


    ---
    a na powaznie. MIR, poznaj mozliwosci i ograniczenia roznych rozwiazan wybierz jedno, cokolwiek zrobisz i tak bedziemy grymasic ;-)
    • 15:
       
      CommentAuthormgr_inz_rafal
    • CommentTime6 Sep 2013 zmieniony
     
    Dzięki Wam za wszystkie komentarze. Generalnie nie jestem spięty ideowo z żadnym z rozwiązań i muszę wymyślić co będzie najlepsze.

    Chętnie skorzystałbym z MyDOS + katalogi, ale Altirra nie ma opcji "Mount as virtual MyDOS disk", co uczyni development upierdliwym. Hint XXLa podany tutaj jest super-wygodny: ->link<-
    Może trzeba się zapoznać z Franny polecanym przez mono w tym samym wątku.

    Ale pobawiłem się trochę Spartą dyskową, wersja 3.2x pobraną z AOL, bo 3.2g nie wstaje mi na Real Atari... Jest tylko problem z numerem napędu: DOS wstaje z D1:, gierkę montuję jako D4:, a już wewnątrz samej gry posługuję się napędem D: i w efekcie nie mogę odczytać plików.

    Czy można Spartę dyskową jakoś przekabacić, żeby myślała, że D: to np. D4?

    PS. Ideowo nie mam też nic przeciwko xBiosowi, ale trochę już by mi się nie chciało przerabiać mechanizmów I/O, które pisałem z myślą o DOSach :)
  16.  
    Hmmm,

    afaik Bibo-DOS and Turbo-DOS XL/XE (Reitershan) both allow up to 128 Files on a 360k diskette. On the other hand if you use 2x 180k you (also) have 2x 64 = 128 Files.

    Bewe-DOS allows up to 1424 files per diskette (think the format does not matter here) and subdirs of course...

    -Andreas Koch.
  17.  
    @CharlieChaplin
    Where can I get the Bewe-DOS with all utilities (FORMAT, etc.) from?
    • 18: CommentAuthorseban
    • CommentTime7 Sep 2013
     
    Hej!

    Tutaj jest: ->link<-

    Kliknij zakładkę "Attach" na powyższej stronie. Są 4-ry ATR-y do pobrania.
    • 19:
       
      CommentAuthormgr_inz_rafal
    • CommentTime7 Sep 2013 zmieniony
     
    Dzięki,
    Udało się pobrać, uruchomić, sformatować i przetestować na Real Atari. Myślę więc, że obiorę kierunek Sparta/Bewe-DOS.

    Na 64kb RAMu gra prawdopodobnie i tak będzie mało grywalna z normalnej dyskietki, chyba, że ktoś ma jakieś turba :) Wygodniej będzie z SIO2SD lub innych dysków twardych.

    Spodziewajcie się więc niedługo pytań o wykorzystanie pamięci rozszerzonej :)
    • 20:
       
      CommentAuthorpirx
    • CommentTime7 Sep 2013
     
    BeWe jest OK, bo możesz w 100% legalnie nagrywać na dyskietkę. A później tak, jak piszesz - się zgra na HDD.
  21.  
    Bewe 1.30 ?!?

    Download it from here !

    -Andreas Koch.
    • 22: CommentAuthorseban
    • CommentTime7 Sep 2013
     
    @CharlieChaplin: Why are you surprised of BeWe DOS in version 1.30? is there any newer or better version?

    with greetings
    Seban/Slight
  23.  
    Na SpartaDos 3.2 osiągam dużo (dużo dużo) większą prędkość I/O niż na BW-DOS. Dyskietka oczywiście ta sama, podpięta przez SIO2SD.

    BW-DOS wyraźnie pauzuje na dłuższy czas w momencie otwierania pliku, Sparta robi to migiem.

    Tak tylko piszę jako ciekawostkę.
  24.  
    @Seban:

    I am not surprised of Bewe-DOS version 1.30 - and afaik there is no newer version available. The "Bewe 1.30 ?!?" was simply a shortened question, maybe I should have asked: "Are you still searching for Bewe-DOS 1.30 ?!?". I am however a bit surprised that Bewe-DOS 1.30 was not available here at AOL for download...

    -Andreas Koch.
    • 25: CommentAuthormuffy
    • CommentTime7 Sep 2013
     
    @mgr_inz_rafal
    Mogę rozpętać III wojnę światową ale zapytam:
    a xbios'a próbowałeś? :)
    • 26: CommentAuthorpin
    • CommentTime8 Sep 2013
     

    mgr_inz_Rafal:

    Czy można Spartę dyskową jakoś przekabacić, żeby myślała, że D: to np. D4?


    Spartę X da się (zmiana systemowego CurDev - można D: ustalić jako dowolny dysk/katalog z zakresu D1:-D15:) - lecz ciężko grę uwiązać jednak do systemu opartego o sprzęt. Sparta 3.X - nie wiem czy ma taką możliwość, może ktoś pomoże (Mono?). Z xBiosem daj sobie lepiej spokój, bo możesz sobie ograniczyć możliwość odpalenia programu z dysku twardego - a jest to dość popularne urządzenie biorąc pod uwagę realnie działający hardłer ;)
    • 27: CommentAuthorxxl
    • CommentTime8 Sep 2013
     
    za to pozwoli gre plikowa lub wieloplikowa bez zadnych przerobek nagrac na kardrydzu :-)

    a w przypadku sparty? po przerobce od biedy mozna nagrac na specjalnym typie karta ale w tym przypadku czy ktos wspominal o ograniczeniu wielkosci pliku do 8kb

    upsss... ;-)

    kazde rozwiazanie ma wady i zalety :-)
    • 28:
       
      CommentAuthormgr_inz_rafal
    • CommentTime8 Sep 2013 zmieniony
     
    @muffy
    Nie próbowałem xBiosa, z powodów, które wymieniłem już powyżej. Engine już *jest* napisany pod DOS i nie chce mi się go przerabiać, zwłaszcza, że filesystem Sparty + merge małych plików w jeden większy prawdopodobnie wystarczy do realizacji moich potrzeb.

    @pin
    Już nie muszę ustawiać D: = D4:, bo w końcu udało mi się sformatować w Sparcie dyskietkę, tak aby butowała się z SIO2SD, więc system + grę mogę mieć na D1:. Moje pytanie miało na celu uniknięcie "przekładania" dyskietek za pomocą guzików na SIO2SD przy każdej próbie odpalenia gry na Real Atari. Oczywiście chętnie dowiem się jak to zrobić pod Spartą plikową ("zmiana systemowego CurDev" jest dla mnie poza zasięgiem z obecną wiedzą o tym OS).

    @xxl
    Priorytetem dla mnie jest to, aby "dystrybuować" dyskietkę, która po włożeniu do SIO2SD lub stacji dysków pozwoli pograć na normalnej Atarynce. Dyski twarde, a już w szczególności karty, ewentualnie później. Zwłaszcza te drugie, bo to dla mnie jeszcze abstrakcja :)
    • 29:
       
      CommentAuthorKaz
    • CommentTime8 Sep 2013
     
    however a bit surprised that Bewe-DOS 1.30 was not available here at AOL for download...


    Dodane do katalogu, dzieki Andreas! :).
    • 30: CommentAuthorwieczor
    • CommentTime8 Sep 2013 zmieniony
     
    @mgr_inz_rafal: byłoby fajnie z pewnych powodów, abyś nie przywiązywał gry na sztywno do D1, domyśl się dlaczego ;) D: oznacza napęd domyślny i został zrobiony po to aby nie uzależniać oprogramowania od napędu fizycznego - to może być D1, D2, D4 - gdziekolwiek tę grę sobie zainstalujesz. Dlatego też nie powinieneś zmieniać systemowego CurDev a używać go po prostu :)
    • 31:
       
      CommentAuthormgr_inz_rafal
    • CommentTime8 Sep 2013 zmieniony
     
    @wieczor
    Nie muszę się domyślać - gra ciągnie dane tylko z D:.

    Tylko teraz tak: W D1: mam Spartę, a w D4: grę. Butuję z D1: wpisuję:

    D4:
    MAIN.XEX

    Sama gra się załaduje, ale poszczególnych plików szuka na D1:

    Spodziewałem się innego zachowania, stąd moje pytanie.
    • 32: CommentAuthorpin
    • CommentTime8 Sep 2013
     
    Zrób to po prostu tak, że wrzuć dosa razem z grą na jeden obraz a odwołania z programu do "D:". Prawdopodobnie to będzie rozwiązanie wystarczające i dodatkowo zapewniające możliwość uruchomienia z praktycznie dowolnego medium (FDD, czy dowolny katalog/podkatalog z HDD przy SDX np.)
    • 33: CommentAuthorwieczor
    • CommentTime8 Sep 2013
     
    Moment, a to nie jest kwestia tego, że D: w sparcie oznacza coś innego niż w innych dosach? Chodzi mi o to mapowanie A: B: C: D: ... kolejnych partycji
    • 34:
       
      CommentAuthormgr_inz_rafal
    • CommentTime8 Sep 2013 zmieniony
     
    @pin
    Tak właśnie zrobiłem i na razie idealnie się sprawdza.

    @wieczor
    Info z Atariki: "Jedną z ważnych innowacji SpartaDOS X w stosunku do innych DOS-ów jest to, że identyfikator urządzenia "D:" (w CIO) nie wskazuje stacji dysków nr 1, lecz dysk bieżący, to jest ten, który był ostatnio ustawiony jako domyślny przez interpreter poleceń DOS-u. Takie zachowanie zostało potem wstecznie zaimplementowane również w SpartaDOS 3.2g.".

    Niestety, wersja 3.2g dostępna na AOL nie chce mi się zbutować z SIO2SD. Z kolei za pomocą 3.2x nie udało mi się sformatować dyskietki. Dlatego też aktualnie korzystam z 3.2d, które wydaje się nie mieć wdrożonej tej opisanej wyżej poprawki z D:
  35.  
    Odgrzebuję wątek, bo w miarę jak Rzygoń się rozrasta pojawiają się nowe sprawy :)

    Otóż, obecnie zauważyłem, że wydłuża mi się czas ładowania mapki. Ponieważ samą logikę ładowania w moim mniemaniu dobrze zoptymalizowałem, zacząłem drążyć temat. Okazało się, że (na oko) 90% czasu odczytywania mapy to otwarcie pliku.

    Po wywołaniu "jsr CIOV" z poleceniem otwarcia pliku IO brzęczy kilkanaście razy. Potem sam odczyt mapy to już tylko jedno, szybkie pierdnięcie :)

    Proces otwarcia pliku zdecydowanie się skraca, gdy plików jest mało. Niestety obecnie jest ich już 146, a będzie ok. 200.

    Moje środowisko testowe to Altirra + SDX + folder zamontowany jako "virtual SDX disk".

    No i teraz pytanie do Was - czy tak długi czas otwierania przy dużej ilości plików na dyskietce to cecha:
    1. Sparty
    2. filesystemu Sparty
    3. Altirry z wirtualnie podmontowanym katalogiem

    I drugie pytanie, jak to leczyć? Wolałbym mimo wszystko uniknąć ładowania całej gry na chama do ext ramu. Może kiedyś jako opcja :)

    Spróbuję w weekend porobić eksperymenty na real HW.
    • 36: CommentAuthorBluki
    • CommentTime25 Apr 2014 zmieniony
     
    Proces się wydłuża, bo więcej danych w katalogu musi być "przerzuconych" aby znaleźć ten właściwy plik.

    A nie myślałeś, aby wszystkie pliki połączyć w jeden i w ten sposób tylko raz otworzyć taki plik do odczytu? Odczytanie pożądanego fragmentu polegałoby tylko na ustawieniu początkowego sektora i bajtu w tym sektorze, a przy pewnej organizacji, praktycznie tylko sektora.
    • 37: CommentAuthormono
    • CommentTime25 Apr 2014 zmieniony
     
    Otwarcie pliku wiąże się z przejrzeniem katalogu stąd odczyty. SpartaFS ma struktury zorganizowane za pomocą map sektorów, a nie linków jak AtariFS. Przy otwarciu czyta się sektor 1, sektor mapy katalogu, sektory katalogu. Kiedy znaleziony zostanie plik w katalogu, to czytana jest mapa pliku (pierwszy sektor, kolejne doczytywane są w razie potrzeby) i sektory danych pliku.
    Zachodzą tu jednak drobne optymalizaje, bo Sparta buforuje sobie odczytane sektory.
    Umieszczaj najczęściej używane pliki na początku. To w sumie w każdym FSie na Atari8 jest dobra praktyka.
    OIDP możesz też pobawić się konfiguracją ilości buforów i plików (tam zdaje się był jakiś plik typu STARTUP).

    Edit: Jeśli idzie o XRAM, to możesz spróbować skopiować przy odpalaniu gry pliku do ramdysku i zmienić bieżący dysk. Jak nie ma ramdysku to zostajesz przy D:. kod programu się chyba nie zmieni, pliki będzie tylko czytało z RD.
    • 38:
       
      CommentAuthormgr_inz_rafal
    • CommentTime25 Apr 2014 zmieniony
     
    @Bluki
    Myślałem o takim rozwiązaniu (kto pamięta jeszcze doom.wad?) ;-)

    Problem w tym, że do IO wykorzystuję systemowe CIO, a tam nie ma odpowiednika seek() i nie można skiknąć w żądane miejsce pliku. Albo o czymś nie wiem.
    • 39: CommentAuthormono
    • CommentTime25 Apr 2014
     
    W Sparcie masz funkcje NOTE i POINT, które działają dokładnie jak SEEK/TELL - co do bajtu w obrębie pliku (uwaga, bo na AtariDOSach te funkcje działają inaczej!).
    • 40: CommentAuthormono
    • CommentTime25 Apr 2014
     
    • 41:
       
      CommentAuthormgr_inz_rafal
    • CommentTime25 Apr 2014 zmieniony
     

    mono:

    Jeśli idzie o XRAM, to możesz spróbować skopiować przy odpalaniu gry pliku do ramdysku

    Pomysł z ramdyskiem jest ciekawy. Chciałbym jednak, aby obsługa gry ograniczała się po prostu do "odpalenia .xex". Czy w takim razie są odpowiednie procedury aby:
    1. Wykryć czy jest ramdysk (lub ramdyski) oraz numery ich stacji?
    2. Jeśli nie, to go utworzyć (bezpiecznie, w różnych konfiguracjach atarki)

    mono:

    W Sparcie masz funkcje NOTE i POINT
    Nie chcę - no chyba, że w końcu będę musiał - ograniczać się do wsparcia tylko filesystemu sparty.
    • 42: CommentAuthorBluki
    • CommentTime25 Apr 2014
     
    Nie tylko w Sparcie jest NOTE/POINT, choć jak zauważył mono,działa to trochę inaczej. Nie wiem czy nie można skonfigurować Sparty, tak aby te funkcje działały jak w Atari DOS-ie, no i czy to da jakąś korzyść.
    • 43: CommentAuthormono
    • CommentTime25 Apr 2014 zmieniony
     
    Jeśli skorzystasz z STARTUP.BAT to możesz tworzyć RD.COM n: stąd wiesz gdzie masz ramdysk :) Jeśli się nie utworzył, to XIO CHKDSK na nim pewnie zwróci błąd; jeśli zaś nie, to z wyniku dostaniesz rozmiar ramdysku (uwaga, bo może się okazać, że jest go za mało albo go w ogóle nie ma -- może to jednak zły pomysł...).
    Z punktu widzenia użytkownika fdd chyba najlepiej byłoby poukładać sobie pliki na dysku i ustawić STARTUP.BAT do odpalenia programu głównego. Ilość buforów (a zatem i memlo) i rodzaj DOSa konfiguruje się przy formatowaniu i inicjalizacji dysku docelowego (XINIT+BOOT).

    Edit: NOTE+POINT - z dokumentacji FTE wynika, że NOTE/POINT wykonywane poprzez XIO na dyskach AtariDOS zadziała dokładnie, jak w AtariDOS - sektor na dysku + offset w sektorze. Z dyskami SpartaDOS będzie to jednak działać jak w Sparcie - offset w pliku (warto zwrócić uwagę na rzadkie pliki w Sparcie :]).
    • 44: CommentAuthorxxl
    • CommentTime25 Apr 2014
     
    > Otóż, obecnie zauważyłem, że wydłuża mi się czas ładowania mapki. Ponieważ samą logikę ładowania w moim mniemaniu dobrze zoptymalizowałem, zacząłem drążyć temat. Okazało się, że (na oko) 90% czasu odczytywania mapy to otwarcie pliku.


    nowy xB pozwala indeksowac pliki na nosniku (nieograniczona ilosc), uzycie zmiennej xFILE calkowicie eliminuje czas otwarcia pliku (nie ma otwarcia pliku), nie mowie o NOTE/POINT; TELL/SEEK; FILE OFFSET.
    moze Sparta tez ma cos takiego...
    • 45:
       
      CommentAuthormgr_inz_rafal
    • CommentTime25 Apr 2014 zmieniony
     
    Wykonałem właśnie trochę pomiarów, wyniki umieszczam poniżej. Ostatnia kolumna to średni czas ładowania jednej mapki, mierzony metodą stoper-palec :)


    Okazuje się, że Rzygoń chodzi całkiem dobrze na realnym sprzęcie, a problemy kreuje emulator (poza Atari800Win z SIO Patch).

    Gra z karty CF (czyli pewnie też z HDD) oraz z Ramdysku jest całkiem bezstresowa. Czas ok. 2,5s na przełączenie levelu w SIO2SD też jest komfortowy, choć w momentach, w których po prostu musimy przebiec parę mapek bez robienia niczego, może wkurzać.

    Biorąc pod uwagę speed karty CF wydaje mi się, że większość z tych 1,5s to czas spędzony nie na I/O, a na rysowaniu levelu, ale nie chciało mi się aż tak dokładnie mierzyć.

    Niestety, nie mam obecnie możliwości sprawdzenia gry na fizycznej stacji dysków, ale pewnie będzie na takowej krucho. Podobnie ze sprzętem wyposażonym w 64kb RAM - gra działa na nim tylko teoretycznie (w praktyce czas ładowania leveli to dziesiątki sekund, gdyż do zbudowania levelu potrzebne jest czytanie z kilku plików i jeśli nie są one zbuforowane w extram to wychodzi kiszka).

    Snucie refleksji:
    1. W grę da się pograć w obecnej postaci zarówno na Real HW, jak i na emulatorze (Atari800Win)
    2. Trzeba porzucić marzenia o graniu na 64kb RAMu, ale nie będę wyłaził poza stockowe 130XE
    3. Trzeba skończyć wszystkie mapki oraz grę :)
    4. Jeśli okaże się, że te 1,5s to czas rysowania, a nie I/O to ogłosić koniec prac
    5. A jeśli okaże się odwrotnie, tzn. że można coś ugrać na czasie otwierania plików, to mam jeszcze wolne dwa banki pamięci, więc mogę mapy pogrupować w bloki po 16kb i raz na jakiś czas robić po prostu dłuższy loading
    5.1. Choć właściwie wolny mam jeden bank, bo wkrótce teksty dialogów zaczną przekraczać 16kb i zajmą kolejny slot extramu
    5.2. A biorąc pod uwagę SDX w trybie BANKED to zostaje mi 0 banków :/

    W każdym bądź razie, szykuje się jakaś fajna robota optymalizacyjna, która na pewno będzie ciekawsza niż robienie kolejnych mapek :)

    PS. Na stos z gościem, który wymyślił wkładanie cartrige od tylca w serii XE!
  46.  
    @xxl
    To co piszesz jest interesujące. Możesz powiedzieć coś więcej o tym "xFILE"? Nie mogę nic znaleźć tutaj: ->link<-

    Wydaje się, że zapewniasz dokładnie to, czego potrzebuję:
    1. Nieograniczona ilość plików
    2. Całkowita eliminacja czasu otwarcia pliku

    Jak z bajki :)

    Obserwacja forum pozwala jednak mieć podejrzenia, że ewentualne użycie xBIOS zwiąże mnie z SIO i granie np. z HDD będzie niemożliwe. Czy dobrze domniemuję?
    • 47: CommentAuthorBluki
    • CommentTime25 Apr 2014
     
    Nie rezygnowałbym z Atari 64kB, chyba, że nie będzie innej możliwości. Po prostu w minimalnej konfiguracji należy zawrzeć wymóg posiadania szybkiego nośnika, jak HDD.
    • 48:
       
      CommentAuthormgr_inz_rafal
    • CommentTime25 Apr 2014 zmieniony
     
    Sztucznie nie będę rezygnował, gra na pewno odpali na 64kB. W obecnej postaci będzie jednak koszmarnie wolna, nawet z szybkim nośnikiem. W przypadku posiadania extram większość danych do budowania mapy oraz obsługi dialogów buforuję w bankach, więc IO dotyczy tylko schematu mapy. Bez extram za każdym razem wszytko ładowane jest z plików.

    Niestety, RAM pod ROM tutaj objętościowo nie wystarczy.

    Poczekajmy jednak na więcej info od XXL; może wersja na 64kb czarodziejsko pójdzie z pomocą xBIOSa :)
    • 49: CommentAuthorpin
    • CommentTime25 Apr 2014
     
    Jak użyjesz xBiosa, to możesz zapomnieć o szybkim HDD. W najlepszym przypadku, jeśli skorzystasz z funkcji xB ograniczysz możliwość do ładowania wyłącznie z obrazu *.atr a ten będzie ładowany około 4 razy wolniej z hdd. Dla porównania osiągalny transfer z HDD może zbliżyć się do 100kB (kilobajtów, nie bitów) /s, z obrazu ATR około 25kB. Poważnie bym się nad tym zastanowił szczególnie, że szybkie I/O jest Ci potrzebne ;)

    Jeśli chcesz przetestować grę w każdych warunkach (w tym na realnej stacji) to podeślij na pin(dot)atari.pl
    • 50: CommentAuthorwieczor
    • CommentTime25 Apr 2014
     
    Ja zamiast nad technologią ładowania cały czas proponuję zastanowienie się nad algorytmem i konstrukcją gry i plansz :) To może dać znacznie więcej korzyści.

Od 1 do 50 z 95

  1. <
  2. 1
  3. 2
  4. >