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: CommentAuthorxxl
   • CommentTime30 Oct 2019 15:10

    
   topic successfully trolled ;-)
2. • 2:
      
     CommentAuthorMq
   • CommentTime30 Oct 2019 19:10

    
   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. • 3:
      
     CommentAuthorKaz
   • CommentTime30 Oct 2019 20:10

    
   Z tym, że koncepcja mini-DOSa wyklucza uniwersalność, wieloformatowość, etc. Jak ktoś udowodni, że jest inaczej, to czapki pójdą z głów :)
4. • 4: CommentAuthortebe
   • CommentTime30 Oct 2019 20:10

    
   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. • 5:
      
     CommentAuthorDracon
   • CommentTime30 Oct 2019 20:10 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. • 6: CommentAuthorpin
   • CommentTime30 Oct 2019 21:10

    
   @Dracon - a jakie MemLo zwraca BeWeDos? $2000? ... no właśnie
   
   Bo MyIDE jest złe? ;)
7. • 7:
      
     CommentAuthorKaz
   • CommentTime31 Oct 2019 04:10 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. • 8: CommentAuthorpin
   • CommentTime31 Oct 2019 08:10

    
   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. • 9:
      
     CommentAuthorKaz
   • CommentTime31 Oct 2019 18:10 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. • 10: CommentAuthorpin
    • CommentTime31 Oct 2019 23:10 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. • 11: CommentAuthorxxl
    • CommentTime1 Nov 2019 15:11 zmieniony

     
    istnieje prawdopodobienstwo, ze LiteDOS bedzie ladowal programy spakowane LZ4.

    • LD-LZ4.jpg
      
      
      
      
12. • 12:
       
      CommentAuthorKaz
    • CommentTime2 Nov 2019 08:11

     
    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. • 13: CommentAuthorxxl
    • CommentTime11 Nov 2019 14:11

     
    jest potwierdzenie:
    
    "LiteDOS 3.00 will have LZ4 decompression build-in the file loading routines."
14. • 14: CommentAuthorbob_er
    • CommentTime11 Nov 2019 14:11

     
    A jak on takie binarki rozpoznaje?
15. • 15: CommentAuthorxxl
    • CommentTime11 Nov 2019 14:11 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. • 16: CommentAuthorbob_er
    • CommentTime11 Nov 2019 16:11

     
    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. • 17: CommentAuthorxxl
    • CommentTime11 Nov 2019 17:11

     
    moze w sparcie tez warto zaimplementowac tworzac kolejny identfikator :-)
18. • 18: CommentAuthormono
    • CommentTime11 Nov 2019 21:11

     
    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. • 19: CommentAuthorxxl
    • CommentTime11 Nov 2019 22:11

     
    nareszcie jakis postep :-)
20. • 20: CommentAuthorxxl
    • CommentTime4 Jan 2020 11:01

     
    ->link<-
    
    wlasnie sie pojawil LiteDOS3 - ten juz laduje binarki ze spakowanmi blokami.
21. • 21:
       
      CommentAuthorshanti77
    • CommentTime4 Jan 2020 16:01

     
    Obecnie wielkość pliku nie ma wielkiego znaczenia, chyba że ktoś wczytuje grę w normalu z kasety.
22. • 22: CommentAuthorxxl
    • CommentTime4 Jan 2020 17:01

     
    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. • 23:
       
      CommentAuthorshanti77
    • CommentTime4 Jan 2020 20:01

     
    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. • 24: CommentAuthorxxl
    • CommentTime4 Jan 2020 20:01

     
    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. • 25:
       
      CommentAuthorKaz
    • CommentTime8 Jan 2020 10:01

     
    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.

    • LiteDUP.mp4
26. • 26: CommentAuthorpin
    • CommentTime8 Jan 2020 11:01

     
    Ale nie bankowanych.
27. • 27: CommentAuthorxxl
    • CommentTime8 Jan 2020 12:01

     
    bardzo fajny pomysl tym bardziej ze realizacja jest dosyc prosta:
    ->link<-
    
    dziwne ze inne dosy tego nie maja...
28. • 28: CommentAuthorpin
    • CommentTime8 Jan 2020 13:01 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. • 29: CommentAuthorxxl
    • CommentTime8 Jan 2020 16:01

     
    to jak uswiadamiac murzyna ze musi pracowac.
30. • 30:
       
      CommentAuthorKaz
    • CommentTime25 Jan 2020 23:01 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.

    • lite1.jpg
      
      
      
      
    • lite2.jpg
      
      
      
      
31. • 31: CommentAuthorpin
    • CommentTime25 Jan 2020 23:01

     
    Super! Konkurencja rośnie! ;)
32. • 32:
       
      CommentAuthorKaz
    • CommentTime31 Jan 2020 13:01 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...

    • FB_IMG_1580472222044.jpg
      
      
      
      
    • FB_IMG_1580472219561.jpg
      
      
      
      
33. • 33:
       
      CommentAuthorKaz
    • CommentTime18 Jul 2020 19:07

     
    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. • 34:
       
      CommentAuthorKaz
    • CommentTime28 Jul 2020 13:07

     
    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. • 35: CommentAuthormono
    • CommentTime29 Jul 2020 12:07

     
    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. • 36:
       
      CommentAuthorKaz
    • CommentTime29 Jul 2020 14:07

     
    Dzięki Mono za szczegółowy opis. Zaraportowałem problem do autora (którym jest Sijmen Schouten).
37. • 37: CommentAuthorxxl
    • CommentTime29 Jul 2020 17:07

     
    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. • 38: CommentAuthormono
    • CommentTime29 Jul 2020 17:07

     
    @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. • 39:
       
      CommentAuthorKaz
    • CommentTime9 Aug 2020 05:08

     
    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. • 40:
       
      CommentAuthorjhusak
    • CommentTime9 Aug 2020 10:08 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. • 41: CommentAuthorxxl
    • CommentTime10 Aug 2020 13:08

     
    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. • 42: CommentAuthormono
    • CommentTime10 Aug 2020 21:08

     
    @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. • 43: CommentAuthormr-atari
    • CommentTime11 Aug 2020 10:08

     
    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.
44. • 44:
       
      CommentAuthorKaz
    • CommentTime9 Oct 2020 23:10 zmieniony

     
    Jest i wersja 3.06:
    
    

    mr-atari:

    -5 digit output on disksize
    -Loading obj-files using XIO 39 command (LZ4-support)
    -LiteROMEMU supporting more soft-cartridges

    • LD1.jpg
      
      
      
      
    • LD2.jpg
      
      
      
      
45. • 45: CommentAuthorxxl
    • CommentTime18 Oct 2020 23:10

     
    tak wyglada ladowanie spakowanch binarek z Basica:
    
    
46. • 46: CommentAuthormono
    • CommentTime12 Dec 2020 02:12 zmieniony

     
    Zaktualizowałem informacje o bloku nazwy wprowadzanego przez NCOPY: ->link<-
47. • 47: CommentAuthorflashjazzcat
    • CommentTime12 Dec 2020 19:12

     
    AMAC used to rely on the status = 3 upon reading last byte of the file; this is the reason I originally mentioned it to Konrad a few years back (I don't know if that was the only reason AMAC didn't work with SDX back in the day, though).
48. • 48:
       
      CommentAuthorKaz
    • CommentTime13 Dec 2020 14:12

     
    Warto dodać, że jest już wersja 3.07:
    
    

    Mr.Atari:

    LiteDOS 3.07 now online, please update your disk(s)
    ->link<-
    NEW:
    Fixed "disappearing sectors when error occurs during save"
    Fixed hidden feature that loads files from subdirectories
    Added C to the internal command-line, Exit to Cartridge (cleared memory)
    Added SIO2BT support in LiteHSIO.DRV
    
    Still working on the enhanced LiteDUP, pain in the ass....
49. • 49: CommentAuthorpin
    • CommentTime22 Jan 2021 22:01

     
    .. i pytanie z tym związane. Czy ktoś może mi potwierdzić, że aktualny obraz z LiteDOS ładuje się np. ze SIO2SD?
    
    Mam z tym ATR'em jakiś dziwny problem, sio2sd próbuje ładować ten ATR loaderem do xex'ów i nie bardzo rozumiem ten stan rzeczy.
50. • 50: CommentAuthorpin
    • CommentTime22 Jan 2021 22:01

     
    wersja 2.x ładuje się niby normalnie, ale każda próba operacji I/O kończy się błędem 168. Hardware w tym momencie to 130xe, U1mb (1088 rambo), xlos, sio2sd.