Zitat:

---

Crash log for task "WBSudoku1.5.0"
Generated by GrimReaper 52.3
Crash occured in module at address 0x7F5713D0
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 016DA720 6812432C 6812433C 00000000 68768E54 00000001 680C7548 00000000
8: 6812432C 7F5713B8 980840AF 00000001 00000004 68124334 0144ACB4 0001A224
16: 6A39C000 69693B50 688927F0 0144A8A4 00000000 683FCCB8 680C74F9 00000190
24: FFFFFFFF 00000005 BBC2B938 00000000 68768E54 68899008 68768004 68769810


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 0 0
4: 0 0 0 0
8: 0 1.67772e+07 1e+61 1e-59
12: 1.45833 1e-05 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 1e+61 1e-59 0.5 4.5036e+15
28: nan 65536 1.67772e+07 0

FPSCR (Floating Point Status and Control Register): 0x00000000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0000F030
Condition (cr) : 0x22000000
Instruction Pointer (ip) : 0x7F5713D0
Xtended Exception (xer) : 0x20000000
Count (ctr) : 0x01450224
Link (lr) : 0x7F5713B8
DSI Status (dsisr) : 0x40000000
Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 00000000 68768E54 680C74F9 00000190 FFFFFFFF 00000005 BBC2B938 00000000
ADDR: 690C75E0 680C7548 68768E54 68899008 6812433C 68768004 68769810 68124330
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x7F5713D0 belongs to module "" (HUNK/Kickstart)

Stack trace:


68k Stack trace:
683fccb6 (68k IP) - "WBSudoku1.5.0" Hunk 0000 Offset 00000cae (SegList: 1a0ff001)
683fccba - "WBSudoku1.5.0" Hunk 0000 Offset 00000cb2 (SegList: 1a0ff001)
01e41cf6 - "Kickstart/dos.library.kmod" Hunk 0001 Offset 00000772
01688034 - "Kickstart/rtg.library" Hunk 0000 Offset 00020b50
0156ce14 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00025b70
0156ce98 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00025bf4
0157011c - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00028e78
0167ade4 - "Kickstart/rtg.library" Hunk 0000 Offset 00013900

68k disassembly:
683fccae: ffa0 linef
683fccb0: 2c5f movea.l (sp)+,a6
683fccb2: 2e00 move.l d0,d7
683fccb4: 2007 move.l d7,d0
*683fccb6: 4eab97e8 jsr -0x6818(a3)

---

Zitat:

---

Ein bekannter Fehler, dessen Problem ich bis jetzt nicht richtig korrigieren konnte. Ich hab erst mal eine Korrekturmöglichkeit im ToolType des Programms eingebaut:
YPOS=-10
Somit kann man es korrigieren. Ist nicht das Gelbe vom Ei, muß mal richtig gemacht werden. Es kann auch sein das ein anderer Wert gesetzt werden muß...

---

code:

---

.
.
.
/* the border variables describe the window border.  If you specify
     * WFLG_GIMMEZEROZERO when you open the window, then the upper-left of
     * the ClipRect for this window will be upper-left of the BitMap (with
     * correct offsets when in SuperBitMap mode; you MUST select
     * WFLG_GIMMEZEROZERO when using SuperBitMap).  If you don't specify
     * ZeroZero, then you save memory (no allocation of RastPort, Layer,
     * ClipRect and associated Bitmaps), but you also must offset all your
     * writes by BorderTop, BorderLeft and do your own mini-clipping to
     * prevent writing over the system gadgets
     */
    BYTE BorderLeft, BorderTop, BorderRight, BorderBottom;
.
.
.

---

Zitat:

---

Ooooaahh! Einen Pointer multiplizieren, da rollt es mir ja die Zehennägel hoch!

---

Zitat:

---

Sind die String 0 terminiert ?

---

Zitat:

---

Ruf mal die Informationen der Einzelnen
Partitionen auf und guck nach der SFS Version. Anhand dieser
kannst du sehen ob OS4 tatsächlich, wie es ursprünglich sein
soll die PPC Version nutzt oder nicht.

---

Das einzige was man da sehen kann ist ob die Partition SFS0 oder SFS2 ist, aber das hat nichts mit PPC oder nicht zu tun, sondern mit Dateien jenseits der 4GB Grenze.

Um rauszukriegen ob die PPC Version von SFS genutzt wird muß man ins Kickstart Verzeichnis gucken (anhand des vollen Versionsstring).

Aber selbst wenn dort die 68k Version liegen würde, erklärt das nicht wo der ganze Speicher bleibt.