@hotrod i managed to start the game using eaudio.device from amines. Otherwise I had the same issue on sam460. But the sound is choppy this way.

@joerg

Your suggesting was added it to back of name, but you add it to front of name perhaps.
clib4_libsdl_x.x.x.x.so

this why list of files will be sorted.

I think troublesome, considering that most stuff, is ported from other OS’s,
you need modify the build process to add the “clib4” part to the name.

__attribute__((__used__)) const char *os4_c_library = “clib4”;
can be put into the link library and forgotten.

so can someone summarise the current status of the latest revision?

@smarkusg

I am glad, you got it working. This port took some amount of time. If you are wondering about the build up with platform plugins, that is not used by this version, I did this exactly because it makes it much easier to do a static version. It really does not make so much difference, although it probably makes it more difficult to argue for a merge with the upstream.

Happy experimenting! :) If you want to share more, please do.

EDIT: I am going to look at the gles2 bindings some time in a not too distant future.

what is the difference between clib2 and clib4?

ah ok got it ! to be honest these are not installed since I am not using IRC at all (I think I just tried once in my whole life) but I would have been tempted with your new web app because I would not have to install anything...

@rjd324
A separate directory like SOBJS:clib4/ isn't required, nor any changes in the compiler/linker (ld) and the loader (elf.library), just make sure any .so using clib4 has "clib4" in it's soname, for example use -soname libSDL_gfx_clib4.so.23 instead of -soname libSDL_gfx.so.23 (newlib) when building libSDL_gfx.so.
Although most developers ignored it, and created a linux/windows like .so/.dll hell instead, there never must be any soft links in SOBJS:

Instead it should be done the following way:
- In the SDK (newlib/lib, clib/lib, etc.) directory you have a libFOOBAR.so, which may be a soft link to the current version, build for example with -soname libFOOBAR.1.2.3.so (newlib) or -soname libFOOBAR.1.2.3_clib4.so (clib4) for version 1.2.3.
- In SOBJS: (and PROGDIR, PROGDIR:sobs) there never is any libFOOBAR.so, and especially no libFOOBAR.so soft link to a specific version, but just the regular files libFOOBAR.1.2.3.so and libFOOBAR.1.2.3_clib4.so.

GCC/ld uses the (current) libFOOBAR.so version from the SDK:(newlib|clib4|ixemul|whatever)/lib directory when linking the executable. It never must use anything from SOBJS: instead for linking!
The loader/elf.library doesn't use (SOBJS:|PROGDIR:|PROGDIR:Sobjs/)libFOOBAR.so when loading an executable linked with it, but uses the soname from it instead (libFOOBAR.1.2.3.so, libFOOBAR.1.2.3_clib4.so, libFOOBAR.1.2.3_ixemul.so, ...).

If it would be done correctly, as proposed and used by the OS4 development team about 20 years ago, there never would be any problems with different .so versions (different versions of the library, using different C libraries, etc.) of the same library as all of them in SOBJS: (and PROGDIR:, PROGDIR:Sobjs/) have a different file and soname.

@LiveForIt

Quote:

You are confusing something here, it is not about updating old documents, but about being able to add to my own articles if something should have changed.

Perhaps I have just expressed myself incorrectly

@walkero

Or does the updated article/instructions have to be created and submitted again?

@Maijestro

Well, the UBOOT on AmigaONE-XE and SE has not been updated, so good if documentation stays the same.

if you have newer hardware, you need correct documentation for your hardware. don’t mess up the old documentation.

@walkero

Quote:

That's pretty cool....thank you

I have one more question, how can we update articles if they are no longer accurate or if something has changed?

@Hypex

What do you mean "always ends up"? As in : You can start cmake, and it does some work, but then it crashes? At what point does it crash, and of course : What does the crash look like?

If it is another stack issue, then it is easy to fix. AMOF I don't quite remember, if the online version contains a stack cookie.

@Hans

it does not.

When you read and write to the chipset, that’s when most chipset is emulated. this how it synchronized clock cycles to the video output. Every read and write, equals a amount of clock cycles, that is used for the video rendering. This who it can get exact output, even when emulation is not real time.

Even the blitter is done like that, even if in that case, should been done in parallel.

So you need to run 99% on the other core, that’s probably fine on X50x0, where emulation is running fine on just one core, the main advantage is that it frees up the main core.

Of course, we can all agree that a bad implementation is better than no implementation.

@Rob

Quote:
Does UAE run the chipset emulation in separate threads from the CPU emulator? If so, then it should be possible to make them run on the unused core(s).

Of course, that would be a lot easier if the OS supported SMP..

Hans

@Tuvok

Quote:
One of the remaining developers, but I'm grateful that there are others. LiveForIt has pointed to clib4 which has 8 contributors to it. There are others too.

We do need more developers, though. And more people doing cool stuff on the Amiga in general. That's one of the motivations behind the Kea Campus' Amiga Corner

Quote:
Thanks.

Just to clarify for everyone: you don't need to be a developer/coder to oin the campus and support my work. Everyone is welcome, and the financial support certainly helps keep it going. If you're not a developer, then you can think of it as a Patreon style sponsorship of Amiga content creation (except Patreon doesn't take a 8-12% cut).

Just make sure you tell me that you're there for the Amiga corner. More info here.

Hans

Has anyone experienced any crashes? I've got the alpha CMake up and running and it starts to work. But it always always ends up in a crash. I'll collect some crash logs. Right now trying to update some code using the newer CMake.

@NinjaCyborg

Quote:

The question would be how much additional and useful software would be able to run directly in OS4 with such a solution. I sold my BPPC before OS4 was available for it so I've never been able to make a comparision between PPC hardware with the chipset and hardware without. I do know that WHDload is fundamentally incompatible with OS4, so the vast majority of games that require the chipset simply cant be run without resorting to UAE.

@Hans
Quote:

I think that would be the optimal solution for most users and alternative payment options from within the Amistore app for users that want to use a different payment method.

Looks useful, Thanks!

I wonder, could possibly a date/time for each be added?

Best regards,

Niels

I do not know if anyone noticed, but there is a new block on the right side of the website where the latest articles are shown. That's an easy way to track new posts.

@Lio
Since you have Wookiechat and AmIRC on AmigaOS, why would you need to use that tool? This is in case you want to get into IRC from other systems without installing and IRC client.