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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthormgr_inz_rafal
   • CommentTime24 Nov 2015 zmieniony

    
   Witam,
   Niedługo puszczam gierę i szukam dla niej odpowiedniego nośnika dyskietkowego. Użytkownicy SDX mają tutaj tę przewagę, że wypakowują sobie pliki gdziekolwiek i jadą z koksem.
   
   Ale dla reszty chciałbym przygotować .atr, który "zamontują i odpalą".
   
   Zatem szukam DOSa, który:
   1. Obsługuje podkatalogi (jak np. MyDos)
   2. Posiada wbudowane procedury Fast SIO (jak np. Sparta dyskietkowa 3.2g (czy jakaś inna literka))
   3. Zawiera opcję "autostart"
   
   Istnieje taki stwór?
2. • 2: CommentAuthors2325
   • CommentTime24 Nov 2015

    
   Jeśli dowiesz się konkretnie który to ktoś pozbierał część tutaj ->link<-
3. • 3:
      
     CommentAuthortdc
   • CommentTime24 Nov 2015

    

   mgr_inz_rafal:

   Istnieje taki stwór?

   
   "Istnieje taki czopkowy stwór?" - Rafał traci ostatnio formę :D
4. • 4: CommentAuthormono
   • CommentTime24 Nov 2015 zmieniony

    
   Jak przez mgłę kojarzę, że chyba BiboDOS potrafił obsługiwać podkatalogi, turbo i 128 wpisów w katalogu.
   
   Edit: Ale z kolei przypomniałem sobie, że Sparta DOS 3.2d potrafiła wykorzystać turbo stacji XF 551 (niekompatybilne z US).
   Musisz poeksperymentować :)
5. • 5:
      
     CommentAuthorpirx
   • CommentTime24 Nov 2015

    
   bewedos?
6. • 6:
      
     CommentAuthorPecus
   • CommentTime24 Nov 2015

    
   BeWe nie ma chyba Fast SIO wbudowanego.
7. • 7: CommentAuthorCharlieChaplin
   • CommentTime24 Nov 2015

    
   Bewe-DOS has an external file for XF551 fast SIO (and there is also an external file by Stefan Dorndorf for Hyper-XF fast SIO under Bewe). Directory has space for up to 1424 files and also offers subdirs. Autostart can be made with batchfile or with BOOT.COM. BeweDOS formatter is limited to 360k, but one can format up to 16MB with SpartaDOS and then copy Bewe-DOS (XBW130.DOS) onto it and boot from it (via BOOT.COM).
   => fast-SIO = external
   
   Top-DOS prof. offers subdirs, external fast SIO for Happy drives and also autostart (maybe even batchfiles). But since it is not fully DOS 2/DOS 2.5 compatible I have used it only once. Think it also supports up to 16MB...
   => fast-SIO = external
   
   
   DOS XE does 16MB but in an awkward way (requires a 16kbyte buffer for this, which means 16k less RAM, ouch!), it supports subdirs and autostart via batchfile. It supports XF551 fast SIO in DSDD/360k format, not sure if it supports XF fast SIO in any other format (also not sure if it supports any other kind of fast SIO).
   => fast XF551 SIO only with 360k format internal, otherwise external; other fast SIO only external
   
   Besides Bewe and SDX, there is RealDOS and SpartaDOS, both support up to 16MB and subdirs. Autostart works via batchfile(s) or BOOT.COM. There are versions with (and without) ultraspeed fast SIO, think there are also versions of these DOS (and external handlers/drivers) that support other fast SIO, e.g. for XF551, for synchromesh, for Turbo and others
   => fast ultraspeed SIO internal (built-in), other fast SIO afaik only external
   
   Last not least, there is MyDOS, it supports up to 16MB (versions 3.x and later, most common are versions 4.5x), supports subdirs, supports batchfiles with Thorsten Karwoth`s batchfile enhancement and fast SIO via external files, like e.g. ultraspeed drivers by Bob Woolley and XF551 drivers by Bob Woolley (both alter the OS and therefore use RAM under the OS).
   => fast SIO only external
   
   There are however various external handlers and drivers for Happy, Speedy, Turbo, XF551 and other fast drives available - one should test these drivers/handlers with different DOS versions (and programs) and see if they do work or not.
   
   In short, subdirs and up to 16MB and other things: 1) SDFS (Sparta DOS File System): SDX, SpartaDOS, Bewe-DOS, RealDOS or 2) DOS II FS: MyDOS, Top DOS Prof. or 3) other FS: DOS XE.
   
   I would not recommend using DOS XE since it is incompatible to any other filesystem (just like DOS 3 and DOS 4). Don`t kill me, if not everything I wrote here is fully correct (after all, I am only human)...

   • TOPPROF.ATR
8. • 8:
      
     CommentAuthormgr_inz_rafal
   • CommentTime25 Nov 2015 zmieniony

    
   Thanks for extensive information, seems like the best way is to apply the trial-and-error method.
   
   I am especially interested in this single paragraph, since I already tested the game agains MyDOS:
   

   Last not least, there is MyDOS, it supports (...) and fast SIO via external files, like e.g. ultraspeed drivers by Bob Woolley and XF551 drivers by Bob Woolley (both alter the OS and therefore use RAM under the OS).

   
   
   How do I apply these external files to the MyDOS atr image?
   
   ------------------------
   
   PS. Dla ułatwienia pozwolę sobie kontynuować po angielsku. Przepraszam nieczytających tego języka.
9. • 9: CommentAuthorCharlieChaplin
   • CommentTime25 Nov 2015

    
   Here they are in the attachment MYDOS455.ATR. The files are named "Ultraspd.AUT" and "XFhigh.AUT". They are ordinary ML files (COM/XEX), under MyDOS 4.50 rename one of them to Autorun.SYS, under MyDOS 4.53 or newer rename one of them to *.AR0.
   
   Note: These fast SIO drivers not only use RAM under the OS, they also alter port B $D301 to do so. So, TB XL will not work with these drivers and errrm, if you use a Ramdisk driver, you should load this first as *.AR0 and then load the fast SIO driver as *.AR1.
   
   (The ramdisk driver would remove the fast SIO driver, thus load the ramdisk driver first and then the fast SIO driver; alas, it is bad when you want to copy several files or one large file fast into the ramdisk, because the automatic option of the subdir :Ramdisk which copies all files of this subdir into the ramdisk will only work with normal/slow speed, because this option is part of the ramdisk driver and the fast SIO driver follows afterwards...)
   
   On the other hand, these two files can be loaded from any DOS that does not have fast SIO drivers and also does not use RAM under the OS... (meaning, they should also work under Bewe-DOS, but I have not tested this).

   • MYDOS455.ATR
10. • 10: CommentAuthorbrx
    • CommentTime25 Nov 2015

     
    @Rafał: Trochę mnie dziwi, cóż żeś tak nakombinował z tymi plikami, że jakiegoś specjalistycznego DOSa szukasz? Robienie czegoś z dziesiątkami/setkami drobnych pliczków i katalogów na mój gust nie ma specjalnego sensu, a już tym bardziej na ośmiu bitach, gdzie każdy bajt pamięci i przestrzeni się liczy...
    
    Jak już gdzieś pisałem, jak gra potrzebuje więcej pamięci, zrób grę w jednopliku, to zwykle pójdzie na dowolnym dosie/loaderze (używaj RUN i INI do ładowania/kopiowania kolejnych "porcji" danych do banków), choć tu wybierak banków stał się niestety koniecznością.
    
    Lecz jeśli chcesz choćby teoretycznego działania gry na 64KB-2KB, to sprawa staje się trudniejsza. O "zgrozo" w takich warunkach najlepiej chyba sprawdza się... XB :]
    
    Jeśli chodzi o systemy turbo, to każdy emulator ma SIO Patch, a ludzi używających jeszcze oryginalnych stacji dyskietek, choćby od święta jest garstka. No chyba, że chodzi o zasady... :(
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime26 Nov 2015

     
    @brx, sugerujesz, że @mgr_inz_rafal ma przepisać całą wytestowaną grę, która zajmuje pewnie ze 150-200 kB, na raz do pamięci?
    
    Ja rozumiem to plikowe podejście, zwłaszcza, że @mgr dopiero nabiera doświadczenia, a niestety tutaj by się ono przydało wcześniej (przechodzić przez 8 sektorów aby otworzyć plik jest niestety dość denerwujące) natomiast sądzę, że frajda z pisania gry pozostawiła ten aspekt rękom jegomościa "jakośtobędzie" bez myślenia o konsekwencjach.
    
    Każdy dzisiejszy programista by tak zrobił i się nie zastanawiał.
    
    Teraz to @mgr też już wie, że tak się na Atari nie robi :/ ale nikt nie doradził, zeby tak nie robić, bo i też nikt nie przypuszczał, że gra się tak rozrośnie. Sam nie uważałem tego za jakiś problem.
    
    @mgr_inz_rafal (ale długa ta ksywka :), ile kb ma gra?
12. • 12:
       
      CommentAuthormgr_inz_rafal
    • CommentTime26 Nov 2015 zmieniony

     
    CharlieChaplin,
    Thanks a lot - I'll test it in the evening.
    
    

    brx:

    Jak już gdzieś pisałem, jak gra potrzebuje więcej pamięci, zrób grę w jednopliku, to zwykle pójdzie na dowolnym dosie/loaderze (używaj RUN i INI do ładowania/kopiowania kolejnych "porcji" danych do banków), choć tu wybierak banków stał się niestety koniecznością.

    Jeśli już miałbym tak kombinować, to wolałbym po prostu załadować wszystko do EXTRAM. Dostęp do danych musi być losowy, a nie jak w demkach (part -> decrunch -> part -> decrunch -> greetings).
    
    Poza tym jak w takim rozwiązaniu zrealizować odczyt/zapis stanu gry? Przy kilku(nasto) godzinnym gameplay jest to konieczne.
    
    

    brx:

    Lecz jeśli chcesz choćby teoretycznego działania gry na 64KB-2KB, to sprawa staje się trudniejsza. O "zgrozo" w takich warunkach najlepiej chyba sprawdza się... XB :]

    
    Tak, xBios mógłby być tutaj dobrym rozwiązaniem. Niestety raczej nie wchodzi w grę, gdyż wymagałoby to kombinacji z wykrywaniem, czy gra jest uruchomiona w xB, czy w SDX (lub innym DOS) i stosowaniem albo SIO albo funkcji XXLa.
    
    Gra działa na 64kB, a na 128kB działa już wyśmienicie, co oznacza, że można pograć na niemodyfikowanym 130XE. A to jest priorytet, gdyż takie stoi u mnie na biurku :)
    
    

    brx:

    No chyba, że chodzi o zasady...

    
    Chodzi o fun! :)
    Zasady to są w biurze :)
    
    

    Teraz to @mgr też już wie, że tak się na Atari nie robi :/

    
    Hmm... To jak inaczej zrobić to na Atari? Na Atari bez EXT RAM? Chętnie się dowiem nawet jak już jest po ptakach, bo masz rację, nic nie zamierzam już przepisywać :)
    
    

    bo i też nikt nie przypuszczał, że gra się tak rozrośnie

    
    A to fakt - ja sam traktowałem to na początku jako kolejny Gruczoł czy Wybierak. Może bardziej taki proof-of-concept i przymiarka do czegoś porządnego. Choć założenia dot. wielkości "świata gry" były od samego początku ambitne.
    
    

    ile kb ma gra?

    Myślę, że z intrem, muzą i całą całością wciśnie się w 300kB.
13. • 13:
       
      CommentAuthorpirx
    • CommentTime26 Nov 2015

     
    > To jak inaczej zrobić to na Atari?
    
    najłatwiej to czytać/zapisywać po sektorach - tak działało wiele (jak nie większość) gier całodyskowych. Czyli np. zamiast nazwy pliku masz 2 liczby - nr pierwszego sektora i liczba sektorów. Of kors development jest trudniejszy, ale do ogarnięcia paroma utilami.
14. • 14: CommentAuthortebe
    • CommentTime26 Nov 2015

     
    Pinokio gdzie jesteś!!! :) Sektorami, boszze, co za bluźnierstwo
15. • 15:
       
      CommentAuthorpirx
    • CommentTime26 Nov 2015

     
    :)))))))))
16. • 16: CommentAuthorxxl
    • CommentTime26 Nov 2015

     
    wlaczenie turbo jesli drive obsluguje (nie trzeba ladowac jakiegos dodatkowego sterownika):
    
    lda xHSPEED
    bmi @+ ; brak turbo
    sta xSPEED
    jsr xBIOS_SET_DEFAULT_DEVICE
    @
    
    
    > Tak, xBios mógłby być tutaj dobrym rozwiązaniem. Niestety raczej nie wchodzi w grę, gdyż wymagałoby to kombinacji z wykrywaniem, czy gra jest uruchomiona w xB, czy w SDX (lub innym DOS) i stosowaniem albo SIO albo funkcji XXLa.
    
    rozwiazaniem jest sterownik :D - i masz obsluge xB spod CIO ale oczywiscie najlepiej jest:
    
    lda xBIOS_VERSION
    
    i w przypadku obecnosci korzystac z funkcji xB i zapomniec o CIO, nadal masz mozliwosc uruchamiania gry z dowolnego urzadzenia - tak z hdd tez. poindeksowac wszystkie pliki co zaowocuje tym, ze dostep do dowolnego pliku na nosniku (nie koniecznie dyskietki) nie bedzie wymagal otwierania czyli odczytu katalogu itp. albo wszystkie pliki leveli polaczyc w jeden duzy plik i zindeksowac go co rowniez daje dobry efekt - w tym przypadku masz 3 bajtowy wskaznik i tak samo dostep bez czytania katalogu - zaden dos w szybkosci tu nie pokona xB :D
    
    poza tym nie przywiazywalbym sie do SIO, korzystajac z funkcji xB dajesz mozliwosc userowi ze nagra sobie Twoja gre np. na kardrydz...
17. • 17: CommentAuthorpin
    • CommentTime26 Nov 2015

     
    @TeBe - już jestem, spokojnie :D
    
    @XXL - autor wyłuszczył Ci, czego nie chce. Jeśli chce mieć plikowy dostęp spod dowolnego DOS, to proponujesz niedowolny dostęp spod xB ;)
    
    

    XXL:

    poza tym nie przywiazywalbym sie do SIO, korzystajac z funkcji xB dajesz mozliwosc userowi ze nagra sobie Twoja gre np. na kardrydz...

    
    
    No i dajesz niepełnosprawny AtariDOS FS, znacznie wolniejszy od np. Sparta FS, a do tego wcale nie potrzeba określonej wersji dosa i Sparty X. Grę można wówczas zapisać w podkatalogu na HDD i wszystko działa bez zbędnych komplikacji.
18. • 18: CommentAuthorxxl
    • CommentTime26 Nov 2015

     
    jak zwykle zaklinasz rzeczywistosc ;-)
19. • 19: CommentAuthorbrx
    • CommentTime26 Nov 2015

     
    @Rafał
    
    

    Poza tym jak w takim rozwiązaniu zrealizować odczyt/zapis stanu gry?

    
    
    Jsk ktoś uruchomi to z DOSa, a DOS i OS zostaną w pamięci, to zapis powinien działać :) Jak ktoś grę uruchomi z np. loadera emulatora, to przy opcji zapisu z przyczyn oczywistych wszystko się wykrzaczy :] W tym wypadku trzeba by jakoś zapis zablokować, a użyszkodnicy emulców i tak mają zapis w dowolnym momencie :)
    
    

    To jak inaczej zrobić to na Atari? Na Atari bez EXT RAM

    
    
    Najprościej napisać skrypt coś w ten deseń:
    
    cat plik001 plik002 (...) plik100 > PLIKI.DAT
    
    (i wykonywać go po każdej zmianie w jakimś mniejszym pliku)
    
    Stworzy to jeden wielki plik z danymi z wielu mniejszych. Oczywiście samo to nic nie rozwiąże, potrzebny jest system obsługi takich danych. Można np. korzystając z dyrektywy .filesize() przy pomocy prostych obliczeń bardzo prosto, wręcz "w locie" przy asemblacji tworzyć statyczną tablicę adresów, jeśli taki połączony plik np. został gdzieś załadowany do pamięci.
    
    I tu aż się prosi, by w podobny sposób czytać pojedynczy plik (jego dane) z nośnika. Ale przy tworzeniu tablicy przesunięć i długości danych dla pliku na nośniku jest niestety gorzej, bo w starych DOSach nie podaje się intuicyjnego przesunięcia tylko sektor i bajt w sektorze, co pewnie da się ogarnąć, ale chyba nie jest wygodne. Dziś w Sparcie i XB jest już chyba "normalnie", aczkolwiek naprawdę przepraszam jeśli coś namieszałem, zupełnie nie czuję się specjalistą w tej dziedzinie...
    
    

    wciśnie się w 300kB.

    
    
    Trochę dużo... O.o To już dwa klasyczne dyski o dużej gęstości, a i klasyczne 320KB RAM zaczyna chyba być zagrożone. No chyba, że mówisz o danych jeszcze nie spakowanych.
20. • 20: CommentAuthorpin
    • CommentTime26 Nov 2015

     
    @XXL - podaję surowe dane podjęte z rzeczywistości ;)
21. • 21: CommentAuthorxxl
    • CommentTime27 Nov 2015

     
    @Rafal; a probowales spakowac dane inflate (stopien kompresji) lub lz4 (szybkosc dekompresji)?
22. • 22:
       
      CommentAuthormgr_inz_rafal
    • CommentTime27 Nov 2015 zmieniony

     
    Czytając powyższe dochodzę do wniosku, że jednak dobrą drogę wybrałem. Dobrą w tym sensie, że nie ma alternatywy, która byłaby prostsza do realizacji. Wystarczy mi teraz dowolny DOS, który obsługuje katalogi (turbo jest opcją) i można grać, a pomysły które padły to:
    

    pirx:

    czytać/zapisywać po sektorach

    
    Tu trzeba by się sporo narobić, tracąc kompatybilność z HDD i zyskując nie wiem ile, ale pewnie niedużo na prędkości. Podział na podkatalogi ładnie rozwiązuje szybkość otwierania plików.
    
    

    xxl:

    korzystac z funkcji xB (...) poindeksowac wszystkie pliki (...) wszystkie pliki leveli polaczyc w jeden duzy plik i zindeksowac

    
    Pewnie i by się dobrze sprawdziło, ale znowu robota wywracająca to co już mam do góry nogami. Do nowego projektu - czemu nie?
    
    

    brx:

    Najprościej napisać
    cat plik001 plik002 (...) plik100 > PLIKI.DAT
    Stworzy to jeden wielki plik z danymi... (...) jest niestety gorzej, bo w starych DOSach nie podaje się intuicyjnego przesunięcia tylko sektor i bajt w sektorze

    Coś jak "DOOM.WAD" :) Niby najprościej, ale jest poważny problem w "starych" (czyli wszystkich oprócz SDX) DOSach :)
    
    Najlepsze podsumowanie pre-factum wyszło pirxowi (cytat celowo zmanipulowany):

    pirx:

    najłatwiej to (...) Of kors development jest trudniejszy

    
    
    

    brx:

    No chyba, że mówisz o danych jeszcze nie spakowanych.

    
    

    xxl:

    a probowales spakowac dane inflate (stopien kompresji) lub lz4 (szybkosc dekompresji)?

    
    Nie próbowałem. Wydaje mi się, że nie jest to potrzebne. Porcje danych ładowane jednorazowo są małe (kilkaset bajtów) i wczytują się błyskawicznie. Problem zaczął się gdy namnożyło plików i sama operacja ich OTWARCIA trwała kilka sekund. Podział na podkatalogi pozwolił mocno zmniejszyć ten czas.
    
    Rozwinęła się w sumie ciekawa dyskusja, która pozwala mi nadrobić pewne zaległości wynikające z faktu, że nigdy nie miałem stacji dysków i w "najlepszych czasach" byłem typowym kasetownikiem :)
    
    Wydaje mi się, że obrana przeze mnie droga jest słuszna, czyli:
    - Spartanie kopiują sobie gierę gdzie chcą i grają SZYBKO
    - Pozostali montują sobie .atr-a (zapewne z MyDOSem) za pomocą SIO-2-COKOLWIEK i grają może trochę wolniej (chyba, że to turbo sugerowane przez CharlieChaplin wypali, czego niestety nie dałem rady wczoraj przetestować).
    
    A właściwie to tak szczerze... Kto w to będzie grał, hehe? 3 osoby przez 15 minut :)
23. • 23: CommentAuthorxxl
    • CommentTime27 Nov 2015 zmieniony

     
    > Czytając powyższe dochodzę do wniosku, że jednak dobrą drogę wybrałem. Dobrą w tym sensie, że nie ma alternatywy, która byłaby prostsza do realizacji.
    
    trudno sie nie zgodzic, optymalizacja nie jest prosta, najprostrzy jest upgrade sprzetu. nie dzala satysfakcjonujaco na standardowym drajwie - kup hdd.
    
    > Problem zaczął się gdy namnożyło plików i sama operacja ich OTWARCIA trwała kilka sekund. Podział na podkatalogi pozwolił mocno zmniejszyć ten czas.
    
    mozna ten czas wyeliminowac a nie zmniejszyc - caly czas dla pozadku trzymajac wszystkie pliki w dowolnej ilosci podkatalogow...
24. • 24:
       
      CommentAuthormgr_inz_rafal
    • CommentTime27 Nov 2015 zmieniony

     

    brx:

    Jak już gdzieś pisałem, jak gra potrzebuje więcej pamięci, zrób grę w jednopliku, to zwykle pójdzie na dowolnym dosie/loaderze (używaj RUN i INI do ładowania/kopiowania kolejnych "porcji" danych do banków)

    
    Tak jeszcze "dodatkowo dodam", że o ile się nie mylę, gra Ridiculous Reality padła ofiarą takiego podejścia. W sensie takim, że przez levele można iść tylko do przodu, a ominięcie kilku wymaga wygibasów z hasłami.
    
    

    xxl:

    mozna ten czas wyeliminowac a nie zmniejszyc - caly czas dla pozadku trzymajac wszystkie pliki w dowolnej ilosci podkatalogow...

    
    I to brzmi nieźle - o ile nie jest to tylko marketing :) Tak jak pisałem, teraz już za późno, ale w przyszłości chętnie się temu przyjrzę.
25. • 25: CommentAuthoras...
    • CommentTime27 Nov 2015

     
    @xxl słaba ta droga Twoja jest, buffowanie ścieżek przyspiesza nawet overmind-a czy totall....dase....
    hie hie...
26. • 26:
       
      CommentAuthorjhusak
    • CommentTime27 Nov 2015 zmieniony

     
    @mgr_in_rafal, jakbyś zmieścił grę w 256 kb to można by grać z mojego kartridża :)
    
    Spróbuj exomizerem spakować intro i grę i zobacz, ile się skompresuje. Rozkompresowywać się będzie kilka sekund.
    
    @tebe, nie wywołuj pinka z lasu. Ops.
27. • 27: CommentAuthormono
    • CommentTime27 Nov 2015

     
    @as: To nie ta warstwa.
    Buforowanie eliminuje oczekiwanie na fizyczny odczyt danych z nośnika, ale transfer do Atari i w DOS, i w xBIOS pozostaje taki sam. Ale nie każda stacja ma byforowanie ścieżek.
    Indeksowanie plików w xBIOS (i generalnie w AtariFS) powoduje, że mając nr sektora pliku i potrzebując dostępu strumieniowego po prostu czytasz TYLKO kolejne sektory pliku (AtariFS link do następnego sektora pliku ma właśnie na końcu sektora danych).
    SpartaFS ma tutaj słabiej, bo żeby dostać się do kolejnego sektora musisz albo:
    1. Trzymać w pamięci sektor mapy pliku (jak się skończy to odczytać kolejny do tegoż bufora) i czytać kolejne nry sektorów danych. Tak więc potrzeba dodatkowo tyle buforów o rozmiarze sektora ile jest otwartych równocześnie plików.
    2. Czytać naprzemiennie sektor mapy i sektor danych. Koszmarnie wolne :(
    xBIOS potrzebuje mieć tylko tyle słów pamięci (potrzebnych na nr sektora) ile jest jednocześnie otwartych plików.
    SpartaFS sprawdza się tam, gdzie trzeba szybko biegać po pliku w te i z powrotem do wyliczonych offsetów, których nie można wcześniej zbuforować. No i mamy miejsce w pamięci na bufory sektora mapy pliku.
    Ot wyszła zaleta AtariFS :)
28. • 28: CommentAuthorpin
    • CommentTime27 Nov 2015

     
    ... na szczęście jedyna ;)
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime28 Nov 2015 zmieniony

     
    O ile sobie przypominam, xb pozwala czytać pliki skompresowane i dekompresować je "w locie" - dla aplikacji są one już rozkompresowane.
    
    Można na 100% zejść poniżej 256 kB.
    
    Grałbym na takim kartridżu.
30. • 30:
       
      CommentAuthorpirx
    • CommentTime28 Nov 2015

     
    @mono - do spartaFS wymyśliliśmy z Pecusiem taki patent, że najpierw czytamy wszystkie mapy sektorów i trzymamy je "skompresowane" deltą - no wiesz, w większości przypadków lecą po prostu sektory jeden za drugim - wystarczy zapisać, ile sektorów czytać po kolei. W następnej kolejności jest przypadek, że trzeba przeskoczyć 1 sektor (mapy), albo kilka (fragmentacja). Summa summarum mapa dla całego pliku mieści się w kilku(nastu) bajtach. Ten patent jest użyty w MicroSpartaDOS.
31. • 31: CommentAuthormono
    • CommentTime28 Nov 2015

     
    @pirx: Ciekawe! Otwarcie pliku pewnie jest dość czasochłonne...
    W sumie to w jednym sektorze (256) mapy mieści się 126 sektorów pliku (32 KB prawie), więc dwa, trzy sektory mapy wystarczy każdemu :). Ciekawe ile to średnio zajmuje w takiej waszej kompresji.
    Co to znaczy "deltą"? Wyznaczaliście delty między nrami sektorów i pakowaliście ich ilość jak w RLE (taka dwupoziomowa kompresja)?
32. • 32:
       
      CommentAuthorpirx
    • CommentTime28 Nov 2015

     
    hej! nie pamiętam dokładnie, ale sprawa jest prosta -
    są 3 znaczniki
    jump to_sector_number
    skip n_sectors
    read n_consecutive_sectors
    
    zdaje się, że pierwsza sekwencja ma 3 bajty, pozostałe po bajcie (jakieś bity oznaczają sekwencję, reszta bitów to "n")
    
    W sumie tak zakodowana mapa ma zwykle kilka bajtów - pierwszy sektor i kilka razy po "read n_consecutive_sectors".
    Na baaaardzo pofragmentowanych dyskach to będzie ze 20 bajtów.
    Można spreparować dysk, na którym ta metoda będzie działać słabo - trzebaby nagrywać plik od wyższych nr sektorów do niższych - wtedy każdy sektor byłby opisany 3 bajtami i mogłoby to zająć za dużo pamięci.
33. • 33: CommentAuthorbrx
    • CommentTime28 Nov 2015

     
    @Rafał: Cóż, jak Ci starczy plików w DOS, to ok. Ale jeśli nie starczy, to i tak czy siak będziesz musiał coś pokombinować :]
    
    W Ridiculous Reality to chyba jakoś inaczej wyglądało, ktoś gdzieś kiedyś chyba wyjaśniał, ale zapomniałem. Zaś po załadowaniu danych do ram jest dostęp do nich w dowolnej chwili, pomijając pewne "subtelności" z przełączaniem banków.
    
    I naprawdę także polecam przeproszenie się z jakimś pakerem. Możesz na początek przetestować choćby prosty RLE, choć w pewnych warunkach z tym algorytmem będą problemy. Potem stocz długie boje z exomizerem i przetestuj kiedyś za mnie Bongo Crunchera ;-)
    
    ATR może mieć i 16MB, ale może jednak warto spróbować zmieścić grę na jednym bardziej klasycznym nośniku? Ba, może tak też się zdarzyć, że czas odczytu i depaku będzie krótszy niż odczyt niespakowanego pliku. A przy nowoczesnych algorytmach naprawdę nie ma już minut spędzonych przy napisie "Decrunching. Please wait..." :)
34. • 34:
       
      CommentAuthorPecus
    • CommentTime28 Nov 2015 zmieniony

     
    Po prostu zakładamy, że dysk nie jest pofragmentowany (fragmentacja na 8bit Atari - słyszał kto? :) ).
    
    W większości przypadków w systemie plików sparty ciągłość zapisu pliku w kolejnych sektorach psują sektory mapy :) . Co 126 ciągłość pliku przerywana jest sektorem mapy. W przypadku nagrania dyskietki "od podstaw" i plików nie przekraczających 126 sektorów długości (czyli 16kB dla sektora 128b lub 32kB dla sektora 256b) w zasadzie mapa jest zbędna - wystarczy znać numer pierwszego sektora i długość pliku. Długość mamy w directory a numer pierwszego sektora... no cóż ... on jest w pierwszym sektorze mapy, którego numer jest w directory.
    
    Zdaje się, że Draco w ostatnim SD-Load też zaimplementował "kompresję" mapy i zaoszczędził jeden bufor wielkości sektora.
35. • 35: CommentAuthorxxl
    • CommentTime29 Nov 2015

     
    AS: ale rozumiesz, ze chodzi o komunikacje miedzy komputerem a urzadzeniem? obecne urzadzenia sio2xx dzialaja jakby mialy zbuforowany caly nosnik ;-) a nie tylko sciezke.
    
    Pecus: pofragmentowane? tam gdzie sparta jest uzywana oczywiscie ze tak, a jesli mowimy o obrazach dyskietek to nie - tylko ze to jest obszar w ktorym nie uzywa sie sparty :D
    
    innymi slowy tam gdzie sparta jest uzywana problem jest nie do rozwiazania za to tam gdzie sparty sie nie uzywa problem nie istnieje ;-)
    
    Mono: jesli za zalete uwazasz mozliwos latwiejszego cofania wskaznika dostepu do pliku i tym tlumaczysz wykorzystywanie sparty fs i jego zapotrzebowania na bufory to chce zapytac jaki program z tego korzysta? :-) no wlasnie :-) jedyny ktory z takiego mechanizmu korzysta nie dziala ze sparta :-)
    pomijam ze cofanie do indeksowanych punktow jak w xB i tak jest szybsze...
    
    brx: xB ma mozliwosc uruchamiania programu z dowolnego miejsca w pliku (zaden dos tego nie ma) wiec w RR mogliby przskakiwac w przod czy tyl i uruchamiasz kod z pliku. problem nie istanieje READY[]
    
    Rafal: czy Twoja gra wlacza na czas komunikacji systemowe NMI?
36. • 36:
       
      CommentAuthorlarek
    • CommentTime29 Nov 2015 zmieniony

     

    Pecus:

    fragmentacja na 8bit Atari - słyszał kto? :)

    
    Tak. Avalon nawet wydał specjalny program, który pozwalał na przeprowadzenie defragmentacji dyskietki - Szperacz dyskowy
    
    

    TA 1-2,93:

    Optymalizacja dysku. Po poprawnym zakończeniu tej operacji wszystkie dane jednego pliku są zgrupowane w jednym rejonie dyskietki, co w przypadku długich plików znacznie przyspiesza ich odczyt.
37. • 37:
       
      CommentAuthorPecus
    • CommentTime29 Nov 2015

     
    xxl: tam gdzie sparty sie nie uzywa problem nie istnieje ;-)
    
    To nagraj na dyskietce w dowolnym formacie 2 pliki o długości np. 200b każdy, potem skasuj pierwszy z nich i nagraj nowy... powiedzmy 1kb.
    Problem nie istnieje???
38. • 38: CommentAuthormono
    • CommentTime29 Nov 2015

     
    @xxl: Na szczęście zawsze można napisać nowy program a wtedy SpartaFS się przyda, bo ma dobrze rozwiązane SEEK/TELL (xBIOS zresztą chyba też nienajgorzej). Standardowe AtariDOS-y tutaj niestety się nie popisały :/
39. • 39: CommentAuthorxxl
    • CommentTime29 Nov 2015

     
    @Pecus oczywiscie ze nie istnieje :-)
    wezmy pod uwage:
    1. atari dos fs: fragmentacja przy nowych urzadzeniach w zaden sposob nie wplywa na dzialanie, przy starszych (oryginalnych) urzadzeniach wplynie na szybkosc np. odczytu i tylko tyle.
    2. sparta dos fs: fragmentacja wplynie niekorzystnie na nowszych i staszych urzadzeniach przy czym na nowszych objawi sie problem z mapa o ktorym pisal Pirx i Ty :-)
    
    jak widzisz... zrodlem problemu potrafi byc juz nawet nie jest fragmentacja ale sam sparta dos fs :D
40. • 40: CommentAuthorpin
    • CommentTime29 Nov 2015

     
    XXL - owe "dolegliwości" nie są bolesne. Wystarczy mieć odpowiednie medium do I/O i raz na zawsze można się wyleczyć z Atari dos FS ;)
41. • 41:
       
      CommentAuthorpirx
    • CommentTime30 Nov 2015

     
    Problem z mapą w SpartaFS jest czysto teoretyczny - wystąpi jeśli się specjalnie spreparuje dyskietkię tak, żeby wystąpił. A i tak "problem" będzie polegał wyłącznie na tym, że nie zaoszczędzi się miejsca w pamięci, bo do tego ta kompresja mapy sektorów ma służyć (SpartaFS tez tego tryku wymaga bufora na mapę sektorów, co w przypadku sektora 512b kosztuje tyleż). Nie będzie zysku, jeśli nagra się plik długości > 170 sektorów sektor po sektorze z malejącymi numerami sektorów. W sumie to żeby spreparować taki dysk trzebaby napisać utilkę, bo ręcznie to by było męczące :]
42. • 42:
       
      CommentAuthormgr_inz_rafal
    • CommentTime1 Dec 2015

     

    xxl:

    Rafal: czy Twoja gra wlacza na czas komunikacji systemowe NMI?

    Ja? Hmm... Ja wyłączam na czas komunikacji DLI. W VBI nie ingeruję.
    
    Nie wiem, czy o to chodziło, bo słabo ogarniam temat :)
43. • 43:
       
      CommentAuthormgr_inz_rafal
    • CommentTime10 Dec 2015 zmieniony

     
    CharlieChaplin,
    I'm working on the MyDos you suggested
    ->link<-
    but I can't get it to autorun anything.
    
    Tried renaming file to autorun.sys or *.ar0, but no luck. Can you suggest something?
44. • 44: CommentAuthorCharlieChaplin
    • CommentTime10 Dec 2015

     
    Strange.
    
    Alright, configured MyDOS for 320k Rambo (option "O" in the menu, followed by Return; if you type a number 1-9 it will configure a floppy/hard drive instead of DOS and Ramdisk).
    
    Then renamed Myramd.AUT into Myramd.AR0 and Ultraspd.AUT into Ultraspd.AR1. When I reboot with the emulator, the first Autorun (*.AR0 = the ramdisk driver) is executed and DUP.SYS is copied to drive 8.
    
    The second Autorun (*.AR1 = ultraspeed driver) seems not to execute, but maybe its a false behaviour of Atari800 WinPlus, have to test it on the real Atari. But I know it worked in the past and I do have a 5,25" diskette with MyDOS configured for my 576k Atari and a Speedy 1050 with ultraspeed that works fine. The version I uploaded is however a newer version, than the one I have on 5,25" diskette, maybe something is broken with the newer version - will test it asap and report then...
45. • 45:
       
      CommentAuthormgr_inz_rafal
    • CommentTime10 Dec 2015

     
    Thanks, I will also investigate a little bit more during the weekend.
46. • 46:
       
      CommentAuthorjhusak
    • CommentTime11 Dec 2015 zmieniony

     
    @mgr, ile masz jeszcze wolnej pamięci?
47. • 47:
       
      CommentAuthormgr_inz_rafal
    • CommentTime11 Dec 2015

     
    Nie wiem dokładnie. Czekam jeszcze na część muzyki i grafiki.
48. • 48: CommentAuthorCharlieChaplin
    • CommentTime13 Dec 2015

     
    Alright,
    
    looks like the latest/newest version of MyDOS (MyDOS 4.55 Beta 4 updated by Lee Barnes) has some bugs. It does not boot on my real A8 (800XL) anymore, while it works okay with Atari 800 Win+.
    
    Okay, here is an older version (it is MyDOS 4.55, but I am not sure if it is Beta 1, 2 or 3) which works alright on my real A8. MyDOS automatically executes the Ramdisk driver (*.AR0), then the ultraspeed driver (*.AR1), if an ultraspeed drive is found. Next, DUP.SYS is loaded - but you could simply add your program as *.AR2 if you wish...
    
    Instead of the ramdisk driver you could also use the Batchfile enhancement by Thorsten Karwoth to format the ramdisk, copy one or more files to the ramdisk and then execute your program(s).

    • MYDOSUS.ATR
49. • 49:
       
      CommentAuthormgr_inz_rafal
    • CommentTime13 Dec 2015 zmieniony

     
    So the autostart issue is resolved, it now works as expected.
    
    Moreover, when I load the ultraspeed driver, the transmission from SIO2SD is nicely boosted.
    
    However :)
    The speed boost only lasts for the first load event. First I load the .xex file which displays the g2f pic and plays music. This is on ultraspeed.
    
    After user presses a key the main game is loaded, unfortunately using the standard speed :/
    (game loader is written using the standard CIO calls.)
    
    What would be next to check?
    1. Whether the g2f pic somehow disables the ultraspeed driver (by altering portb, maybe)?
    2. Whether I need to modify my loader code so it somehow uses the driver? I thought it's up to DOS to decide which driver to use, but I may be terribly wrong.
50. • 50: CommentAuthorCharlieChaplin
    • CommentTime13 Dec 2015

     
    Yes,
    
    I guess so - whenever port B is altered, then the ultraspeed driver is disabled. Thus TB XL, TB XL Runtime and other programs that require RAM under the OS or XRAM will most likely not work with this driver.
    
    Since MyDOS does not have any fast SIO (ultraspeed, XF highspeed, turbospeed, etc.) built-in you have to use an external driver. Luckily, when your drive does not have ultraspeed, the driver does not hang up the system, but load with normal speed instead...