GEM Applikation erstellen

[Arne]

Für das Testkit möchte ich mir eine GEM Applikation erstellen, mit der ich verschiedene 64KB und 128KB Images in ein array lade, dies auch an verschiedene Stellen des arrays. Dann die Endianess ändern und sich den Arrayinhalt wie in einem Hexmonitor ansehen. Und am Ende alles in eine 512kB große Datei speichern.
Nun habe ich früher nie GEM Applikationen erstellt, sondern vor 20 Jahren mit GFA Basic eher wild im Bildschirmspeicher rumgepokt (PRINT).
Realisieren möchte ich das Programm in Pure C, aber mit welchen Hilfsmitteln realisiere ich die GUI?
ACS 2 hab ich hier rumliegen, dann gibt es noch ResourceMaster, Interface.
C ist kein Thema, lediglich GEM.
Was muss ich alles beachten, damit es MagiC/MiNT konform wird? Gibt es da Tutorials zu?

ciao, Arne

[Omikronman]

Ein Programm in GEM einbinden ist der reinste Horror. Das Omikron.Basic Handbuch hat 192 Seiten. Darin sind alle Basic Befehle ausführlch beschrieben. "Das große GEM-Buch zum ATARI ST" von Data Becker hat 460(!) Seiten und befaßt sich nur mit GEM...

[mfro]

Realisieren möchte ich das Programm in Pure C, aber mit welchen Hilfsmitteln realisiere ich die GUI?

Hallo Arne,

so fürchterlich schwierig ist das nicht, wenn Du C beherrschst.

Am besten fängst Du mit einem möglichst einfachen Beispiel an. Bei Pure C - wenn Du das Original hast - sind einige simple Programmbeispiele im Quellcode dabei, die sich als Startpunkt eignen.

Damit würde ich an deiner Stelle anfangen.

Damit läßt sich das (wahrscheinlich am Anfang etwas gewöhnungsbedürftige) ereignisgesteuerte Programmieren von GEM relativ einfach nachvollziehen.

Gruß,
Markus

[Arne]

Salut,

hatte mir eigentlich ein paar Hinweise auf nützliche Tools erhofft, aber evtl. habe ich mich auch unklar ausgedrückt. Ich starte jetzt mit Pure C und ACS 2. Mal sehen, wie weit ich komme.

so fürchterlich schwierig ist das nicht, wenn Du C beherrschst.

Mache ich seit +10 Jahren (werk-)täglich in der Firma (embedded Bereich).

(...) (wahrscheinlich am Anfang etwas gewöhnungsbedürftige) ereignisgesteuerte Programmieren (...)

Ist in Delphi auch so. Der Unterschied zu Turbo Pascal ist mir durchaus bewusst. 
Daher (präemptives Multitasking bei Win32) auch meine Frage, was es bzgl. MagiC, MiNT zu beachten gäbe.
ACS2 Anwendungen sollen ja per se damit klar kommen. Ich probiers einfach.

ciao und Danke, Arne

[mfro]

Ich probiers einfach

Guter Ansatz .

Halte ich persönlich für die zunächst beste Methode, GEM zu verstehen. Bei Problemen einfach fragen...

[neualtuser]

moin

Könnte "Vom Anfänger zum GEM-Profi" mit Diskette anbieten, Leihweise   watt fürn Wälzer  , keine Ahnung von

[mfro]

moin

Könnte "Vom Anfänger zum GEM-Profi" mit Diskette anbieten, Leihweise   watt fürn Wälzer  , keine Ahnung von

Ich habe das Buch seit Ewigkeiten, aber noch nie auf die Diskette geguckt (damals schon kurz nach dem Auspacken mit dem Schreibtischstuhl drüber gerollt, was ihr den Garaus gemacht hat). Meinst Du, Du könntest mir da eine Kopie machen?

Wäre sehr nett und würde mich freuen, dann wäre nach Jahrzehnten wieder alles komplett

[Arne]

Also ein paar Fragen habe ich zu AES/GEMDOS jetzt schon:

• wenn in einer Dialogbox eine Checkbox markiert wird, wird dann vom AES sofort eine Nachricht abgesetzt, die mir dies signalisiert? Oder erst wenn die Dialogbox mit einem Button geschlossen wird?
• wie komme ich an die Dateigröße eines Files? Ich dachte an Fopen() und dann Fgetdta() - in der DTA steht m.W. ja die Dateigröße drin.
• gibt es in GEM bereits sowas wie einen ProgressBar, der also den Fortschritt einer Aktion darstellt? Wie z.B. in Kobold bei einer Kopieraktion.
  Falls nicht, mache ich das dann über das VDI selbst (gefüllte Box) oder gibt es da was eleganteres?

Habe gestern Abend mit ACS Pro 2 angefangen... ist das alles eng auf dem 12" 
thanx, Arne

[mfro]

Also ein paar Fragen habe ich zu AES/GEMDOS jetzt schon:

• wenn in einer Dialogbox eine Checkbox markiert wird, wird dann vom AES sofort eine Nachricht abgesetzt, die mir dies signalisiert? Oder erst wenn die Dialogbox mit einem Button geschlossen wird?

Geht beides. Der Normalfall ist folgender: der form_do()-Funktionsaufruf malt die Dialogbox auf den Schirm und kehrt erst wieder zurück, wenn "OK" oder "Abbruch" gedrückt wurde. Man kann (in der Resourcedatei oder im Programm) bei einzelnen Dialogbox-Elementen aber auch das "TOUCHEXIT"-Flag setzen, dann kehrt die Funktion sofort zurück, wenn dort der linke Mausknopf gedrückt wird.

Allerdings: keine Routine der form_xxx() (Dialogbox-Verarbeitungsroutinen) arbeitet mit AES-Events. Die standardmäßigen Dialogboxroutinen im GEM blockieren die Eventverarbeitung, bis die Dialogbox geschlossen wurde. Umgehen läßt sich das mit Fensterdialogen (selbstgebastelt oder aus irgendeiner Library unter Verwendung der wind_xxx() Funktionen und Fensterereignissen).

• wie komme ich an die Dateigröße eines Files? Ich dachte an Fopen() und dann Fgetdta() - in der DTA steht m.W. ja die Dateigröße drin.

Es mag sogar sein, daß nach einem Fopen() in der DTA tatsächlich die Dateilänge steht (schließlich muß auch das Betriebssystem erst nach der Datei schauen, bevor es sie öffnen kann) - das wäre aber ein undokumentierter Seiteneffekt, auf den ich mich nicht verlassen würde.
Grundsätzlich gibt es zwei Möglichkeiten, die Länge einer Datei zu erfahren:

• Fopen() auf die Datei
  amschließend Fseek() ans Dateiende, als Rückgabewert erhält man die Dateizeigerposition.
  Bevor man aus der Datei lesen kann, muß man natürlich den Zeiger wieder nach vorne setzen.
• Fsetdta() um eine eigene DTA zu setzen (die vorbelegte zeigt mitten in die Kommandozeile),
  Fsfirst() auf den Dateinamen, in der DTA steht anschließend die Dateigröße

• gibt es in GEM bereits sowas wie einen ProgressBar, der also den Fortschritt einer Aktion darstellt? Wie z.B. in Kobold bei einer Kopieraktion.
  Falls nicht, mache ich das dann über das VDI selbst (gefüllte Box) oder gibt es da was eleganteres?

GEM kennt keine ProgressBar. Entweder selber malen über's VDI oder (m.E. einfacher und eleganter) mit den objc_xxx()-Funktionen. Dazu (in der Resourcedatei oder programmtechnisch) zwei G_BOX-Objekte definieren (eine BOX in der anderen), das Element ob_width der inneren entsprechend des Fortschritts verändern und den Objektbaum mit objc_draw() neu malen.

Gruß,
Markus

[Arne]

Danke Markus für die ausführliche Antwort.
Ergo muss ich das Programm minimal anders aufbauen, als gedacht.

Ist es möglich in TOS die Eingabe eines Edit-Feldes auf hexadezimale Ziffern zu begrenzen? Bei Geneva soll das gehen, aber bei plain TOS?
Oder muss ich erstmal alles zulassen und nach Verlassen der Dialogbox prüfen?

thanx, Arne

[mfro]

Ist es möglich in TOS die Eingabe eines Edit-Feldes auf hexadezimale Ziffern zu begrenzen? Bei Geneva soll das gehen, aber bei plain TOS?

Leider nicht. Man kann ein eigenes objc_edit()  in ein eigenes form_do() basteln (wie das geht, steht - zumindest so ungefähr - im Atari-Profibuch, aber das wär' dann doch etwas "heavy" für den Anfang.

[Arne]

Hab jetzt Menüleiste und Dialogboxen in ACSPro 2 angelegt, lasse mir den Code durch ACS erzeugen. In meiner .c habe ich ACSinit, ACSterm und die Create Routine für das Fenster/Desktop. Pure C baut mir alles schön. Wenn ich das PRG aufrufe kommt "TOS Error #35" was wohl auf ein defektes Compilat hindeutet... Bin momentan ratlos.

[mfro]

Hab jetzt Menüleiste und Dialogboxen in ACSPro 2 angelegt, lasse mir den Code durch ACS erzeugen. In meiner .c habe ich ACSinit, ACSterm und die Create Routine für das Fenster/Desktop. Pure C baut mir alles schön. Wenn ich das PRG aufrufe kommt "TOS Error #35" was wohl auf ein defektes Compilat hindeutet... Bin momentan ratlos.

Kannst Du mal die Pure-C Projektdatei posten?

[Arne]

Code: [Auswählen]

ROMEDIT.PRG
=
PCSTART.O      ; alternativ ACS_LOAD.O
ROMEDIT.C
ACS.LIB
ACSPLUS.LIB
PCSTDLIB.LIB
PCTOSLIB.LIB
PCGEMLIB.LIB
PCLNALIB.LIB

Weder mit PCSTART.O noch mit ACS_LOAD.O gehts. Beide bringen den #35 Fehler.

[mfro]

Code: [Auswählen]

ROMEDIT.PRG
=
PCSTART.O      ; alternativ ACS_LOAD.O
ROMEDIT.C
ACS.LIB
ACSPLUS.LIB
PCSTDLIB.LIB
PCTOSLIB.LIB
PCGEMLIB.LIB
PCLNALIB.LIB

Weder mit PCSTART.O noch mit ACS_LOAD.O gehts. Beide bringen den #35 Fehler.

Ich kann da keine Fehler erkennen. Läuft ein einfacher Dreizeiler?

[Arne]

Ich kann da keine Fehler erkennen. Läuft ein einfacher Dreizeiler?

Hmmm... ich glaube da hast Du was gefunden: Ein Hello world terminiert auch mit dem #35.

Code: [Auswählen]

#include <stdio.h>

extern int main(int argc, char* argv)
{
printf("Hello world!\n");
return 0;
}
Kommen halt zwei Warnings, daß argc und argv nicht genutzt werden... aber sonst: TOS Error #35.

Deutet das darauf hin, dass PCSTART.O und/oder die Libs defekt sind?
Habe PC von den drei Originaldisks problemlos installieren können und dann die beiden Update 1.1 Disks drüberinstalliert.

[mfro]

Ich kann da keine Fehler erkennen. Läuft ein einfacher Dreizeiler?

Hmmm... ich glaube da hast Du was gefunden: Ein Hello world terminiert auch mit dem #35.

Code: [Auswählen]

#include <stdio.h>

extern int main(int argc, char* argv)
{
printf("Hello world!\n");
return 0;
}
Kommen halt zwei Warnings, daß argc und argv nicht genutzt werden... aber sonst: TOS Error #35.

Deutet das darauf hin, dass PCSTART.O und/oder die Libs defekt sind?
Habe PC von den drei Originaldisks problemlos installieren können und dann die beiden Update 1.1 Disks drüberinstalliert.

Wie sehen denn deine Compiler-/Linkereinstellungen aus? Compilierst Du vielleicht für einen Prozessor, den Du gar nicht hast?

Ansonsten würde ich behaupten: Lib oder Startupcode defekt.

[Arne]

Ich hatte im Linker -J (Create new object file) mit drin. Ohne dieses läuft das "Hello world" PRG nun.
Im meinem ROMEDIT Projekt habe ich es auch drin. Da nutze ich die GEMDOS Funktionen Malloc() und Mfree().
Ohne -J kam gestern für jedes Malloc/Mfree ein Linkerfehler... irgendwas mit INT16 und PC-relativ. Krieg diesen Fehler aber nicht mehr hin.
Jetzt habe ich ACS_LOAD.O mit drin. Mit -J kommt der #35, ohne -J kommt ein Linkerfehler "Undefined symbol '_BasPag'".

[mfro]

Ich hatte im Linker -J (Create new object file) mit drin. Ohne dieses läuft das "Hello world" PRG nun.
Im meinem ROMEDIT Projekt habe ich es auch drin. Da nutze ich die GEMDOS Funktionen Malloc() und Mfree().
Ohne -J kam gestern für jedes Malloc/Mfree ein Linkerfehler... irgendwas mit INT16 und PC-relativ. Krieg diesen Fehler aber nicht mehr hin.
Jetzt habe ich ACS_LOAD.O mit drin. Mit -J kommt der #35, ohne -J kommt ein Linkerfehler "Undefined symbol '_BasPag'".

Hmmm. Das -J sorgt eigentlich dafür, daß Du das "neue" Pure-C Objektfile-Format verwendest (soweit ich mich erinnere, habe ich das immer benutzt, weil es für den Pure Debugger Voraussetzung ist). Jetzt weiß ich nicht mehr, ob der Linker in der Lage war "altes" und "neues" Objektformat zusammenzulinken. Hast Du möglicherweise einen Mischmasch aus "alten" und "neuen" Objektformaten?

Die Fehlermeldung "PC-relativ" spricht eigentlich dafür, daß eines Deiner Objektfiles eben das ist: PC relativ. Sprünge gehen da nur 16-bit weit und beim Linken war eins der Objekte wohl "zu weit weg".

Wenn eins der Objekte über ein fehlendes _BasPag meckert, hast Du entweder pcstart.o nicht mit dazugelinkt oder eine falsche Reihenfolge.

[Arne]

Habe jetzt im PRJ PCSTART.O statt ACS_LOAD.O drin und gebe wegen den 16bit Sprüngen nun im Compiler -P "Use absolute calls".
Nun funktionierts  Danke!

Leider schmiert ACS 2 unter STeem mit drei Bomben ab. Selbst bei moderaten Einstellungen (640x400x1, 8MHz, 4MB, TOS 2.06)
Auf meinem MST4, TOS2.06, 8MHz läufts.