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.
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 MC48http://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.
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.
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.
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.
