atarionline.pl xBoot DOS - 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.

6. Użytki / Utils  »   xBoot DOS

W dół

Od 51 do 100 z 124

  1. <
  2. 1
  3. 2
  4. 3
  5. >
    • 1: CommentAuthorxxl
    • CommentTime27 Apr 2020 zmieniony
     
    ale po co "sticky"? nie sa wazne numery sektorow... absolutnie nie ruszalbym wpisow directory i statusu

    natomiast nie wiem czy dosy radza sobie z plikami ktore maja mniej danych znaczacych w sektorach innych niz ostatni sektor.
    spodziewam sie ze nie bo dosy obsluguja zmiene dlugosci pliku (bez ingerencji w VTOC) tylko w obrebie jednego ostatniego sektora a tu jestesm ograniczeni nie wielkoscia jedneo sektora tylko wielkoscia calego pliku.

    taka rezerwacja to nowa funkcjonalnosc i korzystajac z niej moim zdaniem inne dosy sobie z tym nie poradza - dla innch dosow zmiana dlugosci pliku musi wiazac sie z uwolnieniem sektorow lub rezerwacja nowych - tu tego nie ma.

    ----
    bardzo podoba mi sie pomysl ze podczas tworzenia pliku okreslam maksymalny jego rozmiar.
    • 2: CommentAuthormono
    • CommentTime27 Apr 2020
     
    Chodziło mi o odczyt, bo zapis jest dość oczywisty - przy nadpisywaniu pliku sektory całego pliku będą zwolnione i zaalokowane nowe.
    Być może inaczej byłoby z dopisywaniem, ale to jest związane z odczytem.
    Bo w trybie odczytu (ale też zapisu z nadpisywaniem, usuwania pliku i dopisywania do pliku) DOS mógłby się zachować dwojako:
    1. Czytamy sektory do momentu natrafienia sektora niepełnego albo zerowego linka - wtedy zgłaszamy EOF.
    2. Czytamy sektory aż do osiągnięcia zerowego linka przy odczycie uwzględniając stopień zapełnienia sektora przy zwracaniu danych. EOF następowałby więc dopiero przy zerowym linku a nie przy pierwszym niepełnym sektorze.
    Kwestia sprawdzenia, ale wolę Ci to poddać pod rozwagę bo mógłbyś to implementować tak, żeby było wstecznie kompatybilne z DOS-ami.
    To że funkcjonalność jest nowa, nie znaczy że nie może być użyteczna przez stare oprogramowanie bezproblemowo.
    • 3: CommentAuthorxxl
    • CommentTime27 Apr 2020 zmieniony
     
    nie jestem pewny o czym piszesz w kontekscie tego zwalniania sektorow. tu nie zwalniamy sektorow nigdy (miejsce na dysku jest rezerwowane w sektorach w momencie tworzenia pliku) i tylko w tym zadeklarowanym miejscu mozna zapisywac ten konkretny plik. nie mozna takiego pliku nadpisywac pod zwyklym dosem bo zwolni sektory i caly misterny plan w...

    xbootdos podczas czytania kontroluje tylko znacznik zajetosci - jesli jest mniejszy od max.sector byte count to EOF, jesli jest = sector byte count to czytaj kolejny sektor pliku (brak kolejnego sektora = EOF).
    natomiast to co proponujesz wygladaloby tak, ze jak mamy zarezerwowane 100 sektorow na plik a zapisalismy tylko 10 bajtow to przy odczycie i tak czytalby 100 sektorow... no sorka.

    jak to pogodzic ze starmi dosami... trzebaby we wszystich pozostalych sektorach ustawic "sector byte count" na zero. ale tez nie jestem pewny czy stare dos sie nie tym nie wywala.

    mono:

    To że funkcjonalność jest nowa, nie znaczy że nie może być użyteczna przez stare oprogramowanie bezproblemowo.


    jak stare oprogramowanie uzyje D: (xbootdosa) to problemu nie bedzie
    • 4: CommentAuthormono
    • CommentTime27 Apr 2020
     
    To jak zadziała DOS przy zapisie to oczywiste. Mnie chodziło właśnie o to o czym pisałeś później, czyli jak DOS znalazłby EOF w takim pliku.
    Właśnie nie musiałoby używać xBOOT DOS-a :) żeby współpracować, bo nowa funkcjonalność mogłaby się dobrze wpasować w stare ramy.
    Jak już pisałem - kwestia sprawdzenia, jak DOS-y sobie poradzą z odczytem takich plików.
    • 5: CommentAuthorxxl
    • CommentTime27 Apr 2020 zmieniony
     
    nie radza. czytaja caly plik do sektora z linkiem 00 00 :)

    pod zwyklym dosem wychodza takie smieci jakie pokazal emka pare postow wyzej.
    • 6:
       
      CommentAuthorpirx
    • CommentTime27 Apr 2020
     
    jest na to rada - oprócz xbootdosa można by zrobić (((relokowalny))) handler urządzenia, np. "X:", wczytywany do zwykłego dosa - wtedy pliczki z XBD da się wczytać tym handlerem.
    pewnie dla Ciebie to parę kliknięć, bo taki handler to ten sam XBD, tylko w innym miejscu pamięci.
    • 7: CommentAuthorxxl
    • CommentTime28 Apr 2020
     
    wczytac DOS do DOS :-) ale oprogramowanie ktore korzysta z D: nic by nie wiedzialo tym "x:" ;-)

    kolejna sprawa to to, ze jak ktos sie decyduje na taki minimalistczny DOS to chodzi mu o dostepna pamiec wiec i tak taki program nie bedzie dzial z dowolnym DOS :D

    problem ktorego nie bylo rozwiazany :-)
    • 8:
       
      CommentAuthorpirx
    • CommentTime29 Apr 2020
     
    raczej mi chodzi o taką sytuację, że ktoś chce odczytać pliki zapisane XBD i coś z nimi zrobić. wtedy pisze
    COPY X:FILE.SAV D:FILE.SAV
    i gotowe
    • 9: CommentAuthorxxl
    • CommentTime29 Apr 2020
     
    ale copy pod starmi DOS zadziala normalnie - w sensie DOSa czyli ten nowy plik zostanie obciety do takiej dlugosci jaka XBD zapisal.

    to jest 100% zgodne.
    • 10:
       
      CommentAuthorpirx
    • CommentTime29 Apr 2020
     
    no i super, znaczy dało się to poprawić?

    nie radza. czytaja caly plik do sektora z linkiem 00 00 :)

    pod zwyklym dosem wychodza takie smieci jakie pokazal emka pare postow wyzej.
    • 11: CommentAuthorxxl
    • CommentTime29 Apr 2020
     
    nie, to tylko pokazuje niekonsekwencje starych DOS, przy copy potrafia kontrolowac wskaznik wypelnienia sektora :-)
    • 12: CommentAuthorzbyti
    • CommentTime29 Apr 2020
     
    Jako, że cisnę @xxl za wybryki którym on zaprzecza to wypadało by też docenić to co @xxl robi dobrze i o tym napisać :]

    xBoot DOS to świetny pomysł i wykonanie, nic tylko używać! Dzięki! :]
    • 13: CommentAuthoremka
    • CommentTime30 Apr 2020
     
    Z tym używaniem to ja bym jeszcze trochę poczekał.
    Jak na razie to w podwójnej gęstości obsługuje tylko pierwsze 8 wpisów.
    W załączonym atr pliki L1..LG to krótki program w ACTION! zapisany 17 razy.
    Niestety można wczytać tylko pierwsze 8. L9 jest już niedostępny.
    • 14:
       
      CommentAuthorpirx
    • CommentTime30 Apr 2020
     
    emka, świetna robota, testy to zwykle najbardziej uciążliwa robota, a bez nich jak bez ręki.

    "A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

    First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone."
    • 15:
       
      CommentAuthorKaz
    • CommentTime30 Apr 2020
     
    Dobra anegdota Pirx, uśmiałem się :D
    • 16: CommentAuthorxxl
    • CommentTime30 Apr 2020 zmieniony
     
    @emka: done...

    na szbko, w nocy albo jutro pooptymalizuje znowu.
    • 17: CommentAuthorxxl
    • CommentTime1 May 2020
     
    poprawione. byl tez blad przy boocie :/


    jest juz na stronie. ->link<-
    • 18: CommentAuthorxxl
    • CommentTime6 May 2020 zmieniony
     
    MEMLO = $980 tak zeby bylo ... chociaz spooooro na wyrost

    dodane:

    NOTE
    POINT

    testowo.
    • 19: CommentAuthortebe
    • CommentTime6 May 2020
     
    Point, ustawia na sektor / bajt

    a Note ?
    • 20:
       
      CommentAuthorpirx
    • CommentTime6 May 2020
     
    zwraca, gdzie jestes w pliku
    • 21: CommentAuthortebe
    • CommentTime6 May 2020
     
    aha, czyli Point to taki Seek, a Note to FilePos
    • 22: CommentAuthorxxl
    • CommentTime6 May 2020 zmieniony
     
    wlasciwie tak.

    sluzyc to moze np. do zapetlania binarek w DOS.

    ---
    podczas gdy NOTE odda Ci faktyczny stan CurrentFilePointer to z POINT trzeba uważać co się robi ;-)

    trzeba tez pamietac... ze w niektorych FS kontrola czy jestesmy w granicach pliku to bajka powtarzana dla potrzeb podtrzymania mitu ze system jest przemyslany.
    • 23: CommentAuthorpin
    • CommentTime6 May 2020
     
    Znów piszesz bzdety. Masakra :)
    • 24: CommentAuthorxxl
    • CommentTime6 May 2020
     
    sa ludzie u ktorych procesy poznawcze w pewnym momencie sie wyczerpuja i czlowiek nie jestes juz w stanie stworzyc ani zmodyfikowac wiedzy o otaczajacym swiecie, pozostaje wtedy wiara w bajki ;-)
    • 25:
       
      CommentAuthorJacques
    • CommentTime6 May 2020 zmieniony
     
    To samo najwyraźniej tyczy się zdolności gramatycznych, używania polskich czcionek i właściwej interpunkcji, no ale po co się wysilać, skoro ma się ego XXL i innych się z założenia mało szanuje ;-)
    • 26: CommentAuthorpin
    • CommentTime6 May 2020
     
    Polska język, trudna język ;-)
    • 27:
       
      CommentAuthorpirx
    • CommentTime6 May 2020
     
  28.  
    Hmmm,

    xBootDOS can load ML-files and Basic files. If the ML-File is named Autorun and Option key is pressed, it will be run automatically. But, Basic files still have to be run manually ?!? Tried this:

    1) renamed the Atari Basic file into Autorun - booting with basic enabled did not work, READY prompt appears (so I have to type RUN"D:Filename.BAS manually); if I boot with Option key, then the file does not (cannot!) run, since Basic is not available...

    2) used an Autorun.SYS creator to load Basic files, the ML-file has 1 or 2 sectors in length; renamed this Basic loader into Autorun - booting with Basic enabled did not work, READY prompt appears (again, had to type RUN"D:Filename.BAS manually); if I boot with Option key, then the short Autorun file loads and loads and loads and never stops loading... (it tries to load the Basic file, but since Basic is switched off with Option key, this does not work)...

    3) okay, I want Autorun to work automatically but with Basic enabled, so I try it with a trick: Used a diskfile version of Atari Basic (which executes a RUN"D:Autorun.ABS at the end); now I can press the Option key to disable built-in Atari Basic but ha, Basic is now loaded from diskette. Alas, when the diskfile of Basic has finished loading, it does not execute the RUN"D:Autorun.ABS" command, no clue why...

    So, I cannot run Basic files with xBootDOs automatically it seems ?!? The reason is that I have some Basic programs from tape that are multi-stage but have an extremely low memlo (they overwrite DOS; from tape they are simply loaded without DOS, with CLOAD or RUN"C:")...

    Is it possible to create another (a second) version of xBootDOS especially for auto-booting (multi-stage!) Basic programs with very low memlo...?!? Some of these Basic programs use RUN"C:" to load the next file (which I can change into RUN"D:Program2.BAS"), but some programs use OPEN #2,4,128,"C:" for the next file (which I have to change into Open #2,4,0,"D:Program2.DAT")...
    • 29: CommentAuthorxxl
    • CommentTime16 May 2020
     
    yes, it can be done, upload sample autorun.sys file and example Basic program that it runs.
  30.  
    Alright,

    here are two examples, these are programs copied from tape to diskette. One could patch the two games (so they e.g. work with DOS 2.5), but for my Tape2Disk project I have copied approx. 800 tapes and more than 100 were Basic programs. No-one wants to patch them all, so it would be much easier to use a special loader for them, like e.g. xBootDOS...

    1) Nato Commander:

    a) you may use the short (1-sector) Autorun.SYS that does RUN"D:Title.BAS" -or- you may use fileversion of Atari Basic Rev. C (CBASIC.COM) with a length of 69 sectors that does a RUN"D:Autorun.ABS" at the end (and therefore uses page 6); if you use Atari Basic, you have to do some renames (CBASIC.COM => Autorun.SYS, Title.BAS => Autorun.ABS)...

    b) the game consists of two files, Natocmd.BAS (Basic) and Natocmd.PT2 (MC). The Basic file loaded the MC with an Open #2,4,0,"C:", which I changed into Open #2,4,0,"D:Natocmd.PT2" - see line 12010. The game also has load (line 3910) and save (line 4010) options, also done with the Open command.

    Under DOS 2.5 you get the blue Microprose screen, but it either does not continue loading or crashes after loading the second part. I could get it running under xBootDOS, when I typed in RUN"D:Title.BAS" manually, but I would like xBootDOS to do it automatically (so I do not have to type in anything)...
  31.  
    2) League Challenge:

    a) you may use the short (1-sector) Autorun.SYS that does RUN"D:Title.BAS" -or- you may use fileversion of Atari Basic Rev. C (CBASIC.COM) with a length of 69 sectors that does a RUN"D:Autorun.ABS" at the end (and therefore uses page 6); if you use Atari Basic, you have to do some renames (CBASIC.COM => Autorun.SYS, Title.BAS => Autorun.ABS)...

    b) the game consists of two files, Leagchal.BAS (Basic) and Leagchal.DAT (text-data). The Basic file loaded the data with an Open #2,4,0,"C:", which I changed into Open #2,4,0,"D:Leagchal.DAT" - see line 145. The game also has load (line 6510) and save (line 6610) options, also done with the Open command.

    c) the program seems to load under DOS 2.5, after a while the message "keep tape running" appears on a light blue screen and then the *.DAT file is loaded (requires some patience). Then the game seems to start with the text "sign on:" on the screen. But wait, the game crashes with an Error 147 under DOS 2.5 and also under LiteDOS, so I tell you where and when (five steps)...

    - sign on: type in a name here (e.g. AAA), press Return
    - next menu: choose a team (e.g. 1), press Return
    - next menu: type "C" to continue
    - training: choose 1, 2 or 3 here
    - start match: type "C" to continue...

    => When loaded from tape, the match now starts with very primitive gfx; under DOS 2.5 and LiteDOS 2.08/XS/RO/3.02 you will get an Error 147 (not enough memory) at line 3305 (which does the match gfx in Gr. 7 mode).
    Under xBootDOS I could get the game running, when I typed in RUN"D:Title.BAS" manually, but I would like xBootDOS to do it automatically (so I do not have to type in anything)...

    Alright, as said before these are just two examples, there are several dozens of Basic tape programs (maybe more than 100 ?) which could benefit of xBootDOS and therefore run fine from diskette...
    • 32: CommentAuthorbaktra
    • CommentTime16 May 2020 zmieniony
     
    Instead of modifying xBootDOS itself (and increasing its size), wouldn't it be better to write a simple AUTORUN.SYS in ML that automatically initializes BASIC and injects RUN"D:AUTORUN.BAS" command?
  33.  
    Yes, an Autorun.SYS that switches Basic on and runs a Basic file could be an alternative. Problem is, that xBootDOs only loads ML files if you hold down the Option key - and since it bootloads only 3 sectors you have to release the Option key quite fast, otherwise Basic stays off (disabled)...

    Thats why I thought it could be good to have two versions of xBootDOS, one that loads only ML files and one that loads only Basic files...
    • 34: CommentAuthorxxl
    • CommentTime16 May 2020
     
    not good. this AUTORUN.SYS file contains three errors, including fatal one, that is why it does not return properly to the system. I modified it but it's still not optimal. Now it loads properly.

    In addition, I shortened xBDos so that he would not check for Basic.
  35.  
    You mean the short (1-sector) Autorun ? It is from Compute! magazine. If this short autorun is faulty, I could test various other Autorun files for Basic programs (usually 1 or 2 sectors in length)...

    However, if the fileversion of Atari Basic Rev. C is faulty, then I have no alternatives. Fandal patched it for me, so that it does a RUN"D:Autorun.ABS" at the end. On the disk you have uploaded (CC.aTR) CBasic.COM now gives an Error 164, so I am not sure if you modified the short 1-sector Autorun or the 69 sector fileversion of Atari Basic...?!?

    Last not least, you said that you shortened XBDOS so that it would not check for Basic - can you make that version with initializer (so I can init. it on multiple disks) ?!?
    • 36: CommentAuthorxxl
    • CommentTime16 May 2020 zmieniony
     
    ? I don't have bugs like you say. view video.


    ----
    check everything, if there were no errors then I will put the initializer in the evening.
  37.  
    Yes, the disk runs fine.

    I simply was not sure which autorun file you modified (the file with 1 sector or the file with 69 sectors), so I looked onto the disk and noticed that the file with 69 sectors gave Error 164...

    Anyways, the program runs fine now. So I would appreciate a new xBDOS version with initializer...
    • 38: CommentAuthorxxl
    • CommentTime16 May 2020
     
    I didn't touch this file. This error usually means that you have copied a file with a tool that does not distinguish between dos2 and e.g. mydos.

    write exactly what you are trying to load this file.
  39.  
    Ah good, when you did not touch this file, the error was probably on my side...

    But most importantly, the Basic program runs fine with XBDOS now and fully automatic, thats great!
    • 40: CommentAuthorxxl
    • CommentTime16 May 2020
     
    inicjalizer
  41.  
    Thank you!

    This is really a good program - exactly what I have been searching for quite some time. Now the search is over and I can use this tool!
    • 42: CommentAuthorxxl
    • CommentTime17 May 2020
     
    follow the topic because I will publish an add-on soon, with the NOTE and POINT commands and maybe autostart BASIC program, you will not need this AUTORUN.SYS to run BASIC program anymore.

    MEMLO will not change of course.
  43.  
    Idea:
    Maybe XBDOS could auto-detect the filetype ? If fileheader is a) standard ML-file (FF FF) then switch off Basic and binary run, if it is b) BAS-file/not ML-file, switch on Basic and do a RUN"D:Filename.BAS and maybe c) if it is LZ4 file (header unknown to me), switch off Basic, binary load and depack on-the-fly...

    Then it would not be required to name the first file AUTORUN - XBDOS could simply check the first file (starting in sector 4) and load it either as ML-file or as BAS file or as LZ4 file... but this is just an idea. Do not know if that would require a lot of work to implement it nor do I know if it requires more memory (I am no programmer)...
    • 44:
       
      CommentAuthorshanti77
    • CommentTime17 May 2020
     
    @xxl a ten DOS może obsługiwać RAMdisk?
    • 45: CommentAuthorxxl
    • CommentTime18 May 2020
     
    @shanti77: odpowiedz podziele na trzy:

    1. jesli to mialoby dzialac na takiej zasadzie ze ladujesz xex ktory "zaklada" ramdysk (w rzeczywistosci laduje 16kb bloki do pamieci rozszerzonej) po czym inicjuje xBDos ktory po uruchomieniu zaladuje z RAM-Dysku program i sam ramdysk bedzie traktowal jak jedna stacje dyskow to: TAK (krotki patch)

    2. ze wzgledu na minimalny rozmiar dosa wprowadzone sa pewne uproszczenia - np. podczas uruchomienia DOS konfiguruje sie na obsluge odpowiedniej gestosci - i to jest kluczowe, nie zmieniam gestosci podczas pracy a przy obsludze RAM-Dysku to jest niezbedne. gdyby fdd mialo gestosc SD/ED to jescze OK ale jak bedzie DD to juz obsluga RAMDysku bez zmiany gestosci sie wykrzaczy. policz, sam sektor katalogu wypadlby powyzej pojemnosci RAM-Dysku dla atari 130... odpowiedz: obecnie NIE

    3. wszystko sie da...
    • 46: CommentAuthorxxl
    • CommentTime21 May 2020 zmieniony
     
    aktualizacja.

    xBDOS mozna uruchamiac na dwa sposoby:

    z dodatkowmi komendami (sa w pliku AUTORUN) - niewazne czy BASIC jest wlaczony czy nie xBD uruchomi dowolny plik binarny AUTORUN

    jesli zaladuja sie komendy dodatkowe (na dyskietce zalaczone przkladowe komendy dodatkowe w pliku AUTORUN) to nastepnie zostanie przeprowadzone automatyczne uruchomienie pliku START.COM a jesli BASIC byl wlaczony to automatycznie zaladuje sie i uruchomi Basicowy program zapisany pod nazwa START.BAS

    z komendami czy bez memlo takie samo $980

    komendy dodatkowe:
    BINARY LOAD (XIO 40)
    NOTE
    POINT

    tak, ze to najszbszy sposob na automatyczne uruchamienie programow w basicu ;-)
    • 47:
       
      CommentAuthorpirx
    • CommentTime21 May 2020
     
    jeszcze a'propos ramdysku - dawno dawno temu używałem handlera "M:", który robił ramdysk bez DOSa (to było dla użytkowników magnetofonów).
    Taki handler mógłby bez problemu pracować z mikrodosami, bo w ogóle nie ma z nimi nic wspólnego. Niestety jak taka pchełka się nazywała, nie mam pojęcia :(
    W każdym razie napisanie takiego relokowalnego handlerka nie wydaje się bardzo trudne, szczególnie jeśli uprościłoby się filesystem i pozakładało jakieś konkretne ograniczenia na liczbę, rozmiar pliczków i możliwe operacje.
    • 48: CommentAuthorxxl
    • CommentTime22 May 2020 zmieniony
     
    po sugestiach przenioslem jednak Binary Load do glownego kodu.

    ->link<-


    czyli:

    MEMLO=$980, zapisuje pliki dowolnej dlugosci, ma Binary Load (XIO 40), ma dodatkowe komendy NOTE i POINT (bez podnoszenia MEMLO), ma funkcje autostartu programu w BASICu.
  49.  
    Thumbs up and a big thank you!

    If I understood correctly, one can load 1) Binary files and 2) Basic files. Binary files can be loaded a) as Autorun or b) as (Autorun and) Start.COM, whereas Basic files must be loaded as (Autorun and) Start.BAS...?!?
    • 50: CommentAuthoremka
    • CommentTime23 May 2020
     
    Na prawdziwym ATARI włożenie kartridża maskuje systemowy BASIC. Dlatego nikt nie wciska OPTION przy starcie systemu i PORTB = $FD. XbootDOS nie potrafi tego wykryć i próbuje załadować START.BAS do innych kartridży np ACTION!, co zawiesza system. Na emulatorze trudno to zauważyć ponieważ prawie wszyscy mają na stałe ustawiony start z wciśniętym OPTION i po włożeniu kartridża PORTB = $FF, a obszar RAM pod adresem $8000,$A000-$BFFF jest na stałe zajęty przez ROM.

Od 51 do 100 z 124

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