[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

Ich könnte mir das mal ansehen, aber versprechen kann ich nichts. Geht nur, wenn ich die Zeit dafür übrig hab.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

So, ich habs mir nun mal angesehen. Das kann etwas dauern, weil da
die BGUI.library verwendet wird, da muß ich mir jetzt mal fix die
Includes für besorgen und ein paar Einfügungen in die FM-Sourcen machen.

Gott sei Dank hat der mit dem phxass gearbeitet bei den Assembler-Teilen,
sonst wärs aufwändig geworden.

Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen
kann.

Grüße


Nachtrag: Da bekommt man richtig Spaß mit, habe ich gerade bemerkt. Zirkelbezüge in den Includes, Parameterübergabe in Registern, ohne Rücksicht auf fremde Compiler... spaßiges Ding Geh mal ruhig von mindestens einer Woche aus, weil ich zusätzlich die Includes etwas umzimmern muß, um die Zirkelbezüge da raus zu kriegen.

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 15.08.2005 um 15:29 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

>Also, wird noch ein paar Tage dauern, bevor man das mit
>dem GCC übersetzen kann.


und GCC bekommt man aber im Internet?


>Nachtrag: Da bekommt man richtig Spaß mit, habe ich gerade
>bemerkt. Zirkelbezüge in den Includes, Parameterübergabe
>in Registern, ohne Rücksicht auf fremde Compiler...
>spaßiges Ding Geh mal ruhig von mindestens einer Woche
>aus, weil ich zusätzlich die Includes etwas umzimmern muß,
>um die Zirkelbezüge da raus zu kriegen.

Ist nicht sauber programmiert, aber von der Geschwindigkeit
und Funktionalität sehr gut.
Ich hab Zeit, das ist kein problem.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

MaikG:
und GCC bekommt man aber im Internet?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

---

Es wäre nett, wenn man die Quellen danach immernoch mit SAS/C übersetzen kann.

---

Ich gebe mir alle erdenkliche Mühe

Leider kann ich das nicht direkt überprüfen, weil ich den SAS selbst nicht habe. Könntest Du das dann erledigen? Normalerweise sollte es da keinen Streß geben, die register __...-Klamotten erschlage ich korrekt mit #defines bzw. überlege noch, ob ich da nicht besser sdi für einsetze.

Alles andere ist nur Fleißarbeit, dutzendfache #include rausschmeißen, unsinnige Vorwärtsdeklarationen, fehlende void etc. pp...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

@whose:

Nimm SDI damit wird es sauber und übersichtlich.

Wenn Du alles selber machst, ist das nur unnütze Arbeit und mit SDI bist Du OS und Compiler unabhängig.

Sie es mal so, wenn man nach dem Umsetzen automatisch ein neues OS nativ beglücken kann, ist das doch eine feine Sache!

Geit

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von geit:
@whose:

Nimm SDI damit wird es sauber und übersichtlich.

---

So dachte ich mir das jedenfalls

Zitat:

---

Sie es mal so, wenn man nach dem Umsetzen automatisch ein neues OS nativ beglücken kann, ist das doch eine feine Sache!

---

Ganz so trivial ist das im Fall von Filemaster leider nicht, mir sind jetzt schon ein paar Stellen im Source begegnet, wo übelst getrickst wird und die unter OS4/MOS mit Sicherheit Ärger machen. Aber das kann man ja später noch bereinigen, wenn gewünscht.

Vorerst gehts darum, daß Teil "halbwegs sauber" durch den GCC und alle anderen Compiler zu bekommen, dann kommen die Hits an die Reihe.

Irgendwann vielleicht dann auch Ports/Anpassungen auf OS4/MOS, wenn jemand Lust dazu hat...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 15.08.2005 um 19:34 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Willst du die Hits auch gleich mit weck machen?
Cool.

---

Zitat:

---

Beim Bildanzeiger wird z.B. "getrickst" da wird die
ModeID von der Datei geöffnet, nur wenn das ein Grafikkarten
Screen ist wird kein Bild gezeichnet. FM macht das nur
mit Amiga-Screens.

---

Ja, das isn "toller" Trick, den habe ich auch schon gesehen

Ich denke, die Funktion kann man dann noch, wenn die Grundlagen "erschlagen" sind, in Angriff nehmen. Die hängt nämlich nicht mit gar so vielen Modulen zusammen wie der Rest des Quellcodes.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Zumindest in so weit, wie es der Code überhaupt zuläßt.
>So tief bin ich noch nicht drin, um definitiv sagen zu
>können, daß alle Hits relativ einfach zu kriegen sind
>(soll heißen: Ohne massiven Umbau der Quellen).


Ein Hit weniger ist schon besser als nichts.

Cyberguard hat öfters etwas mit ReadLong 0000008
angezeigt.

Also in Basic vielleicht der Fehler:
inbuf&=Allocmem...

.
.
.


a&=Peekl ibuf&+8

---

Ja, sowas taucht da im Quellcode auch dann und wann mal auf, sollte aber keinen Hit erzeugen (obwohl... "Sag niemals nie" ).

Wird aber noch etwas dauern, die programmeigenen Includes sind schon ne Lustbarkeit für sich... aber nimmer lang, und das Ganze ist entrümpelt und halbwegs sauber organisiert. Dann kommt der erste Compilerlauf. Und damit evtl. das böse Erwachen

Scherz Das Ganze ist allerdings alles andere als sauber implementiert, kann also noch unvorhergesehene Probleme mit sich bringen. Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte? Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen. Trotzdem verstehe ich den Sinn dabei nicht, einen Zeiger explizit in einem ULONG unterzubringen, statt getrennt Versionen für 68000 und 020+ zu compilieren...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Solar:
Eine ziemlich dösige Angewohnheit mancher Progger, Zeiger und Integers lustig hin- und herzuwandeln. Ich wäre auch dran interessiert zu erfahren, was die Leute da reitet...

---

Hm, vielleicht sollte ich mir mal Informationen zu den SAS-C-Optionen besorgen... ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht. Vor allem taucht dieser Cast nicht überall dort auf, wo die angesprochene Funktion verwendet wird (Projektsuche in StormC ist wirklich eine feine Sache ). Das muß einen Grund haben...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Es gab ja 2 Versionen für 000 und für 020 kann auch
sein das es nur mit Compiler Optionen gemacht wurde.

---

Das sowieso. Naja, ich werd schon noch herausfinden, was sich der Autor bei allem gedacht hat

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

---

Das ist kein MS-DOS.

---

Hmpf!

Man möge mir diese Schludrigkeit nachsehen, hier nochmal die korrekten Ausdrücke:

...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

Ist das jetzt immer noch zu ungenau? Falls ja, bitte das Compilerhandbuch bzgl. der entsprechenden Benennungen der jeweiligen Compileroptionen konsultieren und statt meines Textes einsetzen. Danke.


So kann's gehen, wenn man's eilig hat, grummel...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 19.08.2005 um 11:55 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Zirkelbezüge in den Includes

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte?

---

Zitat:

---

Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Zirkelbezüge in den Includes

---

Das ist doch einfach: den Headern fehlt "#ifndefn#define...#endif".
Strukturen vor Prototypes + Forwards und gut.

---

Ich weiß... das habe ich inzwischen schon erledigt. Bei der Gelegenheit, dachte ich mir, könnte man ja auch gleich diverse Mehrfach-Deklarationen und Vorwärtsdeklarationen einiger Strukturen (die sich fast ausschließlich in den .c-Dateien finden) beseitigen und da einzeln unterbringen, wo sie (zumindest meiner Ansicht nach) hingehören (in ggf. zusätzlichen Headern, brav in #ifndef...#define...#endif verpackt).

Dann sehen die .c-Dateien gleich viel aufgeräumter aus, finde ich.

Über die eigentliche Struktur des Projektes kann man sich ja später immer noch Gedanken machen und eine Änderung fällt dann doch um einiges leichter, wenn man nicht ständig das gesamte Projekt nach diversen Forwards durchsuchen muß. Oder?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

---

Near Code bedeutet nur, das sich jeder Funktionsaufruf in 32k Reichweite befindet. Smalldata heisst maximal 64k Data über A4 adressiert. Beides hat *nichts* mit eventuellen Cast in den Quellen zu tun.

---

Zitat:

---

Wer mit [U]WORD in den eigenen Quellen arbeitet, macht sich das leben nur selber schwer.
BTW1, 'FORM' und Freunde erzeugt man korrekterweise mit MAKE_ID.
BTW2, laß besser die Finger von diesen schrottigen Quellen.

---

Ich weiß, daß die eigentlich Schrott sind. Zum Glück ist relativ leicht zu durchschauen, nach welchem Schema der Autor da gearbeitet hat. Schema Faulpelz vor allem.

Wie ich schon sagte: Reine Fleißarbeit.

Und ich lerne dadurch mit Sicherheit einiges dazu. Vor allem, was man nicht machen sollte...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

---

Reden wir hier von C? Da kommst Du damit in keinster Weise in Berührung. Der Compiler nimmt die passenden Adressierung und gut. Das hat mit Casts wirklich nichts zu tun. Auf dem Amiga gibt es keine Cast wegen Near-Code bzw. Near-Data. Wirklich nicht.

---

Zitat:

---

Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.

---

Zitat:

---

Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

---

Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.

Die von Dir erwähnten kommen dann wohl noch, habe bisher noch nicht alle .c-Dateien probecompilieren lassen...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

---

Zitat:

---

Zitat:

---

Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.

---

Wie ist der letzte Satz hier genau zu verstehen? Oder meinst Du damit, daß die Resource-Base als #define vorliegen muß statt als "extern" Deklaration?

---

Zitat:

---

Zitat:

---

Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.

---

Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.

---

[ - Antworten - Zitieren - Direktlink - ]