PROJECT: Hybrid POWERUP/WARPOS Kernel bridge

# ==============================================================================
# PROJECT: HYBRID POWERUP/WARPOS KERNEL BRIDGE FOR AMIGAOS 4.1
# ==============================================================================

INTRODUCTION
------------
This project aims to bridge the historical gap between the two main PowerPC
kernels for Amiga: WarpOS (Haage&Partner) and PowerUP (Phase5). By modifying
the original ReWarp (powerpc.library) framework on AmigaOS 4.1, with the assist of the AI environment we have tring to
implemented a dedicated execution layer that should allows legacy PowerUP standalone
ELF binaries to run natively alongside WarpOS applications. This work
leverages low-level system calls of AmigaOS 4.1 to provide the specific
environment that Phase5 binaries expect, including TaskObject emulation and
Quark-style messaging synchronization.


TECHNICAL DOCUMENTATION FOR ADVANCED DEVELOPERS
-----------------------------------------------

1. OVERVIEW
The goal of this project was to extend the ReWarp (powerpc.library) framework
to provide native, transparent support for PowerUP (Phase5/Quark) binaries.
While ReWarp excels at WarpOS emulation, many legacy standalone PowerUP
executables remained non-functional or caused Shell freezes due to architectural
differences in ABI, memory management, and context switching.

2. OBJECTIVES
* ABI Unification: Bridging the WarpOS calling conventions used by ReWarp
with the Phase5 PowerUP ABI.
* Standalone Execution: Enabling the direct execution of PowerUP ELF binaries
from the OS4 Shell without requiring an external 68k loader.
* Resource Virtualization: Implementing internal handlers for PowerUP-specific
kernel calls (TaskObjects, ppcM memory cookies, and Quark messaging).

3. TECHNICAL IMPLEMENTATION DETAILS

A. The Extended Jump Table (V13/V46 Mapping)
We implemented a 132-slot vector table to mirror the standard Phase5
powerpc.library specification:
* 68k Offsets (-6 to -90): Standard entry points for 68k-side calls.
* PPC Offsets (-300 to -732): Comprehensive mapping including Math GCC
functions and string utilities (memcpy, __adddi3, etc.) to prevent DSI
exceptions in GCC-compiled binaries.

B. Native Task Launch Logic (_PUP_RunPPC_Task)
To resolve the persistent "Shell Freeze" issue, we moved away from synchronous
function execution within the library context:
* Logic: The library uses IExec->AllocSysObjectTags(ASOT_TASK, ...) to spawn
a native AmigaOS 4 Task.
* Context: The ELF is loaded via InternalLoadSeg. We perform manual
BPTR-to-APTR conversion and relocate the entry point.
* Stack Alignment: Enforced 16-byte aligned stack (SVR4/PowerOpen standard)
to satisfy FPU-intensive PowerUP applications.

C. TaskObject Emulation (Frank Wille/ppclibemu spec)
Based on an extensive analysis of code lines of ppclibemu source code,
we implemented a simulated TaskObject structure within the stack frame:
* Magic ID: Hardcoded 0xA5 at offset 15 (TskObj_idMagic).
* Standard I/O: Linked OS4 Shell Output() handles to the to_outputhandle
field (offset 72) to enable CLI output.
* Signal Mask: Initialized R5 with 0x0100 to simulate a completed startup
handshake, preventing binaries from entering infinite WaitTime loops.

D. Memory Management (The "ppcM" Cookie)
PowerUP applications often validate memory blocks via integrity checks.
We implemented a wrapper for AllocVec that:
1. Allocates an additional 32 bytes of header.
2. Writes the Magic ID $7070634D ('ppcM') at the start.
3. Returns the pointer offset by 32 bytes, satisfying Phase5 integrity checks.

E. Messaging and Synchronization
We implemented native wrappers for the core PowerUP IPC:
* ObtainSemaphorePPC: Enforces ln_Type = 15 (NT_SIGNALSEM) to prevent
validation failures.
* PPCMsgPort support: Mapped CreateMsgPortPPC, DeleteMsgPortPPC, and
ReplyMsgPPC to OS4 Free/AllocSysObject to handle asynchronous communication.

4. BUILD ENVIRONMENT
* Assembler: vasmppc_std (v0.9+), using -Felf -many -mppc32.
* Linker: vlink with a custom ldscript to ensure proper section alignment
(.text, .data, .bss) for AmigaOS 4 ELF standards.
* Target: powerpc.library version 46+ compatibility.

5. SUMMARY OF IMPLEMENTED VECTORS (20 FUNCTIONS)
The current build includes functional wrappers for:
RunPPC, GetCPU, GetPPCState, GetInfo, AllocVecPPC, FreeVecPPC, SPrintF,
WaitTime, WaitPPC, Obtain/ReleaseSemaphore, Put/Get/ReplyMsg, and
Create/DeleteMsgPort.

6. CONCLUSIONS
This implementation represents a "Deep Bridge" approach. By simulating the
internal state of the kernel while utilizing the high-performance
multitasking of ExecSG (AmigaOS 4), the goal is to provide a stable environment
for both legacy binaries that were previously incompatible with modern PPC systems.

No links, no list of what actualy works, just mostly ai generated text.. Is anything heavy works already ?

@kas1e

No source yet, but i'll upload everything as soon as i come back in Italy
The project seems to be well underway from an implementation standpoint, the AI assister required a lot of documentation.
I've gotten to the point where I can compile an executable without errors. WarpOS applications continue to run normally with my executable, but PowerUP applications still won't start for some reason.
I don't have any errors on screen, but something seems to be running in the background... for now my test was conducted only with a couple of shell based apps

The vector table should be completed, and at the level of implementation and error handling I think I am well under way, but I must admit that this project is proving to be much more complicated than I thought, even with the help of AI it is likely that the help of a (expert) human hand still necessary

@samo79
Most of what you (or AI) wrote, for example Quote:doesn't make any sense.

WarpOS = powerpc.library, or a partial emulations on AmigaOS 4.x like my powerpc.library, or a worse and even more limited one like ReWarp.
PowerUP = ppc.library

powerpc.library and ppc.library have nothing in common.

Using a PowerUP API wrapper/emulator like ppclibemu on top of another API wrapper/emulator (powerpc.library) doesn't make any sense and just adds a lot of unnecessary problems.
For running PowerUP software on AmigaOS 4.x implement an AmigaOS 4.x ppc.library instead, similar to the powerpc.library from me or ReWarp for running WarpOS software.
Since PowerUP and MorphOS have, or at least had 20 years ago, similarities in the APIs it shouldn't be much more work than mosemu was for running MorphOS software on AmigaOS 4.x.

what interesting software exists for which there is no public source, that is built and released only with PowerUp and not WarpOS?

@joerg

The initial idea was to use the same powerpc.library for both Kernel emulation.
Since I wasn't sure where to start, I generally used ppclibemu primarily as a reference point, after which I fed the AI ​​all the PowerUP documentation I could find.
My second approach was instead to try creating stubs pointing to a fake ppc.library that could intercept the necessary calls and functions from my modified powerpc.library
Let's just say that at the moment it's still all experimental, and I'm not sure if the AmigaOS4 ELF format is compatible with the PowerUP one.
As I said, I definitely need help to understand exactly why my attempts haven't been successful yet, even though the AI ​​assures me that the approach is the correct one.

Quote:

Is that mosemu code availible somewhere?

@NinjaCyborg

Mostly demos and some old utilities

btw, my first raw implementation can be found here

https://github.com/samo790/ReWarp

@samo79
Quote:

Looks like overcomplicated mess, imho.

If all you want is PUP support, then it mean that as Joerg says, PUP binaries just open and use ppc.library, nothing else need it there. No needs for this over cryptic mess, with bridges, gates, whatever ..

Btw, i do not remember any worth demo or utility for PUP, but maybe FxPaint have some plugin for or version for, not sure..

Firstly take some simple very base PUP utility, create your own ppc.library, and fight with AI till have it working , and then step by step. But even with AI you still need knowledge of internals, or it will make a mess again.

@samo79
Quote:Not possible since PowerUP software uses the PowerUP ppc.library instead, not the WarpOS powerpc.library.

And it's no kernel emulation, neither my powerpc.library nor ReWarp even try to emulate the WarpOS kernel, they are "just" powerpc.library API wrappers redirecting the powerpc.library functions, with required modifications like ABI (register and stack usage, alignment, etc., at least 10-20 times as much workarounds in my implementation than in ReWarp the last lime I checked the tiny ReWarp sources in which nearly everything important was missing, for example FPU emulation in an alignment exception handler), different arguments, etc., to similar AmigaOS 4.x functions, or if not available a reimplementation of the WarpOS functions.
WarpOS software -> AmigaOS 4.x powerpc.library -> AmigaOS 4.x functions.

An AmigaOS 4.x ppc.library would do the same, just for the completely different and unrelated PowerUP API and ABI.
PowerUP software -> AmigaOS 4.x ppc.library -> AmigaOS 4.x functions.

Quote:Result would be:
PowerUP software -> incomplete AmigaOS 4.x ppc.library (ppclibemu) -> AmigaOS 4.x powerpc.library -> AmigaOS 4.x functions.
Slower and much more error prone.

As I wrote already WarpOS and PowerUP have nothing in common at all.
Different PowerPC ABI: WarpOS uses the PowerOpen ABI (was IIRC used by MacOS PPC as well), PowerUP uses the SysV ABI instead like AmigaOS 4.x does.
Register and stack usage, alignment restrictions, ..., nearly everything is different.

There were incompatible ways of extending m68k libraries with PPC native functions as well: A hybrid m68k+PPC WarpOS library can't be used by PowerUP software, nor the other way round.
Edit: There were even libraries, at least one from me, supporting even 3 different types of software: m68k, WarpOS/PPC and AmigaOS 4.x/PPC https://os4depot.net/?function=showfil ... =utility/misc/asyncio.lha
I don't think it would be possible to add PowerUP/PPC and/or MorphOS/PPC as well, but maybe with some AI help you could prove me wrong

@kas1e

You're probably right, I thought it would be easier to start from a ready-made library like ReWarp's using an approach similar to the one used by ppclibemu.
the AI, which is obviously not an oracle, much less an experienced Amiga programmer, confirmed the validity of the approach, so I continued on this path until I managed to compile an executable that atleast did not crash.

As a test Reference i use this small utility:

https://pup.aminet.net/package/dev/c/BestRandom

As ill come back in Italy i will restart my experiments