Yet another thing the Amiga can do that Windoze can't.....

[Damion]

I've never really had performance issues with Windows, for a mainstream OS (something my grandparents have no problem using), it's just fine. Yet, if you desire to get into the "nitty gritty" and tweak Windows around like AmigaOS, you can.

As I see it, AmigaOS is for nostalgics, and/or geeks who like to tinker with things. *Some* ideas may be implemented a bit more simply, but overall, Amigas/AmigaOS is far more difficult to setup and use efficiently. (Try building up an expanded A1200/OS 3.9 system from parts, it's *far* more arduous than, say, PPC Linux even. A Windows PC, from boxed parts to a fully tweaked XP install, can be fully operational in less than an hour... and probably by my 80 year-old grandfather.)

Subjectively, I have *fun* using Amigas/AmigaOS, but (like someone mentioned above) I simply don't see the point in comparison.

   

[MskoDestny]

Cymric wrote:
1. Measure time with a greater accuracy than 55 ms. Amigas have CIAs which provide microsecond accuracy.

At least on more modern systems, the OS will usually give you down to 10ms resolution. The PIT is theoretically capable of going lower, but it's inefficient to do so (interupts are expensive on modern processors and reading from the PIT directly rather than counting interupts is slow for other reasons). If you don't need to trigger interrupts and just need to measure time the ACPI PM clock has sub-microsecond resolution.

3. Display an image based on bitplanes. (Then again, the Amiga cannot really display a chunky image without employing advanced Copper trickery, and then at great loss of resolution. The entire concept is alien to the Amiga hardware, is what I'm saying.) This made the Amiga perfect for sideways 2D scrollers, but absolutely not perfect for 3D games.

I don't know if the Amiga bitplane approach is really ideal for 2D games. It makes sense in the context of the computer as a whole (i.e. it's not just for playing games), but most 2D graphics hardware in games consoles used tiles made up of 4-bit (and in some later incarnations like the Saturn 2D hardware 8-bit) chunky pixels. In a modern computer bitplane based displays really don't make any sense as there isn't any real reason you'd want your display to operate at less than an 8-bit color depth anymore.

2. Generate raster interrupts the way the Copper can.

4. Attach 9-pins joysticks and mice with ease. (You always had to use a 15-pins port.)

5. PCs do not have standard hardware support for light pens and potmeters. Then again, who uses a light pen nowadays? (I had this one for my Schneider CPC464---very nifty and cool toy.)

I don't think these are terribly relevant anymore. The Amiga has better handling of floppy disk hardware too, but hardly anyone would care now since USB flash drives are superior in just about every conceivable way.

6. Nor do they have standard support for analog TV out signals (it depends on your video card) or genlocking (which is now handled in a different way).

I don't know if you can really say the Amiga exactly had standard support for analog TV signals. The 2000 only supported mono composite without extra hardware and the 4000 didn't have any analog TV output at all without extra hardware. TV-out is more or less a standard feature on laptops these days and is reasonably common on desktops too. Of course, none of them support genlocking, but as you said that's a feature that's not really relevant anymore.

[adolescent]

No problem doing that here on my PC.  AsyncWB didn't come out until OS3.9BB1, so you're telling me that it was 20 years ahead of it's time?  :crazy:

[da9000]

stopthegop wrote:

"to be owned" is a verb

Only in prison.   :lol:

LOL!

[da9000]

stopthegop wrote:
Try this on a pee-see; XP gave me an error then proceeded to do exactly the opposite of what should have happened; logically, anyway.    
At the same time, delete all the files in a large scratch directory then uncrunch a large number of archive files to that same directory.  

This could be the OS, but it could also be the specific applications. In other words, who holds the directory lock (I assume M$ Exploder does for the delete), and then does the application that does the unpacking ALSO take a lock on the dir or not? If not, then the OS can't fully be blamed. Although it should notice that another process is trying to access said directory and either hold the lock or warn the application.

[da9000]

@Roj:

LOL! Typical "Windoze" story, trying to print a critical document when running out of time, it's almost a guaranteed even that Winblows will give you trouble! I've had it happen hundreds of times!

[da9000]

Cymric wrote:
...and extracted a compressed mudlib with about the same number of files but much smaller average filesize into that directory. Deletion was nearly instantaneous; it took a little longer for the file system to flush out the changes to disk, ...

which means you conducted the test wrong because all the dirty data was in the file cache. Always wait to flush the dirty data to disk. You can force this by using a proper OS (any Unix, sync is the command), or reading a huge amount of data, which will cause the file cache to flush the dirty data and be filled by other data. I typically do an md5sum of a huge file (movie file) which usually works.

[da9000]

A couple corrections and additions are added to the following:

Cymric wrote:
1. Measure time with a greater accuracy than 55 ms. Amigas have CIAs which provide microsecond accuracy.

That is true, but only partially true. The way the PIC (Programmable Interrupt Controller, which included 3 timers, timer 0, 1 and 2, but only timer 0 could cause an IRQ) works is that you can set the tick count to 65536 (maximum) and then wait for it to go to 0, at which point an IRQ is caused. This yields the 55ms timing that people are refering to. Of course since the PIC worked off of a 1.19318MHz crystal, the actual tick time, and therefore the accuracy of the timer was 0.838 microseconds!! Therefore if you set the ticks to 1 and waited for an IRQ, you would have an almost 1 microsecond accuracy! (of course code and IRQ latency would make that a bit hard, but you were certainly nowhere near the mythical 55ms times, but in the low 1-4 microseconds depending on the CPU). This could and was exploited to create a Copper-like system, by some of us.

Also keep in mind that any Pentium or newer CPU does have a TSC instruction which is as accurate as the clock cycles of the CPU, therefore one can make tiny measurements. The problem is that it cannot cause an interrupt. Although I believe the newer APICs do have more accurate timers, but haven't messed around with that stuff for ages.

Cymric wrote:
2. Generate raster interrupts the way the Copper can.

That's true, because the PCs never had a Copper-like chip. On the other hand, those with some ingenuity and coding skills would (and did) devise a Copper-like system, which wasn't as accurate as the Copper (ex. every 4 pixels), but every scan line, and could have vertical raster bars on various PC screens (aka. demos and games), for virtually "0 CPU cycles". We used the PIC for this.

EDIT: I found my old code... Now, I'm ashamed of what I wrote on line 3, but at least I had my head together for line 4:

"
; this is my software (IRQ based) COPPER-equivalent (sorta chip for the
; Inherently Bogus Machine Piece o Crap (aka IBM PC)  [v86 mode]
; but I will admit to you that I love the x86 assembler instruction set
; and that my Amiga 3000 will kick its ass at any given moment
"

Cymric wrote:
3. Display an image based on bitplanes. (Then again, the Amiga cannot really display a chunky image without employing advanced Copper trickery, and then at great loss of resolution. The entire concept is alien to the Amiga hardware, is what I'm saying.) This made the Amiga perfect for sideways 2D scrollers, but absolutely not perfect for 3D games.

That is enterily wrong. The PC since the EGA days _DID_ support bitplanes and various operations on bitplans (xor, etc). The problems were 2:
1) Limited bitplanes. They were only supported in 16 color mode, which meant 4 bitplanes. Yet we were able to do quite a few cool demos & intros with those because they made drawing much quicker (usually 2x faster, since it's only 4 bits per pixel vs . This also helped a lot in high resolution modes, like 640x480 and 640x400 (games like that Gyger inspired adventure game, whose title I forget, used this, and actually I forgot, one of the games I worked on)

2) You couldn't individually scroll the bitplanes like Amiga playfields. You could only hardware scroll all of them at once. Sucked big time... although there were some tricks you could do, and there was also the ability to have a vertical hardware scrolling split screen.

All the rest hold true as far as I know.

[Cymric]

MskoDestny wrote: ... a lot of stuff...

Just to be clear on this: my post was written somewhat tongue-in-cheek, to put an end to these silly 'PCs can't do this, while my Amiga can!'-discussions. While in most cases the technology has been superseded, the items on my list remain valid as support of the 'My Amiga can do X, while your PC can't!'-argument .

If you don't need to trigger interrupts and just need to measure time the ACPI PM clock has sub-microsecond resolution.

Aha, this is something new for me. I always wondered how PCs could be so hamstrung, although apparently Microsoft and Intel drew up a specification for a new timer called HPET back in 2002, with a finalisation in 2004. So PCs will finally have access to high precision, low overhead timers---it sure took them bloody long enough!

[da9000]

MskoDestny wrote:
...you down to 10ms resolution. The PIT is theoretically capable of going lower, but it's inefficient to do so (interupts are expensive on modern processors and reading from the PIT directly rather than counting interupts is slow for other reasons). If you don't need to trigger interrupts

Not theoretically, but realistically :-)
But you're right, it's inefficient after a certain point due to the latency of the interrupts (especially in mixing real-mode and protected mode code, aka Windoze up to and including 95/98/ME). The biggest problem in the DOS days was the fact that only timer 0 caused an IRQ, so you'd have to do some pretty complex multiplexing to be able to have timing IRQs for other events and the timer. Sucked big time.

MskoDestny wrote:
I don't know if the Amiga bitplane approach is really ideal for 2D games. It makes sense in the context of the computer as a whole (i.e. it's not just for playing games), but most

I think it made perfect sense for 2D games, as long as playfields and a blitter were available, as in the case of the Amiga.

MskoDestny wrote:
hardware 8-bit) chunky pixels. In a modern computer bitplane based displays really don't make any sense as there isn't any real reason you'd want your display to operate at less than an 8-bit color depth anymore.

I agree with this: in modern computers chunky is doubtlessly simpler and better, and of course more desirable (colourwise)

[da9000]

Cymric wrote:While in most cases the technology has been superseded, the items on my list remain valid as support of the 'My Amiga can do X, while your PC can't!'-argument .

No they don't :-p  Not all of them at least. Read my first reply to you.

The Amiga still rules of course :-)

[DonnyEMU]

My reply:

1) Someone beat me to the response with this one dang, there are some knowledgably hardware people here..

2) Not needed and honestly any current GPU/graphics card can cream this for overal function..

3)Most older VGA cards offered both planar and non-planar functionality. Planar functionality just fell out of popularity as resolution and color depth increased. The only Amiga that has halfway decent non-planar support is the CD32 with it's Akiko chip.

4)Pinned ports wholy 1960s Batman, USB is the ONLY way to go.. Not even getting into the whole digital versus analog joystick thing.

5) Again things lost to history. However HP just released a touch screen PC with the release of Vista, I highly suspect that has some modern form of Potentiometer..

6)Standard TV signals and their rates of refresh are very well supported. Please explain your comment further..

[Cymric]

da9000 wrote:

Cymric wrote:
...and extracted a compressed mudlib with about the same number of files but much smaller average filesize into that directory. Deletion was nearly instantaneous; it took a little longer for the file system to flush out the changes to disk, ...

which means you conducted the test wrong because all the dirty data was in the file cache. Always wait to flush the dirty data to disk. You can force this by using a proper OS (any Unix, sync is the command), or reading a huge amount of data, which will cause the file cache to flush the dirty data and be filled by other data. I typically do an md5sum of a huge file (movie file) which usually works.

I didn't do the test wrong. The test is about cocurrent deleting of files and addition of files in the same directory by two separate processes. Unfortunately my computer is so quick that the deletion process (minus the synching) is completed before I can start adding new files. Unfortunately, your solution isn't a solution then, because a) I don't need sync, and b) your description of sync doesn't match with what you describe is required: sync doesn't wait with buffer flushing. What I really need is a custom program which starts up two separate tasks which are given the go-ahead with a signal to both---whether there's flushing out data somewhere along the way is not really a concern for this test. And even then I would have to be careful because this is a problem rife with race conditions, and highly dependent on how the unlink()-process traverses the directory trees as well as how the unzip-process locks extracted files (if at all).

Come to think of it, the entire test is a stupid excercise to begin with precisely because of all these race conditions.

[da9000]

Cymric wrote:
I didn't do the test wrong. The test is about cocurrent deleting of files and addition of files in the same directory by two separate processes. Unfortunately my computer is so quick that the deletion process (minus the synching) is completed before I can start adding new files. Unfortunately, your solution isn't a solution then, because a) I don't need sync, and b) your description of sync doesn't match with what you describe is required: sync doesn't wait with buffer flushing. What I really need is a custom program which starts up two separate tasks which are given the go-ahead with a signal to both---whether there's flushing out data somewhere along the way is not really a concern for this test. And even then I would have to be careful because this is a problem rife with race conditions, and highly dependent on how the unlink()-process traverses the directory trees as well as how the unzip-process locks extracted files (if at all).

Come to think of it, the entire test is a stupid excercise to begin with precisely because of all these race conditions.

Yes, I agree it's stupid because of a simple impossibility: there's no way it can be done simultaneously. One event will have to preceed the other.

Obviously what I meant about your test is that you'd want to start with "data on disk" and not in RAM. The way you described it, it sounded like the dirty data wasn't even on disk. As for sync, it works as prescribed, but I meant that it's to be used before the test, not during or after..

Anyways, enough ->  :horse:  :-D

[Cymric]

Guys, before I get clobbered by lots of angry Amigans and PC-users: My message about what PCs can't and Amigas can was more or less tongue-in-cheek. Of course I know that many of the listed hardware specs are quite outdated, long since superseded by other and far better electronics, and therefore really no longer a sales or even usage point. I also got a few 'benefits' wrong: I stand corrected. Nevertheless, the fact that a piece of hardware is neolithic is of no concern for my little list: it still is something computer A can do what computer B---in its most standard configuration---cannot. We all capiche this?

Please, do add more information on crude hardware hacks: always nice to hear how people circumvented technical limitations of the machine.

[da9000]

Dear Cymric, the horse was meant to be representative of the "delete while unpacking" test, not you :-D

No clobbering of fellow Amigans will be tolerated :-)