PC still playing Amiga catchup

[the_leander]

Have you seen typical driver sets for things like graphics cards these days?

Thanks to direct support for CUDA, PhysX, OpenGL1.0 - 3.0, Direct X (up to v10), Pure Video etc, the drivers for my card alone weigh in at around 100 MB, not including tweaking tools.

The linux drivers aren't much smaller.

And thats mostly down to not having so many user definable options to adjust and things like real time previews of setting alterations. Either relying on the distro's own configuration menus or simply not allowing the options.

In a lot of cases it is litterally only a few megs either way.

[the_leander]

They are not identical.  Each real-time task has its own constraints.  With Amiga, given hardware level compatibility and exact timing using Copper, I can make real-time tasks with more precise timing constraints and right tighter code.  I am speaking in general that works for majority of PCs.  Yeah, you can make your specific PC do equivalent by adding customized hardware...

>No one disagrees that the joystick ports on the Amiga provide lower latency access to traditional digital joysticks; however, that doesn't make the Amiga "better."

It doesn't make the Amiga better, it makes it's joystick interface better.

>No human being can trigger a joystick at an input frequency of 1 kHz. (Something other than a human being might, but we're talking about human beings.) ...

Sorry, but joystick states can change-- I just dumped the data file from river raid in another message.

"Better" is subjective. If a human being cannot access anywhere near the full potential of this port, and the PC offers more then enough overhead that it is still far quicker then a human beings maximum potential reaction time, then seriously... so what?

I can't run a hard drive or a printer or any other of the miriad of periferals available today off of an amiga's joystick port, but I can run one off of any modern PC's USB port.

And you still haven't shown a single game that actually uses more then a tiny fraction of this supposed superior ports capability.

Untill you can show something that actually benefits by having this lower latency your whole argument is dead in the water.

[the_leander]

Be careful what you search for on the net these days. :nervous:


[EDIT]

I just realised this is my 2000th post no wonder I gained a rep power point.

Gratz!

I guess this means I'm going to have to really put my back in to posting more regularly again!

:laughing:

[the_leander]

No, you didn't answer the point.  What makes the timing consistent throughout ECS/AGA/OCS if crystals are so different as you claim?

Erm, as was pointed to in Karlos's drumbeat example:

There is no consistant timing


Now watch and learn as the rest of your argument is slowly chewed up and spat out.

[the_leander]

He hasn't proven anything about the timing of audio interrupts, CIA interrupts, Copper timing being different or varying over time.

You don't need to reference him; I read his posts.

If there is variance of clock speed (even by a fraction of a second) between two otherwise identicle systems using the same cycle, both cycles will still be identicle, but the timing will be different. This is demonstrable for anyone who owns more then one Amiga, even of the same model.

You're mixing up your definitions again, I personally think deliberately here.

[the_leander]

I asked you to reply to post #275; you did not but are now expressing your opinion again.

>Well, arguments as stupid as "you may poll the joystick port 1000 times a second, the PC cannot". Well, it's certainly *true*. But it is so useless that no one in the entire Amiga's existence ever mentionned or used it. No one but you...

The people who don't understand the argument are stupid.  Doing a MOVE.W $DFF00A,D0 is superior to polling an analog joystick (period) via port 201h or via USB.  Then I gave an example of River raid where 1Khz sampling can be used (and I did use it in a "Replay" mode) and this sampling is UNDOABLE on a gameport.

>That was my two cents. You can keep on posting detailed reports on how you can poll the Amiga joystick port faster than anything else, but this won't change anything to that...

You haven't shown PC doing faster joystick port input so we can move on to the next advantage Amiga has over PC.

You haven't shown that your own code is accurate yet either. But regardless, even if by some miracle it is I do have a question:

How is it in any way an advantage when both the Amigas and PC-USB based control systems are far quicker then human reaction times?

[the_leander]

Yeah, that's the rule.  But if the at ring0 you had standardized hardware, you can write more efficient code.

No, what you would have is a problem for 2 or three years down the road building up. The thing that killed the amiga was the fact that it could not keep up.

Anyone writing software tied to specific hardware in this day and age would be fired on the spot in any large software firm. And with good reason.

If those implementations were standardized like 8253 example I gave or even VGA standard modes, you can have more efficient code.  On Amiga, writing to OCS registers works for all OCS/ECS/AGA amigas.

Do you have even the slightest concept of how much things have advanced in the last twenty years in terms of audio and video? You have API's there to abstract these changes and to be fair, DirectX is a pretty damn efficient way of doing things. It's unlikely that you could learn the hardware of a modern GPU these days well enough to improve over what is already available in a reasonable timeframe. To be clear, even mid range GPUs are more complex then every chip on any Amiga ever created in their totality.

Hitting the metal can be done and product enhanced.  I still use same I/O ports and memory address of A000:0000 for VGA access on ISA-based VGA cards, VESA-based VGA cards, PCI-based VGA cards, and AGA-based VGA cards.  So they improved the video cards and yet maintained backward compatibility at hardware level.

LULWUT?! You're comparing 2d VESA to a modern capable 3D GPU? ROTFLMAO!!!

Hitting the metal, given the complexity of modern systems isn't just retarded, it is a complete waste of resources.

Come back when you get a clue.

I wasn't speaking from marketing point of view-- but one of ease of use and learning in a majority of games.

Err, Microsofts tools are among the best on any platform bar none. You want to learn how to produce modern games, you use their tools. It's actually one of the few things they really did get right.

[the_leander]

We're not talking about cost.  We're talking about what's better for using/programming-- is it better to modify a pixel color by doing a XOR [nnnn],EAX or by doing a call to an API?  Legacy mode should be a standard mode.  

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.

Even Comodore saw the writing on the wall, with the A500 you had a copy of the schematics of the custom chips (or at least parts of) in order to allow for easier hardware banging. When systems are as simple as the Amiga, that's great. But you upgrade to a newer, better system and all of a sudden you're having to write off huge sections of your software base each time you do so. Which is why even by 2.0 there was a major shift in 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.

Some applications are undoable via API but can be done if direct hardware access is allowed.

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

I said, "it's not as bad" meaning you can use it along with direct hardware access.  Since setting a mode is nonstandard, you can call it to set a graphics mode and then use direct I/O.  More later if needed.

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

The question would be though, why would you want to? Any monitor you use, be it CRT or LCD will only allow for a certain amount of resolutions. Seems to me you're doing things in a very cackhanded way.

[the_leander]

The trade off was that you had to take the hardware specs into account before creating software to run on it. Stability has nothing to do with it. Flawed code continues to be flawed no matter whether it manipulates hardware or APIs.

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.

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

[the_leander]

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

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.

The hardware of today is so different to the hardware of the XT that to maintain "hardware compatability" would be utterly pointless, in many cases the hardware functions have been completely replaced by other technologies.

No, the joystick argument is over-- Amiga won hands down;

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.

PCs have moved away from that since early 90s are going toward the inferior solely API-based method.

PC's are far too numerous in terms of variation to support anything else. Had the Amiga moved to more comodity type hardware in a similar vein to the Mac, the same would likely have had to have been done. C=, for all their faults saw the writing on the wall, which is why when you bought a shiny new A4000 or A1200, you didn't get a whole bunch of circuit diagrams to help the hardware bangers like you did with the A500, further, they improved APIs based on feedback from programmers. They pushed developers to develop for the OS, not the hardware.

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

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.

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

Creativity is limited by the choices you have.

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

API and hardware level compatibility opens up a lot more possibilities.

Only if everything else is using the exact same setup as your own or you are working only for yourself!! To anyone else with different hardware, the only thing you've opened is likely to be a pack of headache tablets when the poor sap who has the misfortune of using your software finds out that it's been hardcoded for something he doesn't own instead of using the OS's APIs

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

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

Your claim (and that's all it is, as you provided no evidence to support your suposition) that it's better is meaningless. Untill you can provide real world data to show that APIs slow down feedback to such an extent that there is a noticeable lag between what you do and what happens on screen AND prove that it's not down to sloppy game engine coding, it will remain a baseless claim.

(and that's ignoring the whole issue of having to provide custom support for hundreds, if not thousands different controllers and many different interfaces etc etc)

 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.

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.

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.

[the_leander]

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

And as hardware evolves and things are simply dropped as they become obsolete, you end up right right where we are now in terms of hardware, only, you'll have to wait a lot longer to get here because of that added requirement, not to mention the veritable rats nest of kludges you'll have to add to the mix to get there.

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.

You are failing (actually, I suspect wilfully ignoring) the fact that to access even a large subset of the full capability of for instance a modern GPU in a reasonable timeframe the only way to do it is with an API. Also, I/O has improved a great deal in computing. The only remaining bottleneck is optical and hard drives, with the latter being slowly overtaken by SSD's that are an order of magnitude faster.

[the_leander]

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.

You have not yet proven that the Amigas joystick port is capable of actually being able to support anything like that rate.

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

That is not the same though as what you said originally, is it? In fact it's nothing like what you said originally.

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

You've said this time and time again. Prove it.

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

Excuse me? I've said from the beginning that banging the hardware on the modern desktop PC is an exersise in stupidity for many of the reasons given here already. You have completely dismissed them, instead prefering to go on about a dream world where every componant on a PC, regardless of what it actually does, retains some form of hardware legacy compatability. Do not try to turn this around because you've been called on your BS.

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

No it isn't. Unless you're trying to play some kind of pathetic game of semantics. "Commonly used desktop programs" is quite clear in of itself. But if you want to be a pedant, fine.

Show proof that there is not some commonly (by commonly, I mean greater than 50% of the computer using population use it on a regular basis) used desktop (by which I mean a desktop computer still within its design specifications lifetime IE within 6 years of this post) application.

Clear enough now?

Only if the real-time effect you are trying to do is supported by an API call.

That is a given. I note that you still managed to dodge the point again however.

  But as I stated before, you can manipulate I/O ports in so many ways and not all of them will have APi equivalents.

Yes, and how many of those ways can be done without it having a detrimental effect on other processes. Further how can you maintain compatability across the huge differences between computers?

[the_leander]

In general they do fix bugs as versions keep going up and up,

Specifically addressing DirectX, you'll have DX8, for instance. then you'll have bugfixes so that when you run something like dxdiag, you'll end with DX8.000000005 or something. A change from 8 to 9 specifically means a jump in capabilities, for instance shader support.

 

but in one sense you can consider adding more functions a type of flaw as well since that means original was missing things that are now present.

Things being done now probably weren't even a hardware developers wet dream 20 or more years ago! Technology advances, capabilities improve. To try to write it off as flawed because the guy who helped design the XT didn't forsee oneday that graphics processors would become fully programable and that hard drives would be in the Terabyte range is beyond retarded!

You're seriously pulling at straws now. The wise thing to do would be either to retire or concede.

[the_leander]

>You've said this time and time again. Prove it.

I prove it for myself.  You have to go repeat the experiment and prove it for yourself.  Why haven't you replied to my posts where you were refuted rather than wait a while and restate the same argument again.

The data was torn to shreds, all you've recorded is signal noise. You have yet to show that the computer can actually react to anything like the numbers you suggest.

>Excuse me? I've said from the beginning that banging the hardware on the modern desktop PC is an exersise in stupidity for many of the reasons given here already.

Because the point is not banging the hardware on modern existing systems where one system's hardware differs from another.  Point is, IF HARDWARE WAS BACKWARD COMPATIBLE, it's better to allow for API access as well as going direct to hardware.  

Ahh, back to your make belief world. Sorry, this is the real world, you've had it explained why your make belief world doesn't work at least a dozen times now.

>...hardware legacy compatability. Do not try to turn this around because you've been called on your BS.

Your misunderstanding is NOT my problem.  The only part of modern hardware that you can do direct access via hardware is the legacy compatible ports and memory map areas.  That's a good thing.  Your the one who is trying to cheat by trying to misconstrue clear cut things.

Cheat nothing. I understand fully what you're saying, what you're saying is demonstratably false at every turn you take in order to justify your position.

>No it isn't. Unless you're trying to play some kind of pathetic game of semantics. "Commonly used desktop programs" is quite clear in of itself. But if you want to be a pedant, fine.

I don't care if you call them "common" or not.  They are USEFUL programs that require going directly to the hardware.

I C WUT U DID THAR!

Dodging the question again eh? Guess that proves that you've no answer.

 And there are thousands of such programs out there that require precise control of hardware and can't rely on vague, inexact API calls.

Yup, and the vast, vast majority of them are found in embedded situations where the hardware would be considered limited even by Spectrum users of the 1980's. You have yet to show (outside of your fairy land) how this would be in any way beneficial to the common desktop user, yet there have been plenty of examples of where it isn't by other commontators.

>That is a given. I note that you still managed to dodge the point again however.

You keep missing the simplest of points-- the joystick is faster to read on Amiga.  How can you possible understand something like real-time events.

You have not proved that the amiga will actually respond at anything like that sort of speed yet.

>Yes, and how many of those ways can be done without it having a detrimental effect on other processes. Further how can you maintain compatability across the huge differences between computers?

That's not the point.

That is precisely the point, it's the point that every other person on this board has been trying (and failing) to get through to you! Your response to the explanation of why your demands for full and complete hardware access has been to create a wonderful makebelief fairy land where hardware doesn't change even a fraction as radically as it has over the past 20 years!

You only go directly to hardware if it's backward compatible and you know it will work the same on other systems.

And since you can't do that, even between different models of the Amiga (which is again why C= stopped providing hardware diagrams of the chips in question and encouraged developers to use API's instead) the supposed performance increase in immediately offset by the fact that your code will have to be modified or at least take into account a great many variables in order to actually be useful to the rest of the world. The time it takes to do that as well as take advantage of the hardwares "full" capability is so great that in the mean time the hardware has moved on and you can do all that and more via an API in the same timeframe.