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

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

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

[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

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

[da9000]

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

1) Horizontal Rasters

I think most people know this first one, but might as well refresh the memories:

The easiest way to produce a "horizontal raster bars" effect (like Turrican 2 let's say) on the VGA was to use a 256 color video mode and assuming you use a 200 line high video mode, you would put thick lines (2 pixels high) with color values from 0 to 100 (200/2=100 thick lines) in the background and then use palette cycling to cycle the colors from 0 to 100, so as to keep the "sky" fixed. This didn't take as much CPU time as "copying" the "sky" into place, so it was preferable. If you had a vertically scrolling playfield, then you would use more colors/lines, because as the playfield scrolled up and down, a larger area was "exposed". Of course you had to trade off the number of "raster colors" with the colors you'd use for sprites and such. Of course if you came from an Amiga/Atari background, you KNEW that you could pretty much kick major ass with just 16 colors (Bitmap Brothers anyone?), so you had almost 200 colors at your disposal for raster effects

2) Vertical Rasters

This was a much more restrictive effect, due to the stupid VGA. Basically, you would set the VGA so as to repeat "reading" from the same memory address for each scanline, therefore whatever you wrote on memory address 0 to 320 (for a 320 pixel screen), would be repeated until line 200 (in a 320x200 screen). By changing what you wrote in these first 320 bytes, you could create vertical raster bars. If you wanted more performance, you'd drop down to 16 color mode, and draw much more (scrollers!!), but your raster bars would be very crude, color-wise (up to 16 colors). Of course there are tricks: if you used a Copper-like system and syncing with the horizontal retrace signal, you could do a lot more. You could also combine palette cycling and add an animated background. I had a very nice (unfinished) intro screen that did this stuff once.

3) Dual Hardware Scrolling Playfields

Only Amiga makes it possible! But there's a crude way to force the VGA to do something close to that. Now, I'm not talking about the top playfield and the "split screen" playfield at the bottom. That split screen thing only moves up and down. I'm talking about 4 directions.  This was an uber rare effect. I think the only others who have done it in a production were the Future Crew, but not 100% sure (I never bothered to disassemble their awesome Panic demo). Anyways, you would use the starting address offset register of the VGA to do the normal playfield (very much like an Amiga actually, except no DMA and such elegance, but direct CPU PIO, programmed IO). To do a second playfield, you would actually use the line size register (I forget the exact names...), and force the VGA to have super long lines, so as to cause it to start drawing from a different part of memory, as soon as the first rasterline was on screen, you would flip the size back to the normal (320 for example), and the VGA would read the "playfield data" normally. Then at the end, you'd force it again to some weird value (low? I'm forgetting at the moment), to cause it to "reset" back to the proper memory address. Needless to say some VGAs wouldn't function properly with this trick, partially because they were never meant to!!!! (you normally change the scan line pitch once, when setting up the video mode, not per horizontal scan line, during display enable!!!)

Anyways, if I remember anything else I'll try to add.

Ah, if only all the PC freaks had Amigas at that time...