Gunnar hat mich gerade angerufen...
Er wird hier bald selbst was schreiben. Aber nur kurz so viel: Hast du mal einen FPGA selbst programmiert, und gesehen, was du - ich nenne es jetzt mal so - da für "Libraries" vom FPGA-Chiphersteller dazu linken musst, damit da überhaupt mit dem konkreten Chip was funktionierendes bei rumkommt? Das ist auch bei Open-Source-Projekten wie Firebee und MiST so. Und diese Libs sind auch nicht Open-Source. Wenn das mit dem MIxen von Closed/Open-Source so wäre, dann gäbe es kein MiST und auch keine Firebee, weil die natürlich auch diese Libs verwenden müssen. Es ist überhaupt kein Problem in einem FPGA Closed-Source-Code und Open-Source zu kombinieren, sofern man sie nicht durchmischt, sondern fein und sauber mit einem definierten Busprotokoll verbindet. Man kann die Funktionseinheiten voneinander getrennt in den FPGA reinhämmern, so wie auf einer Platine verschiedene Chips sind, die mit einander kooperieren.
Also, ihr könnt Gunnar vertrauen, er hat mir erzählt was er wo schon alles gemacht hat, ich musste mich auf jeden Fall erstmal setzen um das zu verdauen. Nein, falsch, auf dem Sofa hielt ich es nicht mehr aus und musste in der in der ganzen Wohnung "rumkreisen"... Da ich früher selbst in einer Branche unterwegs war, die von dem profitiert, was er machte und ich auch solche Leute bei namhaften CPU- und Chipsatz-Herstellern damaliger PCs kannte kann ich das gut einschätzen. Er ist auf jedenfall nicht einfach irgendein Team-Mitglied, sondern einer der Hauptentwickler des Apollo-Kerns.
Im Apollo stecken hochaktuelle Technologien drin, was z.B. das Pipelining angeht, Branch-Prediction, vermutlich auch Register-Renaming und pipapo was so in topaktuellen CPUs von den bekannten Herstellern intern abgeht. Und das bei voller 68040/60-Kompatiblität. Nur viel Schneller und (erstmal) abgesehen von der PMMU, nur die erwähnte MCU ist viel leistungsfähiger, man könnte darin aber die PMMU voll registerkomatibel abbilden, das ist halt nur viel Arbeit. Manches, z.B. das Ausführen von 64-Bit-AMMX-Befehlen auf einer 32-Bit-CPU ohne Rückhermöglichkeit in 32 Bitmodus irgendwie in einen 64-Bit-Modus, siehe AMD64, zu schalten, hat er sich sogar patentieren lassen.
Der Apollo bleibt Closed-Source weil er einen Geldgeber hat, der den Apollo auch nutzen will, in einer Form, die neben den Beschleunigern für Amiga und ST auch der Szene auf eine andere Weise zu gute kommt. Der Geldgeber will da natürlich nicht, dass irgendein Hansel das dann einfach so nachbaut und selbst Geld mit verdient. Der SAGA wird/ist aber Open-Source. Und in SAGA lässt sich ST-Kompatiblität "reinmappen", ganz ohne neues VDI zu schreiben. Näher will/kann ich das hier nicht schreiben, mir raucht jetzt noch der Kopf...
Während wir telefonierten, compilierte er gerade eine neue Core-Version die 2 AMMX Befehle pro Takt ausführt. Der weiß was er tut. Er sagt z.B. dass der SAGA-Grafikkern schon alle Videomodes des ST, TT und Falcon schon kann. Außerdem auch diverse PC-VGA-Modis (wahrscheinlich auch ET4000, winkewinke?) und natürlich die Amiga-Modis. Er muss für TOS/Softwarekompatiblität nur wissen, wo er die entsprechenden Hardwareregister hinmappen soll. Da braucht er Hilfe, für ST/STE/TT hab ich ihm jetzt erstmal das Profibuch ans Herz gelegt, da findet er erstmal einen Anfang. Das Team braucht da aber noch Hilfe, und je schneller desto besser. Im ersten Moment müsst ihr da garnix mit VHDL oder Assembler machen, es muss erstmal nur ein für TOS passendes Register-Mapping her.
Der Apollo-Core arbeitet mit - neben dem 68K-Bus-Protokoll - mit einem Industrie-Standard-Busprotokoll, an dem z.B. auch ARM-CPUs andocken können. Er hatte mir den Namen gesagt, aber 1,5 Stunden vollgepackt mit Infos, da kann man sich nicht alles merken, habe ich auch noch nie vorher gehört, aber da bin ich technisch aktuell auch nicht "drin". Der Bus ist voll dokumentiert und jeder kann da Chip-"Module" liefern. Jedenfalls ist im FPGA-Core noch viel Platz drin, wo dann aus der Community VHDL-Code zugeliefert werden kann, z.B. Yamaha-Sound, STE/Falcon-Sound, usw. Und das parallel zur Unterstützung von Amiga-Hardware. Der Apollo bekommt einen "Schalter" mit dem dann einfach das ein und aus geknipst werden kann, was gerade gebraucht wird, oder nicht, um ein ST oder Amiga oder sonstwas zu sein. Und demnächst kommt auch eine neue Turbokartenplatine als Nachfolger von Vampire2, die zum einen Massenproduktionsfähig ist, größerer/schnellerer FPGA und zum anderen 1 GB RAM hat... (Dann ist die für über 800 Euro zum Spaß versteigerte Vampire 2 schon wieder "alt")
Er bietet auch dem Firebee-Team seinen Core an, der dann anstelle der Coldfire verwendet werden kann, man muss nur fragen. Ja, und die Firebee braucht eine neue Platine, ja, teuer, Bedenkenträger blah... Ihr müsst nur endlich mal das Brett wegnehmen und euch auf das einlassen, was er anbietet.
Übrigens, hatte jemand aus dem Team eine Vampire2 schon mit TOS 2.06 hochkommen lassen. GEM-Desktop schien da zu sein, aber er konnte wohl nichts machen. Da ich nicht weiß, was für Registermapping schon gemacht wurden, kann ich natürlich nicht sagen, warum keine Bedienung des Systems möglich war, was auch immer...
So und jetzt hoffe ich, dass sich Gunnar hier noch meldet, wie besprochen. Er kann das alles euch noch viel besser erklären als ich.
Der Zug rollt schon, springt auf! Das was jetzt geliefert wird, ist in der neuen Platine schon drin.
Jetzt ist es doch etwas länger geworden... Gunnar, melde dich mal hier.
