atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Do 18.02.2016, 17:08:37
-
Als nächstes Bastelprojekt wollte ich mir gerne diese 8Mhz MC68020 Karte aus Frankreich auf Lochraster aufbauen. Der Schaltplan ist leider nicht eindeutig was die Anschlüsse an den beiden GALs angeht. Die Platine liegt ja als Bild vor und ich habe mir Folien für meinen Laserdrucker besorgt, drucke beide Seiten mal vergrößert aus, lege die übereinander und gehe mal die Anschlüsse durch.
-> http://fr.meric.free.fr/Articles/Classes/booster020/tutoassemblage/MontageBooster020ParEtape.html
-> http://fr.meric.free.fr/Articles/Classes/booster020/noticeBooster20/Booster20Montage.html
(http://fr.meric.free.fr/Articles/Classes/booster020/SchemaBoosterV14portrait.jpg)
(http://fr.meric.free.fr/Articles/Classes/booster020/noticeBooster20/Booster20Montage_html_m50422187.jpg)
GAL nr.:1
GAL16V8;BOOSTER pour ATARI piece 1 Jano le 24/10/91
CLK SIZ1 NVPA SIZ0 A0 NBGACK NC NAS NDS GND
NOE DCLK NLDS A NUDS B D NVMA E VCC
/NUDS=/NDS*/A0
NUDS.trst=NBGACK
/NLDS=/NDS*A0+/NDS*/SIZ0+/NDS*SIZ1
NLDS.trst=NBGACK
/NVMA=/NVPA*/NAS*A*/B*/E*/D+/NVPA*/NVMA*/NAS
NVMA.trst=NBGACK
A:=/A
B:=A*B*/E+/A*D+/E*D
E:=A*E+B*E+E*/D+/A*/B*/D
D:=/A*E+B*E+E*D+A*D
DCLK=A*E*D
GAL nr.:2
GAL16V8;BOOSTER pour ATARI piece 2 Jano le 30/04/92
DCLK NAS NVPA A16 NVMA CLKDE CLK FC1 FC0 GND
NOE NAVEC NDSACK0 A17 CLKD DC DDC NFPUCS HMPU VCC
/NAVEC=/NAS*FC0*FC1*A16*A17*/NVPA
/NFPUCS=FC0*FC1*/A16*A17*/CLK+FC0*FC1*/A16*A17*/NAS+FC0*FC1*/A16*A17*/CLKD
/NDSACK0=/NVMA*/NAS*NFPUCS*DCLK+/NVMA*/NAS*NFPUCS*/NDSACK0
CLKD=CLK
DC=CLKDE
DDC=DC
HMPU=CLK*/DDC*NAS+/CLK*DDC*NAS+CLK*/NAS
-
Nette Spielerei, aber ich glaube die bringt dir kaum Performancegewinn. Die Pak 68/2 mit 020-16, wie ich sie habe, bringt maximal genau das doppelte wie ein 68000. Kannst ja deine Schlüsse daraus ziehen, was dann ein 020 bei 8 Mhz packt.
-
Das auf Folie ausdrucken und übereinanderlegen ist tatsächlich eine sehr gute Reverse-Engineering-Technik. Aber was ist denn bei den GALs uneindeutig? Pins und Signale sind eindeutig beschriftet, bis auf Pin 5 bei U4, wobei aber den GAL-Gleichungen entnommen werden kann, dass es sich dabei um A0 handelt.
Vorteil gegenüber nur einem 68000, den diese Karte ja wohl ersetzen soll, ist auf alle Fälle die FPU, zumindest bei der Software, die diese auch nutzt.
-
In erster Linie geht es mir um MiNT, das ich 020er Code laufen lassen kann. Zum Beispiel die alternativen Netzwerkkarten Treiber für meine NetusBee. Eine PAK68/2 hatte ich schon, die könnte ich auch nachbauen und das 32bit breite TOS weglassen. Aber mit vier GALs ist mir das zu kompliziert und die 16Mhz machen den Braten auch nicht Fett ...
Ich hatte damals mal ein Mega ST Board mit 50Mhz und 64Mhz Hauptquarz. Nachteil war halt die hohe Bildwiederholrate bei den Systemauflösungen. Die Atari Bausteine machen das mit. Jetzt mit einer Grafikkarte wäre das vielleicht wieder Interessant, mal schauen ...
-
@czietz ... ich blicke das noch nicht ganz was jetzt ein 68000 Signal ist und was ein 68020 Signal. Die gibt es ja teilweise an beiden CPUs ...
-
Moment, die Karte ersetzt ja Deine bisherige 68000-CPU. Das was dort im Schaltplan als "68000" bezeichnet ist, ist nur der verbliebene Sockel der alten CPU. Und natürlich müssen die Signale dort entweder mit dem 68020 oder den GALs verbunden werden. Zum Beispiel der Adressbus: A1-A23 von der neuen CPU geht direkt zum Sockel und damit direkt in den Atari. A0 gibt's beim 68000 nicht, also wird das A0-Signal von den GALs in UDS und LDS übersetzt.
Also: Alle gleich bezeichneten Signale im Schaltplan sind miteinander zu verbinden.
-
Hier noch eine Grafik zur Geschwindigkeit der "Booster020"
Links ohne und rechts mit integriertem Cache.
-
Interessant, dass insbesondere Speicherzugriffe ohne den puffernden Cache sogar langsamer sind als mit dem 68000. In dem Artikel, aus dem das Bild stammt ist auch eine mögliche Erklärung:
La seconde explication provient de ce que le ST a été conçu pour tirer le maximum du 68000, et non du 68020 qui n'existait pas à l'époque. En effet, j'ai signalé plus haut que le cycle machine du 68000 est constitué de 4 cycles horloge. Un de ces cycles n'étant pas utilisé par le bus, Shiraz Shivji (NDLR : le concepteur du ST) en a profité pour entrelacer des accès à la mémoire par le Shifter (pour rafraîchir l'écran). Le partage de la mémoire entre le Shifter et le 68000 est donc pratiquement réalisé sans conflit, et donc sans ralentissement du processeur central. Malheureusement pour lui, le 68020 est plus rapide (3 cycles horloge par cycle machine, tous utilisés), et donc les télescopages avec le shifter sont fréquents. Résultat, le 68020 est constamment freiné dans son élan par le Shifter, qui lui ne peut pas attendre (sinon votre écran vous ferait irrésistiblement penser à celui d'une chaîne cryptée bien connue).
http://fr.meric.free.fr/Articles/ArticlesOCR/Un68020pourST.html
Kurz übersetzt und zusammengefasst: Der Autor mutmaßt, dass sich der 68020 aufgrund eines anderen Buszyklus (min. 3 Taktzyklen statt min. 4 Takte beim 68000) mit dem Shifter ins Gehege kommt und damit ausgebremst wird.
Ein Cache hilft da natürlich nur bei Code oder Daten, auf die mehrfach zugegriffen wird, sodass überhaupt Cache-Hits entstehen.
-
So habe mir die Teile besorgt und mal angefangen, fehlt nur noch das Fädeldraht Chaos auf der Rückseite ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12709.0;attach=10830;image)
-
Bekommt man die CPU´s noch ran ? Wenn ja dann könnte man das Board ja mal layouten und 10 Platinen machen lassen. Wäre ja nicht das Monster Problem ? Aber berichte doch mal was es bringt, vielleicht könnte man sie auch auf 16Mhz laufen lassen mit Anpassungen der Gleichungen im GAL
-
68020 CPUs bekommt man über Ebay oder auch für ein paar Euro bei Kessler. Eine Platine wäre toll aber nur original mit 8Mhz ansonsten einfach eine PAK68/2 ohne das 32bit breite TOS nachbauen ...
-
Könnte ja mal Holger anfragen was er denkt welches Aufwand es wäre eine Pak mt heutigen Mitteln aufzubauen.
-
Dann aber doch bitte gleich eine 030er. (oder 040, 060??? Die CPUs sind zwar etwas schwer zu bekommen, aber nicht mehr so teuer wie früher. ( Zur Not schlachtet man einen Mac Quadra aus, den in der Bucht keiner mehr willl... >:D )
-
Aufwand leider zu groß, glaube nicht das er das macht. Ich bin dazu nicht in Stande um eine busadaption vorzunehmen.
-
Der Holger hat mit der PAK68/2 nichts zu tun soweit ich weiss. Die PAK68/2 ist vom Aufwand her nicht so groß, es sind ohne das TOS drei GALs. Den Schaltplan und die PAL Quellen habe ich. Müsste man nur auf GALs umsetzen ...
MC68030/40 oder gar größer ist viel zu groß beim Aufwand und die Bussteuerung nicht ohne. Ausser ein oder zwei Leute bekommt das so einfach niemand hin vermute ich mal.
-
(aufbereiteten & gescannten) Schaltplan, sowie Platinenscans zur PAK68/2 hab ich hier. Die inneren Layer hatte ich auch schon reversiert.
Fehlt also "nur" das Routing + Testlauf, dass nichts vergessen wurde.
Bei ernstgemeintem, nicht kommerziellem Interesse stell ich die Daten gerne zur Verfügung, da ich kein weiteres Interesse habe die PAK68/2 zu reversen.
-
Stelle deine Sachen doch bitte hier ein. Es wäre schade wenn das alles Untergeht. Kannst du denn noch eventuell helfen beim umsetzen der PAL auf GALs. Oder sind die Maxon GAL Assembler Dateien richtig so und sollten laufen ?
-> http://www.atari-forum.com/viewtopic.php?t=23882#p216381
-
Zusammen mit neogain der das Layout gemacht hat haben wir mal Platinen machen lassen ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12709.0;attach=11120;image)
(http://forum.atari-home.de/index.php?action=dlattach;topic=12709.0;attach=11122;image)
Die Gembenchwerte sind sehr gut für einen 8Mhz MC68020 und eine 8Mhz MC68882 FPU, laufen tut das ganze mit KAOS TOS 1.42B auf einem normalen Atari Mega ST1 mit 4MB ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=12709.0;attach=11124;image)
@Idek Tramielski ... die Nova Treiber laufen wunderbar mit der 020 CPU Karte. Das es mit dem MC68010 nicht ging, keine Ahnung. Ist aber nicht weiter wichtig ...
-
Absolut top!!!
-
Cool...was ich nicht verstehe: Warum liegt der RAM und ROM Zugriff über 100%. Liegt das am Level 1 Cache? Ist das denn ein Datencache?
-
Der Formfaktor der original Platine gefällt mir wegen ihrer Kleinheit wegen besser, der Neuen fehlt der Schnuckelfaktor.
-
Cool...was ich nicht verstehe: Warum liegt der RAM und ROM Zugriff über 100%. Liegt das am Level 1 Cache? Ist das denn ein Datencache?
Man müsste sich GEMBench angucken, um zu sehen, wie dort RAM- und ROM-Zugriff gemessen werden. Wenn Instruktionen zum Einsatz kommen, die -- unabhängig vom Speicherzugriff oder einem evtl. aktiven Cache -- auf einem 68020 einfach weniger Taktzyklen brauchen und diese Instruktionen einen ausreichenden Anteil an der Gesamtmesszeit haben, dann sieht man in dem Benchmark nicht etwa einen beschleunigten Speicherzugriff sondern (nochmals) die andere CPU.
-
Alle Benchmark Programme sind irgendwie Mumpitz ...
Es ist auf jeden Fall schneller vor allem mit der ET4000 Grafikkarte. Nicht wahnsinnig schneller aber etwas schneller, mir reicht das erstmal so ...
Meine PAK68/2 läuft ja nicht, ich habe keine Lust den Fehler zu suchen. So groß wird der Unterschied zu den 16Mhz und dem 32-bit breiten TOS nicht sein. Es gibt ja auch noch die Möglichkeit den Mainboard Takt von 8Mhz auf 12Mhz anzuheben. Hatte das damals mal gemacht und das geht wunderbar und läuft sehr stabil ...
-
Der Formfaktor der original Platine gefällt mir wegen ihrer Kleinheit wegen besser, der Neuen fehlt der Schnuckelfaktor.
So wie bei der Janus020 Karte mit SMD MC68020. Bei der CPU fehlen aber Steuersignale ...
-
Doch, der Unterschied zur PAK 68/2 ist gewaltig. Die ist in den meisten Disziplinen etwa doppelt so schnell.
-
Man müsste sich GEMBench angucken, um zu sehen, wie dort RAM- und ROM-Zugriff gemessen werden. Wenn Instruktionen zum Einsatz kommen, die -- unabhängig vom Speicherzugriff oder einem evtl. aktiven Cache -- auf einem 68020 einfach weniger Taktzyklen brauchen und diese Instruktionen einen ausreichenden Anteil an der Gesamtmesszeit haben, dann sieht man in dem Benchmark nicht etwa einen beschleunigten Speicherzugriff sondern (nochmals) die andere CPU.
Wenn man den 256byte Cache abschaltet sind die RAM Und ROM Zugriffe wieder bei ungefähr 100% ...
-
Naja, wie Du schon schreibst: "Alle Benchmark Programme sind irgendwie Mumpitz ..."
Der On-Chip-Cache des MC68020 ist ein reiner Instruction Cache, cachet also nur Programmcode und keine Daten. Wenn der Benchmark nun in einer kleinen Schleife läuft, passt der Code der Schleife aber komplett in den Cache und Du siehst nicht etwa schnellere Datenspeicherzugriffe sondern nur die schnellere Ausführung des Codes aus dem Cache.
-
Doch, der Unterschied zur PAK 68/2 ist gewaltig. Die ist in den meisten Disziplinen etwa doppelt so schnell.
Ein Sprung wäre für mich der Unterschied zwischen ST und TT. Also eine PAK68/3 mit 030iger und 32 oder 50Mhz. Doppelt so schnell ist nicht allzu viel mehr. Mein Grund für den 020 ist MiNT ...
-
Meine PAK68/2 liefert etwa die selben Werte wie ein Falcon, beide jeweils in ST-Hoch und ohne NVDI etc. gemessen. Der Falcon ist nur geringfügig schneller, wegen des besseren Caches im 030er.
-
Habe jetzt einiges ausprobiert und alles gut soweit bis auf die MonSTer und zwar funktioniert das FlashTOS und die 8MB Alternate/Fastram aber am IDE Bus werden keine Geräte gefunden. Mit ACSI alles wunderbar. Alan bekommt eine Karte von mir vielleicht kann er da etwas dran machen, mal schauen ...