Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

(1) 2 3 4 ... 58 »

joerg

Re: I don't get ScreenMode prefs and monitors

Posted on: Yesterday 15:50 #1

Just can't stay away

@densho
Did you add VSYNCMIN=30 in the tooltypes when trying the 3840x1600@30hz mode?

Topic | Forum

joerg

Re: Task scheduler

Posted on: Yesterday 14:56 #2

Just can't stay away

@Ami603

I may still have the sources in some old backups, but nothing I can access currently. You can release it if you want, but if it's working the way I think it did it it could be that it requires internal exec includes not part of public SDKs (struct ETask).

I found several different top.lha in the OS4 beta mailinglist in my Thunderbird backups between 2006 and 2008, but even if they have the same name, and as Niels wrote no version strings, they may work completely different. At least the oldest versions couldn't use the CPUs usage timer from ExecNG in struct ETask yet, it was an ugly hack using interrupts instead...

Edited by joerg on 2023/3/24 15:26:01

Topic | Forum

joerg

Re: Task scheduler

Posted on: 3/23 17:25 #3

Just can't stay away

Unlike the old AmigaOS <= 3.9 one the AmigaOS 4.x ExecNG task scheduler does record the CPU usage times of the executed tasks.
I don't know if tools like SysMon, Scout, etc., can display it, but I implemented a "top" like, shell-only tool several years ago which did.
IIRC I never did a public release of it and it was only available on the internal OS4 developer/beta-tester FTP server, but in the unlikely case it's still working (very likely doesn't work with beta multi-core kernels) it's OK to upload it to os4depot.net if one of the former OS4 developers or beta testers still has it.

Topic | Forum

joerg

Re: SFS2 buffer alignment issue

Posted on: 3/23 16:06 #4

Just can't stay away

@geennaam
Quote:

Let's assume that you're telling the truth that is was the "official" direction to solve alignment issues at the destination (drivers) instead of the source (OS4 applications).

Putting the alignment requirements into the applications instead of the device drivers wasn't possible when the AmigaOS 4.x project was started, 99,9% of the applications were still old AmigaOS 3.x/m68k software.

As for the documentation: I don't know where it is, I only did some AmigaOS 4.x development but none of the documentation parts, and I'm no longer part of the AmigaOS 4.x development team since a very long time.

Quote:

And why is there still the option to set those masks in media toolbox of OS4.1FE when it was "officially" decided to ignore them for >os3.9 anyways? Or did the OS4 team envision that the future for OS4 was to use old 68k mass storage drivers?

It's required for classic Amigas (A1200/A3000[T]/A4000[T]) where AmigaOS 4.x is booted by AmigaOS 3.x using AmigaOS 3.x/m68k device drivers and 3.x/m68k filesystems.

Quote:

And why is Sfs2 exposing this issue where ngfs isn't?

No idea, I don't know how NGFS works internally.

But I did have access to the FFS2 sources and IIRC it should be the same as with SFS2, at least if you use Mask 0xFFFFFFFF in the RDB.
(FFS2 was using the same sources for the AmigaOS 3.x/m68k, 4.x/PPC and MorphOS/PPC versions, still supporting Mask/MaxTransfer/etc. in all versions. For SFS I used independent sources for both versions instead and only the 3.x/m68k sources still included the Mask/MaxTransfer/etc. support.)

Edited by joerg on 2023/3/23 16:50:09
Edited by joerg on 2023/3/23 16:50:45

Topic | Forum

joerg

Re: SFS2 buffer alignment issue

Posted on: 3/23 14:51 #5

Just can't stay away

@geennaam
Quote:

Ok, so the rules are: There are no rules in the Amiga jungle.

Wrong, it was decided by the AmigaOS 4.x development team more than 20 years ago that AmigaOS 4.x device drivers have to work with any alignment, any transfer sizes (as long as it's a multiple of the sector size) and any memory type and hacks like Mask/MaxTransfer/BufMemType/etc. are no longer supported.

One of the reasons was that the Mask/MaxTransfer/BufMemType/etc. workarounds for broken drivers used in AmigaOS <= 3.9 can only be used by filesystems on HDs using a RDB, but nothing else using device I/O (MediaToolBox, AmiDVD, etc.) can get such information to implement required workarounds for specific device drivers and even filesystems used on removable media (CD/DVD, USB, etc.) can't work that way.
Another reason was that users usually don't know which bugs/limits device drivers have and which workarounds (Mask, MaxTransfer, etc.) may have to be added in all partitions of a HD in the RDB in HDToolBox/MediaToolBox.

Quote:

Only to find out that the actual speed will be nowhere near its potential. Just marginally faster than SATA.

There is no speed difference between a filesystem using an intermediate buffer or the device driver doing it for transfers not supported by the hardware. In your example it's a memory pointer in LhA which isn't aligned, not something in the filesystem.

Edited by joerg on 2023/3/23 15:12:01

Topic | Forum

joerg

Re: SFS2 buffer alignment issue

Posted on: 3/23 6:04 #6

Just can't stay away

@geennaam
Quote:

Does SFS2 ignore the Mask setting on purpose?

Yes, as well the other workarounds for old, broken device drivers (MaxTransfer, BufMemType, etc.) which had to be used on AmigaOS <= 3.9.

Quote:

So is there a way to force SFS2 accesses to be at least 32bit aligned?

No, except for using an AmigaOS 3.x/m68k version instead of the AmigaOS 4.x/PPC one

Internal reads/writes (buffers, caches, incl. the diskcache.library ones, etc.) are block size, or at least 32 byte (CPU cache line), aligned, but for direct reads/writes to/from application data pointers SFS doesn't change anything and passes the address and size to the device driver.

Quote:

I could work around it to detect the non-aligned transfer and move the read/write contents to a 32bit aligned intermediate buffer.

AmigaOS 4.x device drivers have to do that, not only for unsupported alignment but unsupported (too large) transfer sizes or physically fragmented memory (when using DMA) as well.
Quote:

But I like to avoid this because it will result in a performance penalty.

Of course, but it would be even worse if the filesystems would do it instead of the device drivers, only the device drivers know their exact hardware limits.

Topic | Forum

joerg

Re: How does AmiUpdate work internally?

Posted on: 3/15 16:56 #7

Just can't stay away

@rjd324
Rollback disabled in the AmiUpdate preferences?

I don't remember how AmiUpdate checks the versions of libraries, if it's using the real library version by loading a library and using struct Library* or by checking the $VER: string.
If it's using the $VER: string and newlib.library.kmod has a $VER: simply change the version there to something lower in the SYS:Kickstart/newlib.library.kmod file and restart AmiUpdate. Ugly hack, but may work.

Topic | Forum

joerg

Re: The ADTOOLS thread

Posted on: 3/15 16:17 #8

Just can't stay away

shcrtbegin.c:


static void (*__CTOR_LIST__[1])(void) __attribute__((section(".ctors")));

static void (*__DTOR_LIST__[1])(void) __attribute__((section(".dtors")));

should be


static void (*__CTOR_LIST__[1])(void) __attribute__((section(".ctors"))) = {(void *)~0};

static void (*__DTOR_LIST__[1])(void) __attribute__((section(".dtors")))= {(void *)~0};

instead.

extern void (*__CTOR_LIST__[])(void); in __shlib_call_constructors() and extern void (*__DTOR_LIST__[])(void); in __shlib_call_destructors() should be removed.

shcrtend.c:


static void (*__CTOR_LIST__[1])(void) __attribute__((used, section(".ctors")));

static void (*__DTOR_LIST__[1])(void) __attribute__((used, section(".dtors")));

should be changed to


static void (*__CTOR_LIST__[1])(void) __attribute__((used, section(".ctors"))) = {NULL};

static void (*__DTOR_LIST__[1])(void) __attribute__((used, section(".dtors"))) = {NULL};

amigaos.h / linker scripts:
%(link_thread) in LINK_SPEC seems to be inserted too early, before startfile is used. Should be changed to make sure link_thread is used between startfile and endfile.

Edited by joerg on 2023/3/15 16:45:32

Topic | Forum

joerg

Re: How does AmiUpdate work internally?

Posted on: 3/15 16:01 #9

Just can't stay away

@rjd324
AmiUpdate only checks the version of a single component in a package, in this case newlib.library.kmod
libc.a shouldn't be in newlib updates anyway, maybe libc.so but not libc.a. It's, or at least was while I still maintained it, an user-only package, developers parts are in the SDK instead.

For other cases you can use SystemRollback to restore an older version, but for the newlib libc.a that doesn't help.

Documentation for AmiUpdate is available on http://amiupdate.codebench.co.uk/index.php?page=description

Topic | Forum

joerg

Re: ISO making SW

Posted on: 3/14 19:21 #10

Just can't stay away

@rjd324
Quote:

Is AmiDVD the software?
I heard, before, that a third party sata controller was needed. Like some SIL thing that you plugged into PCI(e) and that you plugged your drive into.

The enhancer software version of AmiDVD should work with any SCSI, PATA and SATA controller supported by AmigaOS 4.x, incl. the onboard classic Amiga A1200/A4000/CyberStormPPC/BlizzardPPC, as well as the NG EyeTech AmigaOne SE/XE/μ-A1, Sam440/460, X1000 and X5000 ones. IIRC only the A4000T SCSI controller doesn't work, but that's not a problem in AmiDVD but the scsi.device driver.
AFAIK the only problem with the current public enhancer version of AmiDVD is that it doesn't work with some beta X1000 and X5000 (and maybe A1222) kernels, for them a not yet released beta version of AmiDVD is required.

Topic | Forum

joerg

Re: MacOS formated drives on OS4.1

Posted on: 3/14 19:06 #11

Just can't stay away

@eliyahu
Quote:

What about HFS and HFS from the classic Mac OS 9.x days?

My AmigaOS 4.x CDFileSystem port did include some minimal, read-only HFS and HFS+ support, but since Hyperion no longer has a licence for it you may need an old version of AmigaOS 4.1 which still included it (probably any AmigaOS 4.1 version older than FE).
It was only intended for HFS(+) CDs/DVDs, but it did work with HFS(+) HD partitions as well, for example you could read ShapeShifter partitions with it.

Topic | Forum

joerg

Re: The ADTOOLS thread

Posted on: 3/14 18:59 #12

Just can't stay away

@rjd324
Quote:

What I do not understand is that we have someone saying that libstdc++.so CANNOT work if it is not linking with c, gcc etc, and yet we have you who is saying that everything works: when I say everything - I mean being able to invoke a test program using shared libraries and ... it running; not that binutils is perfect or anything.

I wrote it very likely doesn't work without the NEEDED parts in SOs with clib2 (but I'm not 100% sure), but it should work with newlib instead - unless one of the very few libc functions which isn't just a foobar() stub calling INewlib->foobar() but includes actual code and/or data in libc.so is used, in which case the newlib version probably doesn't work either.

afxgroup wrote as well that it does not work - unless he is using a beta elf.library.
If it only works with clib2 using a beta elf.library but not with the public elf.library something is definitely wrong in the clib2 support, either in the clib2 (sh)crtbegin/end code or arrays, or some of the clib2 parts of the linker scripts.

Are the sources of gthr-amigaos-native.c, clib2 amigaos.h, clib2 (sh)crtbegin/end.c and the clib2 linker scripts available online somewhere, displayable using a web browser?
If yes I could check them, but I don't have the time to checkout code using CVS/SVN/GIT/whatever.

Topic | Forum

joerg

Re: The ADTOOLS thread

Posted on: 3/14 6:20 #13

Just can't stay away

@rjd324
Quote:

See my comment above, but the [cd]tors are there, just only when finally linking an executable using -with-dynld. They are just not in the libstdc++.so SO.

The libstdc++.so [cd]tors have to be inside libstdc++.so, just like in the Linux version.
The difference is just that the Linux version use the newer method and has them in .init/.fini_array in the readelf output and the AmigaOS4 version would have to have them in .ctors/.dtors instead using the older method, but there is no CTORS/DTORS section in the AmigaOS4 readelf output (and no INIT/FINI_ARRAY sections either).

Quote:

As I see when building with newlib and using GCC 11.3 and BINUTILS 2.23.2 then SO are working.

Did I get the QT6 thread completely wrong? I thought it doesn't work with newlib either and that's the reason a beta elf.library with some workarounds was createad?

If it's working correctly with newlib there are only a few possible reasons why it doesn't work with clib2:
- something is wrong in the clib2 amigaos.h you are using
- bugs in the clib2 (sh)crtbegin/end code or arrays
- bugs in the clib2 parts of the linker scripts

I did build a shared object version of clib2 about 15-20 years ago and added the required support in my local linker scripts (binutils 2.14.x). IIRC just using a 1:1 copy of the newlib shared objects parts didn't work but it required some clib2 specific changes in the linker scripts to get it working correctly.

Quote:

attempt to open /home/rjd/projects/adtools_test/build/4afx/4afx_build/lib/gcc/ppc-amigaos/11.3.0/clib2/gthr-amigaos-native.o succeeded
/home/rjd/projects/adtools_test/build/4afx/4afx_build/lib/gcc/ppc-amigaos/11.3.0/clib2/gthr-amigaos-native.o
attempt to open /home/rjd/projects/adtools_test/build/4afx/4afx_build/ppc-amigaos/SDK/clib2/lib/crtbegin.o succeeded

I don't know what gthr-amigaos-native is. Make sure it doesn't include any constructors or descructors, there never must by any before the ctor array in (sh)crtbegion.o is linked into an executable or shared object.
The -use-dynld option seems to be missing in the g++ command line?

Quote:

At the moment, when building the single test exectuable (test in directory named "1" in tests) I notice that it is linked with crtbegin/crtend. ...
This is not what the Linux version does. The libstdc++.so is linked with crtbeginS/end (shared version, hence the S) and so is the test binary. I notice that when I add "-shared" in the ppc-amigaos-g++ command then the shcrtbegin/end files are used. This is probably due to the linker script copied over which only uses those when the shared option is provided.

Linux works differently.
On AmigaOS4 shared objects have to be linked with shcrtbegin.o and shcrtend.o (gcc -shared ...) but the executables have to be linked with crtbegin.o and crtend.o instead, no matter if using static or shared linking (for using shared objects gcc -use-dynld ... has to be used).

Edited by joerg on 2023/3/14 6:44:09

Topic | Forum

joerg

Re: The ADTOOLS thread

Posted on: 3/12 17:50 #14

Just can't stay away

@MigthyMax
Quote:

I think rjd324 is even using the unreleased improved elf.library from elfpipe. And so it can even work without ctors/dtors, because as long i understood eflpipe moved the constructor/destructor handling into the elf.library.

It may work without __shlib_call_constructors() and __shlib_call_destructors(), but it can't work if the constructor/destructor function pointers are removed from the shared object, which seems to be the case according to the AmigaOS readelf output of libstdc++.so.

Quote:

This further means, depending on how much effort elfpipe put into it, even newer mechanism can be supported by the elf.library. And additional the handling is decoupled from the used clib, it doesn't need anymore to provide __shlib_call_constructors() and __shlib_call_destructors() function.

By using __shlib_call_constructors() and __shlib_call_destructors() you could switch from .ctors/.dtors to .init_array/.fini_array without requiring a beta elf.library, only shcrtbegin/end of the C libraries have to be updated which can be done by everyone and you can release software using the new method without having to wait until there is a public update of elf.library (if there ever will be any at all).

IMHO the main problem is that he is tying to use GCC 11.3 and binutils 2.23.2 (+ maybe beta elf.library).
It's known that that doesn't work currently. What should be done instead is
- test GCC 11.3 with binutils 2.14.x
- test GCC 3.4.x with binutils 2.23.2
If one of both works it's much easier to update the AmigaOS4 parts.
binutils definitely needs updates in the AmigaOS4 parts, but I'd be very surprised if current GCC versions work without changes in the AmigaOS4 parts.
First getting current versions of GCC work with binutils 2.14.x
(if it doesn't already work) and only after that updating binutils should be the easiest way. But in any case do it one by one, either first get current GCC or first current binutils working correctly on AmigaOS4, not both at once.
Additionally not trying to update the last known working version (in case of GCC that should be version 3.4.x or maybe 4.0.x) directly to the current version, but for example first GCC to 6.x, then to 8.x, 10.x, etc. would make it much easier to find out by which changes the ancient AmigaOS4 parts stopped working as indented and to update them.

Topic | Forum

joerg

Re: My AmigaOne X5000 twins - I need some help and advice.

Posted on: 3/11 8:40 #15

Just can't stay away

(deleted double post)

Topic | Forum

joerg

Re: My AmigaOne X5000 twins - I need some help and advice.

Posted on: 3/11 8:40 #16

Just can't stay away

@trixie
Quote:

Additionally, here is a list of national authorities that deal with customer protection.

That doesn't help since magic isn't a resident of an EU country.
But the "Guarantees for faulty goods" information on https://europa.eu/youreurope/citizens/ ... tees-returns/index_en.htm should be enough to understand which rights he has, no matter if he is an EU resident, or a customer from outside of the EU buying something from an EU dealer.

Topic | Forum

joerg

Re: The ADTOOLS thread

Posted on: 3/11 6:58 #17

Just can't stay away

@rjd324
First of all you can't compare newlib with clib2 (or any other C library), newlib doesn't have a "usual" libc (it's just stub functions calling the newlib.library ones, with very few exceptions there is no code nor data in newlib's libc, it's in newlib.library instead) and no libm at all, while in clib2 the actual code is in libc/libm.
While a newlib libstdc++.so may work without NEEDED libc/libm/libgcc the clib2 one very likely can't.

(sh)crtbegin/end and differences to Unix systems:
Unix executables are started at address 0 of the code (each task has it's own virtual address space), AmigaOS4 can't do something like that (the address space is shared between all tasks) but uses the _start() function instead. _start() is in crtbegin and, among other setup tasks, calls the local constructor/destructor functions of the executable (and statically linked libraries) and IElf->InitSHLibs() for the constructor/destructor functions of shared objects used by the executable.
Shared objects don't need a _start() function but the __shlib_call_constructors() and __shlib_call_destructors() functions called by elf.library instead to call the constructor/destructor functions inside the .ctors/.dtors sections of the shared object. Because of those differences it's required to have different crtbegin/end for executables and shcrtbegin/end for shared objects.
Unix switched to using .init_array/.fini_array instead of .ctors/.dtors several years ago, which results in major differences, you can't compare the way current Unix systems use shared objects with the about 20 years old .ctors/.dtors method AmigaOS4 is still using.

Edit: The readelf output of AmigaOS version doesn't include any ctors/dtors section!? It can't work without them.
Edit2: According to https://maskray.me/blog/2021-11-07-init-ctors-init-array only MinGW and PlayStation 4 still used .ctors/.dtors instead of .init_array/.fini_array. If that's still the case 1 1/2 years later some MinGW/PS4 parts of binutils may have to be used for AmigaOS4.

Edited by joerg on 2023/3/11 7:19:50
Edited by joerg on 2023/3/11 8:03:25

Topic | Forum

joerg

Re: power managment and gfx cards discussion

Posted on: 3/4 10:39 #18

Just can't stay away

@Hans
Quote:

EDIT2: Are these results from an emulated Pegasos II + SM502?

All CPUs supported by the Pegasos II (750, 74xy) have an L2 cache, the results on your page have 0 bytes L2 cache. Definitely some kind of emulation, or fake results.

Best result from a real Pegasos II seems to be https://ns.hdrlab.org.nz/benchmark/gfx ... 2d/OS/AmigaOS/Result/2155

Edited by joerg on 2023/3/4 18:27:26

Topic | Forum

joerg

Re: power managment and gfx cards discussion

Posted on: 3/4 10:12 #19

Just can't stay away

@rjd324
Quote:

This is my reference point:
http://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2346
...
But, I have no idea who is a beta tester on there

Reference has graphics.library 54.252 (with X5000/A1222 DMA support from salass00), it's from an OS4 developer or beta tester.

You have graphics.library 54.248, which doesn't include the X5000 DMA support yet.

Topic | Forum

joerg

Re: AllocBitMap vs AllocBitMapTags

Posted on: 2/26 5:00 #20

Just can't stay away

@Hypex
Quote:

I mean palette based with an index. So even if we compare with 8 bit chunky it needs scaling with a LUT to a direct value. Indirect to direct.

Maybe it's surprising but 8 bit RGB modes really did exist in the 80s/90s, IIRC the Amiga Zorro III Merlin GFX card did support an R2G3B2 mode while all other (Amiga) gfx cards from that time were limited to CLUT (all supported 8 bit chunky modes, some additionally 8 bit planar modes) and YUV for <= 8 bits.
But there never ever was any 1 bit RBG gfx card

The RGB8 formats are irrelevant nowadays, only still required for MSX and Sega emulators maybe.

Except for such rare exceptions and YUV, no matter if it's planar or chunky, with <= 8 bits/pixel it's always a palette based mode with CLUT.

Topic | Forum

Top

(1) 2 3 4 ... 58 »