Autor Thema: Was sollte bei einer neuen Firebee-Auflage evtl geändert bzw verbessert werden?  (Gelesen 40572 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
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. :)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
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.
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
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.

Offline dbsys

  • Benutzer
  • Beiträge: 4.481
  • n/a
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.

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
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.

Offline Börr

  • Benutzer
  • Beiträge: 858
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.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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.
And remember: Beethoven wrote his first symphony in C

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
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.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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 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.
And remember: Beethoven wrote his first symphony in C

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.577
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! ;)
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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

« Letzte Änderung: So 10.08.2014, 22:02:10 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
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.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Da muss ich irgendwas missverstanden haben, naja.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline chris78

  • Benutzer
  • Beiträge: 701
  • Ich liebe dieses Forum!
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?

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.577

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.
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.577
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!
MegaST 4 mit Sounddesigner II MegaBus-Hardware und 56001, MegaSTE, Hades 040, MagiC Mac auf Mac OS 9 und eine FireBee.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
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.
And remember: Beethoven wrote his first symphony in C

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Zitat
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?
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)