atari-home.de - Foren

Software => Alternative Betriebssysteme => Thema gestartet von: czietz am Mo 01.10.2018, 21:48:04

Titel: EmuTOS selbst compilieren
Beitrag 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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Mo 01.10.2018, 21:51:03
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am Mo 01.10.2018, 21:52:14
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", ...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Mo 01.10.2018, 21:56:43
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am Mo 01.10.2018, 22:01:22
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Mo 01.10.2018, 22:04:18
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/
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Mo 01.10.2018, 22:10:43
(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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Chocco am Mo 01.10.2018, 22:58:52
(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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Mo 01.10.2018, 23:03:49
(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.

Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 00:29:21
[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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 00:36:57
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Di 02.10.2018, 07:33:23
... 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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am Di 02.10.2018, 08:27:54
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?)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Di 02.10.2018, 08:41:57
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.

Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 10:00:13
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 10:33:32
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 10:43:28
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.

Zitat von: Lukas Frank
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.

Zitat von: Lukas Frank
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

Zitat
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: tuxie am Di 02.10.2018, 10:45:48
Du musst den Pfad zum GCC erst noch exportieren.... dann geht das kompilieren auch, steht aber glaube in der Anleitung mit drin.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 10:50:07
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 10:58:06
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 11:04:32
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 11:07:06
Habe mal neu gebootet ...

Die exports sind nach booten wieder weg. Dafür müsstest du dir in die Datei $HOME/.profile schreiben
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 13:08:09
.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 ...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 13:59:35
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 14:09:24
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 14:47:52
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 14:52:06
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Di 02.10.2018, 15:21:40
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 16:06:29
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)

Zitat
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)

Zitat
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 16:49:50
Vielen Dank für deine Hilfe aber für mich ist das alles nichts, viel zu kompliziert für meine arme Seele.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 02.10.2018, 17:30:17
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 02.10.2018, 17:57:22
Nichts für mich.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Mi 03.10.2018, 01:17:59
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.
Titel: Icons und EmuTOS (was: EmuTOS selbst compilieren)
Beitrag von: gh-baden am Mi 03.10.2018, 13:04:23
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 …
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Mi 03.10.2018, 17:39:06
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: MJaap am Mi 03.10.2018, 21:09:25
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Mi 03.10.2018, 23:54:13
^^-- 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>
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Do 04.10.2018, 00:52:42
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Do 04.10.2018, 00:58:51
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Do 04.10.2018, 01:10:48
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: KarlMüller am Do 04.10.2018, 11:57:32
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Do 04.10.2018, 12:41:39
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.

Zitat
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.

Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Do 04.10.2018, 16:35:50

... 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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Do 04.10.2018, 17:13:00
Wenn man etwas haben möchte, was *nicht* von der Stange ist, bleiben nur zwei Möglichkeiten:


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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Do 04.10.2018, 21:32:14
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Do 04.10.2018, 22:04:30
Man sollte auf sachliche Kritik nicht mit Polemik antworten - sonst kommt ebensolche zurück.
Mir scheint: Der Kaiser ist nackt.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Do 04.10.2018, 22:05:01
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Do 04.10.2018, 22:08:09
->   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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Do 04.10.2018, 23:36:05
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Do 04.10.2018, 23:48:14
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?

Zitat
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.

Zitat
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Fr 05.10.2018, 00:08:31
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!
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Fr 05.10.2018, 00:59:44
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Fr 05.10.2018, 01:24:23
Oder das System unter Hatari laufen lassen?

Könnte man machen, aber dann kannst du auch gleich einen cross-compiler nehmen.

Zitat
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 09:21:20
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Fr 05.10.2018, 12:08:51
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 /


Zitat
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 13:04:59
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 13:24:12
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 ...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Fr 05.10.2018, 14:24:46
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.

Zitat
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 16:43:05
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Fr 05.10.2018, 16:56:48
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.


Zitat
Jede Mal nach einem Neustart das untenstehende einzugeben Nervt, geht das nicht anders?

Ja, in die $HOME/.profile schreiben ;) Hatten wir das nicht schon?


Zitat
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 17:11:05
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 17:16:39
Ich kann .profile jetzt bearbeiten.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Fr 05.10.2018, 19:15:19
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-.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 19:45:13
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Fr 05.10.2018, 21:52:12
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)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Sa 06.10.2018, 01:04:40
Zitat
Soll die .profile Datei in meinem User Ordner so aussehen ...

Zitat
Hat das jetzt geklappt unter macOS auf dem Apple Macintosh ?

Ja, schaut gut aus, herzlichen Glückwunsch ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 08:59:47
Vielen Dank.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Sa 06.10.2018, 09:29:43
Und was macht der TT? Kompiliert der immer noch? ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: KarlMüller am Sa 06.10.2018, 09:33:06
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 10:27:25
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 12:43:07
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Sa 06.10.2018, 13:17:55
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Sa 06.10.2018, 13:23:58
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 13:26:35
Das dauert rund 20 Minuten, siehe Bild ...

Kann das sein oder Stimmt da etwas nicht ?

Das zweite Bild ist nach 30 Minuten.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am Sa 06.10.2018, 13:39:19
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 13:46:04
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?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 14:31:13
Wieviel Memory steckt in deinem TT?

... siehe Bild.

Habe COUNTRY jetzt mal richtig eingetippt und das ganze nochmal von vorne laufen lassen.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 15:05:42
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 16:16:35
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am Sa 06.10.2018, 16:21:47
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(!).
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Sa 06.10.2018, 16:37:34
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)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 16:39:43
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:~
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 17:03:50
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: tuxie am Sa 06.10.2018, 17:35:08
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.)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 17:44:19
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 ...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Sa 06.10.2018, 17:47:31
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 …
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Sa 06.10.2018, 17:50:48
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 17:56:55
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 18:53:25
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?

Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 19:50:11
Auf meinem Notebook baut ein komplettes EmuTOS 192k in 17 Sekunden(!).

17 Sekunden zu 4 Stunden ist ja eine Hausnummer.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Sa 06.10.2018, 19:58:07
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am Sa 06.10.2018, 20:28:33
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Sa 06.10.2018, 21:06:29
Es ist ja schön das es überhaupt noch geht !
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am So 07.10.2018, 00:51:00
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am So 07.10.2018, 07:54:08
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am So 07.10.2018, 10:27:41
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am So 07.10.2018, 10:37:13
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: simonsunnyboy am So 07.10.2018, 10:46:35
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am So 07.10.2018, 11:08:33
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!
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am So 07.10.2018, 11:55:28
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am So 07.10.2018, 12:12:21
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 ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: czietz am So 07.10.2018, 12:47:24

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...
Titel: OFF: EmuTOS selbst compilieren
Beitrag von: gh-baden am So 07.10.2018, 13:02:17
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: gh-baden am So 07.10.2018, 13:05:26
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.
Titel: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: czietz am So 07.10.2018, 13:51:09
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...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am So 07.10.2018, 14:10:53
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am So 07.10.2018, 14:12:18
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am So 07.10.2018, 15:10:58
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.
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: Thorsten Otto am So 07.10.2018, 15:25:40
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?
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: czietz am So 07.10.2018, 15:35:23
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...
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: Thorsten Otto am So 07.10.2018, 15:46:49
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.

Zitat
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?
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: gh-baden am So 07.10.2018, 16:44:38
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!
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: gh-baden am So 07.10.2018, 16:46:29
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.
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: Thorsten Otto am So 07.10.2018, 17:59:32
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.
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: gh-baden am So 07.10.2018, 19:03:37
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 :-)
Titel: Re: gcc vs. PureC (war: EmuTOS selbst compilieren)
Beitrag von: Thorsten Otto am So 07.10.2018, 19:26:23
Leider kein 68k dabei

Die Jungs die den brown-gcc gestrickt haben, haben auch sowas gebastelt: http://brownbot.mooo.com/
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am So 07.10.2018, 21:28:22
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
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Mo 08.10.2018, 04:54:00
Ah, warum hast Du nun den GCC 7.3.0 installiert und nicht den 8.2 ?
Mit der Lib von mfro ?
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Mo 08.10.2018, 07:34:30
Habe ich da etwas überlesen? Einen 8.2 gibt es doch noch nicht für den Atari ...
Titel: Re: EmuTOS selbst compilieren
Beitrag von: ari.tao am Mo 08.10.2018, 08:12:04
Ach so, danke.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Mo 08.10.2018, 09:01:26
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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Mo 08.10.2018, 09:21:23
@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.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Mo 08.10.2018, 09:41:44
Habe keine Eproms mehr. Neue aus China billig sind bestellt aber das dauert.
Titel: Re: EmuTOS selbst compilieren
Beitrag von: mfro am Mo 08.10.2018, 09:48:18
Habe keine Eproms mehr. Neue aus China billig sind bestellt aber das dauert.

Haha. Ein Projekt zum Gedulds-Training. In jeder Beziehung ;)
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Lukas Frank am Di 09.10.2018, 16:36:59
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 !?!
Titel: Re: EmuTOS selbst compilieren
Beitrag von: Thorsten Otto am Di 09.10.2018, 16:49:36
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?