amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Probleme bei Programmierung unter WinUAE [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

14.10.2002, 11:39 Uhr

Micha1701
Posts: 938
Nutzer
Hi!

Hab gestern ein kleines Programm erweitert und auf meinem Heim-AMIGA getestet. Es lief...

Nun wollte ich heute auf der Arbeit unter WinUAE weiterproggen und siehe da - es läuft nicht mehr...

Mit dem Debugger reingeschaut und folgendes festgestellt:

Bei einer popeligen Adreßzuweisung:

amiga.playermap = &globalmap;

wird in der Variabeln playermap leidiglich die unteren 2bytes mit den ersten 2bytes der Adresse gefüllt. die restlichen 2bytes der Adresse wandern in die nächste Variable....

Das passiert aber nur bei dieser Struktur (amiga). Überall anders funktioniert die Wertzuweisung einwandfrei...

Hat von Euch schonmal jemand dieses Problem gehabt?



--
:boing: Micha :boing:

Look at my HP: http://www.lanser-online.de.vu



[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 12:40 Uhr

thomas
Posts: 7717
Nutzer

Welcher WinUAE, welcher Prozessor, welches AmigaOS, welches NDK, welcher Compiler, welche Optionen ?

Ich programmiere seit einiger Zeit fast nur noch unter WinUAE und hatte noch nie irgendwelche Probleme.

Hast du mal versucht, die JIT auszuschalten, ob der Fehler dann auch auftritt ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 13:27 Uhr

tokai
Posts: 1071
Nutzer
Verwendest du vielleicht int's ? Dann liegt's wahrscheinlich daran, dass dein Compiler auf dem UAE vielleicht auf 2Byte- und nicht auf 4Byte-ints eingestellt ist. Verwende am Besten die typedefs aus exec/types.h, z.B.: LONG, WORD, BYTE etc. (auf Gross- und Kleinschreibung achten! :)
--
http://www.christianrosentreter.de

[ Dieser Beitrag wurde von tokai am 14.10.2002 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 13:38 Uhr

Micha1701
Posts: 938
Nutzer
Zitat:
Original von thomas:

Welcher WinUAE, welcher Prozessor, welches AmigaOS, welches NDK, welcher Compiler, welche Optionen ?

Ich programmiere seit einiger Zeit fast nur noch unter WinUAE und hatte noch nie irgendwelche Probleme.

Hast du mal versucht, die JIT auszuschalten, ob der Fehler dann auch auftritt ?

Gruß Thomas


Ich benutze WinUAE V0.8.8R8 (wegen WinNT4.0). Emulierter Prozessor ist 68020+FPU, OS3.9BB1, NDK3.9, StormC V3 prof. .

Optionen wie folgt:

Sprache: ANSI-C
Debugger: kleine Debug-Datei
ohne Assemblertext
AmigaOS: M68020
Mathe Libs
Far Code und Data

Einen JIT gibt es in dieser "alten" WinUAE Version noch nicht...

Ich habe immer wieder mal Probs mit der Emu. Vielleicht ist sie auf Dauer einfach zu alt... Aber auf die Arbeit bekommen wir so schnell kein aktuelles Windows und daher muß ich wohl mit dieser uralt Version leben....





--
:boing: Micha :boing:

Look at my HP: http://www.lanser-online.de.vu



[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 13:41 Uhr

Micha1701
Posts: 938
Nutzer
Zitat:
Original von tokai:
Verwendest du vielleicht int's ? Dann liegt's wahrscheinlich daran, dass dein Compiler auf dem UAE vielleicht auf 2Byte- und nicht auf 4Byte-ints eingestellt ist. Verwende am Besten die typedefs aus exec/types.h, z.B.: LONG, WORD, BYTE etc. (auf Gross- und Kleinschreibung achten! :)


Die ints werden richtiger weise in 32-bit Longs umgewandelt... Also daher keine Probleme....

Mal ne Frage so nebenher:

Muß ich in einer Struktur eigentlich darauf achten, daß diese eine gerade Anzahl an bytes enthält? Von wegen wordalignment? Oder achtet der Compiler auf sowas?


--
:boing: Micha :boing:

Look at my HP: http://www.lanser-online.de.vu



[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 14:10 Uhr

thomas
Posts: 7717
Nutzer
Zitat:
Muß ich in einer Struktur eigentlich darauf achten, daß diese eine gerade Anzahl an bytes enthält? Von wegen wordalignment? Oder achtet der Compiler auf sowas?


Das macht der Compiler. Natürlich ist es aus Dokumentationszwecken immer sinnvoll, die Füll-Bytes auch zu deklarieren.

Es könnte auch sein, daß du doch einen Fehler im Programm hast. Gerade wenn man mit der dos.library arbeitet, müssen manche Sachen longword-aligned sein. Das kann zufällig hinhauen, oder manchmal auch nicht.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 14:19 Uhr

Micha1701
Posts: 938
Nutzer
Das seltsame ist ja, daß es bei mir zu hause funktioniert hat. Und diese Programmversion hab ich auch auf dem Compiler gestartet - da gabs dann erst den zuweisungsfehler....

Ich hab jetzt mal an der Struktur rumgefummelt. Wenn ich die Variable

char name[30]

auskommentiere, dann gibts diesen Fehler nicht mehr....
Toll, diese Variable brauch ich aber irgendwann mal....

Zum kotzen find ich es auch, daß ich schon wieder ein Problem mit der Grafikausgabe habe. Unter CGX klappts, unter P96 nicht.... ARGGGGHHH!

Naja, ich werds einfach weiterversuchen.... :dance3:
--
:boing: Micha :boing:

Look at my HP: http://www.lanser-online.de.vu



[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 15:17 Uhr

AchimStegemann
Posts: 112
Nutzer
Zitat:
Ich benutze WinUAE V0.8.8R8 (wegen WinNT4.0). Emulierter Prozessor ist 68020+FPU, OS3.9BB1, NDK3.9, StormC V3 prof. .

Optionen wie folgt:

Sprache: ANSI-C
Debugger: kleine Debug-Datei
ohne Assemblertext
AmigaOS: M68020
Mathe Libs
Far Code und Data


Hi!

V0.8.8R8 ist uralt und ziemnlich buggy. Dein Problem dürfte ausschließich an der UAE-Version liegen.

Am besten du holst dir die aktuellste UAE-Version 0.8.22. Keine Ahnung ob die unter WinNT geht. Wenn nicht... Pech gehabt (so bitter das auch klingt).

Ich progge auch unter WinUAE und hatte noch NIE Probleme gehabt (unter WinME).

Gruß
Achim

[ - Antworten - Zitieren - Direktlink - ]

14.10.2002, 16:45 Uhr

thomas
Posts: 7717
Nutzer

0.8.8R8 ist die stabilste Version, die es jemals gab. Und wenn es dort solche gravierenden Fehler in der 68K-Emulation gäbe, würde da kein einziges Spiel laufen.

Wie wäre es, wenn du mal den kompletten Programmausschnitt postest, mit der Struktur ? Vielleicht liegt es auch an Storm. Ich programmiere mit Dice oder VBCC.

Die einzigen Unterschiede zwischen P96 und CGX, die mir bisher Schwierigkeiten gemacht haben, sind 1. unter P96 funktioniert vergrößern mit ScalePixelArray nicht (leere Zeilen dazwischen) und 2. LockBitMap() blockiert unter P96 das komplette Multitasking. D.h. wenn du zwischen LockBitMap und UnlockBitMap ein printf machst, bekommst du einen sauberen Deadlock.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

15.10.2002, 02:02 Uhr

AchimStegemann
Posts: 112
Nutzer
Zitat:
Original von thomas:

0.8.8R8 ist die stabilste Version, die es jemals gab. Und wenn es dort solche gravierenden Fehler in der 68K-Emulation gäbe, würde da kein einziges Spiel laufen.


Nicht die OS 1.x-Emulation ist buggy. Klar, sonst würden die alten Spiele ja nicht laufen. Ich meine aber die Emulation höherer CPUs im Zusammenhang mit OS 3.5+. Das habe ich unter der genannten UAE-Version nicht zum laufen gebracht. Erst bei höheren Version. Außerdem hatte die FPU-Emulation noch einige Macken, die erst später gefixt wurden.

Aber egal... bei WinUAE sollte man generell immer die aktuellste Version haben.

Wir wollen deshalb hier ncht darüber streiten, welche Version am stabilsten ist, da es auch vom Win-OS abhängt, unter dem WinUAE läuft.

Noch 'ne Möglichkeit: Bei manchen PCs reagiert WinUAE seltsam (fragt mich nicht wie, ist halt so). Ist aber für diesen Fall wohl eher unwahrscheinlich, da WinUAE wohl eher gar nicht starten würde.


Gruß
Achim

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Probleme bei Programmierung unter WinUAE [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.