PC still playing Amiga catchup

[DamageX]

Banging the hardware was a cheat, it allowed you to do things on the underpowered machines of the '80s

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.

The trade off was stability

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.

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

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

[Marcb]

It's like comparing a sundial with an atomic clock, there is no comparison.
 

 
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

[paolone]

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'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,

[Hammer]

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.

PC graphics card comes with a BIOS(firmware).

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

Which makes “hitting the metal” unfeasible for userland programs. Also, refer to AMD/ATI Radeon's AtomBIOS.

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

In the real world, they are vendor specfic.

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

There’s a move towards motion controls.

[Hammer]

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.

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.

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.

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?  

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

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.

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

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.

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.

I still remember TSR SoundBlaster emulators.

[Roondar]

I still remember TSR SoundBlaster emulators.

And how they never worked quite right

[Hammer]

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

Refer to http://developer.nvidia.com/object/nvapi.html

"NVAPI is NVIDIA's core software development kit that allows direct access to NVIDIA GPUs and drivers on all windows platforms. NVAPI provides support for categories of operations that range beyond the scope of those found in familiar graphics APIs such as DirectX and OpenGL."

NVAPI = NVIDIA API. A vendor specfic APIs.

NVAPI was use to enable the current CUDA's Direct3D 10.1 supported features with FarCry2.



FarCry2 is an example of "The way its meant to be played" game.

LibCGM doesn't solve HDR FP + hardware AA problem with NVIDIA's RSX, nor it will solve pixel shader's stalls during texture operations.

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

Refer to TSR Soundblaster emulation.

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

There's nothing stopping you making a RING 0 program.

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.

For custom display modes, you either modify the INF(with NVIDIA's case) or

Part of NVIDIA's control panel (I use 185.70 beta)

or play with NVAPI.

[Hammer]

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,

Erm Pixel shader.

split-screening (to go back on topic for a moment), etc.  

3D surface.

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.

On CUDA processors, you have CUDA (ver 2.2), PhysX CUDA,  NVAPI, D3D (upto ver 10), OpenGL(upto ver 3), soon OpenCL (ver 1.0, currently in beta).

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

On the PC, you can have programs in  "kernel space" i.e. usefull for OS vendors, IHVs, hypervisor/virtual machine vendors, copyright protection/spyware/malware and virus writers.

[Hammer]

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.

Did you forget ATI's AtomBIOS?

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

You missed the lesson on X86 legacy tax when it comes to maximising the number of math units? The GPU takes the clean design approach nearly to the maximum.

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

Most modern 3D games needs variable controls.

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

I don't recall "centering issues/calibration issues" with Xbox 360 controlers. When driving a car (real world or virtual), the on-off nature of digital joysticks $ucks.

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

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