PC still playing Amiga catchup

[Karlos]

I thought the PPC has no caches.

Nope, the 603e, for example has 16KiB instruction and 16KiB data. IIRC, the 604e doubles this.

What you are probably thinking of is L2 cache. There isn't any of that on the Blizzard/Cyberstorm. Then again, as far as I know, no amiga accelerator has L2 cache.

[Karlos]

Originally Posted by stefcep2  View Post
BTW does anyone know WHY Windows and linux need a swapfile even if they use so little available RAM? I know you can force the swap file size to zero in Windows, but I suspect it still uses a swap file. And AFAIK Linux won't install without a swap file partition.

First of all, they don't use a little amount of ram. They use as much of it as possible at any given instant since the paradigm they follow is that unused RAM is needlessly wasteful. Instead it's used for caches, buffers and so on:

The memory utilisation of my machine at work here a moment ago was as follows:

Code: [Select]

Mem:   1032208k total,   956012k used,    76196k free,   103616k buffers
Swap:  4610612k total,    31520k used,  4579092k free,   299596k cached


As you can see, most of the physical memory is in use. What you will also note is that most of the swap is not in use. It is possible to run without a swap file, but why would you want to? It's only used when you are trying to do more than can be reasonably accomplished within the confines of your physical memory. Think of it as a safety net. Better to run a  bit slower when paging kicks in than simply stop running and fail in some fashion.

Furthermore, modern memory allocation strategies don't actually have to allocate the memory all at once. Physical allocation need only occur when a page within that allocation space is accessed for the first time. It's not uncommon for large allocations at compile time to turn out to be oversized at runtime. This way, only the amount of memory actually required at runtime (as opposed to what the program thinks it required) gets allocated.

-edit-

My machine at home isn't using any swap:

Code: [Select]

Mem:   4053804k total,  3404668k used,   649136k free,   900776k buffers
Swap: 20000884k total,        0k used, 20000884k free,  1871376k cached


[Karlos]

I don't really think it has anything to do with driver initalization though.

Have you seen typical driver sets for things like graphics cards these days?

Thanks to direct support for CUDA, PhysX, OpenGL1.0 - 3.0, Direct X (up to v10), Pure Video etc, the drivers for my card alone weigh in at around 100 MB, not including tweaking tools.

The linux drivers aren't much smaller.

[Karlos]

And thats mostly down to not having so many user definable options to adjust and things like real time previews of setting alterations. Either relying on the distro's own configuration menus or simply not allowing the options.

In a lot of cases it is litterally only a few megs either way.

True, though quite oddly, the linux driver does have an X Server Settings GUI that grants access to various options I don't see in the Windows version.

[Karlos]

@amigaski

If you are going to pivot the crux of your argument around precision timing with this degree of anality, then I am forced point out that the argument that all amigas have exactly the same timing, expressed in units of time (as opposed to cycles), is not true. You have not factored manufacturing tolerances of the clock crystals, nor have you factored in nonlinear effects caused by slight differences in temperature and voltage.

No two clock crystals give exactly the same timing, they just aren't that good.

[Karlos]

These differences are actually quite easy to demonstrate, too.

All you need to do is to play a test sound (something like a drum beat is good), looped indefinitely on a pair of amiga models of your choice (even the same model) and set them off. Naturally you won't be able to get them perfectly aligned at the start, but no matter. The important thing is how they sound an hour later compared to the start.

[Karlos]

Of course the clock crystal difference gets considerably bigger when you compare PAL and NTSC amigas

[Karlos]

Thought experiment:

Suppose you took an analogue joystick and used the X/Y potentiometers to control an independent left/right output volume from a oscillator (generating a note at let say several kHz)  then fed that into your basic sound card and sampled this signal at 44.1kHz. You could then calculate the RMS intensity of each channel in frames of 441 sample chunks and use that (suitably calibrated) to represent the original X and Y potentials. 441 samples at 16-bit precision would be ample data to get a decent value for the RMS intensity of a simple tone in the kHz range.

That should be pretty damn close to 1kHz sampling of your joystick position

(note, simply sampling a DC potential across the potentiometers with a soundcard isn't likely to work well, or possibly even at all due to the frequency response of the sampling hardware. Not many record 0Hz too well)

[Karlos]

:lol: amigaski has forgotten that physical switches have a maximum switch frequency... any amiga joystick will use cheap switches that will switch far bellow 1khz

Perhaps his joystick is built by the folks that made these

[Karlos]

Churning your hard disk, that's what. Rendering is usually a CPU/memory IO bound task. The bottlenecks there are small and a fast CPU/memory system will plough through such work.

Dependency resolution and all the nonsense that goes with it is generally a disk IO bound task. Modern hard disks have great transfer speeds but they don't seek much more quickly than they did years ago. If you are processing thousands of small files, the time is totally dominated by seeks and the like. The CPU will be twiddling it's virtual thumbs for a lot of it.

Having said that, yum and apt-get (to name just two) are significantly quicker. I think we just live in a world where windows is expected to be slow for these things.

[Karlos]

I don't really think that has anything to do with initalisation though.  With drivers your really are getting back to HD speed and CPU speed. Besides even it took a full second to initalize the card, with the Quad core beast, blazing fast bus speeds, and HD speeds you should be able to initialize just about everything at the same time.  Aside from the fact that many people, as some have pointed our here, this is possible.   Something QNX or Amithlon, take seconds to boot and you can access the internet, hear sound, see the desktop.

Compare the size of your ultra fast boot time OS and the functionality they give to those that boot more slowly on the same hardware.

Neither Amithlon or QNX support anything beyond the basic framebuffer of my card (and probably not even that). So, whilst they can boot in a fraction of the time, they don't offer the same functionality. No 3D, no physics acceleration, no GPGPU support, no video decoding.

If I only use the most basic supported drivers for all my hardware I can reduce the boot time quite considerably. However, I didn't pay good money to buy hardware I can't use properly.  A card with ~960GFLOPS number crunching capability is no better than an old Cirrus Logic if all your OS/divers grant you is a few MB of framebuffer.

The argument about the quad core being able to initialise everything is neither here nor there. Aside from starting services, booting up is pretty much a single threaded operation, one that is dominated by waiting for hardware and disk IO. Disk intensive (many seeks and small transfers) operations are slow on any OS, AmigaOS included.

If you are going to assert that slow boot times must be down to something else, then you need to explain why my A1XE doesn't boot dozens of times faster than my least classic machines do. It has much faster hardware and is pretty much doing the same jobs in the same way as OS3.9 did them during boot time.

[Karlos]

So sorry, you still can't grasp the simple file I wrote and rather opted to be mislead by some speculator who is already known to have mislead people.  When you press the fire button and let go and move the joystick, you can go through a few states of a joystick that require millisecond accuracy.  In fact, it can be less.  Now your bullcrap about two clock crystals not giving exactly the same timing is just that-- a separate argument and just bullcrap since the crystals only need to be as accurate as to produce the timing needed for the system and there are ways to insure they all have consistent timing.  Perhaps, you want to read up on how they actually get Coppers, CIAs, Audio Interrupts, etc. to get the same timing rather than blurting out some blind assertion to mislead people.

Temper, temper. Just mirroring your pedantry. Struck a nerve, did it?

[Karlos]

Thought experiment:

Suppose you took an analogue joystick and used the X/Y potentiometers to control an independent left/right output volume from a oscillator (generating a note at let say several kHz)  then fed that into your basic sound card and sampled this signal at 44.1kHz. You could then calculate the RMS intensity of each channel in frames of 441 sample chunks and use that (suitably calibrated) to represent the original X and Y potentials. 441 samples at 16-bit precision would be ample data to get a decent value for the RMS intensity of a simple tone in the kHz range.

That should be pretty damn close to 1kHz sampling of your joystick position

(note, simply sampling a DC potential across the potentiometers with a soundcard isn't likely to work well, or possibly even at all due to the frequency response of the sampling hardware. Not many record 0Hz too well)

I'm actually really tempted to try this for real now :lol:

[Karlos]

We're yet to be convinced that:

1) Any amiga game, other than your code, samples the joyport at this rate.

The one example I can think of where high joystic sampling rates may be used would be the ZXAM tape interface.

2) That the ability to sample the joystick represents a genuine advantage. Your sample data suggests that you are able to observe the electrical properties of the micro switches as they close and open. I'm certainly not convinced that this resolution is useful unless you intend to produce time a averaged sample of the observed state at a lower resolution. For example, averaging the entire set of samples at 1kHz every frame into a value that you assume is "on" for the frame if more of the samples were in the on state than the off state. I'm not convinced any game does this. It more likely reads a sample once a frame and moves on.

3) You can't really infer what the sample rate of an application is just by attempting to sample the signal yourself and reproduce it the behaviour of the original application from it.

What you should try is sending simulated pulses at different rates to the joyport from another device from which you can control the pulse of and see wether or not the game is capable of responding to it in a predictable fashion.

[Karlos]

If there is variance of clock speed (even by a fraction of a second) between two otherwise identicle systems using the same cycle, both cycles will still be identicle, but the timing will be different. This is demonstrable for anyone who owns more then one Amiga, even of the same model.

You're mixing up your definitions again, I personally think deliberately here.

That's why I pointed out timing specifically "in units of time", rather than "in cycles" However, our friend here has been throwing around statements like "558ns with no +/- bullcrap", which is why I felt the need to clarify.

eg:

Depends on the task.  If your real-time task only involves modifying some registers, you can use the Copper and it's guaranteed with accuracy of 558ns (no +/- latency bullcrap).

And we can talk Amiga vs. PC w/o dealing with OSes although with PCs you'll have a hard time finding modern PCs that even maintain compatibility at hardware level.

Absolutely no way can you say you can claim "558ns accuracy" when the clock signal itself is subject to variance. Furthermore, the clock speed is slightly different between NTSC and PAL Amigas. For example, in a base A1200, the CPU is driven from the same clock as the rest of the native hardware and the stated clock speeds are 14.32 MHz for NTSC and 14.18 MHz for PAL.

[Karlos]

You haven't shown PC doing faster joystick port input so we can move on to the next advantage Amiga has over PC.

You should disassemble the game and find its input handling code before claiming it is using 1kHz sampling. As I've pointed out, you can't base this assumption on attempting to see what minimum sampling rate you need to use to replicate it. I can produce a signal on a machine that I need to sample at 44kHz to get it sounding "just right", but this by no way suggests the signal source is operating at a comparable resolution.