Omikron und Gfa Basic unter Mint. Was ist zu beachten?!

[Arthur]

Ich dachte du hast noch nichts mit GEM und Mint und langen Dateinamen programmiert?

[Omikronman]

Stimmt, aber wenigstens HABE ich programmiert. Und was ich all programmiert habe, einfach unglaublich! O.o Vielleicht solltest Du einfach mal ganz klein anfangen und Dich dann langsam steigern, denn so kommst am ehesten ans Ziel. Ich wollte früher auch immer alles und noch mehr, übernahm mich viel zu oft und scheiterte daher unzählige Male auf halbem Wege. Was nicht heißen soll, dass die Ansätze nicht gut waren...

[simonsunnyboy]

Käse! GFABASIC wird absolut supported, auch für Mint!

Lonny Pursell hat einen voll in GEM integrierten modernen Editor geschrieben und einen gepatchten Compiler inklusive einer neuen Library mit Bugfixes veröffentlicht.

http://userpages.bright.net/~gfabasic/

Ferner entwicklen er und diverse andere (Rajah Lone fällt mir ein), damit weiterhin Mintkompatible Software.

Das ist absoluter Unsinn.

Das ist kein Unsinn. Heutzutage kannst du nun mal nicht mehr auf komemrziellen Support hoffen. Kommt doch endlich mal bitte in die Realität, in der Atari ein Hobby für 5000 von 6 Milliarden ist.

Und Atari heisst auch keinesfalls jenseits von 68030 - das ist engstirning. Atari heisst in jedem Fall auch all das, was davor war.

[Omikronman]

Ich stimme ssb zu. :-)

[Arthur]

Stimmt, aber wenigstens HABE ich programmiert. Und was ich all programmiert habe, einfach unglaublich! O.o Vielleicht solltest Du einfach mal ganz klein anfangen und Dich dann langsam steigern, denn so kommst am ehesten ans Ziel. Ich wollte früher auch immer alles und noch mehr, übernahm mich viel zu oft und scheiterte daher unzählige Male auf halbem Wege. Was nicht heißen soll, dass die Ansätze nicht gut waren...

Hallo Omikronman, hast ja nicht ganz unrecht. Auch ich habe ja schon das ein oder andere kleine Basicprogramm geschrieben. In 80/20Basic(ASIC) unter DOS. Applesoft Basic auf Apple 2, MSX-Basic auf Sony HitBit und einfachste GFA und Omikron-Basic Programme. Da brauchte ich mich aber nicht um Library's zu kümmern, da ich nur das benutzt habe was in allen Basic's schon vorhanden ist. Allein die Geschichte mit den langen Dateinamen ist schon ne menge arbeit wie es aussieht. Da ist noch kein bisschen GEM drin enthalten. Ich bin also ganz froh das ich erst mal diesbezüglich nach gefragt habe. In Basic scheint mir der Aufwand genau so groß zu sein wie in C.  

[simonsunnyboy]

Nämlich gegen 0, da sämtliche sinnvollen BASIC-Systeme für Atari das GEMDOS benutzen. Unter Mint geht das dann auch ohne besondere Kniffe mit den langen Dateinamen. Mint ersetzt das GEMDOS nämlich nur durch modernere Routinen und flexiblere Dateisystemtreiber.

Wäre dem nicht so, würde die Masse der Programme nicht so einfach laufen.

[Omikronman]

Genau! :-)

[michschmi]

GAFABSIC hat sämtliche offiziellen VDI and AES Aufrufe direkt eingebaut, natürlich auch in den Biblitoheken zum Compiler.

Nichtoffizielel kann man mit PEEK und POKE zur Not Nachrüsten, soltlen aber für die allermeisten Dinge nicht nötig sein.

ja, genau aber optimiert auf max 68030-Prozessoren.

Was genau muß bei Systemaufrufen an den Prozessor angepaßt sein? Da werden doch nur ein Daten auf den Stack gelegt und dann ein Trap aufgerufen.

Für alles weitere sollten Libraries genutzt werden, die für das entsprechende System optimiert sind. Solche finden sich im Mint-Paket.

Und die kann man in GFA-Basic oder Omikron.Basic einbinden? Zudem was nützt Dir wenn die Libraries z.B. für 060 ist der Rest aber nur für 030. Mal von Frage  abgesehen ob das geht.


Gerhard

Ach und warum wurde dann etwa zur Zeit des Autauchens der Clone-Ataris  überall postuliert, dass die systemnahe Programmierung Mist ist, weil inkompatibel zu anderen Systemen/Tos-Versionen und dass nur entsprechende (Gem)-Libraries benutzt werden sollten, um die Programme so sauber wie möglich auf allen möglichen Systemen laufen zu lassen?
Warum haben denn um die Jahrtausendwende einige Leute "wie wild" moderne Programmierbibliotheken entworfen.
Dass nicht immer alle Bibliotheken für alle Zwecke vorliegen, bestreite ich nicht.

Du hast sicher bessere Programmierkenntnisse als ich; schaue dir doch die entsprechenden Aufruf/Programmierhinweise im Mint-Paket an. Dort steht, wie was sinnvoll eingebunden wird.

Es geht doch hier nicht um Grundsätze sondern lediglich darum, die "Gefahren" aufzuzeigen, die Programme in bestimmten System-Umgebungen nicht lauffähig machen könnten.

[michschmi]

Käse! GFABASIC wird absolut supported, auch für Mint!

Lonny Pursell hat einen voll in GEM integrierten modernen Editor geschrieben und einen gepatchten Compiler inklusive einer neuen Library mit Bugfixes veröffentlicht.

http://userpages.bright.net/~gfabasic/

Ferner entwicklen er und diverse andere (Rajah Lone fällt mir ein), damit weiterhin Mintkompatible Software.

Das ist absoluter Unsinn.

Das ist kein Unsinn. Heutzutage kannst du nun mal nicht mehr auf komemrziellen Support hoffen. Kommt doch endlich mal bitte in die Realität, in der Atari ein Hobby für 5000 von 6 Milliarden ist.

Und Atari heisst auch keinesfalls jenseits von 68030 - das ist engstirning. Atari heisst in jedem Fall auch all das, was davor war.

ich untersceide dennoch zwischen Support wie ihn Gerhard Stoll etwa für Phoenix (Datenbank) bietet, wo er die Quellen hat und diese direkt anpassen kann.
Klar ist Binary-Gepatche auch eine Art Support, aber da könnte es dir immer wieder passieren, dass irgendein Rechte-Inhaber dir auf die Finger klopft, wenn du dich "zu weit aus dem Fenster lehnst".

Die Gefahr ist bei GFA zwar inzwischen  0, aber bis 2001/2002 hätte das passieren können, da zu dem Zeitpunkt GFA noch (auf Windows) enwickelt wurde.

[simonsunnyboy]

Wenn ich den 3.6 Compiler mit dem von Lonny diffe, dann gibt es da soviele massive Unterschiede, daß allenfalls Teile 1:1 wiederverwendet wurden.

Davon ab arbeitet er mit einem Hades, wenn seine Programme nicht standardkonform wären, würden sie darauf nicht laufen.

[gstoll]

Ach und warum wurde dann etwa zur Zeit des Autauchens der Clone-Ataris  überall postuliert, dass die systemnahe Programmierung Mist ist, weil inkompatibel zu anderen Systemen/Tos-Versionen und dass nur entsprechende (Gem)-Libraries benutzt werden sollten, um die Programme so sauber wie möglich auf allen möglichen Systemen laufen zu lassen?

Damit hast Du vollkommen recht, ich fürchte nur wir reden an einander vorbei.

Meine Frage war nur ob GFA-Basic eine GEM-Lib hat. Wobei mein Verständnis dafür erstmal ist, daß man alle GEM Systemfunktionen aufrufen kann, ohne irgendwelche Klimzüge wie Assemblerteile oder Peek und Poke.

Was Du meinst sind Libs die einem das Leben leichter machen. Dort benötigt man nur ein Kommando um z.B. einen Dialog zu öffnen. Wer das selbst mit GEM Kommandos macht muß drei oder nutzen.

Mint ersetzt das GEMDOS nämlich nur durch modernere Routinen und flexiblere Dateisystemtreiber.

Ich  setze grundsätzlich noch ein Pdomain(1)  am Anfang des Programms.

Gerhard

[guest2552]

Hallo Arthur,

ein paar (sicher nicht erschöpfende) Antworten auf Deine Fragen im Allgemeinen und Omikron.BASIC betreffend:

Kann man ohne spezielle Bibliotheken schon lange Dateinamen verwenden?

Ab Version 5.13 kann Omikron.BASIC (das heißt der Editor) lange Dateinamen falls das System es unterstützt.
Das BASIC selbst ist unabhängig von langen Dateinamen.
Ob der BASIC-intern aufgerufene Fileselector lange Dateinamen korrekt behandelt weiß ich nicht.
Der Fileselector über die letzte mir bekannte GEM.LIB oder GEM.BAS aufgerufen kann langen Dateinamen nicht korrekt verarbeiten (Dateinamenspeicher nur für 13 Zeichen!) Auch ist diese GEM.LIB nicht besonders Multitaskingtauglich da es die Handles von Fremdfenstern ignoriert und die entspr. AES-Funktionen einfach nicht ausgeführt werden.
Diese 2 Probleme liesen sich jedoch (bei Interesse an der Programmierung über die GEM.LIB) ohne Aufstand lösen.

Läuft so ein Programm unter Mint als auch TOS?

Ja! Aber:
Mir ist kürzlich (recht einfach) eine Installation von MiNT +  XaAES oder MyAES unter Aranym auf Windows gelungen und mußte feststellen, dass nach einigen AES-betreffende kleinen Anpassungen meiner Programme alle sehr stabil liefen (z.Zt. noch ausgenommen der freien Listboxen).
Die grundsätzliche Lauffähigkeit von Omikron.BASIC-Compilaten ist also unter TOS, MiNT, Geneva, XaAES und (naja) MyAES gegeben.
Das Hauptproblem taucht erst auf nachdem ALLE laufenden Omikron.BASIC-Compilate (auch das Omikron.BASIC selber) beendet wurden:
Darauf gestartete Applikationen können beim Start das System zum Totalhänger bringen.
Ich denke dass dies an verbogenen Zeigern des Omikron.BASIC in Zusammenhang mit MiNT liegt, weiß es aber nicht sicher!
Einen ausschließlichen MiNT-Betrieb hab ich noch nie versucht - hier bräuchte ich mal Nachhilfe (Installation, Sinn und Zweck). Zum Aktivieren/Testen von Netzwerken hab ich keinerlei Möglichkeit.

Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?

Ich habe in der OW-DEMO.APP der OM-WINs-Library in einem Textfenster eine textbasierte Mini-Version des Programmes SYSHELP in dem die viele Systemaufrufe und -abfragen in der Sourcedatei ersehen könntest. (Aber bitte nächstes Update abwarten)

zu 4.

zu 5. Für Omikron.BASIC kenne ich auch nur noch Karsten Lüdersens Seiten zur KLib-Library

Welche Versionen sollte ich dafür nehmen?

Omikron.BASIC 3.6 für Single-TOS-Betrieb bei Programmerstellung (leider mit leichten Einschränkungen im Code) oder V5.20 für Multitasking und schnellere Rechner.
Omikron.BASIC selber läuft unter TOS, Geneva, MagiC.
Unter XaAES darf kein Dauerklick (z.B. Blockaufziehen) ausgeführt werden da es zu einer Endlosschleife führt (Fehler in XaAES oder drunterliegendem EmuTOS in der Funktion graf_mkstate() - bei zu hochfrequentem Aufruf wird kein Maustaste-loslassen mehr zurückgemeldet). Zudem muß man mit der Fensterverwaltung (Tokenlisting) vorsichtig sein!
Unter MyAES verschwindet die Menuzeile des Omikron.BASIC sofort wieder und das System hängt!

1. Wer Programmiert eigentlich noch an einem richtigen Atari und wer benutzt dafür eher einen Emulator wie Steem, Hatari oder Stemulator oder gar Aranym dafür?
2. Welche Überraschungen oder Besonderheiten sind bei der Verwendung eines Emulators evtl. zu beachten?

Unter Steem auf dem PC läuft die Sache sehr ordentlich, wie ich bemerkte (hab ich im Frühjahr zum weiteren Testen und Entbuggen von OM-WINs und der Applikationen genutzt!) Allerdings bekomme ich den AUTO-Ordner nicht in Betrieb.
Mit dem Stemulator hatte ich Anfang 2000 keine guten Erfahrungen gemacht. Weitere Updates habe ich nicht mehr versucht.
Hatari kenne ich nicht.

Benötige ich unbedingt ein Resource Construction Set oder gehts auch ohne? Und wenn ja, welches würdet ihr empfehlen?

INTRFACE.PRG: mittlerweile kostenlos, sehr stabil, sauber und kompatibel und keineswegs veraltet!


... und noch ein kleiner Nachtrag zum Mörderposting:
Reine TOS-Programme (sauber in Fenster laufend) sind mit Omikron.BASIC nicht möglich da das BASIC bzw. das Compilat Appl_Init IMMER selbstständig aufruft und vom Programmierer nicht unterbunden werden kann.
Es sind also neben sauberen GEM-Programmen nur Schmuddelprogramme ala TOS oder ein GEM/TOS-Mischmasch möglich.
Als Accessory compliert gibt's meines Wissens auch keine Probleme (Einschränkung: der Accessoryplatz ist weg und es ist keine Menuzeile möglich)

Gruß Charly

[Arthur]

Hallo Charly, hab mir gestern und vorgestern mal deine Seite angeschaut und deine mächtigen Libs für Omikron Basic. Was Du da Programmiert hast ist schon echt riesig. Es scheint wirklich der Wurm in Omikron Basic zu stecken wenn es um das OS MiNT geht. Leider haben dein umfangreichen Infos eher abgeschreckt als ermutigt. Ich möchte eigentlich nur ein wenig Programmieren und mich nicht mehr als nötig um die zahlreichen Bugs in Omikron-Basic oder dem Atari OS TOS und MiNT zu kümmern. Mit Geneva und Magic hab möchte ich mich nicht beschäftigen da es Einbahnstraßen sind die nicht weiter ausgebaut werden. Auf dem Falcon mit NVDI ist auch MiNT für die meisten Zwecke mehr als schnell genug. Ich warte jetzt erst mal den C-Kurs hier im Forum ab. Und nochmals vielen Dank für deine neutrale und ausführliche Antwort zum Omikron Basic.

Gruß Arthur

[m0n0]

Wenn es um Mint geht... also wenn du ein Tool für mint schreiben willst, und es keine GEM-GUI haben muss, dann würde evt. auch eine Script Sprache wie Python angebracht sein,... Damit wird das programmieren auch Wesentlich einfacher!

Nur müsstest du eine Konsolen Gui erstellen... also ohne GEM, denn soweit ich weiss hat das MiNT-Python keine GEM Anbindung.

Eine andere Möglichkeit wäre PERL....

[Omikronman]

Tja Arthur, programmieren heißt auch, Probleme zu lösen. Eine Programmierumgebung für den Atari, die mit all die superexotischen Systemerweiterungen, die in den letzten Jahren aus dem Boden gestampft wurden perfekt umgehen kann, kenne ich nicht. Dafür ist der Atari vermutlich auch schon zu lange tot. Wenn man mit dem Atari unbedingt etwas machen will, wofür er nicht gemacht war darf man sich nicht beklagen, wenn das Probleme bereitet. Niemand hat behauptet, daß programmieren einfach ist. Solange Du Dich aber nicht an die erste Zeile Deines Programms wagen willst, brauchst Du eigentlich gar keine weiteren Fragen stellen, denn Programmieren ist nun mal ein langwieriger Lernprozeß, bei dem man umso besser wird, je mehr Zeit man damit verbringt. Und das bedeutet nunmal, irgend wann los zu legen, auch, wenn manche Fragen erst einmal keine befriedigende Antwort finden.

"Ich möchte eigentlich nur ein wenig Programmieren und mich nicht mehr als nötig um die zahlreichen Bugs in Omikron-Basic oder dem Atari OS TOS kümmern."

Quatsch. Du willst nicht programmieren. In mehr als zehn Jahren Omikron.Basic habe ich keine Bugs bemerkt die Dich, falls Du ernsthaft daran interessiert wärst "eigentlich nur ein wenig zu programmieren", davon ahalten würden, genau das zu tun. Wenn Du Deine ganzen Vorbehalte mal ablegen und einfach loslegen würdest wäre das schon ein guter Schritt nach vorn! Der Atari ist aus einer Zeit als man noch bereit sein mußte, Kompromisse einzugehen. Es gab Leute, die ernsthaft erwarteten, daß ein Spiel wie Crown of Creation im GEM-Fenster laufen können müsse. Das ist definitiv nicht möglich (wer es nicht glauben will: ich sprach seinerzeit mit Rebelsoft darüber). Es kann sein, daß Du irgendwann merkst, daß sich Dinge am Atari möglicherweise nicht oder nur unzureichend in Vereinbarung bringen lassen. Wenn Dir dieser Gedanke Kopfschmerzen bereitet, so mußt Du halt die Idee mit dem Programmieren an den Nagel hängen, auch wenn´s schwer fällt. :-/

[Arthur]

Da kann ich dir zustimmen. Zeit ist nun aber kostbar und was ich hier schon an nützlichen Informationen bekommen habe ist sehr viel Wert für mich. Für TOS, Geneva, Magic würde ich mit dem was ich erfahren habe ohne weiteres zu Omikron-Basic greifen. Das ich aber schon ziemlich genau weis was ich vor habe, werde ich mir auch GFA-Basic noch genauer angucken und evtl. ist das von ssb vorgeschlagene Paket etwas besser geeignet für mich. C wird dadurch allerdings auch immer interessanter für mich, wenn ich da auch bei Null anfangen würde. Eine Scriptsprache wie Python möchte ich nicht benutzen und ich wüßte auch nicht weshalb denn gerade Python und nicht eine der zig anderen Scriptsprachen? Nein, das thema Scriptsprachen ist für mich eher uninteressant. Ich hab auch lust was durch einen Compiler zu jagen und dann ein richtiges Programm zu haben. 

[Omikronman]

Du willst den Gaul unbedingt von hinten aufzäumen. Viel Glück, Arthur. 

[simonsunnyboy]

Mal ganz konkret: was hast Du bisher schon programmiert? Wenn Du noch keine zusammenhängenden Programme geschrieben hast, die wirklich eine größere zusammanhängende Aufgabe lösen (mehr als 2+2=4), dann fang NICHT mit C an. Das wird dir den Spaß nur vermiesen.

Python ist übrigens von der Idee her ein guter Vorschlag zum generellen Einstieg in die Programmierung.

Die Kunst beim Programmieren besteht nicht darin, Mint besonders toll zu nutzen, sondern zu abstrahieren und zu kombinieren. Ohne die beiden letzteren Aspekte würde keine moderne Software laufen.