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?
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.
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.
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.
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.
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.
... 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.
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.
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.
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.
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.
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.
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.
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ß!
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.
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
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?
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.
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.
