Hardware > Firebee

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

<< < (9/24) > >>

michschmi:

--- Zitat von: Lukas Frank am Sa 09.08.2014, 12:24:31 ---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 ...

--- Ende Zitat ---

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:

--- Zitat von: Nervengift am Mo 11.08.2014, 13:06:06 ---
--- Zitat ---Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet! ;)
--- Ende Zitat ---

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?


--- Ende Zitat ---
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".


--- Zitat von: Nervengift am Mo 11.08.2014, 13:06:06 ---Ich hätte den Blitter endlich gerne umgesetzt

--- Ende Zitat ---
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:

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

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:

--- Zitat von: Nervengift am Mo 11.08.2014, 20:11:11 ---
--- Zitat ---Ein Falcon-kompatibler Blitter ist in der Firebee grob ungefähr 40x so unnütz wie einer in einem TT.
--- Ende Zitat ---
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. ;)

--- Ende Zitat ---
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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete