PC still playing Amiga catchup

[bloodline]

the only reason this is there now is for a generic driver in the bios to display bootup messages. and windows to load a generic driver on initial bootup. this is not backwards compatibility just a basic commandset.

as for processors the same thing goes as vid cards. there is just enough functionality for bootup processes. this coding has to be standardized to get the system going due to the small size of the bios.

nearly all soundcards use the soundblaster 16(compatible) commands also for a generic driver.  however to get the most out of it you need the driver for the card you are using. all they did was create a subset on the chip for the most basic functionality. so no there is no backward compatibility just SB16 compatibility.

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

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

[jkirk]

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

true true

[Daedalus]

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.

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

[Hammer]

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

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

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.

A boat anchor.

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.

These legacy modes have no bearing on vendor specfic NVIDIA CUDA’s (Geforce 8 and above) and AMD CAL’s (Radeon HD) capabilities.

Notice X86's performance improvements while keeping legacy compatibility vs GPU's performance improvements. To maximise performance, GPUs usually take a clean design approach i.e. applying the latest micro-architecture paradigm on a given transistor count.  

Note that modern X86 translates(amounts to hardware accelerated emulator) CISC instructions to RISCy instruction and hides their expanded micro-architecture registers(i.e. register renaming hardware).

Let's use Geforce 8 micro-architecture as an example.

G80's processing elements has the following specs
[MT IU]
[SP][SP]
[SP][SP]
[SP][SP]
[SP][SP]
[Share memory]

8 scalar threads processors(SP)
32 GFLOPS peak at 1.35Ghz
8192 32bit registers (32K).
- 512KByte total register file space.
768 thread active threads in total.
16KByte on-chip memory
- shared amongst threads of a block
- supports thread communication

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.

>The Xbox 360 controller assumes lack of PC keyboard access. Note that, the mouse is one form of analogue control.

But mouse is usually read as digital data so it's more exact than reading an analog value which tends to fluctuate between various values.

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.

>In real world controls, analogue controls reigns supreme.

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

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.

[Hammer]

They speed up processors and functionality while maintaining compatibility;

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

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

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.

[bloodline]

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.

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

[Hammer]

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.

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.

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

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.

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

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

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

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

[Roondar]

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.

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.

[bloodline]

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.

You have no idea what the BIOS, either on the mainboard or the PCI cards is actually doing. For example, the VESA/VGA support on many modern GFX cards is provided by emulation... The EFI firmware on a very modern Computer, uses emulation to support older technologies...

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

[ElPolloDiabl]

Did I start this? Or were they already at each other throats? :griping:

Interesting read anyway.

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

[Daedalus]

Never heard of OpenCL

http://en.wikipedia.org/wiki/OpenCL