They should make a Windows like Amiga OS so it runs on a PC

[Bruce Abbott]

Originally Posted by hammer

[ Show youtube player ]
AMD's Shader Intrinsic Functions for GCN from 8 years ago. This is developing a specific instruction set code path for a specific GCN instruction set on the PC. This bypasses the DX's DXIL and driver-side shader compilers.

With the RDNA 3 era, AMD is silent on this initiative. Hint: RDNA 3 CU's dual-issue feature can only run in wave32 instructions.

You're out of touch.

Out of touch? What has your PC spam got to do with RTG on the Amiga?

[Karlos]

Originally Posted by Bruce Abbott

Out of touch? What has your PC spam got to do with RTG on the Amiga?

It's Numberwang!

[Bruce Abbott]

Originally Posted by Thorham

Such a waste
My A1200 has no floppy drive. Is it somehow less Amiga like too?

Yes, it is 'less of' an Amiga.

But how much can you take away before it becomes not an Amiga? Remove the keyboard, the hard drive, and the case. Now you have an Amiga motherboard. I have one of those. Add a floppy drive and it's enough of an Amiga to run most games etc., and it would be wrong to call it anything other than an Amiga.

Now take away the custom chips and add an RTG card. Is it still an Amiga? Most would say not. But it's still got CIA chips, so now you have something similar to the DraCo, which ran Amiga OS 3.1.

But the CD32 didn't have CIA chips and we call that an Amiga, so let's remove those too, replacing them with just enough logic to keep the OS happy (like the CD32 did). Add a PCI slot so we can use a 'standard' graphics card, and USB ports for mouse and joystick, and keep calling it an Amiga because people have those things on their A1200s and quite rightly still call it an Amiga.

And it's still got Motorola inside, so we can keep calling it an Amiga even if all the other chips are different, right? But hang on, what's that I see plugged into the trapdoor slot - a PiStorm32! That's it, the final straw - now it's not an Amiga!

[Karlos]

In my experience both using RTG as a dev but also having worked on the driver side (as well as 3D), the problem for RTG on the Amiga is impedance mismatch. Apart from basic rectangular blits, a lot of what the graphics.library does, and how it does it, isn't a superb match for the hardware. Often the hardware was designed to work with some simple single threaded driver model so managing locks and queues and things was quite simple. But on the Amiga you are often doing all this from the context of the application which is any number of different threads. So simple operations end up with overhead of doing locking and stuff themselves as and when they need to make a drawing call. Then there's the whole Pens system, which still has value on an indexed colour display but is a hindrance on any RGB display.

I could go on, but I'm sure you get the drift. In essence it was a decent kludge, but what we needed was an updated API.

[TCD]

Originally Posted by Karlos

It's Numberwang!

The superhero with the calculator in his breast pocket and a periodical table blanket as a cape?

[Karlos]

Originally Posted by TCD

The superhero with the calculator in his breast pocket and a periodical table blanket as a cape?

[Karlos]

But hang on, what's that I see plugged into the trapdoor slot - a PiStorm32! That's it, the final straw - now it's not an Amiga!

Yeah, I don't get this attitude either. The CPU was the only commodity part of the core architecture. As long as the "processor" executes 68K object code with sufficient compatibility and performance for your needs, why care what the implementation is?

The only obvious exception here is if you are writing assembly. Then I totally get it. You are doing something you love and want to craft it to be the best if can be on your target processor. You want your intuition and cycle calculations to be valid. This doesn't make a PiStorm powered Amiga not an Amiga it just makes a hardware CPU a better fit for *your* needs.

[Thomas Richter]

Originally Posted by Karlos

Apart from basic rectangular blits, a lot of what the graphics.library does, and how it does it, isn't a superb match for the hardware. Often the hardware was designed to work with some simple single threaded driver model so managing locks and queues and things was quite simple. But on the Amiga you are often doing all this from the context of the application which is any number of different threads.

Not really, at least not as far as 2D graphics go. Graphics has a semaphore to grand exclusive access to the blitter, and that is OwnBlitter(). P96 has its BoardLock, which is also a semaphore and through which it grants exclusive access to the onboard "accelerator" of most contemporary graphic chips. The operational model of these chips is very similar to that of the blitter: You indicate the graphics operation you want to perform by writing to custom chip registers, and let the blitter or accelerator perform its magic. You wait by testing a particular hardware register for the chip to have done its duty. That's really it, and there is no significant difference.


The complexity comes from the organization of the display hardware, which is planar on the Amiga, and chunky for the graphic chips. Amiga structures are ill-designed to accomodate chunky models, and thus the RTG stack has to do all kinds of tests and tweaks to hide chunky pixel organization behind structures that have been prepared for planar operations. Each bitmap not only requires information where the graphics is, but also how it is organized, and wether it is on board of the graphics card, or in an off-screen buffer because the graphics memory is full.


Note well this is much more flexible than what the native graphics.library could do. Here you had to allocate the graphical elements in chip memory, and then they would stay in chip memory forever, and if chip memory becomes full, you're out of luck. RTG does not work this way. You allocate structures abstractly, and the graphic system puts them wherever is room, and even brings them to graphics memory if there is an advantage, or removes them if it needs room. For blitting, either the CPU on the on-board accelerator is used, depending on where the source graphics is located.

Originally Posted by Karlos

I could go on, but I'm sure you get the drift. In essence it was a decent kludge, but what we needed was an updated API.

The API you have right now is the best you can get if you need compatibility to existing Amiga software that operates on bitmaps and rastports. The API is restricted to how the graphics.library implemented things (in a less forward-looking way by using explicit structures rather than opaque objects).


It's not that there haven't been attempts to provide a better API that is better suited for RTG. That was EGS. What killed EGS wasn't the improper API, it was the lack of applications and the lack of critical mass.

[minator]

Originally Posted by Bruce Abbott

But hang on, what's that I see plugged into the trapdoor slot - a PiStorm32! That's it, the final straw - now it's not an Amiga!

So Amigas back in the day with Blizzard PPCs were not Amigas?
Do people really think that???

[HornBeamSoft]

ppc in blizzard ppc can work together with motorola for ex PowerUP or WarpUp
so it is still Amiga

[TCD]

Originally Posted by minator

Do people really think that???

Bruce does