atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: guest2980 am Di 06.12.2011, 09:49:34
-
Selbstbaubeschleuniger für den Falcon - HW4711-Edition
Hallo Fans des Falcon, und Interessierte, die eben diesem tollen Gerät Beine machen wollen.
Ich brauche nicht zu erwähnen, das es unverständlich war, warum Jahre nach dem TT wieder ein 16Mhz Design eingesetzt wurde. Und viel schlimmer noch, das der Datenbus auf 16bit kastriert wurde. Das bremst das gute Stück ordentlich aus.
Daher wurde auch bei mir der Wunsch groß, diesen mit einfachen "Hausmitteln", also einfachen Kniffen ein wenig mehr Performance einzuhauchen. Leider sind (damals) käufliche Speeder nur noch selten zu bekommen, oder diverse Selbstbauprojekte sind wirklich schlimme Bastellösungen, die (so durfte ich auch erfahren) nur vom Aufbau her !irgendwie! funktionieren und sehr instabil sind. Daher habe ich mich selbst dran gemacht, etwas zu bauen, was erst mal sicherer läuft (also besser nachgebaut werden kann) und nicht so hardwareintesiv ist.
Dabei rausgekommen ist eine Lösung, die für manche bestimmt interessant sein dürfte...
Ist-Zustand:
Falcon Rev.C mit 14MB (60ns) von Bernd Thomas (danke nochmal),
neuer TOS-ROM Baustein mit 55ns, 68882 FPU mit 33MHz.
Ziel:
Beschleunigung des Busses und der CPU in normalen Grenzen (also bis 20/40Mhz) und der Speicher und das
TOS-Rom OHNE Waitsates!!!!! Wir wollen ja dem TT Paroli bieten und mit 16Bit-Bus ein Handicap!
Version 1 (nicht weiter verfolgt):
Ich habe mich an Peter Green's Anleitung gehalten und mit div-Gattern eine Umschaltung des Busses von 16 auf 18 oder 20 oder mehr Mhz realisert. Weiterhin wurden Tests gemacht, die CPU in ihren Zeiten ohne Buszugriff auf das doppelte, also 32Mhz und mehr zu takten. Fazit: Lasst es, und das ist wirklich ein gut gemeinter Rat. Alle Lösungen sind total instabil und können nicht sauber nachgebaut werden. Die Timings auf dem Board sind einfach zu eng und kritisch, da ist solch eine Lösung nicht sauber realisierbar. Auch die Meinung anderer, das die Beschleunigung erst nach dem Booten aktiviert werden darf (also es muss alles beim Einschalten des Falcon ausgeschaltet sein), ist absoluter Quatsch. Da zeigt sich, das der Aufbau viel zu wackelig ist und nicht vernünftig läuft. Meine Version 2 kann auch komplett aktiviert sein (fest auf 1 gelötet) und trotzdem bootet die CPU bei 40MHz!!!)
Version 2 (aktuell):
Da es mit Version 1 zu niederschmetternden Ergebnissen kam, musste etwas her, was a) einfach zu realisieren ist, b) gut integrierbar ist (also keine fliegenden Lochrasterkarten usw.) und c) erweiterbar ist. Ich habe mich nach langem hin und ging meine Wahl an eine (veraltete) GAL-Technik, die zwar betagt ist, aber einige Vorteile bietet. Als DIL-Version kann er Huckepack wie der Clockpach aufgesetzt werden und ist platzsparend, keine externe Bauteile (bis auf den Quarz notwendig) und die Signallaufzeiten sind berechenbar. Die Wahl ging an ein Lattice GAL22V10D-7xx. Dieser ist mit 7ns ausreichend schnell, kann den Clock-Patch durch Push-Pull Outputs ersetzen und er hat Aufgrund seiner Bauform einige Vorteile (dazu komme ich noch) und er war eben auch einfach DA! :-D
Aufbau:
Im Prinzip ganz einfach, JED-File einflashen und dann alle ungenutzten Pins soweit abkneifen, sie sollen ja kein
Kurzschluss machen. Pin 10,12 und 24 auf jeden Fall ganz lang lassen, diese werden Huckepack anstatt des Clock_patch eingesetzt.
Pinbelegung:
2 - 16 Mhz Clock vom COMBEL
3 - Keyboard-ACIA Pin 5
4 - MIDI-ACIA Pin 5
5 - GAL U68 Pin 16
10 - GND vom GAL dadrunter
11 - 40MHz Quarz Clock
12 - GND muss mit dem Pin 10 gebrückt werden.
13 - 32MHz Clock vom Board - zuvor L102 entfernen und rechts anlöten
15 - Board-Clock Ausgang - L102 links anlöten (alternativ ginge auch R234)
17 - DMA-Clock Ausgang
19 - CPU-Clock Ausgang
21 - FPU-CLock Ausgang
23 - Ext. Clock Ausgang
24 +5V (VCC)
Aufbau wie auf den Bildern zu sehn, der Kondensator (wie auf dem Bild zw. 100n und 1uF, wichtig Vielschicht) muss zwingend eingesetzt werden, da die Signale sonst zu unsauber werden. Auch empfiehlt es sich, den GND-Pin 12 zusätzlich mit dem GND-Rand der Platine zu verbinden. Wichtig beim Aufbau, und das meine ich wirklich ernst, Kurze Leitungen nehmen, möglichst Drähte, keine Litzen!!! Über die Clock-Leitung sitzt bei mir noch eine Ferrite-Perle, diese verzögert das Signal um 1-2ns, ausreichend, das Timing zu stabilisieren! der ausgelötete Ferrit (L102) kann in der DMA-Leitung Paltz finden, da diese Leitung extrem gebeutelt wird (hab ich nachgemessen, muss aber nicht, signal ist aber sauberer da weniger Reflexionen). Im ganzen ist mein Board (rev.C) sehr unsauber design't, viele Reflexionen, gerade die Lange Leitung von der FPU/DMA machen Probleme.
Das war's auch schon. Bitte beachtet, der ACIA-Patch und die seperate SDMA-Clockleitung setze ich vorraus.
Siehe hier: http://forum.atari-home.de/index.php?topic=8412.0
Die 500kHz erzeuge ich mit einem HEF4024 im SO-Gehäuse und findet super auch Huckepack auf einem weiteren SMD-Baustein Platz (U57 siehe Bild). Der Quarz sollte neben dem RTC platz finden. So ist alles gut verstaut und sollte auch auf Anhieb funktionieren. Das auf der CPU ein Kühlkörper sitzen sollte, ist klar. ACHTUNG: diese Anleitung ist natürlich nur für versierte Bastler die wissen was sie tun. Weiterhin gebe ich keine Garantie auf die Angaben und ich komme auch nicht für irgendwelche Schäden auf. Jeder sollte sich sicher sein, was er da tut und da auch das Netzteil offen liegt, bitte ich um große Vorsicht, da Netzspannung gefährlich ist.
Ergebnis:
In meinem Aufbau verwende ich einen 40MHz Quarz, der Bustakt ist 20MHz und der CPU-Takt wird verdoppelt. Die FPU läuft immer mit 32/40MHz.
Zum Schalten der Modi verwende ich die Nemesis-Tools oder vergleichbare, die zum Schalten die Pin 5 der ACIA's verwenden... (siehe anderes Problem: http://forum.atari-home.de/index.php?topic=9037.0 )
Hier die Fotos und Ergebnisse mit dem GEMBENCH 4.03 (NVDI ist installiert).
(http://www.fotos-hochladen.net/uploads/bild1rngeu38hv1.jpg)
(http://www.fotos-hochladen.net/uploads/bild2nrjhbe9dvt.jpg)
(http://www.fotos-hochladen.net/uploads/bild3lge2647wbx.jpg)
Es kann ja mal jemand die Ergebnisse vom TT posten, um das mal zu vergleichen ;)
Ich hoffe, Euer erneutes Interesse geweckt zu haben...
Viel Glück (HW)
-
Hallo HW,
das ist ja eine eine super Idee das als Huckepackversion im schnellen GAL zu implementieren und den Cockpatch gleich mit zu ersetzen. Hattest Du auch schon Test's mit diversen Audiprogrammen gemacht...? Viele haben nach dem Einbau eines Beschleunigers in den Falcon Probleme mit der Soundausgabe bekommen. Schon jetzt kann ich für mich behaupten das es in meine persöhnliche Hardware-Ruhmeshalle kommt. ;D
-
@arthur:
ja, klar... die DSP-Ausgabe ist z.T. gestört, daher sollte ja das Design per Software deaktivierbar sein.
Ich hatte das so aufgebaut, das automatisch bei Start der Midi-Ausgabe über Cubase 2.06 der Midi-Port die Busübertaktung abschaltet, jedoch nicht die Verdopplung des CPU-Taktes. Das ergibt eine etwas reduziertere Beschleunigung aber geht bezüglich der DSP-Ausgabe auf Nummer sicher ... :) Das funktioniert auch ausgezeichnet...
Ich werde mich nun diesem Problem annehmen, ich hoffe hier auch auf eine praktikable Lösung. das Einlöten des Widerstandes gegen GND ist wohl doch nur ein "dirty fix".
Hier nochmal eine Anmerkung bzgl. SDMA von Czuba, gefunden hier:
http://forum.atari-home.de/index.php?topic=1823.0
During this last 10 years, everybody heart about 'cracks' on audio or SCSI/floppy data problems, especially when boosting the mb. Atari furnished a patch with a 74F08 onto the GAL U63 to bufferize the bus clock going to 3 directions, especially the SDMA, and this on standard falcons. This patch was called 'Cubase clock modification' for those who had to install it.
OK, after several month passed several years ago on CT2 to fix this problem, I was not sure to know the real raeson of the problem. Every body (and atari) was thinking that the bad quality of the clock to SDMA was the cause of the problems (so the 74F08 fitting).
But after using the 200 MHz logic analyser I can reveal that the first reason is a big bug into the VIDEL chip ! Some times the data arrive later (Videl switches the 32-bit memory bus to the 16-bit CPU bus) and because the timing to latch the data from SDMA is very short, some data are missed !
All the patchs like 74F08, nemesis termination with resistor on SDMA clock trace are not perfect at all ! Their just modify the edge of the clock and allow to win 1 or 2 ns when latching the data ! But the bug into VIDEL is depending too of the Video resolution you use and the temperature of the machine !
I now design a patch that will simply add a Wait State to the SDMA transfer to be sure that it latches the data when really present & stabilized on the data bus
Daher frage ich mich die ganze Zeit schon, den DMA-Controller mit konstant 16MHz zu takten, anstatt mit 18 oder mehr. Da die Daten gelatcht werden, sollte das Speichertiming nicht so kritisch sein, oder denke ich falsch???
Gruß HW
-
Hallo Falcon-User, ein frohes und gesundes 2012,
gleich zu Beginn des Jahres möchte ich mein o.g. Projekt aktualisieren. Bzgl. der typischen DMA-Probleme bei Übertaktung des Systembusses auf >16MHz, habe ich mich die letzten Wochen damit nochmals auseinander gesetzt und bin auch zu wirklich guten Ergebnissen gekommen.
Version 3:
Wie Ihr auf den Bildern sehen könnt, wurde die Beschaltung des GAL's noch etwas vergrößert (hauptsächlich die innere Logik ist erweitert) worden. Weiterhin sind nun einige andere Features dazugekommen, zusätzlich ein 2ter Clock mit 36Mhz, sodass die Beschaltung dem Nemesis-Beschleuniger entspricht.. also LO=18/36MHz und HI=20/40Mhz. Weiterhin kann mit dem Skunk-Tool NUR die CPU-Taktverdopplung bei 16MHz Bus eingeschaltet werden, wenn das mal nicht kompatibel ist... Mehr geht nicht mehr. Tja, so'n GAL ist auch schnell mal voll. :)
Da das Timing ziemlich kritisch ist (das kann ich nun aus eigener Erfahrung sagen), habe ich die letzten 2-3 Wochen ausschließlich getestet und bin zu folgendem Ergebnis gekommen:
1. Der Falcon läuft absolut stabil, sogar über mehrere Tage bei höchstmöglichem Takt und 0 Waitstates für RAM und ROM!!!
2. SCSI läuft in allen Speed-Modi einwandfrei ohne Bit-Fehler (mehrfaches aus und einpacken von ZIP-Dateien und dabei CRC32-Überprüfung über mehrere Stunden)
3. Sound läuft mit dem Falcamp in allen Modi einwandfrei.
4. Cubase 2.6 (auch zusammen mit Analog8 und SPDIF) mit 18/36MHz einwandfrei. den 20/40Mhz teste ich nicht, da per Nemesis der HI-Mode (über ACIA-Midi gesteuert), automatisch deaktiviert wird, sobald Cubase startet. (ist mir aber auch so schnell genug).
5. Sound über ACE-Tracker in allen Modi einwandfrei.
6. Sound mit Aniplayer bei 18/36MHz und aktivertem DMA einwandfrei, bei 20/40MHz gibt es nach einiger Zeit Störungen bis zum Kommunikationsfehler. Mit deaktiviertem DMA in allen Modi einwandfrei.
Zu Punkt 6: Ich habe festgestellt, das die Ergebnisse zum Teil wirklich (wie Czuba bereits schrieb) auf thermische Probleme zurück zu führen sind. Aber es ist nicht der Videl, sondern der DMA-Chip selber. Sobald es anfängt, das der Chip Probleme macht, also tzirpen und blubbern (das sollte jeder kennen), ist der Falcon bereits einige Zeit gelaufen (zwischen 30-90min) und der Chip relativ warm. Es reicht hier ein kurzer Stoß mit Kältespray oder einfach einen Kühlkörper auf dem Chip zu setzen. solange sich die Temperatur um die 20°C bewegt, ist alles ok. sobald sich der Kühlkörper jedoch erwärmt, was nun etwas länger dauert, gehts dann wieder los. Das ist absolut reproduzierbar und über Tage getestet. Leider habe ich diesbezüglich keine Lösung parat. Alle Messungen von Signalen usw. hat nichts ergeben, was auf diesen Fehler hindeutet. Es kann natürlich ein Fehler NUR in meinem Falcon sein, aber das finde ich nur raus, wenn ich diesen Chip tausche onder einen anderen Falcon mit meinem Beschleuniger ausstatte. Bis dahin muss das erstmal so genügen. Ich denke, das die Ergebnisse auch bei funktionierenden Sound und 18/36MHz beachtlich und ausreichend sind.
Achso, ich habe das fast vergessen, bei der Optimierung des Timings gabes noch einen anderen positiven Effekt... Der Falcon ist nochmals schneller geworden (vergleicht die Gembench-Ergebnisse) :D
Weiterhin habe ich in diesen 2-3Wochen Test festgestellt, der der Blitter mit 16MHz NIEMALS abgestürzt ist, somit müsste das Nemesis-Tool nochmal so modifiziert werden, das der Blitter nicht auf 8Mhz getaktet wird...
Das wars erstmal von diesem Projekt...
Gruß HW
(http://img3.fotos-hochladen.net/uploads/foto3dn2luirq49.jpg)
(http://img3.fotos-hochladen.net/uploads/image1hrqlb2pf9t.jpg)
(http://img3.fotos-hochladen.net/uploads/image257fmdknl8t.jpg)
-
Wow... fasst du uns die Version 3 noch zusammen? - Sozusagen als Version 3 für Dummies ? - Z.B. das darin vorhandene GAL muss man selbst programmieren? Wie?
Grüße, raphael
-
Eine tolle Lösung! Vielen Dank, HW.
Ist geplant, daraus eine allgemeingültige Beschleunigerlösung zu machen, so daß man diese selbst nachbauen oder einbauen lassen kann?
-
Es kann ja mal jemand die Ergebnisse vom TT posten, um das mal zu vergleichen ;)
Gerne doch. 8)
(http://mcp.ignorelist.com/bilder/gembenchtt.jpg)
-
Hallo hw, wo hast Du den grünen Draht bezogen den Du am GAL verwendet hast? So etwas Suche ich schon länger. Der TT Benchmark ist mit CaTTamaran (also 48MHz CPU Takt statt 32MHz) und Nova (in 65536 Farben) ausgeführt worden. Werde noch vom normalen TT die Werte nachreichen.
-
Hallo Arthur,
ich vermute mal ganz stark,dass es AWG-28 Wire-Wrap Draht ist.
Grüsse,
Vassilis
-
Hi,
nichtsnutz hat fast recht, ist ein versilberter AWG30 Wire-Wrap Draht.
http://de.farnell.com/pro-power/100-30g/kupferdraht-versilb-kynar-gruen/dp/1202483
für alle Interessierten:
Ich werde eine kleine Schematic hier im Forum veröffentlichen. Das GAL muss mit einem geeigneten Programmer programmiert werden. Über einen kommerziellen Einsatz habe ich noch nicht nachgedacht, es ist auch so simpel aufgebaut, das eigentlich jeder, der mit Lötkolben umgehen kann, das auch nachbauen kann.
Ich denke aber noch darüber nach, Leuten mit zwei "linken" Händen, diesen Beschleuniger zum quasi Selbstkostenpreis einzubauen (das natürlich auch ohne Garantie auf die Funktion oder anderen Abhängigkeiten).
Ggf. könnte ich auch für Interessierte den GAL programmieren, wenn keine geeignete Hardware zur Verfügung steht...
Gruß HW
-
Hallo Ihr zwei, danke. Mit so einem Draht lässt sich bestimmt vorzüglich arbeiten. ;D
-
Auf die Schaltung freue ich mich. ;D
-
Hi, ich nochmal...
Hier die Beschreibung zur aktuellen Version-3 meines Beschleunigers...
Vorraussetzung:
1. Der Clockpatch kann vorhanden sein (dies vereinfacht den Umbau, da zB. die Widerstände bereits entfernt wurden). Dieser Clockpatch wird bei Einbau des GAL's komplett ersetzt!
2. eine extra Leitung zum DMA Pin110 muss installiert sein, da die Clockleitung zur FPU ursprünglich auch zum DMA geht, und dieser ja nicht höher getaktet werden darf. Also, falls noch nicht geschehen: Die Leitung muss am DMA-Chip (Pin110) unterbrochen werden und die Clockleitung muss direkt an Pin110 angelötet werden. Hier wäre noch zu erwähnen, das der evtl. vorhandene SCSI-fix (also Widerstand oder Kondensator) an diesem Pin entfernt werden muss, dieser wird nicht mehr benötigt.
3. eine funktionierende 500kHz-Erzeugung für Midi/Keyboard an ACIA's Pin 3 und 4 (sollte jeder haben, der bereits übertakten wollte). Diese Modifikation kann nicht vom GAL übernommen werden, da im GAL-Baustein nicht genügend Ressourcen vorhanden sind.
Hardware:
1. ein programmiertes GAL22V10D-10 oder schneller...
2. 2 Quarze mit 36MHz und 40MHz
3. 2 Kondensatoren 100nF-1uF Vielschicht X7R
4. 2 Widerstände 22Ohm
5. ein paar Drähte (siehe Post 1)
6. ruhiges Händchen und einen heissen Lötkolben
Einbau:
wie bereits im 1. Post beschrieben, alle Pins bis auf 10 und 24 des GAL-Bausteins kürzen. Pin 10 und 12 brücken, Pin10 nimmt den GND des darunterliegenden GALs auf. Pin24 wird auf den darunterliegenden Pin20 gelötet.
Kondensator zwischen GND und VCC, also 10 und 24 verlöten. Leitungen wie in der Schematic beschrieben einlöten. Die beiden Quarze kann jeder für sich selber ein Plätzchen finden, ich habe für den 40MHz-Quarz den vorgesehnen Platz neben dem RTC verwendet. Der Andere wurde einfach aufs Board geklebt (siehe Bilder). Auf gute GND-Verbindungen beim Aufbau achten...
fertig.
Pinbelegung:
01 - nicht belegt
02 - Glue-Clock (16MHz) kommt vom R217 (unten anlöten)
03 - Leitung vom ACIA Midi Pin5 (aktiviert 40NHz Quarz)
04 - Leitung vom ACIA Keyboard Pin5 (aktiviert 36MHZ Quarz)
05 - Leitung vom GAL u68 Pin16
06 - LOW=einfacher CPU-Takt / HIGH=doppelter CPU-Takt
07 - LOW=standard / HIGH=alternativ (aktiviert den DMA-Patch) - sollte auf VCC liegen
08 - LOW=36MHz /HIGH=40MHz (schaltet den festen FPU-Takt auf Pin20 um) - sollte auf GND liegen
09 - Quarz-Takt 40MHz Eingang (mit 22R terminieren)
10 - GND-Pin vom darunterliegenden GAL
11 - Quarz-Takt 36MHz Eingang (mit 22R terminieren)
12 - GND
13 - Eingang des 32MHz Sytemtaktes (von L102 rechts, Bauteil entfernen)
14 - Systemtakt zum GLUE-Chip (verzögerter Ausgang) - nicht belegt
15 - Systemtakt zum GLUE-Chip (zum L102 links, alternativ R234)
16 - verzögerter DMA-Takt zum DMA-Chip (ca. 8ns) - nicht belegt
17 - verzögerter DMA-Takt zum DMA-Chip (ca. 4ns) - nicht belegt
18 - DMA-Takt zum DMA-Chip Pin110
19 - Ausgang CPU-Takt (zum R222 unten, Bauteil ggf. entfernen)
20 - alternativer fester FPU-Takt auf 36MHz oder 40MHz - nicht belegt
21 - Ausgang FPU-Takt (zum R221 oben, Bauteil ggf. entfernen)
22 - Ausgang EXTERN(Modulschacht)-Takt (zum R216 oben, Bauteil ggf. entfernen)
23 - ODER-Verknüpfung der ACIA-Leitungen Pin5 - zum Pin6 (16/32MHz CPU_Taktwahl)
24 - VCC Btriebsspannung 5V, geht zum darunterliegenden GAL Pin20
Inbetriebnahme:
Sollte der Aufbau ähnlich meiner Empfehlung aufgebaut sein, sollte der Falcon nach dem Einschalten sich genauso verhalten, als wäre dieser Chip nicht eingebaut. Einige Beschleuniger haben einen Schalter eingebaut, um die Taktverdopplung der CPU permanent einzuschalten. Das ist durchaus möglich, ich verwende eine OR-Verknüpfung der ACIA-Leitungen. Da der Skunk den ACIA-Midi verwendet, kann man mit den Skunk-Tool, rein die Taktverdopplung einschalten. Dies beschleunigt ausschließlich die CPU-internen Vorgänge und nicht den Bus.
Mit dem Nemesis-Tool kann man den Beschleuniger auf LO (36MHZ) und auf HI (40MHz) stellen, dabei wird automatisch die Taktverdopplung der CPU eingeschaltet.
Varianten:
Wie bereits beschrieben, kann die Taktverdopplung der CPU auch mit einem Schalter geschaltet werden, grundsätzlich können alle Modi des GAL über Schalter realisiert werden. dann hat man die "ultimative" Kontrolle. Mir ist leider mein Falcon zu schade, alles zu verbohren und zu verbasteln, daher habe ich versucht, die wichtigsten Funktionen per vorhandener Software zu lösen. Weiterhin hat man die Möglichkeit, Finetuning mit dem DMA-Takt zu betreiben. Man kann über die 2 zusätzlichen Ausgänge den Takt weiter verzögern, auch ist eine Systemtakt-Verzögerung möglich (siehe Pinbelegung). Alle zusätzlichen Features und Ausgänge vom GAL, die standardmässig nicht verwendet werden, sind mit einem rotem X gekennzeichnet. Bauteile, die entfernt werden müssen, auch mit dem roten X.
Vie Spass beim basteln, und macht bitte den Falcon nicht kaputt... :'(
Gruß HW
Info: Angehängt ist das GAL-JED File, welches gezippt und in JPG umbenannt wurde...
-
Vielen Dank.
Jetzt bräuchte ich nur noch einen unverbastelten Falcon und einen Bastler. ;D
Und ich weiß noch jemanden, für den der Beschleuniger sicherlich interessant wäre.
-
Vorraussetzung:
1. Clockpatch sollte bereits gegeben sein
2. eine extra Leitung zum DMA Pin110 muss installiert sein, da die Clockleitung zur FPU ursprünglich auch zum DMA geht, und dieser ja nicht höher getaktet werden darf
3. eine funktionierende 500kHz-Erzeugung für Midi/Keyboard an ACIA's Pin 3 und 4 (sollte jeder haben, der bereits übertakten wollte)
Zu 1. Ich dachte das GAL ersetzt den Clockpatch gleich mit.. wozu sollte er dann schon vorhanden sein?
Zu 2. Das sollte kein Problem sein... muß der Pin 110 vorher vom Bord oder die Leitung auf dem Bord aufgetrennt werden damit nicht zwei Taktsignale anliegen?
Zu 3. Ich dachte das Gal würde den 500KHz Clock auch mit erzeugen. Das der Takt an die ACIA's muss ist klar.
-
Hallo Arthur:
zu deinen Fragen:
Zu 1. Ich dachte das GAL ersetzt den Clockpatch gleich mit.. wozu sollte er dann schon vorhanden sein?
Das ist richtig. Es wird der Clockpatch ersetzt. Ich habe mich da etwas "unglücklich" ausgedrückt... "sollte" bezog sich auf die vereinfachte Modifikation des Boards, da die wichtigsten Änderungen (mit den Widerständen usw.) bereits gemacht wurden... Also nochmal richtig: Der Clockpatch kann vorhanden sein, wird aber bei Einbau des GAL's ersetzt!
Zu 2. Das sollte kein Problem sein... muß der Pin 110 vorher vom Bord oder die Leitung auf dem Bord aufgetrennt werden damit nicht zwei Taktsignale anliegen?
Oja, das vergass ich zu erwähnen, das ist wichtig. Die Leitung muss am DMA-Chip (Pin110) unterbrochen werden und die Clockleitung muss direkt an Pin110 angelötet werden. Hier wäre noch zu erwähnen, das der evtl. vorhandene SCSI-fix (also Widerstand oder Kondensator) an diesem Pin entfernt werden muss, dieser wird nicht mehr benötigt.
Zu 3. Ich dachte das Gal würde den 500KHz Clock auch mit erzeugen. Das der Takt an die ACIA's muss ist klar.
Nein, das habe ich auch bereits im ersten Post beschrieben. Diese Schaltung muss separat eingebaut werden. Ich habe diese Schaltung auch Huckepack als SMD eingesetzt. das sieht dann ordentlich aus und man benötigt keine Platine (siehe Posting 1). Der Grund, warum der GAL das nicht übernehmen kann, liegt in der Tatsache, das zum Teilen des Taktes zu viele Register, also Flip-Flops verwendet werden müssen, das nicht genug "Ressourcen" für die restlichen Funktionen "übrig" bleiben...
Leider...
Ich werde die Anleitung nochmal um die o.g. Punkte erweitern.
Gruß HW
-
Hab die Schaltung von HW hier mal direkt verlinkt so das diese auch ohne klick auf den Link angezeigt wird sofern man eingeloggt ist. Mir juckt es langsam in den Fingern. 8)
(http://forum.atari-home.de/index.php?action=dlattach;topic=9038.0;attach=2929)
-
Das sieht sehr interessant aus, und ich habe einen noch total unverbastelten Falken. Ich sehe aber aus obiger Anleitung, dass da noch zusätzliche Sachen gemacht werden müssen, z.B. zwecks Midi. Ziemlich mühsam, sich die Zusatz-Sachen noch rauszusuchen, und ich habe keinen GAL-Programmer.
Könnte man da nicht mal ein Komplett-Paket schnüren?
-
Könnte man da nicht mal ein Komplett-Paket schnüren?
Ich verstehe die Fragestellung nicht...
Das ist doch komplett.
Da ist nichts, was nicht sowieso im zusammenhang mit einem beschleunigten Falken bekannt wäre.
Diese Schaltung ist aber nichts für jemanden der von Tuten und Blasen keine Ahnung hat.
Cheers
Jürgen
-
Siehe Vorraussetzung Nr. 3.
-
Hallo an Alle,
ich melde mich mal wieder zurück, nachdem ich ja lange nichts mehr geschrieben hatte. Ich hatte mit der CT2B genug zu "tun", sodass ich mich nun gerne nochmal zu diesem Thema zurückmelden will.
Also da es ja bestimmt jeden interessiert, der aufmerksam diesen Thread verfolgt hatte:
Ich habe den DMA-Bug, also SCSI und DSP Fehler nun erfolgreich beseitigen können!!! Also nochmal für die langsamen Denker: Kein Knacken, knistern oder Hänger bei der Audio-Ausgabe und auch keine DMA-Fehler bei SCSI-Zugriffen!!!
Bevor nun alle JEAAAHHH schreien, ich kenne nur die Lösung auf meinem Falcon, was keine allgemein gültige Lösung darstellen muss. Wie hinreichend bekannt, das Timing im Falcon reagiert extrem pissig auf Reflexionen oder Dämpfung bei verschiedenen Kabeln. Meine Erfahrungen konnte ich mit der CT2B machen, wofür ich mir extra nochmal einen anderen Falcon kaufen musste. Dort ist das noch kritischer, da der Bus mit 25MHz getaktet wird... Was für mich ein Graus war kann für Euch natürlich ein Juhu bedeuten. Ich habe mit meiner Lösung MP3s stundenlang angehört und das Board auch beföhnt (laut Wärmebildkamera so ca 35°C, das bedeutet ca ein geschlossenes Gehäuse und das auch ICs gerne mal so an die 50°C kommen). Null Problemo.
Zur Lösung:
Bedrahtet wird alles wie oben beschrieben, auch der allgemein bekannter SDMA-Fix mit dem Widerstand MUSS gemacht werden. Ich verwendete einen 1% Metallfilm 68R Widerstand. Als Kabel kommt wieder der o.g. Draht in Frage, versilbert sollte er sein. jetzt muss etwas experimentiert werden, da das Signal noch etwas mehr verzögert werden muss. Entweder man verwendet einen Kondensator (COG oder X7R) über den Wiederstand als Dämpfung (das wären so 4,7-15pF, es muss einfach probiert werden), oder wie ich eine Ferrite-Perle. Da ich die Daten nicht genau weiss, kann ich diese hier auch leider nicht nennen (sie waren einfach in der Bastelkiste)... Sorry.
Zu euren Anfragen:
Natürlich würde ich gern euch allen behilflich sein, da div. Anfragen schon kamen, ich kann gern diese GALs für euch brennen (ich denke zum Selbstkostenpreis) oder ich schnüre ein Paket mit den zu benötigten Teilen. Weiterhin habe ich über eine PCB gedacht, die den originalen und den neuen GAL sowie alle Bauteile beinhaltet. Auch über einen Einbauservice denke ich nach. Wie ich's mache, hängt natürlich von euren Wünschen und Ideen ab.
Also, es bewegt sich...
Ich melde mich, Gruss HW 8)
-
Ich bin bereit. ;o)
-
Hallo hanswurst4711,
wahnsinn, dass du das geschafft hast! Ich halte deinen Hardwarepatch für absolut unverzichtbar für jeden Falcon.
Wir hatten ja schon mal Kontakt. Mich nervt dieses Audioknistern so dermaßen, dass ich keine Lust habe, mit dem Falcon soundmäßig etwas zu machen. Mein Interesse geht eindeutig zu einer PCB mit allen Bauteilen und dem Einbauservice.
Und eine Frage: Kann man davon ausgehen, dass die Schaltung auch mit einer CT60 plus Motherboard-Beschleunigung auf 25 MHz funktioniert?
Herzliche Grüße
AtFaCT
-
Hallo hw4711, was schätzt du wie hoch die Materialkosten dafür kämen?
-
Moin,
oneSTone:
Über die Materialkosten habe ich noch nicht nachgedacht. Sowohl die GALs programmiert verkaufen oder auch als Bundle mit den restlichen Teilen hängt von der Materialbeschaffung ab. Die GALs (die ich verwendet habe) hatte ich ja eh rumliegen. Sollte es in etwas größeren Stückzahlen gehen, müsste ich erst die Beschaffenheit prüfen, z.Z. sind wenn dann nur noch Bausteine mit 10ns zu bekommen (und diese habe ich bisher nicht getestet).
AtFaCT:
Ja sicher, der Sound über den DSP ist ja gerade das Besondere am Falcon, sonst tut es auch ein TT ;)
Da das Timing SEHR kritisch ist, würde ich sogar überlegen, dir und (wenn es nicht soo viele sind) auch anderen anbieten, meinen Beschleuniger einzubauen.
Das macht zwar Arbeit aber es wäre für Leute die einzige Möglichkeit, die bisher keinen Erfolg hatten oder aufgrund der "speziellen weilblichen Note" des Falcon einen Umbau nicht zutrauen...
zur Idee mit der PCB:
mir würde das sehr gefallen, das Ganze auf einer PCB unterzubringen. Leider haben sich auch andere bisher daran versucht und sind kläglich gescheitert. Und das soll nicht heißen, das es an Wissensmangel fehlt sondern tatsächlich am Aufbau und Design der PCB und des Falcon. Daher hatte ich ursprünglich auch davon abgesehen und habe gerade deswegen alles in einem GAL als Huckepack verwendet. Würde man jetzt wieder mit einer PCB anfangen, wäre das sehr sexy da man auch aktuelle SMD/PLCC Bauteile verwenden würde, aber man fängt mit der Anpassung des Timings auch wieder von vorn an... Wie gesagt, aus der Welt ist das aber nicht.
zur CT60+25Bus:
diese Problematik sollten wir auf meinem anderen Thread (CT2B) weiter diskutieren, grundsätzlich ist das Ganze ein Thema immer dann wenn am Bustakt was verändert wird, ganz (oder fast) egal was für eine Turbokarte drinsteckt. Auch ein Herr Czuba, der mehrfach betont hat "100% SDMA fix", hat eigentlich das Problem nie ganz beseitigt, wie ich selbst erfahren durfte. Daher hat er auch bei der CT63 irgendwann gänzlich auf die Busbeschleunigung verzichtet und nur auf Wunsch verkauft.
Noch was in eigener Sache:
Sollte ich mit der CT2B "irgenwann" mal wirklich zufrieden und glücklich sein, denke ich über den Verkauf des von mir umgebauten Falcon nach. Ich denke, 2 Geräte muss man nicht rumstehen haben. Obwohl.. ::)
Gruß HW
-
AtFaCT:
Ja sicher, der Sound über den DSP ist ja gerade das Besondere am Falcon, sonst tut es auch ein TT ;)
Da das Timing SEHR kritisch ist, würde ich sogar überlegen, dir und (wenn es nicht soo viele sind) auch anderen anbieten, meinen Beschleuniger einzubauen.
Das macht zwar Arbeit aber es wäre für Leute die einzige Möglichkeit, die bisher keinen Erfolg hatten oder aufgrund der "speziellen weilblichen Note" des Falcon einen Umbau nicht zutrauen...
Mir geht es bei meinem Falcon darum, den DMA-Bug loszuwerden. Der tritt in allen Modi bei mir auf, also auch ohne CT60 sowie ohne die Busbeschleuning. Ich könnte mir vorstellen, dass sich das mit einer Modifikation des SDMA-Clocks und abgeschirmter Leitung zum DSP beheben lässt. So ähnlich wie du es im CT2B-Thread beschreibst. Also ich wäre überglücklich, wenn du dir meinen Falcon mal anschauen könntest. Würdest du das machen? Wenn jemand das Problem beseitigen kann, dann du. Über die Modalitäten könnten wir uns per PM austauschen.
Herzliche Grüße
AtFaCT
-
@AtFaCT:
Also ich wäre überglücklich, wenn du dir meinen Falcon mal anschauen könntest. Würdest du das machen?
Ja, denke das könnte ich machen... (ich kann dir aber keinen Erfolg versprechen). Melde dich dann per PN.
Gruß HW
-
Hallo hanswurst4711, ich habe dein GAL incl. eines 40MHz Quarzes in einen reparierten Falcon eingebaut (danke an Skul für das Board) und er lief auf anhieb. Die Werte im Benchmark sind fast bis auf die Kommastelle mit deinen identisch. Habe bisher nur die DMA Leitung noch nicht verlötet... (hab aber kein Problem bisher) was ich dennoch nachholen werde. Mein alter SMD 4024 (aus der Schaltung von Peter Green) für den 500KHz Takt hab ich wie Du huckepack verlötet. Nebenbei wurde noch ein "leeres NVRAM" durch einen Dallas ersetzt. Ich bin natürlich ein stolz das ich es hinbekommen habe, was dank deiner Fotos und deines fehlerlosen Plans auf anhieb klappte. Die Datenrate der Festplatte hat sich durch die Schaltung beim lesen und schreiben um ca. 600 KB erhöht (ich hoffe das bleibt so wenn der DMA angenabelt wird). Das System läuft wirklich rund auch unter MiNT läuft alles wie gehabt... nur halt entsprechend schneller. Ach ja, fehlen auch noch die Kabel zu den ACIA's. Bei interesse knipse ich gerne ein paar Bilder davon.
-
@Arthur, danke, daß Du dieses Thema mal wieder aus der Versenkung holst.
Das heißt, Du has HWs Selbstbaubeschleuniger bei Dir verbaut? In dem Fall würde ich mich über Fotos freuen.
Ich habe noch mehrere Falcons im Regal liegen und würde einen davon gern mit HWs Beschleuniger aufrüsten. Da ist es gut zu wissen, daß es außer HW noch wenigstens einen weiteren Falcon Nutzer gibt, der es geschafft hat, diese Lösung lauffähig zu verbauen.
Danke nochmals.
-
Das heißt, Du has HWs Selbstbaubeschleuniger bei Dir verbaut? In dem Fall würde ich mich über Fotos freuen.
Ja, hanswurst4711 hatte mir ein Set (aus programmiertem GAL20V8, 3Widerstände, 2Kondensatoren und etwas vom genialen AWG30 Kabel) zugeschickt. Aus einer defekten SRC hab ich dann noch einen 36MHz u. 40MHz Quarzoszillator ausgelötet (wo der 4024 herkommt steht ja weiter oben).
Löte nachher noch die DMA- und die ACIAs-Strippen an und knipse dann auch Fotos davon. Laufen tut es aber wie geschrieben auch jetzt schon. Die ACIAs sind ja nur für eine sofwaremäßige Umschaltung des Taktes notwendig... und das DMA-Kabel sollte, glaub ich, die Soundprobleme beheben. Ich bin immer noch von der eleganten GAL-Belegung beeindruckt. Wenn man schon mal anderen Beschleuniger eingebaut hat dann findet man sich irgendwie sofort zurecht.
-
Danke, Arthur.
Ich schreibe Dir gleich mal eine PN.
-
moin
@HW
Klasse ! Hut ab, verbeugung, respekt
keine ahnung ob ich es je brauche, aber auch haben wollen >:D
Wem schicke ich meinen Falken? Entlohnung? Vieleicht freie Auswahl ;)
Bis auf das GAL sind die anderen Bauteile reichlich vorhanden.
nau
-
Hier einige Bilder vom meinem Falcon Board mit dem HW4711-Beschleuniger und nur mit dem 40MHz Quarzoszillator. Auf den 36er hab ich erst einmal verzichtet.
-
Da nur 4 Bilder pro Antwort gehen... hier die nächste Charge.
-
Feine Sache. :)
-
Und hier die Werte für die IDE-Platte mit und ohne 4711. :D
-
Wie oben angegeben sind ja die ACIA- und das DMA-Kabel nun auch angelötet. Das dünne AWG30 ist als Taktleitung nicht so optimal wie z.B. die Litze aus einem IDE-Kabel. Daher werde ich zwei, drei Kabel die hohem Takt führen autauschen. Wenn ich dickeres AWG-Kabel hätte würde ich es erst damit versuchen.
Bekomme demnächst einen MC68040RC(40MHz) und werde dann die AB040 dort einbauen.
Was noch auffällt:
1. Der Unterschied mit DMA-Kabel ist, was die Geschwindigkeit angeht, nicht messbar.
Soundtest will ich noch machen. Welche (freie) Software nehme ich dafür am besten?
2. Durch das Anlöten der ACIA-Kabel startet nun der ST wieder in 16MHz und nicht sofort mit 40MHz.
Mit der Nemesis-Software muss/kann jetzt auf die 40MHz umgestellt werden. Den 36MHz Oszillator baue
ich nun doch noch ein...
Bauteilliste.
Quarzoszillator 40MHz
Quarzoszillator 36MHz
2 * 22R Widerstände
1 * 68R Widerstand
1 * 4024 IC
1 * GAL 20V8
etwas Draht
Das GAL ist dabei der Löwenanteil... alles zusammen sollte für unter 20€ zu bekommen sein.
-
Wie schnell muß das Gal sein?
15ns?
-
Hallo Lynxman, meins ist 7ns schnell.
-
Hallo,
ich melde mich mal als heimlicher Leser :-)
Diese Schaltung entspricht ja meiner PowerUP030 die ich vor Jahren Entwickelt habe. Sie funktionierte auch sauber, ich habe allerdings den Videl noch mit einem höheren Takt versorgt so das man bis zu 1024x768 auf einem TFT fahren konnte.
Das größte Problem was ich nicht gefixt bekommen habe, ist der Zugriff auf den Romport habe auch Rom2 mit in die Schaltung am GAL eingebaut aber immer wieder beim Zugriff auf den Romport kam es zum Crash des Systems.
Wir hatten sogar eine andere CPU in den Falcon eingebaut und 50Mhz für kurze Zeit auf die CPU hinbekommen. Aber das waren alles nur Tests und nicht Stabil. Mein letzter Stino Falcon lief mit 25Mhz Bustakt sehr Stabil bis auf den Romport. Da ich aber einen Daynaport am SCSI hängen hatte war mir das auch egal.
Wie sind den die erfahrungen bei dieser Lösung?
Viele Grüße
Ingo
-
moin
Schön das es dich noch gibt. ;D
Könnte mal wieder zugang zum Wiki gebrauchen >:(
So ein paar Bilder und Texte.....
Viel Erfolg, beste Gesundheit (auftauchen nicht vergessen) 8)
nau
-
.... ist der Zugriff auf den Romport....
.....sehr Stabil bis auf den Romport.
Wie sind den die erfahrungen bei dieser Lösung?
Hi Ingo, schön, daß Du noch hier mitliest.
Danke für diesen wichtigen Hinweis! Ich schließe mich dieser Fragestellung an.
Ein beschleunigter Falcon ist sicherlich eine feine Sache und ich möchte in einen meiner Falcons genau so einen Beschleuniger einbauen (lassen).
Als Nutzer diverser Dongles (z.B. für Cubase und Logic) bin ich aber natürlich auf den funktionierenden ROM Port angewiesen.
@hanswurst4711:
Hast Du den ROM Port mal zusammen mit Deinem Beschleuniger ausprobiert?
-
Hallo,
ich melde mich mal als heimlicher Leser :-)
Hallo Ingo, hab mich schon gefragt wann man mal von Dir hört. :D
Bis Sonntag wird es wohl den 100000ten Besucher auf www.newtosworld.de geben. Gratulation und Danke.
Wie sind den die erfahrungen bei dieser Lösung?
Hab es eingebaut und schon ein paar Stunden laufen lassen... die Audiotests werd ich auch noch machen... sonst läufts stabil.
Mit dem Atari Testmodul klappt es auch am Romport (ist aber wohl nicht so Timing-abhängig)... Netzwerk mit Hydra teste ich wenn das neue Easymint raus ist.
-
Wie sind den die erfahrungen bei dieser Lösung?
Hab es eingebaut und schon ein paar Stunden laufen lassen... die Audiotests werd ich auch noch machen... sonst läufts stabil.
Mit dem Atari Testmodul klappt es auch am Romport (ist aber wohl nicht so Timing-abhängig)... Netzwerk mit Hydra teste ich wenn das neue Easymint raus ist.
Hallo Arthur, auf die Ergebnisse Deiner Audiotests bin ich gespannt.
Netzwerk mit Hydra ist auch ein wichtiger Test, zumal ich eine Hydra Netzwerkkarte habe und nutze ;)
Hast Du zufälligerweise auch ein Cubase zur Hand?
-
Nein, hab ich nicht, nur ne MiDi version und Midi ist ja nicht betroffen. Werde das SDMATEST Programm von R.C. probieren das er ja dafür veröffentlicht hatte und hier posten:
Atari Falcon SDMATEST Programm (http://forum.atari-home.de/index.php?topic=10409.msg78067#msg78067)
-
"OT on"
Könnte mal wieder zugang zum Wiki gebrauchen >:(
So ein paar Bilder und Texte.....
Auf der Wiki Startsite steht melde dich bitte im Atari-Home Forum (http://forum.atari-home.de/index.php?topic=9541.msg67768#msg67768)
Auf Newtosworld steht Registiert euch bitte im Forum auf forum.atari-home.de (http://forum.atari-home.de/index.php?topic=9976.msg72839#msg72839) für einen Wiki-Account.
Hoffe das nun soweit alles beantwortet ist. 8)
"OT off"
-
"OT on"
leider nicht, hatte kompletten zugang zum Wiki :D
Jetzt kann ich zwar texten aber keine Bilder hochladen :(
"OT off"
wird wieder ;D
-
Mal nach oben rück, der Thread ist mir ganz entfallen. Eigentlich sollte man mal forenweit den Umbau organisieren, ich hätte zwei Kandidaten im Originalzustand...
-
Hat mal jmd. den ddd-Beschleuniger auseinandergenommen und mit den anderen (PhantomS, Peter Green´s Lösung oder den obigen von HW4711) verglichen?
Ich wüßte gern mal die wesentlichen Unterschiede.
-
Ob das Sinn macht ?
Ich denke mal das im DDD Modul ein GAL mit Kopierschutzbit gesetzt steckt.
Wenn ich einen Atari Falcon hätte würde ich den nicht übertakten. Das geht mit Ausnahme der CPU mit Sicherheit auf die Lebendauer der Bausteine im Falcon. Ganz abgesehen von den Preisen zur Zeit für einen Atari Falcon. Und die paar Prozent mehr wären mir das nicht Wert. Dann doch lieber eine CT60/63 oder so was in der Richtung kaufen wenn es mal etwas zu kaufen gibt ...
-
der vorteil eines geboosteten Falcon liegt aber eben klar auf der Hand "höhere Auflösung" und das macht echt was aus. Klar nicht jeder Falcon macht das mit aber 20mhz ist noch nicht so das man damit die bauteile ins Nirvana Blässt und das die CPU eh eine 32Mhz Cpu ist weiß ja fast jeder oder ?
-
Ich sehe das auch nicht so kritisch, der Falcon startet ja nachwievor mit 16 MHz, man muss ihn ja erst durch Software (die Ports an den 6850ern) hochschalten. Das macht man halt nur, wenn man es wirklich braucht.
-
Zumal mein Falcon schon seit 1999 mit Busbeschleunigung (25 MHz sogar) ohne Probleme läuft uns das bis 2005 im täglichen Alltagseinsatz (also www, also nur mit Beschleunigung aktiviert)... denke die Bauteile können das ab. Auf 2 Chips habe ich allerdings mal einen Kühlkörper aufgeklebt, für´s gute Gewissen und weil ich die da hatte ;)
LG,
Chris
-
Mein Falcon ist auch ohne beschleunigten Bus kaputt gegangen. :'(
Da steckt man nicht drin. Beim Falcon weis man bei den von Atari designten Teilen sowieso nicht auf wieviel die Spezifiziert wurden und wie hoch die Reserven sind.
-
Tjaa, wenn es mal die CT60e zu kaufen gibt ... Aber das ist ja ein anderer Thread?
-------
1) ddd-HS32 + ddd-HS40 waren schon in diesem Falken da auf meinem Tisch eingebaut, als ich ihn in der Bucht geangelt habe. Seither (also seit 8 Jahren) läuft die CPU (obwohl per Schalter problemlos umschaltbar) mit 32MHz im alltäglichen Betrieb.
Seit geraumer Weile habe ich ein Sound-Problem :'( mit dem Vogel (aber seither noch nicht ´reingeschaut). Alle Kommentare, die ich kenne, sagen, daß 32MHz für die CPU und 40MHz für den DSP kein Problem seien, und ich kann mir echt nicht vorstellen, mit weniger auskommen zu müssen (Döskteppe wie Thing oder Jinnee sind mit 1000 Icon-Zuordnungen so schon schnarch lahm, aber das ist auch wieder ein anderer Thread), im Gegenteil, ich brauche dringend ´was schnelleres!
Bei HW4711 und in anderen Threads fiel mir auf, daß da die Rede davon ist, daß für gewisse Zugriffe per GAL auf den niedrigeren Takt zurückgeschaltet wird. Vom ddd ist mir solches unbekannt, und jedenfalls bisher nie aufgefallen. Wie checkt man das?
-------
2) In einem anderen Falken, ebenso geangelt, hatte ich mal eine SpeedResolutionCard, mit der nicht nur wie bei ddd der CPU-Takt, sondern auch der Bustakt beschleunigt werden kann (vermutlich ziemlich ähnlich wie oben im Thread bei HW4711). Als ich den Vogel bekam, lief er nur mit 640x480x4 an VGA. Es war eine mühsame Pröbelei mit Jumpern & Software nötig, mit 40/20Mhz habe ich ihn nie stabil gekriegt, und mit 18MHz Bustakt waren mir für die wenigen Prozentchen an Beschleunigung die Umstände mit den Video-Modes viel zu heftig! (Mit 50MHz am Videl, ganz unabhängig von aller sonstigen Beschleunigung, erreicht man sehr viel leichter beeindruckende Ergebnisse, und sogar ohne solchen Oszi kriegt der Falke allein durch Software schon bunte Federn).
Das Fazit war, daß ich die SRC wieder entfernt habe >:D .
Ich würde mir eher einen ´abgespeckten´ HW4711 wünschen, im Sinne eines Nachbaus der ddd-HS32 (aber vielleicht mit 36 oder 40 MHz).
-
Bei HW4711 und in anderen Threads fiel mir auf, daß da die Rede davon ist, daß für gewisse Zugriffe per GAL auf den niedrigeren Takt zurückgeschaltet wird. Vom ddd ist mir solches unbekannt, und jedenfalls bisher nie aufgefallen. Wie checkt man das?
Wenn Du das mit GEM-Bench testest kannst Du dies an den CPU-Werten erkennen. Wenn die durchschnittlich um ca.130% sind dann wird zurück geswitcht.
-
_^^_ Im Anhang drei Versuche mit GEMBENCH 3.28:
Unter MAGX_6.2, NAES_2+MiNT_1.15.9 sowie TOS_4.04
und ansonsten gleichen Bedingungen (ddd: CPU 32MHz, FPU 40MHz; NVDI_4.12).
Da ist nun von CPU 127% bis CPU 141% alles vertreten.
Was soll ich daraus schließen?
(imho. bloß, daß GEMBENCH nix taugt).
-------
Der Link auf das SDMA-Test-Prg. (Posting #44) funzt nicht.
Woo bekooom?
-
da würd' ich als Erstes mal die Uhr abstellen (und was möglicherweise sonst noch so als Hintergrundprogramm mitläuft) und dann noch mal messen.
-
Jaja, Du würdest Deinen VW auch auf dem Prüfstand unter Spezial-Bedingungen testen, ich dagegen schaue lieber mal, was er denn so im alltäglichen Gebrauch macht... >:D
Hier geht es um die CPU-Performance.
Ein Benchmark, der behauptet, diese zu messen, sollte das völlig unabhängig vom BS sowie auch unbeeindruckt von jeglicher sonstiger nebenläufiger Software können! Genau das aber schafft GEMBENCH _nicht_ (wie meine ScreenShots beweisen). Im übrigen denke ich, daß ich ungefähr weiß, in welche Fallen GEMBENCH getappt ist.
Außerdem kann ich Dir versichern, daß Entfernung von Uhr, TaskLeiste etc.unter MAGX nur zu einem sehr geringen Effekt führt, der in der Meß-Ungenauigkeit von GEMBENCH verschwindet.
Auch noch OffTopic: Wer sich für ´DISPLAY´ interessiert, sollte mal mit dem NVDI beiliegenden Test vergleichen.
-------
Meine Frage an @Arthur (& auch alle anderen) lautet:
Ist ein CPU-Wert von 141% noch "durchschnittlich um ca.130%", also Indikator, daß ddd zurückswitcht - oder schon im Gegenteil der Beweis, daß dies nicht geschieht? Oder, noch mal ganz anders formuliert: Die 68k-CPUs laufen doch asynchron? Warum also meinen manche Speeder, doch mit dem Bustakt synchronisieren zu müssen?
(NB: Ich habe den Verdacht, daß die Werte in GEMBENCH für RAM- & ROM-Zugriff auch bloß reine Phantasie sind).
-------
Der Link auf das SDMA-Test-Prg. (Posting #44) funzt nicht.
Woo bekooom?
-
Ihr vergesst bei eurer Benchmarkdiskussion, dass diese Tests teils unter Single-Task- und teils unter Multitasking-TOS-Versionen gemacht wurden: TOS 4, Magic!, MiNT. Und durch was zeichnet sich Multitasking aus, na...? Richtig. Durch Hintergrundprozesse, welche die CPU auch belasten. Genau das spiegeln auch die Benchmarkergebnisse wieder. Unter TOS 4 ohne Multitasking sind die Werte wie zu erwarten am Besten.
-
Jaja, Du würdest Deinen VW auch auf dem Prüfstand unter Spezial-Bedingungen testen, ich dagegen schaue lieber mal, was er denn so im alltäglichen Gebrauch macht... >:D
Hier geht es um die CPU-Performance.
Ein Benchmark, der behauptet, diese zu messen, sollte das völlig unabhängig vom BS sowie auch unbeeindruckt von jeglicher sonstiger nebenläufiger Software können! Genau das aber schafft GEMBENCH _nicht_ (wie meine ScreenShots beweisen)...
Da brauchst Du nix mehr zu beweisen.
Daß GEMBENCH bezüglich der CPU-Performance nicht besonders akkurat ist, ist seit Urzeiten bekannt. Für einen vernünftigen "pure"-CPU-Benchmark müssten alle Interrupts gesperrt werden, was GEMBENCH eben nicht tut. Selbst wenn's das täte, könnte man wieder argumentieren, daß die Werte falsch sind, weil sie eben nicht in einer benutzbaren, realen Laufzeitumgebung stattgefunden haben (wenn Du feststellst, daß jemand im VBL-Interrupt hängt, hängst Du den dann zum Messen aus oder nicht?).
Irgendwas ist halt immer. Die vernünftigste GEMBENCH Messung bekommst Du, wie die Dinge liegen, eben dann, wenn es (soweit möglich) alleine läuft.
-
ein CPU-Wert von 141% noch "durchschnittlich um ca.130%", also Indikator, daß ddd zurückswitcht - oder schon im Gegenteil der Beweis, daß dies nicht geschieht? Oder, noch mal ganz anders formuliert: Die 68k-CPUs laufen doch asynchron? Warum also meinen manche Speeder, doch mit dem Bustakt synchronisieren zu müssen?
Leider stimmt deine Aussage nur beim Falcon, alle andere Ataris wie der St und auch der TT besitzen einen Syncronen modus nämlich immer dann wenn auf Motorolla Bauteile zugegriffen wird wie z.b. der MFP. Dafür haben die Cpus nämlich auch extra Steuerleitungen damit das Funktioiert. Asyncron laufen alle Buszugriffe die Über Adresse/AS/DTACK gesteuert werden. Und dort ist das auch nicht egal, denn wenn die CPU beschleunigt ist dann stimmen die Timings nicht mehr und die CPU versucht z.b. schon zu lesen obwohl die Daten auf dem Bus noch nicht Stabil sind und damit Führt es zum Crash. Ja es geht das die CPU mit höheren Takt läuft wie der Bus selbst aber dafür bedarf es der Anpassung der Steuersignale d.h. es müssen entsprechend der Differenz verzögerungen eingebaut werden, am Bsp. 8 auf 16 Mhz sind es z.b. 125ns wo das DTACK und das BGACK Signal verzögert werden muß. Und damit ist die CPU am ende für diese 125ns ebenfalls angehalten. Anders ist das wenn ein Cache eingebaut ist.
Beschreibung des Syncronen Buszugriffes siehe Handbuch Seite 9
http://www.weblearn.hs-bremen.de/risse/RST/WS02/Motorola68K.pdf
-
Danke für die Aufklärung, @tuxie , das war nun endlich einmal Tacheles. Und Danke auch für den Link!
-------
Eben weil dann der beste Wert erscheint, @1ST1 & @mfro , war die Messung unter TOS_4 dabei ;).
Wenn ich alle ACCs aushänge (außer ScreenShot), geht der CPU-Wert von 141 auf 142.
Hilfe, Moderator, könnte mal jmd. diese sicherlich sehr interessante Benchmark-Diskussion in einen eigenen Thread auslagern?! (Ich könnte da sicherlich noch einiges zu beitragen ;) ).
Und nun zurück zum Thema:
Meine Frage an @Arthur (& alle) war (und ist immer noch nicht sicher beantwortet), ob ddd/HS32 den Bustakt switcht wie Green oder HW in seiner Version 1, oder etwa nicht, wie HW in seiner Version 3 ?
Die nächste Frage wäre, wie man die Video-Modes in den Griff kriegt, wenn der Bus-Takt zw. 16/18/20/25 MHz wechselt? Nach meiner Erfahrung mit der SRC kommt wohl nur ein fest eingestellter Bustakt in Frage? Wie funzt denn das mit dem Video, @Arthur , wenn der Bustakt per Software umgestellt wird?!
-------
Ist HW noch bei uns?
PS: Ich habe den status nascendi in meinem Vorstellungs-Thread jetzt aufgehoben.
-
Dazu kann ich heute abend nochwas schreiben... bin aktuell unterwegs
-
CPU Benchmark:
Es gibt verschiedene Arten von CPU benchmark, das wären z.b. Primzahlenberechnung, SuperPI und einiges mehr, auf HWbot gibt es eine ganze liste einige davon sind auch Open Source und könnte man eventuell auch auf einem TT/F030 oder gar ST abbilden.
Dann ist noch ein Interessantes Thema die Busgeschwindigkeit also auch der Datendurchsatz zum Ram und zurück, denn mit dieser Geschwindigkeit steht und Fällt die Performance des ganzen Systems. Deswegen bringen die Busbeschleunigungen mehr an Performance als diese Taktverdopplung wie z.b. beim Skunk.
Thema Videl:
Der Videl hat drei Takteingänge 1. 25Mhz (fest) 2. Bustakt, 3. Genlock eingang bzw. Externer Takteingang welcher gern bei der externen blowup verwendet wird.
Die SRC hat soweit ich mich erinnern kann eine direkte Verbindung zum Externen Takteingang des Videls und somit ist der Takt des Videls Bustaktunabhängig.
Bei den einzelnen Tools zum Verändern der Auflösung kann man dann auch Auswählen welchen Takteingang man verwenden möchte.
-
An meinen Dhrystone-Testergebnissen
-> http://forum.atari-home.de/index.php?topic=13075.20
kann man den Einfluß der verschiedenen Parameter auf die Gesamt-Performance, wie zB. CPU-Takt, Bus-Takt, Prozessor, Cache, Video-System etc., sehr gut ablesen.
-------
In welchem Thread hab´ ich denn das bloß gelesen, wie nämlich der Bustakt das Video-Timing (Horizontalfrequenz?) beeinflußt?!
Bei der SRC wird nmE. nur ein Takt (50MHz?) in den ext. Takteingang des Videl eingespeist. Der ist aber nicht für alle Auflösungen brauchbar (ibs. nicht für die drei ST-Auflsgn.) und der 25MHz-ClockTakt (der zB. ST-hi abdeckt) wiederum reicht auch nicht für alle restlichen ... Der mittlere Takt aber verändert sich anscheinend mit dem BusTakt!
Die _Wahl_ ist also sehr eingeschränkt - ausgerechnet für die interessante Auflösung 800x600x4!
-
Das wird aber abhängig der Auflösung selbst gesetzt welchen eingang er verwendet, also ich hatte da eigentlich nie Probleme. Und deinen benchmark werde ich mal testen :)
-
Wie schon mal kurz erwähnt, hatte ich Probs bei der BusTakt-Umschaltung der SRC mit den Video-Modes (in meiner damaligen Naivität hatte ich auch dafür einen Schalter eingebaut).
------
Der Dhrystone ist nicht _mein_ Benchmark. Ich habe lediglich geringfügige Anpassungen an div. M2-Systeme vorgenommen. Lediglich etliche (nicht alle) der Meßergebnisse sind von mir.