PC still playing Amiga catchup

[Karlos]

1.  Hard drives are fast, but files are so big.  So access from hard drive on a PC will never be as fast as access from a dynamic RAM: drive.

Erm, that's a bit of a silly way to put it. Really big files aren't going to fit comfortably into memory either. Chances are they'll get paged out to hard disk anyway.

2. Writing and deleting files frequently as would happen if you used your hard drive as a dumping ground for eg unarchiving stuff which you delete afterwards results in disk fragmentation, reducing your PC's performance over time.

That really depends on your filesystem. Using your Amiga's RAM disk to save disk fragmentation is all well and good but you're ultimately just fragmenting the memory instead. Which isn't a great idea. With 256MB of ram, I've been unable to run an application needing 32MB without a reboot due to this issue.

3.  Its a pain to have to delete unwanted files, wouldn't you just prefer they weren't there next time ypou booted... oh hang-on no-one here boots up anymore so yeah you have to remember to delete otherwise you'll soon have a lot of crap you don't want filling mots of yor hard drive.( don't tell me, hard drives are so BIG now THAT akso doesn't matter).

Use /tmp for your dumping ground and use tmpwatch. Problem solved.

4.  what about installing and running software in RAM just to check it out?

Sure, that's handy sometimes.

Incidentally, you do realise that RAM disks are available on other operating systems, right?

For example:

$ mkdir /var/ramdisk
$ mount -t tmpfs none /var/ramdisk -o size=16m

Et voila, a 16MiB ram disk. It's actually more like RAD, in that it's fixed size, but like RAM: it's entirely volatile.

[Karlos]

I was thinking more of windows regarding fragmentation.  I've never experienced the RAM: fragmentation due to reading and writing to the RAM: disk.  i used it to store animation frames, which then color reduced, resized, deleted and replaced with the processed frames, which were finally compressed into an animation automatically with an arexx script.

Put one large file (ie around half the free memory) into the ram disk, a small file, then another large one. Now delete the two large files and leave the smaller one. Chances are, your available free memory is split into two big chunks.

One of the features of the Amiga's ram: disk is that its dynamic, only as big as it needs to be and handles transparently for the user by the OS. Can this be done in Linux ?

Not sure, I've never tried it. Probably not, at least not the way I suggested earlier.

-edit-

You also forgot to mention that tmpfs has a fixed size but not a fixed size in memory. It only uses as much RAM as its contents and if it gets full it pages itself to disk.

There you go then

[Karlos]

I should point out that under ext3 etc, "large files" in linux are only as large as their contents too, due to sparse file support. Instead of allocating N empty blocks for a large file on disk, it only allocates blocks that are written to.

[Karlos]

For example the first login to KDE is quite slow, the second login is lightening fast.

I totally gave up on KDE with 4.x *shudder*

[Karlos]

google: Results 1 - 10 of about 18,300,000 for windows ram disk
doh

Results 1 - 10 of about 74,900 for amiga ram disk.

Bugger! :lol:

Failed at googlewar.

[Karlos]

@stefcep2

Don't conflate seek times with transfer rates. For large files seek time is usually insignificant compared to the time taken to read or write the data. Here, transfer rates dominate. Now, RAM is certainly faster than hard disk here too, but what you have to consider is whether or not it matters. When streaming blue ray content, for example, existing SATA drives have ample transfer speeds, so you don't gain anything from putting it in RAM.

Conversely, for repeated access to lots of small files, seek times dominate. However, modern hard disks tend to have large caches to mitigate this and filesystems may add additional memory based caching on top of that too.

[Karlos]

Get a clue.  I am talking 680x0.  There is NO "great" difference to need a library.  You want to exaggerate and distort the truth and claim there's a great difference then that's as good as saying they are incompatible.  Biased.

See my earlier post. Any software needing 68881/2 instructions not directly implemented in the 040 FPU will fail on 68040 without the 68040.library loaded. You will just get a fatal F line exception based guru instead. Beyond that, all software will run significantly slower without the 68040.library since the data cache cannot be readily enabled without the library.

The situation is even worse on the 060 where any 32x32->64 bit integer multiplication will fail without the proper 060 support code installed.

They are not minor differences.

[Karlos]

The 68881 is the official motorola FPU for use with 68000, 68010 and even low speed 68020. 68882 is the official motorola FPU for use with higer speed 68020 and 68030. If you have an FPU for a 68000 machine it will almost certainly be a 68881.

MOVE to/from CCR is indeed better but it only exists with 68010 and above. You can't use it in 68000 object code.

[Karlos]

Um... The work I do, music production, simply can't be done on older machines, they are just too slow and have no support for the high definition audio interfaces that I use.

What, a few years ago, used to require several rooms of equipment and a large mixing console, can now be done on a £2000 MacBook Pro, a 24bit firewire multichannel audio interface and Logic Studio (plus and other software of your choice)...

Tut, what's wrong with good old ProTracker on a 512K A500? The timing is perfect and has no latency bullcrap like you get with your tragically inferior generic PC rubbish. Macbook Pro indeed :rolleyes:

[Karlos]

You can have my Emu10k DSP when you pry it out of my cold dead hand. nuf said.

I see your EMU10K and raise you a MOS Technology 8634!!

Emu10K... pah, I have one of those on a card I'm not even using (in my old PC)

Actually I found my old SBLive 1024 a bit of a pain for line in audio capture. There's a noise floor of about -80dB that you can't seem to get rid of.

[Karlos]

Yes, yes I did, because I didn't consider booting up with a comprimised OS.

What do you mean, compromised?

[Karlos]

Try running your raytracer at priority 20. And in the case that it uses a separate process for rendering, bump that up to 20.

[Karlos]

You never understood my point.  If I take an OCS machine with 68000 and run the program which works fine and now switch to an accelerator 68020/68030/68040/etc., the program should work fine (barring some rare exception).

No, you claimed the M68K was hardware backwards compatible whilst lambasting x64 for not supporting 16-bit directly in hardware. We merely demonstrated that the M68K isn't as directly backwards compatible as you claim.

If you accept that some form of missing or privileged instruction handling is necessary for higher 68K processors to run old 68000 code, then you can't slate x64 for needing the same.

Any exception is an exception. The SR should never have been accessible to user model and Motorola acknowledged this mistake.

You keep throwing in FPU/MMU into the picture to confuse things and thus your so-called experiment is a failure.

Yes, you are confused by it. But that doesn't change the argument that M68K does not retain direct backwards compatibility in hardware at each generation. And, FYI, I can get the same class of unimplemented instruction exception on 68060 just by running perfectly good 68020 code. No FPU/MMU required, just long multiplication.