Forums - All Posts - The Amigans website

Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770

Posted on: Yesterday 17:33 #21

Just can't stay away

@Hypex
Quote:

They started moving from static files to dynamic drawers in OSS2. But they didn't finish. And the Kicklayout reverts to the old way.

IIRC the SLB(_v2) file system API was very simple. It can load files, but that's it. No directory reading, or any other file system functions.
I don't know how the newer amigaboot.ub used on the X5000 and A1222 works, someone else ported my SLB_v2 SFS code to it.

Topic | Forum

Re: Tracing

Posted on: Yesterday 17:06 #22

Just can't stay away

@kas1e
Quote:

struct Hook *hookstack = IExec->AllocSysObjectTags(ASOT_HOOK, ASOHOOK_Entry, printStack, TAG_END);

You shouldn't allocate memory in a patched function as that will for example break a Forbid() or Disable() state.
You can't use the IDebug functions in the patch either, maybe StackTrace() is no problem if you use IExec->DebugPrintF() instead of IDOS->Printf(), but for example ObtainDebugSymbol() which has to re-open the ELF file handle can't be used.
Getting the symbols/module name and any output, except for DebugPrintF(), has to be done in your main() task, not in a task calling a patched function.

Instead of using task/CLI names I'd use the unique PID instead, if it's a DOS process and not an exec task.
"serial.device"? If that's really serial.device (or a replacement) it's probably not a DOS process.

Topic | Forum

Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)

Posted on: Yesterday 16:51 #23

Just can't stay away

@white
Quote:

A video card like this one for example with the exact specifications:
EBAY
https://tinyurl.com/2c699sf6

Similar, but that's a gfx card from Gigabyte.
The one geennaam used is a MSI one: https://www.techpowerup.com/vgabios/191488/191488
(probably https://www.techpowerup.com/gpu-specs/msi-r9-270x-gaming-oc.b2537 but this page doesn't include the PCI IDs to be 100% sure).
Even if the hardware may be the same just a different BIOS could cause problems.

Quote:

Apart from the Drivers.

Is the card recognized even without drivers?
I mean on real AmigaOS hardware it is recognized regardless of the drivers.

No, AmigaOS doesn't include a fallback VGA/VESA framebuffer driver.
On systems supporting PCIe (X1000, X5000, Sam460, A1222) a Lite version (max. resolution 800x600, no GPU HW acceleration) of the RadeonHD driver should be included in AmigaOS 4.1 and you can use that to install the full version from Enhancer Software (RadeonHD v3), or the separately available RadeonHD v5 driver for gfx cards requiring the newer version.
Of course it's in the PCI tree you can check for example with Ranger if you have a 2nd, supported gfx card installed, but without a gfx driver for it you can't use it for gfx output.

U-Boot should theoretically work with any VGA compatible gfx card, but it's old x86 emulator doesn't work with the BIOS of some newer gfx cards and may crash.

Edited by joerg on 2024/5/4 17:42:58

Topic | Forum

white

Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)

Posted on: Yesterday 15:22 #24

Quite a regular

Today I tried a normal compilation
so a simple one
./configure

and it gave me the error
meson flex and it came out
I updated:
"meson flex"

then again
./configure
ok everything went well.

but if I use for example a compilation only for PPC AmigaOS:
./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk -Doptimization=3

Here again the connection is lost every now and then again as in previous versions to version 9 of qemu.

so it seems strange to me that I can't complete:
./configure

without having to update "meson flex"

@joerg

This is a separate question,
Excuse me in which file do I find the string:

CFLAGS="-march=native -mtune=native" CXXFLAGS="-march=native -mtune=native"

@Maijestro

I've switched everything to SSD now so I have an SSD just for Linux and another just for AmigOS the old Crucial 250gb I used before.
This makes my job easier.
And I can put a lot of stuff in there

Topic | Forum

Re: Tracing

Posted on: Yesterday 13:30 #25

Home away from home

@LiveForIt
This all just for tests (serial.device i mean). Problem currently is seems in the fact that i set hook from hooked CallHookPkt(), and i need exclude my hook from patched CallHookPkt somehow (but can't see how can i do so by ObtainDebugSymbol() )

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum

LiveForIt

Re: Tracing

Posted on: Yesterday 12:42 #26

Home away from home

@kas1e


struct Task *task = IExec->FindTask("serial.device");

this is dangerous, you are now searching the task list for name, but list can change while you search. so it can crash.

you should do:


IExec->Forbid();

struct Task *task = IExec->FindTask("serial.device");

IExec->Premit();

but this can also be dangerous, because you do not know if your patched is being called inside a forbid(), the permit() can break the forbid() at the wrong time. So you should first check if your inside a forbid, before you do a forbid, and a permit.

Also, if your dealing with another task, it can be unloaded from memory, before you which. So again you should not peek & poke in another tasks Task struct, unless you know you have exclusive asses to it, task struct does not have a locking mechanism, mutex/semaphore, so you most block multitasking.

If you are just comparing task pointers, and not looking inside it, you don’t need to worry about it much, but it can be a different task, then you expected, as memory is often reused in AmigaOS4, but it highly unlikely. More likely the memory will end up being used for something else.


IExec->FindTask(NULL);

does not search the list, and is therefor is safe.
no forbid, permit needed. And if you are working on yourself, you expect nothing is unloaded.

Edited by LiveForIt on 2024/5/4 13:00:59
Edited by LiveForIt on 2024/5/4 14:06:22

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Topic | Forum

Re: Tracing

Posted on: Yesterday 11:35 #27

Home away from home

@Hypex
Ok, things start to clean up itself a bit. If i tried just this in the CallHookPkt() patching function, i then happy crash:


struct Task *task = IExec->FindTask("serial.device");



    if (task != NULL)

    {

      struct Hook *hookstack = IExec->AllocSysObjectTags(ASOT_HOOK, ASOHOOK_Entry, printStack, TAG_END);



      if (hookstack != NULL)

      {

        IExec->FreeSysObject(ASOT_HOOK, hookstack);

      }

    }

But when i put the same exactly code to the main , and leave patching function just pure return to original CallHookPkt, then it works.

So just setting of the Hook inside the patched CallHookPkt cause crash, not the issues with task/process/etc. And it does not matter what my actual printStack function are: i even tried it to be just an empty one.

I.e. pure set of any hook inside the patched CallHookPkt() = crash. Probably that what Joerg mean when says "Exclude own hook from patched CallHookPkt to avoid endless loop and crash" ? But then, my task is explicitly "serial.device", so not the main one ..

Edited by kas1e on 2024/5/4 11:59:05
Edited by kas1e on 2024/5/4 12:01:49
Edited by kas1e on 2024/5/4 12:04:20
Edited by kas1e on 2024/5/4 12:09:29
Edited by kas1e on 2024/5/4 12:12:43

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum

Re: Tracing

Posted on: Yesterday 11:04 #28

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 ?

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum

Re: Trying to get a Radeon HD 7750 working in an AmigaOne XE

Posted on: Yesterday 10:22 #29

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.

Topic | Forum

Re: Tracing

Posted on: Yesterday 9:36 #30

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.

Topic | Forum

Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770

Posted on: Yesterday 9:05 #31

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.

Topic | Forum

Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770

Posted on: Yesterday 8:48 #32

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.

Topic | Forum

Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770

Posted on: Yesterday 8:41 #33

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?

Topic | Forum

dooz

Re: A1222 support in the SDK and problems

Posted on: Yesterday 8:27 #34

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=2

Also 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=9032

I 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

Topic | Forum

Re: Tracing

Posted on: Yesterday 8:24 #35

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 ?

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum

Re: Tracing

Posted on: Yesterday 7:47 #36

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.

Topic | Forum

Re: Tracing

Posted on: Yesterday 6:29 #37

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).

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum

Re: Tracing

Posted on: Yesterday 6:27 #38

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__))


#ifndef __PPC__

The PPC clib2 libamga.a amiga_callhooka.o can only be an useless, empty object.

Topic | Forum

Re: Tracing

Posted on: Yesterday 6:11 #39

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#L49

https://github.com/adtools/clib2/blob/ ... ary/amiga_callhooka.c#L61

But 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).

Join us to improve dopus5!
AmigaOS4 on youtube

Topic | Forum