Hallo Leute, am besten spreche ich die Generation um und über 50 an, wo ich mich selbst auch befinde, die könnten es noch wissen. Und zwar plage ich mich gerade auf dem Steckbrett mit einigen alten 8048-ern in meinem Besitz, die zum Teil auch für heute noch brauchbare Eigenschaften haben, und ich sie mal für einfache Dinge und Spielereien verwenden will. Unter anderem der Siemens SAB80C382, Low Power mit nur 1mA Stromaufnahme und sogar variabler Betriebsspannung zwischen 2,5V und 6V, und CMOS und voll statisch, mit > 0 Hz taktbar. Das ist doch was! Sonst nichts besonderes. Den 8048 gibt es auch heute noch in Massenanwendungen wie Waschmaschine und PC-Tastatur, es war einer der meist produzierten µC mit 8 bit (Intel), und auch überhaupt einer der ersten vor über 35 Jahren. Mit dem TASM-Assembler gelangen mir schon vor dem Jahr 2000 einige Programme, Demos auf selbst gebauten Prototypen. Einen Hochsprachen-Compiler gibts wohl nicht, die Dinger haben nur eine Maximalcodegröße von 4kB, und die Grenze über 2kB auch nur mit Tricks. Die Mnemonics und Befehlssatz kenne ich vom neueren 8051. Sie sind aber dem 8051 gegenüber spartanisch und abgespeckt, im 8051 gewohnte bequeme Befehle gab es noch gar nicht. Leider kann ich den 8048-Code deswegen auch nicht mit einem 8051-Simulator simulieren. Ich fand den vor 20 Jahren veralteter als heute, deshalb meine Frage: Kennt jemand einen 8048-Simulator, den es für gängige PC gibt, oder auch für DOS unter dem Programm virtuelle DOS-Maschine DOSbox? Denn ich hänge irgendwo in einem neu erstellten Assemblercode fest, und finde keine Ursachen für Fehler da drin. Nach drei Tagen habe ich es bestimmt raus, aber vielleicht geht das hier schneller. Sonst biete ich die 30 Jahre alten Dinger der NASA an, die suchten auch schon mal 8085-Steine uralt aus Privatbesitzen, weil Hersteller keine mehr hatten. ;-)
Hatte früher mal einen von NOHAU. Weiß aber nicht, ob die sowas noch zum Download bereitstellen. Einen Simulator für den 8051 habe ich seinerzeit mal in Pascal (DOS) geschrieben. Für den 8051 & Derivate gibst aber nun freie wie Sand am Meer.
manuel1970 schrieb: > http://www.acebus.com/8048.htm Vielen Dank. Da steht zumindest was von Simulator drin, das werde ich mir anschauen. Michi schrieb: > Einen Simulator für den 8051 habe ich seinerzeit > mal in Pascal (DOS) geschrieben. Da hast du aber auch eine Stange Arbeit, und mußt jedes bit oder gar jeden Maschinenzyklus mit Vornamen kennen. > Für den 8051 & Derivate gibst aber nun > freie wie Sand am Meer. Von Otmar Feger & Co. habe ich so einen aus dem Jahr 1991. Der spielt unter DOSbox auf neuen Rechnern ausgezeichnet. Der ist aber vom irischen Hersteller Ashling Microsystems, wie auch der Assembler. Aber gute Produkte. Feger steht da aber immer im Copyright irgendwo mit drin. Ashling machte wohl auch im Auftrag die originalen Intel-Assembler. Es mag sein, daß die Keil-Demoversionen für ihren Compiler einen Simulator drin haben. C ist ja dort nur auf 2kB Maschinencode begrenzt, Assembler wohl nicht, weil den kaum einer hauptsächlich braucht. ;-) Aber 8048 haben die auch nicht oder nicht mehr. Die Jungs in einer alten Firma, wo ich mal war, entwickelten 1980 ihre µC-Programme für industrielle 8048-Anwendung auf einer Intel-Station namens Intellec. Das war eine schweineteuere Maschine so groß wie ein Schreibtisch, 12-Zoll-Monitor grün, Tastatur, mit 8 Zoll Schwabbeldisketten und vielleicht noch Lochstreifenstanzer und -leser, eine eigene Arbeitsstation. Einen PC gab es damals noch nicht, das dauerte noch 3 Jahre, bis der erste IBM-XT und DOS raus kamen.
Kannst ja den 8048 mit einem AVR simulieren, da passt das 48er Programm ins RAM. Musst nur drauf achten, dass er nicht zu schnell läuft. ICE für Arme. ;-)
A. K. schrieb: > ICE für Arme. ;-) Wie nett. ;-) Nein ich habe nur echte 8048. Dem 80C382 fielen 17 Befehle aus dem originalen 8048 weg, die aber nicht so wichtig sind, und ich nicht verwende, es kamen aber 5 neue hinzu, einschließlich HALT. Ein anderer einzelner Befehl bekam einen anderen Maschinencode, aber das alles habe ich schon in der Instruction-Tabelle für den TASM neu gemacht. Ich möchte einfach diese guten 80C382 verwenden, wovon ich eine neue unbenutzte IC-Stange voll habe.
>> http://www.acebus.com/8048.htm > Vielen Dank. Da steht zumindest was von Simulator drin, das werde ich > mir anschauen. Berichte mal, das hört sich interessant an.
Angehängte Dateien:
-
OKI_80C40.jpg
200 KB
Hallo, da das Thema Intel 8048 für einige noch interessant ist, kann ich noch max. 8 OKI 80C40, das CMOS Pedant des 8048, anbieten.
Uwe S. schrieb: > Hallo, > da das Thema Intel 8048 für einige noch interessant ist, kann ich noch > max. 8 OKI 80C40, das CMOS Pedant des 8048, anbieten. Der 80C40 ist mir unbekannt. Die CMOS-Pendants zum 8048 gab es aber unter anderen Bezeichnungen, z.B. 80C39 statt 8039, das ist nichts besonderes. Die habe ich hier auch. Der 80C382, mit dem ich gerade zu tun habe, ist auch CMOS, das Steckbrett auf einfachste Weise auch nur mit 4 Mignonzellen betrieben. 8041 und 8042 waren in allen IBM-kompatiblen AT-PC mal drinne, Slave-Prozessor und Tastaturcontroller, davon habe ich auch noch welche. Die sind augenscheinlich zu nichts zu gebrauchen, aber ich fand am Wochenende noch eine Internetseite eines Freaks, der ein externes EPROM anklemmte, und an 5 Portpins 5 LEDs blinken läßt. Der 8041 ist da in einem Test-Mode, aber wer sagt denn, daß man diesen Test-Mode nicht regulär betreiben kann, wenn er richtig arbeitet? Dieses exotische Teil braucht komischerweise noch nicht mal einen Adreß-/Datenmultiplexer wie den 74373 Latch am Low-Bus, wie sonst an den Intel-8-bit-µC üblich, Adressen und Daten sind direkt mit dem EPROM verbunden. Der kommt dieser Tage auch aufs Steckbrett.
manuel1970 schrieb: > http://www.acebus.com/8048.htm Vielen herzlichen Dank noch mal für den Hinweis auf dieses schöne Tool, es hat mir sehr weiter geholfen, und ich bekam bereits ein paar Fehler aus meinem Programm beseitigt. Unter DOSbox 0.74 auf Windows Vista läuft es ausgezeichnet. Der 8048 ist ja sehr spartanisch gegenüber dem 8051, da fehlen ein paar interessante Befehle, und Programme mit bedingten Sprungbefehlen funktionieren nicht über eine Pagegrenze von 256 Byte hinweg, weil beim Sprung einfach das Low-Adreßbyte im PC für den Sprung ausgetauscht wird. Beim 8051 hatte man diese diversen Mängel behoben. Man kann dort zwar auch nur in einem Page großen Block springen, aber der kann im Codespeicher liegen, wo er will. Der Codespeicher von 4kB ist in 16 Pages unterteilt. Liegt ein Codeblock mitten auf so einer Pagegrenze, und man hat dort bedingte Sprünge drin, vorwärts oder rückwärts, z.B. Jump if Carry set oder Jump if Zero, dann hat man Pech gehabt. Wenn der Assembler bei sowas keine Fehler meldet, hat man noch mehr Pech, und weiß gar nicht, was im Code passiert. Der macht dann, was er will. Ein anderes schräges Ding ist manuelle Bankselektion, denn der Codespeicher kann nur zwei separate 2k-Blöcke, die mit einem Befehl umgeschaltet werden müssen. Auch Tabellen muß man in einer Page anlegen, und die Pagegrenzen beachten. Bei mir sponn der Befehl MOVP A,@A, um einen Siebensegmentcode und die Werte für die Bausteinansteuerung aus einer Tabelle zu lesen. Der Zeiger auf die Daten lag knapp daneben, also neben den Tabellenwerten, das fand ich mit dem Simulator sehr gut. Man muß sein Programm also geschickt in Pages anlegen, und die Pagegrenzen mit ORG-Anweisungen abstecken. Mein Programm hatte nämlich an sich keine logischen Fehler, und dann werden nach Stunden Suche die Augen rechteckig! ;-) Nun ja, der 8048 war für kleine Steuerungen gedacht, so wie heute auch kleine PICs. Meine Frage hier hat sich also echt gelohnt.
Die 8041/42 wurden UPI genannt, Universal Peripheral Interface und haben ein Feature das ich heute bei Mikrocontrollern vermisse: Einer der Ports ist mit einer Busschnittstelle versehen, so dass man dort mit einem Strobesignal datein Einspeichern, oder aber aus einem Register mit entsprechenden Bussignalen von dort abgespeicherte Daten auslesen kann. Das Ganze natülich ohne Beteiligung der internen CPU, also kein Interrupt oder Sowas. Das entschärft bei manchen Sachen ziemlich deutlich das Zeitverhalten. Die Z80 PIO konnte z.B. auch derartige Sachen machen, ich kenne von früher her Mehrprozessorsysteme mit Z80, die durch eine PIO gekoppelt waren und die Handshakesignale den Transfer bewerkstelligten. Solche Möglichkeiten vermisse ich bei Mikrocontrollern... Gruß, Holm
Wilhelm Ferkes schrieb: > Programme mit bedingten Sprungbefehlen > funktionieren nicht über eine Pagegrenze von 256 Byte hinweg, weil beim > Sprung einfach das Low-Adreßbyte im PC für den Sprung ausgetauscht wird. Soweit ich mich erinnere, darf nicht mal eine normale Routine einfach die Pagegrenze überschreiten. Das hiess dann immer, Programm assemblieren und mal schauen, wie lang es pro Page sein darf. Immerhin haben die Jungs in den PC/AT/PS2 Keyboards es auch geschafft, ein N-Key Rollover einzubauen und teilweise Tastaturcontroller gebaut, die deutlich besser sind, als das, was heute so einige verzapfen. Offensichtlich mussten sie sich mit der IBM Kugelkopf messen lassen :-) Haben hier noch irgendwo ein paar 8748 (EPROM Version) - aber keinen Brenner mehr dafür.
Holm Tiffe schrieb: > Die 8041/42 wurden UPI genannt, Universal Peripheral Interface und haben > ein Feature das ich heute bei Mikrocontrollern vermisse: Einer der Ports > ist mit einer Busschnittstelle versehen, Exakt. Das sind Slave-Prozessoren, die vom Hauptprozessor bedient wurden. Immerhin entschied man sich damals für die Verwendung in allen IBM- und kompatiblen Rechnern, das ist schon gigantisch. Auf meinem PC legte ich vor drei Tagen mal einen Ordner "UPI8041" an, wo ich Infos sammele, und auch etwas mit Code experimentieren will. Im Grunde kann heute schon mal einer aufs Steckbrett, man braucht ja außer dem EPROM und Quarz weiter gar nichts. Bis vor einigen Tagen wußte ich gar nicht, daß man den 8041 auch alleine betreiben kann. Allerdings ist er gegenüber dem 8048 abgespeckt, hat glaube ich auch keinen externen Interrupt, vielleicht aber den Timer-Interrupt. In den letzten Tagen sammelte ich dazu mal Schaltungen und Infos aus dem Internet. Da sind auch Schaltungen bei, wie er sogar als Slave eines 8048 oder 8051 oder sonstwas verwendet werden kann. Man kann sich z.B. einen Tastaturcontroller oder Displaymultiplexer selbst bauen, oder einen I/O-Port. Sonst brauchte man für sowas ja spezielle Bausteine wie 8255 I/O oder 8279 Keyboard-Display-Interface. Ein Keyboard-Controller ist in einem der Datenblätter auch vollständig abgebildet. Vermutlich wurde sowas verwendet, wenn der ganze PC mit Tastatur und Bildschirm in einem Gehäuse unter gebracht waren, solche Kisten gab es ja in den 1980-ern. Ich glaube, die Dinger hießen Terminal. Ein 8048 ist aktuell als Keyboard-Controller in meiner vorletzten PC-Tastatur aus dem Jahr 2001. Da habe ich etwas gestaunt, wie gut man sparen kann. In der 10 Jahre älteren Tastatur davor war nämlich der Nachfolger 8051 drin. So verdreht ist die Welt. ;-) Aktuell habe ich hier einen Baustein von Mitsubishi mit der Aufschrift 8042 liegen, das wird auch ein echter sein. Dann zwei weitere Bausteine, von denen ich es nicht weiß. Einer trägt nur den Namenszug Olivetti, der andere den Namen JETkey Fastest Keyboard BIOS. Die kommen auch aufs Steckbrett, mit der Strombegrenzung am Netzteil an. Entweder sind es welche, oder nicht. Matthias Sch. schrieb: > Soweit ich mich erinnere, darf nicht mal eine normale Routine einfach > die Pagegrenze überschreiten. Das hiess dann immer, Programm > assemblieren und mal schauen, wie lang es pro Page sein darf. Eben. Man muß im Listing immer schauen, ob alles richtig ist, und die Adreßbereiche selbst verwalten. Deshalb kann ich mir auch nicht so recht so recht vorstellen, daß es für die Kiste mal einen Hochsprachencompiler gab. Der Compilerhersteller wäre von der Brücke gesprungen!!! Für Hochsprache war aber der kleine Speicherbereich auch nichts. Schon mit einem printf() alleine wäre das EPROM fast voll gewesen. > Haben hier noch irgendwo ein paar 8748 (EPROM Version) - aber keinen > Brenner mehr dafür. Da kannst du auch einfach nur ein EPROM anklemmen, und den internen Speicher abschalten. Wenn ich mehr Spaß an den Dingen bekomme, baue ich auch noch einen Soft-UART, um ihn mit dem PC zu verbinden. Die 8048-er in PC-Tastaturen arbeiten auch mit Soft-UART, denn einen echten UART haben diese Bausteine ja gar nicht. Wie man sieht, spielt das aber auf der ganzen Welt in PC-Tastaturen sehr hervorragend. Ja, ich habe außer einem 8748 auch noch einige Bausteine mit Fenster hier herum fliegen, die man so ohne weiteres nicht in einen Brenner stecken kann. Z.B. 8755, das war ein Baustein mit 2k EPROM, Timer, RAM und I/O für den 8085, damit man einen 8085 mit nur einem Minimum an externen Bausteinen betreiben konnte. Dank Steckbrett werde ich aber auch mal einen Brenner für so spezielle Steine wie den 8755 zusammen tüfteln. Für den 8048 habe ich noch 4 Stück seines speziellen Kumpanen 8243, sie funktionieren alle. Damit konnte man mit nur 5 Pins den 8048 um 16 I/O erweitern. Ganz schräg ist, daß die Bausteine in nur einem Maschinenzyklus kommunizierten, und damit so schnell waren, wie echte integrierte I/O. Andere serielle Busse wie I2C kommen da nicht mit, und dann noch deren ganzer Overhead. Ich testete die Bausteine aber mit einem PIC12F675, der hatte gerade so genug Pins, nämlich 5 I/O. Für den PIC ist dieser Baustein also auch gut, um 16 weitere I/O zu bekommen. In dem schönen Simulator, den ich oben genannt bekam, und ihn gestern verwendete, ist übrigens auch der Assembler mit drin, und ein schönes Beispiel, wie man einfach den Programmspeicher des 8048 und RAM auf 64k und mehr erweitert. Eben mit nur den 5 Pins für den 8243. Auch ganz nett.
In Anlehnung an den Makrocompiler MC48 http://www.b-kainka.de/mc.htm habe ich seinerzeit ein Programmiertool für den 8048 gebastelt. Die Quelltexte des Originals standen nicht zur Verfügung und es war mein erster Versuch, etwas compilerähnliches zu programmieren. Es ist ein DOS(!) Programm, geschrieben mit Turbo-Pascal. Neben den Macro-Befehlen des Vorbildes beherrscht dieses Programm auch alle Assembler-Befehle, es kann wie ein Assembler verwendet werden. Es ist auch mehr ein Assembler als ein Compiler... Auch die Fallstricke, wie Pagegrenzen soll es erkennen (und beheben). Die Macro-Bibliothek ist um einiges erweitert worden, z.B. I2C. Nachdem ich es fertig hatte, hab ich's kaum gebraucht (wen wunderts). Habe es jetzt wieder herausgekramt und unter WinXP laufen lassen, scheint zu funktionieren. Gestartet wird es über die IDE "SV.EXE" (DOS-Programm, Shareware, Runtime-Error 200 entfernt). Alle Dateien im ZIP, aber nur etwas für echte Spinner! MfG. Ewig Gestriger
Wilhelm Ferkes schrieb: > Man kann sich z.B. > einen Tastaturcontroller oder Displaymultiplexer selbst bauen, oder > einen I/O-Port. Sonst brauchte man für sowas ja spezielle Bausteine wie > 8255 I/O oder 8279 Keyboard-Display-Interface Ehrlich gesagt, fand ich dafür den 8051 am besten. Eine komplexe Tastaturmatrix habe ich in seinem bit addressable RAM Feld abgelegt und konnte damit einfachst N-Key Rollover machen, indem ich den aktuellen Matrixzustand mit dem des vorherigen Durchlaufes verglichen habe. Je nachdem wurde dann ein Key-Up oder Key-Down an den Apple Desktop Bus geschickt. (Ja, sowas gab es mal - mit Mini DIN 4 Steckern :-) War 'ne Spezialentwicklung mit speicherbaren Textblöcken. Assembliert habe ich übrigens meistens mit TASM, der nahezu allen alten 8-Bitter konnte vom 8080, A48, A51, Z80 bis zum 6502 und 6800. Lustigerweise ist er in letzter Zeit wieder zu Ehren gekommen, weil ich mit einem TMS320C25 rumgespielt habe, den er auch kann.
Wilhelm Ferkes schrieb: > Exakt. Das sind Slave-Prozessoren, die vom Hauptprozessor bedient > wurden. Immerhin entschied man sich damals für die Verwendung in allen > IBM- und kompatiblen Rechnern, das ist schon gigantisch. Nur hatte Intel das Interface so strunzdumm gebaut - nämlich nicht viel mehr als ein einzelnes Datenregister - dass bei jeder Aktion der Master für seine Verhältnisse lange Zeit Däumchen drehen muss, bis der schnarchlangsame Controller im Kommunikationsprotokoll zwischen Master und Slave einen Schritt weiter ist. Da waren die Alternativen deutlich pfiffiger konstruiert (Motorola 68120 auf 6800-Basis, Zilog Z8094 auf Z8-Basis), die jeweils einen grösseren Dual-Port Bereich definierten. > Im Grunde kann heute schon mal einer aufs Steckbrett, man braucht ja > außer dem EPROM und Quarz weiter gar nichts. Das Zilog Teil gab es mit Sockel für 2KB SRAM huckepack an Stelle des internen ROMs, mit internem Urladeprogramm, so dass der Master das Programm dort hinein laden konnte. Das war auch nicht übel.
A. K. schrieb: > Das Zilog Teil gab es mit Sockel für 2KB SRAM huckepack an Stelle des > internen ROMs, mit internem Urladeprogramm, so dass der Master das > Programm dort hinein laden konnte. Das war auch nicht übel. Von diesen Z8 Piggy-Back Dingern habe ich sogar noch 2 Stück, die ich mal auf einer Fullheight Festplatte gefunden habe(!). Warum die da mit EPROMS (hier also keine SRAMs) und den MCs, die eigentlich nur für Prototyping gedacht waren, eine HDD gebaut haben, ist mir nie klar geworden - und es war die Ausführung mit Gold und Keramikcase. Und die Aufkleber auf den EPROM waren handbeschriftet.
Guten Morgen Matthias , würdest Bitte noch ein Bild einstellen? Sehr interessant.
Matthias Sch. schrieb: > Von diesen Z8 Piggy-Back Dingern habe ich sogar noch 2 Stück, die ich > mal auf einer Fullheight Festplatte gefunden habe(!). Warum die da mit > EPROMS (hier also keine SRAMs) und den MCs, die eigentlich nur für > Prototyping gedacht waren, eine HDD gebaut haben, ist mir nie klar > geworden - und es war die Ausführung mit Gold und Keramikcase. Apple hatte die Z8-03 in den ProFile und Widgets auch ziemlich lange drin. Später wurden die dann durch den Service eingesammelt und durch Masken-ROM ersetzt. Diese Laufwerke kenne ich ziemlich gut, sowohl die Schaltung als auch die Firmware. Bevor sich hier wieder Halbwissen verbreitet: Das EPROM auf dem Rücken des Zilog Z8-03 (oder neben dem MME U8820M) entspricht exakt dem internen Masken-ROM und wird auch genauso angesprochen. Kein Boot-ROM, kein "Urlader", kein Emulations-SRAM. Der Z8 hat einen Testmode, mit dem man das interne ROM überspringen und Code im externen Bereich ausführen kann. Ein bisschen wie /EA beim 8051, aber mit anderer Startadresse. Der externe Code kann dann das interne ROM über ldc-Befehle auslesen.
Angehängte Dateien:
-
Z8a.gif
9,5 KB
soul eye schrieb: > Bevor sich hier wieder Halbwissen verbreitet: Das EPROM auf dem Rücken > des Zilog Z8-03 (oder neben dem MME U8820M) entspricht exakt dem > internen Masken-ROM und wird auch genauso angesprochen. Kein Boot-ROM, > kein "Urlader", kein Emulations-SRAM. Bevor sich hier wieder Halbwissen verbreitet: Beim Piggyback-Speicher des Z8094/Z8594 UPC kann es sich ganz offiziell wahlweise um EPROM oder SRAM handeln. Mit 36 Bytes Bootstrap-Programm intern. Bei RAM handelt es sich auch nicht um einen Testmodus. Bei den selbständigen Microcontrollern der Z8 Reihe dürfte das anders ausgesehen haben. Aber die von mir oben angeführten Z8-UPC verwendeten zwar eine Z8 CPU, sind aber keine selbständigen Microcontroller, sondern zumindest in der Piggyback-Version nur als Slave-Device einsetzbar. Weshalb dieses von den normalen Z8 Mikrocontrollern abweichende Verfahren Sinn ergibt.
>> Die 8041/42 wurden UPI genannt, Universal Peripheral Interface und haben >> ein Feature das ich heute bei Mikrocontrollern vermisse: Einer der Ports >> ist mit einer Busschnittstelle versehen, > Exakt. Das sind Slave-Prozessoren, die vom Hauptprozessor bedient >wurden. Ja, die wenigsten Prozessoren (auch AVR nicht) haben so'n Interface (8 Bit oder mehr par. rein-raus schubsen, mit DPRAM oder FIFO), obwohl sowas doch sehr leistungsfähig ist/wäre. PIC hätte da den PMP anzubieten, mit 'ganzen' 4 Bytes DPRAM oder FIFO.
Interfacing dieser einfachen Art ist aus der Mode gekommen, und dafür gibt es Gründe: Wenn ein solcher Controller in seinem Interface-Protokoll pro Kommando-Byte seine zig Mikrosekunden benötigt, dann pollt ein besserer Prozessor in dieser Zeit hunderte bis tausende von Befehlen hohl und blockiert Bus-Resourcen. Weshalb Peripherie mit Eigenintelligenz entweder genug Dualport-Memory bietet, oder gleich Busmaster-Zugriff verwendet. Es ergibt einfach keinen Sinn, einen Prozessor damit zu beschäftigen, nutzlos auf einen um mehrere Grössenordnungen langsameren Zwerg zu warten. In der Kopplung (nicht nur) von Mikrocontrollern untereinander haben serielle Interfaces längst Pins fressende Parallelinterfaces ersetzt.
Es sind doch keine Mikrosekunden. Der Master schreibt/liesst einige Bytes mit seiner Geschwindigkeit ins/vom Interface (dauert nur wenige ns, viel schneller als bei UART oder SPI). Die Slave-CPU holt das (nach INT) an einem ab bzw schreibts in einem ins Interface rein. Das Schema (INT-gesteuert) ist prinz. genauso wie bei UART,SPI usw, nur das die eigentl Übertragung zwischen den IFs viel schneller ist, und (ja nach Ausführung) mehrere Bytes vom Master/Slave geschrieben/gelesen werden können. Für diese höheren Geschwindigkeiten müsste man bei anderen CPUs (bsp bei AVR) ggfs das ExtBusIF benutzen. DPRAM, FIFOs usw müsste man dann (evtl. im PLD) sep anschalten.
Angehängte Dateien:
-
Vintage_Chips.jpg
59 KB
Uwe S. schrieb: > Guten Morgen Matthias , > > würdest Bitte noch ein Bild einstellen? Gerne, siehe Anhang. Ich habe euch aber angelogen, es ist nur ein Z8 Piggy Back und dazu noch ein Mostek MK3870 mit Piggy Back. Entschuldigt die schlechte Bildqualität, aber meine Powershot G1 ist ein sehr, sehr altes Modell ohne Macro Zeugs. soul eye schrieb: > Apple hatte die Z8-03 in den ProFile und Widgets auch ziemlich lange > drin. Kann gut sein, das es eine ProFile war. Ich habe in den 80ern viel mit Apple gemacht und auch Service Zeugs einer befreundeten Werkstatt plündern dürfen. War jedenfalls eine Fullheigth Platte mit 8 Scheiben. Von oben nach unten und links nach rechts: links: 2 Stck. MC6605 (vermutlich DRAM) Z8 Piggy Back (Aufschrift Z8 2k XROM) mit 2708 EPROM. MK3870 Piggy Back, man beachte den überbreiten Körper. rechts: 2 Stck. 4416 DRAM TR1402 (soweit ich weiss, ein Bruder des CDP1802) 68A00 Motorola 8-bit und ein 8255, speziell für Willem :-) Hab auch noch nen 8755, der ist aber nicht in Gold.
Matthias Sch. schrieb: > Wilhelm Ferkes schrieb: >> Man kann sich z.B. >> einen Tastaturcontroller oder Displaymultiplexer selbst bauen, oder >> einen I/O-Port. Sonst brauchte man für sowas ja spezielle Bausteine wie >> 8255 I/O oder 8279 Keyboard-Display-Interface > > Ehrlich gesagt, fand ich dafür den 8051 am besten. Ja, vollkommen klar, wenn es nicht um Retro-Zeugs wie hier bei mir aktuell geht. > Eine komplexe > Tastaturmatrix habe ich in seinem bit addressable RAM Feld abgelegt und > konnte damit einfachst N-Key Rollover machen, Sowas habe ich alles auch hier verfügbar, Tastatursoftware mit und ohne Diodenmatrix, n-Key-Rollover, in Assembler zum Einbinden in beliebigen anderen Code. So Codeblöcke haben nur ca. 30-40 Bytes Größe, sind in einem Selbstbau auch verwendet, und damit auf beste Funktion verifiziert. Mit dem 8279 Keyboard-Display-Controller experimentierte ich aber auch schon, habe ein 80535-Board, wo einer drauf ist. Da bekommt der µC nur einen externen Interrupt gemeldet, und kann am Bus sein Zeichen fertig abholen, und allenfalls noch in ein FIFO einspeisen. Auch außerordentlich bequem. Eigentlich schade, daß dieser 8279 abgeschafft wurde, man hätte ihn meiner Meinung nach sehr gut als fertiges Peripheral in einen µC implementieren können, so wie es z.B. beim UART auch ist. > Assembliert habe ich übrigens meistens mit TASM, der nahezu allen alten > 8-Bitter konnte vom 8080, A48, A51, Z80 bis zum 6502 und 6800. > Lustigerweise ist er in letzter Zeit wieder zu Ehren gekommen, weil ich > mit einem TMS320C25 rumgespielt habe, den er auch kann. Den TASM verwendete ich sowohl für 8085 als auch jetzt für 8048. Für den 80C382 mußte ich aber eine neue Tabelle schreiben, weil Befehle weg fielen, und andere neue hinzu kamen, oder ein Befehl einen neuen Maschinencode bekam. Das geht dann mit der 8048-Tabelle nicht mehr. Letztendlich schaute ich mir auch die EPROM-Versionen MC68705P3 an. Da brauche ich nur etwas Programmierlogik zu basteln, die haben einen maskenprogrammierten Bootloader im Chip. Aber mit Parallelbus, und er braucht noch 26V Programmierspannung. Da ich keinen Bock auf ein Extra-Netzteil habe, oder dafür einen Stepup-Wandler zu kaufen, mache ich den gerade mal mit einem kleinen PIC. Einfacher PSM-Modulator zur Erzeugung einer Stepup-Spannung nur mit (Schottky-)Diode, Transistor, Spule und Elko aus 5V. Später möchte ich PSM noch gegen einen richtigen PID-Regler tauschen, aber das wird erst nicht nötig sein. Das sollte alles auf das kleinste Steckbrett gehen. Aber alle Dinge brauchen so ihr Weilchen, das ist bei mir auch fast egal. Matthias Sch. schrieb: > und ein 8255, speziell für Willem :-) Schönes Schätzchen, der 8255 aus Keramik. Meine zwei aus der selben Zeit auch von AMD sind leider nur aus Plastik, und beide auch noch aus der selben Charge, funktionieren beide einwandfrei. Von diesen Keramikbausteinen mit geerdetem Plättchen an der Oberseite habe ich nur noch die C1101A (256x1 bit PMOS-SRAM) und 2k EPROM von TI (TMS2516). Die 2516 von 1979 sind 2716, laufen auch gut, ich muß sie nur 5 mal so lange mit der UV-Dosis von moderneren EPROMs löschen. Sie sind also gegen Licht außerordentlich resistent (sollte sie vielleicht auch mal der NASA anbieten ;-)). Habe sie schon ein paar mal verwendet, und sie haben Brennungen und Löschungen gut ausgehalten. Mal sehen, ob ich nicht auch noch mal Fotos mache. Wir haben ja hier noch kein Ende beschlossen. ;-)
Wilhelm Ferkes schrieb: > Eigentlich schade, daß dieser 8279 abgeschafft > wurde, man hätte ihn meiner Meinung nach sehr gut als fertiges > Peripheral in einen µC implementieren können Den hatte ich auch mal auf einer Grafik/Keyboard-Karte für mein Z80 System, der hatte den Vorteil, dass noch eine serielle Schnittstelle drin war, daher konnte ich eigene Tastaturmatrizen ebenso anschliessen wie externe Keyboards mit RS422. Der Nachteil war, dass die Matrixbelegung vorgegeben war. Da der 8279 aber schon in der Steinzeit nicht mehr erhältlich war, habe ich ihn auf der Nachfolgeversion mit einem 8742 emuliert, unter Erhaltung aller Funktionen. Gruss Reinhard
Der i8279 ist ein 8041 mit entsprechender Programmierung, leider etwas anders gebondet. Insofern hast Du genau den richtigen Ansatz gewählt. Lt UPI-41 User's Manual gab es auch welche als GPIB-Controller (i8292) oder DES Encryption Unit (i8294). Echte Masken-ROMs sind bei den MCS-48 extrem selten. Nahezu alle 8049, 8042 etc, die mir bisher begegnet sind, enthielten OTP-EPROMs und liessen sich im Programmiergerät auslesen. Damit kann man einem Nadeldrucker oder einer Tastatur auch mal genauer auf den Zahn fühlen.
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.