atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: czietz am Mo 01.10.2018, 21:48:04
-
@czietz, @Thorsten Otto ... habe mir mal das EmuTOS Makefile angesehen. Kann man in der 192kB Version nicht die console EmuCON weglassen und dafür IDE Support?
Klar kannst Du das, indem Du EmuTOS selbst compilierst. Siehe unten. In der "offiziellen" 192k-Version ist die EmuCON imho viel mehr wert als IDE-Unterstützung. Es gibt keinen Atari-Rechner, der 192k-ROMs verwendet (also ST) und von Haus aus IDE kann. EmuCON ist für alle ST-Nutzer sinnvoll, IDE im ST nur für die Minderheit, die sowas nachgerüstet hat, aber keinen TOS-2.06-Support (also für 256k ROMs) nachgerüstet hat.
Und vielleicht noch FAT16 PC support?
Hm? Der ist doch drin, selbst in der 192k-Version. Was meinst Du genau?
-
Meine Anforderung an EmuTOS ist ja ein Sonderfall.
Ich verstehe das Makefile nicht wirklich.
Ich installiere mir mal den GCC auf dem Atari TT unter MiNT und frage dann nochmal was ich wie im Makefile ändern muss.
-
EmuTOS selbst compilieren, eine extrem knappe Anleitung:
- Crosscompiler (gcc) von Vincent installieren: http://vincent.riviere.free.fr/soft/m68k-atari-mint/. (Ich rate davon ab, es mit gcc direkt auf dem Atari zu probieren; Crosscompiler für Windows, Linux, MacOSX verwenden.)
- EmuTOS-Sourcen herunterladen. Wer sich kein git antun möchte, Github hat auch eine Download-Möglichkeit als ZIP: https://github.com/emutos/emutos ("Clone or download").
- Nach Herzenslust include/config.h anpassen -- optional(!), um gegenüber dem offiziellen Release Funktionen zu entfernen oder hinzuzufügen.
- "make 192" auf der Kommandozeile eingeben und ein 192k ROM bekommen. Oder "make 256", oder "make 512" oder "make prg", ...
-
Crosscompiler (gcc) von Vincent installieren: http://vincent.riviere.free.fr/soft/m68k-atari-mint/. (Ich rate davon ab, es mit gcc direkt auf dem Atari zu probieren; Crosscompiler für Windows, Linux, MacOSX verwenden.)
Xcode kann ich nicht unter macOS. Ist mir alles viel zu kompliziert. Ich versuche es mal mit GCC auf dem Atari oder gar nicht.
-
Hä? Du musst mit MacOSX doch kein XCode verwenden, bloß um Vincents Compiler zu installieren! Auf dem TT wirst Du viel, viel, viel mehr Probleme haben, gcc zum Laufen zu bekommen als unter MacOSX.
-
Crosscompiler (gcc) von Vincent installieren: http://vincent.riviere.free.fr/soft/m68k-atari-mint/. (Ich rate davon ab, es mit gcc direkt auf dem Atari zu probieren; Crosscompiler für Windows, Linux, MacOSX verwenden.)
Xcode kann ich nicht unter macOS. Ist mir alles viel zu kompliziert. Ich versuche es mal mit GCC auf dem Atari oder gar nicht.
Das kannst Du dir sparen, das klappt nicht.
Einen Mac OS X m68k-atari-mint-gcc Crosscompiler (nicht ganz aktuell, aber sollte für EmuTOS funktionieren) findest Du hier: https://donzé.ch/atari/articles/cross-compiler/
-
(76 Bytes fehlen für DE-EmuTOS 192KB mit IDE)
Das ist ja so wenig, was da fehlt, kann man da nicht ein paar Strings in Fehlermeldungen abkürzen und dann paßt’s?
-
(76 Bytes fehlen für DE-EmuTOS 192KB mit IDE)
Das ist ja so wenig, was da fehlt, kann man da nicht ein paar Strings in Fehlermeldungen abkürzen und dann paßt’s?
Könnte man den 192KB Build nicht als ZIP im ROM ablegen, was vermutlich 50% Platz sparen täte. Beim booten würde man das ROM zunächst ins RAM expandieren. Selbst wenn der UnZipper 20k unkomprimiert im ROM benötigt, hätte man dann immer noch zusätzliche150K (76K compressed) für Erweiterungen des ursprünglichen TOS. Einziger Nachteil wäre eine längere Boot-Zeit und vermindertes RAM zur Laufzeit.
Vermutlich bin ich nicht der Erste, der diese Idee hat? :D – Sorry, war 20 Jahre abwesend in der Szene.
-
(76 Bytes fehlen für DE-EmuTOS 192KB mit IDE)
Das ist ja so wenig, was da fehlt, kann man da nicht ein paar Strings in Fehlermeldungen abkürzen und dann paßt’s?
Könnte man den 192KB Build nicht als ZIP im ROM ablegen, was vermutlich 50% Platz sparen täte. Beim booten würde man das ROM zunächst ins RAM expandieren. Selbst wenn der UnZipper 20k unkomprimiert im ROM benötigt, hätte man dann immer noch zusätzliche150K (76K compressed) für Erweiterungen des ursprünglichen TOS. Einziger Nachteil wäre eine längere Boot-Zeit und vermindertes RAM zur Laufzeit.
Klar, kann man machen – aber wozu dann noch das ROM, letztlich … da würde ein kleiner Bootloader dann reichen, der den Rest von Platte bootet. Braucht genauso viel RAM wie die obige Methode, ist aber flexibler. Der Spaß am ROM in alten Kisten ist ja, dass sie eben 200-300 KB RAM sparen. In einer 2-4 MB Konfiguration nicht unerheblich.
-
[Einen Mac OS X m68k-atari-mint-gcc Crosscompiler (nicht ganz aktuell, aber sollte für EmuTOS funktionieren) findest Du hier: https://donzé.ch/atari/articles/cross-compiler/
Und einen aktuellen hier (http://tho-otto.de/crossmint.php). Dort sind sowohl ein aktueller (8.2) als auch 4.6.4 (die Version die wohl z.Z. normalerweise benutzt wird). 8.2 ist auch als komplett-Paket vorhanden (binutils, gcc und libraries), für 4.6.4 musste du die einzelnen Archive installieren (für EmuTOS sollte aber mintlib reichen). Bei meinen letzten tests hat 8.2 etwas kleinere binaries erzeugt als 4.6.4, müsste reichen um IDE einkompilieren zu können.
Xcode brauchst du dafür nicht (für EmuTOS sowieso sinnlos weil gar keine Projekt-Dateien dafür vorhanden sind).
EmuCON ist in den 192k-Versionen sowieso nicht drin, das musst du also nicht rauskonfigurieren.
Am einfachsten in deinem Fall ist: lege eine Datei localconf.h im Hauptverzeichnis an. Dort kannst du alle Einstellungen reinschreiben, die du gegenüber den Voreinstellungen überschreiben willst. In dem deinem Fall wäre das:
#define CONF_WITH_IDE 1
Wenn du noch mehr änderen willst, hilft wohl nur ein Blick in include/config.h. Es sind allerdings 'ne menge Einstellungen, die alle hier zu erläutern dürfte ein bisschen weit führen. In der Regel sollte aber ein Kommentar dabei stehen. Wichtig zu wissen ist nur, daß es einen Satz von "Grundeinstellungen" für jede Haupt-Version (192, 256k, etc) gibt.
Dann einfach im Hauptverzeichnis
$ make clean
$ make 192 COUNTRY=de
eingeben.
Wie gesagt, mit gcc 4.6.4 reicht es für die deutsche Version ganz knapp nicht. US sollte aber gehen wenn du damit leben kannst. Oder du hast Glück mit der neuen Compiler-Version. Übersetzen lässt es sich jedenfalls (464 Bytes frei, gerade ausprobiert), allerdings hat noch kaum jemand das Resultat auch getestet obs funktioniert.
Edit: deutsche und us-Version angehängt. Da es keine "offizielle" Version ist, keine Garantie ;) und auch nicht unbedingt zur Weitergabe empfohlen.
Edit: Anhang wieder gelöscht, da offensichtlich fehlerhaft. Siehe https://forum.atari-home.de/index.php/topic,14728.msg233193.html#msg233193
-
Das ist ja so wenig, was da fehlt, kann man da nicht ein paar Strings in Fehlermeldungen abkürzen und dann paßt’s?
Könnte man theoretisch. Das Problem ist nur daß man dann absolut keinen Freiraum mehr für Fixes hat. Das letzte mal als ich eine Version mit IDE hier bereit gestellt habe, waren noch ca. 20 Bytes anschliessend frei. Ausserdem würde das nicht für alle Sprachen funktionieren, in der griechischen Version sind 2 Tastaturtabellen enthalten, die braucht also etwas mehr Platz.
Ganz abgesehen davon ist 192k mit IDE eine Konfiguration die es so eigentlich nicht gibt, und nur von einigen Freaks benutzt werden könnte ;)
-
... Xcode brauchst du dafür nicht (für EmuTOS sowieso sinnlos weil gar keine Projekt-Dateien dafür vorhanden sind)...
Xcode braucht man nicht, aber es muss installiert sein (und die Lizenz-Einverständniserklärung beantwortet sein), damit man make und Konsorten benutzen kann.
Die Einverständniserklärung kommt beim ersten make-Aufruf.
-
Xcode braucht man nicht, aber es muss installiert sein (und die Lizenz-Einverständniserklärung beantwortet sein), damit man make und Konsorten benutzen kann.
Die Einverständniserklärung kommt beim ersten make-Aufruf.
Oh, wow, Apple überrascht doch immer wieder -- negativ. Welchen Lizenzbedingungen unterliegt nach Apples Meinung denn die Nutzung von GNU(!) oder BSD make?
(Man stelle sich die Reaktion der Leute vor, würde Microsoft so etwas versuchen: "Sie müssen erst Visual Studio installieren und dessen Lizenzbedigungen abnicken, bevor wir die Nutzung von Open-Source-Tools freischalten." Aber bei Apple ist das Vorgehen akzeptiert?)
-
Xcode braucht man nicht, aber es muss installiert sein (und die Lizenz-Einverständniserklärung beantwortet sein), damit man make und Konsorten benutzen kann.
Die Einverständniserklärung kommt beim ersten make-Aufruf.
Oh, wow, Apple überrascht doch immer wieder -- negativ. Welchen Lizenzbedingungen unterliegt nach Apples Meinung denn die Nutzung von GNU(!) oder BSD make?
(Man stelle sich die Reaktion der Leute vor, würde Microsoft so etwas versuchen: "Sie müssen erst Visual Studio installieren und dessen Lizenzbedigungen abnicken, bevor wir die Nutzung von Open-Source-Tools freischalten." Aber bei Apple ist das Vorgehen akzeptiert?)
Was man dort bestätigt, ist nicht die make - sondern die MacOS SDK-Lizenz. Dummerweise starten die Cmdline-Tools (git, make, etc, ...) aber erst, sobald die akzeptiert ist.
Ob so ein "Bundling" rechtens ist oder nicht, darüber gibt es ausführliche Diskussionen in einschlägigen Foren. Ich gehe davon aus, es ist. Apple beschäftigt so viele gut bezahlte Anwälte, daß die garantiert eine fein zieselierte, wohldurchdachte Antwort darauf parat haben, warum das genauso sein muss.
Für mich jedenfalls ein Grund (mehr), mir keinen weiteren angebissenen Apfel zuzulegen.
-
Ich vermute der Cross-Compiler läuft nicht unter macOS Mojave 10.14. Ich will da nichts kaputt machen.
Ich hatte mir damals einen Atari gekauft und später Apple Computer weil man da als reiner Anwender mit ein paar Maus klicks immer aus kommt.
-
Doch mal Installiert und läuft nicht ...
make[1]: m68k-atari-mint-gcc: No such file or directory
make[1]: *** [obj/startup.o] Error 1
make: *** [192] Error 2
Franks-MacMini:emutos-master frank$
-> https://donzé.ch/atari/articles/cross-compiler/
... habe die neuste 2014 Version genommen und laut Beschreibung installiert.
-
Xcode braucht man nicht, aber es muss installiert sein (und die Lizenz-Einverständniserklärung beantwortet sein), damit man make und Konsorten benutzen kann.
Habs noch nicht ausprobiert, aber man könnte vermutlich auch macports oder Homebrew nehmen, wenn man Xcode partout nicht installieren will.
Ich vermute der Cross-Compiler läuft nicht unter macOS Mojave 10.14. Ich will da nichts kaputt machen.
Also kaputt machen kannst du da eigentlch nix, ist ja kein kernel-modul oder sowas ;) Und installiert sich auch unter /opt/cross-mint, überschreibt also garantiert keine anderen Dateien. Ich seh auch keinen Grund warum der nicht auf Mojave laufen sollte, ist eine reine 64bit Version.
make[1]: m68k-atari-mint-gcc: No such file or directory
Wie gesagt, der installiert sich unter /opt/cross-mint. Du musst also /opt/cross-mint/bin auf dem Pfad haben
habe die neuste 2014 Version genommen
... und wie gesagt, es gibt auch deutlich neuere Versionen ;) Auch schon mal die fertig übersetzten EmuTOS Versionen ausprobiert, die ich oben angehängt habe?
-
Du musst den Pfad zum GCC erst noch exportieren.... dann geht das kompilieren auch, steht aber glaube in der Anleitung mit drin.
-
Alles richtig unter /opt installiert/kopiert.
-------
After installation, you should create/modify your bash profile by enhancing ~/.profile with the following lines:
# m68k-atari-mint cross compiler
export PATH=$PATH:/opt/cross-mint/bin
export MANPATH=$MANPATH:/opt/cross-mint/share/man
This allows you to use the cross-compiler using m68k-atari-mint-gcc (or any other tool of it) and query its man pages.
-------
Die beiden export Befehle ausgeführt.
-
Habe mal neu gebootet ...
-------
Franks-MacMini:emutos-master frank$ make 192 COUNTRY=de
/bin/sh: m68k-atari-mint-gcc: command not found
/Applications/Xcode.app/Contents/Developer/usr/bin/make DEF='-DTARGET_192' OPTFLAGS=-Os WITH_CLI=0 UNIQUE=de ROM_192=etos192de.img etos192de.img
/bin/sh: m68k-atari-mint-gcc: command not found
m68k-atari-mint-gcc -m68000 -mshort -Os -fomit-frame-pointer -fno-common -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Iinclude -DWITH_AES=1 -DWITH_CLI=0 -DTARGET_192 -c bios/startup.S -o obj/startup.o
make[1]: m68k-atari-mint-gcc: No such file or directory
make[1]: *** [obj/startup.o] Error 1
make: *** [192] Error 2
-
Alles richtig unter /opt installiert/kopiert.
Das ist gcc 4.6.4, vermutlich wirst du damit keine deutsche Version bauen können. Ich würde dir empfehlen mal http://tho-otto.de/download/mint/m68k-atari-mint-base-20180831-macos.tar.xz zu versuchen. Die Anleitung von Philipp darfst du aber zu Rate ziehen ;)
-
Habe mal neu gebootet ...
Die exports sind nach booten wieder weg. Dafür müsstest du dir in die Datei $HOME/.profile schreiben
-
.profile gibt es schon. Wie kann ich die Datei öffnen? Das System läßt mich nicht ...
Scheint jetzt zu gehen ...
-------
# Padding emutos.img to 192 KB image into etos192de.img
./mkrom: emutos.img is too big: 124 extra bytes
make[1]: *** [etos192de.img] Error 1
make: *** [192] Error 2
Was muss ich in der config.h eintragen damit es nicht zu lang wird?
Unter /opt sieht es jetzt so aus ...
-
Was muss ich in der config.h eintragen damit es nicht zu lang wird?
Schwierig. Das 192k ROM ist schon ziemlich ausgereizt. Du könntest CONF_WITH_ACSI auf 0 setzen wenn du statt IDE darauf verzichten kannst. Und wie gesagt, am einfachsten ist es, eine Datei localconf.h anzulegen statt include/config.h zu ändern, dann weisst du wenigstens was du geändert hast.
Oder du nimmst halt gcc 8.2, oder die images die ich dir oben bereit gestellt habe ;)
-
Es geht mir ja darum das User meines IDE Interfaces ohne eigenes TOS sich selber anhand einer Schritt für Schritt Anleitung selbst eine EmuTOS 192kB Version für IDE zu erstellen.
ACSI muss auf jeden Fall bleiben. In der config.h ist ja bei der 192kB Version fast alles auf 0. Wo könnte man denn noch etwas wegnehmen?
Ich selber brauche es nicht, das IDE Interface nutze ich zusammen mit einer PAK/FRAK mit TOS 3.06. Dort kann ich das IDE Interface so nutzen.
-
ACSI muss auf jeden Fall bleiben. In der config.h ist ja bei der 192kB Version fast alles auf 0. Wo könnte man denn noch etwas wegnehmen?
Das ist halt das Problem, da bleibt eigentlich nichts. EmuTOS komprimiert ins ROM zu packen ist wohl auch keine Lösung, zum einen wurden die Routinen dafür (die schon mal vorhanden waren) vor nicht allzu langer Zeit entfernt, weil sie nie benutzt wurden und dementsprechend seit langer Zeit nicht getestest wurden, Zum anderen benötigt das natürlich Speicher, der auf den Maschinen für die das 192k TOS vorgesehen ist auch nicht gerade üppig sein dürfte.
Bleibt wohl nur gcc 8.2 zu nehmen.
-
Und wie komme ich unter macOS an den gcc 8.2?
Und wie binde ich den gcc 8.2 in das cross-compiler Paket unter /opt ein?
Bei 124bytes zu lang kann man da nicht Dialoge kürzen oder ganz wegnehmen wie das TOS Info. Ob das 124bytes bringt, keine Ahnung.
-
Warum muß denn das TOS partout in 192k hinein? Früher gab es mal Adapter für TOS_2.06, also für größeres TOS - gibt´s jetzt keine mehr? Nirgends?
-
Und wie komme ich unter macOS an den gcc 8.2?
Hab ich doch oben schon mehrfach verlinkt: http://tho-otto.de/crossmint.php (http://tho-otto.de/crossmint.php)
Und wie binde ich den gcc 8.2 in das cross-compiler Paket unter /opt ein?
Fast genauso wie das Archiv von Philipp:
tar xvf m68k-atari-mint-base-20180831-macos.tar.xz --directory /
(der Pfadname /opt ist schon im Archiv enthalten)
Bei 124bytes zu lang kann man da nicht Dialoge kürzen oder ganz wegnehmen wie das TOS
Info
Ganz wegnehmen ist schlecht, dazu müsste man auch den code ändern damit der nicht versucht das trotzdem anzuzeigen. Evtl könnte man die Bildchen entfernen, ob das reicht weiss ich aber nicht. Ausserdem würde es deine Aleitung, wie man so ein TOS erzeugt, nicht unbedingt einfacher machen.
-
Vielen Dank für deine Hilfe aber für mich ist das alles nichts, viel zu kompliziert für meine arme Seele.
-
viel zu kompliziert für meine arme Seele.
Aber du hattest es doch schon fast, hättest nur 'nen anderen Compiler nehmen sollen ;)
Ansonsten, falls jemand so ein TOS braucht, einfach Bescheid sagen.
-
Nichts für mich.
-
Und leider auch nichts für mich (habe keinen Apple).
-------
Ansonsten, falls jemand so ein TOS braucht, einfach Bescheid sagen.
Solange die Icon-Resource proprietär ist (ie. inkompatibel zum orig. M~TOS) kann ich niemandem guten Gewissens zu EmuTOS raten. Wenn Ihr das endlich bereinigt, dann könnte ich ja mal EmuTOS nachladen und testen.
-
Ansonsten, falls jemand so ein TOS braucht, einfach Bescheid sagen.
Solange die Icon-Resource proprietär ist (ie. inkompatibel zum orig. M~TOS) kann ich niemandem guten Gewissens zu EmuTOS raten. Wenn Ihr das endlich bereinigt, dann könnte ich ja mal EmuTOS nachladen und testen.
Da macht Thorsten ein nettes Angebot, und du fängst wieder mit den ollen Kamellen an, das wurde doch schon mehrfach durchgekaut. Du hast ein Anwendungsszenario, das sicher nicht jeder hat, daher ist dein „kann ich niemandem guten Gewissens zu EmuTOS raten“ sehr harsch. Es ist ja nicht so, dass es Daten schrotten würde. Es lädt nur Iconsets nicht wie von dir gewünscht. Das mag ein Ärgernis für dich sein, aber doch kein genereller pauschaler Abrategrund …
-
Solange die Icon-Resource proprietär ist (ie. inkompatibel zum orig. M~TOS) kann ich niemandem guten
Och neee, geht das schon wieder los? Rätst du auch allen von MagiC/Jinnee ab, weil die Icon-Datei nicht zu MTOS kompatibel ist?
-
Warum muß denn das TOS partout in 192k hinein? Früher gab es mal Adapter für TOS_2.06, also für größeres TOS - gibt´s jetzt keine mehr? Nirgends?
Ulrich Skulimma hat eine Anleitung veröffentlicht: http://www.skulimma.de/206imst.html
Ich find's cool, dass EmuTOS fast ein komplettes TOS 2.0x in 192KB packt. Denjenigen, die 256 oder 512KB ROMs verwenden, wird auch nichts weggenommen.
EmuTOS selbst kompilieren wäre auch mal ein netter Artikel für die STC ;)
-
^^-- Gute Idee!
Und danke für den Link!
Och neee, geht das schon wieder los? Rätst du auch allen von MagiC/Jinnee ab, weil die Icon-Datei nicht zu MTOS kompatibel ist?
Du irrst. Ich verwende für MTOS, MagxDesk, Thing, Jinnee & TeraDesk grundsätzlich dieselbe Icon-Datei (& sogar für Gemini könnte man sie verwenden).
<OT on>
Unterschiedlich sind leider die diversen Konfig.-Dateien dieser DeskTöppe (und das ist schon schlimm genug!). Ausnahmen sind die Ease und vielleicht noch NoDesk oder NeoDesk (um die habe ich mich wenig gekümmert). Mein Rat: Macht es so wie Thing und Jinnee! Die vermeiden die 64k 256-Icons-Falle (des TOS) und bleiben dennoch kompatibel. Da die Quellen von Thing ja jetzt offen sind, wäre der ohnehin der angesagte Desktop, den es zu debuggen und fort zu entwickeln gilt - und nicht ein weiterer rudimentärer & proprietärer Desktop.
-------
Da macht Thorsten ein nettes Angebot, und du fängst wieder mit den ollen Kamellen an, das wurde doch schon mehrfach durchgekaut. Du hast ein Anwendungsszenario, das sicher nicht jeder hat, daher ist dein „kann ich niemandem guten Gewissens zu EmuTOS raten“ sehr harsch. Es ist ja nicht so, dass es Daten schrotten würde. Es lädt nur Iconsets nicht wie von dir gewünscht. Das mag ein Ärgernis für dich sein, aber doch kein genereller pauschaler Abrategrund …
Der Grund zum Abraten, @gh-baden , ist keineswegs (m)ein privates Szenario, sondern die proprietäre Falle für einen jeden Anwender, die da ganz ohne sachlichen Grund offensichtlich aufgestellt wurde. Solch ein Verhalten kennen wir aus der (Software- und anderer) Industrie seit einem Jahrhundert zur Genüge (bekanntestes Bsp.: Kodak, die billig FotoApparate unter´s Folk brachten, um dann mit ihren Filmen um so besseren Reibach zu machen). Fürchtet die Danaer gerade dann, wenn sie Geschenke machen! Soweit zum ´netten Angebot´.
Im Übrigen geht es erst in zweiter Linie darum, wie die Icon-Resource _geladen_ wird (ideal wäre sicherlich, wenn die Konfig.-Datei von Thing passen tät), sondern zunächst um diese selbst: Entia non sunt multiplicanda präter necessitatem (Occam´s razor). Das ist leider, leider keine olle Kamelle, sondern immer noch aktuell - weil trotz aller Kritik nicht behoben. Vielleicht muß das ja noch ein paar Mal durchgekaut werden, bis es verdaut wird:
Ein neues Gewand für EmuTOS #27 ff.
https://forum.atari-home.de/index.php/topic,13724.msg222906.html#msg222906
<OT off>
-
Das ist leider, leider keine olle Kamelle, sondern immer noch aktuell - weil trotz aller Kritik nicht behoben.
Liegt vlt auch daran, daß du es trotz aller deiner Lamentiererei immer noch nicht geschafft hast, konkrete Vorschläge zu machen, was mit den Usern geschehen soll die sich schon eine Icon-Datei für EmuTOS gebastelt haben und dann im Regen stehen würden. Ganz abgesehen davon daß du immer nur in diesem Forum anfängst, in der ML habe ich noch nichts dazu gelesen. Ergo liest es von den Leuten, die das zu entscheiden haben sowieso keiner.
-
Ich find's cool, dass EmuTOS fast ein komplettes TOS 2.0x in 192KB packt.
Kann man so eigentlich nicht sagen ;) Nur weil es aus den gleichen Sourcen kompiliert wird, heisst nicht daß alle Funktionen auch in der 192k Version zur Vefügung stehen. Auch der Desktop ist dann gegenüber 2.06 leicht abgespeckt z.B.
-
Der Grund zum Abraten, @gh-baden , ist keineswegs (m)ein privates Szenario, sondern die proprietäre Falle für einen jeden Anwender, die da ganz ohne sachlichen Grund offensichtlich aufgestellt wurde. Solch ein Verhalten kennen wir aus der (Software- und anderer) Industrie seit einem Jahrhundert zur Genüge (bekanntestes Bsp.: Kodak, die billig FotoApparate unter´s Folk brachten, um dann mit ihren Filmen um so besseren Reibach zu machen). Fürchtet die Danaer gerade dann, wenn sie Geschenke machen! Soweit zum ´netten Angebot´.
Du vergleichst OpenSource-Software, die du als Anwender a) beliebig selbst modifizieren und dann wieder verbreiten darfst, b) die kostenlos dir erbracht wird, echt jetzt mit Vendor-Lock-In-Fallen von Konzernen, die „Reibach“ machen? Und Thorstens Offerte, jedem hier ein maßgeschneidertes EmuTOS zu compilieren als nettes Angebot in Anführungszeichen?
Gut, da fällt mir dann auch nichts mehr als Erwiderung ein. Außer vielleicht andere Feindbilder suchen.
-
Ich verusche mich da auch mal mit dem cross-complieren, Nur will es auch nicht so, wobei das jetzt wohl ehr ein grundsätzliches Problem ist und nichts mit EmuTOS.
$ make 192 COUNTRY=de
make DEF='-DTARGET_192' OPTFLAGS=-Os WITH_CLI=0 UNIQUE=de ROM_192=etos192de.img etos192de.img
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/bug.c -o bug
make[1]: gcc: Befehl nicht gefunden
m68k-atari-mint-gcc -m68000 -mshort -Os -fomit-frame-pointer -fno-common -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -Iinclude -DWITH_AES=1 -DWITH_CLI=0 -DTARGET_192 -c bios/startup.S -o obj/startup.o
bios/startup.S:13:20: fatal error: header.h: No such file or directory
compilation terminated.
make[1]: *** [Makefile:1032: obj/startup.o] Fehler 1
make: *** [Makefile:456: 192] Fehler 2
Ich vermute mal das da mit meiner Installation was noch nicht ganz stimmt. Nutze Windws 7 und Cygwin 32. Bei der Installation habe einfach alles durchgewunken. Dabei ist mir dann auf gefallen, dass nicht mal make installiert wurde. Also zusammen mit der libmpc3 installiert.
Danach von Vincent cross-mint-cygwin-20180704-setup.exe installiert. Das Setup merkte dann an das libmpfr4 fehlt. Auch diese dann alles nachgeholt.
Wenn ich make im Hauptverzeichnis ausführe, dann kommt die obigen Fehler. Den ersten kapier ich nicht. Beim zweiten verstehe ich das die Datei header.h fehlt. Wenn ich es richtig verstanden habe wird diese erst zulaufzeit des Makefiles durch awk erzeugt. Der ist zumindest in "C:\cygwin\bin" enthalten.
In der ".bash_profile" steht:
# Automatically added by the cross-mint setup program
export PATH="$PATH:/opt/cross-mint/bin"
export MANPATH="$MANPATH:/opt/cross-mint/share/man"
Irgendeine Idee?
Könnte man eine Auflistung machen welche Pakete alle installiert sein müssen?
-
Beim übersetzen von EmuTOS werden einige Dateien generiert. Dafür benötigst du beim cross-compilieren nicht nur den m68k-atari-mint-gcc cross-compiler, sondern auch den "nativen" compiler für dein System. Da rührt die erste Fehlermeldung her, die andere ist nur eine Folge davon, weil die Datei nicht erzeugt wurde.
Einfache Abhilfe: über Setup.exe von cygwin einfach das compiler-paket installieren.
Könnte man eine Auflistung machen welche Pakete alle installiert sein müssen?
Ohne Garantie, aber bei Aranym werden folgende Pakete installiert:
/cygdrive/c/cygwin/setup-x86.exe -q -P gettext-devel,libjpeg-devel,libjpeg8,cmake,flex,gmp-devel,libfontconfig-common,libfontconfig1,libfreetype6,libiconv-devel,libmpfr-devel,libncurses-devel,libpcre-devel,libpng-devel,libpng16,libpng16-devel,libusb1.0,libusb1.0-devel,mingw64-i686-SDL,mingw64-i686-SDL2,mingw64-i686-SDL_image,mingw64-i686-SDL2_image,mpfr,zip,unzip
Dürfte bei EmuTOS in etwa gleich aussehen. Ansonsten müsste ich mal bei appveyor nachschauen, welche Pakete auf deren image schon installiert sind.
-
... OpenSource ... Anführungszeichen ... andere Feindbilder ...
Ich habe keine ´Feindbilder´, sondern bin als in der Wolle gefärbter Naturwissenschaftler ganz trocken sachorientiert. Und Anführungszeichen verwende ich mitunter, um Begriffe ausdrücklich als nicht von mir stammend kenntlich zu machen; es ist böswillig, da Ironie zu unterstellen.
Was ist das Opensource-Versprechen wert, wenn sogar gestandenen Experten wie FL oder KM es schwerfällt, das wirklich umzusetzen?! Vielleicht schafft es ja MJaap in der STC uns zu erklären, wie man EmuTOS ganz einfach selbst compiliert. Ich selber kenne mich auf dem Atari mit der Programmierung in Modula sehr gut aus - aber schon ein C-CrossCompiler unter Windows ist für mich ein Buch mit sieben Siegeln.
-
Wenn man etwas haben möchte, was *nicht* von der Stange ist, bleiben nur zwei Möglichkeiten:
- machen lassen, von jemand der's kann (Maßanzug). Paßt, sitzt, aber kostet
- selber machen (Heimwerken). Erfordert die Bereitschaft, etwas dazuzulernen und ein wenig (Eigen-) Blut, -Schweiß und -Tränen zu investieren. Kostet aber - darüber hinaus - nix
Es wäre natürlich schön, wenn's den Maßanzug auch für umsonst gäbe ("eat the cake and have it" - s. Brexit). So funktioniert die Welt aber nicht.
-
Wenn man etwas haben möchte, was *nicht* von der Stange ist, bleiben nur zwei Möglichkeiten:
- machen lassen, von jemand der's kann (Maßanzug). Paßt, sitzt, aber kostet
- selber machen (Heimwerken). Erfordert die Bereitschaft, etwas dazuzulernen und ein wenig (Eigen-) Blut, -Schweiß und -Tränen zu investieren. Kostet aber - darüber hinaus - nix
Richtig! Und man sollte bei zweiter Option nicht unterstellen, dass das Lockangebote auf schlimmstem Kommerz-Ramsch-Niveau seien.
-
Man sollte auf sachliche Kritik nicht mit Polemik antworten - sonst kommt ebensolche zurück.
Mir scheint: Der Kaiser ist nackt.
-
Habe mir mal unter MiNT auf dem Atari TT den gcc 7.3.0 installiert.
-> https://github.com/freemint/m68k-atari-mint-gcc/releases/tag/gcc-7_3_0-mint
bunzip2 dauerte eine Stunde und tar nochmal eine halbe Stunde zum entpacken und installieren.
Ein "make 192 COUNTRY=de" läuft jetzt seit vier Stunden. Auf einem i5 MacMini dauerte es komplett nichtmal eine Minute.
Ich habe es auf dem Atari TT jetzt abgebrochen da ich den Rechner nicht über NAcht laufen lassen möchte. Der Compiler war bei deskapp.c ...
Was meint ihr wie lange der rechner braucht? 24 Stunden oder mehr?
-
-> https://donzé.ch/atari/articles/cross-compiler/
das zu installieren klappte gut und war einfach. Aber das OSX GCC 8 Paket lies sich nicht einfach installieren.
-
Man sollte auf sachliche Kritik nicht mit Polemik antworten - sonst kommt ebensolche zurück.
Also langsam reicht es mal wieder. Was bitte schön ist sachlich daran mich mit irgendwelchen dubiosen Anbietern zu vergleichen. Und bereichern tue ich mich schon mal garnicht daran, ganz im Gegenteil. Irgendwie scheinst du es dir zur Aufgabe gemacht zu haben, den wenigen verbliebenen Entwicklern für unsere Platform auch noch den Spass zu verderben.
-
Ein "make 192 COUNTRY=de" läuft jetzt seit vier Stunden. Auf einem i5 MacMini dauerte es komplett nichtmal eine Minute.
Daß man heutige Hardware nicht mit einem Atari (auch nicht mit einem TT) vergleichen kann, sollte klar sein. Aber 4h, und nicht mal fertig ist schon happig. Hattest du das mal mit gcc 4.6.4 auf dem TT versucht?
Was meint ihr wie lange der rechner braucht? 24 Stunden oder mehr?
Hm, kA. Troed hatte mal berichtet, daß die TOS 3.06 Sourcen auf einem STE ca 2 1/2 Stunden brauchen, vom Umfang müsste das vergleichbar sein. Aber der verwendete Compiler dort ist Alcyon, der so gut wie keine Optimierungen macht und erheblich einfacher gestrickt ist.
Aber das OSX GCC 8 Paket lies sich nicht einfach installieren.
Irgendwelche Fehler-Meldungen was genau nicht ging wäre hilfreich ;) hast du das über Philip's Paket drüber installiert, oder frisch?
-
Also langsam reicht es mal wieder.
Ganz meine Meinung.
Meine sachliche Kritik & Meinungsäußerung stand in #32. Das hätte ja unkommentiert stehen bleiben können. Stattdessen kam von GH und von Dir in ## 33 &34 Polemik. Können wir das jetzt bitte wieder beenden?!
Die von Dir zitierten Wörter ´Lockvogelangebote´, ´Kommerzramsch-Niveau´ und ´dubiose Anbieter´ wurden von _mir_ nicht benutzt!
-
bunzip2 dauerte eine Stunde und tar nochmal eine halbe Stunde zum entpacken und installieren.
Könnte man bunzip2 & tar nicht auf ´ner Windose machen und dann das ausgepackte System auf den TT übertragen?
Oder das System unter Hatari laufen lassen?
Wie groß muß eine Partition min. sein um das System sinnvoll benutzen zu können?
-
Oder das System unter Hatari laufen lassen?
Könnte man machen, aber dann kannst du auch gleich einen cross-compiler nehmen.
Wie groß muß eine Partition min. sein um das System sinnvoll benutzen zu können?
Das (gepackte) gcc archiv ist ~25 MB, ausgepackt ca. 80MB. dazu brauchst du dann noch mindestens binutils, mintlib, gemlib und was du sonst noch an libraries brauchst. Grob geschätzt würde ich da mind. 200MB veranschlagen. Hängt natürlich auch davon ab, ob du nur den compiler, oder das ganze MinT-System auf der Partition unterbringst. Bei mir belegt das /usr Verzeichnis ca. 1GB, allerdings sind da auch perl, python etc. mit bei.
-
Irgendwelche Fehler-Meldungen was genau nicht ging wäre hilfreich ;) hast du das über Philip's Paket drüber installiert, oder frisch?
Hatte das drüber installiert bzw. kopiert. Ich habe jetzt mal alles unter /opt gelöscht. Wie muss ich genau vorgehen und was brauche ich alles.
Der gcc auf dem Atari TT ist der 7.3.0. Im /usr/bin Ordner ist noch ein gcc.2.95.3 der vom EasyMiNT/SpareMiNT stammt. Wenn ich "make 192 COUNTRY=de" aufrufe welchen gcc wird denn da benutzt?
-
Hatte das drüber installiert bzw. kopiert. Ich habe jetzt mal alles unter /opt gelöscht. Wie muss ich genau vorgehen und was brauche ich alles.
Am einfachsten sollte es mit dem Komplett-Paket (http://tho-otto.de/download/mint/m68k-atari-mint-base-20180831-macos.tar.xz) sein. Nach dem Download dann auspacken mit
tar xvf m68k-atari-mint-base-20180831-macos.tar.xz --directory /
Der gcc auf dem Atari TT ist der 7.3.0. Im /usr/bin Ordner ist noch ein gcc.2.95.3 der vom EasyMiNT/SpareMiNT stammt. Wenn ich "make 192 COUNTRY=de" aufrufe welchen gcc wird denn da benutzt?
Offensichtlich schon der neue (sieht man ja an der Versionsnummer). Entweder hast du dir den alten bereits überschrieben, oder der ist unter einem anderen Namen installiert. Im Zweifelsfall mal ein
ls -l /usr/bin/*gcc*
eingeben.
Das solllte dann ca. so aussehen
-rwxr-xr-x 3 sebilla users 892618 2. Okt 12:37 usr/bin/gcc
-rwxr-xr-x 2 sebilla users 141106 2. Okt 12:37 usr/bin/gcc-ar
-rwxr-xr-x 2 sebilla users 140968 2. Okt 12:37 usr/bin/gcc-nm
-rwxr-xr-x 2 sebilla users 140976 2. Okt 12:37 usr/bin/gcc-ranlib
-rwxr-xr-x 3 sebilla users 892618 2. Okt 12:37 usr/bin/m68k-atari-mint-gcc
-rwxr-xr-x 3 sebilla users 892618 2. Okt 12:37 usr/bin/m68k-atari-mint-gcc-7.3.0
-rwxr-xr-x 2 sebilla users 141106 2. Okt 12:37 usr/bin/m68k-atari-mint-gcc-ar
-rwxr-xr-x 2 sebilla users 140968 2. Okt 12:37 usr/bin/m68k-atari-mint-gcc-nm
-rwxr-xr-x 2 sebilla users 140976 2. Okt 12:37 usr/bin/m68k-atari-mint-gcc-ranlib
Das Makefile benutzt "gcc" für Hilfsprogramme, und "m68k-atari-mint-gcc" für EmuTOS selber. Auf dem TT sind die beiden identisch.
-
Was mache ich falsch? Es soll ja unter /opt entpackt werden ...
Franks-MacMini:/ frank$ tar xvf /Users/frank/Downloads/m68k-atari-mint-base-20180831-macos.tar.xz /opt
tar: /opt: Not found in archive
tar: Error exit delayed from previous errors.
Edit:
tar xvf /Users/frank/Downloads/m68k-atari-mint-base-20180831-macos.tar.xz --directory /opt
... ergibt Fehler: Failed to create dir 'opt'Can't create 'opt/cross-mint/m68k-atari-mint/sys-root/usr/share/man/man3/listen.3.gz'
/opt ist ja schon da. Oder muss ich sudo voranstellen?
-
Offensichtlich schon der neue (sieht man ja an der Versionsnummer). Entweder hast du dir den alten bereits überschrieben, oder der ist unter einem anderen Namen installiert. Im Zweifelsfall mal ein
ls -l /usr/bin/*gcc*
eingeben.
Sieht bei mir so aus siehe Bild ...
-
Was mache ich falsch? Es soll ja unter /opt entpackt werden ...
Ja, allerdings ist in den von mir erstellten Archiven (im Gegensatz zu Philipp's) der Pfadname /opt schon enthalten, deswegen muss das unter / entpackt werden.
Oder muss ich sudo voranstellen?
Das könnte sein, je nachdem welche Berechtigungen das Verzeichnis hat.
Wenn du da Sorgen hast: du kannst es auch erstmal im aktuellen Verzeichnis entpacken, indem du --directory weglässt. Du müsstest dann im aktuellen Verzeichnis ein Verzeichnis namens "opt" haben. Den Inhalt kannst du dann immer noch verschieben. Wenn alles funktioniert hat, müsste es ein Verzeichnis /opt/cross-mint geben, daß dann so aussieht:
drwxr-xr-x 56 me _lpoperator 1904 Oct 14 2017 bin
drwxr-xr-x 4 me _lpoperator 136 Oct 14 2017 lib
drwxr-xr-x 5 me _lpoperator 170 Apr 10 10:57 m68k-atari-mint
drwxr-xr-x 5 me _lpoperator 170 Apr 10 10:58 m68k-atari-mintelf
drwxr-xr-x 6 me _lpoperator 204 Oct 14 2017 share
Wenn du stattdessen ein Verzeichnis /opt/opt hast, ist was falsch gelaufen ;)
-
Habe mal das Archiv durch Anklicken gestartet, da kam es aber zu Fehlern, siehe Bild. Habe danach das ganze noch mal manuell über das Terminal entpackt.
Jede Mal nach einem Neustart das untenstehende einzugeben Nervt, geht das nicht anders?
export PATH=$PATH:/opt/cross-mint/bin
export MANPATH=$MANPATH:/opt/cross-mint/share/man
Wenn ich gcc --version aufrufe kommt das untenstehende ...
Franks-MacMini:~ frank$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
-
Habe mal das Archiv durch Anklicken gestartet, da kam es aber zu Fehlern, siehe Bild.
Hm, mögicherweise eine Beschränkung des tools das das Archiv auspackt, der Pfadname ist ziemlich lang.
Jede Mal nach einem Neustart das untenstehende einzugeben Nervt, geht das nicht anders?
Ja, in die $HOME/.profile schreiben ;) Hatten wir das nicht schon?
Wenn ich gcc --version aufrufe kommt das untenstehende ...
Franks-MacMini:~ frank$ gcc --version
Der cross-compiler installiert sich ja auch nur als m68k-atari-mint-gcc, der normale gcc ist der für macOS, den willst du ja auch nicht damit überschreiben.
-
Ja, in die $HOME/.profile schreiben ;) Hatten wir das nicht schon?
Ja schon klar aber ich weiss nicht wie ich das machen soll? Ich kann ...
vi /Users/frank/.profile
... aufrufen. Aber was soll ich da eintragen? Ich kann mit vi nicht umgehen, kann vi nicht bedienen.
-
Ich kann .profile jetzt bearbeiten.
-
Ja, ist einfach eine Text-Datei, kannst du auch TextEdit.app für nehmen. Allerdings ist die Datei im FInder wahrscheinlich nicht sichtbar, dazu musst du erstmal versteckte Dateien ainzeigen lassen, zB. mit Cmd-Shift-.
-
Ja und was und wie muss da rein?
Soll die .profile Datei in meinem User Ordner so aussehen ...
test -r /sw/bin/init.sh && . /sw/bin/init.sh
export PATH=$PATH:/opt/cross-mint/bin
export MANPATH=$MANPATH:/opt/cross-mint/share/man
-
Hat das jetzt geklappt unter macOS auf dem Apple Macintosh ?
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e7a4
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
# etos192de.img done (364 bytes free)
# RAM used: 59300 bytes (7588 bytes more than TOS 1.02)
-
Soll die .profile Datei in meinem User Ordner so aussehen ...
Hat das jetzt geklappt unter macOS auf dem Apple Macintosh ?
Ja, schaut gut aus, herzlichen Glückwunsch ;)
-
Vielen Dank.
-
Und was macht der TT? Kompiliert der immer noch? ;)
-
Einfache Abhilfe: über Setup.exe von cygwin einfach das compiler-paket installieren.
Danke das war es. Habe einfach das komplette Devel Paket installiert. Ist jetzt wahrscheinlich viel unnötiges dabei, aber hauptsache es geht.
Ich nehme an das hier der normle gcc genutzt wird ist eine Besonderheit von EmuTOS.
Jetzt kommt die Auseinandersetzung wie das ganze mit den Makefile funktioniert. Damit meine ich jetzt nicht speziell für EmuTOS sondern generell.
-
Ich nehme an das hier der normle gcc genutzt wird ist eine Besonderheit von EmuTOS.
Daß auf dem Host (auf dem es dann gleich anschließend laufen muß) ein Programm erzeugt wird, das erst einen Teil des Ziel-Quellcodes erzeugt, kommt beim Cross-Compilieren öfter mal vor und ist nicht unbedingt EmuTOS-spezifisch. Wenn man (z.B.) MiNT (cross-) compiliert, muß auch erst ein Programm übersetzt werden, das die Tabellen mit den Einsprungadressen für die Betriebssystem-Traphandler erzeugt.
-
Und was macht der TT? Kompiliert der immer noch? ;)
Kann man auf dem Atari TT mit gcc 7.3.0 das "make 192 COUNTRY=de" nicht ein paar Stunden laufen lassen und dann mit Ctrl+c abbrechen und später an der gleichen abgebrochenen Stelle weitermachen lassen?
-
ja, sollte man können. Du musst nur aufpassen daß du beim nächsten mal die gleiche Kommandozeile verwendest. Wenn das target geswitcht werden soll (zb. "make 256"), musst du vorher ein "make clean", machen, dh. es geht alles von vorne los.
Oder einfach mal ne Nacht durchlaufen lassen ;)
-
Und was macht der TT? Kompiliert der immer noch? ;)
Kann man auf dem Atari TT mit gcc 7.3.0 das "make 192 COUNTRY=de" nicht ein paar Stunden laufen lassen und dann mit Ctrl+c abbrechen und später an der gleichen abgebrochenen Stelle weitermachen lassen?
Ja, geht, wie @czietz schrieb, wenn man den gleichen Aufruf vornimmt – und: Datum&Uhrzeit müssen stimmen.
-
Das dauert rund 20 Minuten, siehe Bild ...
Kann das sein oder Stimmt da etwas nicht ?
Das zweite Bild ist nach 30 Minuten.
-
Du hast Dich vertippt: "COUNRTY" statt "COUNTRY", weshalb er jetzt beginnt, die US-Version zu bauen -- von vorne. Dass das auf einem knapp 30 Jahren alten Rechner etwas dauert, ist zu erwarten.
-
Du hast Dich vertippt: "COUNRTY" statt "COUNTRY", weshalb er jetzt beginnt, die US-Version zu bauen -- von vorne. Dass das auf einem knapp 30 Jahren alten Rechner etwas dauert, ist zu erwarten.
Ich würde mal schätzen: etwa 8-10 Stunden. Wenn Dir der Speicher nicht unterwegs ausgeht. gcc ist ein Speicherfresser...
Wieviel Memory steckt in deinem TT?
-
Wieviel Memory steckt in deinem TT?
... siehe Bild.
Habe COUNTRY jetzt mal richtig eingetippt und das ganze nochmal von vorne laufen lassen.
-
Wieviel Memory steckt in deinem TT?
... siehe Bild.
Aha, viel.
Dann wird's daran wohl eher nicht scheitern ;)
Da könntest Du vielleicht sogar noch 100 MB für zusätzlichen MiNT-Cache abzweigen und damit etwas schneller werden.
-
Das mit dem Cache probiere ich mal. Es läuft ansonsten nichts und die Schreib/Lese LED der HDD blinkt so alle 20 bis 30 Sekunden mal kurz auf. Alles sehr langsam.
-
Alles sehr langsam.
Nun, da siehst Du den Fortschritt der Rechenleistung, den Computer in 30 Jahren hingelegt haben. Compilieren ist nun einmal sehr CPU-intensiv. Zum Vergleich: Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
-
Was mich ein bisschen irritiert ist, daß cc1 in deinem Bild mit 45% CPU angezeigt wird. Der müsste eigentlich bei nahezu 100% sein (cc1 ist der eigentliche Compiler, alle anderen warten eigentlich hauptsächlich darauf, daß der fertig wird)
-
Zum Vergleich: Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
Cygwin, oder?
Linux:
make clean
time make 192
real 0m7,744s
user 0m5,804s
sys 0m0,456s
mfro@thinkpad:~
-
Das mit dem Cache probiere ich mal. Es läuft ansonsten nichts und die Schreib/Lese LED der HDD blinkt so alle 20 bis 30 Sekunden mal kurz auf. Alles sehr langsam.
Auf der FireBee hat das Zugeben von 200MB (ja, MB, nicht KB) Cache die Compilierzeit gerade mal halbiert (auf deutlich unter 10 Minuten).
Allerdings ging da vorher die HDD-LED praktisch gar nicht mehr aus, insofern wird's auf dem TT wahrscheinlich nicht so deutlich ausfallen.
-
Könntest eventuell das ganze bisschen beschleunigen wenn du die Files auf ein DMA device legst (ACSI oder SCSI) da beim IDE ja die CPU den Datentransfer machen muss.. (nur eine Idee, ob es was bringt K.A.)
-
Funktioniert das "time make ..." auf auf dem Atari?
Ich nutze IDE nur für eine CF zum Datenaustausch unter Single TOS, unter MiNT läuft NFS. Die Systemplatte ist eine LVD SCSI Platte ...
-
Könntest eventuell das ganze bisschen beschleunigen wenn du die Files auf ein DMA device legst (ACSI oder SCSI) da beim IDE ja die CPU den Datentransfer machen muss.. (nur eine Idee, ob es was bringt K.A.)
Öhm, warum dann die EmuTOS-Sourcen nicht gleich auf eine RAM-Disk legen, wenn man genug RAM hat? Dann spart man sich das gecache …
-
Könntest eventuell das ganze bisschen beschleunigen wenn du die Files auf ein DMA device legst (ACSI oder SCSI) da beim IDE ja die CPU den Datentransfer machen muss.. (nur eine Idee, ob es was bringt K.A.)
Öhm, warum dann die EmuTOS-Sourcen nicht gleich auf eine RAM-Disk legen, wenn man genug RAM hat? Dann spart man sich das gecache …
Lustigerweise ist /dev/ram in MiNT nach meiner Erfahrung nicht mal halb so schnell wie der MiNT-Cache.
Zumindest auf der FireBee. Mag woanders anders sein.
-
Bei einem Snapshot des Bildschirmes wird das Abbild im Ram unter u:/ram abgelegt und das dauert bei einer ein oder zwei Megabyte Datei einige Minuten. Also sehr langsam.
-
Ist fertig nach etwas mehr als 4 Stunden. Ich lasse das ganze morgen mal mit time vor dem Befehl laufen ...
Ich dachte oder hatte die Hoffnung die Größe die Rauskommt wäre ungefähr die gleiche wie mit der 8ter Version vom gcc. Gibt es irgendwo die aktuelle gcc Version für MiNT?
-
Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
17 Sekunden zu 4 Stunden ist ja eine Hausnummer.
-
Gibt es irgendwo die aktuelle gcc Version für MiNT?
Für mint bisher nicht, nur als cross-compiler. Die Scripts und Patches sind aber praktisch identisch zu 7.3, kann also nur ne Frage der Zeit sein bis Miro den gebastelt hat ;)
-
Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
17 Sekunden zu 4 Stunden ist ja eine Hausnummer.
Nunja, in Zeiten, wo fast der gesamte Sourcecode in den Level-2-Cache von modernen, potenteren CPUs paßt … ein TT hat halt nur 3-5 MIPS. Ein 68060 liegt bei über 100 MIPS. Ein PowerPC 750/333 läuft Kreise um den - selbst wenn er ihn emulieren muss. Und das ist Prozessortechnik von 1999, nur 8 Jahre nach Ende des TT. Seitdem sind fast 20 Jahre vergangen.
Der L2-Cache in meinem Server ist größer als meine erste Festplatte, eine SH205.
-
Es ist ja schön das es überhaupt noch geht !
-
Glückwunsch, Frank! Da hast Du etwas geschafft, wovon ich noch meilenweit entfernt bin.
Ziemlich irritiert bin ich über die gemeldeten Zeiten und Größen. Wie hat denn Atari damals, sagen wir 1987, das TOS kompiliert? Weiß das jemand? Ich kann mir weder vorstellen, daß ein TOS zu kompilieren viele Stunden gebraucht hat, noch, daß da Bibliotheken & Tools von 1GB Größe nötig waren.
-
Ziemlich irritiert bin ich über die gemeldeten Zeiten und Größen. Wie hat denn Atari damals, sagen wir 1987, das TOS kompiliert? Weiß das jemand? Ich kann mir weder vorstellen, daß ein TOS zu kompilieren viele Stunden gebraucht hat, noch, daß da Bibliotheken & Tools von 1GB Größe nötig waren.
Atari hat den Alcyon-Compiler verwendet (der Standard-Compiler für CP/M 68K).
Der ist im Vergleich zu einem aktuellen gcc knalldoof, optimiert so gut wie nichts und kann - natürlich - nix von dem, was sich in den letzten 30 Jahren am C-Standard weiterentwickelt hat (und noch nicht mal all das, was damals schon Standard war). Der Alcyon war berüchtigt dafür, daß man mit ihm ganz leicht fehlerhafte Programme schreiben konnte, weil er nur eine sehr rudimentäre Fehlerbehandlung hatte.
Eigentlich nur ein Makroassembler, der ein wenig C versteht.
Im Vergleich dazu sind aktuelle C-Compiler Raketentechnik.
Sie finden (wenn man sie läßt) nahezu jeden Fehler, übersetzen den Quellcode zunächst in eine eigene "Zwischensprache", in der aufwendige Codeoptimierungen durchgeführt werden (gut für uns, weil wir so auch von Weiterentwicklungen der Optimierungsfunktionen profitieren können, obwohl niemand mehr das m68k-Backend pflegt), aber das kostet natürlich Ressourcen. Hinzu kommt, daß gcc eine "universelle" Compiler Collection darstellt, die nicht nur als Grundlage für C-Compiler, sondern auch für eine Vielzahl von anderen Sprachen verwendet wird. Und das nicht nur für m68k, sondern auch für -zig andere Architekturen. Das erzeugt natürlich Overhead, der der Geschwindigkeit nicht zuträglich ist.
Die originalen TOS-Sourcen kriegst Du nicht durch einen aktuellen C-Compiler (genausowenig, wie man ein aktuelles EmuTOS mit dem Alcyon-Compiler übersetzen könnte). Dazu hat sich die Sprache in 30 Jahren viel zu sehr weiterentwickelt (zum Glück!). Das ist so, wie wenn wir hier plötzlich Mittelhochdeutsch miteinander reden wollten.
Dazu kommt, das EmuTOS überwiegend in C geschrieben ist, während in den originalen TOS-Sourcen der Assembleranteil (das damalige C war viel zu lahm und doof für zeitkritische Dinge) deutlich überwiegt. Assembler läßt sich natürlich deutlich unaufwendiger übersetzen.
Weiterhin setzen alte Compiler mehr oder weniger direkt auf TOS auf, während gcc auf dem MiNT-Überbau aufsetzt, der ihm ein Unix-System vorspielt. Das macht die Sache natürlich auch nicht unbedingt schneller und ressourcenschonender.
-
Zum Vergleich: Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
Cygwin, oder?
Die obige Zahl ja. Jetzt mal unter dem Windows Subsystem for Linux und damit quasi nativ: 5 Sekunden für ein EmuTOS 192k. Ich hätte nicht gedacht, dass Cygwin den Prozess so stark verlangsamt.
-
Der ist im Vergleich zu einem aktuellen gcc knalldoof, optimiert so gut wie nichts und kann - natürlich - nix von dem, was sich in den letzten 30 Jahren am C-Standard weiterentwickelt hat (und noch nicht mal all das, was damals schon Standard war). Der Alcyon war berüchtigt dafür, daß man mit ihm ganz leicht fehlerhafte Programme schreiben konnte, weil er nur eine sehr rudimentäre Fehlerbehandlung hatte.
Eigentlich nur ein Makroassembler, der ein wenig C versteht.
Im Vergleich dazu sind aktuelle C-Compiler Raketentechnik.
Dank @Thorsten Otto haben wir ja eine Build-Umgebung mit dem damaligen Alcyon-Compiler und TOS 2.06/3.06 Source-Code. Laut README dauert ein Compiliervorgang von Atari TOS damit auf dem STE auch schon ca. 2 Stunden -- und das, wie Du sagst, trotz des hohen Assembler-Anteils (ggü. EmuTOS) und des viel "dümmeren" C-Compilers.
-
Mich würde es nicht wundern, wenn Atari das TOS damals auf irgendeiner Workstation per Crosscompiler übersetzt hat. Henne/Ei Problem...ich glaube auch nicht, daß der erste ST Prototyp 4MB und Festplatte hatte ;)
Alcyon C mit Floppy uns zu wenig RAM ist sowas von einer Strafe.
-
Dank @Thorsten Otto haben wir ja eine Build-Umgebung mit dem damaligen Alcyon-Compiler und TOS 2.06/3.06 Source-Code. Laut README dauert ein Compiliervorgang von Atari TOS damit auf dem STE auch schon ca. 2 Stunden -- und das, wie Du sagst, trotz des hohen Assembler-Anteils (ggü. EmuTOS) und des viel "dümmeren" C-Compilers.
IIRC war das make dort strunzdoof, und der Alcyon auch im Vergleich zu anderen kontemporären Compilern nicht gerade toll war. Ich beziehe mich aber nur auf Gefluche von Bekannten um 1988, die dann schnell und gerne auf Mark Williams C/Lattice C oder dann Laser C wechselten. Und als Turbo C rauskam, war das Geschwindigkeitsrennen entschieden.
Was mich interessieren würde: ob bei nontrivialen Allerweltsaufgaben der gcc-Code tatsächlich schneller auf der Zielhardware (68030/16 …) läuft als PureC. Clevere Optimierungen sind ja prima, aber wenn dafür bspw. eine kleine Schleife ausgerollt wird, dann hat der 030 mit seinem winzigen 256 Byte-Instruktions-Cache halt schon verloren. Auf einer modernen CPU mit Kilobyte-weise Cache merkt man das natürlich nicht.
Zumindest am Mac steht man mit dem A/UX ANSI-C-Compiler (ab Werk war nur K&R dabei, der ANSI mußte gekauft werden) deutlich fixer da als mit gcc 2.9x. Okay, der ist auch steinalt, ich weiß, gibt aber nix neueres fertig dafür.
Und, um mal wieder ein Lob auszusprechen: Crosscompile-Umgebungen hat am Mac faktisch niemand1 der Community zur Verfügung gestellt. Tätschelt also hier bitte alle schön die letzten Tüftler und Entwickler, sie tun gutes und verlängern den Spaß am Gerät!
1: mpw for macOS / OS X (http://blog.steventroughtonsmith.com/post/109040361205/mpw-carbon-and-building-classic-mac-os-apps-in-os) geht als einziges, AFAIK, in die Richtung – immerhin hat man dann eine moderne Maschine vor sich, aber es wird nicht nativ compiliert, sondern da ist ein 68k-Emulator dazwischen. Aber immerhin bekommt man so das selbe Programm auf "System 1.0" (https://66.media.tumblr.com/edcca7464cf63cff2b63940910bcaa76/tumblr_inline_p8w6u8SOGe1qzq1wo_500.jpg) (1984) als auch auf dem neuesten macOS Intel ans laufen – nativ!
-
Mich würde es nicht wundern, wenn Atari das TOS damals auf irgendeiner Workstation per Crosscompiler übersetzt hat. Henne/Ei Problem...ich glaube auch nicht, daß der erste ST Prototyp 4MB und Festplatte hatte ;)
Man benutzte wohl DEC-VAX-Maschinen mit vt100-Konsolen für die erste Entwicklung, und MV/8000: http://www.dadhacker.com/blog/?p=1051
-
Zum Vergleich: Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).
Cygwin, oder?
Die obige Zahl ja. Jetzt mal unter dem Windows Subsystem for Linux und damit quasi nativ: 5 Sekunden für ein EmuTOS 192k. Ich hätte nicht gedacht, dass Cygwin den Prozess so stark verlangsamt.
Das geht (mit 8 Kernen) noch deutlich schneller:
make clean
time make 192 -j
...
m68k-atari-mint-gcc -m68000 -mshort -nostartfiles -nostdlib obj/startup.o obj/lowstram.o obj/memory.o obj/processor.o obj/vectors.o obj/aciavecs.o obj/bios.o og
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001404 MEMBOT=0x0000dd48
./mkrom pad 192k emutos.img etos192us.img
# Padding emutos.img to 192 KB image into etos192us.img
# etos192us.img done (3736 bytes free)
# RAM used: 56648 bytes (4936 bytes more than TOS 1.02)
real 0m1,522s
user 0m7,593s
sys 0m0,640s
1,5 Sekunden. Nicht daß das unbedingt notwendig wäre ;)
-
Was mich interessieren würde: ob bei nontrivialen Allerweltsaufgaben der gcc-Code tatsächlich schneller auf der Zielhardware (68030/16 …) läuft als PureC.
Dazu habe ich mein Experiment mit CoreMark wiederholt, dieses Mal auf dem TT:
PureC 1.1, Codegenerierung für 68020 und 68881 (FPU) aktiviert: 7,77 Iterationen/Sekunde,
gcc 4.6.4 (von Vincent) -O2 -mcpu=68030: 14,67 Iterationen/Sekunde.
Damit ist der TT etwa 8-9 so schnell wie mein ST: https://forum.atari-home.de/index.php/topic,13075.msg209718.html#msg209718, das Verhältnis zwischen PureC und gcc 4.6.4 bleibt ähnlich.
Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.
Was CoreMark (https://github.com/eembc/coremark) macht, würde ich schon als "nontrivialen Allerweltsaufgaben" bezeichnen. Also Algorithmen, die man auch in Anwendungen finden könnte: Listen abarbeiten, Sortieren, CRCs, State-Machines, Arithmetik...
-
Das geht (mit 8 Kernen) noch deutlich schneller:
make clean
time make 192 -j
...
m68k-atari-mint-gcc -m68000 -mshort -nostartfiles -nostdlib obj/startup.o obj/lowstram.o obj/memory.o obj/processor.o obj/vectors.o obj/aciavecs.o obj/bios.o og
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001404 MEMBOT=0x0000dd48
./mkrom pad 192k emutos.img etos192us.img
# Padding emutos.img to 192 KB image into etos192us.img
# etos192us.img done (3736 bytes free)
# RAM used: 56648 bytes (4936 bytes more than TOS 1.02)
real 0m1,522s
user 0m7,593s
sys 0m0,640s
1,5 Sekunden. Nicht daß das unbedingt notwendig wäre ;)
Ich habe für das OpenSource-IRC-Server-Daemon-Projekt eines Freundes (https://ngircd.barton.de/) damals angefangen zu benchen, wie lange das Bauen braucht. Als die Werte unter 1s fielen, hab ich aufgehört, vor vielen Jahren – auf einem Core2Duo mit 2 GHz, also Technik von vor ~14 Jahren.
BTW: Das Bauen auf einem SE/30 mit NetBSD 1.51 dauerte 18 Minuten – wobei etwa 10 Minuten für autoconfig draufgingen. Der SE/30 ist etwa 25%-30% langsamer als ein TT, ein reines 68030/16-System mit eher langsamen RAM.
Wenn ich jetzt noch den Benchmark an sich finden würde … https://ngircd.barton.de/platforms.html
-
Dazu habe ich mein Experiment mit CoreMark wiederholt, dieses Mal auf den TT:
PureC 1.1, Codegenerierung für 68020 und 68881 (FPU) aktiviert: 7,77 Iterationen/Sekunde,
gcc 4.6.4 (von Vincent) -O2 -mcpu=68030: 14,67 Iterationen/Sekunde.
[…]
Was CoreMark (https://github.com/eembc/coremark) macht, würde ich schon als "nontrivialen Allerweltsaufgaben" bezeichnen. Also Algorithmen, die man auch in Anwendungen finden könnte: Listen abarbeiten, Sortieren, CRCs, State-Machines, Arithmetik...
Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.
-
Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.
gcc 8.2.0 (von Thorsten) -O2 -mcpu=68030: 16,99 Iterationen/Sekunde auf dem TT.
PS: Mit den Linux-Binaries des m68k gcc 8.2.0 bin ich natürlich wieder in das Problem gelaufen, das man eigentlich immer hat, wenn man vorcompilierte Binaries unter Linux bekommt: sie verlangen irgendwelche Bibliotheken in Versionen, die es bei mir (Debian 9) nicht gibt.
EDIT: Zum Vergleich: mein aktuelles Notebook: 30774 Iterationen/Sekunde (ein Kern), 93875 Iterationen/Sekunde (alle vier Kerne). Jeweils gcc 6.3.0 -O2. Kein Wunder, dass das Compileren von EmuTOS auf dem TT soviel länger dauert...
-
Man hat das Gefühl, das gcc wieder ein wenig zulegt, seit echte Konkurrenz (llvm) heranwächst.
Schön ist, daß auch wir offensichtlich was davon haben, obwohl sicher keiner mehr das m68k-Backend auch nur mit dem A... anguckt.
-
Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.
Ähem.
https://github.com/mfro0/libcmini
-
Neuere gccs teste ich, wenn ich herausfinde, wie ich (ohne Neukompilierung) Thorstens Packages unter etwas anderem als /usr installieren kann.
Das sollte in etwa so gehen
$ mkdir /opt/cross-mint
$ cp -pvr /usr/m68k-atari-mint/. /opt/cross-mint
$ mkdir -p /opt/cross-mint/lib64/gcc
$ cp -pvr /usr/lib64/gcc/m68k-atari-mint /opt/cross-mint/lib64/gcc/
$ cd /opt/cross-mint/bin
$ for i in addr2line ar arconv as c++ cnm cpp csize cstrip flags g++ gcc gcov ld ld.bfd mintbin nm objcopy objdump ranlib readelf size stack strings strip symex gcc-7.3.0 g++-7.3.0 cpp-7.3.0; do sudo rm -f $i; cp -a /usr/bin/m68k-atari-mint-$i .; done
$ ln -sf m68k-atari-mint-gcc-7.3.0 m68k-atari-mint-gcc
Ersetze /usr durch das Verzeichnis wo du das Archiv ausgepackt hast, und /opt/cross-mint durch das wo du es installieren möchtest. Das ganze entweder als root oder durch Einsatz von sudo.
Edit: das mit dem umkopieren ist vermutlich nicht mal notwendig, wenn du die Archive mit
$ cd /opt/cross-mint
$ tar --strip-components=1 -xf gcc-8.2.0-mint-20180831-bin-linux.tar.xz
$ tar --strip-components=1 -xf binutils-2.31-mint-20180717-bin-linux.tar.xz
auspackst. Und natürlich müssen die libraries (mintlib etc) dann auch dort installiert werden.
-
PS: Mit den Linux-Binaries des m68k gcc 8.2.0 bin ich natürlich wieder in das Problem gelaufen, das man eigentlich immer hat, wenn man vorcompilierte Binaries unter Linux bekommt: sie verlangen irgendwelche Bibliotheken in Versionen, die es bei mir (Debian 9) nicht gibt.
Das ist ein Dauer-Problem von debian, Auch auf neueren Distributionen sind standardmässig oft ziemlich alte Bibliotheken installiert (u.a. libpng12 von vor ~10 Jahren), Im fall von gcc dürfte es sich vermutlich um mpfr handeln?
-
Das ist ein Dauer-Problem von debian, Auch auf neueren Distributionen sind standardmässig oft ziemlich alte Bibliotheken installiert (u.a. libpng12 von vor ~10 Jahren), Im fall von gcc dürfte es sich vermutlich um mpfr handeln?
libisl. Und ich sehe das grundsätzlich eher als Feature in Debian...
-
libisl.
Ja, da muss ich mal schauen. Die macht bei mir seit dem letzten Upgrade scheinbar auch Probleme, und gcc lässt sich damit gar nicht mehr übersetzen.
Und ich sehe das grundsätzlich eher als Feature in Debian...
Also ich nicht. Ich finde das ziemlich arrogant, die ganze Entwicklng die seitdem da rein gesteckt wurde, einfach zu ignorieren. Das motiviert nicht gerade, überhaupt noch etwas zu entwickeln, wenns sowieso ignoriert wird. Ganz abgesehen davon daß da natürlich auch ne Menge Bugfixes bei sind. Oder möchtest du mit einem Firefox von vor 5 Jahren arbeiten, der Schlupflöcher für Viren hat, die man überall frei erhalten kann?
-
Danke @czietz, das ist doch mal eine Aussage. Dann muss ich mir mal für einen gcc eine schlank(er)e Library suchen, damit nicht wie bei der MiNT-Lib 600kB-Binaries rauskommen.
Ähem.
https://github.com/mfro0/libcmini
*fp* Da hätte ich mal mich erinnern müssen, dabei hatte ich das „damals“ sogar gleich gecloned.
Danke für den Stubs!
-
Man hat das Gefühl, das gcc wieder ein wenig zulegt, seit echte Konkurrenz (llvm) heranwächst.
Schön ist, daß auch wir offensichtlich was davon haben, obwohl sicher keiner mehr das m68k-Backend auch nur mit dem A... anguckt.
Ich denke eher, dass das 68k-Backend „bald“ mal rausfliegt. IIRC haben die Debian/68k-Entwickler immer mal wieder mit Maintainern zu argumentieren, dass da ein echter Bug sei und es ja sinnvoll sei, den zu fixen, auch wenn er nur bei 68k zu Tage tritt.
-
Ich denke eher, dass das 68k-Backend „bald“ mal rausfliegt.
Das wär natürlich übel. Aber ich denke eher nicht, es gibt immer noch reichlich Embedded Devices in denen ein m68k oder ähnliches werkelt.
-
gcc 8.2.0 (von Thorsten) -O2 -mcpu=68030: 16,99 Iterationen/Sekunde auf dem TT.
Beim stöbern im Umfeld des Themas stieß ich auf godbolt Compiler Explorer (https://godbolt.org/). "Live compiliert" im Browser kann man Ergebnisse vergleichen. Leider kein 68k dabei, aber PowerPC, ARM, MIPS und natürlich viel x86-64. Und n verschiedene gcc-Versionen, von 8.2 bis 4.x; auch clang ist zu finden.
Ich kann mit dem Output wenig anfangen, da es bei mir grade so zum 68k-Assembler lesen reicht, aber Mehrsprachler finden ja vielleicht was :-)
-
Leider kein 68k dabei
Die Jungs die den brown-gcc gestrickt haben, haben auch sowas gebastelt: http://brownbot.mooo.com/
-
Das sind die Unterschiede beim Filesystem Cache mit 4MB oder 128MB beim make 192 COUNTRY=de ...
--- Atari TT MiNT (filesystem cache 4096)/GCC 7.3.0 -------
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e7a4
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
./mkrom: emutos.img is too big: 752 extra bytes
make[1]: *** [etos192de.img] Error 1
make: *** [192] Error 2
real 289m10.035s
user 198m2.880s
sys 79m27.875s
--- Atari TT MiNT (filesystem cache 131072)/GCC 7.3.0 -------
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e7a4
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
./mkrom: emutos.img is too big: 752 extra bytes
make[1]: *** [etos192de.img] Error 1
make: *** [192] Error 2
real 225m59.190s
user 185m36.305s
sys 25m27.385s
-
Ah, warum hast Du nun den GCC 7.3.0 installiert und nicht den 8.2 ?
Mit der Lib von mfro ?
-
Habe ich da etwas überlesen? Einen 8.2 gibt es doch noch nicht für den Atari ...
-
Ach so, danke.
-
Das sind die Unterschiede beim Filesystem Cache mit 4MB oder 128MB beim make 192 COUNTRY=de ...
real 289m10.035s
...
real 225m59.190s
...
Bei der FireBee war das eher in der Größenordnung 2 bis 3 x so schnell (langsam).
Aber immerhin: mehr als 20% schneller ist ja auch schon was. Zumal es auf dem TT sowieso schwierig sein dürfte, für den viel Speicher andere sinnvolle Verwendungsmöglichkeiten zu finden.
-
@Lukas Frank : Hast Du schon mal versucht, die US-Version zu bauen?
Die englischen Texte sind deutlich kleiner, das könnte passen. Dann wüsstest Du wenigstens, ob's grundsätzlich funktioniert.
-
Habe keine Eproms mehr. Neue aus China billig sind bestellt aber das dauert.
-
Habe keine Eproms mehr. Neue aus China billig sind bestellt aber das dauert.
Haha. Ein Projekt zum Gedulds-Training. In jeder Beziehung ;)
-
Habe mal das Spaß EmuTOS de192kB auf dem PAK Rechner erzeugt.
--- PAK030/50Mhz MiNT (filesystem cache 4096)/GCC 7.3.0
# TEXT=0x00fc0000 STKBOT=0x00000800 LOWSTRAM=0x00001000 BSS=0x00001c04 MEMBOT=0x0000e55c
gcc -ansi -pedantic -Wall -Wundef -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wtype-limits -W -O tools/mkrom.c -o mkrom
./mkrom pad 192k emutos.img etos192de.img
# Padding emutos.img to 192 KB image into etos192de.img
# etos192de.img done (2232 bytes free)
# RAM used: 58716 bytes (7004 bytes more than TOS 1.02)
real 141m5.725s
user 108m21.835s
sys 31m36.060s
Atari TT war ...
real 225m59.190s
user 185m36.305s
sys 25m27.385s
Was Seltsam ist dass das Image 2232 bytes frei hat im Gegensatz zum Atari TT wo 752 bytes fehlten !?!
-
Was Seltsam ist dass das Image 2232 bytes frei hat im Gegensatz zum Atari TT wo 752 bytes fehlten !?!
Liegt vermutlich daran daß du beim PAK Rechner nicht versuchst hast, IDE mit einzubauen?
-
Hallo,
ich habe mir auf Mac OS Big Sur auch wieder alles Eingerichtet und versuche EmuTOS zu kompilieren, aber leider ebenfalls mit folgenden fehler
bios/startup.S:11:27: fatal error: ../obj/header.h: No such file or directory
compilation terminated.
make[1]: *** [obj/startup.o] Error 1
make: *** [256] Error 2
ingouhlemann@MBP-von-Ingo emutos %
Ich habe schon verschiedene Cross Compiler getestet, von Thorsten und auch von Vincent aber immer das gleiche. Woran könnte das denn liegen ?
-
Hallo,
ich habe mir auf Mac OS Big Sur auch wieder alles Eingerichtet und versuche EmuTOS zu kompilieren, aber leider ebenfalls mit folgenden fehler
bios/startup.S:11:27: fatal error: ../obj/header.h: No such file or directory
compilation terminated.
make[1]: *** [obj/startup.o] Error 1
make: *** [256] Error 2
ingouhlemann@MBP-von-Ingo emutos %
Ich habe schon verschiedene Cross Compiler getestet, von Thorsten und auch von Vincent aber immer das gleiche. Woran könnte das denn liegen ?
Vincents gcc 4.6.4 ist der offizielle Compiler, aber auch mit Thorstens gcc lässt sich EmuTOS compilieren.
1. Welche Version bzw. woher genau kommt der Sourcecode? (Einige Snapshots waren kaputt.)
2. Bitte poste die gesamte Ausgabe von make und nicht nur die Fehlermeldung.
-
Ich habe genau diesen Crosscompile verwendet! Also der von Vincent.. Und ich habe den aktuellen stand aus github ausgechecket. Ich poste gleich den code!
-
Ja, da scheint es ein Problem mit Compilieren auf MacOSX zu geben.
Der eigentliche Fehler tritt aber schon vorher auf (hast Du das auch - ein paar Zeilen vorher im Compiler-Log?):
./localise -g -u localise.ctl bios/ctables.h include/i18nconf.h po/LINGUAS
specified group -u not found in control file
-
Ja genau habe ich
emutos % make 256
/Library/Developer/CommandLineTools/usr/bin/make DEF='-DTARGET_256' OPTFLAGS='-Os' UNIQUE=us ROM_256=etos256us.img etos256us.img
echo us us > obj/country
rm -f bios/bios.tr.c obj/bios.o
rm -f bios/initinfo.tr.c obj/initinfo.o
rm -f bios/kprint.tr.c obj/kprint.o
rm -f bdos/osmem.tr.c obj/osmem.o
rm -f aes/gem_rsc.tr.c obj/gem_rsc.o
rm -f desk/desk_rsc.tr.c obj/desk_rsc.o
rm -f desk/deskinf.tr.c obj/deskinf.o
rm -f cli/cmdint.tr.c obj/cmdint.o
rm -f cli/cmdmain.tr.c obj/cmdmain.o
rm -f cli/cmdparse.tr.c obj/cmdparse.o
rm -f cli/cmdutil.tr.c obj/cmdutil.o
echo > obj/group
gcc -ansi -pedantic -Wall -Werror=undef -Werror=missing-prototypes -Werror=strict-prototypes -Werror=implicit-function-declaration -Werror=format -Werror=redundant-decls -Werror=format-extra-args -Werror=old-style-definition -Werror=type-limits -W -O tools/localise.c -o localise
./localise -g -uus localise.ctl bios/ctables.h include/i18nconf.h po/LINGUAS
specified group -u not found in control file
m68k-atari-mint-gcc -m68000 -mshort -Os -fomit-frame-pointer -fno-common -Wall -Werror=undef -Werror=missing-prototypes -Werror=strict-prototypes -Werror=implicit-function-declaration -Werror=format -Werror=redundant-decls -Werror=format-extra-args -Werror=old-style-definition -Werror=type-limits -Iinclude -DWITH_AES=1 -DWITH_CLI=1 -DTARGET_256 -c bios/startup.S -o obj/startup.o
bios/startup.S:11:27: fatal error: ../obj/header.h: No such file or directory
compilation terminated.
make[1]: *** [obj/startup.o] Error 1
make: *** [256] Error 2
-
Ja. Offensichtlich hat schon länger keiner mehr auf OS X gebaut.
Das tool "localise" benutzt die C-Funktion "getopt()". Die unterstützt bei Mac OS/BSD keine optionalen Argumente für Optionen.
Du kannst dir vorläufig (bis das endgültig gefixt ist, muss ich aber erst mal sehen, wie) behelfen, indem Du statt
make 512(z.B.)
make 512 GROUP=\* UNIQUE=de
aufrufst. Das sollte eigentlich funktionieren.
-
Ja. Offensichtlich hat schon länger keiner mehr auf OS X gebaut.
Naja, hängt von Deiner Definition von "länger" ab ;-). Das problematische "localize"-Tool gibt es ja erst seit gut 3 Wochen.
Das tool "localise" benutzt die C-Funktion "getopt()". Die unterstützt bei Mac OS/BSD keine optionalen Argumente für Optionen.
Magst Du das auf emutos-devel posten? Danke!
-
Sehr gut dankeschön, damit kann ich EmuTOS Kompilieren
-
Das tool "localise" benutzt die C-Funktion "getopt()". Die unterstützt bei Mac OS/BSD keine optionalen Argumente für Optionen.
PS: Mac OS ist da wieder ziemlich primitiv. Diese Syntax mit "::" für optionale Argumente gibt es in Linux' glibc (https://man7.org/linux/man-pages/man3/getopt.3.html), Cygwin, NetBSD (https://man.netbsd.org/getopt.3), FreeBSD (https://www.freebsd.org/cgi/man.cgi?getopt(3)), OpenBSD (https://man.openbsd.org/getopt.3). Nur MacOS (https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getopt.3.html) ist auf dem Stand "BSD April 27, 1995" stehen geblieben. Retrocomputing bei Apple? ;D
-
Ja. Offensichtlich hat schon länger keiner mehr auf OS X gebaut.
Naja, hängt von Deiner Definition von "länger" ab ;-). Das problematische "localize"-Tool gibt es ja erst seit gut 3 Wochen.
Haha. Drei Wochen sind länger als zwei Wochen ;)
Magst Du das auf emutos-devel posten? Danke!
Habe ich vor - mal sehen, ob ich gleich eine Lösung anbieten kann. So viele EmuTOSler, die auf OS X testen können, gibt's ja nicht.
PS: Mac OS ist da wieder ziemlich primitiv. Diese Syntax mit "::" für optionale Argumente gibt es in Linux' glibc, Cygwin, NetBSD, FreeBSD, OpenBSD. Nur MacOS ist auf dem Stand "BSD April 27, 1995" stehen geblieben. Retrocomputing bei Apple? ;D
Dafür, dass BSD denen den verlängerten Rücken gerettet hat, haben die reichlich geringe Affinität zu U*X.
Das Powerbook wird definitiv mein letztes sein - es gibt mittlerweile noch einiges anderes, was mir an dem Laden nicht gefällt...
-
EmuTOS sollte sich ab Commit b29b3f61 wieder unter macOS bauen lassen.
PS: Sorry, @mfro, dass es nicht Dein Patch geworden ist.
-
EmuTOS sollte sich ab Commit b29b3f61 wieder unter macOS bauen lassen.
PS: Sorry, @mfro, dass es nicht Dein Patch geworden ist.
Ist doch kein Problem - mir fällt deswegen kein Zacken aus der Krone ;)
-
Ich teste eben mal und gebe feedback
Edit: Ich kann es bestätigen, mit dem Patch läuft das Kompilieren ohne Fehler durch! Vielen dank für eure mühe
-
Hier wäre es auch noch interessant wie groß der Cache-Einfluss ist wenn als Festplatte ein Flash-Medium statt einer mechanischen Platte zu Einsatz kommt?
-
Sicher das dies hier richtig ist? @Arthur
-
Sicher das dies hier richtig ist? @Arthur
Ja, im Bereich um #82 ging's um die Beschleunigung des Compilierens durch erhöhen des Cachespeichers.
-
Keiner der Entwickler compiliert das auf echter Hardware. Dort wird es höchstens getestet.
-
Keiner der Entwickler compiliert das auf echter Hardware. Dort wird es höchstens getestet.
Tatsächlich hat mich Arthur's etwas "später" Post dazu animiert, EmuTOS mal "nebenher" auf der Firebee zu compilieren:
real 16m56.085s
user 9m55.455s
sys 6m47.605s
Das war auf einem NFS-Filesystem. Herausgefallen ist das exakt identische Binary wie auf dem Cross-Compiler Host.
-
Also die selben Checksummen... kaum zu glauben.
-
Tatsächlich hat mich Arthur's etwas "später" Post dazu animiert, EmuTOS mal "nebenher" auf der Firebee zu compilieren:
real 16m56.085s
user 9m55.455s
sys 6m47.605s
Das war auf einem NFS-Filesystem. Herausgefallen ist das exakt identische Binary wie auf dem Cross-Compiler Host.
Die Werte sind zu addieren also ca. 33m?
-
Nein, tatsächlich knapp 17min, davon knapp 10min gearbeitet, und der Rest Systemzeit, also hauptsächlich I/O.
Übrigens ein erstaunlich guter Wert. Aranym (mit JIT) braucht ca 8min (für das emutos-aranym.img zumindest, die anderen gehen vermutlich ein bisschen schneller).
Wenn man das hochrechnet, kommt man aber zu dem Schluss, daß selbst ein TT wohl mehrere Stunden brauchen würde. Abgesehen davon, daß man auch entsprechend viel Speicher haben muss (gcc ist da nicht gerade kleinlich, denke mal 20-30MB dürfte minimum sein).
-
Nein, tatsächlich knapp 17min, davon knapp 10min gearbeitet, und der Rest Systemzeit, also hauptsächlich I/O.
Danke für den Hinweis. Also real = user + sys.
-
Das war mein Versuch auf einem Atari TT ...
Habe mir mal unter MiNT auf dem Atari TT den gcc 7.3.0 installiert.
-> https://github.com/freemint/m68k-atari-mint-gcc/releases/tag/gcc-7_3_0-mint
bunzip2 dauerte eine Stunde und tar nochmal eine halbe Stunde zum entpacken und installieren.
Ein "make 192 COUNTRY=de" läuft jetzt seit vier Stunden. Auf einem i5 MacMini dauerte es komplett nichtmal eine Minute.
Ich habe es auf dem Atari TT jetzt abgebrochen da ich den Rechner nicht über NAcht laufen lassen möchte. Der Compiler war bei deskapp.c ...
Was meint ihr wie lange der rechner braucht? 24 Stunden oder mehr?
-
Nein, tatsächlich knapp 17min, davon knapp 10min gearbeitet, und der Rest Systemzeit, also hauptsächlich I/O.
Übrigens ein erstaunlich guter Wert. Aranym (mit JIT) braucht ca 8min (für das emutos-aranym.img zumindest, die anderen gehen vermutlich ein bisschen schneller)...
... so legt die Biene sogar noch ein wenig zu - Speicher ist ja genug da, also in die Vollen:
# FS_CACHE_SIZE= specifies the size of disk cache in kilobytes for the
# internal caching module. Default is 128.
#FS_CACHE_SIZE=4096
FS_CACHE_SIZE=204800
und statt NFS eine etwas flottere CF-Karte (obwohl die bei der Cache-Größe kaum noch was zu tun hat):
real 12m50.255s
user 9m55.650s
sys 2m47.485s
Wie man sieht, hat sich nur die sys (I/O) Zeit wesentlich verändert.