atarionline.pl Patch TOS'a dla stabilności blittera - poszukiwany, poszukiwana - 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  »   Patch TOS'a dla stabilności blittera - poszukiwany, poszukiwana

W dół

Od 1 do 17 z 17

  1.  
    • 1:
       
      CommentAuthorxorcerer
    • CommentTime8 Dec 2023 zmieniony
     
    Temat w użytkach, bo chodzi o polowanie na GOODBLIT.PRG czy jakoś tak.

    Najbliżej jak mi się udało podejść do celu to jest ten artykuł z 6/88 ST Computera:

    ->link<-

    ->link<-

    ->link<-

    surowa translacja na lengłydż:
    "Title: Operational Safety

    Introduction:

    Operational safety is extremely important for NASA, and ST users also place a certain value on it. With the blitter, it's a bit of a mixed bag: Whoever doesn't have one, definitely wants one, whoever has one, curses it, because it doesn't really do what it's supposed to do. In short, there are certainly few blitter owners who are completely satisfied and only know the GOODBLIT.PRG from Application Systems by hearsay.

    Body:

    The blitter that is now installed in my system was kindly given to me by a good friend, who has since somehow come across an even better one.

    I want to say that it works quite well in general, but it has its quirks. On the one hand, it's not completely "streak-free" (Tempus), which doesn't bother me any further. On the other hand, it crashes with enthusiasm in EASYDRAW when I try to enlarge italic text. Even Goodblit doesn't help anymore. On the other hand, it works perfectly in the normal desktop and, for example, with IstWord.

    Strangely enough, the EASYDRAW crash did not occur with my friend. In his case, there were only isolated lines to be seen in some drawings.

    ATARI recommends that the signals BR and BGACK be terminated with 4.7 KQ pull-up resistors when extensions are connected to the system bus of the new MEGA-STs. Perhaps this measure will also bring an improvement here.

    In general, the retrofit kit can be recommended. The board is cleanly built, the instructions are brief with only one page, but they are easy to understand thanks to the illustrations. Those who are afraid of installation can also have it done by Rocke for 35.-. At 69.- (trade fair price), the retrofit kit is also very affordable. However, the blitter still needs to be added, which is likely to cost around 200.-.

    Conclusion:

    C.D. Ziegler

    Notes:

    [1] In the original text, the reference is to a footnote that is not included in this translation. The footnote states that Atari recommends this measure to improve the stability of extensions that are connected to the system bus of the new MEGA-STs.
    [2] Rocke is a company that offers technical support and repair services for Atari computers."


    czysto dla rozrywki haluny google bard'a na ten temat:
    user: Atari ST goodblit patch that Fixes blitter crashes (Listing in ST-Computer 6/88)

    google bard: The Atari ST GoodBlitter patch is a modification to the Atari ST's standard blitter code that fixes a number of bugs that can cause the blitter to crash. The patch was originally published in ST-Computer magazine in June 1988.

    The patch is relatively simple to apply, and can be done by following the instructions in the ST-Computer article. Once the patch is applied, the blitter should be much more stable and less prone to crashing.

    Here is a summary of the changes made by the patch:

    The blitter's error checking code has been improved. This will help to catch and report errors that could cause the blitter to crash.
    The blitter's divide-by-zero detection code has been improved. This will help to prevent the blitter from crashing if it is given an invalid argument.
    The blitter's memory access code has been improved. This will help to prevent the blitter from crashing if it tries to access memory that is not available.
    These changes should make the blitter much more reliable and less likely to crash. However, it is important to note that the patch is not a complete solution to all blitter-related problems. There are still some rare bugs that can cause the blitter to crash, even with the patch applied.

    If you are experiencing problems with the blitter, it is always best to try to determine the cause of the problem before applying the patch. This will help to ensure that the patch does not cause any other problems.

    Here are some additional tips for troubleshooting blitter problems:

    Make sure that you are using the correct blitter routines for the task you are trying to perform. There are different blitter routines for different types of operations, and using the wrong routine can cause problems.
    Make sure that you are not trying to access memory that is not available. The blitter can only access memory that is allocated to it. If you try to access memory that is not available, the blitter will crash.
    Make sure that you are not trying to perform too many blitter operations at the same time. The blitter is a finite resource, and too many operations can overwhelm it and cause it to crash.
    If you are still having problems with the blitter after trying these tips, you may need to contact Atari or a qualified Atari ST technician for assistance.


    ktokolwiek widział gdzieś ten artykuł w całości z domniemanym listingiem w asemblerze, albo ma GOODBLIT.PRG proszony jest o jakiś znak w odpowiedzi.

    PS. miejsce gdzie ten artykuł powinien być, jest puste:
    ->link<-

    względnie prawie puste:
    ->link<-

    z archive org pełne 145 mb PDFy być może ściągną się jutro:

    ->link<-

    ->link<-
    • 2:
       
      CommentAuthorxorcerer
    • CommentTime8 Dec 2023 zmieniony
     
    OK to jest to co znalazłem w swoich archiwach - załączam GOODBLIT.PRG , deasemblat , archiwum PD z którego to pochodzi.

    Jak ktoś znajdzie u siebie coś innego to poproszę.
    • 3: CommentAuthortebe
    • CommentTime8 Dec 2023
     
    zamontuj sobie VBXE, tam bliter jest stabilny ;)
    • 4:
       
      CommentAuthorKaz
    • CommentTime9 Dec 2023
     
    Bardzo ciekawy temat, muszę po Silly uważnie się w to wczytać. Czy dobrze rozumiem, że Atari nieco zmaściło blitter w Mega ST i rozwiązanie problemu bugów jest zarówno programowe, jak i hardware"owe? A jak z STE, bo w 1988 roku jeszcze nie mogli o nim pisać, bo go nie było...
    • 5:
       
      CommentAuthorCyprian
    • CommentTime9 Dec 2023
     
    gwoli wyjaśnienia, żaden BLiTTER nie ma bugów. A przynajmniej przez ostatnie 15 lat ich nie odkryliśmy. Układ jest mocno badany przez koderów i programistów którzy pracowali nad odtworzeniem jego pracy w FPGA.
    Oczywiście ma on pewne nieopisane przez Atari zachowania, ale nie są one błędem ani też nie powodują wywalenia się BLiTTERa czy procesora.

    Niedawno oczywiście zostały stwierdzone pewne odchyłki od zwykłego zachowania (BLiTTER vs ET4000 czy BLiTTER vs SoundDMA), wynikają one jednak z rozjazdu sygnałów cyfrowych spowodowanego wiekiem sprzętu.


    Tak na szybko dwa cytaty:

    "fixes a number of bugs that can cause the blitter to crash. "

    Do dnia dzisiejszego nie wykryliśmy żadnego błędu BLiTTERa. Nie ma on możliwości wywalenia się ani też nie spowoduje wywalenia się procesora.


    "The blitter can only access memory that is allocated to it. If you try to access memory that is not available, the blitter will crash."

    BLiTTER ma dostęp do całej 24 bitowej przestrzeni adresowej. Może zapisywać i odczytywać obszary które nie mają podczepionej żadnej kości RAM czy rejestry sprzętowe. Żadna z tych operacji nie wywala BLiTTERa.


    Oczywiście nie wyklucza to możliwości że programista BLiTTERem może nadpisać pamięć systemu lub innego programu i spowodować jego wywalenie.


    BLiTTER w STE (czy Falconie) jest taki sam jak w ST. Jedyna różnica jest taka że w późniejszych wydaniach STE był on połączony z innymi układami w jedną kość.


    W wolnej chwili rzucę okiem na GOODBLIT.S
    • 6:
       
      CommentAuthorxorcerer
    • CommentTime9 Dec 2023 zmieniony
     
    ...a tak wygląda bus error, który nie istnieje (obrazek w załączniku). W A4 jest faktycznie jeden z adresów przestrzeni rejestrów blittera, faktycznie jest to jeden z ważniejszych - $FF8A3C, czyli:
    $FF8A3C|byte |Line Number Register              BIT 7 6 5 . 3 2 1 0|R/W (Blit)
           |     |BUSY ---------------------------------' | |   | | | ||
           |     |0 - Share bus, 1 - Hog bus -------------' |   | | | ||
           |     |SMUDGE mode ------------------------------'   | | | ||
           |     |Halftone line number -------------------------+-+-+-'|

    czyli dokładnie to jest ten adres, którego obecności w rejestrach adresowych należałoby się spodziewać po wypełnieniu wszystkich innych i ostatecznym uruchomieniu blittera. Ten, który zawiera bit BUSY.

    Poniższy fragment rekomendowanego dla programistów szablonu egzekucji blittera też może zawierać odpowiedź, dlaczego Atari zawierające blitter i CPU, które działa szybciej niż 16mhz i jeszcze co gorsza jest taktowane tak (lub po prostu działa z taką prędkością), że wyskakuje poza wielokrotność 2 - może losowo wywalać bus error:

    ->link<-

    * The BLiTTER is usually operated with the HOG flag cleared.
    * In this mode the BLiTTER and the ST's cpu share the bus equally,
    * each taking 64 bus cycles while the other is halted. This mode
    * allows interrupts to be fielded by the cpu while an extensive
    * BitBlt is being processed by the BLiTTER. There is a drawback in
    * that BitBlts in this shared mode may take twice as long as BitBlts
    * executed in hog mode. Ninety percent of hog mode performance is
    * achieved while retaining robust interrupt handling via a method
    * of prematurely restarting the BLiTTER. When control is returned
    * to the cpu by the BLiTTER, the cpu immediately resets the BUSY
    * flag, restarting the BLiTTER after just 7 bus cycles rather than
    * after the usual 64 cycles. Interrupts pending will be serviced
    * before the restart code regains control. If the BUSY flag is
    * reset when the Y_Count is zero, the flag will remain clear
    * indicating BLiTTER completion and the BLiTTER won't be restarted.
    *
    * (Interrupt service routines may explicitly halt the BLiTTER
    * during execution time critical sections by clearing the BUSY flag.
    * The original BUSY flag state must be restored however, before
    * termination of the interrupt service routine.)

         restart:
              bset.b    d2,(a2)        ; Restart BLiTTER and test the BUSY
              nop                      ; flag state.  The "nop" is executed
              bne  restart             ; prior to the BLiTTER restarting.
         *                             ; Quit if the BUSY flag was clear.  

         begin:
              dbra d7,next_plane
              rts



    To się prosi o napisanie crash-testu który będzie w powtarzalny sposób potwierdzać lub negować kolejne tezy, dlaczego to a nie tamto zwiększa szansę na bus error. Albo co sprawia, że nawet GOODBLIT.PRG może nie dać sobie rady.
    • 7:
       
      CommentAuthorCyprian
    • CommentTime9 Dec 2023 zmieniony
     
    W sumie to temat został sprawdzony wiele razy (przez ziomeczków z AF jak i mnie), BLiTTER nie generuje błędu "Bus Error".
    Ale oczywiście mogę napisać program testowy. Tylko zapodaj co miał by on robić.


    "Bus Error" jest to przerwanie które dostaje procesor 68000 od układu GLUE (poprzez nóżkę BERR 68000) w momencie kiedy 68000 próbuje dostać się albo do pamięci chronionej albo komórek pamięci które nie są wykorzystane przez RAM/ROM/Rejestry sprzętowe.

    Otóż GLUE wystawia sygnał BERR do 68000 gdy BLiTTER korzysta z chronionej pamięci, ale 68000 go ignoruje gdyż jest na tyle ogarnięty że rozpoznaje że to nie wynik jego aktywności.

    Przykładowo jeśli nie mamy BLiTTERa w ST i procesor będzie próbował zapisać jego rejestr, np $FF8A3C, to wtedy zostanie wygenerowany "Bus Error".

    "Bus Error" będzie wygenerowany jeśli 68000 będzie chciał zapisać pamięc adresem $0 ($0-$7 są chronione przed zapisem). BLiTTER poprawnie zapisze i odczyta tą komórkę RAM.

    Swoją drogą instrukcja "nop" z poniższej pętli jest zbędne i można ją usunąć. Nic ona nie wnosi a tracimy 4 cykle.
    Prawdopodobnie jest to jakaś pozostałość programistów Atari po testowej wersji BLiTTERa.
    restart:
              bset.b    d2,(a2)        ; Restart BLiTTER and test the BUSY
              nop                      ; flag state.  The "nop" is executed
              bne  restart             ; prior to the BLiTTER restarting.
         *                             ; Quit if the BUSY flag was clear.
    • 8:
       
      CommentAuthorxorcerer
    • CommentTime9 Dec 2023
     
    Narazie to tylko mam do Ciebie prośbę, żebyś przestał się bawić w semantykę i popatrzył na to:



    i na to:

    • 9:
       
      CommentAuthorCyprian
    • CommentTime10 Dec 2023 zmieniony
     
    Myślę że jest warto napisać do Exxosa - autora GemBencha, że jego program wywala Bus Error. Warto żeby pochylił się nad tym co tu nie jest tak.

    Swoją drogą zastanawiają mnie dwie sprawy:
    1) Z tego co widzę to sprawdzasz pod jakiś emulatorem FPGA (MiST?). Czy ten sam błąd miałeś na prawdziwym sprzęcie.
    2) "ein 68020 prozessor ist aktiv" - dobrze rozumiem że masz procesor 68020?

    Jakbyś mógł udostępnić image dysku który wywala Tobie błąd, to bym sprawdził na moim STE.
    • 10:
       
      CommentAuthorxorcerer
    • CommentTime10 Dec 2023 zmieniony
     
    To nie jest problem gembencha. Gembench po prostu tak gęsto produkuje zapytania wywołujące blittera.

    To samo dzieje się w Teradesku, jeśli tylko zostawi się go włączonego na dłuższą chwilę.

    Teradesk się zawiesza.

    Bus Error.

    Już nie wspomnę o dowolnej grze, która używa blittera. Bo np. OpenDUNE ignoruje go zupełnie i się nie wiesza.

    To, czego w tych video nie ma, to drobny detal:

    PROBLEM ZNIKA W TRYBIE MONO.

    Ale to nie jest treść mojego listu.

    Popatrz uważnie, jakie są parametry startowe każdego wideo. Odtwórz dokładnie to u siebie jeśli masz MiST. Ściągnij sobie standardowy ST Core. Nie MiSTery.

    Albo uruchom swoje kontakty i popytaj ludzi, którzy mają dopalone (Mega)ST(e). Bardziej, niż 16 mhz. Rodzaj procesora nie ma znaczenia. Tylko częstotliwość.
    • 11:
       
      CommentAuthorCyprian
    • CommentTime10 Dec 2023 zmieniony
     
    Sprawdź czy u Ciebie na tym MiSTie działa "Lotus STE". On gęsto używa blittera: ->link<-

    Tutaj przykładowe demo fastbobs.zip które równie gęsto używa BLiTTERa. Daj znać wygląda u Ciebie tak:


    Mam Mega STE, mam dopałki 030, Falcona. Robiłem sporo testów BLiTTER (wyniki moich testów są uwzględnione w Hatari i Steem SSE) i nigdy nie miałem z nim żadnych kłopotów.


    Daj znać czy pod Mistem te programy działają ok czy nie.
    • 12:
       
      CommentAuthorxorcerer
    • CommentTime10 Dec 2023
     
    Cyprian, nic już więcej nie będę sprawdzał. Acid Maker zduplikował już ten sam błąd u siebie. Jak chcesz pomóc to spróbuj to zduplikować u siebie.
    • 13:
       
      CommentAuthorCyprian
    • CommentTime10 Dec 2023
     
    xorcerer Gembench u mnie działa poprawnie, przez 30 lat nie miałem pod nim żadnego błędu związanego z BLiTTERem.
    Co więcej, nie znalazłem w sieci by ktoś miał taki problem pod GemBenchem.

    Jak zapodasz mi image swojego dysku, ten pod którym masz ten błąd to sprawdzę Twoją konfigurację na prawdziwym sprzęcie.
    • 14:
       
      CommentAuthorCyprian
    • CommentTime11 Dec 2023 zmieniony
     
    Dobra, całą niedzielę nie dawało mi to spokoju więc postanowiłem zadziałać sam.

    Pobrałem z sieci i uruchomiłem na prawdziwym sprzęcie Mega ST i STE dwie wersje GemBencha. Najnowszą GB608B31 i starą GBNCH402.

    Na 15 uruchomień testów, GB608B31 dwa razy się zawiesił na "VDI Text" i "VDI Text Effects" (ale ani razu na teście BLiTTERa)
    ->link<-

    Sprawdziłem również GBNCH402 15 razy i nie miałem żadnego błędu.
    ->link<-


    Na tą chwilę wiemy że GB608B31 ma jakieś wątpliwości. Sam program napisany jest w GFA Basicu, nie korzysta bezpośrednio ze sprzętu tylko z systemu operacyjnego, nie wiemy co robi wykonując testy. Dodatkowo, ważna uwaga jest taka że problem wystąpił też pod emulatorem MiST (xorcerer), gdzie nie ma prawdziwego BLiTTERa tylko jakiś algorytm udający go w FPGA. Tak więc na dzień dzisiejszy przy tylu zmiennych nie mam żadnej podstawy by stwierdzić że to jest wina BLiTTERa.


    We wczesnych Mega ST była dodana do BLiTTERa mała poprawka ->link<-
    Może być tak że albo pierwsze czipy albo pierwsze płyty miały jakiś błąd. Ktoś sprawdzał że po usunięciu poprawki BLiTTER też działa ok.


    Żeby wyeliminować zmienne typu błędy w programach, błędy w OS czy zakłócenia dodane przez inne aplikacje AUTO/TSR, napisałem program "BLITHIT.PRG" oraz pobrałem "FATBOBS.PRG". Oba programy bezpośrednio korzystają z BLiTTERa, pierwszy wykonuje prawie 70000 blitów na sekundę, drugi podobnie.
    Sprawdzałem je ponad godzinę (BLITHIT na Mega ST a FATBOBS na STE), no i działały bez żadnych zakłóceń.

    Dla pewności uruchomiłem je w niedzielę koło godziny 23ciej, nastęgo dnia sprawdzę czy nadal działają.
    • 15:
       
      CommentAuthorCyprian
    • CommentTime11 Dec 2023 zmieniony
     
    Dziś o 9:20 testy zakończyła awaria prądu na dzielni.
    Do tego czasu programy BLITHIT i FATBOBS działały poprawnie, czyli po mimo 10 godzin intensywnego bombardowania BliTTERa, nie wystąpił żaden błąd.
    • 16:
       
      CommentAuthorxorcerer
    • CommentTime11 Dec 2023
     
    Dzięki a jakieś zdjęcie czy zrzut ekranu z Gembencha z widocznymi wynikami i konfiguracją możesz udostępnić?
    • 17:
       
      CommentAuthorCyprian
    • CommentTime11 Dec 2023 zmieniony
     
    wieczorem zapiszę wynik do pliku

Od 1 do 17 z 17

  1.