atarionline.pl LiteDOS - 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.

    • 1: CommentAuthorxxl
    • CommentTime30 Oct 2019
     
    topic successfully trolled ;-)
    • 2: CommentAuthorMq
    • CommentTime30 Oct 2019
     
    Eee tam xxl, nie przesadzaj. Temat jest nadal ten sam: zaczęło się od LiteDOS, a równolegle dopowiadamy, że przydał by się taki LiteDOS, ale być może z obsługą innych formatów dyskietek - czyli gadamy ogólnie o tematyce DOS-a w wersji Lite. Rękawica była podnoszona w temacie, że niby bez sensu - ja nie uważam, że bez sensu, dlatego piszę co myślę ogólnie o temacie. LiteDOS jest fajną koncepcją, ale formaty dyskietek i współpracy ze sobą DOS-ów wzajemnie są równie ważne. Dziś nie jesteśmy konkurencyjnymi firmami, żeby robić sobie nawzajem pod górkę, a soft powinien wg mnie umieć ze sobą współpracować i dawać ludziom możliwość wyboru i przesiadek z jednego na drugi.
    • 3:
       
      CommentAuthorKaz
    • CommentTime30 Oct 2019
     
    Z tym, że koncepcja mini-DOSa wyklucza uniwersalność, wieloformatowość, etc. Jak ktoś udowodni, że jest inaczej, to czapki pójdą z głów :)
    • 4: CommentAuthortebe
    • CommentTime30 Oct 2019
     
    ogólnie chłopak nie powinien był udostępniać LiteDos-a, powinien był go zachować tylko i wyłącznie dla siebie, nawet nie było tematu :P
    • 5:
       
      CommentAuthorDracon
    • CommentTime30 Oct 2019 zmieniony
     
    Dyskusja także o "okrojonej" Sparcie dla zwykłych ludzi...A BeWeDosa używali??? ;) :P

    A taka ciekawostka, autor LiteDosa kiedyś popełnił i promował rozwiązanie MyIde, bardzooo zje***e przez elitę atarowską w PL (antydema "MyIde demo 1 i 2"). Nawet chyba Lotharkowi kiedyś się dostało za to, że to komuś montował... ;)
    • 6: CommentAuthorpin
    • CommentTime30 Oct 2019
     
    @Dracon - a jakie MemLo zwraca BeWeDos? $2000? ... no właśnie

    Bo MyIDE jest złe? ;)
    • 7:
       
      CommentAuthorKaz
    • CommentTime31 Oct 2019 zmieniony
     

    Dracon:

    Dyskusja także o "okrojonej" Sparcie dla zwykłych ludzi...A BeWeDosa używali??? ;) :P


    BeWeDOS był wspominany w tym wątku już dwa razy. I tyleż razy go w życiu użyłem. Ale jak napisał Pin - nie ma startu do LiteDOSa, jeśli chodzi o dostępną pamięć.
    LiteDOS - $1000
    BeWeDOS - $2000

    Pin:

    Bo MyIDE jest złe? ;)


    Pomijając temat, czy naprawdę jest złe, czy tylko komuś się nie podoba z jakiegoś względu, to może po prostu komuś marzy się komunizm i jedynie słuszne rozwiązania? :)

    Jak ktoś miał ochotę zrobić MyIDE to jego sprawa, a jak ktoś chce tego używać to też jego sprawa. Każde rozwiązanie ma swoje wady i zalety, więc lepiej mieć więcej opcji w życiu niż mniej.
    • 8: CommentAuthorpin
    • CommentTime31 Oct 2019
     
    No to dziwne, bo do dziś nikt tego nie chce używać. To urządzenie nie jest w stanie np. wykonać boot z partyji.
    • 9:
       
      CommentAuthorKaz
    • CommentTime31 Oct 2019 zmieniony
     
    Nie wiem, kto to jest "nikt", ale na forum dedykowanym między innymi MyIDE jest wiele osób, które korzysta i sobie chwalą:

    ->link<-

    Jeżeli chodzi o boot z partycji, to może próbujesz to robić przez Reset zamiast SHIFT+CONTROL+ESC, jak zaleca autor?

    Tu masz opis Zaxona do starszej wersji urządzenia MyIDE, a jest już przecież i MyIDE II, wersja 4:

    ->link<-
    • 10: CommentAuthorpin
    • CommentTime31 Oct 2019 zmieniony
     

    AOL/Zaxxon:

    Wymieniłem ROM Atari XEGS na EPROM 27C512, ze zmodyfikowanym systemem dla MyIDE oraz z oryginalnym systemem XEGS i dodałem przełącznik wyboru systemu.


    pin:

    To urządzenie nie jest w stanie np. wykonać boot z partyji.


    Dopiszę. Samodzielnie, bez ingerencji w rom. Tzn generalnie nie wiążę z tą kwestią jakichkolwiek emocji bo sprzęt lubię wzbogacać o różności, kwestia o MyIDE była tak dla zjebu z uśmieszkiem dodana, przypominam. Kaz - nie masz chyba aspargera? ;)
    • 11: CommentAuthorxxl
    • CommentTime1 Nov 2019 zmieniony
     
    istnieje prawdopodobienstwo, ze LiteDOS bedzie ladowal programy spakowane LZ4.
    • 12:
       
      CommentAuthorKaz
    • CommentTime2 Nov 2019
     
    Tak, autor mi też napisał, że właśnie nad tym pracuje.

    A jeżeli chodzi o filesystem Sparty to przyjrzał się temu i niestety, nie będzie LiteDOS tego wspierał, za duże różnice, za dużo by miejsca zajęła obsługa.
    • 13: CommentAuthorxxl
    • CommentTime11 Nov 2019
     
    jest potwierdzenie:

    "LiteDOS 3.00 will have LZ4 decompression build-in the file loading routines."
    • 14: CommentAuthorbob_er
    • CommentTime11 Nov 2019
     
    A jak on takie binarki rozpoznaje?
    • 15: CommentAuthorxxl
    • CommentTime11 Nov 2019 zmieniony
     
    ->link<-

    ==
    w skrocie (najprostszy przyklad): plik binarn ma budowe identyfikator, nalowek, dane, identfikator, nalowek, dane... identfikatory poza pierwszym sa opcjonalne (jak sie pojawiaja niektore spesudoloadery maja z tym problem). nalowek ma postac adres poczatku, adres konca (po 2 bajty), blok spakowany ma adres konca wyzerowany, to dla loadera oznacza przekaz kontrole do dekompresora a kolejne dane mowia co to za kompresor i ile danych, nastepnie cykl sie powtarza, kolejny nalowek itd.

    jest tu pare skrotow myslowch ale mysle ze wiesz o co chodzi.
    • 16: CommentAuthorbob_er
    • CommentTime11 Nov 2019
     
    Znalazłem to u konkurencji :).
    Osobiście, gdybym miał marudzić, to bym pomarudził, że inny nagłówek (coś innego niż standardowe FFFF i spartowe FEFF-FAFF) byłby lepszym wyróżnikiem niż koniec adresu 0000. No, ale nie będę marudził, bo nie planuję używać w najbliższym czasie ani XBIOSa ani LiteDOSa.
    • 17: CommentAuthorxxl
    • CommentTime11 Nov 2019
     
    moze w sparcie tez warto zaimplementowac tworzac kolejny identfikator :-)
    • 18: CommentAuthormono
    • CommentTime11 Nov 2019
     
    To nie jest wykluczone. Nawet zastanawiałem się nad rozszerzaniem loadera SDX np. o ładowanie plików ACX.

    Przypomnę może mało znaną rzecz. JBW kiedy robił COS-a którego używano w produkcjach Avalonowych wymyślił sobie rozszerzenie kompatybilne z formatem COM.
    On w swoim COS-ie umożliwiał dodanie nazwy programu ładowanego z taśmy. Taki plik mógł być zapisany programem NCOPY.
    Działało to tak, że pierwszy nagłówek pliku lokował nazwę programu w obszarze $100..$10F jeśli dobrze pamiętam. Loader w COS-ie sprawdzał czy tam załadowano cokolwiek i pokazywał to na ekranie.
    W przypadku kiedy DOS ładował taki plik, no to po prostu nazwa ładowała się w obszar stosu i nic się nie działo. Ale COS to obsługiwał.
    Co najfajniejsze to jest to normalny mechanizm, jaki wykorzystuje zwykły format COM do ustalania adresów INIT (adres w obszarze $2E2..$2E3) i RUN ($2E0..$2E1).
    • 19: CommentAuthorxxl
    • CommentTime11 Nov 2019
     
    nareszcie jakis postep :-)
    • 20: CommentAuthorxxl
    • CommentTime4 Jan 2020
     
    ->link<-

    wlasnie sie pojawil LiteDOS3 - ten juz laduje binarki ze spakowanmi blokami.
    • 21:
       
      CommentAuthorshanti77
    • CommentTime4 Jan 2020
     
    Obecnie wielkość pliku nie ma wielkiego znaczenia, chyba że ktoś wczytuje grę w normalu z kasety.
    • 22: CommentAuthorxxl
    • CommentTime4 Jan 2020
     
    nie zodze sie z Toba, ma znaczenie. mam przyklad: user chce wydac gre na karcie ktora miesci sie w atr, ma do wyboru wiekszy kart lub kompresja pliku binarnego ...
    • 23:
       
      CommentAuthorshanti77
    • CommentTime4 Jan 2020
     
    Ale mi chodzi o dekompresję pliku w czasie wczytywania, jak rozumiem po wczytaniu takiego pliku program jest już rozpakowany. Dekompresję dopiero po wczytaniu pliku można wykorzystać do wyświetlenia np. obrazka podczas wczytywania, jakiegoś intra przed grą czy trainera.
    • 24: CommentAuthorxxl
    • CommentTime4 Jan 2020
     
    no ale czy w czasie ladowania czy po, caly czas mowimy o danych spakowanych wiec na dysku zajmuja mniej miejsca, za wersja dekompresji podczas ladowania przemawia to ze nie potrzeba ladowac samego dekompresora ale rozumiem, ze sa przypadki w ktorych moze byc potrzeba zaladowania do pamieci danych skompresowanych mimo, ze beda uzyte tylko raz...
    • 25:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020
     
    Autor zaczął pracować nad kolejną funkcjonalnością, ładowaniem i uruchamianiem plików ROM, cytuję z fejsa:

    New development in LiteDUP 3.x :-D
    (just a teaser for the next update)
    Loading .ROM files and emulating them !


    Filmik w załączeniu.
    • 26: CommentAuthorpin
    • CommentTime8 Jan 2020
     
    Ale nie bankowanych.
    • 27: CommentAuthorxxl
    • CommentTime8 Jan 2020
     
    bardzo fajny pomysl tym bardziej ze realizacja jest dosyc prosta:
    ->link<-

    dziwne ze inne dosy tego nie maja...
    • 28: CommentAuthorpin
    • CommentTime8 Jan 2020 zmieniony
     
    Bo pewnie nie było takiej potrzeby. Są jakieś logicznie określone okoliczności uzasadniające tworzenie wspomnianej funkcjonalności? Pytam, bo może są a nie wiem ;)
    • 29: CommentAuthorxxl
    • CommentTime8 Jan 2020
     
    to jak uswiadamiac murzyna ze musi pracowac.
    • 30:
       
      CommentAuthorKaz
    • CommentTime25 Jan 2020 zmieniony
     
    Nowość w LiteDOS, obsługa ram-disku dla 130XE, jest też używlny dla użytkowników 800XL/XE w Basicu.

    Working on LiteDOS 3, Adding 130XE-RamDisk.
    User-request from Peter Pedro Jochec.
    Reduces free memory by 163 bytes....
    Also usable for 800XL/XE users working with Basic.
    • 31: CommentAuthorpin
    • CommentTime25 Jan 2020
     
    Super! Konkurencja rośnie! ;)
    • 32:
       
      CommentAuthorKaz
    • CommentTime31 Jan 2020 zmieniony
     
    I kolejne usprawnienia:

    LiteDOS 3.01 update:
    LiteRD (ramdisk), added the 14k RAM under the OS.
    Detectable and installed sizes are now, 64k 130XE, 22k 800XL/800XE (with internal BASIC) or 14k 1200XL/800XL with cartridge plugged in.

    Added Copy to E: (request of Martin Panhuis)
    Other devices, like R:, will work just fine too. :-)

    Still a lot to do...
    • 33:
       
      CommentAuthorKaz
    • CommentTime18 Jul 2020
     
    I kolejne poprawki, teraz mamy wersję 3.03:

    ->link<-

    Fixed:
    Filenames without 3 character-extension being seen as error-165
    Compatibility issues with Mini-Office, Last Word.
    Added the ability to access other devices then D: in the build-in command-line.

    Notes:
    Sectors 1-15 are reserved as "bootsectors" on SD-disks / SD-partitons.
    Sectors 1-10 are reserved as "bootsectors" on DD-disks / DD-partitons.
    Sectors 1-3 + 1026-1039 are reserved as "bootsectors" MD-disks.
    • 34:
       
      CommentAuthorKaz
    • CommentTime28 Jul 2020
     
    Tbxx chyba znalazł błąd w LiteDOS. Przy odczycie komendą BLOAD w Turbo Basic XL zwracany jest Error 136 ($88), chociaż plik istnieje i jest poprawny. Rozmawiałem z Mono, który zasugerował, że LiteDOS nie obsługuje pełnego protokołu DOS, stąd problem - Turob Basic nie zauważa, że nastąpił koniec pliku. Podobna sprawa była ze SpartąDOS, którą łatał Draco030.

    Mono - zgłośmy to autorowi.
    • 35: CommentAuthormono
    • CommentTime29 Jul 2020
     
    Nie używałem LiteDOS-a jeszcze, ale zagadnąłem Draco jaką poprawkę wprowadzał do sterownika D: w SDX tak, aby poprawnie współpracował z TBXL 1.5 i okazało się, że DOS 2.x zachowuje się następująco:

    1. Mamy do załadowania plik o przykładowej długości $236.
    2. Ładujemy go do pamięci przy pomocy bufora o długości $200.
    3. Ustawiamy IOCB gdzie podajemy długość bufora ICBUFL=$200 i czytamy fragment pliku - w wyniku otrzymujemy status 1 a DOS zwraca nam w ICBUFL ilość załadowanych danych równą $200.
    4. Ustawiamy ICBUFL na $200 i ładujemy resztę pliku - w wyniku otrzymujemy status 3 (!) a DOS w ICBUFL zwraca nam ilość odczytanych danych równą $36.
    5. Każdy kolejny odczyt z pliku zwróci status $88 czyli EOF.

    Prawdopodobnie LiteDOS nie zwraca 3 kiedy odczytał dokładnie resztkę pliku, ale 1.
    • 36:
       
      CommentAuthorKaz
    • CommentTime29 Jul 2020
     
    Dzięki Mono za szczegółowy opis. Zaraportowałem problem do autora (którym jest Sijmen Schouten).
    • 37: CommentAuthorxxl
    • CommentTime29 Jul 2020
     
    DOS 2 FS przechowuje w sektorze link oraz bajt wpelnienia, sektor zawsze odczytywany jest w calosci (nawet te bajty POZA dlugoscia pliku) a wiec:

    4. status 3 nie otrzymujemy po zaladowaniu do bufora ostatniego "kawalka" bloku tylko PO odczytaniu OSTATNIEGO bajtu nalezacego do pliku z bufora.

    wyglada to tak:
    odczytywany jest bajt z bufora, zwiekszany wskaznik odczytu kolejnego bajtu z sektora, sprawdzany link (czy to ostatni sektor pliku) i W TYM MOMENCIE porownywany ze wskaznikiem wypelnienia i dopiero teraz nastepuje decyzja status 3 lub status 1.

    widzialem tylko jeden loader dla dos2fs ktory nie opiera sie na blednym odczycie ostatniego bajtu pliku (czyli wlasnie PO odczytaniu bajtu sprawdza czy byl to ostatni bajt). DOS2.5 sprawdza przed i po odczycie.
    • 38: CommentAuthormono
    • CommentTime29 Jul 2020
     
    @xxl: Mówisz o buforze dla operacji SIO, a ja mówię o buforze operacji CIO. Ale poza tym to oczywiście masz rację. 3 zwracana jest kiedy właśnie odczytano wszystkie bajty z pliku, 1 kiedy plik odczytano częściowo (jest coś jeszcze do odczytania), a $88 kiedy już nie ma nic do odczytu (wcześniej odczytano wszystko).
    • 39:
       
      CommentAuthorKaz
    • CommentTime5 dni temu
     
    Chciałem tu dodać, że korespondowałem z autorem (Sijmen Schouten), który reaguje na bieżąco i jest bardzo pomocny - i sprawa wygląda na rozwiązaną, przynajmniej dla naszego przypadku :D
    • 40:
       
      CommentAuthorjhusak
    • CommentTime4 dni temu zmieniony
     
    IMHO ten sposób jest dziwny, powoduje spowolnienie operacji odczytu, bo trzeba sprawdzać zarówno przed (czy nie wystąpił eof), jak i po (czy właśnie nie nastąpił eof). Czy stosuje się takie podejście w innych systemach? W unixach nie o ile wiem.
    • 41: CommentAuthorxxl
    • CommentTime3 dni temu
     
    bufor SIO musi zostac bezwzglednie wypelniony bo inaczej bedzie blad transmisji, zreszta taki jest protokol. status 3 nie ma zwiazku z transmisja miedzy urzadzeniami.

    @jhusak: mozna tak powiedziec ale nie calkiem jest to pozbawione sensu. jakie masz zabezpiecznie zeby nie poszukiwac kolejnego naglowka bloku w pliku binarnym?
    • 42: CommentAuthormono
    • CommentTime3 dni temu
     
    @jhusak: Od strony użytkownika korzystającego z CIO nic się nie zmienia, bo dopiero próba odczytania pierwszego bajtu którego nie ma kończy się statusem $88. Ciężar obsługi statusów $01 i $03 leży w sterowniku D:.
    • 43: CommentAuthormr-atari
    • CommentTime2 dni temu
     
    Hi all,

    To be of help, I joined the forum.
    Remember i can not read polish....
    Chrome is set to automatically translate to English.

    About the y=3 'problem', it is not specified by the atari-os-layout (Atari Disk Operating System Reference Manual, atari-800-technical-reference-notes) to have any other value then 1 or error (negative) passed through. For now I have set y=3, but in theory when the block is loaded and the next byte is EOF, you are done.

    LiteDOS is based on these documents, for compatibility reasons I can modify to coop with these flaws.

    Thanks for the feedback, 3.04 is now online.

    Grtz!
    Sijmen.