PC still playing Amiga catchup

[amigaksi]

Amen. Essentially that's what this thread is doing, comparing two very different pieces of technology which were developed for their time.
 
Similarly we could argue that the horse and cart is superior to today's motor vehicle eg.  Horses were enviromentally friendly, there were fewer crashes, they were self repairing and could multitask ( poo and walk at the same time

Bullcrap.  Amiga is more efficient at certain real-time tasks than modern PCs.  And one reason being discussed presently is because it had hardware level compatibility rather than just API level compatibility.  The other reasons like having digital joysticks vs. analog joysticks, having ability to do cycle-exact timing, etc. were already mentioned.

[amigaksi]

True, but even if your code isn't in of itself flawed, it might interfere with other code (that again might not be flawed) in ways that are undesirable. I would have thought one of the major benefits (outside of the time requirements, especially of modern hardware) of running via APIs was that it set out rules and systems to stop that sort of collision from occuring.

But all of this is moving away from the central point of Amigaski's claims of the Amiga's superiority based wholy and solely on an (as yet) unproven hypothesis.

You can set rules for hardware level compatibility as well.  So many people made Ps/2 type keyboards but they all worked with IN/OUT AL,60h..64h in DOS.

What unproven hypothesis?  Amiga has both API and hardware level compatibility-- that's better than relying on some API which may be bugged, you have little information as to what it actually does, and is definitely slower.

[amigaksi]

Reality check: software is worthless without hardware to run it on. Rather than slamming what was once state of the art (I don't suppose you could have done better?) saying it was "underpowered" because it wasn't convenient for what you personally imagined was the One True Way of doing things, consider that people who wrote the naughty code ("cheat") actually created successful products.
...

I wouldn't label it "naughty" or "cheat".  I used direct hardware VGA access or other direct hardware access in all my products (http://www.krishnasoft.com); I allowed for APi method as well in cases where it wasn't available (like Windows XP).  Even under Windows 98SE, you can directly access VGA card (for standard functions), keyboard ports, parallel ports, etc.  XP restricts you a bit more.
And the results are better when going direct to hardware.

[amigaksi]

I've just 'bolded' two words and you've got your answer. Times change, habits change, ways to do things change. A long ago moving balls over lines was a fast way to do computation, today any mobile phone can do the job of a pocket calculator, many magnitude orders faster, simplier and more accurate (in a word: better). Everything that once was a good thing, today is a hack. It happens for TV sets (no more banging on the tv-tuner frequency with a potentiometer, but choosing fixed frequencies pressing keys on remote command), it happens for computers (no more banging the hardware, but calling APIs), and every time progress has its advantages (many) and drawbacks (very few). Yes, flawed code is always flawed code, but how many chances there are, now, that it can mess up the whole operating system if it crashes? On AmigaOS, the same. On any other CURRENT architecture with protected memory, almost zero. I agree with you when you say that old 'hacks' were sometimes state of the art and masterpieces (who can forget Amiga demos?), but I absolutely can't think banging the hardware would be feasible TODAY. The price is a fraction of my 2.6+ GHz processor power, or the inability (:roflmao:) to poll my joystick port (:roflmao:) 1000 times per second? I can live with it.

regards,

You are speculating it's "progress" to use only APIs.  It's FACTUALLY a big hit on creativity.  Now people have to rely on the same dull APIs and live with inefficient code and not knowing exactly what is happening behind the API.  It produces vague, bloated, dull code.  Joystick gameport was an example where Amiga wins even at the hardware level.  In other cases for real-time scenarios, Amiga hardware level compatibility makes it superior to API versions of the same program on PC.  Your 100Mhz or 2.6+GHz processor does not affect your I/O speed. Banging hardware is not possible today (for most cases) because of the mess up of not having hardware level compatibility.  I would rather use some check for I/O port to escape from a critical timing/computational loop than calling some GetMessage() API function which may call thousands of other functions and may not even return!

[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.

[Karlos]

I would rather use some check for I/O port to escape from a critical timing/computational loop than calling some GetMessage() API function which may call thousands of other functions and may not even return!

Sure, because the hardware equivalent bus error, context switch to supervisor mode, exception frame generation, processing, return from exception - all if you are lucky, is just the most efficient thing ever.

[ElPolloDiabl]

Take some solace:

I have not failed. I've just found 10,000 ways that won't work.
Thomas A. Edison

:rofl:

[the_leander]

What unproven hypothesis?  Amiga has both API and hardware level compatibility

The Amiga had only two major iterations in its entire life - OCS and AGA. Comparing that to the evolution of the PC from 1988-2009 is ridiculous!

Your original claim was that the Amiga was superior due to an alledged ability to detect button presses faster then a PC. Your only "evidence" to that effect has been torn to shreds. So yes, as it stands, your hypothesis is as yet unproven. You have since then tried to move the argument to API vs hardware banging.

that's better than relying on some API which may be bugged,

You have not shown that DirectX/OpenGL/OpenCL/Cuda/X are flawed.

Nor have you shown proof that having API's reduce people's creativity either btw.

you have little information as to what it actually does, and is definitely slower.

No, it might be marginally slower in some ways, however, going the hardware banging route is slow as well - in terms of development for starters, not to mention the very real issue you have completely dodged with regard making sure that multiple programs interact in a friendly way without them.

And I see you dodged the question on what commonly used desktop program could not be made in an OS friendly fashion. I wonder why that was :rolleyes:

[Hammer]

Continuation of my reply from yesterday...


I am treating VESA also as an API but at the time VESA BIOS was introduced, most of the other ports were standard so you can use VESA to set the video mode and then use direct I/O or write to video memory after that.  And putting VESA into ROM is better since you don't have to load any drivers that hogged up valuable DOS memory (from 640K).  In fact, I can call some VESA BIOS functions even from Windows 98SE (if they don't rely on selectors).  Games did not run in some cases because NOT all video cards had VESA BIOS or supported the various modes the game was requesting.  Those required a software (non-ROM) VESA Bios

>The overhead can't be that bad either as games still improved when we jumped to Windows instead of DOS, despite the fact by your argument the extra power in the PC should have been stolen in API inefficiencies.

That's not my argument-- the extra power was lost by API inefficiencies.  In all cases, you have more power with direct access to hardware vs. API.  Same for Amiga, if you go through API, your games will not make efficient use of hardware as if you go directly to hardware registers.

Define this lost of computation power. Large API inefficiencies is debunked by Fold@Home GPU2 CUDA example.

[Hammer]

You are speculating it's "progress" to use only APIs.  It's FACTUALLY a big hit on creativity.  Now people have to rely on the same dull APIs and live with inefficient code

Game content providers are only interested in providing content. They are not interested in worrying about the plumbing work. What we have now is RAD i.e. rapid application development. With XNA, one could easily build Super-Stardust clone with 3D based effects.

 and not knowing exactly what is happening behind the API.

This does not reflect the professional gaming development.

  It produces vague, bloated, dull code.  Joystick gameport was an example where Amiga wins even at the hardware level.

Sorry, Nintendo Wii’s control method is currently the leader in casual gaming. In E3 2009, both Sony and Microsoft announced motion based controls. With Microsoft's motion based controls, the handheld control device doesn’t actually exist i.e. optical based recognition.

In other cases for real-time scenarios, Amiga hardware level compatibility makes it superior to API versions of the same program on PC.  Your 100Mhz or 2.6+GHz processor does not affect your I/O speed. (SNIP)

In terms effective bandwidth, my laptop's ExpressCard I/O port is magitude faster than the classic Amiga hardware.

[Hammer]

I wouldn't label it "naughty" or "cheat".  I used direct hardware VGA access or other direct hardware access in all my products (http://www.krishnasoft.com); I allowed for APi method as well in cases where it wasn't available (like Windows XP).  Even under Windows 98SE, you can directly access VGA card (for standard functions), keyboard ports, parallel ports, etc.  XP restricts you a bit more.
And the results are better when going direct to hardware.

A Natami supporter...That figures.

[Hammer]

Bullcrap.  Amiga is more efficient at certain real-time tasks than modern PCs.  And one reason being discussed presently is because it had hardware level compatibility rather than just API level compatibility.  The other reasons like having digital joysticks vs. analog joysticks, having ability to do cycle-exact timing, etc. were already mentioned.

Pure efficiency has limits in respect to brute performance+efficiency and overall design of the system.

If you notice with CUDA processors, the extremely large register set is superior to Natami’s SRAM memory and CELL's SPE local memory.

[Hammer]

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.

Sorry, my laptop can play Blu-Ray 1080p movies in real time.

What target market are you targeting?

[Karlos]

All this harping on about API's being slow and metal banging being faster:

1) Metal banging is fun but fails the moment the metal changes, even slightly

2) Any loss of processor cycles involved in going down the API route is more than made up for in the fact that systems employing API access to devices tend to be running on CPU's orders of magnitude faster than the 68K.

Cycle for cycle, direct hardware access wins, but when your API is running on a machine that can execute billions of instructions per second, worrying about a function call that might execute a few dozen instructions to get the job done is quite simply nothing short of laughable.

[mongo]

All this harping on about API's being slow and metal banging being faster:

1) Metal banging is fun but fails the moment the metal changes, even slightly

2) Any loss of processor cycles involved in going down the API route is more than made up for in the fact that systems employing API access to devices tend to be running on CPU's orders of magnitude faster than the 68K.

Cycle for cycle, direct hardware access wins, but when your API is running on a machine that can execute billions of instructions per second, worrying about a function call that might execute a few dozen instructions to get the job done is quite simply nothing short of laughable.

Not to mention that banging the metal with a multitasking OS is generally a bad idea.

[alexatkin]

Going on about how you could still bang the metal in Win98 is amusing, seeing as that was the single reason why it was such an unstable OS.

Personally, I do not want to go back to the days where I fire up a game, it crashes, and I have to hit the reboot button because said game had taken control from the OS so there was no way for the system to recover from that state.  Or even if the game did not crash, often it would have corrupted the OS environment so I still had to reboot before I could do anything else.

Now compared to today, you can usually recover from any crashed state because games are using standard API OS calls so the OS knows what it needs to cleanup.  You may still get some memory leaks, but at least you aren't forced to immediately reboot in order to continue using the computer.

Lets face it, even games consoles do not bang the hardware anymore for the most part.  They have an OS all their own, they multi-task and have to play nice.  Even then there are still stability issues because they run as close to the metal as possible on APIs.
Oh and they also still get to optimise and improve their gaming engines (yet another API).  Imagine the love if their engine had to bang the hardware directly, not to mention the complexity of porting it to other systems.

As has already been said.  The greatest thing about APIs is how you can write a game on the PC and easily port it to Xbox 360.  Even then there are quite enough optimisations you can do for that specific hardware, even though you are still writing for APIs.  There would be no use at all for banging the hardware as developers do not have the time/money to waste tweaking their code to that degree.