Hallo! Ich stehe momentan total auf dem Schlauch. Ich möchte 2 628512 (512kB SRAM) an einen 8086 anschließen. Leider finde ich im INet keine einheitliche Beschaltung. Meistens sind es nur zusammenkopierte Vorlesungsskripte, wo jeder seinen eigenen Memorycontroller bastelt. Status momentan: Der RAM soll auf einer eigenen Platine sitzen, welche an den Adressbuss, Buscontroller und Datenbuss angeschlossen wird. Der RAM selbst ist wie folgt angeschlossen: [A1...A19] -> [A0...A18] [D0...D7] -> [D0...D7] IC1 lower Byte [D0...D7} -> [D8...D15] IC2 upper Byte Da ich den ROM in den RAM kopieren möchte, sitzt noch ein ATMega64 daneben mit folgendem Aufbau und Funktion: Alle Datenleitungen und Adressleitungen des Rams gehen direkt an Portpins. OE, WR und CS ebenso. Am SPI hängt ein EEPROM, eine (Software)Serielle ist ebenfalls vorhanden. Beim Start des Systems gibt der Mega64 ein "RAM not Ready" auf den Taktgenerator für den 8086. Dieser läuft noch nicht an bzw. gibt den Reset noch nicht frei. Der Mega64 kopiert den Inhalt des EEProms an die Startadresse des BIOS und gibt das "RAM not ready" Signal frei und der 8086 soll dann starten. Alle Ports des Mega 64 werden dann auf Tri-State geschalten um sich komplett abzukoppeln. Später ist vorgesehen über ein zweites Signal den Prozesser warten zu lassen (Waitstates) und den Raminhalt zu bearbeiten... Soweit die Theorie Nun zum Problem: Aus dem Buscontroller kommen die Signale Memory Read (MR) und Memory Write (MW). Ich habe die Abkürzungen mal so gewählt: die nennt jeder etwas anders. Über BHE\ wird die obere Hälfte (D8...D15), über A0 die untere (D0...D7) angesprochen. Beide auf "0" ist dann das ganze Wort. Bloß wo kommen die Leitungen hin? So wie ich die Sache verstanden habe, ist dies nur beim Schreiben wichtig (MW=0) Das würde bedeuten: (über Gatter verknüpft) BHE\ AND MW -> WE (High Byte) A0 AND MW -> WE (Low Byte) MR -> OE (High and Lowbyte) Was mache ich mit CS? Ich finde im Datenblatt nichts, ob bei CS die Datenausgänge auf TriState gehen (oder bei OE). Einen Latch wollte ich eigenlich vermeiden... Unter der Annahme, das CS=1=TriState ist, würde ich noch folgene Verknüpfung machen: MW OR MR -> CS=0 Ich hoffe es hat jemand bis hier durchgehalen und kann mir einen Denkschubs in die richtige Richtung geben. Mirko
CS = Chip Select RAM OE = Output Enable des RAM WR = Write des RAM Mit dem Chip Select Signal wird dem RAM Baustein mitgeteilt, dass dieser angesprochen wird. Ist dieses nicht aktiv, ignoriert er alles. Ist das CS Signal aktiv, bedeutet dies dass der RAM Baustein die an den Adresssignalen A[0..7] anliegende Adresse in seiner Matrix auswählt. Abhängig von dem RD/WR Signal übernimmt er dann entweder die Daten an den Datenleitungen D[0..7] in die ausgewählte Speicherstelle oder legt den Inhalt dieser Speicherstelle an D[0..7] an. Output Enable hingegen spielt nur bei aktiven CS und Read eine Rolle und regelt ob die Datenleitungen D[0..7] tristate sind oder nicht. Beim Write spielt OE keine Rolle. Grundlegend machen CS inaktiv und OE = inaktiv das gleiche beim Lesen. Der einzige Unterschied ist, dass der sRAM bei inaktiven CS in den Standby Modus schaltet und weniger Strom verbraucht als selektiert mit Output Disabled. Nun zu deinem Problem: Du kannst rein theoretisch das OE Signal mit dem CS Signal des Bausteins verknüppern. Alternativ auch OE ständig aktiv halten und die Auswahl nur über das CS regeln. Und zu dem CS Signal: dieses sollte im Normalfall so generiert werden, dass immer der RAM IC ausgewählt wird, welcher für die am Adressbus anliegende Adresse zuständig ist. Wenn du nun deinen Adressraum auf mehrere IC aufteilen würdest, dann müsstest du dieses generieren. Da du aber so große sRAM gewählt hast, dass diese den gesamten Adressraum abdecken, bräuchtest du dieses Signal rein theoretisch nicht. Nun kommt aber noch die Sache mit dem BIOS über den AVR: Hier hast du nun den Fall, dass du in einem bestimmten Adressraum den AVR anstatt dem RAM einblenden willst. Somit müsstest du die Adressleitungen auswerten und schauen, ob nun der ROM Bereich (="CS" vom AVR) angesprochen wird, oder der RAM Bereich (=CS vom sRAM) und entsprechend das CS Signal generieren. Gleiches solltest du auch noch beachten, wenn du beim Startup nach Erweiterungskarten schaust - so fern du welche an einem ISA Bus etc. angeschlossen hast. Erweiterungskarten können auch eigene ROMs und RAMs mitbringen. Dort musst du dann auch dafür sorgen, dass beim Zugriff auf die jeweiligen Bereiche die richtigen Bausteine angesprochen werden. So hat z.B. eine Grafikkarte einen ROM und RAM. Dabei musst du nun beachten, dass der ROM und der RAM eingeblendet wird und dein RAM dann bei Zugriff auf diese beiden Graka Speicher nicht aktiv ist und tristate bleibt. Für das Finden und Ermittlung der Größe der ROMs gibt es einen Quasi Standard nach IBM Prinzip. Eine kleine Struktur in den ersten Bytes der ROMs gibt über die Größe Auskunft und das BIOS hat einen Einsprungsvektor für die Initialisierung des ROMs. Dieses nutzt u.a. die Graka um z.B. den INT 10h umzubiegen und durch eigene Implementierungen im ROM auf den jeweiligen Grafikchip einzugehen. Da die Zugriffszeiten auf den ROM auf natürlichem Wege langsamer waren, baten viele BIOSe die Möglichkeit, den Inhalt des ROMs in den RAM umzukopieren und in dem Adressbereich den ROM der Graka auszublenden und den Hauptspeicher einfach einzublenden. Da wurde dann aber durch den Chipsatz noch ein Schreibschutz digital nachgebaut. So, ich hoffe das hilft ein wenig.
Aso, Nachtrag: Ich habe versucht bei meinen vorherigen Erklärungen immer nur das Signal zu nennen und ob es aktiv oder inaktiv sein soll. Die jeweilige endgültige Logik bei der Umsetzung muss sich dann natürlich darum kümmern, ob das Signal low-aktiv bzw. high-aktiv ist und den entsprechenden Pegel verwenden. So sind bei dem von dir genannten sRAM alle 3 Signale low aktiv, also /WE, /CS und /OE. Und noch ein weiterer Hinweis: die gesamte Erklärung geht nicht auf die Timings ein. D.h. du müsstest anhand des Datenblattes noch die Timings kontrollieren und z.B. ausrechnen, ob du beim Zugriff auf den RAM etc. Wait States einfügen musst, weil der RAM langsamer ist als die CPU. Auch die Mindestzeiten für manche Signale müssen beachtet werden.
Ich glaube kaum, dass er bei einem ollen 8086 und <=70ns RAMs Waitstates benötigt.
Die Chance ist wirklich gering, aber ich wollte darauf verwiesen haben. Schon allein, wenn man das Ganze analog auf andere Speicher anwenden will wie z.B. EPROM und andere nicht-flüchtige Speicher.
Wenn ich die Timing-Diagramme und die T1 bis T4 richtig interpretiere,
passiert folgendes: (Read Cycle)
T1 DTR=0 RD=1 Richtung
ext.Datenbus->CPU, RAM Tristate
BHE Low oder Highbyte
ALE=1 -> AD0...AD15 + A16...A19 -> ALE=0 Adressen A0...A19 liegen
am ext.Bus an
T2 AD0...AD15 float
RD=0 RAM gibt Daten auf
Datenbus
DEN=0 Transceiver aktiv
T3 AD0...AD15 enspricht den gespeicherten RAM-Inhalt
T4 Ausgangszustand ALE=0, RD=1, DTR=1, DEN=1
Bei 5Mhz dauert jeder Zyklus 200ns. Ich denke, der SRAM mit 55ns hat da
genug Zeit sich zu langweilen.
Das mit dem Adressraum hat mich jetzt etwas nachdenklich gemacht.
Ich dachte, auf ext. Erweiterungen wird per IO R/W zugegriffen (und so
auch auf den Speicher der Grafikkarte)
Das das BIOS der Grafikkarte im Hauptspeicher liegen kann, dachte ich
mir schon. (Früher nannte sich das mal "VGA BIOS Shadow" oder so
ähnlich)
Bei so manchen BIOS war es schon damals so, das sie sich in den RAM
kopierten...ich frage mich gerade, ob es da auch einen "Schreibschutz"
gab...
Aber bevor es abschweift:
Ich brauche direkt am RAM (Wenn man es sich als Erweiterungskarte
vorstellt) nur die Signale:
A0...A19
D0...D15
RD
WR
BHE
Aus BHE und A0 mache ich die Unterscheidung ob es das Low, High oder
beide Bytes sind
-> verknüpft mit AND RD -> gehen an OE(h) und OE(l) <- lesen
-> verknüpft mit AND RD -> gehen an OE(h) und OE(l) <- schreiben
-> verknüpft mit AND WR -> gehen an WR(h) and WR(l)
(h=Highbyte-SRAM und l=Lowbyte-SRAM)
CS würde ich auf Low lassen.
So...das war es erstmal... ;)
Mirko
Mirko Barthel schrieb: > Wenn ich die Timing-Diagramme und die T1 bis T4 richtig interpretiere, > passiert folgendes: (Read Cycle) ja, soweit richtig > Das mit dem Adressraum hat mich jetzt etwas nachdenklich gemacht. > Ich dachte, auf ext. Erweiterungen wird per IO R/W zugegriffen (und so > auch auf den Speicher der Grafikkarte) Naja, hängt halt von dem Typ der Karte ab. Eine Grafikkarte hat RAM und ROM. In der damaligen Form dual-port RAM, so dass der Grafik-IC jederzeit den RAM auslesen konnte um die x Bilder pro Sekunde aufzubauen und die CPU am anderen Port, wo die Anwendungsprogramme die Ausgabedaten abgelegt haben. Der Zugriff auf den Arbeitsspeicher ist für 50 Bilder pro Sekunde viel zu langsam (gleiches für den ISA Bus) und von daher bringt die Graka eigenen Speicher mit. Dieser liegt im normalen Speicher Adressraum der CPU. Bei dem ROM das gleiche soweit, schon allein da der ROM ja ein wenig was umbiegen möchte im Arbeitsspeicher den auch die CPU nutzt (Software API über Interrupt). Die I/O Adressen und deren Inhalt wiederrum spiegelten damals die Konfigurationsregister der IC der Karten wieder. Diese wurden damals nicht in den damals knapp bemessenen Arbeitsspeicherbereich eingeblendet (wie es später/heute PCI Geräte machen) sondern hatten einen eigenen Adressraum (I/O address space). Dieser wurde über sogenannte Portadressen adressiert - dafür gibt es spezielle Befehle im 8086 Befehlssatz (in, out etc). Die Hardwareanbindung gestaltet sich hierbei eigentlich gleich zum normalen Speicherzugriff, nur dass diesmal S2 aktiv (low) ist. Bei einem normalen Speicherzugriff wäre S2 inaktiv (high). Die I/O Adressen sind auf A0..A15 beschränkt. Beispielsweise der Interrupt Controller wird nur über I/O Portadressen angesprochen. Seine Adressen werden nicht in den normalen Adressraum eingeblendet (was man aber prinzipell immer machen kann - es reduziert nur den Adressraum und erhöht die Komplexität Selektionslogik). So hat es sich aus IBMs ersten Geräten her eingebürgert (IBM Kompatibilität), den ersten PIC auf die Portadressen 0x20 - 0x3F zu dekodieren und den zweiten auf 0xA0 - 0xBF. Da die PIC jeweils nur zwei Portadressen nutzen (indizierter Zugriff) ist der restliche Adressraum ungenutzt bzw. enthielt Spiegelungen der ersten beiden Ports. Diesen "ungenutzten" Portadressen haben dann später die Chipsätze und andere Controller genutzt und dort ihre Register eingeblendet. > Das das BIOS der Grafikkarte im Hauptspeicher liegen kann, dachte ich > mir schon. (Früher nannte sich das mal "VGA BIOS Shadow" oder so > ähnlich) ja, genau. > Bei so manchen BIOS war es schon damals so, das sie sich in den RAM > kopierten...ich frage mich gerade, ob es da auch einen "Schreibschutz" > gab... Ja, die Chipsätze hatten damals ja alle wichtigen Signale "zur Hand" und haben u.a. die Adressdekodierungen gemacht für die ganzen Standard Controller (CS Signale) und später diese einfach komplett intern nachgebildet (steigende Integrationsdichte). Dabei haben die Chipsätze auch die Verwaltung des Arbeitspeichers vorgenommen und konnten somit steuern ob in bestimmten Adressbereichen der Arbeitsspeicher angesprochen wurde oder halt nicht (wenn dann eine Karte im System verfügbar war, welche an der Stelle angesprochen wurde, war diese sichtbar. Dies kann z.B. in Bezug auf Erweiterungskarten ein mitgebrachter ROM sein oder aber wie am Beispiel Grafikkarte: RAM). Der POST Prozess in BIOS hatte dann mit Hilfe des Chipsatzes u.a. diese BIOS Shadowing angeboten. D.h. ausblenden des Arbeitsspeichers in einem Bereich, kopieren des Inhaltes des Bereiches in einen anderen Bereich (wo noch der Arbeitsspeicher eingeblendet ist), dann ausblenden ROM, einblenden RAM und wieder zurück kopieren. Danach wurde über Register der Chipsätze der RAM Bereich entsprechend als nur lesen markiert und der Chipsatz hatte bei schreibenden Zugriffen auf die Adressräume einfach kein CS Signale generiert. > Aber bevor es abschweift: > Ich brauche direkt am RAM (Wenn man es sich als Erweiterungskarte > vorstellt) nur die Signale: > > A0...A19 > D0...D15 > RD > WR > BHE Das M/IO Signal solltest du mit beachten, damit sich dein RAM nicht bei IO Zugriffen mit anbietet. Ansonsten sehe ich nur das Problem mit doppelten Adressräumen wie z.b. bei den Grafikkarten. Wenn deine "RAM Karte" diese Bereiche nicht ausblenden kann, dann würden sich zwei Speicher angesprochen fühlen: deine RAM Karte und anderer Speicher auf den IO Karten. Bei dem Graka vllt. weniger das Problem, weil rein theoretisch würden beide RAMs an der Stelle den gleichen Inhalt bekommen. Auch das zurücklesen wäre nicht das Problem. Viel eher bei den ROMs: man könnte deine RAM Karte in einem ROM Bereich einer anderen Karte beschreiben können und somit verändern. Damit wäre beim Auslesen fraglich, welches am Bus anliegende Datenmuster nun gewinnt und von der CPU erkannt wird (wenn nicht sogar eine Mischung aus beidem, bzw. Veroderung). Oder vielleicht sehe ich hier auch nur ein Problem wo keins ist. Andere Mitleser sind gerne dazu aufgerufen sich hier zu beteiligen. Ich habe selbst nie für ISA oder ähnlichem entwickelt. Es kann auch nonsens sein. Grüße, Muetze1
lang, lang ists her ;) wenn ich mich richtig erinnere ist BHE einfach das AO für die oberen Datenbytes und das muss mit nichts verknüpft werden.
Und bei einem 8086 kommt BHE dadurch nicht zum Zuge beim RAM Zugriff und kann ignoriert werden. Bei einem 8088 mit einem 8 Bit Datenbus war BHE wichtig und hatte wie schon genannt angegeben, ob man nun D0-D7 oder D8-D15 auf dem Datenbus sieht/auflegen muss. Richtig?
Angehängte Dateien:
-
Maximum_mode_8086.jpg
38 KB
BHE ist aber lt. Datenblatt mit verknüppert. (Das ist aus dem Datenblatt kopiert...mit GIF und PNG wirds nur größer, aber nicht unbedingt besser...bevor Bildformate ins Spiel kommen. Das ist im Orginal auch schon so schlecht. ;) ) Das Problem, das eine Erweiterungskarte seinen ROM im Bereich des RAMs hat, muss es doch schon früher gegeben haben. Die "Urväter" des PCs müssen das doch auch irgendwie vorgesehen haben. Die Schemata in den Datenblättern sind ja ganz nett, aber wenn es an die Substanz geht wirds schwammig. Hilfreich wäre eine komplette(!) Memory Map...also wo was an welcher Adresse liegt. Dann könnte man ganz einfach diese Bereiche per PROM-Dekodierlogik ausblenden.
...was mir eingefallen ist:
(Ich fasse mal alles zusammen, auch schon bekanntes)
00000 bis 9FFFF RAM-Karte (640kB) <-direkt auf RAM-Karte über
Adressdekoder
A0000 bis AFFFF Monochrome Adapter (64k) <-befindet sich nicht auf der
B0000 bis BFFFF Color Adapter (64k) RAM-Karte
[...] <- noch zu ergänzen
F0000 bis FFFFF Boot Location <- FFFFF0 jmp F0000h
F00000 BIOS09
=> Speicher ist in 64k Segmente unterteilt (A16...A19) = 16* 64kB =1MB
=> Die unteren 16Bit der Adresse interessieren nicht
=> Dekodierlogik betrifft nur A16...A19
A19 A18 A17 A16
0 0 0 0 RAM Segment 0
0 0 0 1 RAM Segment 1
[...]
1 0 0 0 RAM Segment 14
1 0 0 1 RAM Segment 15
1 0 1 0 monochrome
1 0 1 1 color
[...]
1 1 1 1 BIOS
Sowas sollte man über einen PAL/GAL dekodieren können und einen
Schreibschutz realisieren können.
Thomas K. schrieb: > Und bei einem 8086 kommt BHE dadurch nicht zum Zuge beim RAM Zugriff und > kann ignoriert werden. Nur wenn man in allen Programmen konsequent darauf verzichtest, byteweise in den Speicher zu schreiben. ;-) > Bei einem 8088 mit einem 8 Bit Datenbus war BHE > wichtig und hatte wie schon genannt angegeben, ob man nun D0-D7 oder > D8-D15 auf dem Datenbus sieht/auflegen muss. Richtig? Beim 8088 gab es weder BHE noch D8-15.
Mirko Barthel schrieb: > Das Problem, das eine Erweiterungskarte seinen ROM im Bereich des RAMs > hat, muss es doch schon früher gegeben haben. Gab es. Die entsprechenden Vorkehrungen waren die Ursache für den berühmten (angeblichen) Satz, "640KB seinen genug für jeden", denn exakt hinter diesen 640KB begann der Adressraum, der für I/O und Grafikadapter reserviert war. Weshalb eben nur 640KB RAM nutzbar waren. 0xA0000-0xBFFFF: Videospeicher der Grafikdapter. 0xC0000-0xDFFFF: u.A. BIOS-ROMs auf Slotkarten, inkl. Video-BIOS. 0xE0000-0xFFFFF: Rechner-BIOS.
...Wieso jetzt plötzlich Maximum Mode (Schaltplantitel) wenn eben noch von M/IO die Rede war...
Nimm doch nen CPLD und mach die Latches, Tristates und Busdecoder alle dort rein. Spart Leitungen da 8086 und CPLD als einziges mit einander Verbunden sind und im CPLD dann Multiplexer usw. drin sind. Dann hat man auch weniger probleme die unterschiedlichen Bauteile mit unterschiedlichen Timings alle auf einen Datenbus zu hängen. Schon mal die internen Datenbus und Adressbus Treiber angeguckt ? Die Latches und Tristate Treiber haben normalerweise schon ihren Sinn (Leitungskapazität usw.) Zusätzlich kann man dann noch Timer, IO-System und vieleicht sogar noch nen rudimentären DMA-Controller implementieren (aber nur wenn man Zeit und Lust hat).
Mirko Barthel schrieb: > Ich stehe momentan total auf dem Schlauch. Ich möchte 2 628512 (512kB > SRAM) an einen 8086 anschließen. Leider finde ich im INet keine .... Ram Prozessor > [A1...A19] -> [A0...A18] > [D0...D7] -> [D0...D7] IC1 lower Byte > [D0...D7} -> [D8...D15] IC2 upper Byte Soweit ok. Da der Prozessor mit einem 8288(Stichwort Minimum-, Maximum-Modus)verwendet werden soll, hier eine kurze Begriffsbestimmung: - Der Maximum-Modus ist für Multiprozessoranwendungen(-> multiple !externe!Busmaster) gedacht, wobei das vom 8288 generierte !LOCK-Signal und der !TEST-Eingang des 8086 eine besondere Rolle spielt. Speziell im (frühen)PC wurde der Maximum-Modus angewendet, um die einwandfreie Kommunikation mit dem 8087 zu gewährleisten, da hierfür die Auswertung des Zustandes der Befehlswarteschlange(Instruction-Queue)der 8086-CPU notwendig ist (Steuersignale !RQ/!GT0, QS0, QS1 des 8288). - Im Minimum-Modus existiert diese Multimasterfähigkeit nicht, der "transparente" Betrieb eines 8087 ist nicht möglich -> einfaches System. Beiden Konfigurationen ist gemeinsam, dass sie 1MB lokalen Speicher und 64kB lokalen IO-Raum adressieren können, lokale Busmaster (DMA-, Video-, Interrupt-Kontroller) können am Systembus betrieben werden. Zurück zur Frage. In der Intel-16Bit-Architektur wählt beim Schreibzugriff A0(machmal auch als BLE bezeichnet) das gerade Byte, BHE das ungerade Byte aus, beim Lesezugriff sind beide Signale aktiv, das unerwünschte Byte wird ignoriert. Wohin diese Zugriffe gehen (Mem oder IO), wird im Minimum-Modus durch das Signal M/IO der CPU festgelegt, im Maximum-Modus bestimmt der 8288 die Richtung. Bei Einsatz von 2x500k Ram sind daher folgende Verknüpfungen der Signale zum Ansprechen des Speichers denkbar: Im Minimum-Modus CSO=!(MEM/IO)&A0;CSE=!(MEM/IO)&BHE;WR,RD parallel an die entsprechenden Pins beider Ram. Im Maximum-Modus CSO=A0;CSE=BHE;MRDC(Speicher lesen),MWTC(Speicher schreiben) parallel an die entsprechenden Pins beider Ram. Falls die weiter oben erwähnten Zuordnungen im Speicheradressraum realisiert(zB.Laden des Bios durch externen Prozessor, eine gelinde gesagt exotische Idee)werden sollen, sind natürlich umfangreichere Auswahlschaltungen notwendig. Wie weiter oben schon festgestellt wurde, sind Informationen zum Aufbau von Systemen mit der 8086-CPU nur spärlich verfügbar. Für alle Interessierten daher noch einige Literaturstellen, in denen !kleine! Systeme beschrieben werden, keine PCs. - G.Schmitt,Mikrocomputertechnik mit 8086-Prozessoren,Oldenbourg 1994,3.Auflage: Umfangreiche Hard- und Softwarebeschreibungen einfacher 8088/8086-Systeme - H.-P.Messmer,PC Hardware,Addison-Wesley 1997,5.Auflage:streift ua. kurz die 8086-CPU und deren Standartperipherie - F.Majewski,Der EMUF86,MC Nr10 1987 oder MC Sonderheft Nr247:Schaltplan und Beschreibung eines 8086-Minimum-Systems
In Circuit Cellar wurde sogar mal ein kompletter Bauplan für ein AT-System(!!) veröffentlicht. Sicherlich findet sich da noch mehr. Und in der Elektor gab es mal einen Schachcomputer auf 8086-Basis. Was das ursprüngliche Projekt angeht: Steht bei mir auch auf der Liste sowas, aber das wird erstmal Minimum Mode und das ROM kommt brav ganz oben in den Addressraum (da wo der Resetvektor landet), dann gibt es eben nur 512KB RAM :)
G. O. schrieb: > realisiert(zB.Laden des Bios durch externen Prozessor, eine gelinde > gesagt exotische Idee) Wenn man sich heutzutage ein bewusst archaisches System aufbaut, aber nicht auch den ebenso archaischen Prozess des EPROM-brennens, löschens, brennens, ... gehen will, dann ist das sogar ziemlich naheliegend. Ausserdem ist diese Methode ebenfalls steinalt. Mainframes und grosse Minicomputer wurden recht oft auf genau diese Weise gestartet. Neu ist hier nur, dass der Steuerrechner einige Jahrzehnte jünger ist als der Hauptrechner. Früher wars umgekehrt, der Steuerrechner war nicht selten ein kleines Vorgängermodell. Auch in Intels Sandy Bridge Prozessoren läuft zunächst einmal der interne Mikrocontroller los (PCU = Power Control Unit), der dann den Rest initialisiert und den ersten Core anwirft.
Den kompletten Bauplan des IBM PC/XT findet man im Netz. Mit Prozessor- und Signalbeschreibung, Schaltplänen auch von Adaptern etc - das waren noch Zeiten, als man Dokumentation ernst nahm: http://www.retroarchive.org/dos/docs/ibm5160techref.pdf
A. K. schrieb: > ...aber nicht auch den ebenso archaischen Prozess des EPROM-brennens, > löschens, brennens,... Die armen Kerle haben sich spätestens nach dem zehnten Fehler aufgehängt. > Ausserdem ist diese Methode ebenfalls steinalt. Mainframes und grosse > Minicomputer wurden recht oft auf genau diese Weise gestartet. Klar -nur- hier wurden und werden funktionierende Programme übertragen. Ich behaupte ja nicht, dass es unmöglich ist, sondern in der zur Diskussion stehenden Konfiguration stelle ich mir die Programmentwicklung, die ja wohl notwendig sein wird, schon auf der Hardwareseite ziemlich kompliziert vor. > Den kompletten Bauplan des IBM PC/XT findet man im Netz. Kann möglicherweise als Anregung dienen, doch das Schaltbild ist derartig umfangreich, dass man Gefahr läuft, den Wald vor lauter Bäumen nicht zu sehen.
G. O. schrieb: > Ich behaupte ja nicht, dass es unmöglich ist, sondern in der zur > Diskussion stehenden Konfiguration stelle ich mir die > Programmentwicklung, die ja wohl notwendig sein wird, schon auf der > Hardwareseite ziemlich kompliziert vor. Das Hauptproblem besteht darin, den Bus freizukriegen. Mit Reset ist das möglicherweise nicht getan, da Adress- und Steuersignale dabei aktiv sein könnten. Mit "not Ready" ist das natürlich auch nicht getan. Der HOLD-State ist der bessere Weg. Ansatz: Die relevante Hälfte vom Datenbus mit schwachen Pullup/downs auf einen HLT Befehl legen und die RAMs durch den AVR abschaltbar machen (HLT=F4, also 5 AVR-interne Pullups und 3 externe Pulldowns). Dann läuft der 86er ab Reset sofort auf diesen HLT und der AVR hat alle Zeit der Welt, den Bus per HOLD an sich zu ziehen um den Speicher zu füllen, indem die Busleitungen per Bitbanging bedient werden. Mit dem nächsten Reset, diesmal mit eingeschalteten RAMs, ist das Thema durch. Pins dafür hat der Mega64 genug, als Zusatzlogik wird nur das "disable RAM" benötigt. PS: Ich gehe hier von einem Minimalsystem ohne Bustreiber aus. Bei PC-artigem Maximalausbau geht natürlich auch die Reset-Version.
Hier kommen ja richtige gute Ansätze. Auf der CPU-Seite sieht es bisher wie folgt aus: ein XC9572 generiert die Clocksignale (8284) und stellt den Buscontroller (8288). An dem sind noch genug I/Os frei. Alles was hier generiert wird, geht auf einen Leiterplattenverbinder. Momentan ist der Datenbus, Adressbuss und Steuersignale vorgesehen. Interrupts sind Platzhalter...da habe ich noch keine richige Idee...wahrscheinlich wird es noch ein XC9572 werden. Grundidee war, alles auf die kleinste Funktionseinheit herunterzubrechen um nicht die Komplexität der "Kuchenbleche" zu haben... Außerdem lassen sich Europlatinen zur Not noch selber ätzen. (Allerdings nach der Natriumpersulfat Disskussion wahrscheinlich doch nicht mehr) Erstmal CPU und RAM zum Laufen bringen: Der Rest ist nur noch Software. ;) Geplanter Ablauf booten: 1. System wird eingeschalten oder Hard-Reset 2. AVR meldet an CPLD -> "RAM_not_ready" (via Pull-up immer not_ready) 3. CPLD hält Resetleitung des 8086 auf low 4. Der AVR hat jede Menge Zeit aus dem SPI-EEPROM das Bios in den SRAM zu kopieren. 5. Wenn fertig, alle Leitungen des AVR auf Tristate (bis auf Steuersignale) 6. AVR zieht "RAM_not_ready" auf low -> CLPD gibt Reset frei und 8086 kann starten Im Debug-Modus ist folgendes vorgesehen: 1. AVR Signalisiert dem CPLD den "Debug"-Wunsch ("1") 2. CPLD zieht "HOLD" auf "1" -> CPU beendet aktuellen Zyklus und gibt Bus frei 3. CPLD gibt "HLDA" con CPU an AVR weiter ("1"=Busfreigabe) CPLD erzeugt zusätzlich das "LOCK" Signal für ext. Peripherie 4. Speicher kann ausgelesen, bearbeitet und beschrieben werden 5. AVR setzt Dubug zurück ("0") -> CPLD gibt HOLD frei ("0") 6. CPU macht da weiter, wo sie aufgehört hat. Alles was mit dem 8087 und den Arbiter(8289) zusammenhängt, lasse ich weg. Ich hoffe mir da keinen Weg zu verbauen, aber der 8289 brauche ich nur bei Muliprozessorsystemen?
Mirko Barthel schrieb: > 4. Der AVR hat jede Menge Zeit aus dem SPI-EEPROM das Bios in den SRAM > zu kopieren. D.h. du hast Bustreiber an den Adress/Steuerleitungen vorgesehen oder trennst die Busse per CPLD? Jedenfalls treibst du einen beachtlich hohen Aufwand für ein einfaches 8086-System. Oder soll das dein neuer PC werden? ;-) Wie soll die Gesamtkomplexität denn aussehen? Wenns nur darum geht, einen 8086 mit Speicher und einigen I/O-Bausteinen zu verbinden, dann ist der ganze Zirkus mit maximum mode überflüssig und der Kern der Lösung schrumpft ein auf den 8086, 2 Adresslatches, das RAM, Taktgenerierung, etwas Dekodierung und den AVR. > Buscontroller (8288). Wenn du mit dem CPLD Äquivalent des 8288 arbeiten willst, dann scheinst du den maximum mode im Auge zu haben ... > . CPLD zieht "HOLD" auf "1" -> CPU beendet aktuellen Zyklus und gibt ... in dem es die HOLD/HLDA Signale nicht gibt.
A. K. schrieb: > D.h. du hast Bustreiber an den Adress/Steuerleitungen vorgesehen oder > trennst die Busse per CPLD? Ok, selbst im minimum mode ist das bei A16-19 erforderlich... lang ists her. Die Latches braucht man also auch dafür.
ARGH! So ein Mist...ich sehe es auch gerade: Im Maximum-Mode sind auf den Pins RQ0 und RQ1 für die Verbindung zum 8087 und 8089. Da ich diese aber nicht vorgesehen habe, war bei mir immer Pin 30/31 HLDA und HALT. (Habe ich mal so gelesen und es hat sich festgesetzt und ich habe nicht mehr nachgesehen) Wie wäre es dann mit dem "Ready"-Signal? (Pin 22) CPLD generiert das "Ready"-Signal ("0") und die CPU führt Waitzyklen aus. CPLD trennt den Adressbus/Datenbus auf und der AVR kann ungestört werkeln. Ursprünglich ist das ganze aus der Idee entstanden: "So schwer kann ein 8086 System ja wohl nicht sein"..naja...offenbar ein kleiner Trugschluß. Ein (vorgefertigtes) 80286 Komplettsystem in einen FPGA laden kann ja (fast) jeder... ;)
Beim Minimum-System ist aber bei 64kB Schluß: Man hat nur 16 Adressleitungen. A16...A19 sind dann zusätzliche Steuerleitungen S3...S6
Mirko Barthel schrieb: > Ursprünglich ist das ganze aus der Idee entstanden: "So schwer kann ein > 8086 System ja wohl nicht sein Ist es auch nicht. Man sollte das Pferd nur nicht von hinten aufzäumen. Also vorneweg die grösstmögliche Lösung anpeilen und sich dann wundern dass die gross ist.
Mirko Barthel schrieb: > Beim Minimum-System ist aber bei 64kB Schluß: Man hat nur 16 > Adressleitungen. Nö, genauso 1MB. > A16...A19 sind dann zusätzliche Steuerleitungen S3...S6 Sowohl als auch. Grad wie bei AD0-15 sind auf diesen Pins A16-19 und S3-6 gemultiplext.
Mirko Barthel schrieb: > Beim Minimum-System ist aber bei 64kB Schluß: Man hat nur 16 > Adressleitungen. Voll daneben, s.o. > A16...A19 sind dann zusätzliche Steuerleitungen S3...S6 Auch falsch. Sx stellen den aktuellen Maschinenzustand bereit. Ich kann nur dringend das Studium der zitierten Literatur empfehlen.
"Die armen Kerle haben sich spätestens nach dem zehnten Fehler aufgehängt." Oder ein Monitorprogramm in das EPROM geladen (weiss jemand eigentlich ein wirklich gutes für 8086/8088 dass anpassbar genug ist um keine PC-Hardware zu erwarten?) und dieses über einen Host mit Code beschickt. Oder ein 28xx EEPROM genommen. Oder einen EPROM-Emulator verwendet. Oder nach dem XKCD-303-Prinzip gelebt.
PS warum eigentlich der 8086 (schwer zu beschaffen ausser Du hast zur richtigen Zeit ein Pollin-IC-Sortiment mit den Russen-8086 bestellt - ich leider nicht. Und mehr Leitungen zu verlegen.) und nicht für den Anfang ein 8088 oder 80188 (beide findet man weit häufiger - ersteren im PC-Schrott, zweiteren in etlichen alten Tintenpissern)?
A. K. schrieb: > Sowohl als auch. Grad wie bei AD0-15 sind auf diesen Pins A16-19 und > S3-6 gemultiplext. G. O. schrieb: > Auch falsch. Sx stellen den aktuellen Maschinenzustand bereit. > Ich kann nur dringend das Studium der zitierten Literatur empfehlen. Für die größtmögliche Kompatibilität sollte es der Maximum-Mode werden. Aus dem Grund habe ich den Minimum Mode nur überflogen, festgestellt dass A16-A19 anders ist und mit dem Maximum-Mode weitergemacht. Leider habe ich dann später doch noch was mit dem HOLD/HLDA Signal daneben gelegen... Als Datengrundlage benutze ich "Einführung in die 16-Bit-Mikrorechentechnik mit dem K1810 WM86" von Bäurich/Barthold sowie diverese Datenblätter. Leider nützt einem das Handbuch zum "IBM-PC" nicht sehr viel weiter, da es sich um einen 8088 handelt (8-Bit Datenbus) Andy D. schrieb: > Oder einen EPROM-Emulator verwendet. Grob gesagt ist die Spiegelung des ROM-Inhaltes im RAM ja so etwas. Andy D. schrieb: > PS warum eigentlich der 8086 (schwer zu beschaffen ausser Du hast zur > richtigen Zeit ein Pollin-IC-Sortiment mit den Russen-8086 bestellt - > ich leider nicht. Und mehr Leitungen zu verlegen.) und nicht für den > Anfang ein 8088 oder 80188 (beide findet man weit häufiger - ersteren im Eigentlich sind alle gleich schwer zu beschaffen. Geh mal auf den Wertstoffhof und versuch da mal was aus deren "Schätzen" zu ziehen. Zumindestens bei uns hoffnungslos... Ich habe von einem Forenteilnehmer 3 CPUs (1810) bekommen sowie (steht im Forum) einen Link zu einem russischen Versender. Da gibts das Ding für 61 cent. (Als ich damals geschaut habe) Allerdings sind die Versandkosten nicht ohne.
Mirko Barthel schrieb: > Für die größtmögliche Kompatibilität sollte es der Maximum-Mode werden. Kompatibilität mit was? Willst du am Ende doch noch einen 8087 dranhängen oder ein Mehrprozessor-Multibus-System aufbauen? Oder einen kompletten IBM-PC mitsamt 5MB MFM-Harddisk?
@mirkob Naja, aber Ebay und der Flohmarkt werden eher eine XT-Clone-oder Druckerleiche haben, und wenn man hier und da mal beim Kelleraufräumen hilft sieht es ebenso aus ; Einen 8086 (allerdings in SMD) könnte man aus einem Toshiba T1200 gewinnen, aber deswegen eine funktionstüchtige und evtl sogar selten gewordene Antiquität zu zerstören ist ein wenig stillos. Unerwartet selten angeboten werden inzwischen Quellen für den 386SX, der ebenfalls für solche SBCs interessant wäre. Einen 8087 zu bekommen könnte etwas schwieriger werden :)
Andy D. schrieb: > Oder ein Monitorprogramm in das EPROM geladen (weiss jemand eigentlich > ein wirklich gutes für 8086/8088 dass anpassbar genug ist um keine > PC-Hardware zu erwarten?) und dieses über einen Host mit Code beschickt. Ein Monitorprogramm arbeitet in der Umgebung, für die es geschrieben ist. Es ein Mißverständnis anzunehmen, dass eine 8086-CPU nur in einer PC-Hardwareumgebung vernünftig funktioniert. Offensichtlich ist hier der Pawlow-Effekt wirksam: 8086==PC-Hardware. Es ist kein Problem, den Prozessor mit, sagen wir, 1kB Ram,Eprom,Rom,Flash laufen zu lassen(alles eine Frage der Software). > Oder ein 28xx EEPROM genommen. Ich vermute mal, dass auch hier eine komplexe Hardware erforderlich ist. > Oder einen EPROM-Emulator verwendet. Genau. Wenn man sich keinen In-Circuit-Emulator von zB. Nohau leisten kann, greift man zu Eprom-Emulator. Neben einem moderaten Preis bietet ein Eprom-Simulator gegenüber einem In-Circuit-Emulator den Vorteil, dass das zu entwickelnde Programm in der Hardwareumgebung getestet wird, in der es später laufen soll. Schwächen in der Hardware, besonders bei höheren Taktfrequenzen(<=60MHz), kommen gnadenlos zum Vorschein, Softwarefehler sowieso. Mir ist kein Monitorprogramm im Netz bekannt, das speziell für den 8086 geschrieben ist. Einzig das Buch von G.Schmitt enthält ein Monitorprogramm, das auf die im Buch beschriebene Hardware zugeschnitten ist und das man abtippen, assemblieren usw. muß. Intel hat 1992 ? zusammen mit seinem Eval-Board für den 186/188 Schaltpläne und ein relativ einfaches Monitorprogramm unter der Bezeichnung EMON86 im Quelltext(Assembler) veröffentlicht. Um Größenordnungen anspruchsvoller ist das unter dem gleichen Namen veröffentlichte Monitorprogrammpacket(Assembler und C++) von AMD, das natürlich an die hauseigene Eval-Umgebung angepasst sein dürfte. > Einen 8086 (allerdings in SMD) könnte man aus einem Toshiba T1200... Warum immer nur einen 8086? Neben dem oben angeführten Clone aus Russland könnte man die V-Serie(hier V30 bzw upD70116) von NEC in Erwägung ziehen. Immerhin werden diese CPUs noch von zB Kessler angeboten.
Es war eher meine BEFÜRCHTUNG das alles was man so findet dann doch PC-orientiert ist. So etwas wie PAULMON für den 8086 wäre schon klasse, ich habs noch nicht gefunden :), und Google ist leider sehr viel verrauschter bei den Stichworten "8086 Monitor" als zb bei "8051 Monitor" ;) Eigentlich braucht so ein Programm ja nur wissen wo der Speicher und wo die UART ist (und welcher Typ UART). Theoretisch. ... Die 28xx EEPROMs sind steckkompatibel zu den 27xx EPROMs und seit Ewigkeiten verfügbar.
>Warum immer nur einen 8086?
Warum überhaupt eine spezielle CPU?
Man kann doch ein (Bus)System so gestalten, dass es weitgehend
unabhängig ist von einer spez CPU. Und viele MCUs haben Bus-IFs die
weitgehend anpassbar sind, bsp. mit mehreren Enables oder mehreren \CSs
für die D-Byte-Auswahl, auch mit asyn RDY-Signal.
Hmmm...bei 4 Steuerleitungen und deren Anschluß angefangen und nun bei Monitorprogrammen und Bussystemen angekommen. ;) Ein spezielles Bussystem habe ich nicht geplant. Da viele Sachen noch in der Schwebe sind, werden alle Signale hin und her geführt. ...und warum ausgerechnet PC-kompatible? Ich will Space Invaders, Lode Runner oder Digger auf (Fast-)Orginalhardware noch mal erleben... ;) (http://www.abandonia.com/en/game/all/sortby%3D1) Der Schrottplatz und Dosbox zählen nicht: Ist ein Feierabend-Projekt... Old-School-TTL...und man lernt (hoffentlich) was. (Und wenn es die Erkenntnis ist, das es doch nicht so einfach ist) Ich möchte keine VGA-Karte nachbauen (CGA reicht! ;)), keine MFM-Fetsplatte wiederbeleben, kein Diskettenlaufwerk... nur ein einfaches System, was aber grundsätzlich zum PC/XT kompatibel ist. (Der Flugsimulator wird wahrscheinlich nicht laufen: Der galt als Softwaretest für ein 100% kompatible BIOS... ;) ) ...so genug in Erinnerungen geschwelgt und zurück zum Thema: Ist es sinnvoll die Datenleitungen des RAM ebenfalls über Latches an den Datenbus zu hängen und wenn ja, über welche Signale wird der gesteuert? Für mich macht das keinen Sinn, da beim fehlen von MWTC\ und MRDC\ der RAM Tristate geschalten wird. Es gibt jeweils für I/O und Memory ein vorgezogenes Schreibsignal. Dient das nur zur Signalisierung, das die Peripherie in T2 vorbereiten kann, dass in T3 das Schreibsignal kommt? Wenn ich keinen Co-Prozessor oder Multiprozessor vorsehe, kann ich dann den Bus-Arbiter entallen lassen oder hat der noch (übersehene) andere Aufgaben? Erstmal CPU+RAM zum laufen bekommen. SIO/PIO, TIMER, Keyboard, Interrupt und DMA kommen dann in der Reihenfolge als nächstes. (Habe ich was wichtiges vergessen?) Achja...passt zwar nicht wirklich hier hin und ist auch noch nicht dran, aber kann man bei einen Xilinx XC95xx die Ausgänge Bedingungsabhängig (Verknüpfung intern) Tristate schalten? Und betrifft das immer alle Ausgänge?
Nur der Vollständigkeit halber: Wenn du wirklich einen PC kompatibel neu bauen willst ohne ihn nachzubauen, dann wird es mit dem 8086 aber doch deutlich komplizierter als mit dem ursprünglich verwendeten 8088. Denn du solltest du dir mal Gedanken darüber machen, wie man aus einem 16-Bit Zugriff der CPU zwei 8-Bit Zugriffe auf die Peripherie durchführt. Wenn also im Programm ein 16-Bit Befehl steht, die davon angesprochende Peripherie aber nur 8-Bit breit ist. Natürlich kann man dies wie auch die 8/16-Bit Aufteilung vom DMA prima mit CPLDs durchführen. Aber inwieweit CPLDs ok seien, FPGAs aber bäh, das erschliesst sich mit nicht so recht. Am Ende ist das einzige echte Retro-Teil da drauf die CPU.
Mirko Barthel schrieb: > Wenn ich keinen Co-Prozessor oder Multiprozessor vorsehe, kann ich dann > den Bus-Arbiter entallen lassen oder hat der noch (übersehene) andere > Aufgaben? Einen zum Original-PC leidlich kompatiblen Rechner zu bauen um Orignalsoftware verwenden zu können, ohne zumindest das Original genau genug zu kennen und verstanden zu haben, erscheint mir als eine ziemlich anspruchsvolle Aufgabe. ;-)
A. K. schrieb: > Nur der Vollständigkeit halber: Wenn du wirklich einen PC kompatibel neu > bauen willst ohne ihn nachzubauen, dann wird es mit dem 8086 aber doch > deutlich komplizierter als mit dem ursprünglich verwendeten 8088. Ich habe verzweifelt einen 8088 gesucht, aber nicht gefunden. Alles was Intel, NEC usw. ist, gibts als Orginal nur zu Mondpreisen. Durch den K1810 gibt es jedoch eine preisgünstige Alternative...aber das ist eben ein 8086. A. K. schrieb: > Natürlich kann man dies wie auch die 8/16-Bit Aufteilung vom DMA prima > mit CPLDs durchführen. Aber inwieweit CPLDs ok seien, FPGAs aber bäh, > das erschliesst sich mit nicht so recht. Am Ende ist das einzige echte > Retro-Teil da drauf die CPU. Problem ist, dass die Beschaffbarkeit der IC`s (Buscontroller, Clock, ect.) ebenfalls sehr schlecht aussieht und der Innenaufbau sehr überschaubar ist, habe ich mich für den XC95xx entschieden, da dieser noch 5V tauglich ist. Kosten bei Angelika 5,55 (9572 in PC44) FPGA ist für mich noch kein Thema. Damit habe ich mich noch nicht auseinandergesetzt. (Bis auf das Projekt, wo ein kompletter 286 in einem läuft) A. K. schrieb: > Einen zum Original-PC leidlich kompatiblen Rechner zu bauen um > Orignalsoftware verwenden zu können, ohne zumindest das Original genau > genug zu kennen und verstanden zu haben, erscheint mir als eine ziemlich > anspruchsvolle Aufgabe. ;-) Man wächst mit seinen Aufgaben.... ;)
Mirko Barthel schrieb: > Ich habe verzweifelt einen 8088 gesucht, aber nicht gefunden. > Alles was Intel, NEC usw. ist, gibts als Orginal nur zu Mondpreisen. > Durch den K1810 gibt es jedoch eine preisgünstige Alternative...aber das > ist eben ein 8086. Den 80C88 - die CMOS Version vom 8088 - kriegt man bei ebay. Auch den 80C188 kriegt man dort - und hat dann den Taktgenerator gleich mit an Bord. Manches aus der 80Cxx/82Cxx Familie ist ausserdem bei Digikey oder Farnell gelistet.
Den V20, NECs pin- und funktionskomptibles Äquivalent zum 80C88, kriegt man ausserdem bei Darisus (UPD70108C). Damit kannst du dann auch noch CP/M-Spiele laufen lassen, denn anders als Intels 8088 kann der sogar 8080-Code ausführen.
Angehängte Dateien:
-
vor_r_ck1.png
260 KB
A. K. schrieb: > Mirko Barthel schrieb: > >> Wenn ich keinen Co-Prozessor oder Multiprozessor vorsehe, kann ich dann >> den Bus-Arbiter entallen lassen oder hat der noch (übersehene) andere >> Aufgaben? > > Einen zum Original-PC leidlich kompatiblen Rechner zu bauen um > Orignalsoftware verwenden zu können, ohne zumindest das Original genau > genug zu kennen und verstanden zu haben, erscheint mir als eine ziemlich > anspruchsvolle Aufgabe. ;-) Kann ich nur bestätigen. Ich hab'mal meinen allerersten Versuch, ca 1992, mit einem '88-Prozessor ausgegraben, 64k Ram und 64k Eprom(emulator). Der Prozessor, Taktgenerator, Intecontroller und serielle Schnittstelle stammen aus meinem XT(2x360k Diskettenlaufwerk, keine Festplatte), den ich damals durch einen '386 ersetzt hatte. Eine Besonderheit ist, dass ich, mangels ausreichender Kenntnisse, die ersten 5 Byte des Resetvektors in einem der auf dem Foto abgebildeldeten GAL abgelegt hatte, so dass der Prozessor wenigstens den ersten Sprungbefehl korrekt ausführen konnte.
Hi In der Zeitschrift Funkamateur gab es 1989 oder 1990 mal einen mehrteiligen Artikel zum Aufbau eines XT-Rechners. Ist aber leider nicht im Archiv der Zeitschrift enthalten. MfG Spess
A. K. schrieb: > Den V20, NECs pin- und funktionskomptibles Äquivalent zum 80C88, kriegt > man ausserdem bei Darisus (UPD70108C). Damit kannst du dann auch noch > CP/M-Spiele laufen lassen, denn anders als Intels 8088 kann der sogar > 8080-Code ausführen. Danke für den Tipp! Aber der V20 ist aber "nur" ein 8088. Und damit würde sich nur der Datenbus von 16 auf 8 verkleinern. Einen 8086 habe ich schon hier liegen. G. O. schrieb: > Kann ich nur bestätigen. > Ich hab'mal meinen allerersten Versuch, ca 1992, mit einem '88-Prozessor > ausgegraben, 64k Ram und 64k Eprom(emulator). Der Prozessor, > Taktgenerator, Intecontroller und serielle Schnittstelle stammen aus > meinem XT(2x360k Diskettenlaufwerk, keine Festplatte), den ich damals > durch einen '386 ersetzt hatte. ...und das ganze auf einer Lochraster/Lötstreifenplatine! Ich glaube, dass ich die Geduld nicht hätte. Spätestens wenn die ersten Fehler beim verdrahten entstehen und vom vielen ab- und anlöten die ersten Lötpads abfallen, vergeht mir die Lust. ;) Aber Hut ab...das beweist also, dass es doch geht! Es sieht sehr kompakt aus und man erkennt kaum etwas auf den IC`s (Bildformate! ;) )...sind das SRAMS? wenn nicht, wie wurde der Refresh gelöst? spess53 schrieb: > In der Zeitschrift Funkamateur gab es 1989 oder 1990 mal einen > mehrteiligen Artikel zum Aufbau eines XT-Rechners. Ist aber leider nicht > im Archiv der Zeitschrift enthalten. Ich benutze als weitere Quelle die c`t: Hier ist ab 01/84 der Aufbau des c`t86 beschrieben. Und das ganze auf Euro-Platinen! Die CPU-Karte habe ich fast 1:1 übernommen...Viel ist ja nicht drauf. Von dort aus geht es dann auf den ECB-Bus, welchen ich aber nicht genommen habe... Ich habe meine eigene Pfostensteckerbelegung: Alle schon durchnummeriert und übersichtlich geordnet. ;) Beim 2. Schaltplan geht es dann vom ECB-Bus auf die RAM-Karte...allerdings DRAM. Die Sache mit dem Refresh will ich mir sparen und SRAM nehmen. Und da ist die Idee gekommen, den EPROM (brennen, einbauen, testen, rausnehmen, löschen und von vorn) im SRAM zu spiegeln. Weiter hinten sind dann auch noch PIO/SIO und in folgenden Ausgaben das Floppy-Interface beschrieben. Leider ist der Schaltplan schwer zu entziffern bzw. zu lesen. Es ist schwer, über mehrere Seiten Signale zu verfolgen: Es ist nicht das Signal, z.B. D0, angegeben, sondern nur die Position auf dem ECB-Bus. (C/2). Ich will aber nicht meckern...ist halt nur sehr mühseelig das ganze rauszusuchen.
Mirko Barthel schrieb: > Einen 8086 habe ich schon hier liegen. Angesichts des Gesamtaufwands ist das wohl kaum ein Argument. > ...und das ganze auf einer Lochraster/Lötstreifenplatine! Ich glaube, > dass ich die Geduld nicht hätte. Öha... So ein Projekt und keine Geduld? Lötpunktraster kann man übrigens ziemlich problemlos anpassen und signifikant umbauen. Bei Geätztem ist das umständlicher. > Ich benutze als weitere Quelle die c`t: Hier ist ab 01/84 der Aufbau des > c`t86 beschrieben. Willst du einen CP/M-86 Rechner bauen, oder einen auf dem deine MSDOS-Spiele laufen? Meiner vagen Erinnerung nach war der c't86 nicht zum PC kompatibel. Schon ulkig. Du willst einen Retro-Rechner für alte PC-Spiele bauen, die bekanntlich voll auf die Hardware des PCs abgestimmt sind, und die einzige wirklich relevante Informationsquelle dafür scheinst du nicht mal mit der Zange anfassen zu wollen. Statt dessen suchst du dir Informationsquellen, deren Bezug zum PC sich auch die gleiche Prozessorarchitektur beschränkt.
A. K. schrieb: >> ...und das ganze auf einer Lochraster/Lötstreifenplatine! Ich glaube, >> dass ich die Geduld nicht hätte. > > Öha... So ein Projekt und keine Geduld? > > Lötpunktraster kann man übrigens ziemlich problemlos anpassen und > signifikant umbauen. Bei Geätztem ist das umständlicher. Ich muss mich hinsetzen und einen mir Schaltplan überlegen und zu Papier bringen. In dem Zug überlege ich lieber 5...nagut bei mir 10 Minuten länger und überprüfe ob das stimmig ist. Da ich aber schon so vorschrittlich bin und EDV benutze, kann ich daraus auch ein Layout ableiten. Einen umgedrehten SMD IC mit Lackdraht aufs Lochraster zu fädeln...ne, dass muss nicht sein. A. K. schrieb: > Willst du einen CP/M-86 Rechner bauen, oder einen auf dem deine > MSDOS-Spiele laufen? Meiner vagen Erinnerung nach war der c't86 nicht > zum PC kompatibel. Im Artikel steht drin, dass ein "Hauptteil der IBM-XT Interrupts" vom BIOS unterstützt werden. Erster sichtbarer Grund ist, dass es nur einen Interruptcontroller (8259) gibt. Ansonsten ist die Hardware der CPU-Karte genau wie alle im Netz verfügbaren Schemata aufgebaut: 8086 8087 8284 Clock 8288 Bus Controller 8259 Interrupt 74LS374 Datenbus 74LS245 Adressbuss [ECB] 74LS244 Adressbuss (+245 vor EPROM) EPROM mit BIOS/Monitorprogramm sowie einige Logikgatter... Ich habe bei mir im Schaltplan 2 8259 vorgesehen, ansonsten sieht die CPU-Karte genauso aus... Zum BIOS: Es gibt ein "Generic XT-BIOS" welches ich als Grundlage nehmen will. Welche "einzige wirklich relevante Informationsquelle" meinst Du? Das PC-Handbuch von IBM? Das war der Ausgangspunkt...bis ich dann den 8086 hatte und einen XT planen musste... ;) Apropos: (Its aber ein 8088) http://www.youtube.com/watch?v=qCj2deCFMnc Hier gibts die Seite dazu: http://ve2cuy.wordpress.com/
Mit kompatiblen Interrupts allein kannst du nur Programme ausführen, die sich ausschliesslich auf BIOS und MSDOS Funktionen verlassen. Spiele jedoch gingen damals in zeitkritischen Funktionen direkt an die Hardware.
Mirko Barthel schrieb: > Erster sichtbarer Grund ist, dass es nur einen > Interruptcontroller (8259) gibt. Ach? Das der PC/XT nur auch nur einen Interrupt Controller drin hatte scheint dir bei aller intensiven Vorbereitung entgangen zu sein. Den zweiten brachte erst der AT. Ähnliche Thematik: Oben erwähnst du DMA. Für welche Funktionalität verwendet der PC denn eigentlich DMA?
Ich würde gleich einen 386EX nehmen, der hat nämlich Timer, IRQ Controller, DMA, 2 UARTs, Chip Select Unit, also fast die komplette PC Hardware, schon integriert. Ausserdem hat er ein "Glueless" Interface, SRAM oder Flash lässt sich direkt anschließen. Ausserdem hat er noch 3 8-bit I/O Ports und ein SSI. Mit dem entsprechenden BIOS kann man ohne größeren Aufwand ein embedded DOS drauf laufen lassen. Die Dinger wurden z.B. in JetDirect Printservern verbaut, sollten also noch gut zu finden sein.
>Ich würde gleich einen 386EX nehmen,
Oder welche von AMD, mit sehr hoher Integration.
(X86-Chips mit Integration, also uCs, sind eigentlich immer
PC-orientiert)
Mir kommt das ganze aber etwas komisch vor.
Der TO will scheinbar einen Rechner mit X86 bauen, der nicht zu 100%
PC-kompatibel sein braucht, gleichzeitig möchte er alte DOS-Programme
ausführen, die ja gerade eine fast 100% PC-Kompatibelität erfordern.
(XC95.. kann man in Tristate schalten, allerdings nicht über den
Haupt-PT-Pfad, geht bei Altera besser. Würde aber statt XC95.. XC95..XL
nehmen, da die auch 5V-tolerant und die XC95.. (mit 5V-UB) zu viel Strom
fressen und auch eine kleinere Eing-Matrix haben (..XL haben 90 davon)
und Xil. die auch fast nicht mehr produziert und desh der Preis extrem
teuer ist. (XC95..XL ist für nä 3..4 Jahre auch schon abgekündigt) )
Mirko Barthel schrieb: > ...und das ganze auf einer Lochraster/Lötstreifenplatine! Ich glaube, > dass ich die Geduld nicht hätte. Spätestens wenn die ersten Fehler beim > verdrahten entstehen und vom vielen ab- und anlöten die ersten Lötpads > abfallen, vergeht mir die Lust. Alles eine Frage der Übung. Und was die Geduld angeht, es klingt nicht besonders cool, aber Geduld und hohe Leidensfähigkeit sind meiner Erfahrung nach die ersten Tugenden bei einem derartigen Unterfangen. ... > 8086 > 8087 > 8284 Clock > 8288 Bus Controller > 8259 Interrupt > 74LS374 Datenbus > 74LS245 Adressbuss > [ECB] > 74LS244 Adressbuss (+245 vor EPROM) > EPROM mit BIOS/Monitorprogramm > sowie einige Logikgatter... > Ich habe bei mir im Schaltplan 2 8259 vorgesehen, ansonsten sieht die > CPU-Karte genauso aus... Ich finde es sehr sportlich, vor allem wenn ich mir deine Fragen ansehe, ein solches Projekt mit einer Handvoll ICs statt mit einer Handvoll Bücher zu beginnen. Und was das zitierte Filmchen angeht, meiner Ansicht nach zeigt es genau in die Richtung, die man einschlagen sollte: Kleine überschaubare Module funktionsfähig machen und erst dann den großen Wurf hinlegen. Ich werde mal ein paar Fotos vorbereiten und posten, von denen ich denke, dass sie zum Thema gehören und die Wirksamkeit dieser Methode illustrieren.
>aber Geduld und hohe Leidensfähigkeit sind meiner >Erfahrung nach die ersten Tugenden bei einem derartigen Unterfangen. besonders weil es bei Lochraster/Lötstreifen-Platinen-Aufbauten tausende Möglichkeiten der Stör-Ein-Aus-Kopplung zwischen den "frei fliegenden" Leitungen gibt.
Was mit der Lochrasterplatine begonnen hatte, ist letztendlich in einen DOS-Rechner gemündet. Für den voll funktionsfähigen Rechner ist eine Europakarte ausreichend, alle anderen abgebildeten Leiterplatten erweitern lediglich das System. Der Clou dieses Entwurfs ist die Möglichkeit, Prozessoren mit 8Bit-oder 16Bit breitem Datenbus ohne (wesentliche) Hardwareänderungen einzusetzen. Das Umsetzen eines Jumpers genügt, um das System umzukonfigurieren. Das verwendete Betriebssystem ist ein (klein wenig angepasstes)RxDos, das Bios stammt vollständig aus eigener Feder. Natürlich soll noch die Gretchenfrage - wie steht`s mit der Kompatibilität zum PC?- beantwortet werden. Hardware - kommt auf den Standpunkt an. Alleine die abartige Zuordnung der ersten 12 Interruptvektoren der von mir eingesetzten CPU erschwert eine 1:1 Nachahmung der PC-Hardware ganz massiv (diese Abweichnung wird in erster Linie für den Mißerfolg des '186/'188 im PC-Bereich verantwortlich gemacht, ein anderer Umstand war sicherlich das schlechte Timing beim Erscheinen des Prozessors). Also, PC und dieses System haben die gleiche Ram-Ausstattung und die Hardwareprotokolle der Ein- und Ausgabegeräte sind beinahe gleich. Mehr Gemeinsamkeiten gibt es nicht. Software - durchwachsen. Da das verwendete Betriebssystem aus der PC-Welt stammt (wenn ich die mageren Quellen richtig verstanden habe, hat es Samsung kurzzeitig bei tragbaren? PCs verwendet. Auf einem PC stellt sich tatsächlich das gewohnte DOS-Feeling ein.), habe ich das Bios trotz der oben erwähnten Probleme soweit gebracht, das es die Anforderungen der Softwareschnittstelle des Betriebssystems zumindest erfüllt. Dieser Minimalismus hat seinen Preis. Wie zu erwarten laufen nur Programme, die ausschließlich im Real-Mode verbleiben, auf dem System. Dies können alte PC-Programme, die nur schlichte (über die Biosschnittstelle) Bildschirmausgaben durchführen, oder eben eigene Programme, deren Verhalten 100%tig bekannt ist, sein. Programme, die ein waschechtes MSDOS verlangen oder die zB die Interruptvektortabelle umorganisieren (eine Unart, die ich bei TurboC oder BC im Emulationsmodus erlebt habe), bringen eine Fehlermeldung und starten nicht oder lassen das System abstürzen. Als ich damals die Lochrasterplatine mit dem 8088 zum Laufen gebracht hatte, habe ich mich trotz der damals schon zu erahnenden Schwierigkeiten dafür entschieden, mit einem '186/'188 weiterzumachen. Das Handbuch war einfach erhältlich und auf den Servern von Intel und AMD waren und sind ausführliche Beispiele dokumentiert und es hat mich einfach gereitzt, einen DOS-kompatibelen Rechner nachzuempfinden.
Konnte erst jetzt antworten... ;) G. O. schrieb: > Und was das zitierte Filmchen angeht, meiner Ansicht nach zeigt es genau > in die Richtung, die man einschlagen sollte: Kleine überschaubare Module > funktionsfähig machen und erst dann den großen Wurf hinlegen. Wenn man mal den Thread von Anfang an sich ansieht, erkennt man, dass viele Sachen erst später gekommen sind. Meine Frage war einzig, ob die A0/BHE Erkennung bei beiden Modi (MR/MW) eine Rolle spielt. Das IBM-PC Handbuch schweigt sich natürlich aus (Ist ja ein 8088) und bei Intel sowie dem 1810-Buch wird nur vom Schreiben gesprochen. Beim lesen wird das unwichtige Byte verworfen. Beim c`t86 muss ich mal mit Farbe die Linien nachziehen um nachzuschauen... ;) Schaut man im INet exixtieren etliche Skripte aus Vorlesungen. Doch überall steht es etwas anders drin. Ich habe es jetzt mit in den CPLD gepackt: Da habe ich dann noch einige Freiheiten. Ich gehe jetzt doch auf die 3,3V (XL) Typen. Der 5V-Typ kostet fast das doppelte. Wenn die Platine funktioniert, mache ich weiter mit der nächsten. Schritt für Schritt. Wenn natürlich Fragen zu Sachen kommen, die in ferner Zukunft liegen, dann ist es klar, dass ich da ins Schleudern komme. G. O. schrieb: > Für den voll funktionsfähigen Rechner ist eine Europakarte ausreichend, > alle anderen abgebildeten Leiterplatten erweitern lediglich das System. > Der Clou dieses Entwurfs ist die Möglichkeit, Prozessoren mit 8Bit-oder > 16Bit breitem Datenbus ohne (wesentliche) Hardwareänderungen > einzusetzen. RAM, BIOS und CPU sitzen bei mir ebenfalls auf einer Europlatine. Die Hardware zum spiegeln des BIOS in den RAM + Schreibschutz nehmen in etwa den Platz weg, den bei Dir das BIOS belegt. Das Bussystem habe ich an die lange Seite gelegt, da ich alle Pins des 16-Bit ISA Busses später zur Verfügung haben will. (Auch wenn ich z.Z. nur den 8-Bit nutze). G. O. schrieb: > Hardware - kommt auf den Standpunkt an. Alleine die abartige Zuordnung > der ersten 12 Interruptvektoren der von mir eingesetzten CPU erschwert > eine 1:1 Nachahmung der PC-Hardware ganz massiv (diese Abweichnung wird > in erster Linie für den Mißerfolg des '186/'188 im PC-Bereich > verantwortlich gemacht, ein anderer Umstand war sicherlich das schlechte > Timing beim Erscheinen des Prozessors). Diese Information habe ich auch. Deswegen schrecke ich vor den Vorschlägen zurück, irgendwelche Druckserver auseinander zu nehmen. Bei den Embedded 386EX bin ich mir nämlich auch nicht sicher, ob der nicht auch Fallstricke hat. Deswegen das Orginal und der modulare Aufbau. (Achtung Glaskugel, Zukunft und ungeplant! Wenn es dann geht, will ich die CPU-Platine durch einen FPGA ersetzen und mich damit mal beschäftigen) Noch einige Fragen: Leider sieht man schlecht, welche Hardware Du für Tastatur, Laufwerksansteuerung (4MB), SIO/PIO benutzt hast. Sind das die orginalen IC`s oder etwas "selbst gestricktes". Auf der I/O Platine sehe ich einen PLCC(?) Sockel... Die anderen I`Cs könnten von der Größe her Orginale sein. Welche Grundidee lag der Grafikkarte zu Grunde? (Umgebaute ISA-Karte?)
Mirko Barthel schrieb: > Noch einige Fragen: > Leider sieht man schlecht, welche Hardware Du für Tastatur, > Laufwerksansteuerung (4MB), SIO/PIO benutzt hast. > Sind das die orginalen IC`s oder etwas "selbst gestricktes". Auf der I/O > Platine sehe ich einen PLCC(?) Sockel... Die anderen I`Cs könnten von > der Größe her Orginale sein. Ich kann Dir versichern, alle von mir seinerzeit verwendeten ICs sind Originale ;-). SIO/PIO ist ein 16C552, das Tastaturinterface ist ein sog."Keyboard-Bios", das ich aus Schrott-Platinen gepult habe. Das Flash-Laufwerk ist mit ICs von Winbond, die offensichtlich nicht mehr verfügbar sind, aufgebaut. Hier bieten sich zB bei Reichelt erhältliche SSD-Disks mit IDE-Interface als Alternative an. Die zugehörige Dokumentation ist ok. > Welche Grundidee lag der Grafikkarte zu Grunde? (Umgebaute ISA-Karte?) Natürlich keine ISA-Karte. Die Grundidee war, mit allgemein erhältlichen Bauteilen den Inhalt des Video-Bereichs, in dem Text abgelegt wird, darzustellen. Daher ist die Konstruktion auch nicht im eigentlichen Sinn grafikfähig. Am ehesten kommt sie einer Herkules-Karte nahe, allerdings mit VGA-Interface. Ich habe die Konstruktion in der Code-Sammlung veröffentlicht -> "vga-karte, fast diskret". Was die übrigen angeführten Prozessoren angeht, aus eigener Anschauung beim '386EX weiß ich: große CPU == große Probleme. Ein DOS, auch mit DPMI-Interface, nutzt den Prozessor nur zu einem Bruchteil aus und die Hardware für Linux oder Windows fitt zu machen ist nicht ohne. Falls es einen Normalsterblichen nach Boards dieser Leistungsklasse gelüsten sollte, führt der Weg zB zu Ebay. Dort werden ziemlich häufig(Stand Ende 2011) PC104-Komponenten(neu+gebraucht) für ca30-50Euro angeboten mit denen man sofort(hoffentlich) loslegen kann.
Eine IDE-Schnittstelle zu schaffen stelle ich mir schwieriger vor als den MFM-Controller zu emulieren und Sektoren/Spurenbasiert auf eine SD-Card zu schreiben. Ein "KB_BIOS" habe ich auch noch da...ein Problem weniger. Die VGA-Karte ist ja der Hammer! ...aber das zu machen ist noch etwas in der Ferne. Danke trotzdem für die vielen Informationen! 386er mit Sockel habe ich auch noch da. Sogar die ganzen IC`s ringsrum. Aber wie Du schon treffend bemerkt hast: "große CPU == große Probleme" Da sieht ein 8086 dagegen einfacher und überschaubarer aus.
Eine IDE Schnittstelle ist im Endeffekt ein vereinfachter ISA-Bus, und eine entsprechende Platte tut so als wär sie ein MFM (eigentlich ST506)-Controller mit angeschlossener Platte. Vorbild für den Controller war IIRC der WD1003. Und eine ST506-Schnittstelle zu bauen bedeutet sicherlich mehr Aufwand, u.a. weil auf dieser die Kopfsignale zwar konditioniert aber im Grunde genommen analog geführt werden, und Du dich um eine ganze Menge Zeug (physikalisches Format, Ausmappen defekter Sektoren...) selbst kümmern musst.
Mirko Barthel schrieb: > ...aber das zu machen ist noch etwas in der Ferne. Danke trotzdem für > die vielen Informationen Alles klar. Dann leg mal los und berichte mal. Viel Erfolg.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.