@Gunnar

Quote:

Gunnar wrote: Dear Cesare Di Mauro, I'm surprised that you continue to argue. Do you really want to show all the world that you talk bullshit?

Yes, please: since it never happened 'til now, I'm really curious that you can prove it for the first time.
Quote:

Quote: The games that I posted use all of these modes. Some games use 8bit, some are 16bit, some are truecolor. Some games even mix modes. All of the games highly benefit from the AMMX memory efficiency boost. I'll talk about it below. Quote: [quote]So, since here I was perfectly right. There are 6 different types of STOREM. Of course you need to use the BYTE version for 8bit, WORD version for 16bit, LONG version for 32bit mode. Just as on 68K you use MOVE.B for BYTE and MOVE.W for WORD

Right and in fact those are DIFFERENT instructions. What I was recalling (remember the R in AFAIR?) was about STOREM, which worked as I've correctly reported.
Quote:

Quote: 3) is OK, but ONLY for the big-endian 16-bit format. It lacks the little-endian one. is plainly false. Because it doesn't support all modes, but only some, and for some it's making totally arbitrary assumptions. 68K uses Bigendian format. Amiga memory layout is also Bigendian. Copper list are in Bigendian, Amiga screenmodes are in Bigendian,Audio to play by PAULA the Amiga audio chip, is in Bigendian. Also our SAGA chunky modes are Bigendian.

Then it's a problem of YOUR implementation.

Amiga with RTG and AmigaOnes supported little endian as data format. For obvious reasons. Which aren't obvious for you, of course.
Quote:

PC use LittleEndian

Wrong again: https://en.wikipedia.org/wiki/OpenGL#Version_history
1.2 March 16, 1998 3D textures, BGRA and packed pixel formats
Quote:

I'm surprised that you do not know this.

See above: you don't know of you talk about.
Quote:

Quote: BTW, it doesn't support 24-bit modes (which usually are used for saving memory and bandwidth, at least for the graphic framebuffer). Yes games normally use 32bit mode truecolor mode and not 24bit. A game coder would know this.

A game coder knows what's better for squeezing the most.

Which isn't your case, since you never understood how important was the 24-bit format for saving both memory size and bandwidth.
Quote:

That said you can with also use STOREM on 24bit mode with an extra instruction.

So, you do NOT support it...
Quote:

Quote: But it's when you talk about performances and saying that AMMX is faster than a PowerPC then you're lying. Please stop making this up! I never said that AMMX is faster than all PowerPC in all and any cases.

Then why do you continue to bother? It wasn't YOU that quote the above sentence from my posts, and ONLY this sentence, trying to show that it wasn't true?

Does my sentence still applies or not? Be clear ONE time in your life: Yes or No?

If yes, then why you're still here arguing, since YOU quoted ONLY this sentence? Care to explain it?
Quote:

I said that AMMX is highly tuned for video and game operations. I said AMMX offers for games very useful instructions that ALTIVEC does not. I said that AMMX offers instruction which allow you to code some often used game operations in a much more efficient way than you can on PowerPC. In other words you save memory bandwidth and get more FPS out of your system.

Totally irrelevant for the discussion, which is centered ONLY on the statement that you've quote from me.

What your trying is called Red Herring and it's a logical fallacy. Of course. You're trying to derail the discussion from its original scope with one which looks similar, if Red Herring wasn't clear to you.
Quote:

Quote: Even more important, you're miserably lying by comparing a whole system, the Apollo Core, which ALSO handles graphic, with others where it's supposed to do ALL work. I never said AMMX would be tuned for PC-Modes which SuperAGA not supports.

Then it's YOUR problem: your implementation sucks.
Quote:

Super-AGA is an Amiga chipset and like everything else in Amiga also our Graphic Formats are BigEndian.

Wrong: see above. Amiga with RTG and AmigaOnes supported little endian. And for good reasons, since when they started borrowing video cards from PCs the only supported format was little endian.

PCs introduce big endians modes quite late.
Quote:

All the games we spoke about are 100% BigEndian. All the code is in BigEndian, all the GFX in them is in BigEndian and also all the Audio is in BigEndian.

So, you're telling me that the original games developed for PCs had all assets in big endian instead of little endian?
Quote:

Quote: And I'm pretty sure that games which properly makes use of it (e.g.: transferring graphic data on its VRAM and using the card's graphic primitives to do the cookie-cut operations and, in general, what's needed) could render all games that you mentioned much faster that the best Vampire card. In theory yes. But praxis many games that we have access to are coded for the CPU to compose the Graphics, as I explained. ROBIN HOOD for example, a very successful PC game which I ported to MorphOS, is coded on the basis that the CPU does all the graphic composition. DIABLO, also a very successful PC game that we ported, is designed the same. Command and Conquer, also a very successful PC game that we ported, is designed the same. Northland, also a very successful PC, is designed the same. Age of Empires, also a very successful PC, is designed the same. Desperados, also a very successful PC, is designed the same. Commandos, also a very successful PC, is designed the same. Star Craft, also a very successful PC, is designed the same. and thousands more games, are designed for the CPU to compose the graphics. If you port such a game to Amiga, than you can keep the whole game engine intact as it was designed. And you can use AMMX in the sprite routines to get a good performance boost in the game. This is very easy. AMMX is very easy to code and to very easy use - magnitude easier than ALTIVEC. The goal behind AMMX is to make coding easier and to improve performance. And this is exactly what it does. You can take a Game source in C, add a few lines ASM in the sprite copy routine and you have a port running fast and good on Amiga. Of course in theory one could also rewrite all these games to NOT use the CPU for composing but instead to use Graphic card operations and to stay in the limited amount of VRAM. But this would need that you rewrite the game completely. This would be 100 times more work.

So, rewriting the game to use AMMX and its sprites routine required little effort, while writing a set of simple APIs to load graphics to the VRAM and apply this graphic to the framebuffer required to completely rewrite the game.

Oh, yes: I trust you. For sure!
Quote:

Lets just look at DIABLO. DIABLO a PC game, does compose the GFX with the CPU. The Amiga port work the same. The OS 4 PowerPC port works the same. The 68K version uses AMMX (if available) to copy the sprites. The 68K version runs the game much faster on the 85MHz 68080 than it runs on a 1000MHz PPC OS 4 machine.

That's because nobody took care of proper conversions, like I've stated before.

It means that even your ports sucked a lot, since you were just using the CPU for doing everything whereas even the cheapest graphic cards had GB/s of VRAM bandwidth and several hundreads for MTexels/s for composing the graphic.

So, the problem wasn't about the systems, which were perfectly able to run those games even in FullHD (and more) with much more FPS: it was about the developers which did a very bad job with the port and decided to don't use The Component which was designated... to handle the graphic.

Nice! And you were supposed to be an expert, right?

@Gunnar

Quote:

Gunnar wrote: @kolla Quote: kolla wrote: @Gunnar The core is the just released 2.16 Ah ... you have an old V2 card. My bad, when you said you have an "actual card" I was thinking we speak about V4 generation cards. Which Screenmode did you use when doing the measurement? Did you use a Screenmode that the PowerPC AmigaOne XE systems are not able to copy to the GFX card in real time?

Oh, so you supposed something which was... WRONG!
@Gunnar

Quote:

Gunnar wrote: Quote: And you don't like them even after that kolla clarified: Because it shows something different from your propaganda... Cesare Di Mauro, maybe you did not understand what the number show? Maybe I did not explain this good enough for you. Let me help you. Kollas result showed exactly what I said. Kolla has different numbers than me as I use a V4 and he a V2. Kolla said he would have an "actual Vampire card", therefore I assumed he had the new generation card. Many thousands of 2D games work the same. They compose the graphics with the CPU, and then they copy the GFX to the GFX card. You need for the compose memory bandwidth and you need for the screencopy memory bandwidth. The Amiga One XE has ~ 180 MB/sec memcopy maximum bandwidth. I think that Kolla ran on the Vampire a screenmode which needs 360 MB/sec bandwidth for the frame copy. And even in this mode the Vampire had still 240-300MB Bandwidth free for composing. The AmigaOne XE has a bandwidth of 180MB, to reach the same game speed as Kolla measured on the Vampire the AmigaOne XE would need 360+240 bandwidth. And yes, if you use AMMX for Sprite copies than you get even more out of the bandwidth. This means what you get out of the 600MB would be like you have 650 or 700 MB bandwidth. The AmigaOne would need to have same game speed a memory bandwidth of 650-700 MB - but it has only 180 MB. And we have not even discussed that the AGP port is slow... Kolla result clearly show that memory performance advantage of the Vampire over the AmigaOne. As 650 MB/sec is more than 180 MB/sec Cesare did this help you understand it now. Or shall I explain it again.

It doesn't need to add PADDING to the discussion, thanks.

@Gunnar

Quote:

Gunnar wrote: Quote: The usual thing: that you're a liar and mystifier. See above. Dear Cesare Di Mauro, your compliments don't change the facts.

Facts are invented things in your case.
Quote:

You try to present yourself here as an AMIGA expert.

Correct.
Quote:

The reality is that thousands of Amiga users have a lot more Amiga coding experience than you.

And nobody of them produced something comparable to Fightin' Spirit and USA Racing...
Quote:

While other Amiga users code games and demos, you dont code,

Wrong again: I don't code Amiga games and demos (which I never coded, BTW, because I don't like to waste my time with them).
Quote:

you prefer to spend your time posting in the forum.

Guess what YOU're doing.
Quote:

You are a pretender.

Don't confuse with me.

Which Amiga games have YOU developed? Nothing. So YOU are the pretender here!
Quote:

You often talk about stuff that you have never done yourself,

Care to prove it?
Quote:

and you make assumptions and claims based on information that you "assume" to be true.

Whereas YOUR assumptions about kolla's systems are OK even if they were completely wrong?
Quote:

And it regularly happens that you don't inform yourself properly

Like kolla's systems? Why you didn't inform yourself properly?
Quote:

or you misunderstood the Internet source you base your "knowledge" on.

Care to prove it?
Quote:

And then you "talk out of your ass".

Again, don't confuse you with me: that's what you did since you were here. And you NEVER proved anything: just lies.
Quote:

But you are not alone. Matthew Hey does often the same. Matthew Hey also often talks total bullshit, because he not informed himself properly.

Care to prove it? Because you NEVER did it!
Quote:

Guys why do you need to spend your time "pretending" in forums?

To slap you for the bullsh*t that you write.
Quote:

Why don't you code something for Amiga instead?

Care to show me which game have you developed for Amiga?
Quote:

Write a good Webbrowser for Amiga or code a new game!

Do it yourself: I've better things for spending my time.
Quote:

Do something useful!

I'm already doing it.

But why you're wasting your precious time writing in this forum? Do you have nothing more important to do, like... writing a game for Amiga. Or WebBrowser?

@Gunnar

Quote:

Gunnar wrote: Quote: [quote]Did you use a Screenmode that the PowerPC AmigaOne XE systems are not able to copy to the GFX card in real time? Why this obsession with AmigaOne XE?

We speak about the AmigaOne because it was used as an example in the discussion before.


If you follow the discussion then it went somewhat like this.

Me: AMMX is very nice for speeding up games.
Me: AMMX has some game coding instructions which for example other SIMD like ALTIVEC not have

But ALTIVEC is faster

Me: This depends on the usecase, there are usecases where ALTIVEC is great, and there are usecases like game coding where AMMX is much nicer to use and has more performance.

maybe at the same clock. But the PowerPC Amigas have 800 MHz or 1000MHz
1000MHz = THIS IS ONE GIGAHERZ!!!! THIS IS FASTER you can never beat a gigaherz

Me: yes, 1000Mhz is higher clock than 85Mhz.
But this does not mean that all the games will run faster.
The 1000MHz is inside the CPU only - the G4 bus to the mainboard runs at 133MHz only.
And 133MHz is actually very similar to the 85 / 100MHz of the 68080.
And in real world there are games running faster on the 68080 than on the PowerPC Amigas with 800 MHz or 1000MHz

Give us numbers as proof. Or you are a liar!

This is how we ended here..[/quote]
Yes, it's a lie, because I've stated one precise statement whereas you completely derailed the discussion instead of proving that my statement was wrong.

@Gunnar

Quote:

Gunnar wrote: @NutsAboutAmiga Quote: Lets summarize: Using 2 x memory sticks never worked reliable, it had issues with interrupts (often IRQ was disabled in drivers, using PIO4 mode), AGP never preformed to specifications, USB ports was f*cked, and L2 cache was most likely deactivated. WOW, these are many problems. Lets make this clear. I would not have started this comparison. I was repeatedly asked to give proof if AMMX can beat a 1000MHz PPC. My initial point was that AMMX is very nice and useful for game coders. And I was comparing coding games with AMMX versus ALTIVEC, simply because I have decades of ALTIVEC coding experience and I know the pain trying to code games with it. As you might know, I worked for IBM and was coding some of IBMs SIMD performance libraries. IBM uses Altivec a lot, even for speeding up certain DB2 database operations. Cesare is angry with me because I called him out as "Forum-Pretender". Now Cesare tried to twist every word from me to proof that I'm a "liar".

Angry for what? I'm still waiting that you prove that my statement, that YOU quoted, is wrong.

In the meanwhile you derailed the discussion with a lot of padding and things that aren't related.

In my opinion:

The POWERPC is a very good CPU for its intended purpose.
The purpose of the POWER CPU was to do floating point number crunching.

The POWERPC was not designed to be an 68K replacement.
It was sold like this my Apple, but it was not designed like this.


I think, the 68K has a number of design strong points.

a) very powerful EA-mode / memory operations
b) very powerful instructions
c) very coder friendly, very easy to learn and to code
d) very compact code
e) Good integer performance


POWER/PC has disadvantages in all these areas.
a) Power has some EA modes, but as powerful as 68K
And of course POWER can work directly on memory.
And POWER can not use 32bit or 64bit Immediates.
b) the power of instruction set of POWER is actually good.
In my opinion the 68K has some advantages.
c) POWER is very difficult to code.
Its assembly very difficult to read. And programs need a lot instruction than on 68K
So the AMIGA spirit of assembly demo coding is gone on Power.
But POWER is also very difficult to code in other areas.
The weak memory model makes multi-threaded coding very difficult.
e) All RISC CPU have a major design disadvantages with Integer code.
Integer code often work on memory, and often uses immediate.
RISC CPU can not directly work on memory, and are very limited in using immediate.

Example:
ADDI.l #$123456,$mymemoryvariable

Even such simple 68K instructions are a challenge for all RISC CPUs.
The RISC does not support the immediate and needs extra instruction to construct it.
The RISC does not support the memory address and needs extra instruction to construct the pointer
The RISC can not directly work on memory so its to need to add a LOAD and a STORE instruction.
For a single simple 68K instruction the POWER often needs 5 instructions.
Its no secret that RISC are always on a disadvantage with integer code.
This is why INTEL kicks IBM ass in the integer field.



What I liked a lot about Amiga was the easy demo and game coding.
The Amiga had a very nice to code CPU.
The instruction set was powerful, and it was enjoyable to code the Amiga in assembly.
What I also love in AMIGA is the DMA based, clever chipset.
Which allowed the coder to do clever things and to do many things very efficiently.
DMA audio, Copper, Sprites, you know what mean
For me these things are very cool on Amiga!


And for me the PowerPC machines miss all what I liked at the Amiga.
They lack the Amiga chipset that I liked, they are difficult to code and the cool Amiga game, demo coding fun is totally gone. The POWER CPU is really a pain to code in ASM.
I speak from experience have written huge libraries in PPC-assembly and was a pain on POWER.


I think it depends what you want.
If you like to code in assembly - then 68K rulez
If you understand how elegant the AMIGA chipset was.
And if you enjoy the elegant idea of the AMIGA design ... then you will miss this beauty on a PC hardware.

If not are not interested in assembly coding, and not see the beauty of the Amiga design - as I do - then you maybe find these PPC good.

But I'm not here to judge. Each his own. Use what you like.

@Gunnar

Quote:

What I liked a lot about Amiga was the easy demo and game coding. The Amiga had a very nice to code CPU. The instruction set was powerful, and it was enjoyable to code the Amiga in assembly.

This was a large part of the motivation behind MC64K.

_________________
Doing stupid things for fun...

Cesare Di Mauro,


Quote:

That's because nobody took care of proper conversions, like I've stated before. So, the problem wasn't about the systems, which were perfectly able to run those games even in FullHD (and more) with much more FPS: it was about the developers which did a very bad job with the port

Thank you very much, for your wise words of the arm chair Amiga coder.

OK you rant now how all game ports for OS4 suck?
How much SCUMM sucks, how much MAME sucks, that DOOM sucks, that DIABLO sucks, that in fact all Amiga game ports are terrible because the coders did not rewrite the games from scratch - like a "proper coder" would do?


So all Amiga developer suck, right?
They all did a very bad job?


Look, the point is they did a job
Someone at least ported DIABLO to OS4.
Someone at least compiled SCUMM for OS4.

Cesare the arm chair expert who does nothing but posting in forums.
He tells all Amiga developers which in opposite to him actually do something for OS4 for Amiga - that they suck?

@cdimauro

Quote:

Whereas YOUR assumptions about kolla's systems are OK even if they were completely wrong?

Do you really call me out for misunderstanding an english word?
Kolla said: "I have an actual Vampire here"
I know the word "actual" under the meaning of "current, latest, newest"
The V4 family are the current systems, and the V2 are the old discontinued family.




Quote:

Care to show me which game have you developed for Amiga?

We just spoke about many of them.
Apollo-Crown, Dr-Apollo, I'm currently working on Apollo-X
And I participated in several. The port of Robin-Hood to MorphOS, does MorphOS count as Amiga?

@cdimauro

Quote:

And nobody of them produced something comparable to Fightin' Spirit and USA Racing...

Where is "USA Racing".
Please give us the EXE, so that we can see what comparable to it is.

Quote:

And nobody of them produced something comparable to Fightin' Spirit and USA Racing...

What do we know about "Fightin' Spirit"?
We know for sure that you were not the lead developer.
We know from you that many of your proposal for the game were rejected.
Cesare Di Mauro, do you take credit for your friends achievements?
Don't do this.

I not try to take credit for "APOLLO-INVADER".
Arne did ask me a few times, and maybe 10% of the code in the game are mine.
But this game is not my achievement. Its Arne achievement he did the most.



Cesare all we see that you pretend to know so much about Amiga coding.
And you pretend you would have done "very important code",
25 years ago in an Amiga game with your friends.
Do you really think all forum readers here are stupid?


Where are your demos?
Where are the games that you did in the 25 years after?
Where is anything?
Did you had an accident and lost your memory and all your programming knowledge?
Why did you not do anything at all, in the last 25 years?

Do you really think, that we not all see through this?

Cesare please stop pretending to be something which you are not.

@Gunnar

Hey, I have an idea for you. Something to heal this rift. The original point of this thread was based the suggestion that arbitrary depth (specifically non power of 2) packed pixels are not only possible but, some of us think (myself included) faster to work with and more efficient than using separate bitplanes. The various technical points are near the start of the thread. The key points are that it's only moderately more complicated than working on a single bit plane (complications include where a pixel's bits span a machine boundary). Generally you'd work in multiples of 8 pixels, where the multiple is a bit depth. So for 5 bit depth your 8 pixel span is 5 consecutive bytes and so on. You can extend this out, e.g using 32-bit words as the basis, then you are equally restricted to multiples of 32 pixels.

Experiments in software show this works, but maybe you could have a think about how you might implement something like this in actual hardware. I won't pretend for a second I have the domain expertise for that.

_________________
Doing stupid things for fun...

@Gunnar

Actual Vampire cards were made by Majsta, the V4s were not (as you have pointed out so very clearly) and are hence NOT Vampire. There must be SOME reason why the word “Vampire” is absent from all V4 product information - at least be consistent.

Oh, and how about that open source SAGA? I have zero interest in the AC68LC080, but SAGA might be of interest, but only if generally available and not tied to all kinds of nonsense.

Last edited by kolla on 08-Oct-2022 at 12:27 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

Amiga with RTG and AmigaOnes supported little endian as data format. For obvious reasons.

its not by choice, its just they things are…
naturally some stuff is equally CPU intensive on BE as LE.
ARGB or BGRA if I do…

uint32 ARGB = A << 24 | R << 16 | G << 8 | B;

or if do:

uint32 BGRA = B << 24 | G << 16 | R << 8 | A;

you also do it using unions, makes it pritty easy too.

It’s acutely the same operations, writing it to memory is the same operation, pixel by pixel.

now if had to work with 24 bit this becomes complicated… now as you stuck with 8bit/16bit and 32bit, there are no 24bit assembler operations.

15bit / 16bit is also a bit crap, but can be overcome with a simple lookup table, at least that’s what I found to be fastest.

8bit is the same on BE and LE, not an issue at all.
converting it to ARGB or BGRA is pretty much the same operation.

Now what can mess this up, is if the person writing the drivers, decides, he is going to do the endianness conversion, now you paternally end up with something that was simple, ending up with lots of endianness swapping, and I think that’s the pitfall here.

Sure other issues as well, like floats, shader code, and other stuff need be uploaded to a modern GPU.

Last edited by NutsAboutAmiga on 08-Oct-2022 at 12:28 PM.
Last edited by NutsAboutAmiga on 08-Oct-2022 at 12:27 PM.

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

Aloha Karlos,

Quote:

So for 5 bit depth your 8 pixel span is 5 consecutive bytes

Maybe you want to also compare it other existing implementations.
For example ATARI planar. Have you used it, do you know the layout?

Or compare with Amiga "AAA" chipset. AAA did had hybrid pixel.
You could set planes to 1bit, 2bit and 4bit mode.

@Gunnar

Yeh the ATARI format in interesting, packs the planes closer, can be advantage doing pixel operations.

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

@kolla

Quote:

Actual Vampire cards were made by Majsta, the V4s were not (as you have pointed out so very clearly) and are hence NOT Vampire.

You misunderstand this.

We just focus in our naming on "Apollo".
We have :
Apollo-Boot, Apollo-Rom, Apollo-OS, Apollo-Core, Apollo-Invader, Apollo-Menace, Apollo-Crown, Apollo-X, Apollo-Blocks, Apollo-Shield.

The V4-SA is the "Vampire" its "Apollo Vampire 4" and its logo is the BAT.
The Vampire and also all the other new card names are "sprites" from an old Amiga game.
We think that using different "sprites" for the different accelerators was a very good idea.
The different names makes it much clearer about model you talk when speak with customers.

Quote:

The Vampire and also all the other new card names are "sprites" from an old Amiga game.

Can you guess from which Amiga game all our cards are named?
We have the following cards:

* Vampire
* Firebird
* Icedrake (Dragon)
* Salamander
* Manticore
... in development is "Kraken"


Do you know the Amiga game?

Last edited by Gunnar on 08-Oct-2022 at 01:01 PM.

@Gunnar

I'm not familiar with the Atari bitplane format. I know it was different, but not much else. Something closer to interleaved?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @Gunnar I'm not familiar with the Atari bitplane format. I know it was different, but not much else. Something closer to interleaved?

ATARI has 1 Planeptr only.

The format is 1 WORD per plane.
In 4 color mode the memory looks like
P0,P1,P0,P1,P0,P1,P0,P1

In 16 color mode the memory looks like
P0,P1,P2,P3,P0,P1,P2,P3


Super-AGA supports both Amiga and Atari formats.