Who's Online |
54 user(s) are online ( 49 user(s) are browsing Forums)
Members: 0
Guests: 54
more...
|
|
|
|
|
Re: Introducing the Rear Window blog
|
Posted on: Yesterday 6:41
#21
|
Just popping in 
|
@Hans Quote: This brings up a good question: what could be done to keep users engaged?
I think it's new that's important; new software (or hardware, but there's not much most of us can do about that) is what stirs interest. But new games are of interest mainly to gamers, new development tools are of interest mainly to developers, and so on, while a new version of the OS is of interest to everyone. Since there's not much most of us can do about the OS either, I'll second the vote for more end-user software. Though development tools are also important, to make it easier to create new end-user software.
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
Posted on: Yesterday 6:23
#22
|
Just popping in
|
@trixie Quote: my personal manifesto for the summer
Does this mean we might see a new version of Rave this summer?
|
|
|
|
|
|
Re: clib2 vs newlib perfomance issues
|
Posted on: Yesterday 6:19
#23
|
Just popping in
|
@kas1e Quote:
#include
int main(void) {
for (int i = 0; i < 1000000; i++) {
printf("%3d %3d %3d\n", 255, 128, 0);
}
return 0;
}
What results do you get if you change printf line to
printf("255 128 0\n");
And what if you change it to:
puts("255 128 0");
And what if you redirect output to different place. Like some file in RAM: or to NIL:
|
|
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
Posted on: Yesterday 6:16
#24
|
Just popping in
|
@kas1e Quote: I switched to IPC only because I started losing strings (some had garbage when they shouldn't). I don't understand what was going wrong there. I can see strings disappearing after the patched call returns, since the calling program would be free to delete or modify them, and anything stack-based would of course go away. But it doesn't seem like that should happen if DebugPrintF() is called before the patch returns (assuming I'm correct that DebugPrintF() doesn't return until the entire string has been sent). Quote: About 64bit issue: i simple create patch_exceptions.c in which patch by hands functions which not fits into generic_patch(). Sounds like a plan. There are some functions that return 64-bit values too, if you get to the point of reporting on return codes.
|
|
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
Posted on: Yesterday 6:07
#25
|
Just popping in
|
@joerg Quote: ...endless loops (if you patch the memory allocation/free functions as well)... To prevent that you have to call the original version of any patched function that's called from within the patch. That would also apply to CopyMem(), PutMsg(), etc. And of course DebugPrintF(), if you call that from the patch.
|
|
|
|
|
|
Re: Catching memory corruption "in the act"
|
Posted on: Yesterday 5:42
#26
|
Quite a regular 
|
Back to the original topic, I was finally able to try the MMU protection method. Here's my example program:
#include <proto/exec.h>
#include <stdio.h>
#include <stdlib.h>
#define BUFFER_SIZE 48
#define MEM_ALIGN_SIZE 4096
#define MEM_GUARD_SIZE 4096
void *AllocMemory(int size, int protect)
{
UBYTE *ptr = IExec->AllocVecTags(MEM_GUARD_SIZE + size,
AVT_Type, MEMF_PRIVATE,
AVT_Alignment, MEM_ALIGN_SIZE,
TAG_END);
if (!ptr) return NULL;
if (protect)
{
struct MMUIFace *IMMU = (struct MMUIFace *)IExec->GetInterface((struct Library *)SysBase, (CONST_STRPTR)"MMU", 1, NULL);
ULONG attrs = IMMU->GetMemoryAttrs(ptr, 0);
IMMU->SetMemoryAttrs(ptr, MEM_GUARD_SIZE, (attrs | MEMATTRF_READ_ONLY));
IExec->DropInterface((struct Interface *)IMMU);
}
return ptr ? (ptr + MEM_GUARD_SIZE) : NULL;
}
void FreeMemory(void *block)
{
if (!block) return;
UBYTE *ptr = (UBYTE *)block;
IExec->FreeVec(ptr - MEM_GUARD_SIZE);
}
int main(int argc, char *argv[])
{
BOOL protect = (argc > 1) ? atoi(argv[1]) : 0;
printf("allocating %d bytes protect %d\n", BUFFER_SIZE, protect);
UBYTE *buf = AllocMemory(BUFFER_SIZE, protect);
if (!buf)
{
printf("allocation failed\n");
return 1;
}
printf("valid writes...\n");
for (int i = 0; i < BUFFER_SIZE; i++)
{
buf[i] = 0xFF;
}
printf("invalid write...\n");
buf[-1] = 0xFF;
printf("invalid writes...\n");
for (int i = 0; i < MEM_GUARD_SIZE; i++)
{
buf[-i] = 0xFF;
}
printf("freeing memory\n");
FreeMemory(buf);
return 0;
}
This works in my simple test case, but there's one catch: the actual project does a metric ton of small memory allocations. The 4KB overhead plus the alignment requirement makes the memory fragmented to the point where the allocations start to fail, even with a 512MB Z3 RAM expansion. I tried smaller guard blocks while keeping the alignment as 4KB, but that ended up causing all sorts of freezes and crashes. I guess my only option is Linux? :(
|
|
This is just like television, only you can see much further.
|
|
|
|
Re: AmigaOS 4 Monthly Roundup - June 2025
|
Posted on: 6/30 21:26
#27
|
Just popping in
|
Thanks for another roundup! I always look forward to your recap of the month 
|
|
- Thomas
|
|
|
|
Re: clib2 vs newlib perfomance issues
|
Posted on: 6/30 16:52
#29
|
Home away from home 
|
@joerg Quote:
Just browsed the clib4 sources a bit, and there is still a lot, way too much, crap from clib2 remaining.
Very simple example:
https://github.com/AmigaLabs/clib4/blob/master/library/stdio/lock.c
Just replacing the old, and probably only used for the AmigaOS 1.x-3.x compatibility of clib2, semaphores (based on Forbid()/Permit()!) by OS4 mutexes (based on atomic increment/decrement instructions) should result in a noticeable speed improvement.
Andrea tried to change it all on mutexes : https://github.com/AmigaLabs/clib4/commits/mutexes/ It change a shit :) And i really mean it : no single speed up. Same slow stuff for fwrite(), printf(), puts() and sprintf(). But what were found that if we commented out for example in fwrite.c, check_abourt, lock/unlock, we then gain a bit : like for fwrite it was 13s for test case, and with commented check_abort/lock/unlock start to be 8. Of course nothing mostly, as newlib gives 0.5s on same test, but still something to think about..
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/30 16:10
#30
|
Just popping in
|
And 76 degrees on my X5040 with a fan at 100%, purchased from Amedia Computer in 2024, is this normal?
In any case, it works.
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/30 14:09
#31
|
Just popping in
|
@daveyw To temp problematic cad-laptop I used Thermal GrizzlybKryonaut extreme paste. Probably bit extreme to Amigas but should work longer time. It didnt function correctly anymore because of temp. Freezes, shutdowns etc. https://www.thermal-grizzly.com/en/kryonaut-extreme/s-tg-ke-002-r
|
|
Peg2 1GHz G4, 1Gb mem, Radeon 9250
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/30 13:27
#32
|
Just popping in
|
As others have pointed out, it is probably time to remove the old thermal paste and do some cleanup and put new thermal paste there.
My AmigaONE X5000/020 was bought new from GGS-Data back in 2022-03-02... So I have had it a bit over 3 years now. I almost use it daily.
I live in the south of Sweden and we have summertime now and my CPU is showing between 65-67 degrees Celcius. Original fan, heatsink and themal paste.
|
|
Current Amiga computers: Vampire V4-SA, Sam460ex, A1-X5000/020
|
|
|
|
Re: Snork: New Tracing Tool for AmigaOS 4
|
|
Home away from home
|
@Joerg Quote:
and only a single, pre-allocated memory buffer per patched function isn't enough either: The (patched) functions might be called by different tasks at the same time.
How can i know how much buffers i need then if there can be any amount of diffent tasks calling for example allocvec() (probably lots at the same time) ? @msteed About 64bit issue: i simple create patch_exceptions.c in which patch by hands functions which not fits into generic_patch(). At moment there just 6 from dos.library using mixed 32/64bits args, intuitions ones as far as i see all fits into 32bit way.
|
|
|
|
|
|
Re: Introducing the Rear Window blog
|
|
Home away from home
|
@walkero Quote: But, this is the best approach for developers and people who want to dive deeper in the OS. For plain users, and we have observed that happening, the whole situation seems frustrating and they leave the community. There is a need to keep a healthy and productive environment for people to feel that things are moving forward. I just hope that the number of people who would care about the survival and expandability of the platform will increase every year. This brings up a good question: what could be done to keep users engaged? Obviously, more regular OS updates and news would help. But, that's in Hyperion Entertainment's hands. I think that more end-user software would help too. Something more than game ports (which are welcome, but not enough to keep things interesting). Hans
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
|
Not too shy to talk 
|
 This is how crappy the original cooler & thermal pad looks like.
|
|
|
|
|
|
Re: NVMe support for Sam460 Uboot - how about X5000?!
|
Posted on: 6/29 21:07
#36
|
Just popping in
|
@LiveForIt
Do you mean integrated in the Uboot, or for adding a module to the Kicklayout?
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/29 19:06
#37
|
Just popping in
|
@daveyw
Could you please post your feedback and the reference of the thermal pad you chose?
|
|
A1200PPC/Sam440ep/Sam460ex/X1000/X5020 OS4.1
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/29 18:50
#38
|
Not too shy to talk
|
Thanks, I will look at replacing the thermal pad. I see they come in different sizes, any idea what size I need? Or any size and cut to fit?
TJ, highly recommend the X5000 cpu temp docky skynet linked.
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/29 16:50
#39
|
Just popping in
|
|
|
|
|
|
|
Re: X5000 maybe dying :(
|
Posted on: 6/29 15:36
#40
|
Not too shy to talk
|
@daveyw
What app or tool are you using that properly shows the Temps for the AmigaOne X5000?
Hopefully you can get this issue fixed.
Thanks
TJ
|
|
|
|
|
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
