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: CommentAuthorvega1
   • CommentTime8 Nov 2024 09:11 zmieniony

    
   witam
   
   czy da się coś zrobić, żeby podczas odczytu ze stacji dysków na przerwaniu IRQ nie dochodziło do zawieszenia odczytu z powodu wystąpienia przerwania DLI?
   
   zależy mi, żeby nie wyłączać ekranu na czas wczytywania kolejnego levelu w BUBBLE BOBBLE...
   
   Wystąpienie przerwania DLI w sposób losowy zakłóca odczyt i zaczyna się w nieskończoność wykonywać poniższy kod
   
   35914: 41: 7 | A=FF X=FE Y=31 (N ) | EB18: D0 03 BNE $EB1D
   35914: 41: 10 | A=FF X=FE Y=31 (N ) | EB1D: AD 17 03 LDA TIMFLG
   35914: 41: 16 | A=01 X=FE Y=31 ( ) | EB20: F0 05 BEQ $EB27
   35914: 41: 20 | A=01 X=FE Y=31 ( ) | EB22: A5 39 LDA RECVDN
   35914: 41: 28 | A=00 X=FE Y=31 ( Z ) | EB24: F0 F0 BEQ $EB16
   35914: 41: 40 | A=00 X=FE Y=31 ( Z ) | EB16: A5 11 LDA BRKKEY
   
   gra praktycznie gotowa..tylko ten błąd został
2. • 2: CommentAuthorvega1
   • CommentTime8 Nov 2024 09:11

    
   niestety przerwanie dli jest konieczne bo trzeba co 4 wiersz ustawiać zestaw znaków....kolor COLBAK też by się przydało...przerwanie DLI akrualnie jest bardzo krótkie
   
   myDLIload1 .proc
   sta DLI_A
   stx DLI_X
   
   ldx dli_cnt
   inc dli_cnt
   
   mva tab_dli_COLBAK+1,x COLBAK
   mva tab_dli_charset+1,x CHBASE
   
   ldx DLI_X
   lda DLI_A
   rti
   .endp
3. • 3: CommentAuthortebe
   • CommentTime8 Nov 2024 10:11

    
   xBios używasz?
   
   ->link<-
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime8 Nov 2024 11:11 zmieniony

    
   Obawiam się, że własna procedura odczytu jest potrzebna. Albo właśnie xBios. Albo pójście w car. 128k car zaemulujesz ze wszystkiego, włącznie z tym opartym o rpiPico.
   
   Dodatkowo jeśli jest trochę miejsca, to można rozpatrzyć kompresję. Ja zrobiłem testowo w pełni plikową wersję Problemu Jasia, gdzie 30 kB leveli skompresowane do 18 siedzi pod romem i w pustych miejscach obrazu Action!
5. • 5: CommentAuthor0xF
   • CommentTime8 Nov 2024 13:11 zmieniony

    
   Przerwania transmisji szeregowej są zgłaszane do momentu ich potwierdzenia zapisem do IRQEN. Więc nie, przerwanie IRQ nie zgubi się z powodu DLI. Może być obsłużone za późno i zgubi się bajt, co jest sygnalizowane błędem odczytu i jego ponowieniem. Ale to nie powinno mieć miejsca w przypadku tak krótkiej procedury DLI. Chyba, że jest ona co skanlinię.
   
   Być może przerwania DLI nachodzą na siebie, a A i X przechowujesz w jednym miejscu zamiast na stosie.
6. • 6: CommentAuthortebe
   • CommentTime8 Nov 2024 14:11

    
   chyba Vega próbuje powtórzyć to co kiedyś zrobił Probe, wstawił obrazek G2F podczas transmisji I/O
7. • 7: CommentAuthorvega1
   • CommentTime8 Nov 2024 15:11

    
   tebe xBootDOS xxl-a
8. • 8: CommentAuthorvega1
   • CommentTime8 Nov 2024 15:11

    
   jhusak...wersja na karta już jest..tam nie ma tego problemu..śmiga bez problemu...ale przy odczycie ze stacji dysków wchodzi w tą pętlę jak wyżej
9. • 9: CommentAuthorvega1
   • CommentTime8 Nov 2024 15:11 zmieniony

    
   0xF jeszcz raz sprawdzę...przerwanie co wiersz jest bo to tryb znakowy...szeroki ekran...jeżeli wyłacze dli a zostawie vbl to wszysko działa...więc problem leży w przerwaniu DLI
   
   zmieniłem jeszcze przechowywanie rejestrow na stosie i też się zawiesiło..
   
   jak da się patch D dla SIO dysk w altirze to gra chodzi bez problemu..ale bez tego patcha to dzieje się jak pisałem wcześniej
10. • 10: CommentAuthortebe
    • CommentTime8 Nov 2024 17:11 zmieniony

     
    zamiast dli_cnt rozważ sprzętowy VCOUNT, pominiesz 'inc dli_cnt' rozmieść dane w tablicach tak aby zgadzały się z wartością VCOUNT
    
    xBootDOS to nie jest to samo co xBios, xBios daje swoje przerwania, xBootDOS tylko minimum DOS-a i niskie Memlo
    
    podobnie foxDOS, możesz go sprawdzić, nie korzysta z tylu zmiennych strony zerowej co xBootDOS
    
    ->link<-
    
    ceną za xBios-a będzie transfer tylko w Normal jeśli chcesz używać przerwań DLI, im więcej przerwań tym wolniejszy transfer
    
    przykład xBIOS-a z muzyką i przerwaniami DLI
    
    
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime8 Nov 2024 18:11 zmieniony

     
    Hm. przy 19200 występuje niecałe 40 przerwań irq na ramkę. Co daje ok. 1 przerwanie na ca 8 linii. Biorąc pod uwagę tryb znakowy i jeszcze przerwanie DLI co 4 linie, które znakomicie wydłuża czas niemożności wykonania tego przez procesor (następna skanlinia jest mocno obciążona i wyłączona w większości przez Antic) wyobrażam sobie scenariusz, gdy coś się nałoży i bajt się zgubi, przez co nastąpi underrun, komp czeka na jeszcze 1 bajt i blokada. Zwłaszcza przy szerokim ekranie.
    
    Przerabiałem to w epoce, byle przerwania DLI powodowały losowe klincze w transmisji. A procedura obsługi przerwania IRQ nie jest jakoś specjalnie zoptymalizowana.
    
    Podejrzewam natomiast, że to może być synergia - suma przerwań ma znaczenie. Przełóż Twoją część z vblk do dli na inne miejsce, najlepiej pod koniec obrazu, tam, gdzie masz puste linie.
    
    Pomysł z tablicowaniem parametrów w zależności od vcount też jest fajny, oszczędzisz parę cykli. Ale rozrzutny.
12. • 12: CommentAuthor0xF
    • CommentTime8 Nov 2024 20:11

     
    System nie potrafi poprawnie obsłużyć underrunu jako błędu, tylko czeka na timeout?
    
    Rzeczywiście systemowe procedury przerwań są wolne. Dużo DMA + DLI i może nie starcza czasu procka na zakończenie IRQ przed następnym.
    
    Jeśli do przepisania są wartości z dwóch tablic, to zamiast indeksować robiłbym INC młodszego bajta adresu tablicy. Trzeba się upewnić, że nie przekroczymy strony. Odpada konieczność zachowania X.
13. • 13: CommentAuthorKonop
    • CommentTime8 Nov 2024 20:11 zmieniony

     
    1. Przerwania DLI można skrócić (czasowo) pod warunkiem, że masz parę wolnych stron pamięci (wątpię):
    
    myDLIloadX .proc
    sta DLI_A
    
    lda #x // automodyfikacja na VBL
    sta COLBAK
    lda #y // automodyfikacja na VBL
    sta CHBASE
    
    lda #nextDliPtr // prekalkulowane
    sta $FFFA // alternatywnie inc $FFFB przy przekraczaniu strony
    
    lda DLI_A
    rti
    
    Jeżeli z jakichś powodów uznasz, że nie potrzebujesz zapisu do WSYNC, to musiałbyś dodatkowo skoordynować zarządzanie $FFFA/$FFFB pomiędzy VBL i DLI. VBL musiałby ustawiać $FFFA/$FFFB na adres pierwszego DLI, a ostatnie DLI na adres VBL. Dzięki temu pozbędziesz się kodu rozpoznania źródła NMI. Ten numer wykorzystuje AWM.
    
    2. Brakuje mi tutaj synchronizacji do WSYNC. Bez tego zmiany rejestrów będą przedwczesne. No chyba, że szczęśliwym zbiegiem okoliczności wpasowują się w końcowy fragment obrazu, gdzie nie widać negatywnych skutków.
    
    3. Przydałaby się własna procedura do obsługi przerwań IRQ.
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime8 Nov 2024 22:11 zmieniony

     
    System ma 2 reakcje na wczytywanie: albo robi takie ksszt, albo prrrrt i od razu ponawia odczyt, albo się zawiesza na parędziesiąt sekund (co było widać w Fujinet za czasów UDP). Więc jeśli po prostu zgubi bajt, to czeka na bajt, który nigdy nie nadejdzie. Może się też rozsynchronizować tylko troszkę i zauważyć błąd wcześniej.
    
    W SKSTAT jest kilka bitów, na które można reagować, ale nie wiem dokładnie, jak to jest sprawdzane w systemie i jaka jest reakcja, ale Zientara to wszystko ładnie opisał.
    
    STA wsync to jest armata - zawsze zadziała i to ładne tęcze generuje. Jednak generator znaków jest potrzebny tylko w momencie generowania linii znakowej, poza tym jest niewidoczny - dużo łatwiej się z jego podmianką wstrzelić, niż z rejestrami kolorów, które widać. Rozrzut jest raptem kilka cykli koloru w lewo/prawo. Czasem coś mrygnie, jak się IRQ klawisza wstrzeli (bo ktoś nie wyłączył)
    
    Stosowanie STA WSYNC "na wszelki wypadek" to trochę strzał w stopę tutaj, bo generuje opóźnienia, podczas których nic nie może skorzystać z CPU, co tylko pogarsza sytuację.
    
    Jestem prawie pewien, że rozbijając vblk na część systemową (z którą działa odczyt bezproblemowo, bo jest skrócona do minimum podczas operacji IO) oraz na część USERa (która zapewnie też się wykonuje), która idzie na DLI w pustym miejscu załatwi sprawę.
15. • 15: CommentAuthorvega1
    • CommentTime8 Nov 2024 23:11 zmieniony

     
    działa:)...zrobiłem przedłużenie mojego przerwania VBL o stare VVBLKI i działa...aczkolwiek to jeszcze nie koniec bo muszę przerwanie DLI dłuższe zrobić...bo uprościłem na max-a ale są zakłócenia w kolorach
16. • 16: CommentAuthorCharlieChaplin
    • CommentTime9 Nov 2024 00:11

     
    One can also use uDOS by Stefan Dorndorf instead of fox-DOS or XbootDOS. It has a memlo $0937 or $0938.
    
    ->link<-
    
    (latest update from 20-July-2023 by Stefan Dietrich Dorndorf)
17. • 17: CommentAuthortebe
    • CommentTime9 Nov 2024 00:11

     
    WSYNC można się pozbyć, zastępując pustymi lub bardziej sensownymi rozkazami CPU, na 65816 z większym zegarem już się rozjedzie
18. • 18:
       
      CommentAuthorjhusak
    • CommentTime9 Nov 2024 02:11 zmieniony

     
    W Altirra Hardware Reference Manual w <edit> Chapter 4.14 Scan line timing (
    ANTIC modes 2-5, subsequent lines, wide playfield)</edit> jest ładna rozpiska, ile mamy cykli w trybie znakowym przy szerokim ekranie. Wygląda na to, że zapis do rejestrów łatwo umieścić w odpowiednim miejscu w generowanej linii, by DLI procka nie przeszkadzała w wyświetlaniu.
19. • 19: CommentAuthor0xF
    • CommentTime9 Nov 2024 08:11 zmieniony

     
    W SKSTAT jest kilka bitów, na które można reagować, ale nie wiem dokładnie, jak to jest sprawdzane w systemie i jaka jest reakcja, ale Zientara to wszystko ładnie opisał.

    
    ->link<-
    

    bit 5 - serial overrun - w momencie zgłoszenia przerwania odczytu szeregowego nie obsłużono jeszcze poprzedniego (0 - wystąpił)

    
    Podstawowe procedury system operacyjnego - 3.2.2 Przerwanie odczytu z szyny szeregowej - jest kod do zgłaszania błędu 142.
20. • 20: CommentAuthortebe
    • CommentTime9 Nov 2024 11:11

     
    jhusak musiałbyś podać wersję "Altirra Hardware Reference Manual" ponieważ w najnowszej wersji (2024-09-21 Edition) na stronie 84 to rozdział "Abnormal shift patterns"
21. • 21:
       
      CommentAuthorjhusak
    • CommentTime9 Nov 2024 12:11 zmieniony

     
    Pewnie tak, wziąłem z dysku :), poprawione. @0xF - dzięki za uzupełnienie.
22. • 22: CommentAuthorvega1
    • CommentTime9 Nov 2024 22:11 zmieniony

     
    prawie działa ale chyba jest problem ze jak IRQ i NMI razem wystąpią to pomija NMI czyli DLI...bo minimalnie potrafi mignąć

    • bb-dli.avi
23. • 23: CommentAuthortebe
    • CommentTime9 Nov 2024 22:11 zmieniony

     
    xBios, tylko on potrafi takie cuda
24. • 24: CommentAuthorthewasp
    • CommentTime10 Nov 2024 18:11

     
    NMI w 6502 ma "wyższy priorytet", tj. może przerwać handler przerwania maskowalnego (IRQ). W drugą stronę to nie działa. Przyczyna "migania" musi być inna.
25. • 25: CommentAuthor0xF
    • CommentTime10 Nov 2024 20:11

     
    vega1 ma rację. Altirra Hardware Reference Manual "Effects of overlapping IRQ/NMI timing"
26. • 26:
       
      CommentAuthorjhusak
    • CommentTime10 Nov 2024 23:11

     

    AHRM:

    Unusual behavior starts when the IRQ sequence begins on cycle 4, which causes the NMI to be lost entirely. Afterward, the IRQ sequence that would begin at cycle 5 or later is taken over by the NMI, resulting in the NMI handler executing earlier than usual.
    

    
    
    Z tego widzę, że w przypadku wejścia IRQ w cyklu 4 gubimy następujący po nim NMI. A jeśli w cyklu 5 i kilku dalszych, NMI wchodzi ZAMIAST IRQ. Czy w takiej sytuacji IRQ się wykona PO NMI?
27. • 27: CommentAuthorthewasp
    • CommentTime10 Nov 2024 23:11 zmieniony

     
    Błędy architektury NMOS są znane. Z tego co pamiętam, ten problem miał się tyczyć wykonania przerwania soft (BRK). Całkowita utrata cyklu NMI na tle IRQ to mimo wszystko spore kuriozum, niebadane przeze mnie szczegółowo w CPU związanym z A8. Swoją drogą, zjawisko powinno zauważalnie dawać o sobie znać również w innych przypadkach (związanych nie tylko z przerwaniami DL), pomimo mniejszego prawdopodobieństwa zajścia.
28. • 28: CommentAuthorthewasp
    • CommentTime10 Nov 2024 23:11 zmieniony

     
    IRQ jest sygnalizowane poziomem, do czasu dezaktywacji sygnału żądania przerwania. Ew. zgubienie czegokolwiek w obrębie cyklu automatu nie jest problemem.
29. • 29: CommentAuthorvega1
    • CommentTime11 Nov 2024 16:11

     
    no coż czasem coś tam mignie...poza tym gra śmiga...jest to akceptowalne
30. • 30: CommentAuthorthewasp
    • CommentTime11 Nov 2024 19:11

     
    Pozwolę sobie na mały offtop: Jestem bardzo ciekaw rezultatów i czekam na wydanie. Zapowiada się bardzo obiecująco.
31. • 31: CommentAuthortebe
    • CommentTime11 Nov 2024 19:11

     
    The Muppet Movie Slideshow, logos ze zmianami na DLI + I/O
    
    
32. • 32:
       
      CommentAuthorjhusak
    • CommentTime12 Nov 2024 14:11

     
    A co tu się na DLI dzieje? Skroll? te 2 paseczki? Wg mnie tu nie ma DLI, wszystko na VBLANK, a przynajmniej można to tylko na VBLANK zrobić.
33. • 33: CommentAuthortebe
    • CommentTime12 Nov 2024 14:11

     
    logos Madteam, podczas ładowania
34. • 34: CommentAuthor0xF
    • CommentTime12 Nov 2024 22:11

     

    jhusak:

    Czy w takiej sytuacji IRQ się wykona PO NMI?

    
    Tak.
    
    

    thewasp:

    Swoją drogą, zjawisko powinno zauważalnie dawać o sobie znać również w innych przypadkach (związanych nie tylko z przerwaniami DL), pomimo mniejszego prawdopodobieństwa zajścia.

    
    Najczęściej IRQ to przerwanie klawiatury, kontrolowane dzielnikiem 114, a więc w zależności od odległości tego dzielnika POKEYa od dzielnika ANTICa, problem będzie występował bardzo często albo wcale. Inicjalizacja POKEYa w OS jest widocznie w takim momencie, że problem nie pojawia się wcale. Można spróbować sprowokować problem przez reset POKEYa zerem w SKCTL.
    
    Przerwania transmisji szeregowej prawdopodobnie mogą powodować pominięcie VLBKI, ale ono niewiele robi w trakcie transmisji (głównie zlicza timeout), więc nawet nie jesteśmy tego świadomi.
35. • 35: CommentAuthorthewasp
    • CommentTime13 Nov 2024 00:11 zmieniony

     
    0xF: Zdarzenia I/O (serial RX i KBD) związane z aktywacją linii IRQ nie są w żaden sposób synchronizowane z sygnałami generowanymi przez układ graficzny, dlatego możemy mówić o mniejszym lub większym prawdopodobieństwie wystąpienia niekorzystnej konfiguracji czasowej dwóch zjawisk: momentu rozpoczęcia cyklu przerwania (wewnętrzny stan 6502) i opadającego zbocza sygnału NMI. Oczywistym jest, że transmisja danych w połączeniu ze zwiększoną częstością aktywacji NMI zwiększy tę wartość i tyle.
    
    Błąd jak błąd, choć "hijacking" przerwań w NMOS 6502 miał polegać na czymś innym: Na "porwaniu" przerwania BRK, które ma charakter "jednorazowy", tj. nie utrzymuje poziomu aktywności tak, jak przerwanie IRQ, którego sygnał (będący wynikiem iloczynu logicznego sygnałów ze wszystkich źródeł) pozostanie aktywny dopóty, dopóki soft (najczęściej handler) go nie wyłączy.
    
    Skoro jednak jest inaczej, tzn. NMI może "wypaść" to... fatalnie! :) NMI jest przecież tym środkiem, który ma gwarantować możliwie najszybszą realizację procesów krytycznych. Skoro ów środek jest tak skuteczny, że aż może zawieść to... słabo wyglądałyby te systemy "life support", o których opowiadał Bill Mensch (CEO Westen Design Center, członek grupy inżynierów pracujących w projekcie Chucka Peddle). Na szczęście wersje CMOS są pozbawione problemów pierwowzoru.
    
    Nie było gier, korzystających z DLI i klawiatury, takich które nie dezaktywowałyby jej przerwania? Względnie dodatków systemowych, korzystających z DLI? Może i nie - nie pamiętam. Wtedy faktycznie, ciężko cokolwiek zauważyć (choć taki "scroll poziomy" miałby prawo "dławić się" sporadycznie, podczas ładowania) - może faktycznie, najzwyczajniej w świecie nie zwracaliśmy na to uwagi.
36. • 36: CommentAuthor0xF
    • CommentTime13 Nov 2024 07:11

     
    Jeśli przez "KBD" rozumiesz klawiaturę, to jej przerwania są zsynchronizowane z obrazem, więc DLI i VBLKI. Poczytaj, jak działa skanowanie klawiatury przez POKEY.
    
    Że są błędy w 6502... Nie wiem, czy masz świadomość, ile i jakich jest błędów w nowoczesnych CPU i GPU?
37. • 37: CommentAuthorthewasp
    • CommentTime13 Nov 2024 08:11 zmieniony

     
    Nie muszę specjalnie czytać, znam mechanizmy POKEYa i owszem - oryginalny automat bazuje na synchronizacji HSYNC (układ opracowany przeze mnie - już nie).
    
    VBLKI nie ma żadnego wpływu na moment wystąpienie bitu start w torze RX (a tym samym SID RDY), względnie na relacje IRQ/NMI związane z przerwaniami TIM(1,2,4).
    
    "Nie wiem, czy masz świadomość, ile i jakich jest błędów w nowoczesnych CPU i GPU?". Sugeruję nie rozmawiać o tym w tym miejscu. Na co dzień projektuję układy cyfrowe o podobnym stopniu złożoności.
38. • 38:
       
      CommentAuthorKrótki
    • CommentTime13 Nov 2024 09:11

     

    thewasp:

    Błędy architektury NMOS są znane.

    
    

    thewasp:

    Skoro jednak jest inaczej, tzn. NMI może "wypaść" to... fatalnie! :) NMI jest przecież tym środkiem, który ma gwarantować możliwie najszybszą realizację procesów krytycznych. Skoro ów środek jest tak skuteczny, że aż może zawieść to... słabo wyglądałyby te systemy "life support", o których opowiadał Bill Mensch (CEO Westen Design Center, członek grupy inżynierów pracujących w projekcie Chucka Peddle). Na szczęście wersje CMOS są pozbawione problemów pierwowzoru.

    
    To nie jest problem architektury NMOS, tylko tego, że ANTIC sygnalizuje przerwanie na nóżce /NMI procesora tylko przez 2 cykle - gdyby robił to dłużej, problem by zniknął.
    
    Poniżej link do dyskusji na ten temat:
    ->link<-
39. • 39: CommentAuthorthewasp
    • CommentTime13 Nov 2024 09:11

     
    (Co znaczy dokładnie tyle, że o sposobie projektowania układów cyfrowych przez współczesne zespoły wiem raczej sporo - nie, że moje są błędne :D)
    
    Nietrudno o zdumienie przy założeniu, że możliwość utraty NMI jest faktem (mógłbym to dokładnie zbadać, ale zajmuję się obecnie innymi problemami). Nie stwarza to problemów w ATARI, jednak pomijając ten aspekt - każdy mechanizm jest zwykle wart tyle, ile warta jest jego najsłabsza część.
40. • 40: CommentAuthorthewasp
    • CommentTime13 Nov 2024 09:11 zmieniony

     
    @Krótki: Rozpatruję to w kategoriach błędu. Ostatecznie NMI powinno zostać obsłużone zawsze, gdy faktycznie wystąpi (żebyśmy dobrze się zrozumieli - piszę o architekturze układu, czyli o rozwiązaniach związanych z teorią automatów i logiki, nie o technologii NMOS)
41. • 41: CommentAuthorthewasp
    • CommentTime13 Nov 2024 10:11

     
    Sygnał na linii NMI jest wewnętrznie próbkowany, dlatego oryginalna dokumentacja wyszczególni wymogi czasowe, związane z przeciwdziałaniem zjawiskom metastabilności przerzutnika (ustalony stan w odpowiednim dystansie czasowym przed opadającym zboczem sygnału phi2 i po opadającym zboczu phi2). Nie pamiętam wymogu utrzymania stanu przez minimum dwa cykle zegarowe, jeśli istniał - okej. Zgoda
42. • 42:
       
      CommentAuthorgienekp
    • CommentTime13 Nov 2024 11:11

     
    Co to za przerwanie, które można "zgubić"? Toż to szok! :)
    
    To jak to teraz nazwać, "zgłoszenie ewentualnego zapotrzebowania na procesor"?
43. • 43: CommentAuthorthewasp
    • CommentTime13 Nov 2024 11:11

     
    @gienekp: W punkt! :)