Julian Reschkes „FlyDials“ gesucht

[Thorsten Otto]

1) Der Pfad zum Include-Verzeichnis kann in Pure-C konfiguriert werden.

Ja, schon klar. Hilft aber nicht, wenn <flydial\flydial.h> gesucht wird, die Datei aber in <include\flydial.h> steht.

2) typedef BYTE: Ok; seltsam, dass es bei mir funktoniert. Bitte PR auf Github.

Ich schätze mal, daß deine portab.h  eine komplett andere als die  vom original Pure-C ist (vermutlich angepasst an PC-GEM). xrsrc.h z.B. scheint auch zu erwarten, daß dort GLOBAL, EXTERN, FAR, GEMDOS, GEM etc.  entsprechend definiert sind.

3) mupfel-tools: müsste ich suchen.

Wäre grossartig, der Vollständigkeit halber. Wie gesagt, einige kann man vermutlich auch durch die mint-binaries ersetzen (date z.B), einige andere sind eh auch in gemini eingebaut (cp, mv). Gibt aber auch welche die Atari-spezifisch sind und vermutlich nirgendwo anders zu finden sind (runopts zb).

4) Gemini 2: war das Kompilieren trivial

Geht so, siehe oben. Hauptproblem war die portab.h, und damit xrsrc.[ch]. In ls.c musste ich auch noch ein paar Sachen ändern (S_ISDIR etc. sind original weder in tos.h noch in ext.h definiert). Gross getestet habe ich bisher auch noch nicht, nur gesehen daß sich sowohl Gemini als auch die standalone-mupfel kompilieren lassen. Möglich, daß ich noch ein paar Fallstricke übersehen habe.

willst Du ein README beisteuern?

Ich habs jetzt erstmal in meinem fork hochgeladen (https://github.com/th-otto/gemini2).

BTW, es würde auch noch Sourcen für die exec_obj.lib fehlen (Interface zu Kobold). Falls du die nicht finden kannst, kann man die auch rekonstruieren (ist nicht besonders gross).

[reschke]

Ich schätze mal, daß deine portab.h  eine komplett andere als die  vom original Pure-C ist (vermutlich angepasst an PC-GEM). xrsrc.h z.B. scheint auch zu erwarten, daß dort GLOBAL, EXTERN, FAR, GEMDOS, GEM etc.  entsprechend definiert sind.

Den PC-GEM-Support können wir eigentlich entfernen; kannst Du mir die ursprüngliche portab.h irgendwo hinlegen?

Sourcen für die exec_obj.lib fehlen (Interface zu Kobold)

Ich glaube nicht, dass "wir" die je im Source hatten -- müsste man Hansi Reichstein (der war es doch, oder?) finden.

[Thorsten Otto]

Den PC-GEM-Support können wir eigentlich entfernen;

Ja, macht für xrsrc.c eh keinen Sinn, das ist eh Atari-spezifisch. Das hat bei den Gemini 1.2-Sourcen und in diversen anderen Projekten auch schon für Probleme gesorgt.
<portab.h> wurde allerdings auch ursprünglich in hello.rh eingebunden; dort habe ich es jetzt erstmal manuell entfernt (was ein bisschen unschön ist, weil das überschrieben wird wenn man sie mit dem Resource-Editor neu erzeugt).

kannst Du mir die ursprüngliche portab.h irgendwo hinlegen?

Die ist recht simple:

Code: [Auswählen]

/*      PORTAB.H

        For use with rsh output of RCS

        Copyright (c) Borland International 1990
        All Rights Reserved.
*/


#if !defined( __PORTAB__ )
#define __PORTAB__

typedef          void    VOID;
typedef          char    BYTE;
typedef          int     WORD;
typedef          long    LONG;
typedef unsigned char    UBYTE;
typedef unsigned int     UWORD;
typedef unsigned long    ULONG;

#endif

/***********************************************************************/


Ich glaube nicht, dass "wir" die je im Source hatten

Dann mach ich mich mal an die Arbeit

PS.: ich kann die Änderungen auch als PR für euer repo zur Verfügung stellen wenn dir das lieber ist, allerdings ist der erste commit recht umfangreich (ohne daß sich wirklich viel geändert hat), weil ich erstmal alle Dateien umbenannt habe, da sie bei mir in einem Verzeichnis auf dem linux-host liegen.

[reschke]

Bitte eine minimale PR :-)

Die Großbuchstaben habe ich aus nostalgischen Gründen dringelassen.

[Thorsten Otto]

Bitte eine minimale PR :-)

Das wird schwierig, wenn ich die Dateien nicht umbenennen soll, weil die folgenden Änderungen ja darauf aufbauen. Wenn du das aus nostalgischen Gründen nicht magst, kann ich das verstehen, aber für meine Arbeitsumgebung ist das notwendig, weil ich sonst die Dateien nach Änderungen doppelt habe, einmal klein, einmal gross.

Vlt. hilft es dir ja erstmal nachzuvollziehen, was ich in https://github.com/th-otto/gemini2/commit/ddd5715e8668d09c500556aec647113929366398 geändert habe.


PS.: die sourcen scheinen tatächlich "der neueste ****" zu sein:

Code: [Auswählen]

$ grep sccsid FlyDials/src/handle.c
static char sccsid[] = "@(#)Fliegende Dialoge 0.57, Copyright (c) "

$ strings gemini.app | grep Fliegende
@(#)Fliegende Dialoge 0.48, Copyright (c) Julian F. Reschke, Jan 15 1995


[reschke]

...zunächst ging's mir um die FlyDials...

[goetz @ 3rz]

Bitte eine minimale PR :-)

Das wird schwierig, wenn ich die Dateien nicht umbenennen soll, weil die folgenden Änderungen ja darauf aufbauen. Wenn du das aus nostalgischen Gründen nicht magst, kann ich das verstehen, aber für meine Arbeitsumgebung ist das notwendig, weil ich sonst die Dateien nach Änderungen doppelt habe, einmal klein, einmal gross.

Und wenn du ein FAT16-Image loop-mountest, und darin die Gemini-Sourcen compilierst? Damit kommt Linux klar, und Hatari & GEMDOS-Emulation legen (weil es nicht anders geht) keine anderen „Schreibweisen“ der Dateinamen in klein an.

[Thorsten Otto]

Das wäre noch umständlicher. Dann müsste ich die Dateien ja jedesmal hin- und her kopieren, das .git Verzeichnis und alles was darin ist muss  ja klein bleiben, und hat auch zu lange Dateinamen.

[goetz @ 3rz]

Das wäre noch umständlicher. Dann müsste ich die Dateien ja jedesmal hin- und her kopieren, das .git Verzeichnis und alles was darin ist muss  ja klein bleiben, und hat auch zu lange Dateinamen.

Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben

[Thorsten Otto]

Wer sagt daß ich Hatari dafür benutze?

[czietz]

Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben

Ähm, ist das nicht das Szenario, wofür...

--gemdos-case <x>

Specify whether new dir/filenames are forced to be in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default

... da ist?

[Thorsten Otto]

exec_job.c ist nun fertig (siehe https://github.com/th-otto/gemini2/commit/371e227c511e588c13491679907691ea185ab402)

Es gibt dort allerdings ein paar Fallstricke:

- Bei der Prüfung auf die AES version wird dort auf _GemParBlk[5] zugegriffen. In der original aes.h von Pure-C fängt die Struktur mit int contrl[15] an, danach kommt dann das global array. Ich kann mir das nur so erklären daß der Source mit den Headern einer anderen Library übersetzt wurde. Betrifft allerdings nur MiNT, MagX wird vorher abgefragt.
- Beim überprüfen des Pfades von kobold_2.prg wird die DTA der Applikation auf einen privaten Bereich gesetzt, aber hinterher nicht auf den alten Wert zurück gesetzt.
- Wenn auf Antwort von Kobold gewartet wird, wird dies in einer evnt_mesag() Schleife gemacht. Andere messages die für die Applikation gedacht waren gehen dabei verloren. Es ist dort auch kein timeout vorgesehen, wenn Kobold nicht antwortet, hängt auch Gemini.
- sämtliche Variablen dort sollten eigentlich als static deklariert werden, um zu vermeiden daß sie mit der Applikation kollidieren.
- in der lokalen search_cookie Funktion ist ein Fehler der zum crash führen dürfte, wenn kein cookiejar vorhanden ist.

[goetz @ 3rz]

Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben

Ähm, ist das nicht das Szenario, wofür...

--gemdos-case <x>

Specify whether new dir/filenames are forced to be in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default

... da ist?

Da guck, danke. (Ich habe das Problem nicht, daher nie zu lösen versucht).

[Thorsten Otto]

@reschke: kann es sein, daß dort noch Ersatzroutinen für malloc() etc. fehlen? Zumindest in der gemini version 1.a (die wohl letzte offiziell verfügbare) wird in AddApplRule, wo malloc() im Source steht, die folgende routine aufgerufen:

Code: [Auswählen]

[0001045c] 4eb9 0005 913e            jsr        malloc

malloc:
[0005913e] 2079 0006 b648            movea.l    $0006B648,a0
[00059144] 4eb9 0005 8c1e            jsr        umalloc
[0005914a] 4e75                      rts

umalloc:
[00058c1e] 6100 fd66                 bsr        mymalloc
[00058c22] 4e75                      rts

Das sieht mir überhaupt nicht nach der malloc() Routine aus pcstdlib aus.

Edit: args, vergiss es. Ist ja da, in myalloc.

[reschke]

FWIW:

ich habe diese Sourcen seit 30 Jahren nicht angesehen, und das Meiste ist ja nicht von mir :-)

[Thorsten Otto]

Schon klar

Ich hoffe es stört dich trotzdem nicht, wenn ich Fragen stelle, sollten noch welche auftauchen. Wenn du sie nicht beantworten kannst, dann ist das halt so.

[Thorsten Otto]

Falls es interessiert: ich habe jetzt in meinem repo auch scripts hinzugefügt, die automatisch auf github die binaries erzeugen.

Verwendet habe ich dazu crosstos (https://github.com/th-otto/crosstos) und pcmake (https://github.com/th-otto/pcmake). Ausserdem benutzt es die originalen  Pure-C Header und libraries (portab.h ist u.A. jetzt auch dort zu finden).

Crosstos ist nicht ursprünglich von mir, aber ich habe ein paar Änderungen vorgenommen, um Parameter per ARGV zu unterstützen (wird definitiv für pclink benötig, weil die Kommandozeile dort in der Regel die 126 Zeichen überschreitet). crosstos benutzt den Musashi 68000 emulator, und erzeugt binaries die die ursprünglichen Atari programme (pcc.ttp, plink.ttp) etc. eingebaut haben. Ausserdem emuliert er teilweise gemdos calls (nicht perfekt, aber zum Aufruf der Kommandozeilen-Version reicht es).

pcmake is ein utility daß ich vor einiger Zeit geschrieben habe, daß einfach ein Pure-C Project-File parsed und compiler, assembler, und linker mit den entsprechenden Option aufruft.

Jetzt muss ich nur noch rausfinden, warum m68k-atari-tos-pc-pcc.tpp beim übersetzen von mupfel.c hängt. Seltsamerweise funktioniert es, wenn ich es erst mit cpp.ttp behandel, und dann das mit pcc übersetze. Das passiert auch nur mit den crosstos-binaries. Direkt auf einem Atari ausgeführt (auch mit einem Emulator) funktioniert es.