Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

(1) 2 3 4 ... 52 »

joerg

Re: X1000 and X5000 in Fractal Cases

Posted on: 4/17 20:03 #1

Just can't stay away

@rjd324
Quote:

Is the performance from X5 better than X1 due to sheer Hz horse power only?

The CPU in the X1000 should theoretically be better, but performance depends on the rest of the system as well.
Probably still the fastest system which could have been used for AmigaOS 4.x, even after more than 15 years, is the PlayStation 3 with it's cell coprocessors. Only very few of the PlayStation games did use the power of the cell coprocessors. Would have been cheap hardware compared to usual AmigaOS 4.x hardware, but not expandable and of course no hardware documentation was available for implementing other OSes on it.

Edited by joerg on 2022/4/18 3:41:20

Topic | Forum

joerg

Re: Help With X5000 Booting/UBoot (plus, general newbie x5000 questions)

Posted on: 4/17 18:11 #2

Just can't stay away

@daveyw
Quote:

Take care, it's vey easy to mangle uboot and make your machine unbootable (as I once did with a SAM that didn't belong to me and scrambled to fix!)

While you can kill some of the old systems with failed U-Boot updates and need to replace a chip to make them usable again (at least the AmigaOne SE, XE and Mini, not sure about the Sam systems, IIRC they should have U-Boot twice in the ROM and being able to switch between both versions if updating one of them failed, but I don't know if that really was implemented) you can't kill it just by changing U-Boot variables.
Any changes you do there which might lead to an unbootable system can easily be reverted.

On the X5000 there is no problem at all, U-Boot as well as it's variables are on a MicroSD card and in worst case all you have to do is to restore it from an image file (can be done on any other system with a MicroSD card reader), or replace it by a new MicroSD card with the U-Boot image stored on it.

Topic | Forum

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 19:21 #3

Just can't stay away

@kas1e
Sorry, but there is no difference.
IIRC I created the first AmigaOS 4.x version of z.library (a shared, AmigaOS native library port of libzip, not a .so one) and someone later implemented a different one, intentionally incompatible to my version.
Any software which was built using the includes of my z.library, but with the other, incompatible z.library installed in LIBS: instead, started crashing for no obvious reason.
It's exactly the same "dll-mess" as with shared objects.

Edit: Maybe it wasn't z.library but bzip2.library, but in any case it was one of the compression libraries for which someone created a version incompatible to my initial AimgaOS 4.x port.

Edited by joerg on 2022/4/16 19:37:09

Topic | Forum

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 18:53 #4

Just can't stay away

@kas1e
Quote:

Native amiga libraries are much better,

There is no difference, for example powerpc.library:
There are/were at least 4 different implementations of it (even if my implementation and it's predecessor, an even much older one which required patching WarpsOS executables, are obsolete now) the version numbers of the library don't help at all.

Topic | Forum

joerg

Re: New verson of CLiB2 from Andrea (afxgroup)

Posted on: 4/16 17:54 #5

Just can't stay away

@afxgroup
Quote:

I've made a lot of tests. even increasing __BUFSIZ__ doesn't help.

The clib2 __BUFSIZ__ was too large, not too small.

Quote:

I've compared the code but i don't see differences.

I don't remember what clib2 did wrong, but the following should be the relevant part of newlib (from stdio.h, but I'm not sure if that's the internal stdio.h, or the public stdio.h for users, in newlib different includes are used for building and using the library):


#define       __sputc_raw_r(__ptr, __c, __p) \

    (--(__p)->_w _w >= (__p)->_lbfsize ? \

            (*(__p)->_p = (__c)), *(__p)->_p != '\n' ? \

                (int)*(__p)->_p++ : \

                __swbuf_r(__ptr, '\n', __p) : \

            __swbuf_r(__ptr, (int)(__c), __p) : \

        (*(__p)->_p = (__c), (int)*(__p)->_p++))

#ifdef __SCLE

#define __sputc_r(__ptr, __c, __p) \

        ((((__p)->_flags & __SCLE) && ((__c) == '\n')) \

          ? __sputc_raw_r(__ptr, '\r', (__p)) : 0 , \

        __sputc_raw_r((__ptr), (__c), (__p)))

#else

#define __sputc_r(__ptr, __c, __p) __sputc_raw_r(__ptr, __c, __p)

#endif

Topic | Forum

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 17:09 #6

Just can't stay away

@kas1e
Quote:

Through, what i noticed : with shared objects, the startup of the scummvm is much longer. By much i mean +2-3 seconds taked out from startup just because shared objects used.

Of course shared objects are slower, instead of linking the libraries just once with the compiler/linker when building the executable using static link libraries, that part hast to be done each time an executable using shared objects is loaded.

Quote:

Maybe for time being we still can go "static" build route ? Or with all the engines enabled it's already out of memory ?

There should be no difference in the memory usage between static and shared libraries, everything is loaded in both cases.
Only if the shared objects are only loaded on a demand basis, i.e. using some kind of plug-in system, using shared objects requires less memory. But that needs special support using elf.library functions, just building the executables with gcc -use-dynld doesn't do that.

The only benefit of using shared instead of static libraries on AmigaOS 4.x is that the users can update shared objects without all developers using them having to rebuild their executables.

Topic | Forum

joerg

Re: New verson of CLiB2 from Andrea (afxgroup)

Posted on: 4/16 16:46 #7

Just can't stay away

@afxgroup
issue #37: newlib.library (at least my versions, I don't know anything about newer ones) uses the clib2 low level I/O functions for the platform specific low level I/O functions.
IIRC the main reasons stdio in newlib was much faster, additionally to the better high level I/O functions, were using a different __BUFSIZ__ and much better getc()/putc() functions.
Additionally make sure async I/O can't be enabled for regular files, only for sockets.

Topic | Forum

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/15 17:54 #8

Just can't stay away

@kas1e
Quote:

Probably it worth to test firstly on: 1). x86 linux, 2). ppc linux (on x5000). Then we will know much more about.

Linux PPC may not help any more. Like MIPS, ARM, etc. PPC CPUs support both big- and little-endian, and most still active Linux/PPC developers switched from using big-endian to little-edian (PPCLE).
It's slower and generally unusable, like any little-endian OS it requires a lot of workarounds for the wrong byte order, but a lot of current Linux software has endian bugs and only works in little-endian mode

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/15 5:22 #9

Just can't stay away

@Hedeon
Quote:

it seems that for example the PPC400 is a bit picky.

IIRC the FPU in the 440ep used in the Sam440ep isn't in the CPU core but external to it and crossing a cache line with a FPU access causes an alignment exception, which isn't the case for example on 60x, 750 and 74xy CPUs.
You don't get an alignment exception in your programs because the alignment exception handler in the 440ep HAL of the kernel takes care of it, but of course that's very slow.
It's probably the same for the 460 CPUs.
Quote:

Still, I think this is not an alignment problem.

If it would be an alignment problem he should get an alignment exception instead of a DSI one.

@LiveForIt
Quote:

I have not noticed an issue with that, but it will slow down the program if you have misalignments.

If it's not just a little bit slower it may be because it's emulated by an integer alignment exception handler in the kernel, just like the FPU one for the 440ep.

Topic | Forum

joerg

Re: X1000 and X5000 in Fractal Cases

Posted on: 4/14 19:20 #10

Just can't stay away

@rjd324
Quote:

I was surprised that the x5 has no altivec support.

The 5020/40 CPUs are QorIQ/PowerQUICC CPUs, built and optimized for network and I/O performance, not for using them for a PC or something similar.

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/14 18:19 #11

Just can't stay away

@Hedeon
Quote:

Integers can be accessed any way you like.

No. While 16 bit accesses, as in those sources, should work on any PowerPC CPU supported by AmigaOS 4.x, be it e300, e400 or e500 API ones, 32 and 64 bit accesses to odd addresses may not be supported by all of those PowerPC CPUs.
POWER CPUs, like the P6T in the X1000, may have even more strict alignment requirements for integers.

Edited by joerg on 2022/4/14 18:55:43
Edited by joerg on 2022/4/14 18:57:36

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/14 17:05 #12

Just can't stay away

@LiveForIt
Quote:

you can write this as:
do { r11 = *((short *) r3); r10 = blackbox(r11) ? //not sure what this does--> rlwimi r10,r11,0,16,31

Check for example rlwimi

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/12 16:27 #13

Just can't stay away

@kas1e
Quote:

Is anyone know if old WarpOS support "unalignment memory access" ?

What i mean, were these exceptions handled and emulated by WarpOS and by our powerpc.libraries be it old Joerg's one, or new one from Hedeon ?

Of course my powerpc.library includes an alignment exception hander, but I don't remember if it only emulates unaligned float/double accesses, which is required for nearly all WarpOS software using the FPU, or unaligned integer accesses as well.

Topic | Forum

joerg

Re: AmigaOne XE, Micro A1-C questions

Posted on: 4/10 19:09 #14

Just can't stay away

@sailor
Quote:

I checked the board, and I have DMA-fix and no USB-fix

I don't know what the USB-fix is, but the AmigaOne DMA "fix" destroyed much more than it fixed.
On a DMA unfixed AmigaOne the on-board ATA controller doesn't work reliable with DMA, but using DMA with a PCI PATA or SATA controller instead (sii3112, sii3114, sii0680, etc.) works without any problems.
On a DMA "fixed" AmigaOne the on-board ATA controller partially works using DMA (but IIRC not completely either, don't rely on it), but using a PCI DMA ATA controller doesn't work any more.

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/8 18:57 #15

Just can't stay away

@kas1e
Quote:

Yes, that what i do (check plz 2 latest posts from me with my_macros.i for sysv, and question about function whhich while looks ok in terms of sysv , but still crashes by some reassons)

Sorry, I don't understand PPC asm at all, I'd have to look up every instruction in a manual.
For example my powerpc.library is nearly 100% C code, with very few __asm__(inline) instructions added, unlike the newer versions which seem to be 100% PPC asm code instead.

Topic | Forum

joerg

Re: H&P PowerAsm

Posted on: 4/8 18:47 #16

Just can't stay away

@Hedeon
Quote:

wosdb uses WarpOS ppc exception handlers that are not(/cannot be ?) implemented as part of the warpos emulation on OS4. It is low-level kernel stuff.

In my powerpc.library WarpOS emulation it should be implemented, but that was only possible because I had access to both of the ExecNG as well as the WarpOS sources.

Topic | Forum

joerg

Re: WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

Posted on: 4/8 18:37 #17

Just can't stay away

@kas1e

Are you using mixed PPC asm and C code? In that case you may have to use the GCC arguments to use the PowerOpenAPI (WarpOS) instead of the (default) SysV one used by AmigaOS 4.x for the C parts. Or change the asm parts from PowerOpen to SysV.
I'd be very surprised if current AmigaOS 4.x GCC ports still support the PowerOpenAPI used by WarpOS at all, but the old GCC 2.9.x versions did support both APIs.
VBCC probably still supports both APIs as well if you don't want to use an ancient GCC version.

Topic | Forum

joerg

Re: Wipeout2097 progress

Posted on: 4/3 18:28 #18

Just can't stay away

@mufa
Quote:

Amigans not used your library for a long, long time. She does not work, for example, from x1000 or x5000.

Of course it can't work on X1000, X5000, A1220 and Sam460, my powerpc.library was implemented a long time before any of those systems were released, and any CPU needs special support, not only for completely different CPUs like the PA6T used in the X1000 but even for very similar CPUs like the 603e, 604, 750, 74xx and 440ep different code was required for working WarpOS emulation.

Topic | Forum

joerg

Re: Wipeout2097 progress

Posted on: 4/3 16:18 #19

Just can't stay away

@alfkil
Quote:

That and the float alignment issues.

Unless speed is an issue that's no problem.

IIRC even the OS4 kernel should have some float alignment exception emulation code for that (it's required for example for the 440 FPU anyway), but if not my powerpc.library does include exception handler code for unaligned float accesses of WarpOS software. Just because of using HUNK instead of for example ELF executables much of FPU the data is aligned wrong in all WarpOS software.

If it helps I could release the exception handler code, or even the complete sources, of my powerpc.library, to someone.
However there are several problems with that:
- My powerpc.library code is a big mess, I never found the time to properly comment the code.
- I don't have the time to help updating, or fixing bugs in it.
- I wont release it for free.
- And most important: After the very bad experiences with the former OS4 development team no (open) source code release from me any more. I would only release it to a single developer using a NDA, who then could release updated binaries, but not any sources based on it.

Topic | Forum

joerg

Re: 68k/OS3.x MatchFirst()/MatchNext()/etc errors on OS4 help need it

Posted on: 4/2 18:33 #20

Just can't stay away

@kas1e
Quote:

Maybe it can come from other DOS functions which inderectly run the MatchXXX functions ?

The Match#?() functions were obsolete functions, only left for compatibility to ancient m68k software, which definitely shouldn't be used inside dos.library itself.
Maybe it's not something directly in the sources you are using, but an old and broken (wrong data alignment) link library using those functions instead, or something in the m68k assembler parts with the same bugs?

IIRC some of the old C libraries (Lattice C, SAS C, etc.) used the dos.library Match#? functions as well.

Topic | Forum

Top

(1) 2 3 4 ... 52 »