First native betas of dopus5, check this out !

I did not claim that it was the only issue. That's why I'm looking for some feedback to see which parts are broken on 3.1. I'll test it on a clean install too, if I can get gdbstub to work.

@BSzili
I remember when we discuss it with jPV (he test it on clean 3.1, with just replaced rexxsys.library to make it runs), that what he found:

Those two arrows on status line don't look like they should on OS3.1,
but they do work on OS3.9:
http://jpv.wmhost.com/testi/dopus5/dopusos31aga.png

Imho, in original sasc code libraries/varargs.c is what make all works on os3.1 and which lately was added to 3.9. Dunno through if we need again bunch of ifdefs for 3.1 support (or if we need 3.1 support at all if 3.9 works), but if you care why not. Just try to make it all clean, like maybe some os31_support.c file or so , without bunch of ifdefs (which we have enough already in code imho).

I highly doubt that programs compiled with GCC would need SAS/C vararg stubs, because if you run them on OS 3.1 the the calling convention will magically change itself. The GCC-style variadic macros expand in compile time, so you end up with the non-varargs versions compiled in (eg. SystemTags() becomes a TagItem array where the arguments gets popped from the stack, and a SystemTagList() call).

@BSzili
It can be some other (non vavargs) funcs we replace with system ones (there was some as well). At least i found replaced funcs as one of easy explain for corruption jPV have on os3.1 and didn't on os3.9 on screenshot i show above.

If you care to make os3.1 support be fully ok and same as it now on 3.9, i can get in touch with jPV again about and ask him for more tests

That sounds more plausible. I just wish there was some comprehensive list of the functions added in OS 3.5+. The only new function I remember adding is DrawIconState, which isn't even used in the 68k build.
In any case I'll find the piece of code which draws the arrows, and see if I can trace the problem from there.

edit: The icons won't show up correctly, because they are not in the chip memory. There's no __chip attribute In GCC, so you have to allocate chip memory via AllocMem or AllocVec.

@Severin
Quote:

Xenic fix it yesterday, try last nightly

@BSzili
Quote:
Come across this issue myself a few time recently when backporting somthing to 68k. I made a little ?construtor? function that coppied the static data into memory allocated with AllocMem(). A pin in the butt, but it worked.

@kas1e

Working great, Thanks Xenic

Now there's just a few things left to fix to make it fully usable.

bug:
Drag'n'drop into app windows doesn't work at all

Setting a key in hotkeys to change the background often fails, just displaying grey. I use:

SetAsBackground NAME wallpaper:* DESKTOP STRETCH

Sometimes it appears to do nothing but I think it's just randomly selected the same background as the current one, there should be a check for that.

Requests:

Mousewheel support in settings requesters.

Being able to select on file size and file comment as in dopus4

The number of characters allowed in the titlebar needs to be increased as we now have much wider screens.

The copy/move requester could be wider amd showing more of the filename being worked on and maybe a second bar showing progress in sub drawers

@kas1e

Got a new bug though, I'm getting a DSI in dopus_progressbar when moving files.

I previously updated on the 5th June so this bug was introduced after that.

dicpng crashlog:


Crash log for task "dopus_progressbar"
Generated by GrimReaper 53.19
Crash occured in module dopus5.library at address 0x7FA56C18
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 7FA56C0C 57938F20 73AC7475 55BBDF18 57938F08 55BBDF18 55BBDF18 02A78644
8: 00000001 00000002 00000001 55BBDF18 59953559 7574AE74 FFFFFFFF 57541C70
16: 02B20000 DF983C00 02B20000 57A4DDA0 00000000 00000000 00000000 5AF10368
24: 08000008 00000001 08000007 5AF1039C 5AF10000 55BBDF18 00000000 578DE750


FPR (Floating Point Registers, NaN = Not a Number):
0: nan -7.60054e+306 -7.60054e+306 -7.60054e+306
4: -7.60054e+306 -7.60054e+306 -7.60054e+306 -7.60054e+306
8: 1 255 216 31
12: 47 258 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 0 0
28: 0 0 0 0

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


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0200F030
Condition (cr) : 0x538B1D70
Instruction Pointer (ip) : 0x7FA56C18
Xtended Exception (xer) : 0x0000FFFF
Count (ctr) : 0x5587AA64
Link (lr) : 0x5B75C610
DSI Status (dsisr) : 0x538B1D90
Data Address (dar) : 0x02021140



680x0 emulated registers:
DATA: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 6FFB8700 93D7AA00 00000000 00000000 00000000 00000000 00000000 57938300
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x7FA56C18 belongs to module "dopus5.library" (PowerPC)
Symbol: progress_set + 0x130 in section 1 offset 0x00039BF4

Stack trace:
[progress_win.c:914] progress_set()+0x130 (section 1 @ 0x39BF4)
[progress_win.c:912] progress_set()+0x124 (section 1 @ 0x39BE8)
native kernel module dos.library.kmod+0x00024cb8
native kernel module kernel+0x00042530
native kernel module kernel+0x000425b0

PPC disassembly:
7fa56c10: 4182003c beq- 0x7FA56C4C
7fa56c14: 81230004 lwz r9,4(r3)
*7fa56c18: 80090000 lwz r0,0(r9)
7fa56c1c: 81290004 lwz r9,4(r9)
7fa56c20: 2f800000 cmpwi cr7,r0,0

System information:

CPU
Model: P.A. Semi PWRficient PA6T-1682M VB1
CPU speed: 1800 MHz
FSB speed: 900 MHz
Extensions: altivec

Machine
Machine name: AmigaOne X1000
Memory: 2097152 KB

@Severin
Quote:

Yeah, pretty possible. Xenic works lately right on updating progress bar things to be fine with 64bit, i repost your report to him.

As for all other reports: if you can, please use our bugreport page for all the bugs and requests:
https://sourceforge.net/p/dopus5allamigas/_list/tickets

It will be easy for all who works on later to deal with, because its only me more or less offten check forums, and i can easy miss something, or not understand something right, etc.

Sure i know you not want to use bloated webrowsers, but just for such task you can use odyssey , as it will help us a lot when all the reports will be at one place.

@Severin
Quote:

Check new nightly, xenic probably fix it

@Kas1e

Confirmed fixed.

@kas1e

There is still the rexxmast error (post 240) happening (at least for me on Aros 68k, propably on 3.1. too). Could you look at it? The problem is that on WinUAE there is the error requester and it at least works but on FS-UAE the system crashes so (to support both) AREXX support is deactivated on Aros Vision by default. It would be great if I could enable it after fixing. Thanx