537 
            08.09.2025, 19:53 Uhr 
            MarioG77 
            
  
 
  | 
          Noch nicht viel weiter... Die Messung am DMA Controller war nicht sonderlich hilfreich. Auffällig ist, dass der DMA Controller bis zu(!) 3 Lesevorgänge bearbeitet, bis der Rechner hängt. Wenn er einmal gehangen hat, funktioniert auch kein Reset mehr - der braucht einen Moment ohne Saft, dann bootet er wieder.
  Ab da ist meistens das Pieeeep Piep Piep deutlich länger, als normal - der lange Piep Ton dauert dann ca 2,5s.
  Laut BIOS wird die Länge des Piepton in einer Schleife - die auf dem DMA Timing basiert - bestimmt. Also wieder ein Hinweis auf ein Problem mit dem DMA:
 
 
 | Quellcode: |   play_sound:   ; make sound? beeeeep - bip - bip         pushfw         cli         OR_DH_DH         jz .do_dl_loop .loop:                 mov bl,0x70; 100ms???         mov cx,0x500; freq         call word speaker         mov cx,0xc233; 55ms? 18 per sec?         call word WAIT_DMA_CYCLE         dec dh         jnz .loop .do_dl_loop:         mov bl,0x12         mov cx,0x4b8         call word speaker         mov cx,0x8178         call word WAIT_DMA_CYCLE         dec dl         jnz .do_dl_loop         mov cx,0x8178         call word WAIT_DMA_CYCLE         popfw         ret ...
  WAIT_DMA_CYCLE:          push ax         shr cx,1         jcxz .end         mov al,[BIOS_OFF_DMA_MODE_REGISTER] ;0x4e0 vs 0xe0 ?         out DMA_MODE_REGISTER,al ; al=0x01 .wait:         pushfw         cli .dma_cycle:         in al,DMA_ADR0         and al,0xfe; ignore A0-bit         CMP_AH_AL         MOV_AH_AL         in al,DMA_ADR0; read 2nd half         jz .dma_cycle         popfw         loop .wait .end:         pop ax         ret
  |  
 
 
  Damit habe ich gerade mal die KI meines nächsten Browser Tabs beworfen. Die Antwort von Claude:
 
 
 | Zitat: |   Die WAIT_DMA_CYCLE Funktion implementiert ein präzises Timing basierend auf DMA-Zyklen des 8237 DMA-Controllers. Hier die Analyse: Funktionsweise der WAIT_DMA_CYCLE: Grundprinzip: Die Funktion nutzt die Tatsache, dass der 8237 DMA-Controller seine Adressregister kontinuierlich inkrementiert, auch wenn gerade kein aktiver DMA-Transfer läuft. Schritt-für-Schritt:
  Setup:
  cx wird halbiert (shr cx,1) - das Timing wird also in halben Einheiten gemessen Der DMA-Modus wird aus BIOS_OFF_DMA_MODE_REGISTER geladen und gesetzt
 
  Zykluserkennung:
  Liest DMA-Adressregister 0 (DMA_ADR0) Maskiert das niedrigste Bit (and al,0xfe) - ignoriert A0 Vergleicht mit vorherigem Wert (CMP_AH_AL) Liest zweimal, um einen vollständigen 16-Bit-Adresszyklus zu erfassen
 
  Timing:
  Wartet auf Änderung der DMA-Adresse (= ein DMA-Refresh-Zyklus) Jeder erkannte Zyklus entspricht einer festen Zeiteinheit Die äußere Schleife (loop .wait) zählt diese Zyklen
 
 
  Relevanz für Ihren Fehler: Das verlängerte Piepen nach Floppy-Zugriff deutet darauf hin, dass:
  DMA-Timing gestört: Der DMA-Controller liefert möglicherweise inkonsistente oder zu langsame Refresh-Zyklen Hängende DMA-Anfrage: Kanal 2 (Floppy) könnte in einem undefinierten Zustand stecken Adressbus-Problem: Fehlerhafte Adressleitungen könnten die Zykluserkennung beeinträchtigen
  Diagnose-Tipp: Prüfen Sie mit Ihrem Logic Analyzer:
  DMA-Refresh-Zyklen auf Kanal 0 während des Piepton-Codes Ob die DMA-Adressregister korrekt inkrementieren Timing zwischen den 3 beobachteten Lesezyklen auf Kanal 2
  Der 8237A neigt bei Hardwarefehlern dazu, in undefinierten Zuständen zu "hängen", was genau diese Symptome erklären würde.
  |  
 
 
  Ich muss jetzt warten, bis ich wieder einen normalen Zyklus habe, das wird dann vermutlich erst in einer Stunde oder später sein. Da komme ich leider erst zeitlich am Mittwoch wieder dran... -- Gruss Mario
  Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1 Zu restaurieren: 1x A5120 und hin und wieder was von oben |