PC still playing Amiga catchup

[amigaksi]

Banging the hardware was a cheat, it allowed you to do things on the underpowered machines of the '80s that simply wouldn't be possible if you had to wait for the OS to do them....

I agree with this completely if you replace word "cheat" with "feat".
It's not a cheat.  It's what hardware is capable of.  Now in modern systems, some tasks require critical timing loops and can't rely on making API calls and making things vague.  Or they want to do something API restricts them from but easily can be done with directly accessing the hardware.

>The trade off was stability, you have code going around the already unstable OS to bang at hardware that may or may not have changed.  

If the hardware is backward compatible, there's no problem with stability.  If OS is unstable for some API calls (bugged), then going directly to hardware makes OS more stable.

>Amiga graphics were simple, a single chip and a few meg of RAM.  Today's graphics are much more complex, a half gig of RAM, a GPU and other hardware.  It's like comparing a sundial with an atomic clock, there is no comparison.

Simplicity and complexity have nothing to do with making hardware backward compatible on I/O port level.

>You have power, you have speed, you have an OS with memory protection and now you have drivers in user space.  Trying to bang the hardware in a dual quad core processor with GPU environment is just stupid.  Especially to try to read the bounce of a joystick...

If you had some application where you wanted to control which part of the program executed by which core at exactly which time, you are better off with hardware level compatibility.  You picking on my joystick recorder again?  It wasn't bounce.  But let's say you want to measure quality of joysticks in a PC application, then reading bounce is of utmost importance and that works better going directly to hardware as well.

>You got a FSB in the GHz range, on a 4000 you've got a bus speed of max 25 MHz.  Your talking to the GPU over an order of magnitude faster than the Amiga talked to Fast RAM.

The principle is the same.  Just because you have a faster system doesn't make APIs catch up with hardware level access.

[amigaksi]

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.

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.

[amigaksi]

That scream you can hear in the distance was the cries of every professional developer of every game and desktop apps studio in th industry crying out in horror at the concept of what you've just written.

Things move too fast and are now so complex that to support even a major subset of capabilities on modern hardware without an overall API to build upon as to make the suggestion completely no go. At best, you would end up with a situation where each software developer would effectively have to write and maintain their own (likely) incompatable layer which would then have to fight other softwares API in order to function.

At which point, you have just effectively rendered the whole point of having an OS completely meaningless.
...

OS is easier to write if all the hardware is backward compatible.  No need to find drivers since all I/O ports are compatible.  Even Windows OSes rely on VGA standard in order to initially boot up.  Then they do a desperate search from a bloated database of 1000s of drivers to try to map to your particular hardware.  That's one reason why AmigaOS (at least up to versions I have) is smaller and quicker to boot/install.

The screams you hear should be louder once you explain to them that API is actually HLI (hardware limiting interface).

>...emphasis to OS friendly applications. The OS deals with the hardware and keeps everything ticking along and the software sits on top. The way things should be.

You can still have that and have hardware level compatibility.

>Name three often used desktop applications that cannot by virtue of their function be made in an OS friendly fashion.

Why 3?  Look at it generically-- any task that requires computations or timing and GUI interaction and wants to run as fast as possible is better off going directly to hardware.  For example, in some tight loop it's better to do IN AL,201h and test the upper bits to see if a Gameport joystick button was pressed then to call an API function to retrive button status.

>I'd bet good money that there was a way within DirectX to call a non standard screensize.

Well, you can set various graphics modes with API or directly so that's not the argument here.

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

[amigaksi]

That is not what available documentation from Commodore suggests.

I don't see any reason why hardware could not be extended with 256 palette registers using different locations rather than overloading the same 32 registers.

[amigaksi]

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

You have a problem understanding me.  Your argument does not show that they cannot have hardware compatibility.

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

No, the joystick argument is over-- Amiga won hands down; it can't be torn to shreds until people stop selling gameport based joysticks and 99% of the people adopt nonexistent USB 3.0.  List of my points is given in post #275.  Now we are talking which has better implementation of hardware for real-time tasks.  Amiga has API and hardware level compatibility.  PCs have moved away from that since early 90s are going toward the inferior solely API-based method.

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

That was not my argument, but there are bugs since they are up to version 10.0 DirectX or something around that number.

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

Creativity is limited by the choices you have.  If you have a C64 and want to use colors, your creativity to paint a picture is limited by 16 colors from palette of 16.  If you have an Amiga and want to use colors, you can paint the C64 pictures as well as make pictures not doable on C64.  Similarly, having just API is restrictive but having both API and hardware level compatibility opens up a lot more possibilities.

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

I never said APIs should be removed and only hardware level programming should be done.  But having that option gives you more possibilities with the machine.

>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:

I gave you a better answer than 3.  If you just want three, my floppy simulation is IMPOSSIBLE to do with API calls; I have this DOS program that does echo effects on DMAd data going to audio card in real-time-- that would be affected using API calls.  I have a joystick recorder which would have problems if it relied only API calls.

[amigaksi]

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

Amiga seems tons of games that go directly to hardware and still have a multitasking OS. It's wonderful that some systems allow you to take over the hardware and use all of it for your application-- you really get to use what you paid for and it works in general not just for your Amiga.

[amigaksi]

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

But if the hardware compatibility is required for newer hardware, then metal won't change registers or affect previous software.

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

Thanks-- some people can't even accept that direct hardware access wins everytime.  The point about processors being much faster is fine, but I/O instructions haven't sped up like processors have.

[amigaksi]

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

Suppose you want to use mode 640*480*16 paletted mode and read palette register #3 and swap with palette register #15.  I can do that with a few IN/OUTs using standard VGA registers or doing MOVE.Ws to $DFF186/$DFF19E on Amiga or a few LDA/STA on 8-bit computers.  Let's see your API calls to do that.  Since you seem to be pretty up to date with all the latest video cards and hype of APIs and video cards are frequently updated and are using best possible technology-- let's see how efficient their APIs are.

[amigaksi]

I still remember TSR SoundBlaster emulators.

If you boot DOS in REAL mode and directly access sound blaster registers, there are no TSRs running nor anything else and your IOPL=0 so nothing is trapping your using the ports.  If such an application works, you know it's hardware compatible with Soundblaster.

[amigaksi]

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.

I have games on Amiga which take over the system and also come back to OS without it crashing so it's doable.  Also, I myself take over Windows 98SE OS and write directly to VGA memory and then restore the OS as if nothing happened.  In fact, there's a built in function in Windows 98SE although undocumented that lets you take over video registers.

Tweaking is unrelated to using hardware registers.

[amigaksi]

As an example, Gravis Ultrasound Max uses TSR Soundblaster emulation. GF1 chip is missing the AdLib-compatible OPL2 circuitry.

You lost track of the point.  There are SB cards that are backward compatible on hardware level.  I proved it by running in REAL DOS mode.

[amigaksi]

By the very nature of evolution within computer hardware, at some point you have to let go of hardware compatability or you are forced to produce ever more drastic hacks in order to maintain it. At some point the value of creating these hacks for infinatesimal improvements, not to mention newer concepts within computing make this a no go. It is far easier to produce an API to bridge basic support (such as VESA) then to build it into hardware.
...

Sorry you missed the point of how VGA is backward compatible on hardware level with EGA/CGA.

>You cannot say that given that you made no effort to test that the data you were recieving wasn't infact signal noise, indeed your "proof" was and is as it stands utter garbage. You were given a solution that would test it one way or the other. I have yet to see you put your hypothesis to an actual test yet. Simply repeating "it's better" over and over does not make it so.

You missed that point as well then.  I gave you LOGICAL statements how you can have millisecond readings which you NEVER replied to.  Just declaring it "garbage" does not change reality.  You are as biased as they come.  It's faster EVEN IF YOU DON'T SAMPLE AT 1KHZ.

>There is always likely to be bugs in software, but that is not the same as a flaw in an API and you should damn well know that! Also, DirectX now supports a great many things that it didn't in the past, the reason for version changes was to allow for the addition of newer capabilities, bug fixes have nothing to do with the DX version number.

I said it's not my argument but I know there are bugs in implementation of the API where certain video cards don't work the same for the same function.

>Correct. But also wrong. You are also limited by your own abilities. Doing things your way means extra work and hassle for everyone else.

Yes, you are limited by your abilities, but you are more restricted with just an API rather than both API and hardware level compatibilities.

>...software finds out that it's been hardcoded for something he doesn't own instead of using the OS's APIs

You are caught in a cyclical reasoning loop.  We are claiming it's better to have hardware compatibility.  Given that, you can do both-- API and hardware level programming.  You are now claiming, suppose he doesn't own that piece of hardware.  Well, that assumes it's not hardware compatible.

>No, you really didn't. Making baseless claims does not constitute an answer.

I gave a general answer-- any application employing time-critical loops.

>Which part of Commonly used desktop program was not clear? Joystick recorders and floppy drive simulators do not constitute anything like commonly used, I doubt even within development circles they're used all that often.

It's commonly used for me.  That's subjective really to say "commonly used".  And why does it matter-- it's an application that can be written only if you have hardware compatibility.

>Secondly with regard to your alledged DOS program, prove that a modern day OS using an OS friendly program that allowed for realtime effects couldn't do as well if not better. I mean real proof.

Only if the real-time effect you are trying to do is supported by an API call.  But as I stated before, you can manipulate I/O ports in so many ways and not all of them will have APi equivalents.