Was sollte bei einer neuen Firebee-Auflage evtl geändert bzw verbessert werden?

[michschmi]

Um das mal klarzustellen, ich bin kein UNIX Typ aber ich hätte erwartet das NFS möglich ist, das entsprechende Modul ist aber nicht vorhanden oder mal mc in der bash laufen lassen oder auch iperf um die Netzwerkgeschwindigkeit zu messen ...

Mein Hauptsystem ist mein Mac mit OSX und das ist finde ich vergleichbar. OSX ist ein BSD UNIX Clone mit dem Finder obendrauf ...

So stelle ich mir auch MiNT mit XaAES vor. Als Anwender Programme sollen natürlich GEM Programme laufen ...

mal für Lukas stellvertretend:

Du weißt aber auch, dass das nicht alles erst seit gestern mit einem 3-Mann-Projekt umgesetzt wird? Es ist eben schon lange kein reiner  BSD-Clone, sondern da steckt NeXt-Code drin und wer weiß, was noch alles; NeXt gibt es seit Ende der 80er, nachdem Jobs bei Apple gegangen ist; also stecken in OSX nun summa sumarum um die 25 Jahre Entwicklungszeit. Vorteil war auch, dass die Anforderungen anfangs klein waren, dass immer eine gewisse Zeit da war, um etwas umzusetzen; dass System ist gewachsen. Die Firebee-Umgebung soll jetzt aber mit wenig Leuten eine eierlegende-Wollmilchsau in Fingerschnippgeschwindigkeit auflegen; dass das nicht funktionieren kann, nicht funktionieren wird, müsste eigentlich klar sein?! Denn das Grundproblem ist doch, dass man immer noch mit 30 Jahre altem Betriebssystem-Code rumwerkelt, der sich anders als Apple-OS X nie zu etwas entwickelt hat, was auch nur ansatzweise mit einem BS anno 2014 mithalten kann. Um alles umzusetzen, müsste man

a) die klompletten Sourcen haben

b) ein Team aus mindestens 20 Leuten haben

c) mal 3 Jahre nichts neues vemelden müssen

und das Wichtigste
 
e) mal mindestens 3 Millionen Euro Entwicklungsbudget haben

Dann, nur dann wäre es meines Erachtens möglich, einen vollfunktionsfähigen Atari-Clone zu schaffen, der dann auch in der Lage wäre, in einer komplett virtuellen Maschine alte 68k-Software laufen zu lassen, wo auch der Romport funktioniert

Da es das aber nicht geben wird, muß man mit dem tröpfchenweise Eintrudeln von Ergänzungen wohl leben.

Und eines müsste auch jedem klar sein: Wenn es Atari weiter gegeben hätte, wpürde das TOS mit großer Sicherheit nicht mer so aussehen, wie es anno 1993 ausgesehen hat. Ich will nicht sagen, dass es in die Apple-Richtung gegangen wäre, aber komplett anders wäre es sicherlch. Dass das Potential da war, hat man ja gesehen, da Atari meines Wissens noch vor Apple ein "Pad", den Stylus, präsentiert hat.

[mfro]

Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet!

Ich fürchte, ich äußere jetzt mal wieder einen ganz abwägigen Gedanken. Aber bestünde auch die Möglichkeit, einen FPGA-Entwickler zu beauftragen und zu bezahlen?

Davon halte ich - ehrlich gesagt - nicht besonders viel. Fähige FPGA-Entwickler sind mit die bestbezahlten Leute in der Branche. Was Du also für (realistisches) Geld bekommen wirst, ist höchstens zweit- oder drittklassig, wenn Du nicht gerade jemanden findest, der ein bißchen noch nicht ganz eingetrocknetes Herzblut für die alten Ataris übrig hat.

Den Leuten, die dafür auch nur ansatzweise in Frage kämen, ist der Mathias - so wie ich ihn kenne - ganz bestimmt schon mehr als einmal diesbezüglich auf die Nerven gegangen (und das meine ich im positivsten Sinn!).

Natürlich ist es nicht völlig ausgeschlossen, daß man jemand fände, der irgendwas in VHDL auf die Beine stellte und irgendwas ans Laufen bekäme. Wenn das Ergebnis aber un- oder schlecht dokumentierter, möglicherweise noch schlecht strukturierter Code wäre (zu einem bezahlbaren Preis eher wahrscheinlich), wären wir nach einer Weile wieder in genau derselben Situation: wir säßen wieder da mit einem halbwegs funktionierenden, aber unvollständigen Core und würden händeringend nach Entwicklern suchen, die das nächste fehlende Falcon-Feature einbauen sollen. Bloß daß der Aufwand (und damit der Preis) sich nochmal neu einzuarbeiten, bei jeder Schleife stiege.

Es wird m.E. einfach nicht anders (weiter) gehen, wenn sich nicht einer (oder besser mehrere) aus der Atari-Szene findet, der sich da einarbeitet. Nur so kann sich ein Open-Source Projekt weiterentwickeln.

"es gibt nichts Gutes, außer man tut es".

Ich hätte den Blitter endlich gerne umgesetzt

Warum?

Ein Falcon-kompatibler Blitter ist in der Firebee grob ungefähr 40x so unnütz wie einer in einem TT. Dort hat Atari den Blitter schon weggelassen, weil er nur Geld gekostet, aber nichts gebracht hätte. Heute schreibt der Coldfire-Prozessor der Firebee sein Bild direkt in den Bildspeicher und der schafft es locker, den Bus zuzuknallen. Auch der schnellste Blitter im FPGA könnte das nicht schneller.

Womit man eine Beschleunigung erreichen könnte, ist ein Grafikprozessor (der beispielsweise Blits innerhalb des Bildspeichers in "Full-Speed" können müsste oder die Konvertierung von Bitmaps vom gerätespezifischen ins VDI-Standardformat und zurück übernehmen würde). Den müsste man aber neu erfinden und der wäre dann zu nichts kompatibel, was es in der Atari-Welt gibt (außer vielleicht - mit geeignetem API - mit den ATI-Grafikkarten).

[Nervengift]

Ein Falcon-kompatibler Blitter ist in der Firebee grob ungefähr 40x so unnütz wie einer in einem TT.

Wenn ich Mathias richtig verstanden hatte, dann bringt der Blitter schon was für die Biene. Das Scrolling etc. soll dann um einiges schneller laufen. Ich bin aber kein Fachmann. Ich kann das auch nicht wirklich beurteilen. Aber sowas wie zügiger Bildaufbau auch bei hohen Auflösungen ist gerade heutzutage für angenehmes Arbeiten sehr wichtig. Ich denke es wird letzten Endes nur sehr wenig Nutzer geben, die die Biene mit einem SM124 betreiben wollen.

[Börr]

Ich habe mir schon zwei FPGA Schulungen von meiner Firma geben lassen.

[mfro]

Ein Falcon-kompatibler Blitter ist in der Firebee grob ungefähr 40x so unnütz wie einer in einem TT.

Aber sowas wie zügiger Bildaufbau auch bei hohen Auflösungen ist gerade heutzutage für angenehmes Arbeiten sehr wichtig. Ich denke es wird letzten Endes nur sehr wenig Nutzer geben, die die Biene mit einem SM124 betreiben wollen.

Das könnte, wie gesagt ein "nicht kompatibler" Blitter/Grafikprozessor übernehmen (also eine FPGA-basierte Grafikmaschine, die z.B. Linien und Kreise gefüllt und ungefüllt zeichnen, Flächen füllen, Raster kopieren - natürlich nur innerhalb des vom FPGA kontrollierten DDR-Rams, die Busbandbreite zum Flexbus ist sehr begrenzt - und/oder Fonts/Zeichen von 1 Bit Tiefe auf die Farbtiefe des Bildschirms konvertieren können müsste).

Ein ST-/Falcon-kompatibler Blitter könnte nur Raster kopieren - und das kann die Coldfire-CPU schon mindestens ebenso gut.

[mfro]

Ich habe mir schon zwei FPGA Schulungen von meiner Firma geben lassen.

Was genau hält dich dann noch davon ab, richtig loszulegen? Die mangelnde Bezahlung? 

[Börr]

Was genau hält dich dann noch davon ab, richtig loszulegen? Die mangelnde Bezahlung? 

Ich warte auf die nächste Serie.

[mfro]

Ein Falcon-kompatibler Blitter ist in der Firebee grob ungefähr 40x so unnütz wie einer in einem TT.

Wenn ich Mathias richtig verstanden hatte, dann bringt der Blitter schon was für die Biene. Das Scrolling etc. soll dann um einiges schneller laufen. Ich bin aber kein Fachmann. Ich kann das auch nicht wirklich beurteilen. Aber sowas wie zügiger Bildaufbau auch bei hohen Auflösungen ist gerade heutzutage für angenehmes Arbeiten sehr wichtig. Ich denke es wird letzten Endes nur sehr wenig Nutzer geben, die die Biene mit einem SM124 betreiben wollen.

Der Atari-Blitter beschleunigt den Bildaufbau bei 1, 4, 16 und 256 Farben (deutlich), weil er für die "Interleaved"-Bitplanes der originalen Ataris optimiert ist. Um beispielsweise bei 8 Bit Farbtiefe ein einzelnes Pixel in einer bestimmten Farbe zu setzen, ist es notwendig, 8 aufeinanderfolgende Worte aus dem Bildspeicher zu lesen, in jedem dieser Worte ein Bit entsprechend der gewünschten Farbe zu setzen oder zu löschen und anschließend wieder 8 aufeinanderfolgende Worte in den Bildspeicher zurückzuschreiben.

Genau auf diese Bildspeicher-Organisation ist der Blitter optimiert und beherrscht die Bitfummeleien schneller als eine 16 MHz-m68k CPU.

Der sehr viel schnellere Coldfire-Prozessor schafft es auch ohne Blitter-Hilfe, trotz dieser aufwendigen Bitschiebereien bei 1-8 Bit Farbtiefe, die Speicherbandbreite der Firebee voll auszulasten. Der Blitter brächte hier also genau nichts (das war bereits beim sehr viel langsameren TT der Fall, deswegen hat ihn Atari dort konsequenterweise weggelassen). Wahrscheinlich wäre der Bildaufbau mit Blitter sogar langsamer als nur mit der CPU - der Blitter müsste ja dasselbe machen (und könnte das auch nicht schneller als die CPU), vorher müsste die aber noch die Blitter-Register setzen.

Bei den höheren Firebee-Auflösungen ist (normalerweise) der Truecolor-Modus aktiv (32 Bit Farbtiefe). Da gibt's kein Bitgefummel mehr, das ein Blitter irgendwie beschleunigen könnte - ein Pixel auf dem Bildschirm entspricht 1:1 einem Prozessorwort. Hier kommt es also ausschließlich auf die Speicherbandbreite - also wie schnell Daten zwischen Bildschirm- und Haupspeicher hin und hergeschoben werden können - an (abgesehen davon, daß ein Atari-kompatibler Blitter gar nicht mit Farbtiefen > 8 Bit umgehen kann).

In den Truecolor-Modi braucht man gegenüber den interleaved Bitplanes der Atari-Auflösungen völlig andere Strategien, um flotten Bildaufbau und flottes Scrollen zu realisieren. Der Atari-Blitter kann das nicht.

[Nervengift]

Dann muss Mathias mal erklären was er mit "Blitter" meinte. Zumindest meinte er, dass man die Firebee in höhren Auflösungen wie Full HD noch nicht unbedingt nutzen sollte, da der Bildaufbau und das Scrolling doch etwas träge sind in diesen Auflösungen. Er meinte auch, dass das an einem (ich nutze jetzt mal bewußt den unbestimmten Artikel) noch fehlenden Blitter lege. Vielleicht kann er ja nochmal Klarheit in dieser Angelegenheit schaffen. Vielleicht erinnere ich mich auch total falsch, was das angeht.

Alles in allem denke ich aber, dass dieser Thred die Schwachstellen, die die Biene (noch) hat, gut offenlegt. Auch wenn's hier etwas durcheinander geht und man nicht immer direkt auf Änderungen an der Hardware eingeht. Ich meine aber, dass man schon aus den hier geäußerten Dingen Konsequenzen ziehen kann. Wie und ob die umsetzbar sind, wird sich zeigen.

[Lukas Frank]

... mfro hat das ja Super und erschöpfend erklärt dass die Geschichte mit dem Blitter nichts bringt ... !

Vielleicht wäre es eine Idee wenn Medusa die neue Firebee in einem Mini Tower Gehäuse mit PCi Backplane anbietet und mit einer alten ATI Radeon PCI 9200 (Radeon 7000/7500/8500/9000/9200) ausstattet, die Karten haben bestimmt einiges mehr an Grafikpower wenn man einen richtigen Treiber zu den Karten schreibt. Oder AGP ?

[1ST1]

PCI und AGP sind beides tote Pferde. Wenn schon dann einer oder mehrere PCIe x1 Slots (4er oder 16er halte ich für übertrieben). Klar, da müssten dann neue Treiber her, die alten Karten passen dann nicht mehr und auch kaum noch erhältlich. Aber ich denke, da müsste sich doch der eine oder andere Opensource-Treiber aus dem Linux-Lager als Quelle für die Entwicklung eines Firebee-Treiber nutzen lassen.

[mfro]

PCI und AGP sind beides tote Pferde. Wenn schon dann einer oder mehrere PCIe x1 Slots (4er oder 16er halte ich für übertrieben). Klar, da müssten dann neue Treiber her, die alten Karten passen dann nicht mehr und auch kaum noch erhältlich. Aber ich denke, da müsste sich doch der eine oder andere Opensource-Treiber aus dem Linux-Lager als Quelle für die Entwicklung eines Firebee-Treiber nutzen lassen.

Einen PCI-Express Bus wird es an der Firebee mit Sicherheit nicht geben. Der PCI-Bus wird von der Coldfire-MCU geliefert und ohne daß Freescale das ändert (das wird wohl nicht passieren), gibt's hier auch bei der Firebee keine Änderungen.

Ist aber auch gar nicht notwendig. Es hält dich (schon jetzt, also auch ohne "Neuauflage") niemand, einen "PCI-nach-PCI-Express-Adapter" in einen PCI-Slot zu stecken, Du kannst daran sofort PCIe-Karten betreiben (Treiber vorausgesetzt). Die Firebee "sieht" dann einfach eine weitere PCI-Bridge und "dahinter" weitere PCI-Karten.

Der Software (Treiber) ist es völlig egal, ob PCI oder PCI-Express. Der Unterschied ist nur in der Hardware, die softwareseitige Ansteuerung ist absolut identisch. Von der zusätzlichen Geschwindigkeit wird man bei der Firebee nix haben, die kann mit 250 MB/s sowieso nix anfangen.

PCI-Karten gibt's übrigens noch wie Sand am Meer.

[Lukas Frank]

Bei der recht kleinen Auflage der Firebee halte ich die ATI Radeon für eine gangbare Lösung …

Die bekommt man noch gut über Ebay, ich habe auch noch eine 7000er in meinem alten G4 als zweit Bildschirm Karte.

Es gibt ja schon lange die Radeon Treiber für die CT60/63 mit CTPCI, ich weiss allerdings nicht wie gut die sind ...

[Lukas Frank]

Ich würde mir einen Bildschirmschoner in der Hardware wünschen der einfach nur den Bildschirm ausschaltet und auch die USB Tastatur und Maus überwacht. Twilight funktioniert auf der Firebee nicht richtig wenn man Tastatur/Maus über USB angeschlossen hat, er nimmt keine Tastatur Eingaben und auch keine Mausbewegungen an, nur Maus klicks. Vielleicht sogar mit einem CPX Modul ...

Ich hatte mir mal in den 90igern eine kleine Schaltung für meinen Atari TT mit TTM195 zusammen gebastelt die einfach die Tastaturschnittstelle überwacht hat und nach 3 Minuten oder so den Bildschirm ausgeschaltet hat ...

[1ST1]

Den PCIe-Bridgechip könnte man auf einer zukünftigen neuen FB-Platine unterbringen.

[Börr]

Den PCIe-Bridgechip könnte man auf einer zukünftigen neuen FB-Platine unterbringen.

Muss man dazu nit einfach den ColdFire per FPGA mit den Pins verbinden?

[1ST1]

Wenn hier jemand eine PICe-Bridge in VHDL hat oder selbst coden kann...?

[mfro]

Ihr habt Ideen  !

Der PCI-Bus ist vom FPGA aus nicht erreichbar.

Wenn ich nur "A" mit "B" verbinden will, verwende ich lieber Stecker (ist an der Firebee schon dran) und Buchse, das ist deutlich günstiger als ein FPGA. Abgesehen davon dürfte es ein wenig knifflig bis unmöglich sein, einen seriellen Datenstrom aus einem FPGA mit mindestens 1,25 GHz (das wäre PCIe 1.0) zu erzeugen...

[Arthur]

Da noch kein einziger Post auf meine eigentliche Frage kam.

Man könnte auch Änderungen an der Firebee vornehmen ohne das neue Funktionalität dadurch hinzugefügt wird.

Ich will es mal am Beispiel des Falcon erklären. Der Falcon hat, wie wir alle wissen, im NVRAM die Batterie vergegossen... für eine nächste Revision hätte ich mir eine Lösung wie im TT oder auf den PC-Mainboards gewünscht so dass man selbst die Batterie einfach wechseln kann. Oder das statt des propitären Speichersteckplatzes im Falcon gleich ein PS/2-Port verbaut worden wäre

Also an eher kleineren Verbesserungen bzw. Optimierungen hatte ich eigentlich gedacht.

Also bitte kein AGP, PCIe oder zusätzliche schnellere Prozessoren oder andere Fantastereien. Danke fürs lesen.

[Lukas Frank]

Arthur du bist ja gut, die Firebbe hat ja schon alles was man sich wünschen kann, da bleibt nur eine bessere Grafikleistung ...

... ausser natürlich ThunderBolt, PCIe, USB 3.0 etc. pp und ein Umstieg auf eine aktuelle Intel CPU