@ppcamiga1

Quote:

ppcamiga1 wrote: from developer POV pistorm is hardware that changes Amiga into joystick, mouse, keyboard interface for rpi. emu68 is emulator like winuae. Don't be fooled. treat it is as it is. made everything for linux on rpi, with decent 3D API like vulkan, only add few lines of code to read joystick, mouse, keyboard from Amiga side.

False. Emu68 is not an emulator like WinUAE.

Emu68's bare-metal is closer to Transmeta's CodeMorph approach than instead of UAE.

Emu68 allows C= Amiga AutoConfig to govern "plug and play" on bare metal RPi.

Emu68's Broadcom VideoCore RTG drivers are real bare-metal graphics drivers for C= AmigaOS.

Emu68's WiFi drivers are real bare-metal Pi WiFi drivers for C= AmigaOS.

Amiga is only 32-bit address aware which doesn't affect Emu68's 64-bit process.

Last edited by Hammer on 19-Jan-2025 at 01:01 AM.
Last edited by Hammer on 19-Jan-2025 at 12:54 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Just call it WasPiD. Done. "Wasp" as in "Was inspired by Wazp" and Pi is 3, when rounded to the nearest integer. As well as being, you know, Raspberry Pi.

Phew, that's the difficult bit done. When's it shipping?

Last edited by Karlos on 19-Jan-2025 at 01:38 AM.
Last edited by Karlos on 19-Jan-2025 at 01:36 AM.

_________________
Doing stupid things for fun...

@Karlos

It doesn't have "3D". It should have "3D" somewhere in the name.

Somebody with the Warp3D development team followed IBM OS/2 Warp...

"Warp" can be interchanged with distortion.

Star Trek's "Warp" usage is speed beyond light speed, hence Star Wars version is Hyperspace i.e. Hyper.

Could name it Hyper3D. Other people have used Hyper3D.

In the old 3D implementation, warped/distorted capable sprites are used as texture tiles e.g. Sega Saturn.

C= Amiga Hombre used warped/distorted capable blitter hardware as the texture mapper.

Amiga is late with hardware-accelerated texture-mapped 3D.

Could name it Delusion3D as a pun on vampires or zombies since the Amiga platform is the walking dead.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

Could name it Hyper3D.

That doesn’t work when you do just hexi-edit binaries to replace “warp3d�.


My suggestion, which is closer to home and closer to reality… Worm3D

Last edited by kolla on 19-Jan-2025 at 02:40 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hammer

what you wrote is pure propaganda bs.

the truth about pistorm is
that pistorm changes Amiga into joystick, mouse, keyboard interface for rpi.
ans emu68 is emulator like winuae.
you fool yourself
treat pistorm is as it is.
made everything for linux on rpi, with decent 3D API like vulkan,
only add few lines of code to read joystick, mouse, keyboard from Amiga side.

@MagicSN

don't lie about Emu68.
Os is not native.
Whole os is emulated.
Emu68 works like WinUAE.
Stop spread propaganda BS.
Stop trolling.

@ppcamiga1

Quote:

ppcamiga1 wrote: @Hammer what you wrote is pure propaganda bs. the truth about pistorm is that pistorm changes Amiga into joystick, mouse, keyboard interface for rpi.

False.

1. The main point about my A500 Rev6A's ECS Denise upgrade is 56khz Paula audio.

2. Amiga chipset is legacy software support just as PC has VGA legacy support.

Amithlon is a failure since it had no WHDload Amiga games. Many Amiga owners are not interested in a half-baked DraCo-like solution. Amiga is not a Mac.

Quote:

ans emu68 is emulator like winuae.

False. You're fooling yourself.

Last edited by Hammer on 19-Jan-2025 at 06:27 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Of course PiD has 3. What's the first digit of Pi? :)

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

ppcamiga1 wrote: @MagicSN don't lie about Emu68. Os is not native. Whole os is emulated. Emu68 works like WinUAE. Stop spread propaganda BS. Stop trolling.

Wrong.

Read https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/transmeta/
The Transmeta Code Morphing Software.

68000 to 68030 implements large microcode firmware and engine to execute 68K ISA in several clock cycles on a simplified CPU core.

68040 is the 1st 68K CPU to implement a hardwired near 1 instruction per clock implementation for most of the 68K integer instructions.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Back to the serious side, the notion of creating a drop-in single file replacement for W3D that targets a specific hardware+RTG combination is something I've thought about doing a number of times, but the "nontechnical nonsense" I alluded to in previous posts has always put me off.

Some technical things to consider when doing this:
- Aim for a high level language implementation except where ASM is strictly necessary. This helps you to:
- Organise your monolithic code into logically discrete modules that you can create compile time abstractions for so that you can:
- Allow for future expansion of the project to cover other GPU, for example earlier Pi models and older PCI cards, e.g R200 etc.

That's all doable with zero performance losses due to indirection.

Once you are in the thick of it, remember that the main context structure contained many sensitive fields that were only meant to be called by library methods. Which of course meant some people decided to poke them anyway. Keep a shadow copy of the context for comparison purposes so that you can check for illegal changes to these and handle them accordingly.

I've mentioned earlier that implementing the V4 methods first will help to simplify the job of providing much of the V3 functionality but you will need to maintain various vertex layout state of the client code is mixing V4 and V3 calls. Not a deal breaker but one to watch out for.

On the topic of vertex arrays, the format you give to the hardware is obviously hardware specific but you will be required to support a fairly wide range of potential layouts for coordinate, texture coordinate and colour data array input. It's easy to end up with a giant mess of duplicated code here.

The key to avoiding that is to recognise the only thing actually changing is the step of fetching the next coordinate data in a read. So, a sensible use of runtime indirection here is to have a set of functions that read a given coordinate type/layout and to call them through pointers that you set and maintain when important state changes. When I did this for the P2 driver originally, the binary size dropped by about a factor of 10 and the performance increase was pretty noticeable.

As an evolving product, Warp3D had bugs in early drivers that were fixed only in later ones. This leads to the inevitable and annoying situation in which software may have depended on a behaviour in an early driver that was rectified in a later one. A classic example from the Permeida was a change to blending mode that was needed for Heretic 2 but broke Wipeout2097 causing the engine trail to be rendered incorrectly.

One way to solve this, that I added later was to allow environment variables that can be set based on the application name. There are other ways it could be solved too that might be simpler to achieve even if less amiga-like, e.g. you could just have a flat file configuration that can have all the same info in key/value pairs with application name sections. Whatever you do, be prepared for having to deal with bug dependencies one way or another.

Finally the nuclear option. In the hopefully unlikely event that someone thinks this endeavour is any kind of infringement and gets a case of legal butthurt over it recognise that Warp3D is very low level and only a subset of applications depend on it directly. While a shame to not support them, most of the 3D games and applications people will likely want to run/port are running on MiniGL.

You could therefore target that as your injection point instead. Having MiniGL as an Amiga shared library is already a thing in OS4 IIRC. It would be more work, but you're going to be backporting titles from PPC more than likely anyway so the opportunity to drop a dependency on statically linked MiniGL for a stub link library that calls MiniGL.library is there. The benefits of doing this are that you can actually accelerate a lot more than you can by *just* targeting Warp3D since the VideoCore is actually a hardware GL implementation anyway. So all your transform, clipping and lighting can be delegated directly to the GPU and you get the benefit of being able to draw on existing Linux DRM examples on how to approach it all. For games that rely on vertex buffers and things, the performance improvements here should be very conspicuous.

Best of luck to all involved!

_________________
Doing stupid things for fun...

Just one more point. If you did go down the MiniGL.library route instead, there's nothing stopping you adding some lower level function calls and ability to attach a render context to some user supplied bitmap. You could do this so that someone else could create a Warp3D.library implementation that uses it instead, where they just have to implement a bit of state and resource management but otherwise just call through to your implementation. So you can still have your low polygon cake and draw it.

_________________
Doing stupid things for fun...

@ppcamiga1

You are lying. I am actually a developer using both OS4 and PiStorm, so I know what I am talking about. Emu68 cannot emulate the chipset.

I do not know what you think you gain by spouting propaganda.

Yes, I probably should not feed the troll, but sometimes it is hard to me...

@MagicSN

Don't sweat it, he says the same thing all the time. He's like TLM (Tiny Language Model). Sometimes I think he might be, created by someone as a joke but now serving an essential function in keeping the site from becoming totally moribund or crashing stock in popcorn shares otherwise.

_________________
Doing stupid things for fun...

@Karlos

Thanks! All good advice.

What we currently have is a proof-of-concept monolithic Warp3D.library which is for Videocore4/Pi3 though (so a lot of this needs to be completely exchanged, also the structure of the code might get changed - as you pointed out if in the future a different model should be supported it would be good to separate stuff related to the hardware to such not related to the hardware and stuff.

ASM will have to be used as the Videocore needs some ASM in the QPU ASM language (it was actually a first roadblock that no assembler for Videocore VI was available - though we got one in meantime, assembler in this case does not mean a binary, it is a large C++ function which takes QPU ASM Source and outputs a binary representation as an array). The ASM language is "similar but different" for Videocore IV and Videocore VI.

The starting work will of course not depend so much on the solution for "legal issues" but be principial work. As it does not require a specific structure when just finding out how the stuff works.

Thanks for the good wishes!

Best regards,
Steffen

@MagicSN

With respect to asm, I meant the library itself, the entry points and internal state and resource management aspects. Naturally the videocore will require it's own hardware level instructions generating as I assume it uses a modern unified shader approach to rendering.

_________________
Doing stupid things for fun...

@Karlos

Yes. Well, the current plan is to do the stuff on the library itselves, exactly as you suggest - in highlevel language, so in C.

@MagicSN

You MagicSN are lying.
You MagicSN spread propaganda BS.
Emu68 works like WinUAE.
Emulate whole os.
Stop trolling.

@Hammer

szulc fool you. what you wrote is pure bs.
uae also has JIT since year 2000.

@Karlos

waste of time. just use rpi as rpi. install qjoypad.
sell pistorm users usb cable, usb kvm switch, gamepad usb interface
and everything may be done without any code for pistorm

@ppcamiga1

I think there is logical error in your assumption.

So answer this how is AGA outputed on Amiga side, if AGA chips are not used, how does Audio come out of the Paula chip, if that chip is not used?
how does floppy work, if the chips are not used and so on.

Why do you think PiStorm runs faster then EUAE on the same hardware? if its as your saying the same approach.

You don’t need to like it, or think its correct path forward, but that has nothing to do with how It works. Please sperate your emotions from the technical aspects.

The A600GS and TheA500 mini is what you’re saying PiStrom is,
but this are different products. and does not attach to a real Amiga.

Where your argument fits best is on Vampire, but that’s a completely different thing again, because vampire tries to replace the Amiga chipset. But approtch is not in software but using a FPGA.

Last edited by NutsAboutAmiga on 19-Jan-2025 at 02:32 PM.
Last edited by NutsAboutAmiga on 19-Jan-2025 at 02:07 PM.
Last edited by NutsAboutAmiga on 19-Jan-2025 at 02:03 PM.
Last edited by NutsAboutAmiga on 19-Jan-2025 at 01:59 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS