Hardware > Hardware (Classic 16-/32-Bit)

Selbstbaubeschleuniger für den Falcon - HW4711-Edition

(1/14) > >>

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

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

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

Navigation

[0] Themen-Index

[#] Nächste Seite