Who's Online |
19 user(s) are online ( 9 user(s) are browsing Forums)
Members: 2
Guests: 17
orgin, NinjaCyborg,
more...
|
|
|
|
Re: Payback game: last CD batch
|
Posted on: 10/10 21:20
#221
|
Just popping in
|
@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.
|
|
|
|
Re: CLIB4 Shared Objects and Shared Library
|
Posted on: 10/10 20:44
#222
|
Home away from home
|
@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.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Qt 6 progress
|
Posted on: 10/10 20:36
#223
|
Not too shy to talk
|
so can someone summarise the current status of the latest revision?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 10/10 20:26
#224
|
Just can't stay away
|
@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.
|
|
|
|
Re: CLIB4 Shared Objects and Shared Library
|
Posted on: 10/10 20:18
#225
|
Not too shy to talk
|
what is the difference between clib2 and clib4?
|
|
|
|
Re: New web application for IRC
|
Posted on: 10/10 20:06
#226
|
Quite a regular
|
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...
|
|
|
|
Re: CLIB4 Shared Objects and Shared Library
|
Posted on: 10/10 19:04
#227
|
Just can't stay away
|
@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.
|
|
|
|
Re: AmigaOs4.1 manuals/howto
|
Posted on: 10/10 17:33
#228
|
Just can't stay away
|
@LiveForIt Quote:
LiveForIt wrote:@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.
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?
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
|
|
|
Re: AmigaOs4.1 manuals/howto
|
Posted on: 10/10 16:57
#229
|
Home away from home
|
@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.
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: AmigaOs4.1 manuals/howto
|
Posted on: 10/10 16:43
#230
|
Just can't stay away
|
@walkero Quote: walkero wrote: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. 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?
|
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 10/10 10:12
#231
|
Just can't stay away
|
@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.
|
|
|
|
Re: Why not use the second core for chipset emulation?
|
Posted on: 10/10 8:16
#232
|
Home away from home
|
@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.
Edited by LiveForIt on 2024/10/10 8:39:29 Edited by LiveForIt on 2024/10/10 8:41:03 Edited by LiveForIt on 2024/10/10 8:43:32
|
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
|
|
|
Re: Why not use the second core for chipset emulation?
|
Posted on: 10/10 3:38
#233
|
Home away from home
|
@Rob 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. 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
|
|
|
|
Re: Why not use the second core for chipset emulation?
|
Posted on: 10/10 3:35
#234
|
Home away from home
|
@Tuvok Quote: It almost looks like you are one of the last remaining coders holding the flag! Thank you for that. 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 CornerQuote: I really welcome your initiatives and the energy you put in the Kea Campus. I wish I had the time to start coding and support you. I can't atm, but the time will come. 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
|
|
|
|
Re: CMake 3.29 Native (OS4)
|
Posted on: 10/10 3:28
#235
|
Not too shy to talk
|
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.
|
|
|
|
Re: Why not use the second core for chipset emulation?
|
Posted on: 10/10 1:02
#236
|
Not too shy to talk
|
@NinjaCyborg Quote: Which brings me to the idea I posed in the title. On the PowerPC machines that have an extra core that isn't used, could it be feasible to use that core to run a chipset emulator? If it's never preempted, it should be easier to keep timing, albeit it has to emulate several different chips, but none of them run at clock speeds close to the core's real clock speed. 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.
|
|
|
|
Re: AmiStore purchases and downloads
|
Posted on: 10/10 0:34
#237
|
Not too shy to talk
|
@Hans Quote: You mean get users to sign a pre-authorization agreement on an Amistore website which then enables them to purchase from the Amistore with one click?**
Yes, I think that could be done. 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.
|
|
|
|
Re: AmigaOs4.1 manuals/howto
|
Posted on: 10/9 23:51
#238
|
Just can't stay away
|
Looks useful, Thanks!
I wonder, could possibly a date/time for each be added?
Best regards,
Niels
|
|
|
|
Re: AmigaOs4.1 manuals/howto
|
Posted on: 10/9 23:21
#239
|
Site Builder
|
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.
|
|
|
|
Re: New web application for IRC
|
Posted on: 10/9 23:17
#240
|
Site Builder
|
@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.
|
|
|
|