Atari St mit Vampire 500 FPGA Turbokarte

[tuxie]

Bitte hört auf mit Streiten, ich denke es wird der Firebee sogar gut tuen, da die Atari Szene wieder einen kleinen Aufschwung erhalten wird. Vielleicht steigen sogar eine Amiga Jünger mit ein.

[Mathias]

Bitte hört auf mit Streiten, ich denke es wird der Firebee sogar gut tuen, da die Atari Szene wieder einen kleinen Aufschwung erhalten wird. Vielleicht steigen sogar eine Amiga Jünger mit ein.

Entschuldigung tuxie, jetzt wirds einfach nur mehr absurd!

1ST1 sieht in diesem Core eine sehr flotte Upgrademöglichkeit, und erfindet eine Konkurrenz zur FireBee (die er sich schon vor ein paar Tagen am Anfang des Threads gewünscht hat). Ich sage das ist Blödsinn, da die FireBee auf keinem "Markt" ist, und es eben keine Konkurrenzsituation geben wird (falls es überhaupt irgendwas geben wird), anscheindend springen Mehrere wie Du und Nervengift aber drauf an – also auf diese imaginierte Konkurrenz. Jetzt schreibt mjaap ein einziges Posting als antwort auf nervengift, und bestätigt ca. meine Meinung, daß das Eine das Andere ja nicht auschließt.

So; und jetzt kommst Du daher siehst ein "streiten" das nicht existiert (also nicht bzgl. der FireBee, meine Kommunikationsschwierigkeiten mit 1ST1 gibts natürlich – aber das hat mit mjaaps Posting auf das Du jetzt direkt reagiert hast nichts zu tun), forderst ein, daß nicht mehr gestritten werden soll, reproduzierst aber genau das im 2 Halbsatz warum wir überhaupt zum diskutieren angefangen haben, nämlich daß dieser Core irgendwas mit FireBee-Konkurrenz zu tun hätte.

Du empfindest also die Äußerung daß es keine Probleme geben wird als streiten, und forderst das Ende dieses Streites damit ein, daß Du die angeblichen Probleme aber wieder implizierst, also den Grund der Diskussion entgegen Deinem eigenen Streitverbot nochmals postulierst, obwohl er jeglicher Grundlage entbehrt. Selbstverständlich verwirfst Du diese Probleme abschließend dann wieder, ...

Kommunikationstechnisch genial gemacht, aber vermutlich nur passiert, und leider hochgradig absurd. Ich fürchte halt daß wieder mal Viele gar nicht alles lesen und nur Bahnhof verstehen und ein "Streiten" sehen, …

[tuxie]

Hier gibt es zwei Meinungen, du hast eine und 1st1 hat eine, und jeder verteidigt seine Meinung. Ich finde die Firebee genial, und ich finde auch eine Beschleunigerkarte genial, und meine Meinung ist das sich beides Ergänzen wird weil der anreizt für Ataris wieder mehr wächst.

[Mathias]

Nein, es gibt eben nicht 2 Meinungen! Genau das ist der Punkt. Es gibt lediglich eine Unterstellung. Welche da war:

Oder ist es eine Art Bedrückung, weil so eine tolle Hardware aus dem Amiga-Lager kommt und sich jetzt anschickt, den ST zu erobern? Warum muss man TOS kennen um eine schnelle CPU in den ST zu verpflanzen? Gefahr für die Firebee? Angst?

Und ich tue nichts anderes als mich gegen diese Unterstellung zu wehren, weil sie jeglicher Grundlage entbehrt.

Und Du reproduzierst das hier wieder, … obwohl ich nichts gegen eine flotte Upgradekarte mit Grafik hätte!

[1ST1]

Ja, Mathias, du hast natürlich vollkommen recht, es darf nur deine Meinung geben! Keine andere, wirklich nicht. Du hast hier die einzige Deutungshoheit.

Ps: Ich bleibe bei meiner Meinung. Wer will noch eine Firebee haben, wenn er für hoffentlich wesentlich weniger Geld eine viel kompatiblere Vampire mit ansonsten ähnlichen Leistungsdate in einem kleinen ST haben kann? Tipp: Schonmal mit kleinen STs eindecken.

[1ST1]

Nochwas gefunden, das macht sprachlos...

Code: [Auswählen]

      CPU      MHz   CARD                MIPS
      68020     14    A1200                 2
      TG68            Mist                  4
      68020     28    Blizzard 1220         4
      68030     26    ACA1233               4.2
      68030     50                          6
      Coldfire 266    Firebee               8
      68040     28                         19
      68040     40                         27
      68060     50                         32
      68060     80    A1200+Apollo1260     46
      68080     78    Vampire GOLD         86
      68080     92    Vampire GOLD2       165
Die 8 Mips der Firebee sind natürlich bescheiden. Das liegt daran, dass in dem MIPS Benchmark der DBRA Befehl benutzt wird, den Coldfire nicht kann, und emuliert werden muss. Ansonsten stünde die Firebee deutlich besser da,

[MJaap]

Nochwas gefunden, das macht sprachlos...

Die 8 Mips der Firebee sind natürlich bescheiden. Das liegt daran, dass in dem MIPS Benchmark der DBRA Befehl benutzt wird, den Coldfire nicht kann, und emuliert werden muss. Ansonsten stünde die Firebee deutlich besser da,

"Geben Sie sich in Zukunft bei der Rechenleistung nicht mit weniger als 20 VAX-Mips (Millionen Befehle pro Sekunde) zufrieden." (Richard Miller)

Im Ernst: Diese reinen Rechen-Benchmarks sind natürlich wenig sinnvoll und selbst komplexe Grafik-Benchmarks auf dem PC haben damit zu kämpfen, dass Hersteller ihre Treiber auf die Benchmark-Tests optimieren. Man muss eben doch reale Hard- und Software vor sich haben, um festzustellen, ob die Kiste "schnell genug" ist.

[gh-baden]

Nochwas gefunden, das macht sprachlos...

Code: [Auswählen]

      CPU      MHz   CARD                MIPS
      68020     14    A1200                 2
      TG68            Mist                  4
      68020     28    Blizzard 1220         4
      68030     26    ACA1233               4.2
      68030     50                          6
      Coldfire 266    Firebee               8
      68040     28                         19
      68040     40                         27
      68060     50                         32
      68060     80    A1200+Apollo1260     46
      68080     78    Vampire GOLD         86
      68080     92    Vampire GOLD2       165

Vom 68040 mit 40 MHz zum 68060 mit 50 MHz nur 20% schneller? Aber vom 68040 mit 28 Mhz zum 68040 mit 40 ganze 40%? Komische Werte :-)

[1ST1]

Habe - auf der Suche nach Vergleichswerten für z.B. Intel-CPUs mittlerweile auch einen MIPS Wert von 44 für 68040-40 gefunden. Traue keinem Benchmark, den du nicht selbst gefälscht hast. Aber dennoch, selbst wenn das nur tendentiell stimmt, ist es dennoch ein Hammer.

[czietz]

Nun wissen wir nichts (Source Code?) über diesen Benchmark, den Du ausgegraben hast. Wenn ich als Hersteller meine CPU irgendwo gut aussehen lassen will, kann ich problemlos einen Benchmark maßschneidern, der genau das erreicht. Z.B. kann ich das ganze so fein tunen, dass es auf meiner CPU vollständig (Code + Daten) im Cache läuft, bei der "Konkurrenz" aber viele Cache-Misses produziert => voilà, Ergebnis zu meinen Gunsten verfälscht.

MIPS sind als Maßzahl einfach so undefiniert, dass sie ohne genaue Beschreibung des Benchmarks kaum Aussagekraft haben -- ein Vergleich zu anderen Architekturen (Motorola 68K vs. Intel x86) ist daran erst recht nicht möglich. Nicht ohne Grund werden MIPS manchmal auch als Meaningless Indication about Processor Speed bezeichnet.

[Börr]

Jetzt muss ich doch was schreiben, die Benchmarks kann man sich von der Apollo Seite runter laden. Da laufen aber viele Apollo Befehle nicht direkt unter der Firebee. Wenn wer helfen will die Benchmarks zum laufen zu bringen, bitte
Und zum Vampire gegen Firebee: Ich habe eigentlich gehofft den Apollo Core in die Firebee zu bekommen zum ausführen der alten Software. Ein St mit 68080 ist was ganz anderes wie eine Firebee, wenn man beides auf dem Schreibtisch liegen hat und direkt vergleichen kann wird man das merken.
Und das rummgezänke ist ja fast schon AMIGA!

[Nervengift]

Aus @Mathias Sicht muss man ihm vollkommen Recht geben. Das ACP ist ein Open Source Projekt, das kein Geld verdienen muss, will und wohl auch nicht kann. Daher ist es konkurrenzlos. Die Hardware steht seit Graumen und das Design ist offen, Software ist auch soweit verfügbar. Im Grunde kann jeder, der die Möglichkeiten hat, die Firebee nachbauen und weiterentwickeln. Da ist es dann unerheblich ob jetzt weiterhin Firebees verkauft werden oder nicht. Nichts muss aber vieles kann. Wenn in Sachen Firebee nichts weiter passiert, dann ist das vielleicht nicht gut für den Fortschritt des Projektes. Aber ansonsten stimmt das schon, die Biene ist konkurrenzlos sogesehen.

Ich kann @1ST1 Euphorie nicht wirklich nachvollziehen. Es ist derzeit nicht wirklich abzusehen was in Sachen Vampire und Atari ST auf uns zukommen wird und was das Board letzten Endes können wird. Insofern finde ich Dein Verhalten auch etwas übertrieben, wenn Du jetzt das Vampire Board mehr oder minder in den Himmel hebst und als das non plus ultra darstellst, die Firebee dagegen als total unterlegen ansiehst. Das halte ist - vor allem in dieser frühen Phase - für total zu kurz gegriffen. Das wird sich nachher zeigen, wenn die Vampire für den ST verfügbar sein wird.

Ich würde mir sicherlich auch sofort ein(e) Vampire080 kaufen, wenn es eine stand alone Variante gibt und das Vampireboard in einem handelüblichen Format ausgeliefert wird (z. B. ITX, ATX etc.). Dabei sollten die seriellen Schnittstellen, parallele Schnittstelle, IDE (SATA), Ethernet, Sound, HDMI (DVI, VGA) ect. nicht fehlen und Anschlüsse vorhanden sein bzw. einfach nach draußen zu führen sein. Dann hätte man einen leistungsfähigen, kompatiblen Atari 68k Clone. Wie gesagt "hätte". Warten wir ab was passieren wird. Aufgrund früherer kommerzieller Projekte in Sachen TOS-Clones bin ich erstmal entsprechend zurückhaltend.

Die/das Vampire bietet mit Sicherheit einige Chancen für die TOS-Szene, aber ich sehe eben auch Gefahren. Ich hoffe aber letzten Endes, dass man Chancen nutzen kann und es vielleicht auch zu einer Zusammenarbeit zwischen ACP und Vampireprojekt kommen kann. Vielleicht mag es auch in Sachen Software nochmal etwas neues kommen. Warten wir es ab.

Mag einer nochmal einen Link zur offiziellen Vampire-Seite posten und zu dem angesprochenen Forum? Vielleicht macht eine Anmeldung in dem Forum Sinn. Alleine schon deswegen um gar nicht Gräben entstehen zu lassen und Leute zusammenzubringen.

[Börr]

http://apollo-core.com/
http://apollo-accelerators.com/
Gibt es c sourcen von dicken Demos? Dann würde ich die mal durchbauen/lassen, um zu sehen wie die beiden Boards da gegenüber stehen.

[1ST1]

Dieser massive Unterschied im Benchmark von Vampire Gold und Gold2 wird dadurch erklärt, dass man den Core Gold2 massiv optimiert hat, so dass er insbesondere sehr kleine Schleifen sehr schnell abarbeiten kann. Laut Entwickler kommen solche kleinen Schleifen in typischen 68K-Programmen sehr häufig vor (zumindestens auf dem Amiga). Bei größeren Schleifen wird der Vorsprung des Gold2 Cores nicht mehr so groß sein. Ich denke, es wird spannend, wenn auf der Vampire mal die ersten ST-Benchmarks (GemBench, Quickindex, etc.) laufen.

Übrigens wurde die Vampire inzwischen scheinbar schon versuchsweise in einem Mac mit 68000 CPU eingesetzt und soll dort in der Lage sein, MacOS zu starten, was angeblich nicht ganz trivial sein soll.

Einsatz des Apollo-Cores in der Firebee: Dann würde man wahrscheinlich den Coldfire garnicht mehr brauchen.

Derzeit hat das Vampire-Team einen festen Fahrplan (die Leute arbeiten schon etwa 8 Jahre an dem Thema) und noch einiges vor sich, hauptsächlich in Bezug auf den Amiga. Über den ST fangen die gerade an, sich Gedanken zu machen. Wie man aus dem Thread dort lesen kann, macht man sich jetzt erstmal dran, zu sehen, in welche ST-Modelle die Vampire 500 reinpassen kann, ohne die Platine zu ändern. Es soll aber bald auch mal ein Systemstart ausprobiert werden, erstmal deckt man sich wohl mit ST-Hardware ein. Ich habe die Leute schonmal auf Spezialitäten hingewiesen,die beim ST inkompatibel zum Amiga sein sollten (Realisierung eines IDE-Ports, Grafikkartenmöglichkeinen wie VHDL-ET4000 Nova/Vova/... komatibel (allerdings finde ich den ET4000 VHDL-Core nicht mehr...), Viking-SM-194-Graka, brauchbare TOS-Versionen, usw.) und weiteres. Sprich, auf ATARI Seite ist man noch recht am Anfang. Aber Gunnar ruft uns (also die ATARI Community) dazu auf, sein Team zu unterstützen, sei es ein VDI-Treiber für die SAGA-Grafik, oder Beischaffen von Schaltungsunterlagen/VHDL-Code für andere Grafiklösungen, IDE-Port, was auch immer, usw. Und wir müssen denen einiges auch noch erklären, die sind da nicht so tief drin, z.B. die Beduetung einer vollständigen 68kMMU für MiNT (und TOS 3.06). Gemeinsam schaffen wir das aber.

[tuxie]

Ich will deinen Optimismus eigentlich nicht Bremsen, aber der letzte Post von Gunnat deutet aber darauf hin das diese Entwicklungen einer FPU und eine MMU erstmal ganz hinten anstehen, und sie erstmal ihren Fahrplan abarbeiten und wenn dies geschehen ist wird es dort weiter gehen. Aus diesem Grund habe ich auf die Cores von Wolfgang Förster verwiesen da er dort schon eine Mamutaufgabe hinter sich hat und das Projekt davon Profitieren könnte.

[1ST1]

Auf Suska habe ich auch schon verwiesen, auch auf die MiST-ST-Cores (z.B. wegen implementierung einer Grafikkarte, scheinbar müssen die für den digitalen Grafikausgang die Originalgrafik nochmal implementieren). Eine FPU ist aber schon im 68080 drin, ihr fehlen nur ein paar (im Amiga?) garnicht benutzte Befehle, für die keine "Chipfläche" ver(sch)wendet werden soll. Das müsste halt mal von unserer Seite überprüft werden (welche Befehle, werden die in ST-Software auch nicht verwendet?). Eine rudimentäre "neue" MMU gibts auch schon, ich habe auch schon darauf verwiesen dass die Funktion der 68K-MMU für MiNT gebraucht wird. Oder das MiNT Kernel-Team müsste sich mit der Apollo-MMU auseinander setzen und schauen, ob die in MiNT alternativ nutzbar wäre.

[mfro]

Nochwas gefunden, das macht sprachlos...

Code: [Auswählen]

      CPU      MHz   CARD                MIPS
      68020     14    A1200                 2
      TG68            Mist                  4
      68020     28    Blizzard 1220         4
      68030     26    ACA1233               4.2
      68030     50                          6
      Coldfire 266    Firebee               8
      68040     28                         19
      68040     40                         27
      68060     50                         32
      68060     80    A1200+Apollo1260     46
      68080     78    Vampire GOLD         86
      68080     92    Vampire GOLD2       165
Die 8 Mips der Firebee sind natürlich bescheiden. Das liegt daran, dass in dem MIPS Benchmark der DBRA Befehl benutzt wird, den Coldfire nicht kann, und emuliert werden muss. Ansonsten stünde die Firebee deutlich besser da,

Ich habe mir den bewussten "Benchmark" mal angeschaut, der diese Werte liefert. Leider gibt's keine Quellen dazu, also musste der Disassembler ran. Die innere Schleife, die da gemessen wird, macht folgendes:

Code: [Auswählen]

addil #16,%d0
addil #16,%d1
addil #16,%d2
addil #16,%d3
addal #16,%a0
addal #16,%a1
addal #16,%a2
dbf %d6,0x486

Gemessen wird da also letztendlich nichts anderes als wieviele (in dieser Kombination in der Realität nicht auftretende) add-Instruktionen die CPU pro Sekunde ausführen kann. Praktisch werden tatsächlich die "MIPS" (Millionen Instruktionen Pro Sekunde) gemessen.

Und "natürlich" mit Befehlen, die der Apollo-Core tatsächlich parallel ausführen kann. Die Schleife ist sozusagen auf den Core "maßgeschneidert". Da ist nix gegen einzuwenden, aber keiner sollte glauben, daß das Ergebnis die reale Performance widerspiegelt.

Die Tatsache, daß die Firebee bei diesem Benchmark so miserabel abschneidet, liegt nicht *nur* an dem dbf-Befehl, den der ColdFire emulieren muß. adda.l gibt's auf dem Coldfire auch nicht. Gemessen wird hier also im wesentlichen die Geschwindigkeit der m68k-Emulation der cf68klib.

Jetzt bin ich einfach mal frech und baue den synthetischen Benchmark, der zu nix nütze ist, einfach mal so um, daß die Firebee den "Coldfire-native" ausführen kann:

Code: [Auswählen]

       move.l  %[loops],d6
       add.l   #1,d6
1:     addi.l  #16,d0
       addi.l  #16,d1
       addi.l  #16,d2
       addi.l  #16,d3
       lea     16(a0),a0
       lea     16(a1),a1
       lea     16(a2),a2
       subq.l  #1,d6
       bne.s   1b

Der Code macht im Effekt genau dasselbe, ist immer noch zu nix nütze, aber eben mit Befehlen, die der ColdFire-Prozessor direkt (und in einem Taktzyklus) ausführen kann. Dann sieht's plötzlich ganz anders aus:

Code: [Auswählen]

ran 7.595000 seconds, MIPS: 210.664917
Daß da nicht 264 steht - entsprechend der FireBee-Taktfrequenz von 264 MHz - liegt daran, daß ich der Fairness halber nicht durch 9, sondern noch immer durch 8 geteilt habe, Coldfire muß die dbf-Entsprechung in zwei Befehle/Taktzyklen aufteilen. Die Interrupts habe ich im übrigen auch nicht abgeschaltet, weil ich nicht weiß, ob das Original das tut.

Aber das ist noch nicht das Ende der Fahnenstange. Schließlich geht's hier nur darum, (ansonsten sinnlose) Befehle so schnell wie möglich auszuführen...

Also noch ein bißchen frecher:

Code: [Auswählen]

               move.l  %[loops],d6
               add.l   #1,d6
        1:     addi.l  #16,d0
               mac.l   d0,d1,acc0
               addi.l  #16,d1
               mac.l   d0,d1,acc0
               addi.l  #16,d2
               mac.l   d0,d1,acc0
               addi.l  #16,d3
               mac.l   d0,d1,acc0
               lea     16(a0),a0
               mac.l   d0,d1,acc0
               lea     16(a0),a1
               mac.l   d0,d1,acc0
               lea     16(a0),a2
               mac.l   d0,d1,acc0
               subq.l  #1,d6
               bne.s   1b

Auch der Coldfire-Prozessor kann (manchmal) zwei (in diesem Fall ebenso unnütze) Befehle gleichzeitig ausführen, wenn man seine EMAC Units ein wenig beschäftigt. Die Befehle sind alles andere als trivial (eine Multiplikation und eine Addition in einem Befehl), trotzdem werden sie in einem Taktzyklus abgearbeitet (im besten Fall, den ich nicht hinbekommen habe, auch in einem halben).

Code: [Auswählen]

ran 12.935000 seconds, MIPS: 262.852717
Warum hier keine besseren Werte rauskommen (also "echtes" superskalar x 2), weiß ich (noch) nicht. Die EMAC Units sind ein bißchen zimperlich, was die Registernutzung angeht und ich habe noch zu wenig damit gemacht um wirklich dahintergekommen zu sein, welches Register man wann "ungestraft" anfassen darf.

Die Werte des Apollo-Cores sind selbstverständlich beeindruckend. Einen so komplexen CPU-Core wie den des 060ers mit der Taktfrequenz ans Rennen zu bekommen, ist alles andere als trivial. Ich betone, ich will den hier absolut nicht schlechtreden, mir geht's nur darum, die Sinnlosigkeit solcher Benchmarks aufzuzeigen.

[1ST1]

Darf ich das mal ins apollo-Forum rüberposten? Vielleicht lassen die ja die Variationen mal auf dem Apollo-Core laufen?

[mfro]

Darf ich das mal ins apollo-Forum rüberposten? Vielleicht lassen die ja die Variationen mal auf dem Apollo-Core laufen?

Klar darfst Du. Allerdings wird der zweite Teil nicht laufen bzw. in die entsprechenden Apollo-Gegenstücke umgewandelt werden müssen (falls es die gibt).

Der erste Teil wird niemanden erstaunen, der ungefähr weiß, was in der cf68klib passiert, bringt also keinen wirklich weiter.

Die fehlenden Instruktionen/Adressierungsarten sind zweifellos eine Einschränkung der Coldfires/FireBee, aber - mit realem Code - bei Weitem nicht so drastisch wie der "Benchmark" den Eindruck erweckt.

Dasselbe gilt übrigens auch für (zumindest einen) der anderen Benchmarks, den ich mir kurz angeschaut habe. Dort wird in einer Schleife mit NOP-Instruktionen gemessen (also, wie lange es dauert, "nichts" zu tun).

Dummerweise ist der ColdFire aber "beim Nichtstun besonders langsam". Die NOP-Instruktion braucht nicht nur selbst 6 Taktzyklen, sondern macht auch noch einen Pipeline-Flush (danach läuft die CPU mit nochmal sechs Takten Latenz erstmal neu an). Ersetzt man die NOP-Instruktion durch TPF (macht auch "nix", aber in nur einem Zyklus und spart sich den Pipeline-Flush), läuft die entsprechende Schleife 12 Mal schneller (aber auch das ist sehr synthetisch: kein realer Code wird unnötig lange "nichts" tun).

[1ST1]

ADD.L #imm,An is fully supported by Coldfire.
Please check this yourself in Coldfire Programmer Reference Manual Page 4-4

Boah, die Antwort hier herüber zu setzen ist mir zu viel, er hat sehr ausführlich geantwortet... Du hast die äußere Schleife vergessen und die damit zusammenhängende Sprungvorhersage. Jedenfalls so tief bin ich in der 68K Assembler-Geschichte nicht mehr drin dass ich da jetzt eigenständig antworten könnte, ihr beide aber schon. Schau mal, vielleicht beteiligst du dich auch direkt an der Diskussion...?

http://www.apollo-core.com/knowledge.php?b=1&note=2559

Für die Allgemeinheit nur kurz: Der Apollo läuft derzeit bei 80-90 MHz, was mit dem verwendeten bezahlbaren FPGA zusammen hängt. Damit kann Apollo aber schon flüssig MPEG dekodieren, laut Aussage bei manchen Videos sogar flüssiger als ein PPC mit 600 MHz in einem Amiga-NEO System. Man kann auch eine Vampire in der Preisklasse der Firebee bauen, mit einem entsprechenden FPGA und dann taktet das Ding bei 200 MHz, und wenn die ATARI- und AMIGA Gemeinde zusammen stehen würden und es verlangen würden und sich leisten könnten wäre auch ein ASIC mit 1 GHz möglich... Klingt auf jeden Fall vielversprechend.