atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: Tammy-Aachen am Fr 26.06.2020, 08:25:11
-
Hallo liebe Atari Freunde!
Kennt Jemand das Programm Edit DSS. Es ist ein Midi-Editor Programm für den Korg DSM-1 Synthesizer Sampler.
Ich bin auch auf der Suche nach den c-Compiler von Digital Research. Ich weiss, dass es nicht der beste Compiler ist, aber ich habe ein Einführungsbuch das speziell auf diesen Compiler zugeschnitten ist.
Hat jemand Info? Wo ich so etwas noch beziehen könnte? :)
VG Tammy
-
Ich bin auch auf der Suche nach den c-Compiler von Digital Research. Ich weiss, dass es nicht der beste Compiler ist, aber ich habe ein Einführungsbuch das speziell auf diesen Compiler zugeschnitten ist.
Bitte, bitte, tu Dir das nicht an! "Nicht der beste Compiler" ist eine heftige Untertreibung. Du wirst keine Freude damit haben; ebenso ist das nicht der geeignete Compiler, um C zu lernen. Suche lieber nach einer Kopie von Pure C (falls Du auf dem Atari entwickeln möchtest).
Davon abgesehen, dass ich Dir nur nochmal ausdrücklich davon abraten möchte, findest Du den C-Compiler von Digital Research im Entwickler-Kit von Atari, z.B. auf dev-docs: https://docs.dev-docs.org/htm/search.php?find=Atari+TOS+Developer%27s (https://docs.dev-docs.org/htm/search.php?find=Atari+TOS+Developer%27s).
-
Kennt Jemand das Programm Edit DSS. Es ist ein Midi-Editor Programm für den Korg DSM-1 Synthesizer Sampler.
Edit DSS gab es damals nur als kommerzielle Version für 250 USD. Vermutlich ist es ziemlich unwahrscheinlich, daß es mal im Orignal bei ebay auftaucht...
Schau' doch mal nach Sound Designer von Digidesign:
http://www.muzines.co.uk/articles/sound-designer-universal/3988
Sound Designer ist als Download verfügbar und schnell gefunden...
Ob Du damit etwas anfangen kannst, weiß ich nicht. Bitte probier's mal und berichte darüber!
-
Vielen Dank :)
Ich probiere den Compiler mal aus und werde berichten über meine Erfahrung.
Sound Designer kenne ich und ich weiss jetzt nicht, ob da der DSM-1 vorhanden ist. schau ich mir auch mal an!
VG Tammy :)
-
Sound Designer kenne ich und ich weiss jetzt nicht, ob da der DSM-1 vorhanden ist. schau ich mir auch mal an!
Im oben verlinkten Testbericht wird in der Infobox weit unten wird der Korg DSM-1 explizit erwähnt.
-
Ich probiere den Compiler mal aus und werde berichten über meine Erfahrung.
Hauptsache Du merkst Dir nichts, was Du mit diesem Compiler und aus jenem Buch zu C gelernt hast. Du wirst dort nämlich einen uralten Dialekt von C finden, der mit moderneren Compilern entweder gar nicht funktioniert oder als schlechter Stil gilt.
-
Bitte, bitte, tu Dir das nicht an! "Nicht der beste Compiler" ist eine heftige Untertreibung.
Dem kann ich nur zustimmen ;)
Man darf allerdings auch nicht vergessen, daß der noch aus CP/M Zeiten stammt.
Wie oben schon geschrieben, gerade für Einsteiger dürfte Pure-C die beste Wahl sein, weil einfach zu bedienen. Auch sollte die Dokumentation komplett in Deutsch vorhanden sein.
-
Hallo :)
Ich habe das Ding mal ausprobiert auf meinen Mega STE!
Ich habe folgende Befehlszeile eingegeben : C B:Programname
Ist echt schwierig mit dem Compiler, da er zwar startet, aber nichts finden kann. Sehr Merkwürdig? Das Programm habe ich separat auf eine Diskette verband. Er greift auch drauf zu, aber er findet wohl nichts. Es kommen zwei Bomben und eine Menge Text? Den Compiler starte ich von einer F Partition der Festplatte? :(
Dann habe ich das Programm im gleichen Verzeichnis kopiert und die Befehlszeile ohne Laufwerksangabe A bzw. B. Genau das gleiche Problem!!!!
Dann alles nochmals auf Diskette. Compiler auf die Diskette und das Programm auf einer Diskette.
C B:Programmname , ??? Kein Ergebnis.
Braucht er vielleicht eine bestimmte Ordnerstruktur, um die Bibliotheken usw. zu finden? ::)
Ich schau mir mal Pure C an! Nutzt Pure C denn die gleichen Bibliotheken?
Danke Euch!!
VG Tammy :)
-
Ist echt schwierig mit dem Compiler, da er zwar startet, aber nichts finden kann. Sehr Merkwürdig?
Ja, er ist da recht eigen. Ich müsste nochmal nachschauen, irgendwelche Environment-Variablen müssen glaube ich gesetzt sein. Auch Abstürze mit Bomben wenn etwas falsch läuft sind relativ normal. Am besten: Finger von lassen. Du wirst da nicht glücklich mit werden, selbst wenn du es zum laufen bekommst.
Nutzt Pure C denn die gleichen Bibliotheken?
Nein, Pure-C hat eigene, die aber alle mit dabei sein sollten. Einziges Problem, wenn die Beispiele in deinem Buch sich auf den alten Compiler beziehen: die Include-Dateien bei Pure-C heissen teilweise anders: osbind.h -> tos.h, aesbind.h -> aes.h etc.
-
Hallo!
ok, dann werde ich mir mal Pure-C anschauen!
Danke für die ausführliche Antwort.
VG Tammy :)
-
ok, dann werde ich mir mal Pure-C anschauen!
Gute Wahl. Genauer: fast alles ist besser als Alcyon-C. Pure C ist schnell, solide, und ein gutes Produkt. Irgendwann kannst du dann noch die Bibliotheken gegen andere austauschen.
Der Debugger von Borland/Pure ist auch gut, und der PureProfiler. Hab die aber schon lange nicht mehr benutzt, ich weiß nicht, wie die auf modernen AES-Maschinen laufen.
Mit Pure C schreibst du dann am besten ANSI C (statt des alten K&R C), das kannst du dann auch mit gcc nutzen, bspw. Christian und Thorsten hatten ja schon darauf hingewiesen, dass ANSI C „moderner“ Stil ist -- nicht nur das, es hilft auch, manche typischen C-Fehler zu vermeiden bzw. den Compiler finden zu lassen.
-
Mal vllt eine komische Frage... Aber was spricht gegen GnuC ? den gab es doch als ++-version, wenn ich mich noch recht erinnere...
-
Im Prinzip nichts, ausser daß dafür zwingend MiNT benötigt wird, und das läuft auf "normalen" STs nicht so besonders zügig. Für Einsteiger nicht so unbedingt die erste Wahl, aber wenn du C++ benutzen willst, wohl tatsächlich die einzige.
-
Mal vllt eine komische Frage... Aber was spricht gegen GnuC ? den gab es doch als ++-version, wenn ich mich noch recht erinnere...
Sicher, wenn er entweder einen sehr potenten Atari hat, oder crosscompilieren möchte, dann kann man gerne gcc nehmen.
Wenn er nur 4-8 MB RAM hat, oder irgendwas unter einem 68040, dann würde ich gerade nicht gcc nehmen. Sondern PureC oder allenfalls Lattice C.
Auf einer modernen Kiste kann man natürlich ganz prima mit gcc crosscompilieren. Dank vieler Spenden bleibt das 68k-Backend im gcc noch erhalten :)
-
Komisch, auf meinem normalen 1040STE mit 4mb und 2.06 unter MiNT rennt es quasi sauber. Und was heißt schnell? Wenn ich Schnelligkeit will, nehme ich keinen ATARI, dann hau ich meinen Musikrechner oder mein Coding-System an...Bei der Nutzung meines ATARIs will ich hauptsächlich Spaß und die Geschwindigkeit setze ich nicht voraus... Imho halt.Aber lief GnuC (ohne die ++-Adaption) nicht sogar unterm' Plain_system ohne Mint ?!? Meine doch. Wobei ich aus Bequemlichkeit auch eher zu Lattice greife...
-
Komisch, auf meinem normalen 1040STE mit 4mb und 2.06 unter MiNT rennt es quasi sauber
Frage mich wie das gehen soll:
$ size /usr/libexec/gcc/m68k-atari-mint/4.6.4/cc1
text data bss dec hex filename
6805288 20952 361736 7187976 6dae08 /usr/libexec/gcc/m68k-atari-mint/4.6.4/cc1
Dh. der compiler alleine braucht schon mind. 7MB um überhaupt in den Speicher zu passen. Ganz zu schweigen von allem anderen das dann gerade noch läuft...
Aber lief GnuC (ohne die ++-Adaption) nicht sogar unterm' Plain_system ohne Mint ?!?
Nein, der benutzt zum starten der diversen Prozesse fork()/exec(). Das betrifft auch make, und eine halbwegs posix-konforme shell gibts mE. unter SingleTOS auch nicht.
-
Aber lief GnuC (ohne die ++-Adaption) nicht sogar unterm' Plain_system ohne Mint ?!?
Nein, der benutzt zum starten der diversen Prozesse fork()/exec(). Das betrifft auch make, und eine halbwegs posix-konforme shell gibts mE. unter SingleTOS auch nicht.
Uuuuralte 1.x oder 2.x gcc-Versionen liefen IIRC auch unter Plain-TOS.
-
Uuuuralte 1.x oder 2.x gcc-Versionen liefen IIRC auch unter Plain-TOS.
Paßt ja zu mir. Bin ja auch Uuuuralt... *ggg* ;-)
-
Hallo!
ok, dann werde ich mir mal Pure-C anschauen!
Danke für die ausführliche Antwort.
VG Tammy :)
Es gibt auch noch den AHCC (http://members.chello.nl/h.robbers/) von Hank Robbers... ich bin kein Programmierer und weiß deshalb nicht weshalb der so wenig Erwähnung findet wenn mal nach einen C-Compiler gesucht wird. Hier gibt es eine Einführung in die GEM Programmierung bei Verwendung des AHCC (https://docs.dev-docs.org/htm/search.php?find=peter+lane).
-
ich bin kein Programmierer und weiß deshalb nicht weshalb der so wenig Erwähnung findet wenn mal nach einen C-Compiler gesucht wird.
Vermutlich weil der (gelinde gesagt) eine sehr bescheidene Oberfläche hat. Ausserdem ist sowohl der Compiler als auch die mitgelieferte Bibliothek ziemlich buggy. Wenn man nicht gerade für die FireBee entwickeln will, ist man mit Pure-C deutlich besser bedient.
Einziges Problem: Pure-C ist (im Gegensatz zu AHCC) eigentlich immer noch nicht frei erhältlich.
-
ich bin kein Programmierer und weiß deshalb nicht weshalb der so wenig Erwähnung findet wenn mal nach einen C-Compiler gesucht wird.
Vermutlich weil der (gelinde gesagt) eine sehr bescheidene Oberfläche hat. Ausserdem ist sowohl der Compiler als auch die mitgelieferte Bibliothek ziemlich buggy. Wenn man nicht gerade für die FireBee entwickeln will, ist man mit Pure-C deutlich besser bedient.
Einziges Problem: Pure-C ist (im Gegensatz zu AHCC) eigentlich immer noch nicht frei erhältlich.
Pure-C ist unter TOS/GEM tatsächlich unschlagbar. Welche "schlankere" Version des GCC könnte man denn als Basis nehmen, um sie mit einer Pure-C ähnlichen IDE aufzumöbeln? Da ich immer mit Pure-C gearbeitet habe, hat sich mir diese Frage bisher nie gestellt.
-
Pure-C ist unter TOS/GEM tatsächlich unschlagbar. Welche "schlankere" Version des GCC könnte man denn als Basis nehmen, um sie mit einer Pure-C ähnlichen IDE aufzumöbeln? Da ich immer mit Pure-C gearbeitet habe, hat sich mir diese Frage bisher nie gestellt.
Schlank heißt hier: uralt. GCC 2.5 oder 2.6 müßte die letzte für SingleTOS gewesen sein, aus meiner Erinnerung. Ich habe nie generierten Code gegenübergestellt, aber die Libraries von GCC 2.x waren viel dicker auftragend als alles rund um PureC, so dass viel schlankere Programme herauskamen.
PureC gewinnt in der 68k-Codegenerierung deutlich gegenüber Sozobon (die Basis von AHCC) und Lattice. Anderes habe ich selbst nie angeguckt, aber Zeitschriftentests zufolge hat PureC auch bspw LaserC, Megamax C ziemlich in den Boden gestampft.
Nichtsdestotrotz ist PureC inzwischen auch steinalt¹, Compileroptimierungen haben (https://www.youtube.com/watch?v=zBkNBP00wJE) heute ein völlig neues Niveau (https://www.youtube.com/watch?v=bSkpMdDe4g4) gegenüber damals erreicht (https://www.youtube.com/watch?v=w0sz5WbS5AM). Ich weiß nicht, wieviel davon im heutigen gcc generisch erreicht wird, und wieviel Plattform-unabhängig, wäre sicher einen Blick wert - und dank Crosscompiler von Thorsten und anderen ja leicht zu kriegen.
1: Schon eher simplere mathematische Optimierungen werden von PureC nicht immer erkannt und vorgenommen, das klappt schon bei manchen Kombinationen von Multiplikationen nicht, woraus man billige Additionen machen könnte.
-
Schlank heißt hier: uralt. GCC 2.5 oder 2.6 müßte die letzte für SingleTOS gewesen sein, aus meiner Erinnerung.
2.95 gab es auch noch. Wurde am Anfang wohl auch noch für Mint verwendet. Allerdings ist man dann auch an alte Libraries gebunden, neuere kriegt damit ohne ziemlichen Aufwand nicht mehr übersetzt.
Anderes habe ich selbst nie angeguckt,
Ich hab schon öfter mal Pure-C mit gcc verglichen. Hängt immer sehr vom Anwendungszweck ab, mal hat der eine die Nase vorn, mal der andere. Pure-C ist denke ich vor allem bei 68k durch die Register-Übergabe der Parameter im Vorteil, das spart einiges an Code und Speicher-Zugriffen.
Zeitschriftentests zufolge hat PureC auch bspw LaserC, Megamax C ziemlich in den Boden gestampft.
Naja das ist auch kein Wunder, die genannten waren auch nicht viel besser in der Codegenerierung als Alcyon. Nicht mal automatische Register-Zuweisung haben sie hinbekommen, das musste man alles selber explizit angeben.
und wieviel Plattform-unabhängig,
Ich würde schätzen mindestens 90% davon ist plattform (und sogar Sprachen)- unabhängig. Der plattform-abhängige Teil macht eigentlich nur noch peephole-Optimierungen (bestimmte Befehlsfolgen durch andere ersetzen).
das klappt schon bei manchen Kombinationen von Multiplikationen nicht, woraus man billige Additionen machen könnte.
Das hängt in den meisten Fällen vom Compiler-Schalter -G (Size-Optimierung) ab. Gesetzt wird dann normalerweise muls/mulu genommen, wenn nicht, und einer der Operatoren konstant ist, eine Folge von Additionen. Könnte auch noch von anderen Bedingugne abhängen (z.B. wieviel Bits in der Konstante gesetzt sind; ausserdem wird dafür ein temporäres Register benötigt), aber grundsätzlich beherrscht Pure-C diese Optimierung.
Haupt-Problem bei Pure-C ist eigentlich nicht die Code-Optimierung, sondern die Tatsache daß er nur 16bit ints kennt. Das macht es schwer bis fast unmöglich, heutige Programme damit zu benutzen.