I just add you to admins group, so feel free to restructure anything we all need.
O.K. I'll take a look at the possibilities as soon as I get a chance.
Quote:
Btw, i currently trying to build os3 version of dopus5 on my winuae setup, and so far already build dopus5.library, filetype.module and almost finish with main binary.
That's a good start. If you can get it to build in winuae then I would assume the next step would be to convert it to compile with GCC for OS3. Getting it to run might be a different matter. So far I count 27 system patches and lots of assembler routines. Unfortunately, I only have a PPC Amiga and my 68k GG compiler stopped working as of OS 4.1.
Quote:
Btw, how can i un-iconify back from "button iconify" mode ? With plain iconify its enough to press RMB on top bar, but seems from button-iconify mode it didn't works.
If you click the close gadget you should get a requester asking if you want to quit or uniconify. If you don't then you need to uncheck the "Configuration/Operation/General/Don't ask before quit" item and save the config. The button and window iconify methods are outdated. You can now iconify to a Workbench icon or AmiDock icon (or both I think). A number of users who have been using Dopus4 for 15+ years get upset when Dopus4 is changed to work differently than it always did. I would have preferred to remove a lot of old stuff but I'm leaving it the way it is. If you want to iconify in a more modern way then change "Configuration/System/Clocks/When iconified..." item to "An AppIcon". You can add it to AmiDock by activating the "DOCKY" Tooltype in the Dopus4 icon.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
That's a good start. If you can get it to build in winuae then I would assume the next step would be to convert it to compile with GCC for OS3.
Or at least just build working os3 version in which fix the bugs which prevent to use it on os4. At least that can be faster and can give something usable right now. We can add some debugging printfs and even debug where os3 version sucked up. And while ppls will have working os3 versions, we can start to rewrite it to gcc and so on.
Quote:
Getting it to run might be a different matter. So far I count 27 system patches and lots of assembler routines. Unfortunately, I only have a PPC Amiga and my 68k GG compiler stopped working as of OS 4.1.
Those assembler routines mostly nothing: there is about 5 of the same ones called "lsprintf.asm" (same size, same code), which of course pretty easy to replace on C one, and the other ones are:
There is an archive with all the stuff, +it contain dopus5-debug binary , which may be helpfull.
I test it on my os3 setup already: it works. Yeah !
On os4 it starts and works, through give DSIs when i spawn new Lister.
Tested it for now in all the areas, seems works on 70% everythere. At least all settings (bring truecolor backdrops, set filetypes, scripts, screenmodes, icon settings (with those ones i see that something wrong with icons format), etc) works fine. But have freeze when do "select theme", also something wrong with topbar of the screen, etc. I.e. there is for sure something to fix, but first need to make listers to works.
I test it on my os3 setup already: it works. Yeah !
Good work! I wonder if your OS3 version works on MOS. We already knew there would be some problems using it with OS4.
Quote:
Tested it for now in all the areas, seems works on 70% everythere. At least all settings (bring truecolor backdrops, set filetypes, scripts, screenmodes, icon settings (with those ones i see that something wrong with icons format), etc) works fine. But have freeze when do "select theme", also something wrong with topbar of the screen, etc. I.e. there is for sure something to fix, but first need to make listers to works.
It could be a system patch issue (or not). It would be interresting to know if your compiled version works on a classic (68k) Amiga.
Quote:
Those assembler routines mostly nothing: there is about 5 of the same ones called "lsprintf.asm" (same size, same code), which of course pretty easy to replace on C one,
Don't be too quick at replacing lsprintf.asm with C funnctions. Some of those assembler routines also contain other assembler functions that are not part of the lsprintf function. The Dopus lsprintf function uses the exec RawDoFmt ()function which calls a locale.library function once Locale is loaded and running. The function in locale.library handles the string characters that are used in languages other than English. I don't know if the C library string functions are localized and can work in the same way. Since I can't really help with the OS3 compile you are working on, I'll take a look at some of the assembler functions to see if I can convert them to C. For some it may take a 68k assembler expert.
Quote:
For me is much more important those 27 system patches about which you told. How you search them ? Some usuall functions ?
Look in the Library code and check out wb.c and dos_patch.c. Most of the patches may only be for WorkBench replacemant mode. If that's the case it might be possible to get Dopus working in non-replacement mode without dealing with any patch issues.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I wonder if your OS3 version works on MOS. We already knew there would be some problems using it with OS4.
Yeah, i test that build on MOS for now: it works. Listers opens fine and works, no crashes or problems which arise on os4.
Quote:
It would be interresting to know if your compiled version works on a classic (68k) Amiga.
If you mean in general: yeah,i test it on os3 and it works. But if you mean those small bugs: nope, on os3 i didn't have them. I can do "load theme" and so on. But its all expectable of course, those small bugs will need to address later.
Quote:
Since I can't really help with the OS3 compile you are working on, I'll take a look at some of the assembler functions to see if I can convert them to C. For some it may take a 68k assembler expert.
That will be a good start ! I can just then grab C versions and include to os3 build, to see, if they works fine.
@all Currently i trying to find out the roots of opening-lister crashes, and so far i hope i pretty close already (but help of amiga-coders-experts is need it of course :) ):
Code structured like this: Once we choice "Lister/New" in dopus5 menu, lister_new() function is called from lister.c. But its just simply IPC_Launch -> in end of lister_new() we have such kind of code:
// Start lister process
if (!(IPC_Launch(
&GUI->lister_list,
&ipc,
"dopus_lister",
(ULONG)lister_code,
STACK_DEFAULT,
(ULONG)lister,(struct Library *)DOSBase)))
{
if (!ipc) lister_free(lister);
return 0;
}
I.e. actuall code is "lister_code()".
lister_code() are placed in the lister_proc.c file, which inside have lister_open(), which placed in the lister_window.c file. But lister_code() not only call lister_open(), its in general main code with all the loops and stuff: that involve timing, icon, appmessage, reply to messages and handle answers from, and so on. lister_open() its just some crap like making actual window, idcmps, and so on, whicle lister_code() are our main mess (imho).
So, that "main" lister_code() structured like this:
Go an icon drag timer?
Busy request returned?
Periodic timer return
intuition messages
Application messages
Icon notification
commands (in some of them lister_open() is called if need it).
IPC_Reply(lmsg);
check_on_exit(), etc and continue or exit
}
some_cleanup_code;
I.e. code in FOREVER works like while() , and "commands" its all usuall stuff with CASE balblabl: break.
Sooo.. once we run dopus5, and spawn a lister, code do:
Firstly on running of lister, all the code from FOREVER passes fine and debug prinfs brings:
before Go an icon drag timer? before Busy request returned? before Periodic timer return before intuition messages before Application messages before Icon notification before commands
Then prinfs brings that we are in the
case IPC_SHOW:
LISTER_OPEN:
...lister_open() + some small settings for ..
break;
and lister_open() from that happens (there is also another places where lister_open() can be called, but first one, after which we already will have dsi, happens in that CASE).
At this moment, visually, lister already opens, but but with no actual content inside. (only borders, top bar, etc).
So i firstly prinfs/delays all the code in the IPC_SHOW/LISTER_OPEN: nothing. Then, i go to the place what happens after break from, and that is:
IPC_Reply(lmsg);
(almost at the end of lister_code function, and almost end of FOREVER loop).
And i just add such stuff:
printf("we are before IPC_Reply(lmsg)\n");
Delay(500);
IPC_Reply(lmsg);
printf("we are after IPC_Reply(lmsg)\n");
Delay(500);
And what is interesting, is that after all that initial/first code happens, and it breaks from IPC_SHOW/IPC_LISTER, it prinfs/do that:
we are before IPC_Reply(lmsg) we are after IPC_Reply(lmsg) we are before IPC_Reply(lmsg)
BANG !! BANG !! DSI !
we are after IPC_Reply(lmsg). we are before IPC_Reply(lmsg) we are after IPC_Reply(lmsg) we are before IPC_Reply(lmsg) we are after IPC_Reply(lmsg)
and then we finish whole FOREVER loop, and continue from begining (but already crashes, we continue to see new prinfs because its running in different process).
So, its something with messages (?). I through do not know why it reply 4 times instead of 1 (its is ok?), and why it crashes at all, on second reply (on first one is ok). I can assume that there should be only 1 reply, and because of that it crashes on second one, but i am not expecrt in messages, so dunno..
If anyone will take a look at the code, then IPC_Reply() together with all other IPC related stuff define in the include/dopus/ipc.h , and some ipc related code in the library/ipc.c
Btw, what is intersting, is when i add Delays there and there, i even sometime can ignore DSIs and have spawned lister:
But i think that kind of understanable : ipc + messages => delays can make differences visually. + That can make us think, that if it spawns sometime, then problem not in lister code itself, but in that IPC / messaging crap and whole FOREVER loop.
I remember there was such kind of problems for me when i do bad loops with messages in my warp3d mags (the same loop, the same answering on messages, etc). And while on os3/mos it was ok even with "wrong" code, on os4 it give kind of the same problems with DSIs and crashes..
Edited by kas1e on 2012/12/20 20:23:04 Edited by kas1e on 2012/12/20 20:23:34 Edited by kas1e on 2012/12/20 20:24:22 Edited by kas1e on 2012/12/20 20:26:36 Edited by kas1e on 2012/12/20 20:27:34 Edited by kas1e on 2012/12/20 20:28:39 Edited by kas1e on 2012/12/20 20:30:52 Edited by kas1e on 2012/12/20 20:31:33 Edited by kas1e on 2012/12/20 20:34:09 Edited by kas1e on 2012/12/20 21:37:39
@spot Checking for now how all the other parts of dopus5 done, and they all done like this, and those IPC_Reply and co uses all the time. But by some reassons for listers it sucked up.. Maybe some more flags, or overloading by that "saveds varags a0/a1/a2" #OOPS# :)
ps. good news, Jens Langner step in as well to works on dopus5.
Those assembler routines mostly nothing: there is about 5 of the same ones called "lsprintf.asm" (same size, same code), which of course pretty easy to replace on C one,
Don't be too quick at replacing lsprintf.asm with C funnctions. Some of those assembler routines also contain other assembler functions that are not part of the lsprintf function. The Dopus lsprintf function uses the exec RawDoFmt ()function which calls a locale.library function once Locale is loaded and running. The function in locale.library handles the string characters that are used in languages other than English. I don't know if the C library string functions are localized and can work in the same way. Since I can't really help with the OS3 compile you are working on, I'll take a look at some of the assembler functions to see if I can convert them to C. For some it may take a 68k assembler expert.
utility.library contains SNPrint() which is a localised snprintf. Most sensible would be to use that.
So, its something with messages (?). I through do not know why it reply 4 times instead of 1 (its is ok?), and why it crashes at all, on second reply (on first one is ok). I can assume that there should be only 1 reply, and because of that it crashes on second one, but i am not expecrt in messages, so dunno..
Assuming we are talking standard exec message then you can't reply it more than once. I'm not 100% sure but I think replying the msg Add it to the reply posrt exec list. clearly add a node to a list that is allready part of the list without removeing it first will do Bad Things.
Assuming we are talking standard exec message then you can't reply it more than once. I'm not 100% sure but I think replying the msg Add it to the reply posrt exec list.
As i see those IPC ones are standard exec messages, just a bit overloaded by stuff: see how include/dopus/ipc.h looks like:
#define REPLY_NO_PORT (struct MsgPort *)-1 // Sync msg, no port supplied
#define REPLY_NO_PORT_IPC (struct MsgPort *)-2 // Sync msg from a non-IPC process
// IPC process
typedef struct _IPC {
struct MinNode node;
struct Process *proc; // Process pointer
IPCMessage startup_msg; // Startup message
struct MsgPort *command_port; // Port to send commands to
struct ListLock *list; // List we're a member of
APTR userdata;
APTR memory; // Memory
struct MsgPort *reply_port; // Port for replies
ULONG flags; // Flags
} IPCData;
// Used in the stack paramter for IPC_Launch
#define IPCF_GETPATH (1<<31) // Want copy of path list
#define IPCM_STACK(s) (s&0xffffff) // Mask out stack value
// Pre-defined commands
enum {
IPC_COMMAND_BASE=0x8000000,
IPC_STARTUP, // Startup command
IPC_ABORT, // Abort!
IPC_QUIT, // Quit process
IPC_ACTIVATE, // Activate process
IPC_HELLO, // Something saying hello
IPC_GOODBYE, // Something saying goodbye
IPC_HIDE, // Process, hide thyself
IPC_SHOW, // Tell process to reveal itself
IPC_RESET, // Process should reset
IPC_HELP, // Help!
IPC_NEW, // Create something new
IPC_GOT_GOODBYE, // Got goodbye from something
IPC_IDENTIFY, // Identify yourself
IPC_PRIORITY, // Change your priority to this
IPC_REMOVE, // Remove yourself
};
clearly add a node to a list that is allready part of the list without removeing it first will do Bad Things.
But it is works on os3 without probs back in past and works on mos still ?
@Spot Quote:
Broadblues: maybe you should get yourself involved? =)
Yeah indeed. Will be cool to fix right now that lister-crash, and bring working 68k version for all, and then we can works in chil mode, step by step rewriting/fixing crap.
@AlexC Quote:
What is the value defined for the STACK_DEFAULT constant? Maybe it's just a stack issue?
#define STACK_DEFAULT 6144
done like this everythere (i.e. in 3 files: config/configopus.h, library/dopuslib.h and programm/dopus.h)
I tryed to set 100000 for lister running in main run in lister.c => same DSI, same crashlog 1:1
Quote:
What does the crash log look like?
68k mess (because its 68k build for now), but here is:
Quote:
Crash log for task "dopus_function" Generated by GrimReaper 53.6 Crash occured in module at address 0x7F692544 Type of crash: DSI (Data Storage Interrupt) exception
Well that's rediculously small for a PPC system. push it up by a factor of ten.
Quote:
But it is works on os3 without probs back in past and works on mos still ?
So what? That could be for lots of reasons. Could be because 68k doesn't have memory protection so the bug is never caught. It could be because the bug isn't the replying message but else where causeing the message to be replied multiple times.
You are going about this the wrong way anyway. You should port the code to gcc and build a native version for your target, then you can really debug the thing. There's an outside chance you're really chasing a bug in petunia or something of that nature. BTW Does blacklisting it make any difference?
Quote:
Broadblues: maybe you should get yourself involved? =)
You are going about this the wrong way anyway. You should port the code to gcc and build a native version for your target, then you can really debug the thing.
Sure i will going that way if no one else will do it while i trying to fix os3 version, its just will take time for me (as i am no programmer in general). And will be not done tomorrow, or in 2 days. And as noone else even starts now, i from my side can try to fix with all your help os3 version to have it working , while work on rewriting it to gcc will going on.
Quote:
There's an outside chance you're really chasing a bug in petunia or something of that nature.
Even better, if bug in petunia, i know how contact with Rachy and while he works on Jit we have chance that he will fix it in petunia as well.
Quote:
BTW Does blacklisting it make any difference?
Tryed right now: same crash, just a bit different assembler (that is expected imho as we disable jit), and it looks now like:
@Andy I rebuild everything with stack *100 just in case (i.e. library, main binary, etc), and multiply not only STACK_DEFAULT, but also STACK_LARGE (dopus5 have only them) - same crash 1:1
Ps. i wonder, if i can try to use os3 debuggers on os4 (like monam, inbuild sasc one, etc)
I have been successful in rebuilding Opus Magellan in SASC on OS4. SASC is fully Petunia compatible - there is no need to use UAE to build. Just be careful to add all the proper includes to user-startup and be careful not to overwrite any of the OS4 SDK paths (like bin). It builds VERY fast on SASC in OS4.
Where did you put the delay to make the lister "sort of" work? i have tried adding small delays to lister.c in various places with no success.
I'm sure that like me you discovered you needed to add the executive sysinfo include files, as well as use NDK 3.9 and multiuser include files from Aminet to get Magellan to properly build. See my posts on Amigaworld.net about what includes I used.
Please keep us posted on what you find about the listers....I think the problem should be relatively easy to resolve. You are a lot more familiar with porting stuff to OS4 than I.... And I agree with your approach. You need to make sure you can rebuild a working version on Os3 before attempting to port it to a different compiler. To port it to a different compiler first adds too many unknowns right away.
I have been successful in rebuilding Opus Magellan in SASC on OS4. SASC is fully Petunia compatible - there is no need to use UAE to build. Just be careful to add all the proper includes to user-startup and be careful not to overwrite any of the OS4 SDK paths (like bin). It builds VERY fast on SASC in OS4.
For me everything setuped automatic and good: i have peg2 at one side, and notebook with winxp on another side, both in the network, both use the same shared resource. Winuae by itself also see those resource, and build directory of dopus5 are on that place as well. So i just by one hand type "smake" in winuae console, and after second have a ready to run binary which i already see on os4 in necessary place.
Quote:
Where did you put the delay to make the lister "sort of" work? i have tried adding small delays to lister.c in various places with no success.
It mostly happens by some lack few times, and after content showups, its all anyway crashes/freeze.
Quote:
I'm sure that like me you discovered you needed to add the executive sysinfo include files, as well as use NDK 3.9 and multuiuser include files from Aminet to get Magellan to properly build.
How else i can it build at all without ?:) Without all those includes it is unpossible to build it as it (only disabled those parts), so i of course use them.
And btw, anyone who told you there is no GST command lie: there is, but it just a script, which do:
cd ram:
sc:c/sc RESETOPTS NOMULTINCLUDES NOOBJECTNAME MGST=include:all.gst sc:source/all.c
Quote:
Please keep us posted on what you find about the listers....I think the problem should be relatively easy to resolve.
You can already see in that thread that problem seems no very easy one, as messages and crap involved. I already find out where crash happens, but it didn't help us much for now ..
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
