Hardware > Hardware (Classic 16-/32-Bit)

Was sollte so eine neue ST/STE CPU-Karte mitbringen?

<< < (15/19) > >>

MJaap:

--- Zitat von: mfro am So 17.01.2016, 19:07:42 ---So was wie die Firebee ist m.E. der "letzte, einigermaßen vernünftige" Kompromiss. Software, für die man den Quellcode hat, ist relativ einfach daran anpassbar, für existierende Software ist die Emulation gerade schnell genug. Alles andere ist Träumerei und m.E. völlig unrealistisch.

Trotzdem hat die Firebee nicht genügend Entwickler, um für euren Geschmack schnell genug vorwärts zu kommen. Wie wäre das erst bei einem System, bei dem man überhaupt nichts mehr weiterverwenden könnte?

--- Ende Zitat ---

Eben, mfro hat recht.

Ich dachte erst, atari-home hätte irgendwelche Caching-Probleme, denn diese Diskussion hatten wir schon ein paar Mal - und eigentlich wird diese Diskussion schon seit 1995 geführt. Der Zug in Richtung PPC, x86-TOS etc. ist abgefahren, ich sehe jedenfalls nicht irgendwelche Entwickler herumirren, die nur auf einen Fingerzeig warten um TOS zu portieren und Treiber zu schreiben. So etwas passiert nur, wenn ein Entwickler darauf "Bock" hat, denn die Zielgruppe ist sehr, sehr klein.

... und das ist auch der Unterschied zum C64, Amiga oder gar Atari 8-Bit. Die Zahl der aktiven User ist wesentlich größer und damit auch die Zahl der Neuentwicklungen, Händler, Magazine. Dann gibt es eben Entwicklungen wie den C64 Reloaded, eine praktische Turbokarte für den Amiga inkl. RAM-Erweiterung und neuem Kickstart-OS zum Reinstecken oder ein zweisprachiges Magazin mit mehr als zwei Redakteuren ;)

Gast120501:

--- Zitat von: HelmutK am So 17.01.2016, 18:44:40 ---Ja, MiNT als eigenständiges OS, wie Linux/*BSD, usw. für alle CPUs, aber mit GEM statt oder zusätzlich zu X, das müsste mal einer machen.

-Helmut

--- Ende Zitat ---
Meinetswegen kann das auf einem kompletten Linux-Kernel drauf laufen, man würde sich dann viel Treiber- und Systemtool-Entwicklung einsparen.

Gast120501:
MJapp, nicht vergessen, MiNT war zunächst Experimentierfeld und Spinnerei eines einzelnen Programmierers, und bei Linux war es ganz genauso.

ST-Oldie:
Hi,


--- Zitat von: 1ST1 am So 17.01.2016, 17:43:51 ---Das ist etwas, wo ich mich sowieso schon gewundert habe, dass  da niemand was gemacht hat. GEM gibts ja bereits für x86, allerdings kann das weder mit mehr als 640 kB RAM umgehen, noch ist es 32- oder gar 64-bit-tauglich, das müsste angepasst werden. Dann ein VDI was in ein Windows- oder Linux-Fenster reinschreibt, am besten per DirectX oder OpenGL, die ATARI-spezifischen Änderungen in PC-GEM nachpflegen, und wenn Anwendungen in 68K-Code gestartet werden sollen, QUEMU bemühen... Klingt natürlich alles einfacher, als es ist... Wir haben ja schon aranym und hatari...

--- Ende Zitat ---

An sowas in der Richtung hatte ich schon vor Jahren gedacht, damals aber für den PPC. Linux Treiber, darüber eine Schicht für die GEMDOS API und einen 68K Emulator für die Anwendung starten. Nur, woher Mitstreiter nehmen? Damals gab es Leute, die vor einer Hardware Entwicklung weniger Angst als vor einer Software Entwicklung hatten. Und dann den ersten Versuch einer Hardware basierend auf dem Coldfire gestartet hatten. So ein Projekt sollte man wegen dem Umfang schon mit einem kleinen Team starten.

Tschüß
Michael

Mathias:
Was isn heute hier im Forum los? 50 neue Nachrichten, … ;)

Zum Endlos-Thema Andere CPU-Architektur/Emulation/68k-Upgrades/…
ich hab da schon irgendwie das Gefühl daß ihr alle ein bissl multiple Persönlichkeiten seid. ;) Ausnahmslos jeder von euch hier in der Debatte hat einen Plan davon wieviel Arbeit jede Idee bedeuten würde. Gerade auch Du Angelika, da Du ja selber programmierst. Es ist total sinnentleert, sich über den langsamen Fortgang von der FireBee oder auch Aranym zu beschweren, und gleichzeitig neue – viel komplexere – Projekte anzuregen. Ihr müsst das wirklich mal verinnerlichen daß es kaum Menschen gibt, die das machen können – außer uns selber. Es gibt nur wenige Leute, die die Expertise für solche Monsterprojekte tatsächlich besitzen und die müssen alle für ihren Unterhalt sorgen und können nur nebenbei an Atari-Dingen arbeiten.

Es braucht also entweder neue Menschen die programmieren, oder wir müssen irgendwie die paar wenigen Menschen die wir haben von den Alltagssorgen freispielen – egal mit welchem Projekt – wenn irgendwas zügiger vorangehen soll.

Und zur FireBee speziell noch: Nervengift hat das ja schon schön gesagt. Aber nochmals ganz deutlich: Medusa hat ganz zu Beginn vom ACP-reloaded schon festgestellt daß die Hardware machbar ist, aber die Software von so einer kleinen Firma nicht zu schaffen ist – nicht nebenbei. Also war der "Deal" wenn sich viele Programmierer an der Software beteiligen, wird die Hardware gebaut. Und diese Hardware existiert, und rockt! Stellt euch nur mal vor die FireBee hätte schon einen Supervidel, ein Suska, einen DSP und ein paar Video-Codecs "eingebaut", … was technisch ja möglich wäre.

Und selbstredend ist die softwareseitige Optimierung der FireBee ein weitaus kleinerer Schritt als alle anderen "Neuen Ideen". ;)
Aber ich sehe den Wunsch nach flotteren aktuelleren Umgebungen. Und ich anerkenne daß es – auch wenn die Debatte grundsätzlich redundant ist seit 20 Jahren, wie mjaap gesagt hat – das Bedürfnis nach einer irgendwie gearteten Atari-Zukunf existiert.

So, aber jetzt um die Debatte noch zu verkomplizieren, ich hatte ein paar sehr interessante Gespräche mit einem FireBee-User aus Russland, der im professionellen Emulations-Bereich arbeitet. Er hat die Idee gehabt die Zukunft der Plattform per reiner CPU-Emulation zu suchen. Einen möglichst perfekten 68k-Emulator auf x86 oder ARM, der aber ausschließlich die CPU emuliert. Sprich, das Projekt dadurch vereinfacht, daß nicht versucht wird das ganze System zu emulieren auf irgendeiner Stangen-Hardware, sondern sich ein kleines Team auf so eine CPU konzentrieren kann, die dann in neuen Hardware-Designs, für Upgradekarten usw. genutzt werden kann ohne daß man die ganze Peripherie mitemulieren muß, die ja weiterhin von den "Ataris" zur Verfügung gestellt wird, nur statt der 68k/Coldfire CPU halt eine andere die nur emuliert genutzt wird.

Um aber auch sowas vom Arbeitsaufwand her abschätzen zu können hier seine Einschätzung zu JIT (ausgehend von einer Debatte über die Optimierung der cf68klib von MicroAPL, die im FireTOS eingebaut ist):

"As far as JIT-compilation is concerned there are some "rule-of-thumb" numbers. As in:
1) 10-15x slowdown vs native - one-guy project done on weekends (~1man/year)
2) 3-4x slowdown vs native - decent JIT architecture with some arch-specific optimizations (~10man/years)
3) 1.8-2.0x slowdown vs native - large team of reserachers (~100man/years)
4) 1.2-1.5x slowdown vs native - insanely large library of peephole optimizations (~1000man/years)"

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete