PC still playing Amiga catchup

[stefcep2]

It's all down to the trolling at this point.
The amiga was great because back in the day the graphics knocked your socks off.

The Amiga was great for a lot of reasons other than the graphics.  But if the A500's graphics is what made it great for you, then I'll take that into account when giving any credibility to what you post.

[EvilGuy]

But none let you set the priority of individual tasks.

What? Have you used Windows or Linux in the last five years?

Windows:
Bring up task manager, Process Tab, right click on the intended process, select priority.

Linux:
Open up gnome-system-monitor, select processes, select intended process, select priority.

All nice and point and clicky.

[Trev]

But none let you set the priority of individual tasks.  The Windows system decides what is a "program" and what is a "background" task.  You may for example want a higher priority given to a *particular* task in the background, but not to other background tasks.  Windows won't let you do this: any task whose window you haven't made active becomes a background task, and will eventually get lower priority to any task whose window is active, or vice versa depending on if you give more cpu time to "programs" or "background" tasks.

That's not true. Windows provides fine grained control over priorities, both in APIs and user accessible GUIs (hint: Task Manager). You're also a bit confused. Priorities affect scheduling, but they don't affect quantums. All threads except those with real-time priority can be preempted by the scheduler, and starved threads will eventually have their priorities boosted to compensate for overactive higher priority threads.

You're also oversimplifying foreground v. background. I'm going to go out on a limb and guess that your experience doesn't extend much beyond single-user--i.e. a single window station--desktop systems. That's OK, though. Microsoft publishes more documentation than any other software vendor, and it's all publicly available. For free.

[EvilGuy]

So why are there Linux kernels compiled with different schedulers readily available in most Linux repo's?  Must mean the Linux user community has already had this very discussion, and felt the need to re-compile their kernel with a new scheduler, just to try to catchup to the Amiga?  Kernels with different schedulers exist because they offer something the standard one doesn't.  Whether you want to make use of it is besides the point.

Some people want to use Linux on servers, so they have a different kernel to those that want to use it on a Desktop machine. Some people want a kernel that has a nice boot splash screen, whilst others don't want video output at all. And considering that Linux can
support so much more hardware then the AmigaOS can its not surprising that there are
so many different kernel versions available.

Of course, changing schedulers from user space isn't anything spectacular. Linux has had the ability for a while, http://dynsched.sourceforge.net/ and http://www.linuxhowtos.org/System/iosched.htm for examples of changing the process and IO schedulers. Normally when kernels are built all of the schedulers are built as well, its just a matter of changing the one the kernel is running with. And where the Amiga is still playing catchup - these are all part of the standard kernel - no third party hack like Executive on the Amiga, needed.

[amigaksi]

Commodore was unable to react as quickly other companies...

And during VGA standard card development, some bigger companies beat other smaller companies in developing standard VGA cards that had backward compatbility in hardware.

[amigaksi]

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.

...

There's more than ten tables.  It looks like they append newer tables as newer hardware is added.  You can fetch various things like I/O port addresses for SMI and so forth and read/write directly to I/O ports.  If all the chaos of various other audio/video/ethernet/etc. cards didn't arbitrarily use I/O port, memory map resources they could have fixed the I/O port addresses but ACPI is dealing with in best way given the chaos of people using their own I/O ports/memory maps.

>It fosters rapid GPU hardware development.

>Depends on APIs.

APIs are always slower than going direct.  You can draw that conclusion logically without having to measure the time.  They still have to develop GPU hardware to newer functions supported by API and still use some I/O method so I don't see how much harder it can be to develop to some specified I/O ports and memory map.

[amigaksi]

actually that port was the easiest to replace because it was relatively unused by most users. those that did use them just went with the flow and upgraded to usb. they were not singling out gameport users. ps2 users resisted the change so they tended to hang around. same with parallel users(until usb printers became common) now they may or may not be there an motherboards. serial ports are sill used for industrial applications even tho outdated so those are usually still on the motherboards.

Must be a billion gameports out there-- perhaps a few million trashed.  So it's hard to make a statement-- it's unused.  Perhaps, you don't use the gameport.  And my motherboard has a parallel port and PS/2 connectors -- no serial port.  So your speculation serial ports are still around is just your experience.  I see more desktops with parallel ports.  By the way, Microsoft must have done some gaming research to come up with XBOX joysticks.

[amigaksi]

i know what you said. but you qualified your statement with "well-behaved."

...

You can have well-behaved of any software-- one that goes direct to hardware or API.

>well-behaved apps could go to the hardware more efficiently BUT this is only if there is no hardware errors in compatibility.

That's worse for APIs.  If there are hardware errors, they are usually published and kept so you know they will be there.  If you fix them in APIs, then you have to worry about whether the user has the erroneous version or newer version.  Sometimes hardware errors are taken as features like enabling 7 bitplanes in OCS to enable a static mask bpldat.

>the api allows a buffer zone as i said so that if the hw has bugs the manufacturer can work around them. also if an api fails then there is coding that will reset the api so the os does not die. however if you go direct to hardware there is no such coding at present to handle this kind of event which has the potential to lock up the os.

Sorry, but application API access is protected by OS but drivers using APIs aren't.  So they are likely to cause OS lockups just as well as one going direct to hardware. But you can also protect applications going direct to hardware using IOPM.

>by definition direct to hardware is DIRECT there is no floodgates in between for protection. if you do we are back to the api model.

Sorry, that's not how IOPM works and there's no API model involved.  If you wanted to protect your hard drive I/O ports, you can protect them via OS and application can go direct to hardware and only OS will get control if application accesses those I/O ports you protected.  Application does not have to use API.  My application (MPDOS Pro) is an example that goes direct to hardware on I/O ports and does not use any API calls and keeps OS stable.

[amigaksi]

Reformatting or restoring the file would most likely place the data on a good sector, leaving the bad sector unused and waiting for the next unwitting block of data to be written to it. It depends on the disk and the allocation scheme used.



Of course, but it could also be caused by an interruption to the OFS/FFS file system routines, which are in no way fault tolerant.

The most likley cause of the problem in both cases (regsitry on NTFS v. arbitrary data on OFS/FFS) is a disk failure or a catastrophic system failure. Edge cases related to file system deficiencies and unsynchronized access to data structures are less common, but NTFS obviously has an edge over OFS/FFS.

Actually, hard drives are more robust now then they were in the past.  But writing to hard drive (especially registry) when there's power outage or you turn off the system can cause corruption of the file and that problem has nothing to do with hard drive failure.  It can happen on brand new hard drive.  My point is that in that case Amiga's simpler style of writing data to separate files would cause less damage.

[amigaksi]

By defining those standards, you limit innovation. How wide are the ports? 1 byte? 4 bytes? 8 bytes? How large is the framebuffer? 256 kilobytes? 4 megabytes? 256 megabytes? 1 gigabyte?

The only surefire way to provide both backward and forward compatibility is an API, regardless of where that API is implemented.

Sorry, but I did give many examples of how this standard can be hardware based and not limit innovation.  VGA was 8-bit initially.  They made 16-bit VGAs (ISA) then 32-bit (VESA) and then 32-bit (PCI) and then AGP and so forth.  Even if you wanted to add new ports, you can still retain the old ones.  API is the inferior method of doing it.  It may be cheaper (save some silicon), but it's worse for the general user who can better optimize things going directly to hardware.

[koaftder]

Sorry, but I did give many examples of how this standard can be hardware based and not limit innovation.

No the hell you didn't. You've just given us platitudes about BS while ignoring how modern hardware works.

[amigaksi]

It's not? Even the Amiga did things in parallel, hence the sensitivity to actions that interfered with system timing, e.g. a CAS instruction.

Most (not all, but most) new systems sold today have at least two CPU cores, never mind the number of independent execution units on the cores themselves. Parallel execution is now the de facto standard, whether your software is aware of it or not. You can ignore parallel execution, of course, but only to the detriment of the rest of the system.

If you do an IN AL,DX and then switch contexts the stack will save (EAX,EDX) at least which are related to the IN instruction thus no parallel instruction can execute until this one finishes.  I am just speaking of context switching on the same processor.  You have to wait for IN to finish to use the joystick data or whatever other device you are doing IN from.

[amigaksi]

No the hell you didn't. You've just given us platitudes about BS while ignoring how modern hardware works.

You look like you had a bad day.

[koaftder]

The Amiga was great for a lot of reasons other than the graphics.  But if the A500's graphics is what made it great for you, then I'll take that into account when giving any credibility to what you post.

I remember when the old man brought that Amiga 1000 home back in '85. Other kids had the NES, some had the c64. We had PC's in school. That a1k blew it all away. Nothing could compare. I remember going to a software store in Dallas texas back then, and seeing the Juggler demo projected on the wall. I caught my first taste of C on the amiga. Used that machine until 1993. When we moved to North Carolina in 1990, I never saw Amiga anything since. No software in the stores, no Amigas on display. I do remember around 1995, the Weather Channel had a problem. A CLI window was on display, for the whole nation to see. Thats the last i ever saw amiga anything in the wild.

[koaftder]

If you do an IN AL,DX and then switch contexts the stack will save (EAX,EDX) at least which are related to the IN instruction thus no parallel instruction can execute until this one finishes.  I am just speaking of context switching on the same processor.  You have to wait for IN to finish to use the joystick data or whatever other device you are doing IN from.

Nope, this is wrong. Nobody uses that hardware, no modern machines ship with it. Folks haven't used it in 10 years.

[koaftder]

You look like you had a bad day.

I had a great day.