atari-home.de - Foren
Hardware => Firebee => Thema gestartet von: Arthur am Fr 08.08.2014, 14:06:18
-
Mich würde interessieren was an der Firebee eurer Meinung nach noch besser gemacht werden könnte bzw. verbesserungswürdig wäre wenn eine neue Firebee-Auflage heraus gebracht würde bzw. wird. Auch wenn ihr wunschlos glücklich mit eurer Firebee seid dann könnt ihr das natürlich auch gerne hier posten.
Ergänzung: Bitte lasst uns hier nicht über noch nicht unterstützte Schittstellen der Firebee diskutieren!
-
Eine sehr gute Idee!
Ich hoffe, daß sich die zahlreichen Firebee Nutzer tatsächlich hier äußern.
Das wäre auch für den einen oder anderen potentiellen Neunutzer sicherlich sehr interessant.
-
Ich habe (noch) keine Firebee, kann aber mal schreiben, was mich bisher davon abgehalten hat, eine zu erwerben.
Als jemand, der über die Musikproduktion zum Atari gekommen und deswegen noch immer beim Falcon "hängengeblieben" ist, fehlen mir bei der Firebee Hardware folgende Dinge:
- ROM Port
Ob es von der Grundlage der Firebee überhaupt möglich ist, diese Schnittstelle nachzurüsten bzw. noch zu integrieren, konnte ich bisher nicht klären.
-
Wie kommst Du auf die Idee daß es keinen ROM-Port gäbe? Den gabs immer schon, und der ist direkt hinter dem IDE-Port: http://acp.atari.org/files/OriginalboardDE.pdf
Daß etliche Dinge noch nicht implementiert sind (SCSI, ROM-Port usw.) hat ja mit der Hardware selber nichts zu tun! Aber nachdem Du selber ganz klar von "FireBee Hardware" schreibst, meinst Du ziemlich sicher auch nicht die Softwareunterstützung, sondern das Board selber.
-
Wie kommst Du auf die Idee daß es keinen ROM-Port gäbe? Den gabs immer schon, und der ist direkt hinter dem IDE-Port: http://acp.atari.org/files/OriginalboardDE.pdf
Daß etliche Dinge noch nicht implementiert sind (SCSI, ROM-Port usw.) hat ja mit der Hardware selber nichts zu tun! Aber nachdem Du selber ganz klar von "FireBee Hardware" schreibst, meinst Du ziemlich sicher auch nicht die Softwareunterstützung, sondern das Board selber.
Tja, war mir nicht sicher, wie ich es hätte ausdrücken sollen. Im Prinzip geht es mir um eine Lösung für verdongelte Software, bzw. darum, daß diese Software ohne das Vorhandensein einer bestimmten Hardware nicht läuft. Ob das jetzt Hardware oder Firmware ist, die da noch implementiert werden muß, das kann ich als Außenstehender nicht beurteilen. Das bloße Vorhandensein einer Pfostenleiste ist ja noch keine Lösung.
-
Wenn die Atari konformen Schnittstellen wie ROM-Port, SCSI, ACSI, IDE, Seriell etc. eingebaut werden, wünsche ich mir vom ACP / Medusa einen schönen Mini Tower mit PCI Backplane zum Einbau der FireBee ...
-
Wenn die Atari konformen Schnittstellen wie ROM-Port, SCSI, ACSI, IDE, Seriell etc. eingebaut werden, wünsche ich mir vom ACP / Medusa einen schönen Mini Tower mit PCI Backplane zum Einbau der FireBee ...
Der Gedanke hat etwas, wie ich finde, auch wenn die Firebee mit SD und CF-Karte kaum Platz benötigt. Wer später mal eine echte 3,5 Zoll Platte und/oder eine PCI-Karte verwenden möchte für den ist ein passender schicker Mini Tower eine praktische elegante Sache um Kabelgewirr auf dem Tisch zu vermeiden. Wahrscheinlich ist das es sogar entsprechende passende Tower dafür gibt aber ob die auch schick und klein genug sind? Ich könnte mir vorstellen das ein direkt vom Hersteller passendes Gehäuse mit integriertem Netzteil seine Abnehmer finden würde wenn die Treiberentwicklung fast abgeschlossen ist. Jedem sollte aber klar sein das sich das erst lohnt wenn entsprechende Stückzahlen der Firebee verkauft werden. Die Stückzahlen der verkauften Firebees würden mich ja schon interessieren... ;D
-
Ich für mein Teil würde gerne für ein schickes Gehäuse so was zwischen 200 und 300,- Euro ausgeben wollen ...
Ansonsten gerät das Teil wieder zu einer Bastelbude !
-
Ich denke, dass man an der Hardware selbst kaum noch etwas verbessern oder ändern kann. Eine schnellere CPU wäre cool. ;) Ansonsten ist wohl alles mit tiefgreifenden Designänderungen verbunden. Ich hätte z. B. eine ITX-Firebee echt klasse gefunden. ;D Bereits 4 GB integrierter Flashspeicher oder mehr auf der Firebee fände ich auch nicht so übel, den man direkt für seine Daten nutzen könnte. Aber dann ist auch eine Designänderung der Platine von Nöten. Von Firewire, Thunderbolt etc. ganz zu schweigen. Ich denke auch, dass das alles letzten Endes unnötiger Balast wäre. Viel wichtiger ist, dass erstmal solche Schnittstellen wie ROM-Port, SCSI, ASCI et. zum Laufen gebracht werden. Für einige sind diese Schnittstellen eben unverzichtbar. Die Biene sollte in der Form wie sie ist erstmal richtig fliegen lernen. Also bitte nicht den zweiten Schritt vor dem ersten machen. Meine Meinung. ;)
-
Bevor man etwas an der Hardware macht, sollte man erstmal die Software in die richtigen Bahnen lenken ...
Ich bin von meiner FireBee recht enttäuscht, mein Atari TT war nicht viel langsamer (subjektiv, gefühlt) und der UNIX Unterbau beim MiNT fehlt mir. So ist das ja nichts anderes als von Atari damals die MultiTOS Diskette, abgesehen vom XaAES ...
Da muss sich jemand kümmern und die SpareMiNT Tools auf die aktuellen Versionen bringen und auch für die FireBee kompilieren ...
-
Da muss sich jemand kümmern und die SpareMiNT Tools auf die aktuellen Versionen bringen und auch für die FireBee kompilieren ...
Moin,
fordern kann man viel - Selber machen!
Das hättest Du mit etwas Recherche vor der Anschaffung der Firbee rausfinden können.
Die Firebee mach imho nur Sinn wenn man selber in der Lage ist zur programmieren und kompilieren.
Das Angebot an Software für die Firebee ist halt recht überschaubar, was möglicherweise daran liegt,
das es zu viele Endanwender gibt die nur warten....
Cheers
Jürgen
-
Da kann ich die Entwickler nicht verstehen, da für mich MiNT/XaAES und UNIX zusammen gehören ...
... auch wenn man die nicht braucht.
Nice to have !
-
Da kann ich die Entwickler nicht verstehen, da für mich MiNT/XaAES und UNIX zusammen gehören ...
Da kannst Du bestimmt prima mit Mathias drüber diskutieren :D
-
Da kann ich die Entwickler nicht verstehen.........
Die Entwickler sind Leute wie Du oder ich - Enthusiasten, die das als Hobby machen - nix professionell!
Lese Dir den ersten Beitrag durch, und Dir wird klar, worauf Du Dich eingelassen hast:
http://forum.atari-home.de/index.php?topic=10784.0
-
Da kann ich die Entwickler nicht verstehen, da für mich MiNT/XaAES und UNIX zusammen gehören ...
Da kannst Du bestimmt prima mit Mathias drüber diskutieren :D
Definitiv, da können wir Tagelange Flamewars führen, gell!! ;)
Zumal mir noch niemand schlüssig erklären konnte warum all jene (eigentlich nur ein paar Wenige sehr Laute) die angeblich unbedingt Unix brauchen, unfähig sind sich Unix zu installieren. Nicht falsch verstehen – ich könnte auch kein Gentoo, oder FreeMint von Grund auf aufsetzen, …
Bei der Ganzen Debatte gehts seit Jahren darum, warum wir als ACP nicht auf allen FireBees ein MiNT mit Unix VORINSTALLIERT haben, … anstatt daß endlich mal wer einfach ein gutes Unix-Setup macht.
Frank Lukas, wenn du eine flotte Unix Umgebung willst würde ich dir empfehlen mit EmuTOS zu arbeiten, und wie Markus oder Vincent das reine Coldfire MiNT zu nutzen. Da ist schon super viel Arbeit geschehen, alles ist 100% ColdFire Code, und die ganzen Unix-Tools gibts auch schon seit Langem.
-
mein Atari TT war nicht viel langsamer (subjektiv, gefühlt)
Dann schalte die FireBee mal auf 640 x 480 und 16 Farben oder sowas, und staune! ;) Vor Allem ändere die Bootauflösung auf 640 x 480 in SW!
Selbst mein Hades mit ATI Mach 64 4MB Karte fühlt sich gegenüber der FireBee sehr gemächlich an. Und das Gefühl hatte ich vor der FireBee niemals.
Da muss sich jemand kümmern und die SpareMiNT Tools auf die aktuellen Versionen bringen und auch für die FireBee kompilieren ...
Ja, und das ist die größte Schwäche der MiNT Entwickler-Gemeinde, daß nicht zusammengearbeitet wird. Ich weiß von 7 Leuten die irgendwie an SpareMiNT Paketen herumdoktern, oder sogar schon ganze Setups gemacht haben, aber eine zielgerichtete Entwicklung oder gar strukturierte Abarbeitung der Pakete, damit auch weniger geübte Leute alles nutzen können, findet nicht statt. Jeder kocht sein eigenes Süppchen, und resigniert aber irgendwann vor der großen Aufgabe. Anstatt daß mal z.B die 42 Easy-Mint Pakete neu kompiliert werden, …
-
Da muss sich jemand kümmern und die SpareMiNT Tools auf die aktuellen Versionen bringen und auch für die FireBee kompilieren ...
Moin,
fordern kann man viel - Selber machen!
Das hättest Du mit etwas Recherche vor der Anschaffung der Firbee rausfinden können.
(…)
was möglicherweise daran liegt,
das es zu viele Endanwender gibt die nur warten....
Dem kann ich nur zustimmen, und es ist auch gut wenn das mal wer (nicht immer nur ich) klipp und klar sagt. Das Projekt lebt von den Beiträgen der Ehrenamtliche aktiven Menschen, und was wir nicht selber machen wird nicht passieren. Es gibt einfach keine "Instanz" an die man etwas delegieren könnte!
Zur Ehrenrettung von Frank Lukas muß ich aber sagen, daß er nicht nur fordert sondern auch schon aktiv geholfen hat und was beigetragen hat, was natürlich offentlich nicht bekannt ist.
Die Firebee mach imho nur Sinn wenn man selber in der Lage ist zur programmieren und kompilieren.
Das Angebot an Software für die Firebee ist halt recht überschaubar,
Dem muß ich laut wiedersprechen! Ich habe etliche hundert funktionierender GEM-Programme auf meiner FireBee, und kann eigentlich Alles damit erledigen. Und nein, man muß nicht programmieren können! Genau das war ja das Ziel der oben kritisierten Unixlosigkeit, daß dieser Eindruck eben nicht entsteht!
-
Tja, war mir nicht sicher, wie ich es hätte ausdrücken sollen. Im Prinzip geht es mir um eine Lösung für verdongelte Software, bzw. darum, daß diese Software ohne das Vorhandensein einer bestimmten Hardware nicht läuft. Ob das jetzt Hardware oder Firmware ist, die da noch implementiert werden muß, das kann ich als Außenstehender nicht beurteilen. Das bloße Vorhandensein einer Pfostenleiste ist ja noch keine Lösung.
Ich kann Dich schon verstehen, das ist natürlcih ein triftiger Grund wenn Du Deine Software noch nicht verwenden kannst. Es ist halt, wie Nervengift weiter unten so gut beschrieben hat, die Sache daß die Vorhandenen Schnittstellen mal alle unterstützt werden sollten.
Im Gegensatz dazu habe ich Arthur und Dein erstes Posting so verstanden, daß ihr Änderungen an der Hardware besprechen wollt. Was aber vermutlich in diesem Thread jetzt eh schon aussichtslos geworden ist, nachdem wir 1000 unterschiedliche Themen haben ;)
Und die Pfostenleiste ist eine Lösung. Sobald der ROM-Port "Softwareseitig" implementiert ist, brauchts noch ein Flachbandkabel und die Buchse (Kostenpunkt max. 20 Euro). Ich habe auch schon zwei Quellen für genügend originale ROM-Port Buchsen.
-
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 ...
-
Hallo Mathias, mein Atari TT war schon eine schöne Maschine, mit 1024x768 bei 64k Farben, mit NetSurf, PhotoLine und so weiter ...
Und beim Netzwerk war er auch mit 800kB recht schnell dabei ...
Natürlich sind die Auflösungen der FireBee sehr schön und das Teil ist auch schnell und die USB Ports laufen einwandfrei aber am System fehlt mir etwas, damit das richtig rund wird ...
Dem UNIX Unterbau braucht ja keiner nutzen, ist halt nur schön wenn er da ist/wäre ...
-
Und die Pfostenleiste ist eine Lösung. Sobald der ROM-Port "Softwareseitig" implementiert ist, brauchts noch ein Flachbandkabel und die Buchse (Kostenpunkt max. 20 Euro). Ich habe auch schon zwei Quellen für genügend originale ROM-Port Buchsen.
Hallo Mathias, auch das ist wieder mal ein kleines Wunder. :)
-
Wer will, der kann sich auch eine Unixumgebung ganz einfach selbst basteln. Das ist nun kein Hexenwerk mit dieser Anleitung:
https://sites.google.com/site/probehouse/mint-os-for-atari/mint-unix-environment
Wenn ich meine Biene habe, dann wollte ich das gentoo mal ausprobieren und wenn's soweit läuft, dann will ich auch eine Anleitung zum Installieren hier posten. Kann jetzt wohl nur mit der Biene noch etwas dauern. :(
Aber mal zurück zum Thema. Ich denke, wir können hier alles Mögliche an Änderungen an der Hardware diskutieren, was für zukünfige Entwicklungen sicherlich auch nicht schlecht ist, aber bei der zweiten Generation wird wohl nicht so viel möglich sein, was man ändern wird können. Insofern wäre es vielleicht (von Mathias) nicht so schlecht zu wissen welche Änderungen am Design/Layout überhaupt möglich wären bei der zweiten Generation. Es macht ja keinen Sinn, wenn wir alle 16 zusätzliche USB-Ports haben wollten und Mathias dann sagt, vergisst es, das ist rein gar nicht möglich.
-
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 hatte ich eigentlich gedacht.
-
Tja, war mir nicht sicher, wie ich es hätte ausdrücken sollen. Im Prinzip geht es mir um eine Lösung für verdongelte Software, bzw. darum, daß diese Software ohne das Vorhandensein einer bestimmten Hardware nicht läuft. Ob das jetzt Hardware oder Firmware ist, die da noch implementiert werden muß, das kann ich als Außenstehender nicht beurteilen. Das bloße Vorhandensein einer Pfostenleiste ist ja noch keine Lösung.
Ich kann Dich schon verstehen, das ist natürlcih ein triftiger Grund wenn Du Deine Software noch nicht verwenden kannst. Es ist halt, wie Nervengift weiter unten so gut beschrieben hat, die Sache daß die Vorhandenen Schnittstellen mal alle unterstützt werden sollten.
Im Gegensatz dazu habe ich Arthur und Dein erstes Posting so verstanden, daß ihr Änderungen an der Hardware besprechen wollt. Was aber vermutlich in diesem Thread jetzt eh schon aussichtslos geworden ist, nachdem wir 1000 unterschiedliche Themen haben ;)
Und die Pfostenleiste ist eine Lösung. Sobald der ROM-Port "Softwareseitig" implementiert ist, brauchts noch ein Flachbandkabel und die Buchse (Kostenpunkt max. 20 Euro). Ich habe auch schon zwei Quellen für genügend originale ROM-Port Buchsen.
Womöglich "schießt" Arthur mit seinem Diskussionsanstoß wohl doch über das eigentliche Ziel hinaus. Ich gebe Dir, Nervengift und Frank Lukas ganz recht, zunächst sollte die schon vorhandene Hardware (Schnittstellen, Pfostenleisten, usw.) vollständig implementiert sein und entsprechend funktionieren. Erst dann sollte man sich Gedanken darüber machen, ob überhaupt noch was fehlt und was.
-
Mich würde interessieren was an der Firebee eurer Meinung nach noch besser gemacht werden könnte bzw. verbesserungswürdig wäre wenn eine neue Firebee-Auflage heraus gebracht würde bzw. wird. Auch wenn ihr wunschlos glücklich mit eurer Firebee seid dann könnt ihr das natürlich auch gerne hier posten.
Ergänzung: Bitte lasst uns hier nicht über noch nicht unterstützte Schittstellen der Firebee diskutieren!
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 hatte ich eigentlich gedacht.
Wirklich mitgelesen?
Womöglich "schießt" Arthur mit seinem Diskussionsanstoß wohl doch über das eigentliche Ziel hinaus. Ich gebe Dir, Nervengift und Frank Lukas ganz recht, zunächst sollte die schon vorhandene Hardware (Schnittstellen, Pfostenleisten, usw.) vollständig implementiert sein und entsprechend funktionieren. Erst dann sollte man sich Gedanken darüber machen, ob überhaupt noch was fehlt und was.
-
Die Verfügbarkeit :D
Eine M68k CPU im FPGA damit 99% der alten Software läuft, also quasi ein MiSt oder Suska im FPGA und nur die Coldfire Progs auf dem coldfire ausgeführt werden. Und eine schnelle standart Bus Schnittstelle, um evtl eine andere CPU drann zu packen z.B. PI oder Arduino, als Slave.
-
Die M68K CPU ist bereits in der Firebee integriert, man kann Programme darauf starten, in dem man sie von *.prg in eine andere spezielle Dateiendung umbenennt.
-
Die M68K CPU ist bereits in der Firebee integriert, man kann Programme darauf starten, in dem man sie von *.prg in eine andere spezielle Dateiendung umbenennt.
Das wäre mir neu.
-
Die M68K CPU ist bereits in der Firebee integriert, man kann Programme darauf starten, in dem man sie von *.prg in eine andere spezielle Dateiendung umbenennt.
Das wird doch, wenn ich es richtig mitbekommen habe, per Softwareemulation umgesetzt.
-
Nein, da ist tatsächlich eine 68000 CPU im VHDL-kern drin. Matthias wird das bestätigen können, wenn er mal wieder hier rein schaut. Vielleicht ist es auch in der Online-Doku/Spezifikation enthalten.
-
Nein, da ist tatsächlich eine 68000 CPU im VHDL-kern drin. Matthias wird das bestätigen können, wenn er mal wieder hier rein schaut. Vielleicht ist es auch in der Online-Doku/Spezifikation enthalten.
Ich weiß nicht, wo Du das her hast, jedenfalls stimmt es nicht. Wenn da ein 68k-core drin wär', wüsst' ich's ;).
FireTOS stellt die m68k-Kompatibilität ausschließlich über Software mithilfe der cf68klib (http://www.microapl.co.uk/Porting/ColdFire/cf68klib.html) von MicroAPL (ja, genau die, die mal einen FORTRAN- und APL-Compiler für den ST gemacht haben). Was die nicht abfängt, muß "im Flug" gepatcht werden.
-
1ST1 spricht von Vincents "Soft CPU" http://vincent.riviere.free.fr/soft/68kemu/ Das ist aber eine reine Software-Emulation! Börr hätte gerne eine CPU in VHDL abgebildet im FPGA (die Idee hatten wir auch schon vor langer Zeit). Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet! ;)
-
Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet! ;)
Meiner Ansicht nach wär' so was witzlos, falls überhaupt machbar.
Das Ding wäre sozusagen ein MiST in der Firebee. Der Coldfire-Prozessor hätte nichts zu tun und würde nur zuschauen, wie der FPGA sich abrackert und der würde wahrscheinlich nicht mal die Geschwindigkeit des MiST erreichen (falls ein 68k-Kern überhaupt noch reinpassen würde, mit Wolfgang's letzten Änderungen (SCSI und Umstellung von Toplevel und DDR-Controller auf reines VHDL) wird's langsam ein wenig eng da drin.
Die Coldfire-CPU der Firebee ist nach meinen Messungen bei realen Programmen ungefähr 40 Mal schneller als der MiST im "Steroids"-Mode. Mit der der CF68k-Lib ist immer noch locker ein Faktor 15-20 drin (je nachdem, wieviel der Illegal-Exception-Handler zu tun bekommt).
_Das_ ist meiner Ansicht nach das Potential, das es zu nutzen gilt. Wer volle ST-Kompatibilität haben will, sollte sich eher einen MiST kaufen. Da ist genau das (und nur das) drin, was dafür gebraucht wird.
Gruß,
Markus
-
1ST1 spricht von Vincents "Soft CPU" http://vincent.riviere.free.fr/soft/68kemu/ Das ist aber eine reine Software-Emulation! Börr hätte gerne eine CPU in VHDL abgebildet im FPGA (die Idee hatten wir auch schon vor langer Zeit). Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet! ;)
Das sehe ich anders wenn er doch schreibt:
Nein, da ist tatsächlich eine 68000 CPU im VHDL-kern drin.
Also nicht per VHDL in Hardware sondern per Software im FireTOS umgesetzt wie wir nun wissen.
-
Da muss ich irgendwas missverstanden haben, naja.
-
Der Unixunterbau könnte man mit Busybox bestimmt realisieren. Gibt es nicht so eine Art VM in der man die Firebee am einem PC oder MAC laufen lassen kann?
-
Nein, da ist tatsächlich eine 68000 CPU im VHDL-kern drin.
Also nicht per VHDL in Hardware sondern per Software im FireTOS umgesetzt wie wir nun wissen.
Auch nicht ganz richtig. Es ist ein eigenständiges Programm, daß einfach nur die CPU emuliert, während der Rest vom System normal nativ weiterläuft. Das hat mit FireTOS nichts zu tun (ist lediglich in unserem offiziellen Setup als Programm zum ausführen von ".68k" Programmen angemeldet). In der Tat ist es die einzige Möglichkeit unter EmuTOS Programme mit 68k Code auszuführen.
-
Hallo Markus!
Wie immer, kein Problem sofern sich ein FPGA-Entwickler findet! ;)
Meiner Ansicht nach wär' so was witzlos, falls überhaupt machbar.
Das Ding wäre sozusagen ein MiST in der Firebee. Der Coldfire-Prozessor hätte nichts zu tun und würde nur zuschauen, wie der FPGA sich abrackert
Ja, da hast Du schon recht. Grundsätzlich ist das nicht von hoher Priorität, aber als dritter Kompatibilitätslevel wäre es schon nett für Menschen die Programme brauchen die um die Burg nicht mit Soft-CPU wollen. Ich denke da an Notator oder solche Kandidaten, die nichtmal auf original Falcons laufen. Da wäre es schon nett quasi einen ST auch noch an Board zu haben. Auch um alles auf einem System machen zu können. So haben wir uns das jedenfalls vor ein paar Jahren mal gedacht. Aber ohne VHDL Entwickler is es sowieso müßig, …
Die Coldfire-CPU der Firebee ist nach meinen Messungen bei realen Programmen ungefähr 40 Mal schneller als der MiST im "Steroids"-Mode. Mit der der CF68k-Lib ist immer noch locker ein Faktor 15-20 drin (je nachdem, wieviel der Illegal-Exception-Handler zu tun bekommt).
_Das_ ist meiner Ansicht nach das Potential, das es zu nutzen gilt.
Auch da hast Du vollkommen recht. Wenn jemand unseren eigenen Illegal-Exception-Handle wie geplant umsetzen würde wäre das ein riesen Schritt vorwärts!
-
Auch da hast Du vollkommen recht. Wenn jemand unseren eigenen Illegal-Exception-Handle wie geplant umsetzen würde wäre das ein riesen Schritt vorwärts!
Mir ist nicht klar, was der besser machen sollte als der in der CF68K-lib. Der Illegal-Exception-Handler kann nur die m68k-Befehle abfangen, die auf dem Coldfire tatsächlich illegal sind (und das hat MicroAPL nach meinem Verständnis vollständig und perfekt umgesetzt).
Die (wenigen) verbleibenden Befehle, die _nicht_ illegal sind, aber sich im Coldfire-Prozessor anders verhalten als beim m68k (ein Byte auf den Stack pushen und als Word wieder runterholen z.B., das macht Pure-C gerne) kann kein Illegal-Exception-Handler abfangen. Das geht nur in der Emulation.
-
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? Man könnte z. B. vorher Spenden sammeln. Ich hätte den Blitter endlich gerne umgesetzt und wäre dann auch bereit dafür zu bezahlen. Ich denke, was die Leute am meisten nervt sind die nicht funktionierenden Schnittstellen und auch, dass einige Sachen bislang nicht wirklich umgesetzt sind oder nur halb fertig sind. Ich fürchte nur auch, dass sich an diesem grundsätzlichen Zustand in den nächsten fünf bis zehn Jahren nicht viel ändern wird, wenn man nicht bereit dazu ist Geld zu investieren.
Wie Mathias schon schrieb, das Projekt kann nur Erfolg haben, wenn es auch entsprechend von den Endanwender unterstützt wird und sie sich einbringen. Man kann eben nicht erwarten, dass man bei einem nicht kommerziellen Projekt alles fertig serviert bekommt mit einem entsprechenden Support. Das ACP-Team kann sowas nicht leisten, meine ich. Ich selbst kann z. B. rein gar nicht programmieren. Ich hatte versucht bei Freunden Intresse zu wecken, die programmieren können, was das ACP angeht, aber die haben alle dankend abgewunken. Sie meinten nur, für Geld würden sie's machen. Über diese Einstellung kann man sicherlich streiten, aber wenn wir etwas unbedingt haben wollen und das verbunden mit einem relativ sicheren Fertigstellungsdatum, dann wird es nicht anders gehen, wenn man sich solche Dienstleistungen dazukauft, denke ich.
Ihr könnt ja mal schreiben was ihr davon haltet und ob sowas aus der Sicht des ACP-Teams überhaupt möglich ist?
-
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.
-
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).
-
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. ;)
-
Ich habe mir schon zwei FPGA Schulungen von meiner Firma geben lassen.
-
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.
-
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? >:D
-
Was genau hält dich dann noch davon ab, richtig loszulegen? Die mangelnde Bezahlung? >:D
Ich warte auf die nächste Serie.
-
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.
-
Dann muss Mathias mal erklären was er mit "Blitter" meinte. >:D 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. ;)
-
... 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 ?
-
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.
-
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.
-
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 ...
-
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 ...
-
Den PCIe-Bridgechip könnte man auf einer zukünftigen neuen FB-Platine unterbringen.
-
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?
-
Wenn hier jemand eine PICe-Bridge in VHDL hat oder selbst coden kann...?
-
Ihr habt Ideen :D !
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...
-
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.
-
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 ;D
-
... ausser natürlich ThunderBolt, PCIe, USB 3.0 etc. pp und ein Umstieg auf eine aktuelle Intel CPU ;D
Das nennt sich dann Aranym.
-
Nein das ist falsch, MiNT/XaAES und die UNIX Tools in X86 Code um/neu schreiben, neue Programme in X86 Code und für die alten einen 68k-Emulator ...
-
Wenn du das alles auf ein X86 umbaust, kannst du dir auch ein Freebsd auf ein normalen PC installieren mit einem Atari Emulator, oder du baust Pear PC um für Atari
Was wäre denn mit dem kickstart-projekt..? Vielleicht könnte man darüber die Firebee günstiger anbieten und so mehr Entwickler begeistern...
-
Das wäre aber nicht dass gleiche ...
Ein Host Betriebssystem mit einem Emulator ist halt kein richtiges Atari/TOS System.
Wenn man ein MiNT X86 hätte könnte man jede aktuelle Hardware nutzen.
-
Hallo,
die Firebee ist sehr gut ausgestattet.
Man könnte höchstens noch USB 3.0 oder die schnellere Coldfire CPU installieren.
Ein USB Diskettenluafwerk wäre auch nicht schlecht.
Auf die PCI Backplatine warte ich auch immer noch.
Gruß Martin
-
Schau doch mal da nach der Firebee Seite -> http://didierm.pagesperso-orange.fr/
Ich denke man kann jede PCI Backplane nehmen (Vorsicht bei der Stromversorgung!) und eine Radeon PCI Grafikkarte betreiben, es ist sogar ein PCI auf PCIe Adapter möglich, so wie ich das gesehen habe mit einer 4port USB Karte drin ...
Etwas fertiges von Medusa wäre mir auch Lieber, ich persönlich mag eigentlich nicht mehr basteln ...
Wenn man sich die beiden Treiber Pakete zur Firebee runterlädt und sich die readme Texte mal durchliest bekommt man einen guten Überblick was die Firebee angeht ...
-
ACHTUNG!
Ich denke man kann jede PCI Backplane nehmen
Definitiv nicht! Wenn man eine handelsübliche 32 Bit Backplane nimmt, grillt man sich die FireBee unwiederruflich! Es braucht eine leicht modifizierte 64-Bit Backplane. Didier hat seinen PCI-Slot selber händisch zusammengelötet.
Also bitte keine Backplanes ausprobieren, wenn ihr euch die FireBees nicht zerstören wollt.
-
Ja das mit der Spannungsversorgung ist ja beschrieben auf der Seite. Einmal sieht man seine selbstgelötete PCI Bus Verlängerung zu der Radeon Karte und auf dem anderen Bild ist eine fertige Backplane zu sehen mit dem PCI auf PCIe Adapter und der USB Karte ...
Deshalb ist etwas fertiges von Medusa eine schöne Sache ...
Ich habe mal irgendwo gelesen das die ATI Radeon Karten einen Blitter in Hardware haben, wenn die Atari Software das unterstützt wäre das vielleicht eine schnelle Lösung ...
-
Schon eine Mach32 hat einen Blitter vom Feinsten drin, der also wesentlich über das Kopieren von Speicherbereichen hinaus geht. Das sind nämlich ganz hübsche (aufgeblasene) 8514/A-Karten, die können Linien, Kreise, Flächen, Farbverläufe und noch viel mehr hübsche Dinge selbstständig zeichnen. Leider nutzt das die Nova-Treibersoftware alles nicht. Ich weiß das, weil ich lange Jahre eine ATI Mach 32 Ultra EISA in meinem PC hatte (sie liegt noch im Keller).
-
Wie sieht es mit openGL ES aus? Oder Cuda?
-
Wie sieht es mit openGL ES aus? Oder Cuda?
Ist bestimmt auch wichtig und interessant, jedoch dachte ich an feine Hardware-Verbesserungen...
Frank schrieb zum Beispiel in einem Thread das seine Firebee in dem Gehäuse recht Heiß wird.... oder das er nich nachvollziehen kann wozu der Akku sinvoll ist.
Vielleicht wäre ein Temperatursensor der von der Software ausgelesen werden kann verbunden mit einer Lüftersteuerung eine gute Erweiterung. Oder die Möglichkeit die Firebee ohne Akku und statt dessen mit einer CR2032 o. ä. zu puffern... als Option per Jumper konfigurierbar.
So Tips wie USB 3.0 machen, glaube ich, wenig Sinn da selbst bei vielen auch fast aktuelle PCs die Speicheranbindung für das enorme Tempo nicht gebacken kriegen. Eine schnellere CPU halte ich für wenig sinnvoll wenn es noch so viele nicht unterstützte Atari-Schnittstellen auf dem Board gibt... Floppy, ROM etc.. Diese sind zwar schon auf der Frebee vorhanden aber momentan noch als Statisten.
-
Ja evtl eine Arduino Schnittstelle oder sowas für eigene Hardware Basteleien :D
Lieber einen Arduino braten wie die Firebee, quasi als Puffer.
-
Cuda macht keinen Sinn, so viel Daten wie dieser Numbercruncher frisst, kann der Coldfire garnicht liefern. Das wäre ja so als ob ne Fliege einen Frosch essen wollte! (Oder Porsche VW kaufen wollte...) Eher lässt sich nebenbei die ganze Firebee unter Cuda emulieren...
Wie Arthur schrieb, wichtig wäre erstmal dass alle vorhandenen Schnittstellen so laufen wie mal angedacht.
-
Ich habe mir auch kein Firebee geholt, da mir der Formfaktor überhaupt nicht gefällt, von daher wäre es Klasse, wenn es was in dieser Richtung gäbe (mini-itx z.B.). Ansonsten kann ich nicht viel dazu sagen.
-
Ich sehe Verbesserungsbedarf eher bei der Software, nicht der Hardware. Die Firebee ist was Schnittstellen angeht, komplett ausgestattet. Welcher Entwickler würde denn Cuda oder USB3 ausnutzen? Auch den Wechsel auf eine Intel-CPU sehe ich kritisch. Am Ende würde es wohl ein paar Kommandozeilentools und evtl. die ein oder andere OpenGL-App nativ geben. Apple konnte wechseln, weil der Konzern Hardware, Software und Entwicklungstools kontrolliert und auch ein kommerzieller Markt für Mac-Software da ist.
Für Entwickler ist es wichtiger, dass die Hardware möglichst Atari-nah bleibt, damit sich der Aufwand für Umsetzungen und Anpassungen in Grenzen hält.
-
Also für mich wäre bei einer Neuauflage nur eines sehr wichtig, eine schnellere Grafik und wenn es endlich gehen würde die DSP Unterstützung, als zweites, so das man endlich einem Falcon nahe kommt.
Bei der Grafik wünsche ich mir echt, das da eine PCI Graka ihren Dienst dann verrichtet. Es geht doch nicht an, das es nur zwei Leute schaffen, eine Radeon anzuschliessen. Das muss einfacher gehen!
Wenn das mit der Grafik geklärt ist, dann bin ich auch gerne bereit eine neue Version zu kaufen.
-
Ich gebe Angelika recht. Eine schneller Grafik fände ich auch gut und zeitgemäß. Die Performance einer CTPCI mit Radeon wäre für mich der Maßstab.
Zum Beispiel könnte man die Firebee doch direkt mit einer passenden 1-Slot PCI Backplane und einem höheren Gehäuse ausliefern, wo man ohne Probleme eine Radeon einstecken kann. Wenn es denn eine Bezugsquelle für größere Mengen von passenden Grafikkarten gäbe, könnte ich mir sogar ein Bundle vorstellen.
-
Ich gebe zu bedenken: PCI ist nicht mehr zeitgemäß, man bekommt diese Karten kaum noch. Man sollte dann eher darüber nachdenken, PCIe 1x zu verwenden und dann einen aktuellen Linux-Open-Source-Grafiktreiber von AMD oder nVidia nach verwertbarem zu zerpflücken, und daraus dann einen VDI-Treiber für eine möglichst aktuelle einfache Grafikkarte zu machen.
-
Ich gebe zu bedenken: PCI ist nicht mehr zeitgemäß, man bekommt diese Karten kaum noch. Man sollte dann eher darüber nachdenken, PCIe 1x zu verwenden und dann einen aktuellen Linux-Open-Source-Grafiktreiber von AMD oder nVidia nach verwertbarem zu zerpflücken, und daraus dann einen VDI-Treiber für eine möglichst aktuelle einfache Grafikkarte zu machen.
Wenn man jemanden dazu findet, aber die PCI Radeon laufen inkl. XBIOS Calls.
http://bus-error.nokturnal.pl/tiki-read_article.php?articleId=11
Das wäre ein grosser Schritt und so viele neue Friebee's wird es auch nicht geben, das man da keine alten ATIs bekommen könnte.
Jedenfalls wäre damit die FB viel aktraktiver als sie nun ist. Ist ja auch Alpha, aber damit könnte man endlich in eine Beta Phase gehen.
-
Ist es dann nit wieder hin mit den alten Games? Oder müßte man dann nicht die Grafikchips an die Grafikkarte weiterleiten?
-
Für alte Spiele, sofern sie überhaupt auf dem Coldfire laufen, könnte man ja im "ST-RAM" eine virtuelle Grafikkarte (also einfach der normale beim ST reservierte Speicherbereich, achtung frei platzierbar) anlegen, und ein Hintergrundtask (Der Coldfire hat gegenüber einem 68000 ja genug Reserven) kopiert das dann in den Framebuffer der PCI(e)-Karte. Dabei muss er natürlich die Bitplane-Ebenen in Bytes pro Pixel umwandeln, was das Ganze etwas aufwändig macht. Oder man lässt das eine Art Blitter in VHDL machen...
-
Jetzt nenne ich den Thread bald in "Wünsch ans Christkind" um! ;)
Im Ernst Dinge wie Formfaktor ändern sind keine kleinen Änderungen für die nächste Serie!
Zu PCI: Die Radeons laufen seit Ewigkeiten. Das Problem ist die Backplane für Enduser derzeit. Ich kann aber vermelden daß seit ein paar Wochen wieder dran gearbeitet wird. Überlegungen wie "PCI is obsolet" halte ich für komplett irrelevant bei Kleinserien. Wir brauchen ja keine 5000 Radeons pro Monat. Außerdem werden sie noch neu hergestellt und ich habe einen Distributor in DE.
PCIe 1x geht mit Adapter auf PCI auch schon problemlos. Ich sehe also keinen Grund die Kompatibilität zum einzig verfügbaren Treiber den es gibt - nämlich den für PCI Radeons - abzuschneiden.
Generell ist zu PCI noch zu sagen daß das eben in der ColdFire Kontroller eingebaut ist. Alle Änderungen wäre also auch mit einem sehr aufwendigen Redesign verbunden.
Und dann noch was zu Börr und Arduino; wir haben einen sehr vielseitigen Expansion Socket on board, da sollten eigentlich an I/Os keine Wünsche offen bleiben! Bis jetzt hat niemand auch nur irgendwas dafür gebastelt!
-
Jetzt nenne ich den Thread bald in "Wünsch ans Christkind" um! ;)
Im Ernst Dinge wie Formfaktor ändern sind keine kleinen Änderungen für die nächste Serie!
Zu PCI: Die Radeons laufen seit Ewigkeiten. Das Problem ist die Backplane für Enduser derzeit. Ich kann aber vermelden daß seit ein paar Wochen wieder dran gearbeitet wird. Überlegungen wie "PCI is obsolet" halte ich für komplett irrelevant bei Kleinserien. Wir brauchen ja keine 5000 Radeons pro Monat. Außerdem werden sie noch neu hergestellt und ich habe einen Distributor in DE.
PCIe 1x geht mit Adapter auf PCI auch schon problemlos. Ich sehe also keinen Grund die Kompatibilität zum einzig verfügbaren Treiber den es gibt - nämlich den für PCI Radeons - abzuschneiden.
Generell ist zu PCI noch zu sagen daß das eben in der ColdFire Kontroller eingebaut ist. Alle Änderungen wäre also auch mit einem sehr aufwendigen Redesign verbunden.
Und dann noch was zu Börr und Arduino; wir haben einen sehr vielseitigen Expansion Socket on board, da sollten eigentlich an I/Os keine Wünsche offen bleiben! Bis jetzt hat niemand auch nur irgendwas dafür gebastelt!
Sehr schön, das an der Grafik Schnittstelle wieder gearbeitet wird. Dann hoffe ich mal das Beste! :-)
Und die ATI Radeon passt zum Leistungsspektrum der Firebee, alles andere wäre nicht angebracht.
-
So gerade wieder über Klaz Seite gesurft (http://www.klapauzius.net/index.html):
Klaz hat ja Arkanoid so weit wie es geht an die Firebee angepasst.
Er schreibt dazu:
- USB keyboards and mice won't work in the game. You'll have to use Atari keyboards/mice or connect PS2 devices via an Eiffel interface.
- Some monitors may not support the FireBee's ST low screen resolution, the output timings generated by the FPGA are not 100% yet. If you get a black screen, try to use the VGA input on your LCD monitor by using a DVI->VGA adapter.
- You need to start the game from FireTOS or from Mint. Running the game from EmuTOS won't work, since there is no 68K emulation layer in EmuTOS.
- There will be slight flicker on some of the sprites here and there, due to the VBL interrupt not being synced to the monitor VBL (hard to fix, maybe some day).
- There's another minor bug in the FPGA/Videl that shifts the entire ST low picture down by one halfline. This is hardly noticeable in this game, though.
- Snapshots taken on the FireBee can't be restored on other machines (and vice-versa).
Das müßte alles noch angepasst werden, dann könnten noch mehr ST/Falcon Programme / Games gepachtet werden.
Frage: Wird daran gearbeitet? Ist überhaupt von den FB-Entwicklern ein Interesse daran? Wenn man schon soweit ist, da müßte doch die letzten Hürden doch zu überwinden sein!
Und: Wie zu Teufel hat das Klaz gemacht? Eine HowTo wäre Klasse, dann könnte sich andere FB-Besitzer auch mal dran versuchen, auch ich!
-
Selbst eine PAK 68/2 (68020-16) ist schneller als der Blitter im ST. Aber Blitter gibts immer noch, ud das schon sehr lange in PC-Grafikkarten, diese arbeiten aber nocht Bitplane-Orientiert, sondern halt in den üblichen Farbmodis. Diese Blitter snd aber wesentlich komplexer, weil sie nicht einfach nur Speicherbereiche kopieren können, sondenr sie können auch Linien zeichnen, Flächen füllen, usw.
-
Quatsch, heute macht man alles über Shader. Wann kann man wieder welche Kaufen?
-
Wie wäre eine Firebee anstatt mit einer Coldfire CPU mit einem gebrauchten MC68060 ...
-
Wie wäre eine Firebee anstatt mit einer Coldfire CPU mit einem gebrauchten MC68060 ...
Ein vernünftig schneller ARM-Prozessor und Aranym bzw. Hatari... Die 68060 sind viel zu rar...
-
Wie wäre eine Firebee anstatt mit einer Coldfire CPU mit einem gebrauchten MC68060 ...
Die Debatte ist doch so alt wie das "Milan-2-Aus". Das wäre unbezahlber! ein 060er kostet 350 Euro neu. Außerdem muß man die ganze Peripherie dazu neu designen wie RAM, PCI, IDE, ... der V4e ist ein Microcontroller der das alles schon eingebaut hat um 30,- Euro. Mit 060er käme ein Rechner auf 1500 Euro oder mehr für weit weniger Leistung. Das zahlt doch niemand, sonst hätte Rodolphe doch sein Projekt vom Powerphoenix schon lange umgesetzt.
-
Wie wäre es, wenn man die CF Karte so legen könnte, sodass man diese einfach ein- und ausstecken, also wechselbar machen könnte?
Grund: So muss man jetzt die FB aufschrauben (mag ich nicht!), um die CF zu tauschen, um mal z.B. EasyMint zu testen auf einer neuen CF.
So wie es jetzt ist, habe ich nach den vor Monaten gemachten Erfahrung mit EasyMint und Falcon keine grosses Vertrauen oder in das Aufsetzen einer neuen CF. Gibts da außer dem Tutorial für Gpart kein gutes Tutorial wie man eine neue CF Karte mit MiNT einrichten kann?
-
Angelika, wenn Du auch noch einen Platz für einen externen Zugang zur CF-Karte herzauberst (ohne das Board zu vergrößern), ... ;)
Im Ernst, das geht sich ja nicht aus, wenn Du das Board mal genau betrachtest. Und eigentlich ist ja die SD-Karte als Wechselmedium gedacht. Und wenns Dir wirklich super-wichtig ist, es gibt auch Leute die am 2. IDE-Bus CF-Karten laufen haben, die kann man dann überall hinlegen.
Partitionieren geht leider noch nicht mit Boardmitteln. Da braucht es noch externe Programme und Rechner.
-
Ich hatte auch einen Atari. Einen MegaST mit 4MB und ein Viking 19'' Monitor.
Bis auf "StarGlider" und "The Pawn" habe ich nie auf einem ST gespielt - sondern
"nur" gearbeitet: Sei es mit OS9/68000 oder RTOS/PEARL oder was mein gesamtes
IT-Leben danach geprägt hat: Smalltalk-80 unter 1280x1024 monochrom - das hat
einfach alles getilt ....
Seit 24 Jahren habe ich dann nichts mehr mit dem ST gemacht aber mit zunehmenden
Alter schaut man zurück und worauf schaut man zurück: auf den Atari ST und andere
ältere System. Noch einmal einen zulegen ? Was kostet es ?
Nun ja all diese Systeme haben das gleiche Problem: OS/2 oder eComStation, RiscOS,
GEM, DOS. Die Hoch-Zeit ist vorbei und man sucht sich sein Plätzchen.
Dabei fällt mir vor allem ein System auf: RaspberryPI. Ein eigentlich underpowered
System - das aber das Herz der Leute erreicht. Warum eigentlich ...
Es ist billig. Das scheint mir wichtig zu sein. Geht das Ding kaputt, dann wird
einfach ein neues bestellt - und man kann sicher sein, dass man ein neues System
bekommt. Das System hat seine (technischen) Schwächen - das ärgert alle, ABER es
nehmen alle in Kauf.
Linux ist da mit GUI, viel Software - aber unglaublich langsam. Aber das scheint
auch keinen mehr zu stören. LibreOffice ist da, man kann drucken, man kann ins
Internet gehen und kann viel damit machen. Der geniale Einfall ist die GPIO Leiste,
die einfach unglaublich viele Menschen motiviert - einfach, aber es geht.
Bücher erscheinen.
Wer würde es wagen, mit einer Firebee zu basteln ? Wenn die kaputt geht, dann sind
mindestens €600 im Eimer - und man bekommt eventuell keine mehr nach. Also lässt
man das lieber und nimmt einen Pi. Wenn der kaputt geht ... (s.o.).
Der Pi liefert (unter Linux) alle Programmiersprachen mit. Also bietet er einen
einfachen Einstieg für alle Programmierer.
Interessanter ist dann der Blick auf RiscOS unter dem Pi. Ein System mit guter
Geschwindigkeit unter dem Pi, aber mit einer immer kleiner werdenden Community.
Diese Community wurde komplett überlaufen von dem Interesse und sie ähnelt der
Atari-ST Community: Primär alte Software, wenige neue Entwicklung - halt eine
ältere Community. Aber mit einigen interessanten Aspekten:
* das Betriebssystem ist OpenSource
* man hat nun eine SD herausgebracht, in der man zu Sonderpreisen Software
raufgepackt hat, die nur unter RiscOS unter dem Pi arbeitet. Man hat also
alle Softwarehersteller irgendwie hinter sich bekommen.
* man liefert ein SDK ebenfalls zu einem Sonderpreis auf SD inklusiver der
Dokumentation bzgl. Programmierung .
Auch hier gibt es Druckprobleme, Netzwerkprobleme ... aber nach einer langen
Zeit scheint man das mit der aktuellen Software langsam in den Griff
zu bekommen. Aber mit den Programmiersprachen unter RiscOS ist das so ein
Problem: eigentlich nur C (wenn man vom alten BBC-BASIC) absieht. Hier
fehlt klar eine einfache Sprache, die nur mit einem Editor auskommt. Hier
redet auch keiner mehr von kommerzieller Nutzung.
Dann noch eComStation: geschlossene Software mit kleiner Community. Primär
immer noch kommerzielle Nutzung. Aber nun mit Mozilla Firefox, Thunderbird
und OpenOffice. Man kann also mit dem System auch arbeiten.
Was würde ich mir von einem Atari-ST System wünschen ?
Wenn ich nur alte Software ablaufen lassen will, dann reicht mir der MiST
für €210. Die Firebee kostet immerhin praktisch immer noch das vierfache
davon.
Mit der Viking-Emulation der MiST könnte ich zumindestens das System
bekommen, dass ich noch Ende der 80ziger Jahre aktiv nutzte.
Ich würde daher eher für eine Neuauflage der Firebee nach altem Muster
plädieren: zuviele Teile sind noch nicht genutzt oder funktionieren noch
nicht sicher genug. Die Neuauflage sollte daher zwei Punkte erfüllen:
-> es gibt sie noch, man kann sie kaufen
-> die erste und zweite Auflage soll nur ein Ziel erfüllen:
-> ein letztes natives 68K System für reine GEM Programmierung
bzw. Konsolenanwendung anzubieten
-> Subsysteme weiter entwickeln
Eine dritte Auflage der Firebee sollte günstiger werden. Raus mit
allen Sachen, die nicht notwendig sind:
-> ACSI/SCSI-Schnittstelle
-> ST-Tastatur
-> ST/TT Floppy
Was ich beibehalten würde: RS-232, IDE, Midi, Printer.
Den Bastelaspekt würde ich mit einem verbesserten Support für den ROM-Port
und dem Extension-Socket stärker hervorheben. Einen interessanten Aspekt
fände ich die Aufnahme von Arduino-Interfaces - wie man ihn jetzt erstmals
bei den FPGA-Herstellern finden kann (Altera). Wegen dem Bastelaspekt
würde ich auch den Centronics- und den RS-232 port lassen. Genial einfache
Interfaces. Allerdings sollte es so abgesichert sein, dass man die Firebee
nicht zerstören kann - vielleicht wäre es billiger einen Pi
davorzuschalten :-)
Grafische Auflösungen wie HD halte ich für unbedingt wünschenswert.
Kann man den Extension-Port hardwaretechnisch dem Extension-Port des
RaspberryPI nachempfinden ?
Man sollte versuchen, 1-2 Softwareprodukte aktuell auf der Firebee zu
halten oder lauffähig zu halten:
-> Cubase
-> Papyrus
-> Calamus
Man sollte eine SD-Card verkaufen, die zumindestens alle notwendigen Tools
und Doku beinhaltet, um ST-Software erstellen zu können mit aktueller
Dokumentation etc. Eine Entwickler-SD sozusagen. Auch mit sehr einfachen
Programmiersystemen wie BASIC, Python oder so etwas.
Und eine entsprechende Applikations-SD - eine Sammlung von einigen Anwendungen,
die heute noch funktionieren und sinnvoll sind.
Aber wie gesagt: ich habe seit 24 Jahren keinen Atari mehr angefasst, aber
eine Firebee hätte ich fast zu Weihnachen mir gekauft - aber es gab sie nicht.
Daher habe ich mir eine MiST bestellt und dann geht es wieder langsam los.
Aber eine Firebee fände ich immer noch toll.
Aber es sind noch viele, viele Fragen bei mir offen:
- wo finde ich Quelltexte aller Systeme (FPGA) ?
- bis auf FireTos sollte doch alles offen sein ?
- wo finde ich die Dokumentation ?
- welche Compiler/Interpreter soll man nutzen ?
- es fehlt an Doku bzgl. Programmierung
- welche besonderen Features des Chips werden eigentlich genutzt ?
-
Sehr interessantes Posting! Danke dafür.
Eine dritte Auflage der Firebee sollte günstiger werden. Raus mit
allen Sachen, die nicht notwendig sind:
Ich möchte nochmal darauf hinweisen, daß alle Anschlüsse gemeinsam - wir sprechen von MIDI, ACSI, Floppy, Paralell, 2 x Seriell, ROM-Port, SCSI, Atari Tastaur/Maus, Game-Port, PS/2 gerade mal 50 Euro am Preis des Boards ausmachen. Es ist also relativ sinnlos sie wegzulassen, zumal es auch meißt nur PIN Header sind (dazu unten mehr).
In Kleinserien bekommt man ein so komplexes Board leider nicht wirklich billiger.
Den Bastelaspekt würde ich mit einem verbesserten Support für den ROM-Port
und dem Extension-Socket stärker hervorheben.
Der Bastelaspekt wäre ja noch viel genialer, da die ganzen PIN-Header ja als alles funktionieren können das im FPGA konfigurierbar ist. Beispielsweise könnte ACSI auch als Falcon DSP-Port dienen, oder SCSI als zusätzliche I/Os usw.
Und das alles auch während dem Betrieb umkonfigurierbar, ... ;)
Grafische Auflösungen wie HD halte ich für unbedingt wünschenswert.
Geht schon derzeit problemlos. Scrolling ist halt für heutige Ansprüche schnarch langsam, was ein FPGA Entwickler aber ändern könnte.
Man sollte versuchen, 1-2 Softwareprodukte aktuell auf der Firebee zu
halten oder lauffähig zu halten:
-> Cubase
-> Papyrus
-> Calamus
Papyrus läuft problemlos, Calamus will Ulf jetzt 2015 nochmal angehen hat er gesagt (nachdem viele Anfragen zur Lauffähigkeit auf der FireBee gekommen sind, schätze ich) und Cubase ist ein Sorgenkind, da etliches am System vorbei passiert, direkt auf Hardwareadresse zugegriffen wird, oder auch nur niedrige Auflösungen möglich sind.
Man sollte eine SD-Card verkaufen, die zumindestens alle notwendigen Tools
und Doku beinhaltet, um ST-Software erstellen zu können mit aktueller
Dokumentation etc. Eine Entwickler-SD sozusagen. Auch mit sehr einfachen
Programmiersystemen wie BASIC, Python oder so etwas.
Ja, das hast Du vollkommen recht. So ein Entwickler-Paket war auch schon lange angedacht, ist aber mangels manpower nie umgesetzt worden.
Wenigstens gibt es im offiziellen MiNT-Setup ein Entwicklungspaket mit dem sofort losprogrammiert werden kann!
Und eine entsprechende Applikations-SD - eine Sammlung von einigen Anwendungen,
die heute noch funktionieren und sinnvoll sind.
Auch das ist als Addon zum MiNT-setup schon länger angedacht. Womöglich wird es aber auch "nur" ein gutes Verzeichnis auf der Homepage, ...
- wo finde ich Quelltexte aller Systeme (FPGA) ?
http://atariforge.org/gf/project/firebee/
- bis auf FireTos sollte doch alles offen sein ?
Ja genau.
- wo finde ich die Dokumentation ?
In den Hirnen der jeweiligen Entwickler, die oftmals sehr Dokumentationsunwillig sind. Angelika z.B: verzweifelt daran ja auch schon. Es gibt zwar einiges an Info, aber das muß man sich mühsam zusammenklauben. Was genau hättest Du gerne?
- welche Compiler/Interpreter soll man nutzen ?
Du kannst GCC, AHCC, vbcc oder GFA-Basic nutzen derzeit.
- es fehlt an Doku bzgl. Programmierung
Ja.
- welche besonderen Features des Chips werden eigentlich genutzt ?
Welcher Chip? Ich verstehe die Frage nicht.
-
Welcher Chip? Ich verstehe die Frage nicht.
Ich meinte die Teile auf der Coldfire: DMA-Einheit auf dem Coldfire und die Timer und die anderen Sachen halt auf dem Chip.
Wie sieht es eigentlich mit der Verfügbarkeit des Coldfire-Prozessors aus ? Sind die bereits abgekündigt und wenn ja: wie lange bekommt man dann noch diese Chips ? Wenn es diese nicht mehr geben sollte, bliebe wohl in der Tat nur noch FPGA übrig ....
Marten
-
Welcher Chip? Ich verstehe die Frage nicht.
Ich meinte die Teile auf der Coldfire: DMA-Einheit auf dem Coldfire und die Timer und die anderen Sachen halt auf dem Chip.
Wie sieht es eigentlich mit der Verfügbarkeit des Coldfire-Prozessors aus ? Sind die bereits abgekündigt und wenn ja: wie lange bekommt man dann noch diese Chips ? Wenn es diese nicht mehr geben sollte, bliebe wohl in der Tat nur noch FPGA übrig ....
Marten
Der Coldfire-Microcontroller hat "on-chip" eine 16-Kanal-DMA-Einheit, zwei Netzwerkinterfaces, vier serielle Ports, einen Interrupt-Controller, eine EMAC "DSP"-Einheit (so ähnlich wie "AltiVec" beim PPC), vierkanaliges SPI, ein PCI-Interface, zwei "Slice"-Timer, vier "General Purpose"-Timer, nochmal "ne Hand voll" COMM Timer, ein USB-Slave-Interface, drei schlelle SRAMS und ein i2c-Interface.
Wenn ich nichts vergessen habe.
Fast alle der "spezialisierten" Anschlüsse können auch als "normale" I/O-Ports verwendet werden.
Benutzt wird davon heute von allem ein bißchen was, außer dem EMAC (soweit ich weiß, gibt's noch kein Programm, das den wirklich nutzt).
Zum Experimentieren ist aber noch mehr als genug übrig...
-
Ja, ja das liebe fehlende SDK! Vor allem wenn man 20 Jahre später wieder einsteigt, dann fragt man sich nur noch: "Was zur Hölle geht eigentlich ab..." und da gebe ich Matthias recht, daß man sich hier wieder wie damals rein denken muss.
Ich habe nun nach ein paar Monaten Pause über den Sommer wieder mit der Firebee angefangen und mich erstmal durch Unmengen an Downloads von Sourcen und Dokus durchgeschlagen, um ein passablen Weg zu finden, der da nun heisst: Crosscompiler Mac zu Hatari / STE / Falcon und parallel Coldfire Exe zum Test auf FB. Das zunächst mal mit Assembler um wieder ein Gefühl für die Chips und TOS/GEM Funktionen zu bekommen. Als nächstes steht dann C mit GEM im Vordergrund, evtl. mit einem kleinen Abstecher zu GFA (der Artikel in neuen ST ist doch reizvoll dazu, was da geht). Also C mit GEM, weil ja alles MiNT konform sein soll und nix mehr TOS, wobei ich das mit Arkanoid immer noch interessant finde.
Zu Software: Ja, das passt heute, da ich gerade heute Abend mir mal die Software aus der Atari UpToDate Liste die Mega-Programme vorgenommen habe, ob ich sie finde und was ist, mager ist es.
Also ich habe mir folgende Programme ausgesucht:
Texel 2.2, Artworx 2.09, Chagall 2.0, Papillion 3.0, Papyrus 10.20 und K-Spread 4.
Ergebnis: Texel und Artworx finde ich nirgends. Texel nur eine 1.6 Version. Artworx gar nicht.
Chagall sogar in der 2.11 Version, aber die geht auf der FB nicht, mal sehen ob die 2.0 geht.
Papyrus nur eine 4x Version, aber keine 10.20. K-Spread 4, ok! Wenn ich vor über 1.5 Jahren nicht die NVDI 5 Dateien gefunden hätte, wäre es damit auch "Essig".
So am Wochenende teste ich die gefunden Versionen aus, ob diese auf der FB gehen.
Was ich damit sagen möchte, wie kann man sagen, die Programme gehen, wenn man als FB-User diese Programme nicht finden kann. Ja, Texel und Artworx wird es heissen, wende Dich an ASH, aber direkt kommt man auf die Bestellseite auch nicht drauf, also eigentlich nichts mehr offizielles. Papyrus findet sich gar nicht mehr! Also wie soll man da ran kommen, da haben nur die durchgängigen User ihre Ressourcen, aber wir Neu-Wiedereinsteiger kommen da überhaupt nicht dran.
Hier nun mein Ansatz: Das Firebee-Team soll sich mit den alten Entwicklern/Distributoren einigen, das man die letzten Versionen frei gibt (evtl. mit Source zur Weiterentwicklung für die FB - da würde ich mich sogar anbieten für die Wartung) und diese Programme dann den jeweiligen Firebee Käufern mit gibt, als Rundum Sorglos Paket; ob nun als SD oder Download ist egal. Hauptsache ich höre nicht immer wieder, bei mir geht´s aber mit der und der Version. Weil es gerade so viele "freie" Versionen gibt die nicht auf der FB gehen, führt das ganze zu einem Software-Problem auf der FB. AtariUpToDate ist da schon mal eine grosse Hilfe. FB ist ein Nische und da muss man das ganze einfach Bündeln.
Das sowas geht, sieht man mit Photoline.
Ach ja, da ich so schön gerade am Schreiben bin, als nächstes kommen Tracker dran, ist da mit der FB Erfahrung gesammelt worden?
Und Matthias, was meinst Du damit: "im offiziellen MiNT-Setup ein Entwicklungspaket mit dem sofort losprogrammiert werden kann" ? Also auf der FB CF-Card war nix drauf! Also wieder das schöne Spiel "Such mich!" ? Das ist doch was Neu-Wiedereinsteiger verwirrt, welche Infos habe Gültigkeit und welche nicht und wie fange ich am Besten an! Die damalige Aussage "Alles wie früher beim Falcon ist gültig!". Hm, schon damals musste man sich die infos für den Falcon zusammen suchen. Also hier ist dringender Bedarf!
-
Abend Angelika!
Ich kann das alles schon nachvollziehen, was Du schreibst und wie Du das empfindes. Und generell hast Du ja recht.
Aber; da steckt so unglaublich viel Arbeit dahinter, wo Du einfach ein lapidares "das FireBee Team sollte" schreiben kannst. Alleine meine Korrespondenz mit ROM und Invers und die ganzen Überlegungen, Ansätze und Nebenabsprachen dazu mit anderen Programmierern usw. würden ein kleines Taschenbuch füllen.
Schau Dir doch mal an wie es mit THING! und den ganzen Sachen von Sven gelaufen ist (und immer noch läuft), wo wir recht erfolgreich waren, dann bekommst Du einen Eindruck wie langwierig und umfangreich das Alles ist. Das passiert nicht einfach so, sondern muß gemacht werden.
Also Freiwillige vor! ;)
Daß dann auch viele der Programme die Du nennst in so einer komischen Schwebe sind, kommt ja auch nicht von ungefäht. Das waren alles ehemalige professionelle komerzielle Programme, und teilweise kann man sie immer noch kaufen. (Im Zweifelsfall an Oliver Buchmann von ASH direkt schreiben.)
Das sie jetzt einerseits nicht mehr aktiv verkauft werden und andererseits nicht frei sind, ist natürlich anstrengend. Ich wäre mit beiden Möglichkeiten zufrieden, aber ordentlich verfügbar sollten sie sein, ohne daß man den Hersteller bitten muß sie zu verkaufen!
Und auf Deiner CF-Karte sollten am Desktop AHCC, Digger und RSM sein, von Anfang an. Wenn nicht dann auf C im Ordner DEVTOOLS. Das war uns recht wichtig, daß das bei den Basisprogrammen mit dabei ist.
-
Ich habe ja auch nicht Euere Arbeit kleingeredet. Es ist beachtlich was geleistet wurde und ich honoriere es. Das FB- sorry- ACP-Team (http://acp.atari.org/contact_de.html) ist schon ein gutes Stück voran, aber es gibt da drei Baustellen.
1. Hardware / VHDL
- Grafik-Problem aka Anbindung des Grafik-Speichers an den FPGA. Wolfgang arbeitet ja schon dran und meine ganze Hoffnung und alle guten Wünsche begleiten Ihn, das er das Problem diese Jahr in den Griff bekommt.
- VHDL-Entwickler fehlen. Leider! ich hab mir es angeschaut, so schwer ist das nicht von der Sprache her; nur fehlt mir das erweiterte elektrotechnische Wissen dazu (nur TG und Informatik-Studium reicht da nicht).
2. Software-Pakete:
- Eine korrekte Zusammenstellung und "Download" Möglichkeit für den FB-User. So wie es die Kollegen von A-EON für den Amiga mit dem AMIStore nun machen. Z.B. Photoline war für die FB freigegeben aber nicht auf der CF der FB.
3. Developer-SDK:
- Aktuelle Entwicklersoftware: Ist ja nett das AHCC, Dinger und RSM mit dabei waren. Aber nicht in der aktuellen Version, da muss der FB-User sich erst mal schlau machen, wo er die Updates herbekommt. Zudem was bringt die Software, wenn keine Doku vorhanden ist und man kann außer evtl. der mitgeliefert Demo-Source nix dazu anschauen bzw. etwas selber programmieren.
- Nicht alle Entwicklersoftware war installiert. Als ich die FB gekauft habe, gab es schon GFA, GCC und VBCC. Und das war eine Enttäuschung als ich dazu auf der CF nicht gefunden habe. Ich dachte doch naiv, dass ich für das Geld wenigstens was Rundes bekomme, wo ich zunächst mal alles vorfinde und nicht suchen muss.
- Dokumentation: GANZ WICHTiG! MiNT wie funktioniert es. Wie funktioniert XaES, wie der Desktop, warum gibt es verschiedene Desktop-Tools. Wie kann ich am besten mit GEM und dem AES (XaES oder myAES) umgehen, programmtechnisch. Nein, kein Kurs in Assembler oder C. Wobei C für MiNT das geeignete Mittel ist. ich bin gerade heute über 92/93 Ausgaben des ST Magazins und ST Computers gestossen, wo es dazu Artikel gibt (MiNT / MultiTOS, Einführung, MiNT-API, Worauf muss man bei der Spieleprogrammierung unter MiNT acht geben). Stelle ich gerade zusammen! Das fehlt dem versicherten FB-User/Entwickler. Es sind kleine Artikel, also kleine Hilfen, aber besser als gar nichts.
-Zusatz: Crossdev-Kits GCC auf Win oder Mac inkl. Doku "How To and Debug" oder VBCC. Wie kann man für STE/Falcon und FB gleich programmieren, worauf muss man achten usw.
So, das erst mal soweit. Du hast mir immer noch nicht zu Papyrus geantwortet, wo bekomme ich die 10.20 her.
Wie gesagt, ich bin "Neu" und habe die Kontakte nicht, dafür machst Du das ganz gut, aber wenn es Dir hilft, gibt mir die eMail Adressen ich kann die auch mal kontaktieren. Nur mein Ruf ist der, daß wenn ich was "Scheisse" finde, das auch sage. Ich bin nicht diplomatisch! Also nicht jeder findet meine Art gut!
Ach ja,vor Weihnachten habe ich den Philipp Donze angemailt, ob er für den GCC Grosscompiler Port für den Mac, die fehlenden Libs SDL und LDG mit aufnimmt, damit ich mal so ein paar SDL Games für die FB durchcompilieren und für die FB-User zugänglich machen kann. Leider hat er nicht geantwortet.
So, noch was für die Source-Code-Fraktion. Auf github kann man sich ein GROSSES Packet an Source für den ST/E/Falcon herunterladen. Da ist alles darunter von Hardwaretreiber über Demos in Assembler bis Spiele, also zugreifen: https://github.com/ggnkua/Atari_ST_Sources
Danke dem edlen Spender für den Upload!
-
Dem kann ich in nahezu allen Punkten nur zustimmen. Ich habe jetzt auch zu büffeln. Was ist von den vielen WWW-Seiten überhaupt noch relevant - was ist nicht mehr relevant. Was ist der "normale" Programmierweg (xyz-Mint, xyz-AES).
Das mit den github-Seiten ist schon mal ein guter Fundus.
Auf der anderen Seite ist der Einsatz von Software, die man nicht einmal mehr kaufen kann, eine extreme Falle. Ich weiss z.B. nicht mehr, ob NVDI wirklich notwendig ist ? Legal kann man das wohl nicht mehr kaufen.
Brauch ich einen HDDDriver - muss ich den kaufen, oder ist der bei der FB dabei ?
Ansonsten wäre eine Doku wirklich wünschenswert zu wissen, welche besonderen Resourcen der Firebee bereits durch das System genutzt wird (DMA-Controller, Timer...) - oder ob man sich primär auf die ursprünglichen Atari-ST Hardware verlaesst.
Dieser Chip ist ein Traum für einen Realtime-OS Entwickler (FreeRTOS portieren ?) - muss richtig Spass machen. Aber wie sieht das mit der Verfügbarkeit der Chips aus ...
Der VHDL-Resourcen habe ich mal durch Altera 13.1 gejagt - ohne Fehler :-), scheint aber noch eine Menge Platz im FPGA zu sein korrekt ? Wenn ich das richtig verstehe, sind erst knapp 30% (LE) der Resourcen genutzt !?
Noch Fragen ?
1) Kurze Einführung in die Besonderheiten mit VHDL/FPGA Programmierung in Zusammenhang mit dem Firebee Board. (Kompletter zyklus: Checkout von xyz, übersetzen, Kabelverbindungen mit der Firebee ...)
2) Genaue Memory-Map der Firebee.
3) Werden die besonderen Debugfähigkeiten der Coldfire-CPU bei der Firebee unterstützt. Wenn ja - wie ?
Aber zur Zeit wäre überhaupt die Verfügbarkeit einer Firebee wünschenswert .... meine MiST habe ich inzwischen und mit der 1280er Auflösung und monochromer Auflösung und dem Hyper-Chipset kann man schon recht gut arbeiten.
Ich habe ja auch nicht Euere Arbeit kleingeredet. Es ist beachtlich was geleistet wurde und ich honoriere es. Das FB- sorry- ACP-Team (http://acp.atari.org/contact_de.html) ist schon ein gutes Stück voran
-
Zu MiNT gibt es hier was:
http://wiki.sparemint.org/index.php/Mantis:start
nicht ganz frisch, aber kann ja jede(r) noch ergänzen.
Zum TOS allgemein hier:
http://toshyp.atari.org/
Mehr hab jedenfalls ich zuletzt eigentlich nicht gebraucht.
-Helmut
-
@parc_de und @AngelikaZ: Ich kann euch mit dem, was ihr geschrieben habt, nur zustimmen. Ich bin zwar kein Programmierer und ich habe von dem Thema auch null Ahnung, aber wie ihr schon über Papyrus und andere Anwendungsprogramme geschrieben habt, dieselben Probleme habe ich oder hatte ich auch. Und mich stört das auch, dass es keine zentrale Anlaufstelle für die Firebee gibt, was Softwareupdates etc. angeht. Ich denke, das Problem wurde schon oft genug geschildert und beschrieben. Das ist eine Sache.
Wenn man einen Blick ins Amigalager wirft, dann wird man echt verdammt neidisch. Man hat die Auswahl zwischen mehreren Desktopsystemen und die Softwareunterstützung ist inzwischen verdammt gut. A-EON leistet in dieser Hinsicht verdammt gute Arbeit und ich denke, die haben alles richtig gemacht. Allerdings - und das wäre die andere Sache - ist A-EON auch ein kommerzielles Unternehmen. Das ACP Team ist das nicht. Dort sind alle mehr oder weniger ehrenamtlich tätig und opfern bereitwillig ihre Freizeit für das Projekt. Gäbe es alle diese Menschen nicht, dann gäbe es keine Firebee. Dass es die Biene überhaupt gibt, ist auch deswegen erstaunlich, da mit dem Scheitern des Milan II und der Milan Computer GmbH auch eine ganze Menge Atari User der TOS-Plattform den Rücken kehrten und jene mehr oder weniger praktisch zusammenbrach. Die Leute, die heute noch übrig sind, sind die letzten Mohikaner. Ich denke, dass der Atari Szene und vor allem dem ACP schlichtweg die Manpower fehlt, um das Firebeeprojekt so zu stemmen als wäre es ein kommerzielles Projekt wie es damals der Milan war. Das ist ein Ding der Unmöglichkeit. Nichtsdestotrotz meine ich, dass eine Firebee-Homepage mit den entsprechenden Links zum Runterladen der Systemsoftware und anderer wichtiger Anwendungsprogramme, der Development-Tools und entsprechender Anleitungen ein riesiger Schritt nach vorne wäre für das Projekt. Bloß wer machts? Das liegt auch etwas an uns. In dieser Hinsicht hat
Matthias Jaap mit der AtariUpToDate-Homepage echt etwas großes geleistet und ich denke, diese Adresse sollte für jeden Neuling die erste Adresse sein, wenn man nach TOS-kompatibler Software sucht:
http://www.atariuptodate.de/de/firebee/
Wir haben es auch der Firebee zu verdanken, dass es diese Homepage überhaupt noch gibt bzw. dass diese auch aktuell gehalten wird.
Wenn man nach Anleitungen sucht und vor allem Infos in Sachen "How to do", dann sollte man einen Blick ins NewTosWorld-Wiki werfen:
http://www.newtosworld.de/
http://wiki.newtosworld.de/Hauptseite
In Sachen in MiNT und dessen Installation ist folgende Seite DIE ultimative Seite:
https://sites.google.com/site/probehouse/mint-os-for-atari/installing-mint
Im Grunde sind die Informationen, die man braucht, alle vorhanden. Es fehlt nur eine gewisse Bündelung an zentraler Stelle. Und wie gesagt, es liegt nicht auch zuletzt an uns letzten Mohikanern sowas wie das NewTosWorld-Wiki mit Leben zu füllen. Da muss sich dann aber auch jeder selbst in den Arsch treten und wenn man etwas herausgefunden hat wie etwas geht und umsetzbar ist, es im Wiki veröffentlichen.
Eine Art abgespeckte Firebee wird wohl genauso wenig alleine vom ACP stemmen zu sein wie die oben beschriebenen Sachen, fürchte ich. Ich weiß aber auch nicht ob eine solche Biene wirklich notwendig wäre. Ich bin aber auch kein Entwickler. Ich denke nur wenn man alte ST-Software nutzen möchte und nicht auf originale Hardware zurückgreifen kann oder will, man am besten zu den FPGA-Clones (Suska etc.) greift. Die Firebee ist in dieser Hinsicht schon High End und infolgedessen auch nicht für fast 30 Jahre alte TOS-Programme gedacht sondern für aktuelle Programme oder eben solche, die noch Ende der 90er Jahre für die Clones entwickelt wurden und heute immer noch brauchbar sind. So sehe ich das zumindest.
Ich freue mich aber schon auf die zweite Auflage der Biene zumal ich mir auch schon eine bestellt habe. Ich bin mir über die Hürden, die damit verbunden sind, durchaus bewußt, aber ich bin eben auch so ein Bekloppter, der die Biene unbedingt haben möchte und austesten möchte was geht und was nicht. Zugegeben ist der Nostalgiefaktor auch ein wenig dabei. Ich denke auch, dass man nichts falsch gemacht hat, indem man auf die Coldfirelösung setzte. Auch wenn es den 68060 anscheinend bei Freescale noh gibt (wie auch den 68000), so ist in dieser Hinsicht die Fahnenstange erreicht. Der Coldfire wird wohl weiter entwickelt und auch die Freescale-Seiten dazu sind nicht schlecht soweit ich das verstehe, was dort geschrieben steht:
http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF
So. Jetzt habe ich meinen Senf auch nochmal dazu gegeben. Ich hoffe, Mathias kotzt nicht wegen der vielen Kritik und dass er sich immer wieder rechtfertigen muss, aber es ist eben nicht so einfach wenn so viele Querdenker mit gewissen Eigenheiten - wie es die verbliebenen Atarianer zweifelsohne wohl sind - zusammen etwas auf die Beine stellen wollen oder müssen, damit ihre Plattform nicht total aussterben wird.
-
Liebe Angelika!
Es gibt ein paar mehr als 3 Baustellen. Aber die werde ich jetzt nich auch noch alle ausbreiten ;)
Grundsätzlich hast Du ja recht, daß all das was Du da im letzten Posting angesprochen hast wünschenswert wäre. Nur das nützt ja nichts wenns niemand macht! Und manche Forderungen sind auch unrealistisch. Du kannst nicht ernsthaft erwarten, daß wir 4 Entwicklungsumgebungen immer aktuell halten auf der Vorinstallation. Sowas ist nicht administrierbar, und in 3 Monaten muß man eh das nächste mal updaten, also ist es nicht schlimm wenn die Version auf der Platte 2 Jahre alt ist.
Und bei anderen Plattformen hat man auch noch keienn C-Compiler installiert, wenn man sich einen Computer kauft.
Das soll jetzt natürlich nicht bedeuten, daß es nicht sehr viel zu verbessern gäbe. Ja, teilweise ist es ein riesen Chaos. Das liegt aber auch an den Menschen die da zusammenarbeiten. Manche z.B. wollen nicht daß ihre Software woanders gehostet wird (wie auf der ACP-Seite), andere Entwickler aus dem Team informieren uns über neue Software via atari-forum.com :-) Und selbst wenn es da keine Stolpersteine gäbe, es gibt niemanden der die Datenbank sinnvoll wartet.
Ließ Dir doch nochmal die "Jobbeschreibungen" im Thread "Das ACP sucht Dich" durch. Das ist ernst gemeint dort, und den Arbeitsaufwand bräuchte es damit wir alle Ideen von uns und die Ansprüche der UserInnen umsetzen könnten. Und damit sind wir auch schon beim Punkt; es fehlt ja nicht an den Ideen oder dem Wissen was gemacht werden sollte, sondern an Leuten die es tun. Es ist ja nicht neu daß z.B. eine zentrale Downloadseite - zumindest mal für die Eigenentwicklungen - fehlt. Nur wer machts? Insofern sind solche "Forderungen", Ideen oder nur Wünsche halt immer ein Bohren in offenen Wunden, da wir das im Team ja schon vor 4 Jahren so machen wollten.
Es wird also kein Weg daran vorbeiführen, daß alle ein bissl in die Richtung ihrer eigenen Wünsche mitarbeiten. Du Angelika könntest beispielsweise das was du rausfindest im WIKI dokumentieren und es Neuen damit in Zukunft leichter machen.
Insofern kann ich Andreas' Posting über weite Strecken nur zustimmen. Besonders die Notwendigkeit kollaborativ vorzugehen um was weiterzubringen hat es gerade schön beschrieben.
Und ein Punkt noch. Ich hatte auch keine Kontakte. Ein Großteil meiner Tätigkeit besteht auch darin einfach Informationen zu suchen. Das Webarchiv zu bemühen und alte Zeitschriften zu lesen welche Firma was entwicklet hat. Da gibts kein "Geheimsissen" oder unaufholbare Vorsprünge, einfach tun, ...
Zu Papyrus; einfach via papyrus.de den Uli Ramps kontaktieren und sagen daß Du die letzte Atari-Version kaufen willst.
-
So, noch was für die Source-Code-Fraktion. Auf github kann man sich ein GROSSES Packet an Source für den ST/E/Falcon herunterladen. Da ist alles darunter von Hardwaretreiber über Demos in Assembler bis Spiele, also zugreifen: https://github.com/ggnkua/Atari_ST_Sources
Danke dem edlen Spender für den Upload!
Wow, da sind etliche Sachen bei, die ich noch nicht kannte. Danke für die Info, werde die Adresse mal ordentlich weiterverbreiten :)
In Sachen in MiNT und dessen Installation ist folgende Seite DIE ultimative Seite:
Vielleicht für die Installation, aber auch dort gibt es nicht die aktuelle Version. Gerade bei MiNT und XaAES ist die Lage ziemlich verwirrend (viele Websites, die meisten veraltet). Ok, aber dafür gibt es ja EasyMiNT :)
-
Lieber Matthias!
Vorweg, dieser Thread heisst "Was sollte bei einer neuen Firebee-Auflage evtl geändert bzw verbessert werden?".
Ergum: Kommt hier alles auf Tisch was ärgert! Punkt! Keine Beweihrächerung, kein Wehleiden, einfach nur Fakten!
Und keine Ausflüche, warum was wie nicht geht! Aus dem und dem Grund. Das höre ich in Labber-Meetings von den Lossern zu genüge. Ich dachte und denke immer noch, das hier darum geht, das Produkt besser zu machen.
Und nicht darum, wie toll wir doch alle sind und streichen uns würdevoll durchs Haar. Never!
Deshalb NICHTS ist UNREALISTISCH. Es ist nur dann unrealistiscch, wenn MAN es nicht möchte! Punkt!
Grundsatz bei der Softwareentwicklung/Produkt: Dem Käufer immer ein aktuelles Produkt geben. Deshalb gibt es sowas wie Continious Integration, sodaß man jeden Sekunde liefern kann. Nur mal um den Level ganz hoch zu halten, muss bei der Biene nicht sein, aber halbwegs aktuell JA doch! Gerne bin ich bereit das zu übernehmen. Muss mich nur dazu überwenden, die FB aufzumachen und mit einer neuen CF Card anzufangen. Werde ich wohl auch nun machen! Aber wenn was kaputt geht, hast Du das Teil bei Dir zur Reperatur. Hehehe !
Und es geht nicht um jeden Compiler wie bei anderen Plattformen, sondern daß du was auf der ACP-Seite ankündigst und dann findet man das auf dem Produkt nicht. Das hat mich füchterlich geägert, auch das die Firmware noch die aus 2012 war (Urauslieferung!) Nee, das geht überhaupt nicht!
Für den Austausch von Informationen ist ein Forum okay, ABER man muss dann sowas auch Bündeln, zum Teil sind die ACP-News ganz nett, aber monatelang tut sich nichts, nicht mal wie früher ein "Stand der Dinge" Report. Das muss kommen! Damit der Kunde sich wohl fühl und nicht alleingelassen. Wenn Du es nichts machen möchtet, dann gibt mir die Infos, aber bitte in Deutsch oder Englisch, aber franzözische bitte übersetzen, die Sprache kenne ich gar nicht.
Ja, diese unseeligen "Jobbeschreibungen". Arggghhh! Sind wir bei einem Konzern! Ich bin Freelancerin, mit nicht von mir sanktionierten und gewollten Strukturen jagst du mich!
Du hast mir damals mit der FB mitgegeben, dass man soviel an Softwareprojekten übernehmen könnte z.B. Vision oder so. Ich hab es mir angeschaut und mich erst mal verkrochen, aus verschiedenen Gründen. Aber der Hauptgrund ist, die Plattform erst mal wiederentdecken bevor man sowas macht. Nun denke ich bin ich soweit, das man dieses Thema angehen kann, wenn überhaupt noch gewollt. Aber mit sinnvollen Programmen wie Texel, Artworks oder Papyrus, zur Pflege und zum Erhalt.
Wichtig Links und Wiki. Hier wäre zunächst sehr sinnvoll, aktuelle funktionierende Links auf einer Seite zusammenzufassen, wo dann der User weiter kommt. Ja, AtariUpToDate ist eine Superseite. Leider sind viele Links "Dead" oder die Programme finden sich nicht. Jedenfalls ist es notwendige das man EINE Anlaufstelle hat und nicht mehrer, wo das ein dort und das andere hier steht, zudem nicht mehr aktuell ist oder veraltet. Das hat mich in den letzten Monaten zur Verzweiflung getrieben.
Und ja, AtariUpToDate könnte sich als die Anlaufstelle herausstellen, evtl. kann man noch Anleitungen, Infos usw. mit auf die Seite nehmen. Ich habe bis jetzt nur an die FB gedacht und in diesem Gedankengang kam nur die ACP Seite vor die das als Produktverantwortliche machen müsste.
So nun weis du was mich geärgert hat und was ich für verbesserungswürdig halte, so wie die Frage am Anfang gestellt wurde.
-
AGP bringt in der Leistungsklasse nichts, vor allem da man auch hier auf gebrauchte Karten zurückgreifen müsste. Interessanter wäre ein PCIe 1x-Slot, evtl. ließe sich da auf Basis eines Opensource-Treibers für Linux einer aktuellen Einsteigergrafikkarte (gibts auch als PCIe x1) was machen. Da müsste man wenigstens nicht mehr auf alte gebrauchte Grafikkarten zurückgreifen müssen.
-
AGP bringt in der Leistungsklasse nichts, vor allem da man auch hier auf gebrauchte Karten zurückgreifen müsste. Interessanter wäre ein PCIe 1x-Slot, evtl. ließe sich da auf Basis eines Opensource-Treibers für Linux einer aktuellen Einsteigergrafikkarte (gibts auch als PCIe x1) was machen. Da müsste man wenigstens nicht mehr auf alte gebrauchte Grafikkarten zurückgreifen müssen.
Ich verstehe das Posting inhaltlich überhaupt nicht! Erstens gibt es die Radeons noch neu in allen erdenklichen Ausführungen. Der Treiber ist da und man muß nicht mehr entwickeln. Zweitens geht PCIe x1 per Adapter von PCI auch problemlos, das hat Didier schon gezeigt. PCIe x1 macht meines erachtens überhaupt keinen Sinn.
-
Natürlich lässt sich PCI nach PCIe usw. über einache Bridge-Chips realisieren, sowas kann sich nur nicht jeder selbst basteln. Wenn Radeons bereits untzerstützt werden, und nicht nur altertümliche Mach32/64-Karten, dann um so besser!
-
PCI auf PCIe x1-Adapter sind Stangenware. Schau Dich mal hier um: http://didierm.pagesperso-orange.fr/ct60/ctpci-e.htm vom September 2011 gibts ein nettes Foto mit laufendem PCIe x1 Adapter in der FireBee.
-
Hallo,
nochmal mein Senf.
Die Adapterkarten, Radeons usw laufen, aber es mangelt an brauchbaren Backplanes wo man die Biene nicht schrottet. Deswegen nochmal mein Apell. Bitte bitte bringt ein Backplane raus das man in ein ATX Gehäuse Schrauben kann um die Zusatzkartenb auch nutzbar zu machen - und Mutige vom Schrotten der Biene durch nicht passende Backplanes zu schützen.
Gruß Matthias
-
PCI auf PCIe x1-Adapter sind Stangenware. Schau Dich mal hier um: http://didierm.pagesperso-orange.fr/ct60/ctpci-e.htm vom September 2011 gibts ein nettes Foto mit laufendem PCIe x1 Adapter in der FireBee.
Ein Adapter auf einem Adapter auf einem Adapter. Professionell aufgebaut nenne ich was anderes. Sowas muss soweit integriert sein, dass man das ohne zu Basteln in ein Standardgehäuse reinbekommt.
-
Also für mich ist eine professionelle Backplane für ein Standardgehäuse alles andere als gebastelt ...
Wenn ich da dran rumlöten müsste wäre das für mich gebastelt !
-
Professionell
;)
https://www.youtube.com/watch?v=AxD21w3xiLk
>:D
-
Jetzt wird's off topic. >:D
Welche Spezifikationen muss eine Backplane denn aufweisen, damit man sie mit der Firebee verwenden kann?
Ums "Adaptieren" kommt man eh nicht herum, wenn man die Biene in eine Backplane steckt. Man muss 'ne Menge Anschlüsse nach draußen führen. Insofern wäre das wohl nichts für mich.
Aber das ist auch alles Geschmackssache. Zumindest besteht die Möglichkeit die Radeons zu nutzen. Ob einem die jetzt gefällt oder nicht, das muss jeder für sich selbst entscheiden. ;D Vielleicht kann man ja irgendjemanden dazu bringen Treiber für eine Nvidia GTX 970 zu schreiben und noch viel besser, der GPU auch CPU-Aufgaben etc. zuweisen. Dann hätten wir vielleicht keine Firebee mehr sondern eine Rocketbee mit Warpantrieb. :P Und wehe jemand bezeichnet meinen Vorschlag jetzt als nicht professionell. :D
-
Auf didiers Homepage siehts man recht gut. Die richtige Backplane haben sonst krachts schonmal komplett (Biene Tot) und dann zwei Leitungen löten. Also Basteln.
Deswegen bin ich dafür ne Bienenplane zu machen, am besten noch mit ein paar sachen integriert, aber das werd ich bei Gelegenheit nochmal extra anführen. Das passt jetzt nicht in diesen Thread/Diskussion.
Aus meiner Sicht wäre das aber wirklich die nächste wirklich wichtige Hardware, am besten noch vor der nächsten Auflage der Biene.
Gruß Matthias
-
Also erstmal, wie ich irgendwo schon gesagt habe, wird an der Backplane seit einigen Wochen wieder gearbeitet. Ich habe mittlerweile eine Radeon im Testbetrieb (als 3. Mensch).
Das Problem an der Backplane ist, soweit ich das verstanden habe, daß die PCI Implementierung im ColdFire mit anderer Voltanzahl läuft als üblich. Daher muß man - obwohl ein 32-Bit-Bus - eine 64-Bit Backplane mit zumindest einem zusätzlich verlegtem Signal nutzen. Sonst brät man wie matashen angemerkt hat die Biene, ...
Ein zweites Problem besteht in der Spannungsversorgung der Backplane und Grafikkarte über die Biene selber, das wird knapp, und wir überlegen grade was die beste Lösung wäre.
-
Also der PCI-Adapter der Firebee hat die Kerbung links - damit gibt sich die Firebee als 3.3 V PCI Karten aus ?
Marten
Das Problem an der Backplane ist, soweit ich das verstanden habe, daß die PCI Implementierung im ColdFire mit anderer Voltanzahl läuft als üblich. Daher muß man - obwohl ein 32-Bit-Bus - eine 64-Bit Backplane mit zumindest einem zusätzlich verlegtem Signal nutzen. Sonst brät man wie matashen angemerkt hat die Biene, ...
-
Also der PCI-Adapter der Firebee hat die Kerbung links - damit gibt sich die Firebee als 3.3 V PCI Karten aus ?
Ja. Die Firebee hat - wie alle Coldfires - 3.3V PCI, ist also völlig standardgemäß. Durch die PC-Dominanz gibt's leider nur sehr wenig "echtes" 3.3V PCI Zubehör. Wer das nicht weiß oder ignoriert und 5v (Karte oder Backplane) "falschrum" steckt, hat 'ne echte "Feuerbiene". Aber nur kurz.
-
Hoffe das die Backplane zur Firebee bald von Medusa kommt, habe mir schon mal eine Radeon 9200 PCI mit zwei Kerben (3,3 und 5V) über Ebay gekauft und hoffe das die passt ...
Die Karte wird doch bestimmt mit fVDI betrieben, oder ?