Who's Online |
76 user(s) are online ( 46 user(s) are browsing Forums)
Members: 0
Guests: 76
more...
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: 5/8 14:41
#161
|
Not too shy to talk 
|
Tested few games, with Sam 440ep Flex using Radeon HD 7750. https://youtu.be/MWPsmwVkjsMCro-Mag Rally https://youtu.be/AYT4jtwsY1QOtto Matic https://youtu.be/l4z_l8uEXnsSteps to Required to make Radeon HD 7XXX work. 1. Update UBoot. UBoot 1.3.1g 04-Dec-2020 updater. 2. Get transparent PCI-PCIe bridge, with a P17C9X chip. It supports 66mhz bus. 3. Get PCIe x1 - PCIe x16 riser adapter. 4. Get compatible Radeon HD card. 5. Get A-EON's Enhancer Software 2.2 and install it. 6. Add text MODULE Kickstart/RadeonHD to SYS:Kickstart/kicklayout file, just after MODULE Kickstrat/PCIGraphics.card. 7. Install Hardware, it just should work now. NOTE. Brige card with PEX 8111 chip worked without a problems. It said it shouldn't work with Flex. https://youtu.be/VqkGFlqje6o
Edited by utri007 on 2024/5/8 21:51:00
Edited by utri007 on 2024/5/9 15:31:40
|
|
|
|
|
|
Re: AmigaOS 4.1 Final Edition Update 2 fatal failure
|
Posted on: 5/8 13:14
#162
|
Quite a regular 
|
@sacc-dude
OK but I have little money and it is for some other things.
My graphics card is an ATI Radeon that I don't remember the name and it has 256 MB
I don't know if I will bring my stuff to SACC meeting or AmiWest
|
|
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
|
Posted on: 5/8 12:24
#163
|
Just can't stay away 
|
@kas1e You are mixing signal bit numbers with signal masks. In the patch replace
IExec->Signal(&main_task->pr_Task, 1 << portsig);
by
IExec->Signal(&main_task->pr_Task, portsig);
You could remove the unused port and message parts and simply use something like
int8 portbit = IExec->AllocSignal(-1);
if (-1 == portbit) error;
else portsig = 1UL << portbit;
in main() to allocate a signal. Quote: portsig = 0x00000010
mainPort->mp_SigBit = 0x00000004
WTF ? :) Shouldn't it be the same ? Sig Bit is the 8 bit signal bit number (0-31), portsig a 32 bit signal mask: 1 << SigBit;
|
|
|
|
|
|
Re: My Amiga Projects
|
Posted on: 5/8 11:14
#164
|
Just popping in 
|
Hi!
Update to my projects:
Sin: No change since last time sadly. Still in works:
Heretic 2 68k: I expect this to be out still first half of 2024, this was the main project the last few weeks
Quake 2: Out for 68k and OS4
Two secret projects: They will be in the focus now actually, or one of them will. Both for OS4 and 68k. Currently mainly work on OS4 version is done.
There is one more project for 68k where I wonder on the feasibility, but would be something for "start of coding end of the year".
(So you see I am jumping to and fro between 68k and OS 4... I usually start with OS4 - ways better debug possibilities - and port back to 68k later in project). Want to support both platforms longterm (as to 68k mainly PiStorm and Vampire is interesting, but looking for other 68k options on the two secret projects)
|
|
|
|
|
|
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
|
Posted on: 5/8 11:09
#165
|
Quite a regular
|
@joerg
In practical terms
what would you recommend for qemu "Pegasos2"
do not create the SWAP partition I created it with 4GB double the RAM that you can have with qemu.
In this case, the Command to add in the startup-sequence:
Is C:BootLoader COMMANDLINE "NoDiskPager" also valid for Pegasos2 if I remove the SWAP ?
Could the system be more efficient ?
Is it valid only for the classic ?
I have currently changed to:
BlockSize 512
Buffers 10000
MaxTransfer FFFFFFF (maximum)
Mask 7FFFFFFC (32bit aligned)
I have not currently removed the SWAP
If I remove it, will it lead to invalidation of the disk ?
Edited by white on 2024/5/8 17:03:12
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home 
|
@joerg Quote:
Sending and waiting for signals does that.
Right, so.. i doing that: Out of functions at top:
uint32 portsig;
uint32 usersig;
struct Task *patched_task = NULL;
struct Task *main_task = NULL;
struct MsgPort *mainPort;
main():
main_task = IExec->FindTask(NULL);
BOOL ABORT = FALSE;
struct ProcessIDMessage *receivedMessage = NULL;
mainPort = IExec->AllocSysObjectTags(ASOT_PORT, ASOPORT_Signal, SIGB_SINGLE, TAG_END);
if(mainPort != NULL)
{
portsig = 1U Wait(portsig | usersig);
if (signal & portsig)
{
IExec->DebugPrintF("port signal\n");
/*while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort))
{
IExec->DebugPrintF("mainport received: ProcessID = %lu\n", receivedMessage->processID);
//IExec->ReplyMsg((struct Message *)receivedMessage);
IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);
}*/
IExec->DebugPrintF("port signal for 0x%08lx\n", patched_task);
//stack trace, etc.
IExec->Signal(patched_task, SIGF_SINGLE);
}
if (signal & usersig)
{
IExec->DebugPrintF("ctrl+c signal\n");
while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort)) { // make sure port is empty
IExec->ReplyMsg((struct Message *)receivedMessage);
}
ABORT = TRUE;
}
}
}
Patched CallHookPkt:
ULONG APICALL Patched_CallHookPkt(struct UtilityIFace *Self, struct Hook *hook, APTR object, APTR message) {
struct Process *process = (struct Process *)IExec->FindTask(NULL);
if (IS_PROCESS(process))
{
struct CommandLineInterface *cli = BADDR(process->pr_CLI);
if(cli)
{
if(cli->cli_Module)
{
static char buffer[128];
IDOS->CopyStringBSTRToC(cli->cli_CommandName,buffer,sizeof(buffer));
if(!stricmp(buffer,traced_binary))
{
if (&process->pr_Task != NULL)
{
if (hookstack != NULL)
{
patched_task = &process->pr_Task;
IExec->DebugPrintF("set signal!\n");
IExec->SetSignal(0, SIGF_SINGLE);
IExec->DebugPrintF("signal it!\n");
IExec->Signal(main_task, 1 Wait(SIGF_SINGLE);
IExec->DebugPrintF("CallHookPkt call # %d\n", callhookspkt_counts++);
}
}
}
}
}
}
return Original_CallHookPkt(Self, hook, object, message);
}
}
And on serial have that: Quote:
set signal!
signal it!
now wait!
And nothing happens, like, i never come to the main task like "portsig" never sends. I tried to replace Quote:
IExec->Signal(main_task, 1 << portsig);
on Quote:
IExec->Signal(main_task, 1 << mainPort->mp_SigBit);
And it works as expected ! Then i printf out the values of portsig (which should be mainPort->mp_SigBit), and of mainPort->mp_SigBit exactly, and they different! : Quote:
portsig = 0x00000010
mainPort->mp_SigBit = 0x00000004
WTF ? :) Shouldn't it be the same ?
Edited by kas1e on 2024/5/8 12:22:09
Edited by kas1e on 2024/5/8 12:23:17
Edited by kas1e on 2024/5/8 12:24:15
Edited by kas1e on 2024/5/8 12:26:25
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Quote: with global set as before for 150 CallHookPkts i only have 12 stacktraces Because you didn't stop the patched task and wait until the main() task is done with the stack trace. It can be done in different ways, sending messages, or SupendTask() in the patch and RestartTask() it in the main task after the stack trace is done, but using signals is the easiest way. Quote: So i need something like - 1 CallHookPkt happens - 1 stack trace provides. Sending and waiting for signals does that.
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg
The problem was that for single invoking of CallHookPkt from my test binary, we have 150 CallHookPkts in the system. So, idea was to catch all those 150 CallHookPkts, and made a stack traces out of them all (to see, from where all they come).
So, if we will now just stacktrace my single task, we will have just one stack trace for my process. While need to have all stack traces for all CallHookPkts : with global set as before for 150 CallHookPkts i only have 12 stacktraces. All i want is to know from where each CallHookPkts come , all 150.
So i need something like - 1 CallHookPkt happens - 1 stack trace provides. For this purposes i probabaly must to do suspend/restart of tasks, but again, with globals and without messaging this wasn't enough (12 stack traces for 150 callhookpkts only).
Now trying to find a easy way to catch every callhookpkt (but only when my binary invoking) and made a stacktrace of any of them.
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Quote: Aren't we tried to use messages/signals whatever for exactly purposes to send ProcessID from the patch to the main ? In your example, processID aren't transferred, which was the whole purpose of last 2 pages :) Yes, but I don't understand why. In your patch you are checking the task name or ProcessID and only do something for this single task. For a single task using signals is enough. Sending messages with the ProcessID to the main task would only be required if you want to debug different tasks at the same time.
|
|
|
|
|
|
Re: Compiling qemu X64 for OS4.1 (Ryzen) and also other CPU (MAC)
|
|
Just can't stay away
|
@balaton Quote: OK so basically buffers is a metadata cache, not related to caching file data but only directory entries so its size probably should be related to how many files are stored on the partition and how many of them are expected to be open at the same time. So it can be lower for archive volumes or volumes with large files but should be higher for sys or partition with many small files that are accessed frequently. For a partition with only few very large files used most of the time read-only you can use only a few buffers, but when writing it it will get slow as well since it's not only directories but several other file system block types like the bitmap of used/free blocks on the partition, pointers to the data blocks used by a file, etc. Quote: For swap will it be ignored whatever is set there or it's allocated but unused? If it's not allocated then it does not matter and can be left to default. If I got this correctly. All file system parameters are ignored, for example the block size as well since the swap partition has to use the CPU page size for it.
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@joerg
I am completely looses now :( Aren't we tried to use messages/signals whatever for exactly purposes to send ProcessID from the patch to the main ? In your example, processID aren't transferred, which was the whole purpose of last 2 pages :)
Aren't with your example we simply return to globals again ? Because i had to define patched_task and main_task as globals out of the functions, and we then back to the same as before (process_to_inspect = process); with only one difference that we add signals for wait and send now around.
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@Hypex Quote: I noticed those VARARGSS68K but I didn't see why they were necessary. Any emulation of 68K var args is internally to the emulators so shouldn't need to be exposed. Would have required 2 different implementations for all varagrs TagItem functions: One which can be called from PPC native code and a different one which can be called from emulated m68k code. Quote: Aside from that varargs are a common function practice in portable C code that can run on x86 or PPC and others so varargs never looked 68K exclusive to me. The C parts are common, but the implementation of varargs is CPU specific. IIRC on m68k everything is put on the stack, but on PPC the first 8 integer, FPU and AltiVec arguments are passed in registers and only if there are more the stack is used. VARARGS68K doesn't use the standard PPC varagrs method but only the stack, exactly like on m68k, and a single function can be called form both PPC native and emulated m68k code.
|
|
|
|
|
|
Re: 2024 - April - Space Cadet Pinball
|
|
Quite a regular
|
The competition has now ended.  Thanks to all for playing! Congratulations to the winner, 328gts!
|
|
|
|
|
|
Re: Tracing
|
|
Just can't stay away
|
@kas1e Stop allocating anything in your patched function, your patch code is running in a foreign tasks and you don't know in which state it is. Allocating anything, memory, ports, messages, etc., can for example break Forbid() since the memory, page, etc. allocator may have to wait for exclusive access with a mutex. As long as you only want to debug a single task messages aren't required, sending signals is enough. In the patch you can't allocate signals, for example fails if all are used already, use SIGF_SINGLE instead. For the main task you can allocate a signal. Something like patch function
patched_task = IExec->FindTask(NULL);
IExec->SetSignal(0, SIGF_SINGLE);
IExec->Signal(main_task, 1 << portsig)
IExec->Wait(SIGF_SINGLE);
main()
if (signal & portsig)
{
IExec->DebugPrintF("port signal for 0x%2508lx\n", patched_task);
stack trace, etc.
IExec->Signal(patched_task, SIGF_SINGLE);
}
|
|
|
|
|
|
Re: Tracing
|
|
Home away from home
|
@Hypex Quote:
So the simplest way if avoiding the reply port would be this:
Simple crashed right after i got "mainport received: ProcessID = 191" and code do "IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);". I.e. processID messages from patched hook fine first time, we receive it, print the value, but then, when we need to answer we crash. That how currently it looks like: part from patched callhookpkt:
if (&process->pr_Task != NULL)
{
if (hookstack != NULL)
{
struct ProcessIDMessage *message = (struct ProcessIDMessage *)IExec->AllocSysObjectTags(ASOT_MESSAGE,
ASOMSG_Size, sizeof(struct ProcessIDMessage),
ASOPORT_AllocSig, FALSE,
ASOPORT_Signal, SIGB_SINGLE,
ASOMSG_ReplyPort, NULL,
TAG_DONE);
if (message != NULL) {
message->processID = process->pr_ProcessID; // Get the process ID here
}
IExec->SetSignal(0, SIGF_SINGLE);
IExec->PutMsg(mainPort, (struct Message *)message);
IExec->Wait(SIGF_SINGLE);
IExec->FreeSysObject(ASOT_MESSAGE, message);
IExec->DebugPrintF("CallHookPkt call # %d\n", callhookspkt_counts++);
}
}
}
Part from main():
if (signal & portsig)
{
IExec->DebugPrintF("port signal\n");
while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort))
{
IExec->DebugPrintF("mainport received: ProcessID = %lu\n", receivedMessage->processID);
//IExec->ReplyMsg((struct Message *)receivedMessage);
IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);
}
}
|
|
|
|
|
|
Re: Tracing
|
|
Not too shy to talk
|
@kas1e Quote: You say i need local port to give a reply port, but I can avoid it, while can't (as i need it), but instead create it by some other than AllocSysObjectTags way as it have “allocation overhead” ? Or what you mean exactly ? Sorry was typing reply in a rush before bed time. Okay so by local port I meant a port local to your patched function. You don't necessarily need a port, it's just the messaging system is designed in a two way fashion, so a message is sent to a task and that task replies the message back when it has finished. The port doesn't need to be a normal port either where a message is sent back to. A message can be bounced back as a signal or even trigger a software interrupt as you've seen. By “allocation overhead” I mean needing to allocate memory on the fly. So by comparison local variables are less overhead as they just get reserved on the stack and avoid an API call. I'm most likely just being pedantic as I would avoid any system calls allocating resources inside a debug routine. Given OS4 has the slab allocator it's probably not such a big deal. Quote: As i understand it, you still suggest to use for AllocSysObjectTags also ASOPORT_Signal when allocation for message, and this mean i can not create second reply port, and handle it without ? (sounds strange!) But what about “allocation overhead” which you mention, then if AllocSysObjectTags() still should be used for ? Sorry, I see I've confused you. In this case you allocate a message. But it needs a reply port allocated as well. The reply port can just be specified as a signal using the ASOPORT_Signal tags as you have set up. But you will need to allocate a port with ASOT_PORT type and those tags. However, since you are only messaging your own task, you can just skip the reply port all together. It can be set to zero in the message, in which case it will just mark the message as free when replied back. In this case, you can simply skip another port, and just signal back directly. When your main task has finished with the message just grab the process ID from the ProcessIDMessage and signal it back. Quote: The main()'s code is not changed, of course. Hope you wasn't mean that i need to change that too and fully rewrite it to handle new sort of signal without receiving a reply ?:) It will need to bounce it back. You can use the ReplyMsg() mechanism which will need a port attached. Or just simply signal back with a SIGF_SINGLE in this case. That might be best in this case. It avoids setting up a port and you can just use a preset signal. Quote: And where is FreeSysObject() in your example ? Should't it be right after Wait(SIGF_SINGLE) ? Oh yes it should. I just focussed on the message and waiting for signal to go ahead and continue. Quote: ps. Never touched anything with all this messages, but after reading wiki were under impression that for communicate between 2 tasks i need one single port , in which i do this communication by messages, not that i need different port for each messages which should be send from one task to another.. In the common case two ports will be involved. For source and destination. Source sends to destination, which then replies it back to source when finished. So the simplest way if avoiding the reply port would be this:
IExec->DebugPrintF("port signal\n");
while(receivedMessage = (struct ProcessIDMessage *)IExec->GetMsg(mainPort))
{
IExec->DebugPrintF("mainport received: ProcessID = %lu\n", receivedMessage->processID);
//IExec->ReplyMsg((struct Message *)receivedMessage);
IExec->Signal((struct Task *)receivedMessage->processID, SIGF_SINGLE);
}
|
|
|
|
|
|
Re: 2024 - April - Space Cadet Pinball
|
Posted on: 5/7 22:54
#177
|
Just can't stay away
|
<Bumpy> This competition should probably be wound up and the result list revised - I was not the winner ultimately  . Best regards, Niels
|
|
|
|
|
|
Re: Attempting to upgrade Sam 440 with an R7 240 or HD 7770
|
Posted on: 5/7 21:18
#178
|
Not too shy to talk
|
@Spectre660
Nova Bridge is Warp3D support for a Radeon HD cards? It would make all old games work.
But before I buy it, I would like to test this more. I need games that support Warp3D Nova if I have figured it correctly?
|
|
|
|
|
|
Re: Tracing
|
Posted on: 5/7 20:30
#179
|
Home away from home
|
never mind
|
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.
|
|
|
|
Re: Tracing
|
Posted on: 5/7 20:15
#180
|
Home away from home
|
@balaton Quote:
. or maybe in the hooked function call suspend self after sending the message and from the main task call restart for the process ID that was passed in the message, then you won't need either a reply message port nor a signal.
That looks like the way to go , and sounds more easy!
|
|
|
|
|
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
