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

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Arthur

  • Benutzer
  • Beiträge: 6.800
  • Mein Atari erinnert mich an die gute alte Zeit..
    • Atari Wiki
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.259
    • Ein wenig was über mein anderes Hobby. :-)
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: 6.800
  • Mein Atari erinnert mich an die gute alte Zeit..
    • Atari Wiki
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: 3.230
  • 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: 6.800
  • Mein Atari erinnert mich an die gute alte Zeit..
    • Atari Wiki
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: 702
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: 7.110
  • Da kringelt sich doch die Locke in der Glocke!
    • HomeCon - der Homecomputer-Treff in Rhein-Main - auch für ATARI
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.
Power without the Price. _/|\_ ATARI

Beware of D.A.U.

1040STFM Twer (PAK68/2,Ovrscn,4MB,1GB SCSI,DVD), 4x1040STFM, 520/1040STE, 520STFM, 260ST, 3x520ST/+, Mega ST1+2+4, 2x Mega STE, 2x Falcon030 20GB/14MB, Stacy4, STBook, TT030/Nova/20MB/72GB, SMM804,SLM-804+605, 5xPofo

Offline mfro

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

Offline Arthur

  • Benutzer
  • Beiträge: 6.800
  • Mein Atari erinnert mich an die gute alte Zeit..
    • Atari Wiki
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: 7.110
  • Da kringelt sich doch die Locke in der Glocke!
    • HomeCon - der Homecomputer-Treff in Rhein-Main - auch für ATARI
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.
Power without the Price. _/|\_ ATARI

Beware of D.A.U.

1040STFM Twer (PAK68/2,Ovrscn,4MB,1GB SCSI,DVD), 4x1040STFM, 520/1040STE, 520STFM, 260ST, 3x520ST/+, Mega ST1+2+4, 2x Mega STE, 2x Falcon030 20GB/14MB, Stacy4, STBook, TT030/Nova/20MB/72GB, SMM804,SLM-804+605, 5xPofo

Offline mfro

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

Offline Mathias

  • Moderator
  • *****
  • Beiträge: 1.541
    • www.firebee.org
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.031
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 »

Offline Arthur

  • Benutzer
  • Beiträge: 6.800
  • Mein Atari erinnert mich an die gute alte Zeit..
    • Atari Wiki
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: 7.110
  • Da kringelt sich doch die Locke in der Glocke!
    • HomeCon - der Homecomputer-Treff in Rhein-Main - auch für ATARI
Da muss ich irgendwas missverstanden haben, naja.
Power without the Price. _/|\_ ATARI

Beware of D.A.U.

1040STFM Twer (PAK68/2,Ovrscn,4MB,1GB SCSI,DVD), 4x1040STFM, 520/1040STE, 520STFM, 260ST, 3x520ST/+, Mega ST1+2+4, 2x Mega STE, 2x Falcon030 20GB/14MB, Stacy4, STBook, TT030/Nova/20MB/72GB, SMM804,SLM-804+605, 5xPofo

Offline chris78

  • Benutzer
  • Beiträge: 372
  • Ich liebe dieses Forum!
    • iiot-factory
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.541
    • www.firebee.org

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.541
    • www.firebee.org
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.031
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.

Offline Nervengift

  • Benutzer
  • Beiträge: 1.259
    • Ein wenig was über mein anderes Hobby. :-)
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)