Nach dem bedauerlichen Weggang von Fredi Aschwanden macht das Atari Coldfire Project trotzdem Fortschritte. Ein zweites Entwicklertreffen wurde dazu genutzt, Kontakte zu pflegen und Pläne zu diskutieren.
Eines vorweg: es ist üblich, das nicht alle Dinge, die auf einem Entwicklertreffen besprochen und beschlossen wurden, veröffentlicht werden. Dies ist nicht nur auf dem Atari-Markt so, denn Meldungen, die eventuell schnell revidiert werden müssen, helfen niemanden.
Das Treffen fand im beschaulichen Rimbach statt, einem Dorf in Hessen, das nicht allzuweit entfernt ist von Frankfurt. Hier finden Programmierer Auslauf in einer schönen Waldlandschaft, die allerdings in Teilen verdächtig an "Blair Witch Project" erinnert. Die Nachbarschaftswache übernehmen die zwei Katzen von Oliver Kotschi, dem Leiter des Project Coldfire. Nicht weit entfernt von dessem Wohnort liegt in der "Innenstadt" der Laden von Oliver, der von Tabakwaren bis Barbie-Puppen so ziemlich alles anbietet. Der Termin für das Entwicklertreffen richtete sich ganz nach Jörg Willhelm, der kurz zuvor an das ACP-Team mit einem Angebot herangetreten ist. Zuerst war das erste oder zweite Oktoberwochenende im Gespräch, aber kurzfristig wurde es auf das letzte Wochenende im September verlegt. Dadurch konnten zwangsläufig weniger am Entwicklertreffen teilnehmen, aber die Kapazitäten, d.h. Olivers Wohnung waren auch begrenzt. Die Teilnehmer waren im einzelnen Markus "PCI-Bios" Fichtenbauer, Elmar "Deesse" Hilgart, Alexander "Umfrage" Feige und Norman Feske. Bei der Aufzählung fehlt natürlich der Name Jörg Willhelm. Diesem ist bedauerlicherweise das Auto kurz vor dem Treffen kaputt gegangen, so das am Freitag mittag kurzerhand eine Telefonkonferenz abgehalten wurde.
Das Board von Willhelm Elektronik wird nicht speziell für den Atari, sondern für den industriellen Bereich entwickelt, in dem der ColdFire zuhause ist. Auslieferungsdatum und Preis waren schon im Vorfeld unrealistisch, denn es fehlt u.a. das TOS. Das Willhelm-Board basiert auf dem Micro-Server-System der gleichen Firma, das mit einem ARM-Prozessor läuft. ARM-CPUs sind vom Embedded-Bereich bekannt und stecken ansonsten auch in RiscPCs und dem GameBoy Advance. Dem Microserver hinzugefügt werde sollte nun eine PCI-Karte, die den ColdFire enthält. Das "Board" ist letztendlich "nur" eine Reihe von PCI-Slots, die eine ARM-, Ethernet-, Grafik- und eben die ColdFire-Karte enthalten soll. Dies ist im industriellen Bereich praktisch, da alle Komponenten schnell austauschbar sind. Für den Heimbereich, der mit dem ACP letztendlich beliefert werden soll, ergeben sich daraus einige Probleme. So hängen die PS/2-Maus und -Tastatur an der ARM-Platine. Dies bedeutet, das der ColdFire zum lesen der Tastatureingaben einen Umweg über den PCI-Bus und die ARM-Karte einschlagen müßte. Damit wäre der ARM mit 220 MIPS (Generation 1-Board) bzw. 600 MIPS (Generation 2) der wohl schnellste Tastaturprozessor überhaupt. Das Ausweichen auf USB-Mäuse und -Tastaturen kommt wegen fehlender Treiber nicht in Frage, zumal dies einen sehr hohen Entwicklungsaufwand bedeuten würde. Die derzeitige Planung sieht zwei Boards vor, die sich auf dem Datenblatt hauptsächlich durch verschiedene Versionen des ARM/ColdFire unterscheiden. In der Telefonkonferenz hat sich herausgestellt, das ein Zwischenboard gebaut wird, dessen Preis noch nicht feststeht, aber zwischen dem angepeilten Preis von Board 1 (600 EUR) und Board 2 (900 EUR) liegen sollte. Geklärt werden konnte die Frage, welcher Prozessor die Bootphase erledigen soll. Voraussichtlich kann die gewünschte CPU per Jumper festgelegt werden. Das Hauptproblem bleibt das Zwei-Prozessor-Design. Der ColdFire wird dem Board nur hinzugefügt. Der ARM wäre nicht nur ein teurer Tastaturprozessor, sondern würde noch mehr Entwicklungsarbeit bedeuten. Schließlich müßten zumindest Mini-Programme für den ARM geschrieben werden, die Tastatur- und Mausmeldungen an den ColdFire weiterleiten. Praktisch würde es bedeuten, zwei Betriebssysteme zu schreiben, denn schließlich muß auf dem ColdFire auch ein Betriebssystem laufen. Für ein ARM-Betriebssystem existiert im Atari-Bereich kein Fachwissen und es ist auch schwer dies von Leuten zu verlangen, die praktisch ehrenamtlich Zeit in das ColdFire-Projekt stecken. Die Möglichkeiten des ARM als leistungsfähigen Coprozessor wären wohl auf lange Zeit ungenutzt - im Gegensatz zum DSP der Deesse, in der ein Nachfolge-Chip zum DSP56001 des Falcon steckt. Das nächste grundlegende Problem sind die Hardware-Adressen. Da das System nie als Atari-Clone konzipiert war, liegen alle Hardware-Devices und -Adressen irgendwo im Speicher. Neben den eigentlichen Gerätetreibern müßte auch der Festplattentreiber angepaßt werden. Auch die Verwendung des Open Source-TOS EmuTOS wäre aufwändig, da es sich auf die Original-Atari-Adressen verläßt. Dies ist eben nicht mit einer Neukompilierung erledigt. Hier wäre es wichtig, wenn in das neue Board ein Adreßmapper eingebaut wird, der PS/2, serielle, parallel, Floppy und IDE an die gewohnten Adressen legt. Als Grafikkarte ist eine ATI Rage Pro eingeplant. Ob diese in genügend Stückzahlen vorhanden ist, muß sich noch zeigen, da sie eigentlich vor vier Jahren aktuell war. Die Grafikkarte hängt wie alle anderen Komponenten am PCI-Bus, inwieweit sich das auf die Geschwindigkeit auswirkt, könnte erst anhand eines Prototypen getestet werden, der jedoch noch nicht vorliegt.
Nach eingehender Diskussion wurde eine "Liste" ausgearbeitet, in der die wesentlichen Punkte aufgeführt sind, die eine Verwendung des Willhelm-Boards erleichtern würden:
Leider hatte Jörg Willhelm einen Termin, so das die Antwort nicht mehr rechtzeitig eintrudelte.
Erfreulich ist, das sich neben Rodolphe Czuba noch weitere potentielle ACP-Mitstreiter gemeldet haben. Es sei auch noch einmal darauf hingewiesen, das die ACP-Gruppe kein elitärer Zirkel von seltsam murmelnden dunklen Gestalten ist, die FPGA-Chips huldigen. Dies zeigt auch die Teilnahme von Alexander Feige, dem Initiator der großen Atari-Umfrage. Wie in Atari-Forem bereits zu lesen war, hat er einige Ideen zur Vermarktung des ColdFire, die beim Rest des Teams auf offene Ohren stießen.
Vermutlich wird zum Erscheinen dieses Artikels schon mehr bekannt sein. Die von einigen geforderten regelmäßigen Updates soll es geben, wenn auch nicht täglich, sondern z.B. jede Woche einmal.