Selbstbaubeschleuniger für den Falcon - HW4711-Edition

[guest2980]

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).






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)

[Arthur]

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. 

[guest2980]

@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

[guest2980]

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) 

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   

[cyberish]

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

[dbsys]

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?

[Arthur]

Es kann ja mal jemand die Ergebnisse vom TT posten, um das mal zu vergleichen 

Gerne doch. 

[Arthur]

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.

[nichtsnutz]

Hallo Arthur,

ich vermute mal ganz stark,dass es AWG-28 Wire-Wrap Draht ist.

Grüsse,
Vassilis

[guest2980]

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

[Arthur]

Hallo Ihr zwei, danke. Mit so einem Draht lässt sich bestimmt vorzüglich arbeiten.

[Arthur]

Auf die Schaltung freue ich mich.

[guest2980]

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...

[jens]

Vielen Dank.
Jetzt bräuchte ich nur noch einen unverbastelten Falcon und einen Bastler.

Und ich weiß noch jemanden, für den der Beschleuniger sicherlich interessant wäre.

[Arthur]

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.

[guest2980]

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

[Arthur]

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.

[1ST1]

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?

[Athlord]

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

[1ST1]

Siehe Vorraussetzung Nr. 3.