atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Arthur am Mo 04.02.2013, 01:38:54
-
Es gibt zumindest für die STs 16MHz Beschleuniger (http://atari4ever.free.fr/) zum selbst bauen (DIY). Hat das schon wer gemacht und was kommt dabei unterm Strich heraus? Gibt es das auch mit Cache als DIY Projekt? Wer hat schon Benchmarks von so einem Projekt gemacht?
-
In irgendeinem 1040ST habe ich so ein ganz primitives Ding drin, was den Takt auf 16 MHz anhebt, wenn der Prozessor in der Befehlsausführung ist, sprich gerade nicht auf RAM, ROM oder IO zugreift. Auswirkungen: Nicht wirklich bemerkbar.
-
... ohne L2 Cache lohnt das nicht !
-
Wenn ich meine STs mit dem Mega STE vergleiche: viel Unterschied in der Geschwindigkeit spüre ich eigentlich nicht! Zusätzliche Problematik: viele (Ältere) PRGs scheinen unter 16MHz Schwierigkeiten beim Bildaufbau zu haben!
-
Ich hatte mir damals mal einen Atari Mega ST4 mit 12Mhz Busspeed umgebaut indem ich den Hauptquarz
gegen einen 48Mhz Quarz ausgetauscht habe und diverse Bauteile extra mit den richtigen Taktraten
versorgt habe ...
Da die Geschwindigkeit allerdings nicht ausreichend war habe ich noch eine
PAK68/2 (24Mhz 68020+FPU /TOS 2.06) obendrauf gesetzt ...
Hauptquarz = 48Mhz
Zusätzlich einen 16Mhz Quarz verbauen (mit 74x74 runterteilen)
16Mhz = Floppy HD
8 Mhz = Floppy DD
4 Mhz = Soundchip
2 Mhz = Soundchip
500Khz = beide 6850 Bausteine
Mein Rechner hatte keinerlei Probleme mit den hohen Taktraten (Shifter/MMU/GLUE etc.), allerdings
muss der Monitor mehr als 90Hz verkaften können ...
-
Wenn ich meine STs mit dem Mega STE vergleiche: viel Unterschied in der Geschwindigkeit spüre ich eigentlich nicht! Zusätzliche Problematik: viele (Ältere) PRGs scheinen unter 16MHz Schwierigkeiten beim Bildaufbau zu haben!
Probleme machen nicht die 16Mhz sondern der 16kB L2 Cache ...
-
Ob es alleine der 16 kB Cache ist, kann ich nicht wirklich bestätigen. In der ersten Ausbaustufe meines Towers hatte ich einen 520ST drin, und da war ein HBS-240 drauf (68000-16 mit 16kB Cache und FPU), das war sehr kompatibel, soweit ich mich erinnere musste ich den eigentlich nie abschalten. Das Abschalten kam erst als ich die Pak 68/2 auf dem 1040ST Board im Tower eingebaut hatte, da gabs dann vereinzelte Programme, die mit dem Cache nicht zurecht kamen, teils waren das Darstellungsfehler, teils auch Abstürze mit Bomben, hier taten sich insbesondere zwei Sounddemos mit Samples des TOS-Magazins hervor.
Der HBS-240 hat sich Performance-mäßig einigermaßen bemerkbar gemacht, etwa wie ein Mega-STE eben, aber kein Vergleich zur Pak, mit der ich bei nornmalen Anwendungen etwa die selben Performance-Werte wie mit einem Falcon erreichte.
Da ich aber damals meistens reine ST-Anwendungen nutzte, war die CPU-Beschleunigung nur selten bemerkbar, da ja eigentlich alle Anwendungen auch auf einem 8MHz ST vernünftig laufen sollten. In Calamus habe ich aber die Beschleunigung durch den HBS-240 bzw. erst recht durch die PAK bemerkt, und auch beim Autorouting in PCB-Edit. Was meistens mehr brachte, war wen ein Autor sich die Mühe machte, zeitkritische Sachen statt in Hochsprache in Assembler handoptimiert auszuführen, bei Sparrow-Text war das von Version zu Version beeindruckend festzustellen, so Sachen wie "Suchen & Ersetzen", In große Dokumente Text am Anfang einfügen und so. Sparrow war größtenteils in GFA programmiert, aber zeitkritische Sachen in Assembler.
-
Probleme machen nicht die 16Mhz sondern der 16kB L2 Cache ...
Weil ältere TOS-Versionen nichts vom Cache wissen, kann und darf der (es ist kein modifiziertes TOS oder ein AUTO-Ordner Programm dabei, oder?) eigentlich nur im "write through"-Modus betrieben werden - d.h. jeder schreibende Zugriff auf den Hauptspeicher schreibt in den Cache und ins Main Memory (bzw. nur in den Hauptspeicher und der Cache wird ungültig markiert).
Probleme können dann eigentlich nur noch DMA-Geräte (Floppy, HD, Blitter) bereiten, die vom Cache nichts wissen. Noch ältere TOS-Versionen (vor 1.4, soweit ich mich erinnere) enthalten Zeitschleifen, die von der Prozessorgeschwindigkeit abhängig sind. Die dürften aber gar nicht laufen, denke ich.
-
Hauptquarz = 48Mhz
Zusätzlich einen 16Mhz Quarz verbauen (mit 74x74 runterteilen)
16Mhz = Floppy HD
8 Mhz = Floppy DD
4 Mhz = Soundchip
2 Mhz = Soundchip
500Khz = beide 6850 Bausteine
Mein Rechner hatte keinerlei Probleme mit den hohen Taktraten (Shifter/MMU/GLUE etc.), allerdings
muss der Monitor mehr als 90Hz verkaften können ...
Das ist ja interessant und eine schöne Möglichkeit. Die heutigen TFT Displays sollten doch noch damit klar kommen, oder muß ich meinen CRT behalten? Der Atari dürfte dann so um die 50% schneller sein?
-
http://www.stcarchiv.de/stc1992/09_gehtdoch.php
-
Hallo Frank, den Artikel kenne ich natürlich. Ich hab dich jetzt so verstanden das es nur mit ein paar Oszillatoren auch getan ist. Hab ich das jetzt falsch verstanden? Zu so einer Aktion fehlt mir gerade die Zeit und das Zeugs.
-
Hallo Frank, den Artikel kenne ich natürlich. Ich hab dich jetzt so verstanden das es nur mit ein paar Oszillatoren auch getan ist. Hab ich das jetzt falsch verstanden? Zu so einer Aktion fehlt mir gerade die Zeit und das Zeugs.
... so wie ich das aufgeschrieben habe funktioniert es.
Allerdings vertragen TFT Bildschirme die zwischen 90-100Hz der ST-Hoch Auflösung nicht denke ich mir.
http://forum.atari-home.de/index.php?topic=10116.msg74322#msg74322
-
Also der TFT hat 75KHz Zeilenfrequenz...und bei 640*400 Pixeln wärs schon schön wenn er das noch darstellen könnte sonst halt mit CRT (96KHz).
-
... meine TFT Bildschirme machen nur entweder 50, 60 oder 75 Hz egal bei welcher Auflösung.
-
Schön wärs ja, wenn das mit nur einem Oszillator und einem GAL ginge der dann daraus die notwendigen Frequenzen erzeugt so dass man evtl. zwischen turbo und normal per Schalter oder auch Software auswählen könnte.
-
ich bin dran... ;)
Geplant:
16MHz mit doppelt so schnellem Speichertakt aber gleichzeitig mit Standard-Auflösung/Refresh des Monitors.
Da die MMU/CPU/RAM komplett synchron getaktet werden, sollte sich ein guter Geschwindigkeitszuwachs bemerkbar machen. Das ganze mit GAL und Schalter/Software...
Optional, während der Befehlsausführung (/AS) mehr Takt, um es synchron zu halten, ggf. 24MHz. Aber dann wirds aufwändiger, da nur mit Cache das was bringt...
Fortschritt:
Alte CPU muss raus!!! es muss definitiv ein 16MHz auf Sockel. Speicher muss getauscht werden, da meistens zu langsam. Das habe ich mit einer 4MB Erweiterung verbunden. Funktioniert warscheinlich nicht mit Speichererweiterungen aus SIMMs oder Drahtverhau. Tauschen der RAM-Chips oder Huckepack wäre sinnvoll.
TOS Roms könnten zu langsam sein, es sollten schnellere ROMs her, am besten FLASH in Verbindung mit einem ROM update auf 2.06 (z.Z. in Arbeit). Z.Z. meckert in meinem 1040ST (oder besser 4096ST) der Blitter mit 16MHz rum. 8MHz für den Blitter wären eine Option, aber so schnell gebe ich nicht auf... :)
Mal gucken...
Gruß HW
-
Zur Info: Meine 16 MHz PAK68/2 "blittert" schneller als der 8 Mhz Blitter. Ich hatte damals meine 1040ST-Platine so umgebaut, dass der Blitter drin läuft, und nach ersten Tests mit der Pak und GEM-Bench habe ich ihn wieder ausgebaut.
-
ich bin dran... ;)
Geplant:
16MHz mit doppelt so schnellem Speichertakt aber gleichzeitig mit Standard-Auflösung/Refresh des Monitors.
Da die MMU/CPU/RAM komplett synchron getaktet werden, sollte sich ein guter Geschwindigkeitszuwachs bemerkbar machen. Das ganze mit GAL und Schalter/Software...
Optional, während der Befehlsausführung (/AS) mehr Takt, um es synchron zu halten, ggf. 24MHz. Aber dann wirds aufwändiger, da nur mit Cache das was bringt...
Funktioniert bei einem alten 520ST bei mir bzw. hat vor 10 Jahren funktioniert. Allerdings musste ich ihn immer mehrmals ein-ausschalten bis das Bild am SM124 ruhig war, da es am linken Bildschirmrand immer zu Shifterzucken kam.
Bringt dann 200% Leistung. Geht am besten mit ganz alten Chipsätzen. IMP kann man knicken.
Viel Erfolg.
-
Speicher muss getauscht werden, da meistens zu langsam. Das habe ich mit einer 4MB Erweiterung verbunden. Funktioniert warscheinlich nicht mit Speichererweiterungen aus SIMMs oder Drahtverhau. Tauschen der RAM-Chips oder Huckepack wäre sinnvoll.
Der Speicher sollte nicht langsamer als 80ns sein.
Ich habe (oder hatte) ein Mega-Board im Keller mit 80ns Rams, dürfte aber die Ausnahme sein. (Leider ist das Board defekt.)
Simm-Erweiterungen und Kabelgewurstel mit PS/2-Simms haben das Problem der ewig langen Signalleitungen.
Huckepack würde ich nicht machen, da dabei der Stromverbrauch unnötig hoch geht oder die Signalleitungen belastet werden.
TOS Roms könnten zu langsam sein, es sollten schnellere ROMs her, am besten FLASH in Verbindung mit einem ROM update auf 2.06 (z.Z. in Arbeit).
Ich denke das die ROMs immer zu langsam sind. Eproms unter 100ns sollten kein Problem sein zu finden.
Bei Flash ist es kein Problem schnelle zu finden.
Z.Z. meckert in meinem 1040ST (oder besser 4096ST) der Blitter mit 16MHz rum. 8MHz für den Blitter wären eine Option, aber so schnell gebe ich nicht auf... :)
Der Blitter ist mit 8MHz ein Bremsklotz, den würde ich enfernen wenn er nicht mit 16MHz will.
-
So, hier mal ein paar Fotos:
z:Z. ist der Blitter mit 8MHz betrieben:
(http://img3.fotos-hochladen.net/uploads/stbild1qcaf28gedh.jpg)
(http://img3.fotos-hochladen.net/uploads/stbild2dvmcnt5oar.jpg)
Der Blitter ist mit 8MHz ein Bremsklotz, den würde ich enfernen wenn er nicht mit 16MHz will.
Mir ist aufgefallen, das trotz 8MHz am Blitter die Displayperformance deutlich besser ist, als ohne Blitter
mit einem Systemtakt von 16MHz.
Damit kann ich der Aussage, das der Blitter mit 8MHz ein Bremsklotz ist, nicht bestätigen (zumindest bei 640x200).
Gruß HW
-
Das sieht doch schick aus :)
Vllt. krieg ich meinen 16MHz 520ST wieder in die Gänge zum Vergleich. Der hat aber keinen Blitter. Hatte ihn früher mit CoMa als AB/FAX im Einsatz. da war - glaube ich - auch eine 2.5" HDD drin...
-
Nett... Ein solchermaßen getunter 520er würde mir auch gefallen.
-
So, hier mal ein paar Fotos:
z:Z. ist der Blitter mit 8MHz betrieben:
(http://img3.fotos-hochladen.net/uploads/stbild1qcaf28gedh.jpg)
(http://img3.fotos-hochladen.net/uploads/stbild2dvmcnt5oar.jpg)
Der Blitter ist mit 8MHz ein Bremsklotz, den würde ich enfernen wenn er nicht mit 16MHz will.
Mir ist aufgefallen, das trotz 8MHz am Blitter die Displayperformance deutlich besser ist, als ohne Blitter
mit einem Systemtakt von 16MHz.
Damit kann ich der Aussage, das der Blitter mit 8MHz ein Bremsklotz ist, nicht bestätigen (zumindest bei 640x200).
Gruß HW
Der ist ja viel schneller als der Mega STE. Dieser erreicht bei mir 124% im Display- und 196% im CPU- Test.
Einige Einzelwerte:
GEM Dialog Box 4,710 zu 3,120
VDI TEXT 5,230 zu 3.090
Blitting 1.320 zu 1,050
Float Math 7,200 zu 6,595
16Mhz, Cache, Blitter, selbe Auflösung und Referenzwerte wie bei dir wahren natürlich eingestellt.
Woran liegt das? Ist TOS 2.06 langsamer als 1.02?
-
Er schrieb doch, dass er den Bustakt auf 16MHz angehoben hat!
-
ach so, lesen müsste man können :-[
-
Hallo HW, die Ergebnisse sind für mir absolut ausreichend. Wie hast Du das Problem mit den zu hohen Bildfrequenzen in SW beheben können? Oder blieb dort die Frequenz unangetastet?
-
@Ryo:
Der ist ja viel schneller als der Mega STE.
Um nochmal kurz den Unterschied zu erläutern. Wärend im MegaSTE der Bus weiterhin mit 8MHz läuft, nur die CPU in den I/O freien Cycles mit 16MHz läuft, fallen alle Buszugriffe recht langsam (normal wie bei 8MHz) aus. Um nun der CPU die Chance zu geben, doch noch einigermassen Performance zu liefern, wird der CPU ein Cache vorgeschaltet. Dieser kann bei Zugriffen auf den Speicher, welcher schon einmal zuvor stattgefunden hat, diese Werte viel schneller liefern, ein sogenannter Cache-Hit. Bei linearen Zugriffen funktioniert das natürlich nicht. Übrigens sind alle "Aufsteckbeschleuniger" so aufgebaut, also erreichen die gleiche Performance bei 16MHz wie der MegaSTE.
Meine Lösung taktet ALLES auf 16MHz, d.h. auch die MMU. Somit ist rein theoretisch wirklich bei allen Messungen 200% zu erwarten, auch ohne Cache. Einzig der Blitter bekommt 8MHz, weil dieser mit 16MHz wirklich nicht läuft.
Anders als bei den anderen Lösungen muss hier darauf geachtet werden, das alles schnell genug ist, also CPU, RAM, TOS-ROMs und es sollten möglichst keine IMS-Setups verwendet werden, da diese zu langsam sein sollen (hab ich so gelesen, geprüft ist diese Aussage von mir nicht). Weiterhin sollten die Address-PullUps verkleinert werden (es sind teilweise 10kOhm verwedet worden, was viel zu gross ist 4,7 - 3,3k sollten es schon sein.
Anbei mal ein Screenshot mit abgeschalteten Blitter. Dort kannst du gut erkennen, das der ST genau doppelt so schnell ist.
(http://img3.fotos-hochladen.net/uploads/stbild3jy4mp6a72n.jpg)
@ arthur:
Hallo HW, die Ergebnisse sind für mir absolut ausreichend. Wie hast Du das Problem mit den zu hohen Bildfrequenzen in SW beheben können? Oder blieb dort die Frequenz unangetastet?
Das ist ganz einfach. ich bremse die Shifter-Zugriffe der MMU auf den Speicher einfach aus. Das mache ich mit einem VerUNDen eines 2MHz Taktes(z.B. vom GLUE) mit der DE Leitung der MMU. Somit muss die Bildschirmausgabe gezwungenermassen mit der Hälfte des Bildschirmtaktes ausgelesen werden, was genau dem Original entspricht. ;)
Übrigens funktioniert das soo gut, das ich sogar eine FBAS-Ausgabe (Compsite) in PAL störungsfrei ausgebe. Auch so eine kleine Mod von mir, ich habe den FM-Modulator "operativ" entfernt und die Beschaltung auf dem Mainboard so abgeändert, das jetzt parallel zur ST-RGB Ausgabe auch ein Composite-Ausgang am Modulator-Ausgang verfügbar ist. Beide Signale beeinflussen sich nicht, da die Ausgaben getrennt verarbeitet werden. Alle Screenshots sind auch auf einem kleinen TFT-Monitor über Composite gemacht. :)
Ich werde aber dieses Projekt wahrscheinlich abbrechen, bzw. erstmal auf Eis legen und an einem 1040STE weiter machen, den ich hoffentlich die Tage bekomme.
Hat jemand Interesse, an dem ST weiter zu machen?
Gruß HW
-
D.h. Du trennst die 16MHz-out-Leiterbahn vom Shifter auf und führst dort auch 32MHz zu. Und die CLK zum Blitter muss auf 8MHz umgelegt werden?
Hättest Du Interesse das mal als Schaltplanergänzung zu zeichnen. Wäre für die Nachwelt sicher interessant.
Ich weiss nicht mehr, wo ich meine Schaltung her habe. MAUS Net nehme ich an...
Was meinst Du mit:
keine IMS-Setups verwendet werden
bye, Arne
-
D.h. Du trennst die 16MHz-out-Leiterbahn vom Shifter auf und führst dort auch 32MHz zu. Und die CLK zum Blitter muss auf 8MHz umgelegt werden?
Ja, und es muss auch die Peripherie mit 8MHz versorgt werden, prinzipiell hat ja der 8MHz Ausgang von der MMU nun 16. Dieser geht zur CPU, dazu muss dann dieser Takt noch runtergeteilt werden auf 8MHz und versorgt dann den Rest des Boards. Alternativ ginge auch der 4MHz-Ausgang der MMU, da dieser jetzt 8MHz hat. Dieser scheint aber zu schwammig zu sein. Jetzt noch das DE Signal ausbremsen, fertig. In der Theorie schon, leider sind die Signale zu schwammig, um sie so zu verwenden. ein Leitungstreiber mus an diversen Stellen verwendet werden. Ich pusche mit einem 74F04 die 32MHz vom Quarz, treibe dann mit einem Gatter 2 weitere und führe sie dann dem Shifter bzw. der MMU zu. All solch kleine Tricks, und ich bin immer noch nicht soweit zu sagen, das ist alles super stabil und so kann das jemand nachbauen. Ich veröffentliche erst, wenn ich sicher bin, das alles funktioniert. So hab ich das auch damals beim HW4711 Beschleuniger für den Falcon gemacht, übrigens läuft dieser immer noch einwandfrei. ;)
Was meinst Du mit:
Zitat
keine IMS-Setups verwendet werden
Ich meinte IMP-Setup (vertippt). Dieser wurde viel in den neueren Mega-ST verbaut und sollen nicht so übertaktungsfest wie die Orginal-Motorola-ICs sein. Bestätigt oder dementiert ist das von mir aber noch nicht.
Hier mal ein Bild mit dem aufgedruckten Label IMP:
(http://i.ebayimg.com/t/Atari-520-1040-ST-STF-STFM-Mega-ST-computer-motherboard-GLUE-IC-chip-TESTED-OK-/00/s/OTg1WDEwMjQ=/z/weYAAMXQM6ZRFVYM/$T2eC16Z,!yEE9s5jGKMBBRFVYL6eHw~~60_35.JPG)
Gruß HW
-
Stimmt. Vieles muss ja den "Originaltakt" bekommen: FDC, sonst mag er nur noch HD-Disks, PSG, sonst kriegt er ne Fistelstimme usw.
Den Umbau bei meinem habe ich glaube ich irgendwo als ASCII Art. Beim SM124 gab es dann nach dem Einschalten oft links am Rand ganz helle Striefen vertikal, als wenn das Bild nach links hinten "wegklappen" würde. Da half nur mehrmaliges On/Off bis es weg war. Dann war es aber bis zum nächsten Einschalten weg. Hast Du das auch?
PS. ja, die IMP sind untauglich. Zumindest die, die ich in meinem 520 getestet hatte - da ist ja noch vieles gesockelt. Blittersockel hatte der natürlich nicht - daher kann ich hierzu nix sagen.
Aber toll, dass Du Dir die Mühe machst.
Wo hakts denn noch?
Gruß, Arne
-
Hallo Hanswurst4711, kann verstehen wenn Du den STE lieber tunen möchtest aber evtl. kannst Du ein paar ST Infos und Bilder von deinem ST-Tuning veröffentlichen da ich meinen "Super ST" unbedingt auf 16MHz beschleinigen möchte bzw. es damit versuchen möchte.
-
Mein 16MHz 520 ist recht "gerupft". Weiss nicht, ob ich den nochmal zum Laufen kriege. Aber ich hatte mir damals die Mühe gemacht eine Platine zu routen. Sind nur drei 74xx TTL drauf plus bischen Rs und Cs.
ScooterPCB ist ja jetzt "Freeware", könnte bei Interesse die Anleitung und das Layout mal rauskramen.
-
Hallo Arne, das wär ja schön dann könnte man Scooter PCB ja sofort sinnvoll nutzen. ;)
-
So, anbei zwei ZIPs (PDF in ZIP umbenennen).
16MHZ.ZIP:
Der 16MHz Boardtakt-Umbau. Die ScooterPCB Platinen in unterschiedlichen Layoutstadien.
Dann hatte ich mal Platinen für das ST-Computer 10/12MHz Projekt machen lassen. Die sind im ZIP 12MHZ.ZIP.
Herrn Kahlert ist allerdings aufgefallen, dass die Bohrdurchmesser der Makros der ST-Version teilweise nicht stimmen (z.B. IC Sockel haben in Scooter 0.4mm Bohrdurchmesser, müssen aber 0.6mm haben).
Die PC Version von Scooter hat die korrekten Makros, allerdings kann die ST Version die PC Makros nicht lesen.
-
Die IMP's sind qualitativ identisch man sollte beim Shifter und DMA aber die zusätzliche Diode (http://phoenix.inf.upol.cz/~opichals/libhyp/hypview.cgi?url=atmarita.de%2Fstartseite%2Fimages%2Fchips%2FCHIPS_X.HYP&index=29&line=9#line9) nicht vergessen.
Muss mir nur noch Scooter installieren dann schau ich mal in deine Pläne rein. Viele Dank fürs posten.
-
Die IMP's sind qualitativ identisch (...)
Du meinst sicherlich damit, dass alle IMPs gleich schlecht sind, gelle. ;D
Falls Du aber der Ansicht sind IMPs sind qualitativ identisch zu nicht-IMPs.... dann bist aufm Holzweg.
Hab gestern mal in die Anleitung zur HBS640 geschaut. Da wird auch extra auf IMP eingegangen...
Wie gesagt. Hab mir damals extra einen alten 520ST besorgt, da die alten Chipsätze sich am besten übertakten ließen. War - gleube ich - im MAUS Net eine Diskussion drüber.
-
Hallo Arne, ich beziehe mich auf die Chips 'n Chips.
Der C100110-001 DMA-Chip soll nur in verbindung mit dem GLUE Chip
(ebenfalls der Firma IMP) eingesetzt werden, die IMP Chips sind
keinesfalls schlechter als die nicht IMP Chips, sie sind aber mit
einer anderen Technologie (Fertigungsprozess) produziert worden.
Weiterhin muss jeweils zwischen dem Pin 40 des DMA Controllers und
des Videochips eine Diode eingelötet sein, weil die Chips am besten
mit einer ~4.5 Volt Versorgungsspannung arbeiten!
Und hab mit den IMP's selbst auch keine negativen Erfahrungen gemacht. ;)
-
Im Normalbetrieb machen die IMP-Chips auch keine Probleme (außer wenn gewisse kleine Hardwaremodifikationen wie die von dir zitierte nicht gemacht werden) aber die lassen sich nicht mit mehr als 8...10 MHz takten.
-
Im Normalbetrieb machen die IMP-Chips auch keine Probleme (außer wenn gewisse kleine Hardwaremodifikationen wie die von dir zitierte nicht gemacht werden) aber die lassen sich nicht mit mehr als 8...10 MHz takten.
schrieb ich ja bereits. In der HBS640 Anleitung steht, dass man idealerweise IMP MMU mit IMP DMA kombiniert + Diode. Wie lötet man die denn bitte an MMU/Glue an? :o
IMPs laufen in einem Standard ST ohne AddOns ausreichend gut. Aber wehe man baut einen Speeder ein. PAK68/3 mit nem IMP sauber zum Rennen zu bringen? Na, ich weiss ja net...