|
Anzeige
|
Adressdekoder für 68k CPUHallo *, ich befasse mich gerade gedanklich mit dem Design eines Boards für einen 68000. Im Gegensatz zu den meisten Projekten möchte ich allerdings das RAM bei 0x0000-0x???? haben um zur Laufzeit die Vektoren für die Exceptions ändern zu können. Mein Ansatz wäre jetzt für die Dekodierung ein CPLD zu verwenden und damit für die ersten Zugriffe nach dem Reset das ROM auf 0x0000 zu "spiegeln". Gibt es weiter Vorschläge? Nimm einen 68010, 020, 030. Da hast Du dann ein Vektorbasisregister und kannst die Exceptiontabelle irgendwo hinlegen. fchk
Man kann die drei Function Code Pins FC0--FC2 für die Dekodierung benutzen, denn diese signalisieren auch den Zugriff auf die Reset-Vektoren. So hatte ich Anfang der 1990er mein eigenes Board entworfen. Der Adressdekodierer bestand im Wesentlichen aus 2 GALs (16V8 und 20V8) und ein paar TTL-Gattern. Meine Dokumentation ist aber leider etwas lückenhaft. Für die moderenen 68k-CPUs musst Du aber ggf. prüfen, ob die sich gleich verhalten. Andere Lösungen implementierten ein Flipflop im Adressdekoder, das nach dem Auslesen des Resetvektors kippt und dann statt des ROMs das RAM in den unteren Adressbereich einblendete, bis zum nächsten Reset. Grüßle, Volker
So hat es der Amiga gemacht ;-) Address decoder (die die jeweiligen ChipSelect-Signale (CS)) erzeugen brauchste doch so oder so um weitere Chips etc an den AdressBus zu klemmen. Statt konfigurierbaren PLD könnte man aus der 74 Familie auch einen "1 aus n decoder" verwenden (74xx138). :
Bearbeitet durch User
Es ist halt die Frage, wie man das zahlt. Ein FlipFlop, von RESET zuruckgesetzt, wird gesetzt so bald ein Zugriff anderswo erfolgt der sowieso decodiert wurde. Dieses FlipFlop fliesst in die Decodierung ein und blendet z.B. das RAM aus. Besser als Instruktionen oder Zeit zählen.
Musste erst mal mein ur-uraltes 68000 Assembler Manual (Kane,Hawkins,Leventhal) ausgraben um mich etwas aufzufrischen. ;-) Also lt. Fig 15-1 sind es 256 Vektoren, davon einige (24) für Motorola reserviert und 192 für User Interrupts. Man könnte das ROM dort lassen, wo es hingehört. Nach einem RESET eine Struktur/Sprungtabelle im RAM anlegen mit später modifizierbaren Vektoren. Die ROM Vektoren zeigen auf diese Sprungtabelle im RAM. Kostet ein paar Zyklen, spart aber Hardware und erfüllt alle Zwecke. Ich würde das Rom kopieren, weil könnte 8Bit sein und Ram dann in Wortbreite. Ich muss Heiner beipflichten. ROM mit Shadow-RAM Konfiguration und Flipflop zum Umschalten. Beim Einschalten das ROM ins RAM kopieren und umschalten. Danach kann man alles so Ändern, wie man es mag. Dann aber darauf achten, dass im ROM nur relative Sprünge und Referenzen verwendet werden, damit diese im RAM auch noch funktionieren. Und eine physikalische Umschaltung nach abgeschlossenem RESET braucht man dennoch. :
Bearbeitet durch User
Nö. Nach Reset: ROM lesen, RAM schreiben. Umgeschaltet: RAM lesen, RAM schreiben. Im Reset-Handler den Adressraum auf sich selbst kopieren, umschalten. Hat man schon anno Z80 so gemacht. :
Bearbeitet durch User
OK, komplett also. Na ja, kann man machen wenn genug RAM zum Verschwenden da ist. Mir erschließt sich allerdings der Nutzen noch nicht vollumfänglich. Der Aufwand hält sich in Grenzen. Ich hab das mal gelöst, in dem ich RAM und ROM auf der gleichen Adresse hatte. Gelesen wurde nach RESET immer das ROM und geschrieben immer das RAM. Dann wurde per IO umgeschaltet und das ROM "verschwand". Die Logik dahinter ist minimal und das "Durchkopieren" einfach. Der Code benötigt für das Umschalten keinerlei Besonderheiten. Er macht im RAM einfach da weiter, wo er im ROM aufgehört hat. Ich hab das vor langer langer Zeit mal so gemacht... 6502 oder Z80... Ich weiß es nicht mehr. Später noch mal in einem Ti DSP.
Beim Atari ST wurden nur die ersten beiden Vektoren (Init-Werte für SSP und PC) aus dem ROM eingespiegelt. Macht den Adressdecoder etwas komplizierter als stumpfes "Hälfte RAM, Hälfte ROM", aber sobald Du etwas Peripherie dranhängst, ist er das ohnehin.
Hm, da gibt es Unterschiede zwischen den verschiedenen Modellen, die Variante des A1000 kommt wohl dem Anliegen des TO am nächsten. Bei diesem wurde zu Beginn der "ROM-Inhalt" von Diskette in einen extra (Kickstart-)RAM geschrieben und dann dieser RAM als ROM geschaltet und das eigentliche boot gestartet. Das nannte sich WCS - Writable Control Store. Für die Nachfolger A500 und A1000 dagegen hatte man die Firmware fertig so das deren Platine einen echten ROM bekam. Die Logik für die bootphase ist beim A1000 noch diskret (74* und so) während die Nachfolger dafür den Garry als custom chip hatten. Beschreibung der Logik im Garry gibt es für FPGA-Nachbauten, bspw. in Minimic.projekt. Gekürzter Auszug
Wie man am input 'boot' und 'ovl' sieht, ist das nur die halbe Wahrheit, mehr kann man sicher den Schaltplänen vom A1000 und A500 entnehmen. In einigen Projekten wird statt logic ein kleiner (8 bit) µController verwendet. Wer diesen "Stilbruch" (moderner Controller auf klassischen 68k board) nicht scheut kann man auch damit das Umkopieren realisieren. "... haben um zur Laufzeit die Vektoren für die Exceptions ändern zu können ..." Hm, welche den? Beim Amiga konnte man bspw den Cold (x002A) und den Cool Capture (x002E) "verbiegen" um die Staradresse des bei boot auszuführenden zu ändern: https://www.thedigitalcatonline.com/blog/2018/06/25/exploring-the-amiga-5/
Alle 256 welche ein 68000 bietet! Denn im Eröffnungsbeitrag ging es nie um einen Amiga. Noch eine andere Lösung: Hier hat jemand einen Haufen 68360 anzubieten. https://www.eevblog.com/forum/buysellwanted/motorola-xc68360fe25b-cpu-qfp/ Die haben einen CPU32 Kern mit den meisten 020 Erweiterungen (die Bitfield-Opcodes fehlen), integrierter programmierbarer Decodierlogik (man braucht also keine externen Adressdecoder) und interner Peripherie. Dazu ein BDM Debug-Port zum Flashen und Debuggen. Ich habe mit diesen Teilen Ende der 90'er Jahre entwickelt. https://www.nxp.com/products/MC68360 fchk Für die PGA Version de 68360 hätte ich sogar einen HP Emulator. Allerdings sind die PGA-Sockel nicht mehr beschaffbar.
Besorge dir ältere 68000-Cpu Hardware-Beschreibungs-Bücher und alte Atari ST und Amiga Assembler-Programmierbücher. Die Programmierung ist nicht ganz einfach. Letztlich sind die 68000er ja auch untergegangen, gerade weil sie nicht so einfach auf Hardware-Ebene programmiert werden können, und weil die Kompatibilität nicht so gut wie beim Intel funktionierte.
68k-Assembler ist geradezu traumhaft, was soll daran "nicht einfach" sein?
Was für ein Unsinn.
Sind die Pins nicht im 100-mil-Raster angeordnet? Dann lassen sich die Sockel doch recht einfach durch einreihige Sockelleisten "emulieren", z.B. mit: https://www.reichelt.de/de/de/shop/produkt/praezisions-sockelstreifen_2_54_mm_20-polig-119950 Grüßle, Volker
Mnemonics/Maschinencode sind sogar derart großartig strukturiert, dass man noch nicht einmal einen C-Compiler vermissen würde. Einer der Angenehmsten den ich seinerzeit in den Fingern haben durfte.
genau.
+10! Der liest sich fast wie Hochsprache. Ich hab den 68k-Assembler zwar nur als Trockenübung gemacht (mangels geeigneten Computer, ich wollte damals einen Gepard) aber ... ich kannte damals 6502 und 6809.
Könnte man mache, ist aber spätestens bei den Sockeln die ich gerne benutze um wie in diesem Fall die Pins am Emulator zu schützen nicht mehr ganz so toll.
Das ist doch völlig verdreckt. Wer soll das kaufen?
Dann wird's mal Zeit sich zu entscheiden. Entweder wird das gesamte ROM kopiert (beginnend bei ROM 0x0 nach RAM 0x0), dann braucht man sich um Adressenanpassung nicht zu kümmern. Oder aber das ROM wird nach einem RESET kurz bei 0x0 eingeblendet, etwas kopiert, dann woanders eingeblendet und dort benutzt. Dann müssen Kopierroutine sowie alle anderen mit unterschiedlichen Basisadressen behandelt werden. Wie gesagt, man kann die tollsten Sachen machen. Aber alle Verschiebereien und Einblendungen benötigen auch noch zusätzliche Hardware. Und gefragt wurde nach ›weiteren Vorschlägen‹. Nicht nach Wiederholungen der bereits im Eingangsbeitrag genannten Idee.
Wenn man die Arbeitsweise im Hinterkopf hat dann schon. Nur der Einstieg halt erfordert etwas mehr Aufmerksamkeit, im Schlaf lernt man den nicht. Die Hardware ist prinzipiell vorbildlich aber
Dass die Cpus untergegangen sind? Da gehörten sicher noch andere Hinweise dazu, Kompatibilitätsmangel oder Schwierigkeiten bei den Cirquit-Erweiterungen (Entwicklungsintegrationsschwierigkeiten - wurden damals hier auf MC.Net sehr gut erklärt). Als Fanboy sieht man natürlich nicht mehr die Schwierigkeiten der CPUs damals. Fakt ist: sie sind untergegangen. Warum sind die Intel oder Z80 Cpus nicht gleich untergegangen? Naja, möglicherweise war auch die Preis/Leistung-Sache im Gang. Aber Informationen und Einübungen waren auch nicht unbedingt billig. Oder noch anders: Die 68000er waren schlicht so schlecht optimiert, dass sie keine Zukunft hatten. Und hinsichtlich des Hardware-Bastelns sich viele Nächte mit Bombenrauswurf auf dem Bildschirm um die Ohren zu hauen, war auch nicht unbedingt so dolle. Letztlich waren Intel und Z80 auch deutlich besser dokumentiert als die 68000er, dessen gute Informationen man vor allem an den Unis finden konnte - sofern man Glück hatte.
Der innere Ablauf der Befehle war besonders ab 68020 derart komplex, dass eine effiziente Beschleunigung durch modernere Verfahren wie out of order execution und superscalar execution enorm erschwert wurde. Mit 68060 kam das zwar, aber der Zug ging damals bereits in eine andere Richtung. Andere dahingehend hochkomplexe Architekturen wie VAX und NS32K scheiterten ebenfalls daran. Mit Coldfire überlebte die 68K Architektur als ein wieder deutlich reduziertes Derivat in Embedded. X86 war damals tatsächlich weniger komplex als 68020, was diese Punkte angeht, und hatte die Stückzahlen, trotzdem den damals enormen Aufwand dafür zu rechtfertigen. :
Bearbeitet durch User
Nur waren die 80er Jahre von einer Abkehr von Assembler-Programmierung geprägt. Pascal und C lieferten sich ein Rennen, das C gewann. Und wenn man einmal auf Hochsprachen-Ebene ist, spielt die Assembler-Ebene keine wesentliche Rolle mehr. Eher schon die Frage, ob der Aufwand einer Assembler-freundlichen Architektur überhaupt noch sinnvoll ist, oder ob man sich auf Maschinen-Ebene auf das beschränkt, was Compiler benötigen. :
Bearbeitet durch User
Dann hätte ein sofortiger Umschwung weg von CISC auf reine RISC Architektur stattfinden müssen. Die Intel CPUs haben "das Rennen gewonnen" weil sie zum richtigen Zeitpunkt in den richtigen Geräten (den aufkommenden PCs) und in echten Stückzahlen auftauchten. Und ich hoffe doch sehr, dass niemand ernsthaft diese grauenvolle Segment-Register Architektur als die beste Erfindung seit geschnittenem Brot ansieht. VHS hat auch das Rennen gegen Betamax gemacht, egal wie grottig es war.
Hat ja auch, nur nicht so blitzartig wie du schreibst, und eingeschränkt durch die kritische Masse der x86er. Ich hatte damals selbst mit diesem Compiler-Thema zu tun, und mit der Affinität von Compilern und Architekturen. Der Schlüssel war der Erfolg der Pentium Pro Architektur, in der die erwähnten Punkte erfolgreich und erschwinglich implementiert wurden. Von da an wars wieder relativ egal, was darunter steckte. :
Bearbeitet durch User
Betamax? Was war das? Bei mir hat VHS gegen Video 2000 gewonnen, weil es nur bespielte Kassetten in VHS zum Ausleihen gab und Video 2000 noch in den Babyschuhen steckte...
Na ja, die komplette x86 Architektur kann man nun wirklich nicht als RISC einstufen. Sie haben später einige wenige RISC ähnliche Dinge eingebaut, aus dem einfachen Grunde weil diese besser/schneller/Energieeffizienter funktionieren. Als reines Gedankenspiel könnte man mal darüber nachdenken, was damals passiert wäre, hätte man tatsächlich auf RISC gesetzt. Ohne Wenn und Aber und mit der vollen Marktmacht und demzufolge einem enormen Entwicklungspotential. Die Compiler-Bauer hätten Rückmeldungen geliefert und diese so in die nächste Hardware-Inkarnation einfließen lassen. Iterate, Iterate, Iterate, … Wo stünden wir heute?
Fan von alternativer Geschichte? Es gab eine Zeit, in der die RISC deutlich vorne lagen, bei gleicher Chiptech und -Fläche. Mittlerweile ist der bei x86 höhere Aufwand aber kaum noch relevant, der Anteil am Chip minimal. :
Bearbeitet durch User
Sie haben das als notwendige Grundlage von out of order execution eingebaut. Die Auflösung der komplexen Befehle in Sequenzen dafür geeigneterer einfacher Befehle. Das RISC zu nennen ist Werbesprache, weil damals en vogue. Ebenso könnte man die Mikrobefehle einer Maximal-CISC Architektur wie VAX RISC nennen. In den letzten Jahren ändert sich das Bild etwas, weil Mobilgeräte am PC-Monopol kratzen, der PC nicht mehr zwingend ist. Auch Microsoft öffnet sich vorsichtshalber wieder ARM, um nicht eines Tages auf der falschen Seite der Geschichte aufzuwachen. :
Bearbeitet durch User
Viele gute C-Programmierer hatten früher schon auf den Apple-Computern programmiert und so konnten die auch gut Atari-Programme in C entwickeln. Würde aber nicht sagen, das Pascal verloren hatte. Zumindest auf der Spiele-Crack-Ebene nicht ;) so grundsätzlich war damals viel Basic-Asm-Pascal KnowHow verbreitet, vor allem auch bei guten Elektronikern. Die hatte sich aber auch mehr auf den Intel-PC konzentriert. Beim Atari ST war eine Basic-Entwicklung IDE mit eingebaut. War aber ein schreckliches Teil, echt zum Weglaufen oder zum Vergraulen. Diesbezüglich hätten sich die Atari-Leute deutlich mehr Mühe machen müssen. Viele User sind damals dann schnell auf GFA-Basic umgestiegen, glaube ich. https://de.wikipedia.org/wiki/GFA-BASIC)
Apple hat auch viel mit einer Pascal-Variante gearbeitet: https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/ Auf dem Amiga war Modula-2 , eine Art Pascal-Nachfolger, recht beliebt. Dennoch hat C obsiegt.
Dass Du immer nur von Spielen faselst, sagt vieles über Deine Kompetenz aus. Und mir ist kein Cracker begegnet, der etwas anderes als Assembler benutzt hätte.
Blödsinn, das ST-BASIC war nie im ROM, das lag auf einer Diskette bei.
Haben sie, deshalb haben sie nach einer Weile stattdessen Omikron BASIC (nur den Interpreter) beigelegt.
Sowohl das als auch Omikron BASIC waren verbreitet. Omikron hat dann wohl das günstigere Angebot gemacht.
Erbsenzähler. Soweit ich weiß, kam das im Lieferpacket mit, und sonst nichts anderes. War halt reichlich enttäuschend als ersten Eindruck.
Beim Amiga (zumindest beim 500er) war auch ein reichlich enttäuschendes BASIC dabei. Naja, war von Microsoft, konnte also wohl nicht wirklich gut sein...
Kenne ich gar nicht. Damals war das vom C16 aber super. Bei PC habe ich auch noch ein MS-BASIC mit Compiler. Das fand ich gar nicht so übel, weil natürlich auch damals (noch nicht so lange her) noch verschiedene Schulprogrammierhefte mit BASIC erklärt wurden und nicht wie aktuell mit Java oder Python.
Kickstart 1.3, AmigaBASIC 1.2, Microsoft 1985,1986 Das war so grauenvoll, dass man es bei neueren Kickstart Versionen dann aus gutem Grund endgültig begraben hat. Man hat damit erfolgreich all das am Amiga schlecht gemacht, was eigentlich verdammt gut war. 190 Sekunden für den Hut. In der Zeit hatte die Oma ein paar Socken für den Winter gestrickt.
Andererseits, kaum eine andere Firma kann von sich behaupten über Jahrzehnte hinweg dieses Niveau aufrecht erhalten zu haben.
Angehängte Dateien:
bei jedem Heimecomputer lag "damals" irgendwie ein BASIC dabei. Vielleich um den Bildungsbereich (Schulen) zu bedienen, die zumindest in den USA damals einen großen Anteil unter den Kunden der Computerfirmen ausmachten. Und es gab langsame und noch langsamere Basic-Interpreter und die schnarch langsame Nutzung von trigomometrischen float-Funktionen auf diesen FPU-losen 8MHz Kisten tat ihr übriges. Das Amiga-Basic flog hauptsächlich wegen der Kosten und Inkompatibilitäten zu neueren OS-Versionen raus.
Wie jedes Andere auch, konnte AmigaBASIC mit Integer Werten arbeiten. Und es war nicht verboten, sich einmalig eine kombinierte sin/cos Tabelle mit 450 Einträgen zu erstellen.
(Es ist übrigens absichtlich schlecht lesbar geschrieben, da Formatierung und sogar Leerzeichen zusätzliche Rechenzeit benötigen.) :
Bearbeitet durch User
Es ist ja schon alles geschrieben und genug nostalgiert worden - nur noch nicht von mir ;-) Seinerzeit hatte ich das /Reset-Signal mit an den Adressdekoder ('/INIT' am GAL20V8) gelegt. Nach Laden des Stackpointers und der Startadresse (hier 0x100000) wurde 'HALT' aktiv und somit das RAM ab 0x0 und das EPROM ab 0x100000 angesprochen. Die letzte 68K CPU war bei mir der 68HC001, den ich auch dem TO empfehlen würde. 68k hatte ich dann durch die sehr ähnlichen H8/3003, H8S2392 und H8SX1668 ersetzt. Seinerzeit alles schöne Teile!
Angehängte Dateien:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
