PC still playing Amiga catchup

[Hammer]

If hardware that is backward compatible uses same I/O ports, IRQs, DMA channels-- there no conflicts to be resolved.  When hardware vendors use their on I/O ports arbitrarily, their own IRQ channels, DMA channels then you have conflicts to resolve.  

The Wintel PC is an open platform.

>If you're having to reinvent the wheel and have every application bang the metal to the extent the app requires, you are in effect writing a (partial) driver or framework for your application to sit on...

Ahhm, did you miss the list I gave of advantages; you wouldn't rewrite the driver-- the OS would have the functionality built-in without needing drivers and application would be able to go directly to hardware where driver functionality is not supported or inefficient (like palette example).  

If the userland applications "hits-the-metal",  who will arbitrate the device's access?
I'm still waiting on Protracker vs OctaMED V4 vs Deluxe Music.

>The gains of hardware compatability, yes, lets add 10, 20, 30% extra silicon to every major I/O chip for stuff that's no longer used and long dead... Your entire argument is based on a fairytale world.

Sorry, you keep missing the point.  That's your speculation 10-30% extra silicon.  Even with some extra silicon, it's worth it given the benefits.  

As for the benefits, it depends on the market.

The legacy percentage for AMD K8 Winchester is larger than AMD K8 Sledge-Hammer i.e.
1.  K8 Sledge-Hammer, ~10 percent for legacy 105 million.
2.  K8 Winchester i.e, ~17 percent for legacy from 68.5 million.

[Hammer]

At the end of the day, stick your average PC user in front of:  Amiga OS, Linux, Windows, Mac.

Chances are they will figure out how to get on the Internet on the latter three, but stand no chance at all on the Amiga.  Mainly because they would be lucky if they even had a TCP/IP stack on it.

Come on, lets be realistic.  The point here is, that for the vast majority of user a PC does exactly what they need it to do.  This might mean it can't do a few things the Amiga could do, mainly because they are things your average user does not need to do.  The PC is a mainstream "do it all" machine, it makes no sense wasting time and money including backwards compatibility, except wheres its absolutely essential.  That is why they removed 16bit support from Windows some time back, it was no longer useful and just added bloat, bugs and more importantly a LOT of time wasted for the development team making sure it was still compatible with all the new stuff.

As we said before, why bother including support for the PC to be able to do stuff that 99.9% of the userbase do not need, and can easily be done on custom hardware more efficiently?  If the Amiga is better at this than a modern PC then excellent, but it also proves the point that it would make no sense using a PC to do it.  Why would you want to use a Ghz CPU eating around 150W of juice, to do something that a custom board could probably do in 10W?

My dual core 2.2 Ghz CPU eats around 35Watts.

[Hammer]

People have problems in this thread sticking to the example.  I can also switch entire frames by changing a video memory ptr on Amiga. But that isn't the point.

Still limited to Amiga's memory design and graphic's processor speed. You want to start a frame per second race? Let's see HAM8 vs ....

CUDA GPUs have extremely large instruction issue per cycle rate, extremely large registers (e.g. can go up to 512 KByte), super-scalar (dual issue per SP) pipelines, extremely large SMT, caches (both hardware and software managed), high speed memory (and designed specifically for graphics i.e. GDDRx types), Ghz range stream processors(SP), multiple ROPS,Triple digit (e.g. 400Mhz) Mhz dual RAMDACs and 'etc'.

The amount of “Instructions in flight” (both in parallel and sequential(in pipeline)) in CUDA GPU kills any classic Amiga IGP chipset.

Should I bring in ATI Xenos?

[Hammer]

Man, Karlos I cut you deep with that "Frankenstein" thing back there.  I really am sorry.  Ok. Look you have an "expanded" Amiga.  Better?



Actually I did read the guide for executive about a decade ago. From memeory, Executive offers more than one unix-like scheduler.  It offers several, some that have nothing to do with Unix. Which you can select and turn off without rebooting.  Can any other PC OS do this?

In any case nothing wrong with gaining inspiration from others.  Hell it worked for Microsoft.  And the scheduler in Linux was a subject of debate about 12-18 months as it was viewed as good server scheduler, but not that good for a desktop.  Hell an mp3 playing back could make GUI stutter.  Things may have improved, don't know, couldn't be bothered fartsing around with it anymore, but I play with linux from time to time.  Still you can't deny that multi-tasking on the Amiga rocks after all these years. even compared to the latest and greatest from MS.

What's better about the new schedulers?

There's AROS X86....

[Hammer]

As I just explained to someone above, the I/O on modern systems is NOT as fast as the processors (or even memory accesses).

Still faster than all Amiga hardware.

 Even if you use GPU, you still have to feed the parameters from host CPU to GPU using API calls.  

Complied shader programs are programs. CPU is fast enough to feed the GpGPU e.g. Fold@Home GPU2 client.

[Hammer]

Compatibility is a MAJOR thing to have.  CPUs weren't trying to keep up with GPUs as their target wasn't just pure math performance.  But they did maintain backward compatibility on hardware level.  

Erm, modern X86 CPUs includes micro-code translation engines i.e. on-chip firmware (look up tables) based decoders.

And I bet hardly anyone would upgrade to a new PC if it WASN'T backward compatible.  

Unlike the GPU, the CPU is the host for control code. The application of hit-the-metal vs abstraction are dependent on needs.

[Hammer]

It's useful until it becomes corrupt and renders the entire system unbootable. And of course, you have to deal with applications that write stuff to it and never remove it (bloating it) and spyware/viruses screwing with it.
.

I still recall Saddam Virus from mag cover CD on my classic Amiga 500.

 Continuously reading/writing same file means higher probability of failure of system than reading/writing different files.  I have seen several systems that wouldn't go into Windows because of registry corruptions.  I suppose you can get "lucky" if the back-up didn't get corrupted as well.  However, it would still affect start-up/shut-down times since you could corrupt the registry if you just turn off the machine and restoring it would increase start-up time.

This an OS issue. Run AROS X86.

[Hammer]

It depends on the I/O port.  Also different motherboards I have timed give different results for same I/O ports.  If you went directly to hardware on PC in standard VGA mode, you can set palette indices faster but the point was making an API do it since nowadays video modes are nonstandard assuming you even have a paletted mode.  CPU is fast enough to feed the GPU but what is the overhead as compared to doing a few MOVE.W on Amiga.

As the RSX pixel shader example shows, you have factor in instruction pairing i.e. parallelism.

[Hammer]

I have read it will-- just the simple palette index problem should tell you how inefficient it is to go through APIs vs. doing it via hardware.  

Not everything needs to be retargetted.  It's better to have both API and hardware level compatibility so if you want to retarget go through the API.  Why force people to accept retargetability even if they don't need it and force them to use less efficient means.

 With GPUs, parallelism and maximum math unit counts are the priories.

There's not just sacrifice in speed though.  You also have restrictions on what API allows you to do with the hardware.

The thin libCGM didn't solve RSX's design flaw.

 Many Amiga games wouldn't be possible if they only relied on API calls.

Amiga's API is primitive.

[Hammer]

That's the chaotic scenario now because they are BASING STANDARD on APIs.  Preivously, all manufacturers were complying with hardware standards-- look at PS/2 keyboards and ports, look at parallel ports, look at VGA/EGA/CGA cards, look at serial ports, look at floppy drive interfaces at 3F0..3f7h, etc.  By the way, even now there are devices that are based on hardware standards based on ACPI specification.  So whoever thinks it's not doable nowadays is just speculating.

Ahem, you did forget firmware’s role?

An ACPI system consists of a series of ten tables. These ten tables define which devices are present on the system and what their capabilities are as they relate to configuration and power management. These tables are built by the system BIOS at boot. When the system boots, it looks for specific entries contained in two of these tables (the Fixed ACPI Description table [FACP] and the Root System Description table [RSDT]) to determine if the system is ACPI compliant. This information is extracted from these tables in the form of an OEM ID, OEM TABLE ID, OEM REVISION, and CREATOR REVISION. If these tables are not present or the information contained in the descriptors above is invalid, the system is assumed to be non-ACPI and the legacy hardware abstraction layer (HAL) is installed.

For Windows, google "ACPI HAL"(hardware abstraction layer).

>this is true however as these new features come into existance the api is updated with functions that allow you to use the features that programmers need and want implemented. as such those games are still possible you just need to be creative with what you have.

You are more restricted with APIs;

It fosters rapid GPU hardware development.

 APIs are slower and inefficient.  APIs are more inexact.

Depends on APIs.

[Hammer]

It depends on what instructions you try to do in parallel.  If you do an IN AL,DX then TEST AL,128 obviously, you processor has to finish the IN instruction however long it takes.  I was giving case where using AMIGA direct access outdoes PC going through API since API is more restricted than going directly to PC hardware.

One could develop a better mouse driver. There's nothing stopping you developing a better mouse driver.

Logitech's SetPoint software allows a user to set polling rates as high as 1000Hz.
Another 1000Hz poll enabled gaming mouse is Razer's DeathAdder/Mamba.

One the reasons in purchasing a gaming PC mouse is it's poll rates.

USB Mouserate Switcher 1.1. enable poll rates of +3000hz.

[Hammer]

Once you accept that Amiga can swap palette indices faster than API-based modern system, we can looks at other examples where Amiga wins.  I am not contesting you have more graphics horsepower overall in modern graphics cards but in some cases Amiga still wins when you look at time spent by CPU especially if you are going through APIs.

The APIs doesn’t hinder the compute performance. Modern desktop host CPUs are sufficiently fast enough to feed the GPU. Remember, modern GPUs are superscalar, pipelined, higly paralleled and highly threaded architecture.

With current CUDA processor, you can have 768 active stream threads per 8 SP cluster i.e. the front-end is larger than the available stream units. My Geforce 9500M GS GPU (32 SPs) can have 3072 active threads.  

 Frame per second race is also as easy as setting video memory pointers on Amiga.  I believe we had some of this discussion before-- regarding playing .anim files and decompressing them on-the-fly using a double-buffered approach.  Time to switch between frames is just for flipping pointers.

CUDA processor has multiple texture address units. You did not address "frame per second" rate. Comparing Amiga's play back capabilities against ATI's UVD and NVIDIA's PureVideo is laughable.

[Hammer]

I'm beginning to think that amigaksi is actually not debating the actual time needed in some of his examples, but purely how many processor cycles it takes to achieve them. I could be wrong here, but if he does it would explain some of his objections.

He basically implies, that today’s engineers are dumb and stupid. He didn't factor in the overall performance of the system. Refer to my posted PS3 RSX shader example in relation to instruction pairing.

Needless to say, this is not a very good way to look at things. Almost everything in modern computers (and that includes setting up the GPU) is IO limited and not processor limited.
 

In terms of computation intensity, Geforce 9400 IGP kills Core 2 Quad using the same memory bus.

[Hammer]

Hi,

@Hammer,

Would you care to repharase that, your CPU may use 35 watts, but what size is your power supply, your video card, your audio chips or card, your hard drive, your CD-ROM player (or DVD) your memory, your USB ports, and your fancy little cpu cooler.

add them all up

and your computer is probably equal to one heck of a room heater

It's a Q1 2008 "gaming" 15.4"  laptop. According RMclock, the entire system consumes around 25 watts to 55 watts.

[Hammer]

Cop out.  That's what you always wind up with when you have no arguments left-- who cares?  Well, who cares about 2Ghz or 7Mhz?   To me (and millions of others) having IN AL,DX is more significant than processor speed.

>2. And you're twisting YOURS. You started this silly argument saying that Amiga game port can poll joysticks 1000 times every second (be aware you haven't yet proved it), thus making the (classic) Amiga platform "more suitable for games".

It can do more than 1Khz.  You are twisting things again.  All I said was some games can use the 1Khz.  It's more accurate.  And AMIGA IS FASTER in reading the joysticks regardless of the sampling rate of the joystick.

>"ANY USB port can handle 1 KHz as well, even more", and this ends up the argument. YOU decided to complicate it introducing "hardware banging" and assembly lines. And here started bullcrap.

You don't even follow the flow of arguments.  API vs. direct hardware is a separate point (more generic).  Joystick polling is slower on PC whether you use API or direct hardware.  Stop misquoting me.

>3. and 4. The installed park has nothing to do with this discussion. There are plenty of 486 and Pentium - Pentium III machines out there, but they aren't anymore reliable for gaming.

Sorry, but you said there NO gameports out there.  I don't see how you equate # of gameports with 486/Pentium/P3s.  

>That's evolution, a word that the Amiga community didn't know until it killed us all.

Sorry, Amiga also involved quite a bit and with hardware level compatibility.  Your speculation that it killed us all is absurd.  Why not state something logical or something people can prove.  Anyone can state his opinion.  The point is PC still hasn't equalled or surpassed PCs in all respects not "who cares".

>5. Ok, here you have touched the sum of ridiculous. I can start ignoring you.

That's what you done anyway thus far in this thread.

If game controller in question is a usb device and running Windows XP SP2, "usbport.sys" can be hacked(via Hex edit) to support higher poll rate.

For 2006 Linux, the mainline kernel was patched to allow for the USB polling rate to be changed. There are two ways to do this. First a parameter can be added to the kernel commandline:
-usbhid.mousepoll=[polling interval] (e.g. for polling interval, 250, 500, or 1000 would be entered.)

The second method is when the driver is built as a module in which case the following command would go into either /etc/modprobe.conf or /etc/modules.conf depending on the distribution:
- options usbhid mousepoll=[polling interval]

[Hammer]

How is it clearly not true?

PCs have been playing catch-up ever since Amiga was introduced.  They have had higher processor speeds/computational power even before Amiga was introduced.  They are still playing catch-up in some areas.  Their API method of approach is making it worse for them.

APIs enables the PC to quickly adapt and assimilate technologies.