Are your sources open?
Seems like you are printing some memory area initialized with zeroes (MEMF_CLEAR AllocVec TAG).
One way to isolate it sholud be initialize memory with 1 (Clear_value TAG).

Bad contact I suppose

Well done, thanks!

..What if you use screens instead of windows?

Congrats!

Will new clib2 present in next OS4 SDK?

This snippet of code should regard a function to "Scale a 64x64 texture + alpha-channel it".
See first post.

rlwimi r10,r11,0,16,31
rlwimi r10,r11,0,24,31

can be both replaced with
andi r10,r11,0xFFFF
andi r10,r11,0xFF

compiler has generated a complex instruction instead of a much simpler one

About DSI crash it could be a previous mem allocation bug, so pointers r3 and r4 can exceed limits.

In the first post there's the whole code.
Maybe instead of debug ASM it can be rewritten in C, it's quite short.

@kas1e

_BlankChunky:
lis 26,_BlankChunky@ha # load the address of the label
addi r26,26,_BlankChunky@l # in r26 (2 steps)


whitout use of mnemonics try these two couple of commands, maybe on your assembler you have to remove the '%' or '%r' registers prefix, under GCC instead I use this.

addis %r26,0,_BlankChunky@ha
addi %r26,%r26,_BlankChunky@l

*************************************

ADDIS - Add Immediate Shifted

Syntax: addis rD,rA,SIMM

This command is used to add a 16-bit immediate value to the upper 16 bits of a 32bit register. It adds a 16-bit signed integer (SIMM) to register rA, then shifts left register rA by 16 bits and then puts the result into the register rD (destination). The lower 16 bits are cleared by this command. So to fill a 32 bit register with an immediate 32-bit value you first have to use addis to fill the upper 16 bits and then addi to fill the lower 16 bits. Otherwise the lower 16 bits would be cleared again by the addis command.

Example: addis 3,3,4

In this example GPR3 and the value 4 are added, then GPR3 is shifted 16 bits to the left and the result is put into GPR3. This will then contain 0x00040000 in hexadecimal. If you then execute an addi 3,3,4 command GPR3 will contain 0x00040004 in hexadecimal.

To move a pointer to an address of a variable or function into a register there are the @ha/@h and @l modifiers available. If you append these to the variable name you get the lower (@l) 16 bit of the absolute 32-bit address of the variable and with @ha you get the higher 16 bit of the absolute 32-bit address.

Example:

addis 3,0,hello@ha
addi 3,0,hello@l
With these two instructions the absolute 32-bit address of the string variable hello is moved into the GPR 3 register.

Instead of addis/addi the mnemonics lis/la are often used.

About PowerASM you can ask to Sam Jordan http://www.sam-jordan.ch/software.htm

Anyway different ABI lead you to change registers usage.

I want point also to this fast/simple url about powerpc assembler https://wiibrew.org/wiki/Assembler_Tutorial

Sometimes is faster to replace simple macros instead of resolve them for specific assembler rules not widely supported.

A couple of "lis" and "addi" can be a fast solution to replace "la" macro

Lookat here, it's quite simple task replace those macros for GPRS and FPRS regs.
PowerPC assembler is much more robust and simpler than old 68k

IBM docs prolog/epilog

Regarding seeing everything in black and white, it is a common vision for many developers.
I had to work hard on myself to understand that people are very different from machines and that their decisions are often the result of buggy algorithms or wrong impressions.
This from my point of view, but for them the one who is bugged is me.
Once this is accepted by both parties, a negotiation can begin, the outcome of which remains uncertain.

What matters most now, however, is to resume the dialogue and see if time allows for new solutions to arrive that can allow the development of AmigaOS to move forward.

Also I am definitely convinced that the secret is to make the whole system open source but at the same time find a strong management that can profit from the development and sales of the system.

@joerg

I suggest you to open a thread on major Amiga forums, tell your experience and ask for a community refund for your never payed work.

Let us know your paypal account or some other way to donate.

I can give you a litte month by month and support your old and future efforts, I'm sure others can do the same.

I don't know if this can refund 100% but I hope this approach can give you a little satisfaction and let you come back to amiga community.

I'm quite sure the only way to do further in "Amigaland" is release opensource projects, with some kind of restricted license to avoid others to sell your work for free.

@salass00

Nice to know, thanks!

I wonder if instead of removing it and mortify amiga users, there is a way to pay legitimate developer for the job done.

The same could be done for other os4 core software not payed.
Maybe a community bounty could be a valid solution?

Once payed all software could be possible publish sources on github or other public repositories with some kind of "permissive" licence?
..ask for a friend

@kas1e

I don't think it's a race condition.
What if Delay (0)?

@joerg

I hope you can come back to Amiga coding and have fun, again.

OS4 is really a great piece of software and it improves greatly old amigaos experience on NG systems.
Tanks a lot!

@kas1e

To emulate OS4 under x64 we have two choices: WinUAE for windows users or UAE/QUEMU for linux users.

UAE/WinUAE are based on an old version of QEMU engine, PPC emulation was added as plugin.
You can emulate an Amiga classic with a PPC expansion board and it's fully compatible with OS4.1fe
You can archive a good speed on gfx side setting UAEGFX as board, but it's ok also with Picasso IV board, but in this case you are limited with 4mb ram to 32bit hd resolutions.
Cpu/fpu emulation has some little bugs, all fixed in latest QEMU releases. Sadly both Toni and Frode, as stated on some EAB posts, aren't interested in a new QEMU plugin version and considers OS4 compatibility as a "side effect" adding powerpc board emulation.
So OS4 compatibility is remained without any active support.

On QEMU side we have Sam460ex and Pegasos II boards emulation, but we have more severe limitations because some motherboard features aren't still implemented.
So you have a limited GFX card compatibility and graphics speed is very poor.
Instead CPU/FPU are well emulated and speed is quite good and has no bugs in powerpc instruction emulation.

So to improve/develop further OS4 emulation we need:
for UAE/WinUAE a new plugin version based on latest QEMU sources
for Sam460ex/Pegasos II board a better gfx implementation with also 3d support.

Sadly QEMU project is really hard and complex!
It's not an easy task and to emulate an expansion board like a gfx card or a sound card you should know all it's chipset internals.
There's an active project to emulate a radeon board but it's still incomplete due lack of chip documentation.

https://osdn.net/projects/qmiga/wiki/SubprojectAti
https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2
http://zero.eik.bme.hu/~balaton/qemu/amiga/