PC still playing Amiga catchup

[stefcep2]

If by that time scale you mean PC's currently on sale, then I'd only be able to agree with the caveat that the observation it applies to some systems. You can buy/build PCs in the 500 quid range that will manage 1080p playback perfectly well. You don't even need a high end graphics card, my work Radeon X300 with MPlayer under fedora manages it, the principal limitation there is the fact it's a single core P4 (which is pretty much yesterdays kit now).

i'm talking PC's that were on sale barely 2 years ago.  On my Win XP Athlon 4800+ using integrated graphics, 1080i Full HDTV occassionally skips a frame.  

What else can you do when you play 1080p on the pentium 4?

[stefcep2]

rotfl; what sort of Internet can a fresh install AOS3.1 reach anyway? Dodging malware because your computer is so ancient isn't a benefit for your system. Otherwise clearly the C64 is much better then an Amiga system because it can't get any malware at all.

"fresh" as in without security software

[stefcep2]

It's not that it isn't possible, it's that doing so makes for a retarded design.

here's some facts:  Linux can and does offer the user a choice of schedulers. A different scheduler does change the behaviour of the OS significantly.  The fact that more than one scheduler exists on Linux suggests the default scheduler's performance doesn't perform as well in all usage scenarios, otherwise there would be no need for a different scheduler.  So allowing the user to choose a different scheduler is not such a retarded idea in the eyes of Linux developers themselves.  Now here's the rub: the scheduler is built into the kernel: and its one scheduler per kernel.  You wanna change your scheduler, then you use a different kernel.  You don't simply switch of the old scheduler, and select the new one from a list of schedulers that you'd like.  like you do with amiga and executive.

[koaftder]

here's some facts:  Linux can and does offer the user a choice of schedulers. A different scheduler does change the behaviour of the OS significantly.  The fact that more than one scheduler exists on Linux suggests the default scheduler's performance doesn't perform as well in all usage scenarios, otherwise there would be no need for a different scheduler.  So allowing the user to choose a different scheduler is not such a retarded idea in the eyes of Linux developers themselves.  Now here's the rub: the scheduler is built into the kernel: and its one scheduler per kernel.  You wanna change your scheduler, then you use a different kernel.  You don't simply switch of the old scheduler, and select the new one from a list of schedulers that you'd like.  like you do with amiga and executive.

You missed the point of my reply. You argued that pc operating systems can't change the scheduler and have it valid after a reboot. I said that makes for a retarded design. You can never be sure of what's hanging around in memory after a reset. That is all.

[stefcep2]

You missed the point of my reply. You argued that pc operating systems can't change the scheduler and have it valid after a reboot. I said that makes for a retarded design. You can never be sure of what's hanging around in memory after a reset. That is all.

I argued that the amiga can change the scheduler without a reboot,  but you can switch the Amiga on and off if you like to clear what's in memory, its not as if it takes any longer than a soft reset...wait a minute..thats anther argument isn't it...  Actually i don't think windows can change the scheduler at all, reboot or not.  And Linux needs a different kernel altogether to boot from to change the scheduler.  And who knows what other changes you didn't bargain for might be in that kernel..

[the_leander]

i was more referring to the endless updates, some of which will result in a non-bootable system (Linux especially)

Only time I've ever had a linux update crap out an install was once when moving from Ubuntu 5.x to 6.x. But as with windows, it's better to do a clean install of an OS rather then an update. Does it happen? Sure. Happens to windows too, only when it happens there, it makes the news.

Here's one possibility:  I understand that having drivers for a lot of hardware allows things like plug and play to work.  But it also means you have information on your system about hardware that will never be used. So why not make hardware with built in flash that holds the drivers for that hardware only.  The software in flash identifies the hardware to the OS, the OS then installs the driver off the flash.  Information only relevant to actual hardware that is installed is then stored by the OS.

Which in turn would mean that either all OS's adopt compatability for these drivers, or more likely, windows alone gets drivers. The problem is that at some point the OS has to deal with all these different drivers regardless if they're supplied by CD or on onboard flash, now if you've only got to deal with a tiny handful then a loose collection of files as in the Amiga will almost certainly suffice. But at some point this will become very difficult to manage and maintain. The logical way to do with sorting it all out is a database. Given that many other OS's take this approach, perhaps the registry, far from being a bad idea, may simply have earned a bad reputation from the bad old days of windows 9x...

Strange.  Its also strange that you installed Idefix with OS 3.5 to get your IDE CDROM to work.

Nono. To get to the point where I could install 3.5/3.9 I had to get idefix to do it's thing, I then had to go back and edit the script so that it worked reliably. This is before I installed 3.5.

Mind you this was all years and years ago now.

actually office and web are pretty much the only thing that the PC will dominate in the future: console games outsell PC games, and despite Mediacentre/MythTV/Viiv the PC doesn't dominate digital TV/DVD/Bluray/PVR's in the lounge room, where consumer appliances rule.

Possibly. Tbh I think the PC as we know it will continue for a long time to come. It as a platform is far too versatile. The thing that make it what it is today will keep it going - it's flexability. It's not the best gaming system by virtue of its complexity, its not the best anything, but it does more things well enough that it is useful in its own right. What you will see however is more very capable pieces of hardware that are purpose built to do a small subset of these functions in a more appliance like fashion. I think the EeePC and Ebox are merely a taste of that.

[stefcep2]

Only time I've ever had a linux update crap out an install was once when moving from Ubuntu 5.x to 6.x.

I've ended up with a non-booting PCLOS just by installing a SNES emulator from the repo.  A dependency was updated, which KDE needed an update for, which was available but not installed by synaptic.

Which in turn would mean that either all OS's adopt compatability for these drivers, or more likely, windows alone gets drivers. The problem is that at some point the OS has to deal with all these different drivers regardless if they're supplied by CD or on onboard flash, now if you've only got to deal with a tiny handful then a loose collection of files as in the Amiga will almost certainly suffice. But at some point this will become very difficult to manage and maintain. The logical way to do with sorting it all out is a database. Given that many other OS's take this approach, perhaps the registry, far from being a bad idea, may simply have earned a bad reputation from the bad old days of windows 9x...

theres a logical leap here ( non-Windows support aside): why does my PC need to keep a database of thousands of hardware pieces that are not and will not be present on my machine, if each piece of hardware that i can buy comes with it own self installing drivers in flash ROM?

And if a hardware manufacturer wants to support alternative OS's whats stopping them from putting a driver on the same flash rom?  And what's stopping the alternative OS users from reading the Win driver in ROM and reverse engineering it, isn't that what they soemtimes do now anyway?

Nono. To get to the point where I could install 3.5/3.9 I had to get idefix to do it's thing, I then had to go back and edit the script so that it worked reliably. This is before I installed 3.5.

Mind you this was all years and years ago now.

the atapi system was a hack to let cheap IDE interfaces-which were ubiquitous on the PC to recognise IDE-equivalents of peripheral which were available for scsi, because PC's didn't come with scsi interfaces.  IDEFix was a commercial third part utility that attempted to give the same functionality to the IDE interface on the A1200 and A4000.  It was therefore a utility based on a hacked idea.  Its not unexpected that early versions of IDEfix may not have worked 100%. No doubt you knew this.  Its not the Amiga's fault that it didn't comply with what was a hacked PC interface design initially.  IDEFix 97 worked well, and OS 3.5 and OS 3.9 included this functionality as standard.

[koaftder]

I argued that the amiga can change the scheduler without a reboot,  but you can switch the Amiga on and off if you like to clear what's in memory, its not as if it takes any longer than a soft reset...wait a minute..thats anther argument isn't it...  Actually i don't think windows can change the scheduler at all, reboot or not.  And Linux needs a different kernel altogether to boot from to change the scheduler.  And who knows what other changes you didn't bargain for might be in that kernel..

Oops, I read your original post last night thinking you were arguing that you can change the scheduler and reboot with it intact. Sorry.

As far as schedulers go, I've never messed with it on linux. Never felt the need, and I've been using linux for dang near 15 years. Never had an issue with it on windows either.

[stefcep2]

As far as schedulers go, I've never messed with it on linux. Never felt the need, and I've been using linux for dang near 15 years. Never had an issue with it on windows either.

ha ha.  That neatly paraphrases what I've been saying: Pro-Amiga: "Amiga can do x better".  pro-PC: "i don't use or need x, i don't care, it therefore doesn't matter.  PC wins".  Its an argument that can be easily reversed: i dont use cloud computing, i watch DVD's on a DVD player, i don't watch Bluray, i play games on consoles not PC's, so none of these PC features matter.


Well Win 7's scheduler works differently and gives higher priority to user-initiated commands, and Linux offers entire kernels with different schedulers, so clearly schedulers do matter to users out there, if not to yourself.  And it would be a nice if PC gave you a choice, and a simple way of making that choice.  But they don't.

[the_leander]

theres a logical leap here ( non-Windows support aside): why does my PC need to keep a database of thousands of hardware pieces that are not and will not be present on my machine, if each piece of hardware that i can buy comes with it own self installing drivers in flash ROM?

From an individual level, what you're saying makes sense. The problem is that Windows hardware support stretches back for nigh on a decade. With each new itteration of hardware bringing more capabilities and additions. It means that you can take your copy of windows XP and install it as easily on a machine first produced in 2000 as you could on a system that is still warm from the production line today. How do you deal with the miriad of hardware variations and mixes (which probably number tens of millions of possibilities) without one?

And if a hardware manufacturer wants to support alternative OS's whats stopping them from putting a driver on the same flash rom?  And what's stopping the alternative OS users from reading the Win driver in ROM and reverse engineering it, isn't that what they soemtimes do now anyway?

Depends on the device, but lets take graphics cards as a good example. The drivers for both windows and Linux are more or less the same size. So instead of having, lets say a 30+ meg flash chip and all the electronics that go to support it, you're now up to 60, and then there'll be some versions of linux that'll need it in a different package format and so on and so on. It comes down to two things essentially, at least for the above example: The added cost of designing it into the hardware and fitting it in the way you suggest as well. And the cost of having to supply a miriad of drivers for various OSs. Verses a 1pence CD and leaving the other OS's either to supply vender made drivers via repos or OSS equivalents.

No doubt you knew this.  Its not the Amiga's fault that it didn't comply with what was a hacked PC interface design initially.  IDEFix 97 worked well, and OS 3.5 and OS 3.9 included this functionality as standard.

I was using IDEfix 97. But to get to the point where you could install 3.5 or 3.9, you had to have a working dosdriver which the 3.5 boot disk could copy to itself to allow the installation to take place. Either way this is all immaterial. I fixed it, it worked for the entire of the time I had both the 1200 and the drive in question (which was many years, indeed it was still connected and functional when I finally let the system go back in.... 2003 or so).

[amigaksi]

All of which still does not change that, despite a slower to react bit of port hardware that the PC will spend less actual time running the code to poll said port, even with the API overhead.

Or in simpler terms: the PC can do more other stuff while waiting for the IO device to be ready than the Amiga can. Which is to say that even though it uses API's to access hardware, thanks to being really, really, really fast it still is faster than the Amiga to execute the relevant code (i.e. poll the hardware).

That it needs to wait longer for the hardware to be ready is irrelevant because this discussion is not about the speed of a parrallel port controller (which is the primary cause newer PC's have slower ports) but about the overhead incurred by the API's and drivers driving said controller.

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.  So, you can't draw the conclusion that API access will be still faster than Amiga going direct to hardware.  If API call was just doing the exact thing you would have done with the hardware, then you can say the overhead is minimal given processor speed of PC.  Also for input like USB input of joystick or gameport input of joystick, you will be doing multiple I/O instructions whereas Amiga does one.

I don't know what you mean by parallel port controller is primary cause of slower ports.  It's not.  Parallel ports are usually PCI in the latest machines that have them; however, there are other I/O ports like 60h..64h (keyboard) that are much slower.

[amigaksi]

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


This an OS issue. Run AROS X86.

It's an OS issue but that's what that particular point was about.  Amiga OS doesn't fill up some big file which failing causes an entire system failure.  I think they should allow system boot to continue allowing user to disable registry useage.

[amigaksi]

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


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


Amiga's API is primitive.

Yeah, parallelism and math units may be priority because everything is already standardized toward some API, but it would be better if hardware level compatibility was standardized and then API can still be built on top of that.

Amiga's API may not be as rich as modern APIs but even modern APIs don't offer the flexibility of going directly to hardware.  There are many things that are still inefficient using API approach.  As I stated, it's HLI (hardware limiting interface).

[the_leander]

ha ha.  That neatly paraphrases what I've been saying: Pro-Amiga: "Amiga can do x better".

But as was shown in the case of joystick polling, it couldn't.

pro-PC: "i don't use or need x, i don't care, it therefore doesn't matter.  PC wins".

With a landscape as diverse as the PC, going from nano-itx through to quadcore desktops and ending with rackmounted blade servers and everything in between. With all the different operating systems that run within that ecosystem, comparasons of a technical nature are for the most part pointless, especially when what you're comparing it to was starting to look outdated compared to those same PCs by the time AGA was comming out. Hell even addon cards for the Amiga at the time could outperform AGA in every respect, graphics, sound, I/O - the works.

It's not about being pro anything, indeed to even start to think in those terms is a gross misunderstanding of the situation. This was about pure technical points. Nothing more. It is you and your chum amigaski that have attempted to turn it into a "Pro-PC, Pro-Amiga" debate, no one else.

Well Win 7's scheduler works differently and gives higher priority to user-initiated commands, and Linux offers entire kernels with different schedulers, so clearly schedulers do matter to users out there, if not to yourself.  And it would be a nice if PC gave you a choice, and a simple way of making that choice.  But they don't.

Linux is used in different roles. As you yourself pointed out in an earlier comment - Linux schedulers (at least at the time) were better suited for servers. Now you have branches more specialised toward desktop usage. Different requirements require different solutions. I would imagine that the Windows server systems have no end of tweeks that make them perform better in a server role then its desktop counterpart.

Choice in this case only makes sense if you understand the consiquences of that choice. Chances are, if you know what a scheduler is and how differences in what it does effects a system, chances are you know enough about the system to be able to change it anyway. If building computers has taught me one thing, it is that the user, for the most part doesn't particularly care about choice, so long as it does what they expect, when they expect it. If you put in a preference system that allowed the user to access and alter every single option from the get go, they would almost certainly be overloaded (at best) and complain, or worse, start fiddling and then complain when it broke.

[amigaksi]

perhaps you misinterpret this. there is this movement in the pc world where legacy ports are getting replaced by a single port(to make them cheaper). perhaps that is where the reason lies.

keyboard
at>ps2>usb

mouse
serial>ps2>usb

joystick
joyport>usb

Printer
Parallel>usb

External Modem
serial>usb

see a trend?

There may be move toward USB, but the fact that they left certain ports in while eliminating gameport should indicate they are trying to improve gaming interface.  I.e., they are admitting gameport sucks and user is better off using another interface.  Newer audio cards also aren't using gameport although it was built-in into many audio cards.

[koaftder]

It depends on what instructions you try to do in  Parallel ports are usually PCI in the latest machines that have them; however, there are other I/O ports like 60h..64h (keyboard) that are much slower.

Nope, it's on the Super I/O chip, which can be on it's own IC or integrated into the northbridge. Either way it's on the low pin count bus along with the flash rom and other crap.