Who's Online |
101 user(s) are online ( 50 user(s) are browsing Forums)
Members: 1
Guests: 100
davec555,
more...
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 11:04
#21
|
Home away from home 
|
@Hypex Quote:
But I don't see FindTask(NULL) in your main(), I only see it in the Patched_CallHookPkt() routine.
Rigth, there is none, because i don't it :) I just point about that if it was in main, then yeah, that will be my main process, but as this FindTask(NULL) only in patched CallHookPkt, then , together with check on only my binary to trace (via cmd_CommandName), we at this point kind of sure (i were in hope) that this is the process we had, and we not need any new "findtask" for , as we already can suspend it from &process->pr_Task. Quote:
However, looking again at the code of callhookpkt_stacktrace_v1.c, this may be easier than it seems. Is this libauto as no libraries are opened? Also, where is IDebug filled in? I don't see any protos for it nor am aware of libauto able to open debug interface of Exec.
IDebug is an Exec's thing, and yeah i use libauto: i tested by standalone binary (without patching involved) and IDebug handles well by it and stack trace working for let's say FindTask("Workbench").. But not when i put my process to trace on : it simple hang binary i want to trace+stack-trace right after first CallHookPkt() call. Maybe when we in patched function i should obtain IDebug again ?
|
|
|
|
|
|
Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE
|
Posted on: Yesterday 10:22
#22
|
Just popping in 
|
@Gebrochen No, I gave up, I couldn't get any to work. At first I couldn't get any to fit in the PCIe bridge as I was unable fit a plug on the back of the cards. I was able to fit a cable to the 5450 but even that was a lost cause. Despite the physical connection another issue was the 66Mhz slot and AGP slot share the same bus. So the firmware or UBoot must be set to change modes before plugging anything in. I found this out after the fact and almost fried the cards as I wasn't aware of it when testing. So, for my XE, it's actually harder to install a HD card than a Sam 440. 
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 9:36
#23
|
Just popping in
|
@kas1e Quote: mm.. sounds complicated enough ! :) I mean we run the binary, so we have our own findtask(NULL) process (of main binary, in the main() ). The fun of library patching. But I don't see FindTask(NULL) in your main(), I only see it in the Patched_CallHookPkt() routine. Quote: Then, if we run findtask(null) in the patched callhookpkt(), then we find the proccess from where this patched callhookpkt were run, right ? (because if not, how i can detect then the name of the tasks invovled in, etc). Yes, the process that called CallHookPkt(). It would find that process in FindTask(). Quote: And then, when we in this process in this patched function, should't process be not our from main(), but the one name of task from which we are taken ? Yes, it would. That's where I see the issue. The process that called Patched_CallHookPkt() would end up suspending itself. Since it finds itself with FindTask(). Then passes that to SuspendTask(). It finds itself then loses itself lol. It likely doesn't matter what context printStack() would be running in at this point. If printStack() is running on the same context as the calling process, that is while it's the running process, then that will cause trouble. However, looking again at the code of callhookpkt_stacktrace_v1.c, this may be easier than it seems. Is this libauto as no libraries are opened? Also, where is IDebug filled in? I don't see any protos for it nor am aware of libauto able to open debug interface of Exec. 
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: Yesterday 9:05
#24
|
Just popping in
|
@utri007 What model 7850? Not much info. On Hans site one listed as working and the other as failed. http://hdrlab.org.nz/projects/amiga-o ... r-hardware-compatibility/Unfortunately you need to hook up a serial terminal and be a tech head to see what is really going on. As despite the video card technically being able to open a screen or text without any Radeon driver AmigaOS 4 isn't designed to display emergency errors and catastrophic fails. And even then, it tends to be some incompatibility, usually software driver. So just to check. Any power input the 7850 needs is connected to card. Riser card is connected to power. I've heard only one power input can be connected to a riser at once. 7850 is slotted into riser, riser is connected to PCIe bridge with USB cable, PCIe bridge in PCI slot. You're good to go. If you see UBoot something else is amiss.
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: Yesterday 8:48
#25
|
Just popping in
|
@joerg
I've examined the Enhancer files and seen evidence of an install script that modified the Kicklayout in place and inserted the RadeonHD driver in there. What I wonder is why this isn't used? The problem with AmigaOS is that it relies on all these files with no built in managers. They started moving from static files to dynamic drawers in OSS2. But they didn't finish. And the Kicklayout reverts to the old way. It may be a simple file but it is the most important core system file so really needs CLI tools to manage it in the least.
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: Yesterday 8:41
#26
|
Just popping in
|
@Gebrochen Yes I know you were thinking of modern AmigaOS. Which, funny as it is, is more colourful than a standard Windows desktop which has a plain boring appearance that looks old fashioned to me but they called it modern in today's world. Even Windows 3.1, which is closer to AmigaOS 3.1, is more colourful than Windows 11. Go figure!  But what's their problem? They plug things into Windows and they mostly work. But plug something into AmigaOS and find it doesn't, it works backwards, and must be added by hand? 
|
|
|
|
|
|
Re: A1222 support in the SDK and problems
|
Posted on: Yesterday 8:27
#27
|
Just popping in
|
@sailor A little bit higher results here on A1222. I am running a beta 1222 Tabor system from year 2016. I repeated test with emergency USB stick that is delivered with A1222+ but the results are the same. Maybe you have some stuff working in background..... stream_spe: Function Best Rate MB/s Avg time Min time Max time Copy: 842.8 0.191521 0.189850 0.196177 Scale: 547.7 0.295012 0.292110 0.304204 Add: 627.5 0.385231 0.382451 0.388252 Triad: 595.9 0.404831 0.402750 0.410643 stream: Function Best Rate MB/s Avg time Min time Max time Copy: 840.9 0.192648 0.190283 0.196379 Scale: 154.2 1.038695 1.037723 1.040899 Add: 162.7 1.478401 1.475531 1.481802 Triad: 156.5 1.537082 1.533314 1.538960 Indeed LTE emulator is doing a great job. In applications with less FPU code user will not notice any speed slowdown. That is the main objective with LTE. But I guess these results are also high because of fast memory transfer on A1222. About the 3D games - the problem is primary because of minigl library. Practically nothing will work (even included demos with minigl). At least in my testing. Lot of system parts in AOS4 are optimized with SPE. Also Warp3DNova and other code done by Hans is optimized. But there is a minigl version for both mixed FPU and SPE code and only SPE version. It can be downloaded from: https://www.goldencode.de/?page=2Also other SPE optimized games from Daniel are on this page. Also there is a Novabridge that will then make FPU/SPE minigl library operational on Radeon RX cards. Also then Rewarp will make possible to run software for WapUp. There is a great tutorial by kas1e here: https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=9032I tested all this in A1222 and results are great in some games, some not (too slow to play). I even amanged to get Quake Darkplaces working with more than 20 fps under LTE (Quake uses a lot FPU code). Quake darkplaces must be started with benchmark switch (otherwise it doesnt work, also game must be started from previous saved game position - if you have one from other Amiga system): stack 9000000 darkplaces-sdl -benchmark -widht 640 -height 480 Lots of things to investigate and play around with A1222  Real SPE optimized games will work excellent because SPE FPU performance is fast. This is when FPU is used in games - then I guess the real thing is to transfer all the calculations on the graphic card...not using much of FPU. Here I have A1222 with Radeon RX 580. It works great. -dooz
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 8:24
#28
|
Home away from home
|
@Hypex Quote:
The problem is when another process calls your function that process is the one running so it ends up suspending itself!
mm.. sounds complicated enough ! :) I mean we run the binary, so we have our own findtask(NULL) process (of main binary, in the main() ). Then, if we run findtask(null) in the patched callhookpkt(), then we find the proccess from where this patched callhookpkt were run, right ? (because if not, how i can detect then the name of the tasks invovled in, etc). And then, when we in this process in this patched function, should't process be not our from main(), but the one name of task from which we are taken ?
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 7:47
#29
|
Just popping in
|
@kas1e I can see what's going on. Your patch does indeed find the process that is calling your patched function and is a different process to your tracing process. The problem is when another process calls your function that process is the one running so it ends up suspending itself! You will need to do some IPC I think. I've dealt with this stuff before. What I usually do is setup a MsgPort stored as global pointer in main process so it can be reachable outside it. Then in the patched function setup a Message as local static or allocated on demand. Fill it with the task ID. Send it to your main process and wait. From the main process wait on the port for messages. Perform the needed extraction, print it out then signal back. I like to use SIGF_SINGLE as it's designed for one time use. It should be cleared beforehand. This way also avoids suspending a task as the other task will be waiting for your main one to process the information. Then it gets signalled back. Given it needs to print out a stack track regardless the latency of using IPC shouldn't bother it much.
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:29
#30
|
Home away from home
|
@joerg Quote:
You are suspending your own task, the one executing this code, and can't be reached
But aren't i doing this only when i am in process which had cli_commandname i point out in the argv[1], so should suspend this one instead, and not my general one ? In other words, how to find out an task address of the process i need to trace, like by doing another FindTask ? But how to say that this is the task i need to find which had my cli_commandname ? The task name my binary have is "Background_CLI" as many other ones, so second FindTask() probably will of no help there (that why i were under impression that when i am already checked that current process is the one having my cli_command, doing suspend of this process will mean suspend this one, and not general one).
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:27
#31
|
Just can't stay away 
|
@kas1e Quote: Clib2 indeed have amiga_callhook.c and amiga_callhooka.c: But both with
#if (defined(__GNUC__) && !defined(__PPC__))
or
#ifndef __PPC__
The PPC clib2 libamga.a amiga_callhooka.o can only be an useless, empty object.
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:11
#32
|
Home away from home
|
@joerg Quote:
You are suspending your own task, the one executing this code, and
Damn :) But if i will remove suspend/restart, i then will be not able to correctly obtain stack trace ? (tried now with removing, crashes on IDebug->StackTrace(..) ) Quote:
Is there an OS4 PPC libamiga.a with a CallHook() function?
Would be complete nonsense (unless all it does is calling IUtility->CallHookPkt()), but OTOH I wouldn't be surprised if clib2 has something like that.
Clib2 indeed have amiga_callhook.c and amiga_callhooka.c: https://github.com/adtools/clib2/blob/ ... rary/amiga_callhook.c#L49https://github.com/adtools/clib2/blob/ ... ary/amiga_callhooka.c#L61But this one compiles in only when build 68k version of clib2, for os4 it didn't (at least, as i see from Makefile's in Andrea's clib4 fork). But if i check libamiga.a from original clib2, i can see there "amiga_callhooka.o", which probabaly just an empty stabs, as code of CallHookA pure 68k asm. Quote:
CallHook() is no OS function but statically linked into m68k executables from the m68k libamiga.a,
Right, so then we can forget about CallHook() old stuff then. Probably the reasons why i have so small amount of CallHookPkt() calls on pure WB (50/s), is that nothing were runs which open up hooking functionality of all classes,libs,etc (through, i was under opinion that when WB load up, it already uses intuition heavy).
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 6:01
#33
|
Just can't stay away
|
@kas1e Quote: But when i run my test binary, it simply invokes one time call to CallHookPkt when reach a state of "stricmp" comparison that it's my binary i want to trace, and then nothing happens : test binary with CallHookPkt usage didn't runs, but also didn't crash , and in trace we stuck forever on SuspendTask.. right when we should obtain a stacktrace. Maybe i can't suspend process like that ? I mean:
SuspendTask(&process->pr_Task,0) ?
struct Process *process = (struct Process *)IExec->FindTask(NULL);
...
IExec->SuspendTask(&process->pr_Task,0);
You are suspending your own task, the one executing this code, and
uint32 result = IDebug->StackTrace(&process->pr_Task,hook);
IExec->RestartTask(&process->pr_Task,0);
can't be reached Quote: If you had access old source code of OS4, will it be no NDA-breaking if you will check if for example, those gadgets and datatypes you mention do use CallHookPkt(), or, still old CallHook() ? I don't have access to the sources, but using m68k libamiga.a CallHook() in PPC native code is impossible. It can only be used for emulated m68k hook functions called by emulated m68k code, only IUtility->CallHookPkt() can be used from PPC native code, checks if the hook function is PPC native (direct function call) or emulated m68k code (executing it with the m68k emulator). Is there an OS4 PPC libamiga.a with a CallHook() function? Would be complete nonsense (unless all it does is calling IUtility->CallHookPkt()), but OTOH I wouldn't be surprised if clib2 has something like that. Quote: And if there is a way how we can calculate pure CallHook() usage (not CallHookPkt()) in whole system per second ? CallHook() is no OS function but statically linked into m68k executables from the m68k libamiga.a, some implementations of libamiga.a CallHook() are even m68k assembler.
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: Yesterday 4:55
#34
|
Just popping in
|
@MamePPCA1
It's hard to answer without knowing what's stopping the partition showing up. But if they don't show up in DirOpus they won't appear in the other backup programs as well. However, with DirOpus you also need to add your partitions to the list on the left unless you right click on the "S" button near the centre, to see your partitions.
So when you booted the pen drive did they show up? Does your Workbench show up? If you can see that then you can at least back it up.
Also, be careful of SFSSalv. It's rather old now and SFS has been updated since. Since you have an X5000 you should also have Enhancer included. This has an updated SFS as well as PartitionWizard. This can check your partitions for errors and also do a backup. The Salvage option can back up to another drive.
You have SFS\2 volume as well. I've had one in the past but it broke. I had to salvage the data. As mentioned SFS\2 lacks recovery tools. I've avoided it since. I may have been able to backup by copying off Workbench before the filessystem totally destroyed itself.
It's recommend to use NGFS now as it's a modern filesystem with 64 bit support and can replace both SFS\2 and JXFS with a supported filesystem that has recovery tools. But, the catch is, it's only released for X5000. It's constantly updated to fix bugs. However, there's no easy way to update it, as you are expected to track down the developers email address and ask for it.
|
|
|
|
|
|
Re: Tracing
|
Posted on: Yesterday 4:25
#35
|
Home away from home
|
@joerg Is for every run of CallHookPkt i should install a hook, grab stack trace, and remove hook ? For now i have that: https://kas1e.mikendezign.com/aos4/tra ... llhookpkt_stacktrace_v1.cBut when i run my test binary, it simply invokes one time call to CallHookPkt when reach a state of "stricmp" comparison that it's my binary i want to trace, and then nothing happens : test binary with CallHookPkt usage didn't runs, but also didn't crash , and in trace we stuck forever on SuspendTask.. right when we should obtain a stacktrace. Maybe i can't suspend process like that ? I mean: SuspendTask(&process->pr_Task,0) ? ps. Btw: Quote:
I would have expected much more calls/s.
layers and graphics (for example the BackFill Hooks), intuition (incl. all BOOPSI gadgets, images and data types, Windows alpha/shape/scrolling/etc., ...), IIRC Dockies (AmiDock) as well, and a lot more in AmigaOS uses Hooks
With AmiDock's Dockies there indeed lots more CallHookPkt() happens: 250/s (while without, with pure plain system with WB loaded only 50/s). As for other intuitions and co hooks, it surely shows me just about 50/s. If you had access old source code of OS4, will it be no NDA-breaking if you will check if for example, those gadgets and datatypes you mention do use CallHookPkt(), or, still old CallHook() ? And interesting, that when i tried to trace for example this one: https://www.os4coding.net/sites/default/files/ra_appwindow_0.txt (creates AppWindow hook in the ReAction window object) it counts ~500 calls to CallHookPkt(). So maybe if i not use any class when load up system, then it didn't loaded up, so those CallHookPkt() isn't active. But once i load up first time a app which use intuition hooks, then it throw massive usage of the CallHookPkt() ? ps2: And if there is a way how we can calculate pure CallHook() usage (not CallHookPkt()) in whole system per second ? As far as i aware CallHook() were varags version of CallHookPkt(), so then finally any call to CallHook() go through CallHookPkt anyway..
Edited by kas1e on 2024/5/4 4:44:23
Edited by kas1e on 2024/5/4 4:57:21
Edited by kas1e on 2024/5/4 4:58:19
Edited by kas1e on 2024/5/4 5:34:51
Edited by kas1e on 2024/5/4 5:51:33
Edited by kas1e on 2024/5/4 5:55:28
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
|
Quite a regular 
|
@Hypex .Quote: Hypex wrote:@MamePPCA1
Personally, I've tried these backup programs before, but end up giving up. Not sure what it was but they can get stuck if a file system has errors. I tend to go back to Workbench even though that has flaws.
Both are old designs and a strange mix. One is 68K so using old DOS functions but simple enough. The other is updated for OS4 but still using an old interface and is slightly confusing to use.
I'd use the older BackUp given the choice. Just needs source and destination. But, you could also just use a tool like DirOpus. That may be the easier option. All you say is good but,how can I use an app like Directory Opus 4 if the partitions doesn't appear? I really need a solution to this mess as soon as possible.
|
|
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
|
Quite a regular
|
@joerg
OK I take note,but I think I've hearded it before.
|
|
Amiga 500 1MB Chip RAM with ACA 500+ACA1232,CD32,Amiga 1300 030/50 Mhz,32MB (now on my hands at least)and Amiga One G3 XE PPC 800 Mhz,ATI Radeon 9250 128 MB,256 MB RAM,Seagate 200 GB HD,2 working DVD drives,X-Arcade double for MAME,Sil0680,4 USB ports,LG
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg But then, if involved components didn't build with gstabs, i will be unable to see what happems even with stacktrace, right ? For example i cookie up this based on exec doc and spotless debugger:
#include <proto/exec.h>
#include <proto/dos.h>
#include <exec/types.h>
#include <exec/interrupts.h>
#include <exec/tasks.h>
#include <dos/dos.h>
#include <stdio.h>
int32 printStack(struct Hook *hook, struct Task *task, struct StackFrameMsg *frame)
{
switch (frame->State)
{
case STACK_FRAME_DECODED: {
IDOS->Printf("(%p) -> %p ", frame->StackPointer, frame->MemoryAddress);
struct DebugSymbol *symbol = IDebug->ObtainDebugSymbol(frame->MemoryAddress, NULL);
if (symbol) {
if(symbol->Type == DEBUG_SYMBOL_MODULE_STABS && symbol->SourceFileName)
IDOS->Printf("[%s: line %d]: %s", symbol->SourceFileName, symbol->SourceLineNumber, symbol->SourceFunctionName);
else if(symbol->SourceFunctionName)
IDOS->Printf("%s", symbol->SourceFunctionName);
else
IDOS->Printf("[%s]\n", symbol->Name);
IDebug->ReleaseDebugSymbol(symbol);
}
}
break;
case STACK_FRAME_INVALID_BACKCHAIN_PTR:
IDOS->Printf("(%p) invalid backchain pointer\n",frame->StackPointer);
break;
case STACK_FRAME_TRASHED_MEMORY_LOOP:
IDOS->Printf("(%p) trashed memory loop\n", frame->StackPointer);
break;
case STACK_FRAME_BACKCHAIN_PTR_LOOP:
IDOS->Printf("(%p) backchain pointer loop\n",frame->StackPointer);
break;
default:
IDOS->Printf("Unknown state=%lu\n", frame->State);
}
return 0; // Continue tracing.
}
int main()
{
struct Task *task = IExec->FindTask("Workbench");
if (task != NULL)
{
struct Hook *hook = IExec->AllocSysObjectTags(ASOT_HOOK, ASOHOOK_Entry, printStack, TAG_END);
if (hook != NULL)
{
IExec->SuspendTask(task, 0);
uint32 result = IDebug->StackTrace(task, hook);
IExec->RestartTask(task, 0);
IExec->FreeSysObject(ASOT_HOOK, hook);
}
}
}
And the output are:
12/0.Work:hooks> stacktrace
(0x64da8e80) -> 0x01806544 [kernel]
(0x64da8eb0) -> 0x0183c338 [kernel]
(0x64da8f10) -> 0x7ff0edd8 [LIBS:workbench.library]
(0x64da8fc0) -> 0x0185f2b4 [kernel]
(0x64da8fd0) -> 0x0185f32c [kernel]
So for "workbench" task we had this stack trace. At lest we can see the components involved ..
Edited by kas1e on 2024/5/4 4:26:04
|
|
|
|
|
|
Re: Snes9x NG version 1.62.3 release 4 Software/Opengl/EGL_Wrapper renderers
|
|
Quite a regular
|
@HunoPPC Quote:
Thank you for your feedback but I personally tested this new version on native machines (SAM440, software and opengl rendering actually goes through SDL1 but I don't see the connection).
The Qemu/Pegasos2 machine currently has problems with old SDL1 libraries and it leads to unsightly artifacts and distortions. The AmigaOneXe/Sam460 machine does not have these problems and we do not yet know exactly what the problem is, as the Pegasos2/AmigaOneXe machine is based on the same code. At the moment it is suspected that it could be something in the AmigaOs4.1 kernel that only occurs with the Pegasos2 version of AmigaOs4.1 in combination with the SiliconMotion 502 graphics card. As far as we know it is due to the 16-bit bitmaps of SDL1 SDL2 from version 2.26.5 uses 32-bit bitmaps in all applications and this also works very well under Qemu/Pegasos2. https://github.com/AmigaPorts/SDL/rele ... /v2.26.5-release-amigaos4If possible could you provide the software renderer via SDL2 so that it works on all systems? For example: MilkyTracker/BreakHack/LiteXL and new ports that use SDL2 libraries for software rendering work without problems. On real hardware it doesn't matter if the software renderer is available via SDL1 or SDL2 as 3D acceleration is mainly preferred here.
Edited by Maijestro on 2024/5/3 19:23:58
|
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Quote: Of course probably the best way will be to use GDB or db101/spotless, and instruction by instruction find out how the way from user application till final CallHookPkt() passed , but maybe it possible to trace without debugger and in more automatic way ? You have to implement a stack backtrace in your IUtility->CallHookPkt() patch using IDebug->StackTrace() (problem: It's using a hook as well and you have to exclude this hook in your patch, otherwise you'll get an endless loop and crashes), IDebug->ObtainDebugSymbol(), etc., just like the debuggers do.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
