Firebee reloaded

[mfro]

Ich muß da glaube ich was Ergänzen. Laut meinen Informationen hat Torlus letztes Jahr die Quartus-Probleme gelöst, und es läuft grundsätzlich mit aktuellem Quartus und sauber eingerichteter Timeline usw. Soweit mir bekannt ist das auch getestet.

https://github.com/Torlus/firebee-fpga

Ich fürchte, da muß ich dich enttäuschen, Mathias. Torus hat im wesentlichen in Quartus die Timing-Überprüfung für die kritischen Pfade ausgeschaltet (die Probleme also nicht behoben, sondern einfach ignoriert). Die Synthese läuft so durch, beim Booten kommt (für manche, aber nicht alle Auflösungen) auch ein Bild, hat aber Pixelfehler (und Abstürze, zumindest wenn man das FPGA-RAM als ST-RAM benutzt). Das Ergebnis ist bestenfalls instabil, aber m.E. nichts, worauf sich aufbauen ließe.

Außerdem hat er den (sowieso schon etwas chaotischen) Code durch einen automatischen VHDL nach Verilog Konverter geschickt, so daß (ich zumindest) damit überhaupt nichts mehr anfangen kann.

Wolfgangs – sehr unterstützungswürdige – Idee ist halt, die ganze FireBee FPGA-Geschichte in wirklich sauberem VHDL vorzulegen, damit jeder Mensch dran weiterarbeiten kann. Und das dauert tatsächlich, …

Das ist meiner Ansicht nach der einzig richtige und auch einzig gangbare Weg, wieder an eine saubere FPGA-Konfiguration zu kommen.

[mfro]

Wichtig für die Firebee ist FAT16

Doofe Frage eines Unwissenden: Warum?

Weder FireTOS noch EmuTOS können nativ mit FAT32 umgehen.

Die FAT32-Unterstützung kommt von MiNT und das muß natürlich erstmal irgendwoher geladen werden. Die Firebee Bootpartition muß deswegen FAT16 sein.

[Lukas Frank]

Wichtig für die Firebee ist FAT16

Doofe Frage eines Unwissenden: Warum?

Die Frage sollten besser Mathias und mfro beantworten ...

Das Standard Dateisystem der Firebee ist kein Atari Partitionsschema sondern es wird MSDOS FAT16 benutzt, zum Booten mit gesetztem Bootflag. Die Grenze liegt auf der Firebee für FAT16 bei 2GB pro Partition. Es kann nur vom IDE, SCSI oder der CF Karte gebootet werden, nicht von der SD Karte. Die Firebee kann auch mit Atari partitionierten Volumes umgehen, habe aber noch nicht getestet ob die Firebee von einer BGM Partition auch booten kann ...

Der HDDriver müsste erstmal die Schnittstellen der Firebee unterstützen und dann noch FAT16.

FAT32 und ext2 ist MiNT only, MagiC kann noch FAT32 aber MagiC läuft nicht auf der Firebee, vermute ich mal ...

[1ST1]

FAT12 ist ein Dateisystem, was Partitionsgrößen von  maximal 16 MB erlaubt. Das ist das, was in TOS 1.0 integriert ist. Ab TOS 1.02 ("Blitter-TOS") wird bereits FAT16B unterstützt, denn nur so lassen sich Partitionen größer als 16 GB erzeugen. Das "B" steht übrigens für "BigDOS", einem Namen den man auch als Atarianer kennen sollte. Allerdings gibts zwischen TOS FAT16 und MS-DOS-FAT16B kleine Unterschiede, so dass man am Atari auch BIGDOS.PRG in den Autoordner werfen sollte, um vollständige Kompatiblität zu bekommen.

Siehe auch https://de.wikipedia.org/wiki/File_Allocation_Table

[Nervengift]

Die FAT32-Unterstützung kommt von MiNT und das muß natürlich erstmal irgendwoher geladen werden. Die Firebee Bootpartition muß deswegen FAT16 sein.

Gut zu wissen, wenn ich dann vielleicht demnächst meine Biene einrichten kann. Danke.

Es kann nur vom IDE, SCSI oder der CF Karte gebootet werden, nicht von der SD Karte.

Warum nicht eigentlich auch von der SD-Karte? Mit solch einer Beschränkung wirft man sich doch auch wieder unnötig Knüppel zwischen die Beine, finde ich. ... Ist SCSI denn schon implementiert? Ich dachte, der Anschluss sei noch tot?

Noch eine andere Frage: Im Firebee-Minigehäuse ist doch eine Halterung für eine SSD drin? Einen SATA <--> PATA (IDE)-Adpater muss man dann aber noch selbst nachrüsten bzw. eine entsprechende SSD kaufen, die zum Anschluss passt?

[mfro]

EmuTOS bootet übrigens prima von einer SD-Karte (wenn keine CompactFlash Karte drinsteckt, sonst landen die Partitionen der SD-Karte dahinter).

Eine SSD würde ich in die Firebee nicht reinstecken.

Overkill.

Das wird nicht (oder höchstens unwesentlich) schneller als eine CompactFlash Karte, der Durchsatz ist durch die Anbindung des IDE-Interfaces beschränkt (Falcon kompatibel, deswegen keine DMA-Modi möglich). Selbst wenn die (im FPGA) implementiert wären, ist der Durchsatz des FlexBus (33 MHz mit Adress-/Daten Multiplexing) die nächste Geschwindigkeitshürde.

[Lukas Frank]

Das mit den 2GB FAT16 stimmt nicht, habe mich vertan, irgendwie hängen die 2GB in meinem Kopf. Die Firebee bootet genau wie der Falcon von einer 1GB Partition ...

[1ST1]

Das mit dem 1 GB Bei FAT16 ist eine TOS-Limitierung, das Dateisystem wurde nicht ganz genau wie bei MS-DOS implementiert. Da waren die Tramiels bei den Bits etwas zu geizig oder so. An der Stelle scheint nichtmal BIGDOS auf kleinen STs, TT und Falcon zu helfen.

MS-DOS kann FAT16B Partitionen bis 2 GB adressieren, mit dem DOS von Windows 95B/98/ME gehen sogar 4 GB, das nennt sich dann FAT32, wobei das noch weitere Neuerungen (Lange Dateinamen usw.) enthält.

[Lukas Frank]

->   https://de.wikipedia.org/wiki/File_Allocation_Table

Meine 2GB scheint eine alte FAT16 Grenze zu sein und FAT32 reicht bis in der TB Bereich, dort gibt es nur eine Dateigrenze von 4GB meine ich, deshalb ist heutzutage auch exFAT die Wahl ...

[Nervengift]

Wie groß dürfen denn Partitionen unter MiNT sein, wenn man FAT32 und ext2 einsetzt?

Es wäre sogar eine Option ganz auf FAT32 zu verzichten und zusätzlich zur FAT16-Bootpartition zwei ext2-Partionen anzulegen. Die eine für den Unixkrams von easymint und die andere für die Anwendungsprogramme. Hätte den Vorteil, dass man in einer Multiuserumgebung auch Zugriffsrechte vergeben könnte für die Anwendungsprogramme, so dass diese nicht mehr so einfach von jeden gelöscht werden können. Da das aber alles über die Kommandozeile laufen muss, stelle ich mir das als jemand, der nicht unbedingt "Textadventures" begeistert ist, nicht so einfach vor.

Das mit der SSD war eine Überlegung, weil ich dann nicht einen zusätzlichen CF-Cardreader anschaffen müsste, um die CF-Karte am Hackintosh einzurichten. Der Preisunterschied zwischen den SSDs und CF-Karten ist auch nicht so gravierend als dass es aus der Perspektive keinen Sinn machte. Einzig und allein 32 GB als Massenspeicher in einem Atari (Clone) einzusetzen, ist für mich pure Verschwendung. Dass die Schnittstellen in der Biene nicht die volle Geschwindigkeit ausnutzen finde ich jetzt auch nicht so dramatisch, da alleine die niedrigen Zugriffszeiten schon einen enormen Geschwindigkeitszuwachs bringen im Vergleich zu herkömmlichen Festplatten. Aber letzten Endes ist das wohl alles gehupft wie gesprungen, das stimmt schon.

[Mathias]

Ich fürchte, da muß ich dich enttäuschen, Mathias.

Nein, damit enttäuscht Du mich nicht. Ich hab ja keine Aussage über die Qualität des Codes oder den Gesamtzustand des IP-Cores oder so getroffen. Ich wollte nur ergänzen, daß es grundsätzlich schon auch möglich ist, auch mit einer aktuellen Quartus-Version. Aber daß Wolfgangs Ansatz der einzige Zukunftsweisende ist, da sind wir uns einig

[Mathias]

Also woher die Idee kommt, daß man von der SD-Karte nciht booten kann, verstehe ich auch nicht. Natürlich geht das. Ich hab mir halt MiNT oder so nicht angetan weil mir das zuviel "Einrichterei" gewesen wäre, aber mit TOS geht das natürlich. Ist halt von der Geschwindigkeit ca. so wie wenn man den MegaSTE statt von der Platte von Floppy startet

Wie groß dürfen denn Partitionen unter MiNT sein, wenn man FAT32 und ext2 einsetzt?

Unter MiNT gibt es da keine echten Beschränkungen mehr. Ich hab ja die 2TB Platte an der Biene hängen manchmal. Das TOS kann das seit einiger Zeit auch für FAT32 bis 2TB.

zwei ext2-Partionen anzulegen.

Für mich ist diese "Dateisystem-Syncerei" und "Runterfahren müssen" der Atari-Feeling-Killer schlechthin. Ich will auch weiterhin meine Ataris einfach ausschalten können. Deshalb nutze ich auch nur FAT32.

Das mit der SSD war eine Überlegung,

Das ist ein enorm frustrierendes Kapitel, … ich habe insgesammt 5 SATA-IDE Adapter getestet, keiner hat anstandslos funktioniert (aber auch am Mac oft nicht). Es scheint auch Probleme bei der länge der IDE-Kabel auf der Biene zu geben. Je kürzer desto sicherer. Ich würde also derzeit Allen ein max. 10cm-Kabel und direktes IDE-Interface empfehlen. Kommt auch ungefähr aufs Selbe raus, besonders wenn man bedenkt daß es ja im MiNT keine TRIM support usw. gibt, und man eigentlich einen Controller nehmen müßte der das nicht braucht. Es gibt aber etliche Leute, die auch große IDE-Platten problemlos in der FireBee betreiben.

[Nervengift]

Das ist ein enorm frustrierendes Kapitel, … ich habe insgesammt 5 SATA-IDE Adapter getestet, keiner hat anstandslos funktioniert (aber auch am Mac oft nicht).

In meinen alten PowerMac G4 MDD FW800, den mein Onkel noch als Bürorechner nutzt, hatte ich letztes Jahr eine intel SSD eingebaut und diesen Adapter dafür verwendet:

http://www.amazon.de/MANHATTAN-158282-SATA-Drive-Konverter/dp/B002LBVUFK/ref=sr_1_63?ie=UTF8&qid=1405264059&sr=8-63&keywords=sata+auf+ide#productDetails

Der funktioniert echt super ohne jegliche Probleme und läuft auch mit voller Geschwindigkeit der ATA100-Schnittstelle.

Deshalb nutze ich auch nur FAT32.

Wenn man auf sowas wie Multiuser und Rechtverwaltung etc. verzichten kann und möchte, ist das sicherlich auch ein Weg. Aber ich finde diese ganzen Minttüfteleien auch sehr interessant.

Kommt auch ungefähr aufs Selbe raus, besonders wenn man bedenkt daß es ja im MiNT keine TRIM support usw. gibt, und man eigentlich einen Controller nehmen müßte der das nicht braucht.

Ach. TRIM wird überbewertet und bei einer SSD mit einer einigermaßen vernünftigen Garbage Collection sollte das an einer Biene nicht weiter auffallen. ... Aber gut zu wissen mit den Anschlusskabeln. Eine CF-Karte dürfte dann wohl erstmal doch die beste Wahl sein.

[mfro]

Für mich ist diese "Dateisystem-Syncerei" und "Runterfahren müssen" der Atari-Feeling-Killer schlechthin. Ich will auch weiterhin meine Ataris einfach ausschalten können. Deshalb nutze ich auch nur FAT32.

MiNT nutzt für die FAT32-Dateisysteme dasselbe (unified-) Cache System wie für ext2 Dateisysteme.

Daß man bei FAT32 auf die "Dateisystem-Syncerei" verzichten könnte, ist deshalb (leider) falsch.

Du machst früher oder später dein Dateisystem genauso kaputt, wenn Du einfach ausschaltest. Nur merkst Du's eben nicht (oder erst viel zu spät), weil FAT so was wie ein "dirty flag" nicht kennt.

Das "einfach ausschalten" würde funktionieren, wenn Du in der MINT.CNF "OLDTOSFS" angeben würdest - dann nutzt MiNT die normalen GEMDOS Schreibroutinen, wird aber schnarchlangsam.

Wenn ich mich recht erinnere, läuft dieser MiNT-Teil aber nicht mit FireTOS zusammen (irgendwas ist nicht so ganz Coldfire-kompatibel und es fehlen an jedem gelesenen Puffer ein paar Bytes am Ende).

Fazit: "einfach ausschalten" mit der Firebee + MiNT ist nicht. Kann man natürlicht trotzdem machen, man riskiert aber seine Daten. Würde ich nicht weiterempfehlen.

[Mathias]

MiNT nutzt für die FAT32-Dateisysteme dasselbe (unified-) Cache System wie für ext2 Dateisysteme.
Daß man bei FAT32 auf die "Dateisystem-Syncerei" verzichten könnte, ist deshalb (leider) falsch.

Das war mir tatsächlich neu! Eine Tragödie für mich persönlich, … Zum Glück geht wenigstens "Runterfahren" aus MiNT schon rein per Software.

Würde ich nicht weiterempfehlen.

Wird ab sofort so erledigt.