Announcement: there is an English version of this forum on Hallo, ich habe ein Programmierproblem aus antiker Zeit. Es geht darum einen möglichen Hardware-Defekt auf dem Mainboard eines 286er zu finden. Szenario: das Rechner funktioniert soweit einwandfrei, sämtliche 8-bit oder 8-bit-fähigen ISA Steckkarten bekomme ich zum Laufen, bei reinen 16-bit ISA Steckkarten funktioniert es nicht. Auf der Hauptplatine sitzt zwischen Chipsatz und dem ISA-Bus etwas 74er Logik, im Wesentlichen sind das 74ACT245 Bustransceiver. Eine Möglichkeit ist, dass ein oder mehrere dieser Bustransceiver defekt sind. Das würde ich gerne gezielt durchmessen. Transceiver sitzten sowohl im Daten- wie im Addressbus. Auf dem 8-bit Teil des ISA Bus liegen DATA<0..7> und ADR<0..19>. Auf der 16-bit Erweiterung des ISA Bus liegen DATA<8..15> und ADR<17.23>. Ich würde jetzt gern ein kurzes Testprogramm schreiben, mit dem ich gezielt auf eine Addresse einen Datenwert schreibe, dann könnte ich messen ob das am ISA Bus ankommt, bzw. wo auf dem Weg dahin das Problem liegt. Ich bin zwar fit in einigen Programmiersprachen, aber bei MS DOS und Hardware ansprechen hört es auf. Ich bin soweit gekommen das ich z.B. mit QBASIC Folgendes machen könnte 10 FOR a = 0 to 255 20 OUT &H80, a 30 NEXT a 40 GOTO 10 Das wäre als rudimentärer Test für den 8-bit ISA Teil ok, aber ich komme damit nicht in den ADR<17.23> Bereicht, und OUT schreibt nur ein Byte also auch kein Test für DATA<8..15>. Was Programmiersprachen angeht bin ich offen, QBASIC, darf auch gerne C sein oder Turbo Pascal, eigentlich alles wofür ich einen Compiler für DOS besorgen kann. Falls es Assembler wäre bräuchte ich etwas Erklärung zum Code dazu, Assembler ist zu lange her und war auf 68k. Also...habt ihr ein paar Zeilen Code mit dem ich den 16-bit ISA Bus testen könnte? Gruss, Ingo
Es gibt einen IO Bereich, beim PC 0x00-0x3ff oder so mit dem out Befehl und einen Datenbereich mit segment und Offset 1MB oder 16 MB.
Ingo schrieb: > OUT &H80, a Setzt doch nur ein Byte auf Adresse H80. Keine Ahnung was auf H80 ist aber ich denke wenn es 16 bit sein soll wird auf 81 das zweite Byte sein.
Ingo schrieb: > Das wäre als rudimentärer Test für den 8-bit ISA Teil ok Nö, noch nicht mal. Damit "testest" Du nur I/O-Zugriffe, nicht aber Speicherzugriffe. Mit der QBASIC-Funktion Peek kannst Du einen lesenden Speicherzugriff innerhalb eines 16-Bit-Segments ausführen, mit DEF SEG legst Du die Segmentadresse fest. Und damit kannst Du beliebige Speicheradressen von 0000:0000 bis FFFF:FFFF ansprechen. Falls Du das mit den Segmenten nicht kennst - PCs nutzen im "real mode" eine 20-Bit-Adressierung, und diese 20 Bit setzen sich aus zwei 16-Bit-Werten wie folgt zusammen:
1 | Segment xxxx0 |
2 | + Offset 0yyyy |
Das ist also mehrdeutig; 0100:0001 ergibt die gleiche Adresse wie 0000:1001 Effektiv kannst Du den Adressraum in 16 Blöcke à 64 kByte zerlegen, das sind die Segmente 0000, 1000, 2000 ... bis E000 und F000. Mit dem Offset (das ist der Wert, den Du der PEEK-Funktion übergibst) kannst Du 64 kByte innerhalb des Segments ansprechen. Klingt komisch? Ist aber so. Peek: https://scruss.com/qbasic_hlp/T00AB.html Def Seg: https://scruss.com/qbasic_hlp/T00A0.html
:
Bearbeitet durch User
Harald K. schrieb: > Falls Du das mit den Segmenten nicht kennst - PCs nutzen im "real mode" > eine 20-Bit-Adressierung, und diese 20 Bit setzen sich aus zwei > 16-Bit-Werten wie folgt zusammen: Ok der Teil ist schonmal interessant, und wir Rüdiger geschrieben hat liegen im unteren Bereich die IO-Addressen....so dunkel kommt mir das bekannt vor, vor so 30 Jahren mal auf den Registern der VGA Karte rumgeschrieben :) Statt PEEK würde ich POKE nehmen - ich will schon schreiben, und dann auf dem ISA Bus schauen was dort ankommt. Nur sind wir da immernoch im 8-bit ISA Bereich - PEEK/POKE nehmen nur byte values, ich muss aber DATA 8-15 testen - 20-bit Addressen reicht auch nicht, da bin ich noch im 1MB Addressraum, ich müsste aber eigentlich in den 24-bit Addressraum also 16MB um die Addressleitungen auf dem 16-bit Teil zu testen. Zum Verständnis hier ein Bild vom ISA Stecker https://upload.wikimedia.org/wikipedia/commons/0/0b/ISA_Bus_pins.png
Ok spannend.....24-bit Addressierung wäre wohl Protected Mode, der beim 286er auch ein rechter Krampf ist weil man wohl da ohne Reset nicht mehr raus kommt. Aber ich habe nochmal Steckkarten verglichen, und vielleicht kann ich einen Fehler auf den Addressleitungen ausschliessen. Eine Karte die nicht lief war eine VGA Karte mit GD5424, die Verwendet die Addressleitungen A17-A23 und ist 16-bit only. Aber auch eine Tseng ET4000AX lief nicht, die ist zwar 16-bit aber verwendet die Addressleitungen auf der 16-bit Erweiterung nicht. Damit würde sich der Verdacht auf defekte 74er Logik auf gerade mal 2 Chips verringern. Ok die könnte ich jetzt einfach mal blind tauschen, aber wir sind ja auch neugierig. Einfach nur ein 16-bit Write und sei es auf irgendeine Addresse im IO Bereich würde es ja schon tun für einen Test. Morgen mal schaun ob ich mit Turbo Pascal weiter komm....etwas Beispielcode habe ich gefunden, leider wieder nur Byte-Writes aber müsste mal schaun ob ich da nicht einen UInt16 direkt schreiben kann und was das macht. Ach da werden Erinnerungen wach, so ein Codebeispiel fiel mir mal vor 30+ Jahren in die Finger und dann hab ich ein Diskettenkopierprogramm geschrieben schön mit Grafik und 3D-Buttons. Wär so spannend das wieder zu finden und zu sehen was für einen MIST ich da geschrieben hab :D
Ich will dir ja die Freude an der Fehlersuche nicht daempfen, aber die "geheime Wunderwaffe" der Hardwareentwickler dieser Zeit waren in Schottkytechnologie gebaute PALs. In IBMs IBM/AT finden sich m.W. z.B. genau drei solcher PALs an den entscheidenden Stellen der Dekodierung. Die kann man zwar grundsaetzlich selbst programmieren, du wirst aber heute kaum "leere" PALs kaufen, noch einen Programmierer einfach dafuer auftreiben koennen. Da bleibt dann nur ein Spenderboard und eine Transplantation. Hat man keinen (In-Circuit-)CPU-Tester wie den TI990(?) mit passendem Pod, ist die naechst beste Option ein DOS-Debugger und ein hinreichend vielkanaliger Logikanalysator. Dazu muss man natuerlich ein wenig 8086 Assembler k(o)ennen. Mit einem BASIC-Interpreter ist das nur Gestocher im Heuhaufen. Ein funktionsfaehiger 286er koennte dir auch wertvolle Einsichten in die Ablaeufe unterschiedlicher Buszyklen bescheren. Und die Schaltplaene des IBM/AT die schaltungstechnische Umsetzung am Beispiel zeigen. Viel Erfolg!
Motopick schrieb: > Ich will dir ja die Freude an der Fehlersuche nicht daempfen Keine Sorge, tust du nicht :) Der "286er" ist ein Commodore A2286 Bridgeboard, also im Prinzip so etwas wie ein Single-Board-Computer mit einer zusätlichen Anbindung des Amiga Zorro Bus. Die Bus-Transceiver werden in der Tat von PALs angesteuert, aber von denen habe ich die JEDEC Files, PALs sind beschaffbar bzw. könnte die auch in GAL umwandeln, und Programmierhardware bis zum guten HiLo All-07 ist auch vorhanden :) Ich habe die PALs - noch - nicht im Verdacht, da sie auch einige andere Signale bereitstellen, und es scheint wirklich Alles bis auf den 16-bit Teil vom ISA zu funktionieren. Aber daher auch die Motivation das wirklich zu testen, ich will nicht wahllos Chips austauschen und dann ist der Fehler immernoch vorhanden, oder im schlimmsten Fall schlägt Murphys Law zu und beim Tauschen entsteht noch ein weiterer Defekt so dass ich dann 2 parallel suchen darf. Aber ganz auszuschliessen ist das mit den PALs auch nicht, die sind nach 30+ Jahren weit über ihre Werte in den Datenblätter bezüglich Programmierung halten.
Ingo schrieb: > 286er zu finden. Szenario: das Rechner funktioniert soweit einwandfrei, > sämtliche 8-bit oder 8-bit-fähigen ISA Steckkarten bekomme ich zum > Laufen, bei reinen 16-bit ISA Steckkarten funktioniert es nicht. Das muß nicht unbedingt etwas kaputt sein, es gab Chipsätze mit schlechtem Timing. Falls der zufällig "Suntac" ist, abhaken.
Ingo schrieb: > ... Aber ganz auszuschliessen ist das > mit den PALs auch nicht, die sind nach 30+ Jahren weit über ihre Werte > in den Datenblätter bezüglich Programmierung halten. Wenn es echte PALs sind: Da werden Fuses weggebrannt. Haltbarkeit: Ewig Aber "schwache" Ausgaenge... Kuriosum: Ein 2kB ROM(!) aus einem Apple mit einem kippelnden Bit.
Motopick schrieb: > Kuriosum: Ein 2kB ROM(!) aus einem Apple mit einem kippelnden Bit. Wunderbar, sowas freut bei der Suche :D Richtig...GALs waren die Kandidaten die die Programmierung verlieren...nein sind echte PAL auf der Karte. Bin mal gespannt was es ist...könnte auch blöd sein und ein Haarriss einer Leiterbahn...also mal schaun ob ich mit Turbo Pascal da irgendwie weiter komm...245er hab ich eh keine da, so dass ich garnicht in die Versuchung komm doch mal blind Chips zu tauschen.
Ich würde ja beinahe sagen, daß direktes Schreiben auf den ISA-Bus gar nicht ohne weiteres möglich ist, bzw. wenn es möglich ist, das System crashen kann. Auf diesem Bus läuft bereits DMA und die Steckkarten müssen sich an IRQs und DMA-Kanäle halten, damit der Bus funktioniert.
Ingo schrieb: > Ok der Teil ist schonmal interessant, und wir Rüdiger geschrieben hat > liegen im unteren Bereich die IO-Addressen. Die liegen nicht im unteren Bereich, das ist ein komplett separater Adressraum. x86-CPUs haben zwei Adressräume, einen 64 kB großen I/O-Adressraum, der mit I/O-Instruktionen (IN und OUT) angesprochen wird, und den Adressraum, in dem Programm und Daten liegen. Zwar teilen sich die Adressräume die Datenleitungen, aber die für die Datenübertragung verwendeten Signale /IOR & /IOW sind separat von /MEMR & /MEMW. Im ISA-Design des 5150 (PC), 5160 (XT) und auch des 5170 (AT) wird nur das unterste kByte des I/O-Adressraums (0x000 - 0x3ff) verwendet, das ist eine künstliche Beschränkung, die sich IBM ausgedacht hat, um das Hardwaredesign der ISA-Steckkarten zu vereinfachen. Die weiteren Adressleitungen werden bei I/O-Zugriffen nicht ausdecodiert, so daß effektiv ein IN 0x13f0 auf den gleichen Peripheriebaustein zugreift wie ein IN 0x03f0. Mit der Einführung des PCI-Busses wurde eine Erweiterung des I/O-Adressraums überfällig, seitdem werden 16-Bit-I/O-Adressen verwendet. Besorg' Dir mal das IBM 5170 (AT) Reference Manual, da sind die Buszyklen des 16-Bit-ISA-Busses ausführlich beschrieben. Auch das IBM 5160 (XT) Reference Manual ist lehrreich, weil Du dort das Funktionieren des 8-Bit-ISA-Busses verstehen lernen kannst. Ingo schrieb: > Statt PEEK würde ich POKE nehmen - ich will schon schreiben, und dann > auf dem ISA Bus schauen was dort ankommt. Wenn Du ohne weiteres Verständnis der PC-Architektur munter im Adressraum herumschreibst, wirst Du interessante Überraschungen erleben. > Nur sind wir da immernoch im 8-bit ISA Bereich > - PEEK/POKE nehmen nur byte values, ich muss aber DATA 8-15 testen Das Konzept gerader/ungerader Adressen ist Dir unbekannt? > - 20-bit Addressen reicht auch nicht, da bin ich noch im 1MB > Addressraum, ich müsste aber eigentlich in den 24-bit Addressraum also > 16MB um die Addressleitungen auf dem 16-bit Teil zu testen. Da müsstest Du Dein "Test"programm im "protected" Mode laufen lassen. Viel Spaß damit. Ben B. schrieb: > Ich würde ja beinahe sagen, daß direktes Schreiben auf den ISA-Bus gar > nicht ohne weiteres möglich ist, Doch, das ist es. > bzw. wenn es möglich ist, das System crashen kann. Das kann es, aber nicht aus den von Dir vermuteten Gründen. > Auf diesem Bus läuft bereits DMA und die Steckkarten > müssen sich an IRQs und DMA-Kanäle halten, damit der Bus funktioniert. Wenn DMA aktiv ist, kann die CPU nicht zugreifen und wartet, und umgekehrt. Das erledigt die Hardware, da kommt sich nichts ins Gehege. Steckkarten, die auf dem ISA-Bus selbst DMA-Zugriffe ausführen ("Busmaster-DMA") waren selten, ein Beispiel ist der Adaptec 1542 (ein SCSI-Controller). Sowas war dann auch das erste, was in späteren PCs mit zusätzlichem PCI-Bus nicht mehr funktionierte. Effektiv wurde in ISA-Systemen DMA nur für Floppycontroller benutzt, so bizarr es auch klingen mag. Das lag auch daran, daß das Hardwaredesign das ganze sehr, sehr langsam gemacht hat. Hier ein bisschen Hintergrund dazu: https://wiki.osdev.org/ISA_DMA Interrupts haben mit Speicherzugriffen überhaupt nichts zu tun. Abstürzen kann das ganze, wenn auf von anderen Dingen genutzte Speicherbereiche zugegriffen wird. So ein Programm liegt schließlich irgendwo im RAM, und das RAM teilt sich den Adressraum mit dem Rest. Wenn also ein Testprogramm sich selbst oder das Betriebssystem überschreibt, dann war's das.
> Das würde ich gerne gezielt durchmessen. Transceiver sitzten > sowohl im Daten- wie im Addressbus. Das ist der grosse Moment des Komponententesters im Oszi: Beitrag "Einfacher Komponententester fuer Oszi" Einmal kurz an jede Leitung und du siehst sofort eine verbratene Ausgangsstufe weil ja alle Daten und Adressleitungen dasselbe Bild ergeben muessen. Vanye
Vanye, Du wurdest schon mehrfach darum gebeten, Zitate nicht zu verstümmeln. Warum machst Du das immer noch?
Ingo schrieb: > Szenario: das Rechner funktioniert soweit einwandfrei, > sämtliche 8-bit oder 8-bit-fähigen ISA Steckkarten bekomme ich zum > Laufen, bei reinen 16-bit ISA Steckkarten funktioniert es nicht. Was exakt bekommst Du "nicht zum Laufen"? Wie wirkt sich das "funktioniert nicht" aus? Was machen die "reinen 16-bit-ISA-Steckkarten"? Welche sind das? (Typenbezeichnung und/oder Bild) Womit versuchst Du die "zum Laufen" zu bekommen?
Ingo schrieb: > könnte auch blöd sein und ein Haarriss einer Leiterbahn Das erinnert mich an mein persönliches Fehlersuche-Highlight meiner PC-Bastelzeit: ein Hundehaar in einem PCI-Slot das immer komplett zugeschraubtem Gehäuse - aber eben nur dann - Fehler produzierte; das war ein Spaß!
Michi S. schrieb: > ein Hundehaar in einem PCI-Slot Oh shice....ja das hört sich nach viel Freude an, ab wann hast du hinterm Vorhang nach Kurt Felix gesucht? Ich bin noch nicht dazu gekommen das weiter zu testen, muss die Kiste erstmal wieder halb zusammenbauen. Aber offen ist halt immernoch wie ich mit einem Testprogramm ein Pattern auf die Datenleitungen 8-15 bekomm. Es könnte natürlich auch etwas wirklich Verrücktes sein, z.B. beim Chipsatz ein Teildefekt wo nur ein paar Pins selektiv kaputt sind...aber ich hoffe immernoch dass es doch relativ einfach wird.
Ingo schrieb: > Aber offen ist halt immernoch wie ich > mit einem Testprogramm ein Pattern auf die Datenleitungen 8-15 bekomm. Du hast noch nicht verstanden, was gerade und ungerade Adressen sind, wie? Magst Du meine Fragen beantworten? Die habe ich nicht zur Provokation gestellt, sondern aus Gründen der Diagnose. Ich habe ein bisschen das Gefühl, daß Du den falschen Baum anbellst.
> Vanye, Du wurdest schon mehrfach darum gebeten, Zitate nicht zu > verstümmeln. > > Warum machst Du das immer noch? Vielleicht weil "das" ein Exzerpt/Auszug ist und kein Zitat !? Damit handelt es sich nicht um eine "Verstümmelung" sondern um eine aufs Wesentliche fokussierende Inhaltswiedergabe. In einem Exzerpt behindert eine Quellenangabe nur den Lesefluß und ist für die Problemlösung komplett unnötig. Ende Offtopic ->|
:
Bearbeitet durch User
Bradward B. schrieb: > In einem Exzerpt behindert eine Quellenangabe nur den Lesefluß und ist > für die Problemlösung komplett unnötig. Ja, sicher, die eine Zeile behindert den Lesefluss total. Sieht man. Das man bei mehrfachen Bezügen auf einen Beitrag die Quellenangabe bei nachfolgenden Bezügen weglassen kann, wie hier > Ende Offtopic ->| zeigt, daß Du Dir da ein Problem einbildest, was so nicht existiert.
Harald K. schrieb: > Was exakt bekommst Du "nicht zum Laufen"? > > Wie wirkt sich das "funktioniert nicht" aus? > > Was machen die "reinen 16-bit-ISA-Steckkarten"? > > Welche sind das? (Typenbezeichnung und/oder Bild) > > Womit versuchst Du die "zum Laufen" zu bekommen? Ich konnte das System mit folgenden Karten testen 1) Soudblaster 16, CT2290 2) VGA Karte mit CL-GD5424, 16 bit Karte 3) VGA Karte mit Tseng ET4000ax, 16 bit Karte 4) VGA Karte mit Chips F82C451 Die Soudblaster 16 läuft, getested nur der Sound-Teil und nicht der IDE Teil der Karte. Von der Karte ist aber bekannt, dass der Sound-Teil auch in 8-bit Slots läuft. Die CL-GD5424 und ET4000ax laufen beide nicht, das heisst das System hängt ganz am Anfang, es kommt kein Bild, und soweit ich eben ohne Bild durch Beobachten von Floppy, Festplatte, etc. raten kann scheinen wir da noch vor dem PC Bios zu hängen. Die F82C451 läuft - wie man sich das eben so vorstellen kann, Bild wird angezeigt, BIOS, MS DOS bootet. Daher der Verdacht, dass es an der 16-bit Erweiterung des ISA Bus liegen könnte, und da mir die Karten zum Testen ausgehen wollte ich dann zum Messen übergehen. Was du mit dem Konzept der Geraden und Ungeraden Addressen meinst habe ich in der Tat noch nicht verstanden. Ich erinnermich Dunkel früher mal Grafikausgaben auf VGA programmiert zu haben indem ich direkt in den Speicher ab A0000 geschrieben habe, und soweit ich mich erinnere fortlaufend Byte für Byte. Das sollte doch sowohl für 8-bit VGA Karten als auch für 16-bit VGA Karten gelten, oder liege ich da falsch? Und wenn ich da falsch liefe, wie könnte ich Data 8-15 auf dem ISA Stecker testen?
Halte doch einfach mal ein Oszi dran und schau, ob Du bei Aktivität des PC plausible Signale hast. Bei defekten Datenleitungen stimmt meistens entweder der low- oder high-Pegel nicht mehr, die Flanken sind extrem verschliffen oder es gibt gar keine Aktivität mehr.
Nimm den alten AFD Debugger für DOS und schreib da ein 5 Zeilen Programm drin oder setzt die Register auf den Bereich D000:0000 und lese den bereich ein
Th S. schrieb: > Nimm den alten AFD Debugger für DOS und schreib da ein 5 Zeilen Programm > drin oder setzt die Register auf den Bereich D000:0000 und lese den > bereich ein Das DOS bringt einen Debugger mit, heißt ganz einfach debug, und kann eine txt-Datei mit Assembler-Befehlen oder auch interaktiv ausführen. Warum nicht einfach den nehmen, wenn es nur um grundsätzliche Dinge geht?
Jens G. schrieb: > Th S. schrieb: >> Nimm den alten AFD Debugger für DOS und schreib da ein 5 Zeilen Programm >> drin oder setzt die Register auf den Bereich D000:0000 und lese den >> bereich ein > > Das DOS bringt einen Debugger mit, heißt ganz einfach debug, und kann > eine txt-Datei mit Assembler-Befehlen oder auch interaktiv ausführen. > Warum nicht einfach den nehmen, wenn es nur um grundsätzliche Dinge > geht? Was das Herumgeeier mit (Quick-)Basic oder Turbopascal soll, weiss ich auch nicht. https://www.startpage.com/do/dsearch?q=%22out%20dx,ax%22 Dazu empfiehlt die Kueche noch die Liste der BIOS-Interrupts.
Mit OUT DX AX ging das. In AX kommt dein 16Bit-Wort und in DX, wo es hingehen soll. Kannst es auch übern Zeiger adressieren. Wird dann automatisch inkrementiert. Geht dann mit OUTS. Auf die Daten wird dann mit DS:SI gezeigt. 40 Jahre her. Hab damals am ECP-Druckerport (H377?) sauschnell Daten eingelesen. Da war ich 16. 😅
Mir geht's ähnlich, ich habe seinerzeit als Halbstarker einen WAV-Player für die Soundblaster 16 unter DOS in Assembler geschrieben. Allerdings kann ich mich nicht daran erinnern, daß ich dabei besonderes Augenmerk auf den ISA-Bus legen musste. Im Wesentlichen war das nur auf den Interrupt warten und der Soundkarte mitteilen wo sie ihre Daten findet, der Rest ging via DMA-Transfer wenn ich das korrekt in Erinnerung habe.
Ingo schrieb: > Also...habt ihr ein paar Zeilen Code mit dem ich den 16-bit ISA Bus > testen könnte? Wenns QBASIC 1.1 sein soll hätte ich ein erweiterbares Beispiel.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.