PC still playing Amiga catchup

[Roondar]

Sorry to disagree, but I can boot up in REAL mode in DOS using a floppy disk and write to same I/O registers directly for many sound blaster cards, read/write DMA data, read/write memory mapped areas for VGA, etc.  There's no OS running that is trapping the I/O locations or memory areas and emulating the features.  Some may be doing it in software, but those examples I gave I know aren't just software running in the background.

For simple stuff like VGA, yes.

For more modern hardware this doesn't fly. Meaning that you can't actually access the 3D portions of your Nvidia GFX card the same way as your ATI GFX card or your onboard one.

Heck, from what I understand the implementations might not even be the same for different cards from the same company. Meaning a Nvidia 9600 and a Nvidia G260 might need altogether different ways of being accessed.

They don't do this to stop backwards compatibility, they do this because it's the best way to get high performance out of your chips. For a well documented example of why you sometimes need to break with the past to move on, look no further than Amiga AGA. That could have been so much more if Commodore had not tried so hard to keep compatibility and instead had designed a new chipset around more modern technology.

[Roondar]

I don't agree with you at all.  I gave you the example of VGA-- it could have been implemented just as efficiently while maintaining hardware level compatibility.

No, it couldn't. Keeping hardware backwards compatible leads to bad stuff - like AGA palette changes needing a gross hack, or a PC architecture that struggled for years with limits based on old AT hardware. The PC only recently started recovering from the legacy hardware mess. And this was not a bad thing at all.

[Roondar]

I still remember TSR SoundBlaster emulators.

And how they never worked quite right

[Roondar]

AGA palette changes being more complex that it was is because they wanted to save on register space not because of backward compatibility.  Legacy hardware ports is what is currently making some tasks possible (especially real-time stuff) which would otherwise be impossible under modern systems.

That is not what available documentation from Commodore suggests.

[Roondar]

Able to run multiple FLV in HD, upscale DVD (e.g. PowerDVD , play Blu-Ray 1080p movies, mobility and 'etc'.

I hate to nitpick, but he stated 'probably 15 years ago'.
I'd hardly see you doing any of those things on a bog standard PC from 1994

Heck, most of the PC's out there today can't do all of those things, let alone at the same time.

(Disclaimer: this does not mean I don't feel PC's have long since surpassed the old Amiga, it merely means I feel most people on these boards overstate the capabilities of the average PC)

[Roondar]

Hi,

@Amigaski,

A Palette Swap is a concept most commonly found in fighting games. Palette Swaps occur when two or more characters share the same style sprite or character model with only minor color or cosmetic changes. Although visually similar, pallet swap characters may have very different moves and personalities.

So far as I can find a palette swap is used in only 38 games.

Oh my God that is a lot of games, how can I cope with this grave defect in API's, I am going to junk my PC and return to the Amiga because of this defect, to think that I am slowing down my computer when I play these 38 games out of thousands that are out there for the PC.

Thank You Amigaski for bringing this grave defect up, I will always be grateful to you

Palette swap games as follows:

1.  Battletoads
2.  World of Warcraft (now wonder I always lose, I didn't think I was that crummy)
3.  Bionic Commando Rearmed
4.  Soul Calibur IV
5.  Super smash Bros. Brawl
6.  World of Warcraft: The Burning Crusade
7.  Phantasy Star Universe
8.  Mortal Kombat Armageddon
9.  Soul Calibur III
10.  Street Fighter II Turbo: Hyper Fighting
11.  Samurai Shodown V Special
12.  Disgaea: Hour of Darkness
13  Soul Calibur II
14.  Supr Smash Bros. Melee
15.  Advance Wars
16.  Diablo II
17. Diablo Gift Pack
18. Sour Calibur
19.  Might and Magic VI: The Mandate of Heaven
20.  Mortal Kombat 4
21.  Samurai Shodown IV: Amakusa's Revenge
22.  Heroes of Might and Magic II: The Succession Wars
23. Mortal Kombat Trilogy
24.  Ultimate Mortal Kombat 3
25.  Lufla II: Rise of the Sinistrals  
26.  Mortal Kombat 3
27.  Killer Instinct
28.  Mortal Kombat II
29.  Battletoads In Battlemaniacs
30.  Mortal Kombat
31.  SuperMario Bros. 3
32.  Final Fight
33.  Goldern Axe
34.  Barbarian
35.  Super Mario Bros.
36.  Mario Bros.
37.  Joust
38.  World of Warcraft

There you have it people the 38 games made that have the critical pallette swap error using API,

Thank You Amigaski for this very important information, we are very obliged to you for this information.

Now can you tell us what kind of drugs that you are on, we would all like to get some of it because it has to be really good stuff.

smerf

I think he meant the practice of changing the onscreen colours in non true colour systems, such as the index based palette colours used on the Amiga and VGA/SVGA 256 colour mode. As in, when you change (or swap) colour one from blue to green and all pixels which where blue are now green.

Which is not relevant in todays games anymore at all because no games made these days still use index colour modes like the old ones did and GFX cards are fast enough* to change every pixel on screen from one colour to another in less time than it takes to draw the pixels on screen anyway.

It was a cool trick back in the days though. Lots of copper tricks are based on the index colour nature of Amiga displays. Colour cycling is also one of the tricks make possible using this technique. Then again, they had to because the machines back then where 'not very good' at displaying true colour images. These days all these effects can be done the brute force way and developers no longer really care about 2D performance anymore.

*) By at least one order of magnitude, probably way more.

[Roondar]

An internal Blu Ray drive will run around US$110.  So it should have been a bog standard PC + US$110.  The news said the US turned off it's non-HD TV last Saturday, where does that leave non-HD Amigas?

Quite true. However, the fact it was not installed by default will be enough for 95% of the people owning a PC to not have one. Only a very small percentage of computer users actually care enough about such things to add stuff to their computer later (internally that is). I'm guessing most people will just buy a PS3 or standalone Blu-Ray player if they want one.

Case in point: the latest PC rage (well, over where I live anyway) is the netbook style mini-laptops. Everyone wants one. No one cares they have sub-par specs.

As to the Amiga.. Well, it's still a nice retro-puter even without NTSC being broadcast

[Roondar]

Hi,

@Roondar,

Yes, I know, but I just wanted to show him just how signicant this is with today's modern graphic cards. I mean really you are comparing a chip that moves at a speed of no more than 14 mhz -28 mhz compared to a modern day graphics card that has core clock speeds of 400 mhz to 800 mhz or faster and is moving pixels like a freight train moving at the speed of light.

I mean come on I like the Amiga too, but after using Amiga Forever on my PC than going back to my Amiga 4000 it does seem like it is moving slow, but I like it like that because it keeps me from turning it on that much, should make it last longer.

smerf

Like how I develop my C64 programs on WinVice these days and only test them on the real hardware afterwards. Don't wanna break my lovely 8-bitter!

Anyway, you are of course correct - modern day GFX cards run at silly speed (thats several steps above ludicrous speed by the way). The day for Amiga custom chips is long past.... Though that doesn't mean I don't love the old Ami

[Roondar]

Which is faster: MOVE.W $DFF00A,D0 or going through a serial protocol?

That's a dishonest question.

But I'll bite.

The PC implementation (using API's etc) will be faster doing it's poll than the Amiga's MOVE.W will be. Even if the serial protocol itself is slower, the vastly (and I do mean vastly) faster processor will need less time to execute the whole API based serial poll than the Amiga's MOVE.W will take.

Now, that the serial port on the PC is usually sucky and hence slower to be sampled is another matter, but the fact is that the code driving said sucky serial port is extremely likely to be faster than the MOVE.W.

If only because your 3Ghz machine can execute it's code -literally- thousands of times faster and the API overhead is not adding thousands of times more code.

[Roondar]

I wasn't referring to the old serial port-- but USB HID being a serial protocol.  The I/O instructions aren't running at 3Ghz.  In fact, I have experimented a lot with I/O to parallel ports and other I/O instructions and some old machines running at 100Mhz...400Mhz have faster parallel ports than machines running at 1Ghz and above.  Take for example a Toshiba Tecra 8000 at 300Mhz-- it's parallel port gets 1 megabytes/second easily (going direct to hardware of course).  Now take a Thinkpad A31 (1.6Ghz) and it's parallel port gets only 700Kilobytes/second (going direct to hardware w/o bullcrap APis).

So a MOVE.W on Amiga OCS takes a few microseconds consistently.  Using a serial protocol involves a lot more I/O instructions which aren't that much faster as processor speeds are.

All of which still does not change that, despite a slower to react bit of port hardware that the PC will spend less actual time running the code to poll said port, even with the API overhead.

Or in simpler terms: the PC can do more other stuff while waiting for the IO device to be ready than the Amiga can. Which is to say that even though it uses API's to access hardware, thanks to being really, really, really fast it still is faster than the Amiga to execute the relevant code (i.e. poll the hardware).

That it needs to wait longer for the hardware to be ready is irrelevant because this discussion is not about the speed of a parrallel port controller (which is the primary cause newer PC's have slower ports) but about the overhead incurred by the API's and drivers driving said controller.

[Roondar]

It's given someone knows high level language and assembly, he can produce more efficient and faster code in assembly since he can better deal with misalignment, registerizing variables, use the flags optimally, etc.

This is simply not true.

Optimizing code is already quite hard to do in higher level languages*. Going to lower levels does not make it easier, it makes it harder because you now have to both choose the best algorithm (where 95-99% of your performance will come from - even the best assembly coded Bubble Sort ever won't beat even the lousiest Visual Basic Heap Sort ever for anything above say a thousand entries to be sorted), the best way to implement the algorithm you chose considering your application requirements and you also have to do that in the best, most optimal way possible in assembly.

Chances are you can do one or two well enough and fail at the other(s).

Not to mention that modern compilers are actually quite good at doing all the things you suggest as they use the same tricks you describe. Or the fact that todays programs tend to be a 'tad' more complicated than something as trivial as sending some bits over a parralel port. When your sourcecode is measured in megabytes you should be damn happy you didn't need to think about how to access the screen to write a few pixels on it but could just call a library to do so and be done with it.

*) This is one of the reasons that optimizing compilers these days optimize your code and their own assembly output instead of just optimizing their assembly output. And contrary to what you might think, the step where they optimize your handwritten code is by far the biggest gain, optimizing the assembly (better/optimal register use, unrolling loops, alignment, etc) gains less in almost all cases.

[Roondar]

It depends on what instructions you try to do in parallel.  If you do an IN AL,DX then TEST AL,128 obviously, you processor has to finish the IN instruction however long it takes.  I was giving case where using AMIGA direct access outdoes PC going through API since API is more restricted than going directly to PC hardware.  So, you can't draw the conclusion that API access will be still faster than Amiga going direct to hardware.  If API call was just doing the exact thing you would have done with the hardware, then you can say the overhead is minimal given processor speed of PC.  Also for input like USB input of joystick or gameport input of joystick, you will be doing multiple I/O instructions whereas Amiga does one.

Unless it's interupted during the IN AL,DX by say, the task scheduler and gets to do something else. IO is almost always done in an synchronous way on PC's. And I'm pretty sure that waiting on the joyport/parrallel port/serial port/whatever port doesn't actually stop me (and therefore the processor) from doing other things.

I don't know what you mean by parallel port controller is primary cause of slower ports.  It's not.  Parallel ports are usually PCI in the latest machines that have them; however, there are other I/O ports like 60h..64h (keyboard) that are much slower.

I misread which port you where talking about.

[Roondar]

CUDA processor has multiple texture address units. You did not address "frame per second" rate. Comparing Amiga's play back capabilities against ATI's UVD and NVIDIA's PureVideo is laughable.

I'm beginning to think that amigaksi is actually not debating the actual time needed in some of his examples, but purely how many processor cycles it takes to achieve them. I could be wrong here, but if he does it would explain some of his objections.

Needless to say, this is not a very good way to look at things. Almost everything in modern computers (and that includes setting up the GPU) is IO limited and not processor limited. Severly so. Even onboard RAM is considered 'very slow' by the processors of these days. And that doesn't even go into the effects caches, multicore, pipelining, branch prediction, etc have on just how many cycles something takes to do.

In essence the IO overhead limits or even outright negates any API overhead you might incur.

[Roondar]

He basically implies, that today’s engineers are dumb and stupid. He didn't factor in the overall performance of the system. Refer to my posted PS3 RSX shader example in relation to instruction pairing.

And all of that is only considering the hardware side. The whole argument breaks down on the software level anyway - software these days is so much more complicated that you don't want to think about the hardware while writing it (to such an extent as is possible). You don't want to think about the endianness of your processor, the type of harddisk controller you are interfacing with, etc, etc.

You only want that level of control when absolutely needed and not as a basic requirement to write software. You don't want all that added headache when you are writing your enterprise-class ERP product or multi-gigabyte multimedia program (something like, say, World of Warcraft). This is the real reason API's are such a good thing and it's one that is being completely glossed over.

In terms of computation intensity, Geforce 9400 IGP kills Core 2 Quad using the same memory bus.

Indeed, though I will add that the average GPU is not in all situations a good CPU (even though you can run code on them). The reverse is, however, never true. Even a really fast CPU is still not going to beat a GPU at its tasks.

And it doesn't change anything about my statement, really (except maybe the bit about GPU access). If main RAM is too slow for your CPU that means your CPU is not going to be computation limited but IO limited instead. Let alone how many wait states you'd introduce by getting data of a stupendously slow thing like a harddisk or even worse, a USB mouse.

Lucky us programming evolved beyond polling until it's done in most cases and, wisely, this is only done these days when it can't be helped (or you have a bad programmer ).

[Roondar]

Don't get me wrong folks, I'm delusional that a thread on this site can still pull 1000+ responses in a short time.  I just wish it was all threads..  Then we might actually be able to say that the Amiga isn't dead after all..

:laughing:

Well, my Amiga's don't appear to be quite dead yet.

The platform?
There is that saying about horses....