PC still playing Amiga catchup

[amigaksi]

Yeah, I understand that, but what about using 3 different weapons for example? Or a driving game with more than just accelerate/brake? Or even Street Fighter? High punch, middle punch, low punch. An awful pain if you have to combine a button with a joystick movement to choose a different attack. And it rules out attacks while jumping, crouching etc. Yes, 10 buttons is making things overly complicated, but so is limiting yourself to 3 or less. Of course start/pause/reset can be moved away, but sure you don't need more than that anyway - game select screens shouldn't need more than direction and one button.

I guess example of data compression is appropriate here.  If you take majority of games, and take down how many buttons are a must to play, you will end up with a series of number with some maximum and minimum (0 for pacman, 2 for defender, 176 for Flight simulator, etc.).  Now rather than carry lg(MaxButtons-1) bits, you simply use the lg(majority of cases for buttons-1) and have special codes/cases for those exceptions.  So for example, Atari 800 games generally only need one button so in case of Defender they used the Space bar for Smart Bomb and some other key for hyperspace.  That makes it simple for the user to figure out and not need a manual everytime he puts some game in.  Nowadays, you switch games and you have to remember which button did what in addition to making learning curve bigger for each game and less responsive due to bigger choice of options for buttons.

[amigaksi]

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

I already answered this.  VGA went through an evolution where it kept backward compatibility at the hardware level.

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

Might does not make right.  So big companies are following some API standard that does not mean it's the most efficient method.

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

Take any software using those APIs, and I can write a more efficient software going directly to the hardware.

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

You just don't understand the point.

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

It's the same resources you use as with API.

>Come back when you get a clue.

You have no clue that it's better to have hardware level compatibility as well as APIs.

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

I prefer the simpler digital joysticks over analog joysticks w/various interfaces and 10+ buttons.  As I have experienced and seen many others, people have a harder time dealing with the complexities of extra buttons and analogicity for every game.  Wasn't it Microsoft that implemented a GUI and mouse to make things SIMPLER.  How about a mouse with 10+ buttons.  Actually, I saw one of these and it's terrible trying to even move the mouse around without pressing some button accidently and having something weird happen.

[amigaksi]

if you find one method inefficient in the current system you can change the system to be more efficient then create a driver to interface with the api. if we maintained hardware compatibility you would have to either create both chips on one die or use the existing inefficient method. both are bad since putting both on one chip would be expensive. and using the inefficient method will prevent optimization to improve performance.

They speed up processors and functionality while maintaining compatibility; they sped up VGA and functionality while maintaining compatibility; Creative Labs made all those Sound Blaster cards while maintaining backward compatibility.

[amigaksi]

More often than not, this backward compatibly that the hardware offers, is actually just an emulation... which links nicely to amigaski's other "ignorance thread"...

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.

[amigaksi]

...
simply you are mistaking backward compatibility to a basic codeset for initial bootup.
...

Take an easy example of trying to use more than 256K of VGA memory.  Each VGA card implemented its own I/O Window register like $3D4 or $3CE.  There are hundreds of different I/O Window registers some using 4K banks some 64K banks and then there are various methods of using the linear memory mode at various memory mapped locations.  Now all this could be a single Window register and single linear memory area if things were standard like they were for the basic VGA card (A000:0000, $3C0..$3DF, etc.).

[amigaksi]

I though I'd find a nice little article for you that details the problem Apple have faced:

"
Managing the platform

Another aspect to keeping technical specifications out of the limelight is that Apple is careful to expose access to hardware components in a manageable, sustainable manner. If developers are allowed to write "to the hardware," the result is a broken platform where the vendor can't move forward without breaking the apps.

Apple experienced this problem in the clever hacks to the classic Mac OS which resulted in destabilizing the system, a problem that got progressively worse after the company sanctioned the system patches in System 7 under the name Extensions. In Mac OS X, reference releases have been plagued by Input Manager hacks that similarly caused some serious compatibility problems.

That has led Apple down the road of a tightly managed iPhone platform where the execution of third party software requires code signatures and sandboxing, and where access to hardware has been roped off until the company could perfect abstracted public access to features in a way that can accommodate new underlying changes as future models are released.

Users shouldn't need to know how much RAM is available to the operating system of a mobile device, or how fast its primary CPU core is clocked at; what they should care about is how usable the device is and what it allows them to do. That's the message Apple is working to control."

That's why PCs may have suffered recently-- they were following Apple's policy of ineffiiciency.  I am not speaking of maintaining some undocumented hacks relying on processor timing to be backward compatible especially since it's now a given that processor speeds will change.   However, those examples should not be reason to remove direct hardware access completely and not to consider it significant that hardware be standardized at port level (not API level).

[amigaksi]

Userland programmers should not worry about the implementation i.e. plumbing work.

...

As I said, there's nothing wrong with having APIs for user mode and still having standardized hardware on I/O port/memory-map level so at least kernel mode software can be written to take advantage in best possible way.

>A boat anchor.

It doesn't have to be just the basic VGA-- entire SVGA/XGA/SXGA could have been standardized at hardware level; but it wasn't so you have to live with the method of accessing them through APIs.

>...To maximise performance, GPUs usually take a clean design approach i.e. applying the latest micro-architecture paradigm on a given transistor count.  

Because they are already assuming now that they only have to write for APIs.  Also, it's cheaper for them to start fresh.  But it's better to have both.  If some video card company had maintained hardware standards at I/O level throughout their history, it would be pretty popular and useful since it would work with all OSes (DOS, Windows 3.x, XP, Vista, Linux, etc.) and would allow for direct programming.  I know ATI even has like 10 different I/O port locations on various cards that do the same thing.

>1. Geforce 8600 GT/8700M GT/9500M GS/9600M/9650M GT has four of these processing elements i.e. 32 SPs with 32768 32bit registers.

>2. Geforce 9600 GSO has eight of these processing elements i.e. 96 SPs with 98304 registers i.e. these values are stored next to actual execution cores.

>Notice the register count differences between examples 1 and 2.

Yeah, but given they are only accessed via APIs, they could change the GPU and register sets.  However, if they had known that many applications are writing directly to the hardware, they would have to maintain APIs and be backward compatible from hardware perspective.  

>I was referring to variable of movement compared to on-off nature of a digital joystick. >Anyway, my mouse has an optical scanner i.e. it has a DPI resolution and it doesn't have a mouse ball. It has A-to-D conversion.

Most games on PCs use analog joysticks but they could just as well have been written with digital joysticks.  Yeah, a few games need the analogicity, but why should most of the games suffer because of it.

>I wasn't referring to marketing point of view i.e. refer to real world cars. Xbox 360's RS's replicates (player's POV)'s head movement changes.

I have played Pole Position on Atari 800 and Atari 5200 and it works great with digital joysticks and analog sticks although latter has centering issues/calibration issues.

[amigaksi]

Intel and AMD didn't give you(and anyone else) access to X86’s RISCy micro-architecture instruction set.


Standards breaks when vendors can't copy/clone another vendor’s specific features e.g. NVIDIA CUDA vs AMD CAL. DirectX11's compute shader and OpenCL attempts to standardise GpGPU.

Never heard of OpenCL-- but OpenGL is also an API standard.  I think the problem with VGA cards occurred when no hardware standard was set for going past it's basic 640*480*16/320*200*256.  People started writing their own methods of doing 640*480*65536, 1024*768*16777216, etc.  Even at that point, it wasn't that bad since you could set the mode via VESA BIOS and still go directly to A000:0000 and use the I/O ports for palettes.  But then it got worse and worse as more and more features got added by various vendors.

[amigaksi]

From GPU's POV, maintaining a CPU style legacy may not be efficient for the transistor budget. For example, GPU's allocates their transistor budgets to math units.

Also, I don't think NVIDIA would share thier GPU ISAs with anyone else.
...

Actually, even VGA standard bandwidth and chipsets varied but they used the same I/O ports and memory map areas.  I have timed various VGA graphics cards using standard graphics modes (these are older PCI cards) and the Matrox had one of the highest bandwidths (> 2X over ATI), but they were accessed the same way.

>Close sourced NVIDIA and ATI driver packages include JIT re-complier engine. You are welcome to write Radeon drivers that would beat the offical Radeon drivers.

Even amongst Radeon cards, they don't use the same I/O ports.  

>AMD and NVIDIA offers "close-to-metal" with thier GPUs, but they are vendor specfic. With PS3, NVIDIA provides LibCGM thin-layer.

It's "thin-layer" may be worth it if it's not vendor specific.

>Pre-programmed macros on MS gaming mouse while playing with Xbox 360 players in Gears Of War(via Xbox Live) is an advantage.

>I use an 8 button gaming mouse e.g. able to change sensitivity on-the-fly (two buttons), change weapons, use alternate weapons fire, use health packs and 'etc'.

I still find the simple one/two button-based games fun and easy.  I played this 3D game on playstation where you had to pick up objects but the interface is highly complicated and you miss the object many times and when you are under attack, you have to first set position then move or press one of the buttons to attack back.  By the time you figure it all out, game's over.

[amigaksi]

they are standard. standard through the api. this way you create a program and the os retains control over the hardware. after all it is an Operating System. not window dressing for direct hardware access.

i am not going to say that the api system couldn't be implemented better. what i am saying is this method is fine and is not a problem.

OS does retain control of the hardware but it application can also use it directly-- the way it's set up in Amiga.  APIs will always be worse than direct control from efficiency point of view and knowing exactly what is happening in the system.

[amigaksi]

I agree that too many buttons are unnecessary and make things too difficult to remember (PlayStation controllers are my example here), but I stand by too few also being an issue. Why would you not need a manual to look up which keys on the keyboard are for the hyperspace and smart bomb? There are something like 60 possibilities there instead of the 6 you'd have with e.g. a CD32 controller. It's something I never liked as I tended to play games holding the joystick base with one hand - look at the ZipStik and tell me how you use a keyboard without losing either the fire button or directional control...

It's any key to hyperspace and spacebar for smart bomb.  You may need the manual, but the most useful function is the one button to fire and it's to figure out what it does without any manual.  Hyperspace is hardly used to begin with so no sense in confusing things by putting 10+ buttons on the controller when only one or two matter most of the time.

[amigaksi]

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.

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.

[amigaksi]

Some important points here:



The BIOS is a software API... the very thing you are arguing against... in fact it was the fact that the BIOS abstracted the hardware that lead to the popularity of CP/M (the forerunner of MSDOS).

...

I said "it's not as bad" since you can still take over the hardware; mode switching is not used that often as say changing palettes, modifying a pixel, split-screening (to go back on topic for a moment), etc.  and you wouldn't have to be playing guessing games as to what the API is doing.  Just set the VESA mode once and then use the I/O ports and directly write to VGA.  If you don't need low-level accesses then use the API.

>And this is why we use APIs!!! Ok, so you have now successfully argued against yourself, maybe you understand

My argument has been the same-- it's better to have both.

[amigaksi]

On the contrary, when Creative had to go from ISA sound cards to PCI ones they had a HELLOVA time making them backwards compatible.  There is also an endless list of "soundblaster emulation" cards which never worked right as because they were "hardware compatible" they couldnt fix it.  However if you use a higher level API and software drivers you can easily patch any compatibility problems later.
...

"On the contrary" to what?  Did you like misread or skip some posts?  Sound cards are NOT backward compatible.  I stated an example where some Sound Blaster cards are backward compatible at the hardware level and they can be accessed directly with more efficiency.  I was stating that if they were all like that, that is better.  API restricts your access to hardware for what the function performs and it's inefficient.

>My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

That's your speculation.  Some Soundblaster audio cards ISA and PCI versions of them are hardware compatible.  I can set use I/O locations 220h..22Fh and DMA/IRQs directly.  It's not being done in software as I explained before.

>The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

No it doesn't break the argument, since you never understood the argument according to what you wrote.  APIs restricts your access to the hardware and is less efficient than directly writing to hardware registers if there is backward hardware compatibility.

>Now when talking graphics cards things get even worse as they are so much more complicated.  Do you REALLY think its cost effective to include legacy modes in every single new card you release?  

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.  Some applications are undoable via API but can be done if direct hardware access is allowed.

>As for VESA, as I understand it that is still an API but it was mostly supported via the graphics card BIOS which is the only real difference between hardware and software support anyway.  

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.

[amigaksi]

Continuation of my reply from yesterday...

...That said, DOS games would always come with software VESA as many graphics cards lacked support, or supported the wrong specification.  So the whole VESA introduction could just have easily been done with software drivers anyway except as people were using DOS (Win95 was not yet a large enough install base to support exclusively) it was easier to keep it in the graphics card BIOS.  The instant enough people were using Win95 over pure DOS though they made the jump, as it was so much easier to support.  If keeping things in hardware was as good as you say, why was it so hard to get DOS games working properly compared to once they made the jump to Windows?
...

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.

>And blimey, how large do you think the graphics card BIOS would need to be in order to have backwards compatibility for ALL GPU functions?  How often would it need to be patched to fix bugs?  Quite frankly, its just not practical and you damn well know it.  Using VESA as an argument just seems plain silly, given the above that early VESA was supported via software drivers - very much like how modern drivers support Direct3D today.

You missed the point there.  VESA is an API as well; it's not as good as directly being able to set a video mode through direct i/o.

>Nobody is saying that 100% accurate backwards compatibility would be a bad thing.  I'm sure there are a few benefits from a developers point of view (for a few very rare unusual applications), but you have to live in reality.  

Not "few".  If I/O ports and video memory were standard in all video cards for all their functionality, you will have more efficient applications and less restricted games/applications.

>There is no PC standard which says your sound/graphics card must talk in this language (apart from VESA and old VGA standards), with these memory addresses, etc.  There is also the little thing of evolution to think of.  If you write a strict standard you are stuck with it, forever.  However with an API if you find more efficient ways of doing stuff at the hardware level, the only restriction is rewriting the software driver.  This is not a whole lot different to how it works at the hardware level except the risk/cost of doing it hardware level is insane (hard to fix once in production, huge BIOS to handle the translation).  And no, directly pushing bits around the GPU directly is simply insanity.  It was fine for Amiga because the chipset was relatively simple, but a modern graphics card GPU is going to be many times more complex than a whole Amiga so claiming that you should have the same hardware access is just plain silly.

I don't think complexity makes a difference.  VGA standard is also pretty complex since it also incorporates EGA/CGA mode compatibility as well.  

>Likewise when two competing companies make a graphics card with new functions, how on earth do you propose they would make them compatible with each other without an API?  You can't develop the standard that far in advance of the actual hardware development because you are keeping your cards close to your chest to beat the competition to market with the latest features.

How did they make VGA standard cards with same I/O ports and video memory?  The same way for newer functions.  The act of settling for API compatibility is the problem.

>Again, of course a hardware level API like VESA is handy if you want to bang the hardware more directly and save yourself some CPU cycles.  However nobody outside of an insane asylum is going to want that level of control.  Nobody actually NEEDS that level of control.

That's your subjective opinion.  Most Amiga OCS games go directly to hardware and would be worse if they did not.  Most early PC games went directly to CGA/EGA/VGA.

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