atari-home.de - Foren
Software => Coding => Thema gestartet von: Arthur am Di 13.07.2010, 15:10:55
-
Hallo zusammen, ich möchte gerne ein Programm, ähnlich dem E-Nick von maanke, für Mint und TOS Programmieren. Ziel dabei ist es noch mehr Treibereinstellungen und Netzwerkeinstellungen vor nehmen zu können. Für den Anfang reicht mir erst mal eine Version für die Bash und auch TOS, später dann auch als GEM-Version. Hier meine Fragen dazu. Alle gestellten Fragen beziehen sich auf Omikron- und GFA-Basic.
1. Kann man ohne spezielle Bibliotheken schon lange Dateinamen verwenden?
2. Läuft so ein Programm unter Mint als auch TOS?
3. Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?
4. Gibt es schon irgendwo ähnliche Programme die schon als Source verfügbar sind um sich dort einzulesen.
5. Wer kennt Links zu Omikron- und GFA-Seiten für Anfänger wie mich? :)
6. Welche Versionen sollte ich dafür nehmen?
-
1. Kann man ohne spezielle Bibliotheken schon lange Dateinamen verwenden?
2. Läuft so ein Programm unter Mint als auch TOS?
3. Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?
4. Gibt es schon irgendwo ähnliche Programme die schon als Source verfügbar sind um sich dort einzulesen.
5. Wer kennt Links zu Omikron- und GFA-Seiten für Anfänger wie mich? :)
6. Welche Versionen sollte ich dafür nehmen?
alles kann ich nicht beantworten, aber einiges :) (alle Antworten beziehen sich auf Gfa-basic
zu 1: nein, da auch die aktuellste Gfa-Version herauskam, als es gerade den TT gab und Mulittasking-Systeme noch nicht so verbreitet waren
zu 2: ohne Bibliotheken läuft das alles nur in TOS (in den Doks, die jeder Mint-Distri beiligen gibt es einige Hinweise, was beim Prgrammieren zu beachten ist
zu 3: k.A.
zu 4: k.A.
zu 5: http://userpages.bright.net/~gfabasic/
zu 6: Die letzte verfügbare GFA-Basic version ist 3,6TT. Hierzu gibt es inzwischen mehrere Patches und Erweiterungen. Auch unter der Adresse zu 5 findest du einiges.
Der GFA-Original-Editor läuft nicht ohne Probs auf Grakas. Hierzu gibt es die Erweiterung Alacard von Reiner Rosin (http://rosin-datentechnik.de/rosin-online/software.html#tos; Angegben ist Shareware, ob der Autor noch erreichbar ist, bezweifle ich wegen des Alters der Seiten) oder Bastard von Run!-Software (http://www.run-software.de/start.php)
-
1. Kann man ohne spezielle Bibliotheken schon lange Dateinamen verwenden?
Ich glaube nicht, sonst hätte ich diesen (langen) Artikel wohl nicht gefunden: http://run-software.de/tt_lname.php
Aber vielleicht ist das ja garnicht so wichtig, weil in deinem Fall alle Dateipfade kuerzer oder gleich 8 Zeichen sind.
3. Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?
Ich weis, nicht so gerne gesehen, und nur eine Lösung bis Du was besseres hast, aber das könnte so aussehen: (Pseudocode)
if( verzeichnis_vorhanden("/root") )
{
// es ist ein mint system
}
zu 2: ohne Bibliotheken läuft das alles nur in TOS (in den Doks, die jeder Mint-Distri beiligen gibt es einige Hinweise, was beim Prgrammieren zu beachten ist
Wieso denn das? Für mich klingt es so als ob GFA auch unter MiNT loift.
-
"Wer kennt Links zu Omikron- und GFA-Seiten für Anfänger wie mich? "
Mit GFA-Basic habe ich ewig nicht mehr gemacht, da der Falcon sich mit GFA Basic nie wirklich wohl fühlte. Ich helfe aber gern wenn jemand in Omikron.Basic einsteigen will, bin ja der Omikronman. Aber laßt Euch gesagt sein: GEM ist nichts für Anfänger! :-)
-
Bei http://www.rgfsoft.com gibt es auch noch einige Freeware inkl. GFA Sourcen.
U.a. ist dort auch eine Library die Dateifunktionen besitzt die Lange Dateinamen unterstützen. (lglib )
-
zu 2: ohne Bibliotheken läuft das alles nur in TOS (in den Doks, die jeder Mint-Distri beiligen gibt es einige Hinweise, was beim Prgrammieren zu beachten ist
Wieso denn das? Für mich klingt es so als ob GFA auch unter MiNT loift.
na, dass das Programm unter Mint läuft bedeutet ja nicht, dass es von hause aus (also in der Standard-Version) auch Mint-Kompatiblen Code erzeugt. GFA kann ohne entsp. Libs nur nicht Gem-kompatiblen Code erzeugen. Die Verwendung von Line-A wird im Handbuch seinerzeit sogar nich als Verbesserung beschrieben ;) ; dies ist für Gem ein absolutes No-Go.
GFA läuft auch nur mit Mint ohne Memory-Protection sauber. Mit MP müssen diverse Einschränkungen beachtet werden.
Aber in den Mint-Docs steht das alles drin ;)
-
Ich würde GFA Basic nicht mehr nehmen. -.- Besser Omikron.Basic und die GEM-Library rein, dann hast Du zumindest schon mal, was Du brauchst. Ob Du mit GEM-Programmierung klar kommst, ist dann eine andere Frage. Nicht zuletzt lautet das Kapitel eines Buches für den Atari ST: "GEM-Grafik: extrem müde". Der Autor wußte, wovon er sprach!. :-( Das ganze erinnert ein wenig an Neulinge der heutigen Zeit, die gern Programmieren lernen möchten, noch überhaupt keine Ahnung haben und als erstes "Tomb Raider 999" machen wollen...
-
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/ (http://userpages.bright.net/~gfabasic/)
Ferner entwicklen er und diverse andere (Rajah Lone fällt mir ein), damit weiterhin Mintkompatible Software.
-
Das ganze erinnert ein wenig an Neulinge der heutigen Zeit, die gern Programmieren lernen möchten, noch überhaupt keine Ahnung haben und als erstes "Tomb Raider 999" machen wollen...
Naja, für den Anfang reicht ja auch ein Text-Menü, muss ja nicht gleich ein Komplettes GEM Programm sein! :)
-
MIR würde das für den Anfang auch genügen! :-)
-
na, dass das Programm unter Mint läuft bedeutet ja nicht, dass es von hause aus (also in der Standard-Version) auch Mint-Kompatiblen Code erzeugt. GFA kann ohne entsp. Libs nur nicht Gem-kompatiblen Code erzeugen. Die Verwendung von Line-A wird im Handbuch seinerzeit sogar nich als Verbesserung beschrieben ;) ; dies ist für Gem ein absolutes No-Go.
Du bringst da IMHO etwas durcheinander. Line-A und GEM haben erstmal nichts mit FreeMiNT zutun. FreeMiNT ist erstmal nur ein GEMDOS, BIOS und XBIOS Ersatz bzw. Erweiterung. Wobei letzter beiden nur zum Teil.
Line-A sollte auf keinem System genutzt werden, da es nur für bestimmte Grafikauflösungen gedacht ist.
Auch Omikron.Basic benötigt eine Library für GEM. Die ist halt dabei, keine Ahnung wie das bei GFA ist.
3. Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?
Würde ich per Cookie-Abfrage machen. Können wir genauer klären wenn es tatsächlich benötigt wird.
4. Gibt es schon irgendwo ähnliche Programme die schon als Source verfügbar sind um sich dort einzulesen.
Also Sourecode jetzt nicht, aber E-Nick ist in GFA-Basic geschrieben. Kannst Dich ja mal an Marc-Antón Kehr wenden.
Achso, EasyMiNT ist in GFA-Basic geschrieben.
Ob Du mit GEM-Programmierung klar kommst, ist dann eine andere Frage.
Keine Ahnung warum immer so auf GEM herumgetrampelt wird. Das ist auch nicht schlimmer als wenn Arthur jetzt anfängt sich mit dem Thema lange Dateinamen zubeschäftigen.
Gerhard
-
Keine Ahnung warum immer so auf GEM herumgetrampelt wird. Das ist auch nicht schlimmer als wenn Arthur jetzt anfängt sich mit dem Thema lange Dateinamen zubeschäftigen.
Ich habe hier noch ein Data Becker Buch zur GEM Programmierung am Atari ST. Das Buch allein ist doppelt so dick wie das Omikron.Basic Handbuch...
-
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.
-
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/ (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. Die letzte Version von GFA-Basic ist 3.6TT. Dass besagte Leute Patches und Erweiterungen schreiben. ist unbestritten. Aber Support ist das nicht. Eher ein "Machen wir das beste aus den zur Verfügung stehenden Mitteln, weil mit irgendwas muß ja programmiert werden."
GFA-Basic war bis 2002 auf Windows weiterentwickelt worden und deshalb wurde der Quell-Code nie frei. Nach 2002 wurde das Projekt von einer Halb-offiziellen Community weitergeführt, die sich ausdrücklich auch an AtariST-User wendet. In wieweit diese aber über den Quell-Code verfügt ist nicht klar. Seit 2005 gibt es aber auch auf dieser Seite keine sichtbae Aktivität mehr:
Hier einige Links:
http://de.wikipedia.org/wiki/GFA-BASIC (http://de.wikipedia.org/wiki/GFA-BASIC)
http://gfa-basic.liebenstein.de/index.html (http://gfa-basic.liebenstein.de/index.html)
-
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. Für alles weitere sollten Libraries genutzt werden, die für das entsprechende System optimiert sind. Solche finden sich im Mint-Paket.
-
na, dass das Programm unter Mint läuft bedeutet ja nicht, dass es von hause aus (also in der Standard-Version) auch Mint-Kompatiblen Code erzeugt. GFA kann ohne entsp. Libs nur nicht Gem-kompatiblen Code erzeugen. Die Verwendung von Line-A wird im Handbuch seinerzeit sogar nich als Verbesserung beschrieben ;) ; dies ist für Gem ein absolutes No-Go.
Du bringst da IMHO etwas durcheinander. Line-A und GEM haben erstmal nichts mit FreeMiNT zutun. FreeMiNT ist erstmal nur ein GEMDOS, BIOS und XBIOS Ersatz bzw. Erweiterung. Wobei letzter beiden nur zum Teil.
Line-A sollte auf keinem System genutzt werden, da es nur für bestimmte Grafikauflösungen gedacht ist.
Auch Omikron.Basic benötigt eine Library für GEM. Die ist halt dabei, keine Ahnung wie das bei GFA ist.
Gerhard
ich weiß. Ich wollte nur den eklatanten Unterschied zwischen systemnaher und systemunabhängiger Programmierung etwas verdeutlichen. Sorry, wenn das verwirrt hat. Systemunabhängig und damit lauffähig auf allen Tos-Versionen geht nun mal nur über Gem.
-
wer´s mag: Omikron.Basic ist ab Version 5 in GEM eingebunden.
-
Danke für die vielen Informationen die ihr schon gepostet habt. Einige Fragen würden mich noch brennend interessieren:
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?
3. Ich weis das die Antwort auf die Frage schon teilweise gepostet wurde, aber welche Omikron- und GFA-Bibliotheken könnt ihr sonst noch empfehlen? Welche sind gut dokumentiert und evtl. auch sauber programmiert?
4.Benötige ich unbedingt ein Resource Construction Set oder gehts auch ohne? Und wenn ja, welches würdet ihr empfehlen?
-
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.
1. Wer Programmiert eigentlich noch an einem richtigen Atari und wer benutzt dafür eher einen Emulator
Ich nutze den Milan, zum Teil auch MagiC Mac X.
2. Welche Überraschungen oder Besonderheiten sind bei der Verwendung eines Emulators evtl. zu beachten?
Von MagiC PC bekannt, daß er bei bestimmten zugriffen auf den Speicher keine Fehlermeldung bringt. Ein Original stürtzt ab.
MagiC Mac (X) hat zwar einen 020er mit FPU, aber es scheint bei der FPU nicht alle Kommandos drin zu sein bzw. Fehlerhaft.
Ähnliches kann Dir mit jedem Emu passieren. Mit den von Dir genannten habe ich keine Erfahrung.
Benötige ich unbedingt ein Resource Construction Set oder gehts auch ohne? Und wenn ja, welches würdet ihr empfehlen?
Kommt halt darauf an was Du machen willst. Menüzeile und Dialoge würde ich nur damit machen und auch in den Quellcode einbinden sondern immer laden. Damit kann man unterschiedliche Sprachen unterstützen.
Ich perönlich nutze ResourceMaster, wobei ich gerade sehe das die Homepage unten ist. Letzte Version war Freeware.
Gerhard
-
Ach Arthur, Du machst Dir viel zu viele Gedanken. Fang doch einfach mal an! Ich verwende den Stemulator für Omikron.Basic. Mir ist bisher nichts aufgefallen, was ich dabei extra beachten müßte.
-
Ich dachte du hast noch nichts mit GEM und Mint und langen Dateinamen programmiert?
-
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...
-
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/ (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 stimme ssb zu. :-)
-
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.
-
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.
-
Genau! :-)
-
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.
-
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/ (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.
-
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.
-
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) (http://toshyp.atari.org/de/00500b.html#Pdomain) am Anfang des Programms.
Gerhard
-
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
-
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
-
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....
-
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. :-/
-
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. ;)
-
Du willst den Gaul unbedingt von hinten aufzäumen. Viel Glück, Arthur. :-\
-
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.