Hi Olaf,
ich werde mal versuchen das Phänomen nachzustellen. Bislang hatte ich ausschließlich über die serielle Schnittstelle der CPU (Videokarte 8.2) gearbeitet.
Im meiner "MFA-Jugend" hatte ich die beiden Seriell-In/Out-Vektoren $FC80/$FC83 auf eine angepasste serielle Kassetten-Schnittstellenkarte verbogen ($FC86/$FC89), um daran mein RS232-Terminalprogramm anzuschließen. Damals gab es aber noch kein MAT32k, somit war das für mich auch kein Problem und es funktionierte, vermeintlich alles (wie bei Dir aktuell auch, zumindestens wenn es MAT85 betrifft).
Aber eines habe ich mittlerweile immer wieder festgestellt: Die Routinen in MAT85+, SPS, Basic, Editor sind sehr eigenwillig programmiert, vor allem was den Umgang mit Systemroutinen angeht.
Ein kleines Beispiel wenn es z.B. um das Löschen des Bildschirminhalts geht (wird bei SPS und BASIC als erstes angesprungen):
;******************************************************************************
;* BCLEAR - Bildschirm loeschen
;*
;* Veraenderte Register
;* -
;******************************************************************************
BCLEAR:
L3FD6:
push psw ;L3fd6 f5
push d ;L3fd7 d5
push h ;L3fd8 e5
lhld M85RAM_FC84 ;L3fd9 2a 84 fc Vektor fuer SEROUT sichern
push h ;L3fdc e5
lxi h,SERO ;L3fdd 21 9f 08 kurzfristig den SEROUT-Vektor verbiegen
shld M85RAM_FC84 ;L3fe0 22 84 fc
call SERIT3b ;L3fe3 cd 90 08 Direkteinsprung in MAT85, Bildschirm loeschen
pop h ;L3fe6 e1
shld M85RAM_FC84 ;L3fe7 22 84 fc Vektor wiederherstellen
pop h ;L3fea e1
pop d ;L3feb d1
pop psw ;L3fec f1
ret ;L3fed c9
Alles anzeigen
Auch viele andere Stellen habe ich bei meiner Arbeit gefunden, die "unschön" programmiert sind. Dies ist den offensichtlich verschiedenen Programmierern geschuldet, die die jeweiligen Teile des MAT85+-Systems erstellt und anschließend irgendwie zusammengefrickelt haben.
Im Code wurde dann auch gerne mal die serielle Schnittstelle (CAS-In/Out) mit $F0/$F1 und auch mal mit $FE/$FF angesprochen, um nur einen der vielen Fehler die ich gefunden habe, aufzuzählen.
Auch viele Direkteinsprünge in den MAT85-Code (keine Nutzung der Sprungtabelle des MAT85-Codes) können hier Dein geschildertes Problem verursachen. Denn dadurch werden vorher umgestellte In/Out-Vektoren umgangen bzw. nicht mehr berücksichtigt.
Ich werde die Tage mal Dein Problem nachstellen, eventuell finde ich ja den Fehler in den (verschiedensten) Routinen.
Wie hast Du denn eigentlich deine Ein-/Ausgabe geändert? Hast Du den In/Out-Vektor verbogen oder die Routinen an das Grant Searle -Modul angepasst?
Den Assembler-Code muss ich noch ein wenig aufräumen, denn hier sind noch viele Hilfs-Kommentare und Verweishinweise enthalten, die erst noch bereinigt werden müssen. Aber eines ist mit mittlerweile gelungen: Das MAT32k besteht nun aus MAT85, SP1, SPS, Kontaktplan, Basic, Editor incl. Hilfsmenu und dem GAL-Programmierer, sowie etlichen Anpassungen und Erweiterungen. Dadurch habe ich aber jetzt ein neues Problem bekommen. Freie Speicherplatz in dem 32k-Eprom: ein einziges Byte ...
Gruß
Thilo