a) Ein Prozessor braucht RAM, damit Software darazuf laufen kann. Der am FPGA der Firebee angeschlossene 128 MB RAM wird schon als Video-RAM verwendet, da bleibt je nach Auflösung, Farbtiefe, Refreshrate usw. nicht sooo viel übrig, und durch den Shared-Betrieb (CPU+Video) würde die CPU evtl. ausgebremst.
Aha. Und wo denkst Du, wird wohl das Video-RAM der SAGA Grafik in der Vampire liegen?
b) Wer 512 MB RAM in einem Rechner bezahlt, will diese auch nutzen. Mit dem Apollo-Core geht das nicht.
Kann er doch. Mit den Programmen, die auf dem ColdFire laufen. Und das sind eine ganze Menge.
Ansonsten: zeig' mir ein Atari-Programm, das mehr als 16 MB Hauptspeicher braucht. Zeig' mir eins, das überhaupt mehr als 64 MB (sinnvoll) nutzen kann.
c) Schau mal ins Blockdiagram der Firebee, was an PCI noch alles do dran hängt. Ohne den PCI-Bus verliert die Firebee einige wichtige Schnittstellen.
Du darfst mir gerne glauben, daß ich die Innereien der FireBee ein wenig besser kenne als Du.
USB hängt da mit dran, ja. Das heißt, um von einem FPGA-m68k aus USB nutzen zu können, muß der mit dem ColdFire reden. Na und? Das macht der MiST (beispielsweise) genauso. Soweit ich weiß, hat sich da noch keiner dran gestört.
f) (emu)TOS/GEM/MiNT ist keine Multiprozessing-Umgebung, und schon garnicht asymmetrisch (zwei verschiedene CPUs, wenn auch artverwandt, aber das bekommen ja nicht mal moderne Betriebssysteme hin)
Hast Du den MiST-Eigentümern, die mit ihren Kisten (m.E. zurecht) sehr zufrieden sind, auch schon erklärt, daß das, was sie da machen, gar nicht funktionieren kann?
g) Coldfire und 680x0 sind auch nicht Open-Source. Die ganzen Zusatzchips in der Firebee sind auch nicht OpenSource. Und die zum Erstellen/Linken der Binärpakete für den FPGA-Chip erforderlichen Biblioteken von Altera/Intel sind auch nicht als OpenSource rausgegeben. Daher ist der Status des Apollo-Cores irrelevant, solange das Team bei der Implementierung hilft und ggf auch Anpassungen macht - und das tun sie, wenn es erforderlich ist.
Und genau hier kommen wir zum Kern der Sache. ColdFire, m68k und PIC sind tatsächlich nicht frei. Völlig richtig. Aber die sind *fertig* und *fertig dokumentiert*. Daran will ich gar nichts ändern können.
Ich bin zu Atari-Zeiten schon zu oft in eine Sackgasse gerannt, um eine solche heutzutage nicht zu erkennen. Wenn die Apollo-Jungs morgen keine Lust mehr haben (haben sie die denn heute?), Ataris zu unterstützen, stehst Du im Regen.
Eine Kombination aus freier Soft-/bzw. Configware und dem Apollo-Core kommt für mich (und mit mir) schlicht nicht in Frage. Es würde den wesentlichen Grund, warum ich die FireBee gekauft habe, für mich zunichte machen: alles was man daran ändern kann, kann (und darf) man daran ändern. Den Finger auf jedes einzelne Bit legen, wenn man will (und kann). VHDL lernen und den Core ändern. Sogar ein neues Board daraus designen (wenn man ...).
Wenn da unbedingt ein m68k-Core ins FireBee-FPGA sollte, würde ich lieber den von Wolfgang Förster (oder den TG68k) nehmen. Auch wenn die ein bißchen langsamer wären.
Zum Thema Apollo-Team und Atari-Unterstützung. Ich würde nie jemandem vorwerfen, wenn und daß er im Wesentlichen in seinem eigenen Interesse handelt (mach' ich ja schließlich auch meist). Aber ich kann erkennen, wenn das jemand tut und mir überlegen, ob dieses Interesse auch meins ist.
Von Seiten Apollo-Team habe ich bislang nur gesehen, daß Atari-Support genau so weit geht, wie das eigenen Interessen dient: die Anzahl der potentiellen Käufer zu erhöhen, damit sich eine professionelle Serienfertigung lohnt. Darüber hinaus war noch nichts zu sehen und konkrete Fragen blieben unbeantwortet. Soll jeder selbst sehen, wohin das führt und ob ihm das reicht.
