Amiga questions you've always been too embarrassed to ask

[ajk]

Here is what it looks like as a waveform:



If we assume that we want to play a pure (sine) tone, it can clearly be seen that the 16 bit version is much less jagged than the 8 bit. A pure tone should only have one frequency, but the jaggies (abrupt changes in the signal) will cause there to be also higher frequency content in the output. Depending on the exact conditions this will manifest as some kind of tingling, squealing or other noise in the sound.

These higher frequencies can be later filtered out, but doing so will mean also losing some of the intended higher frequency content. That is why it would be better to have a better representation (= more bits) of the signal in the first place.

And of course another major issue is also the loss in dynamic range, as Daedalus explained. A quiet tone might only use, say, 3 bits of the range and that will be a very blocky waveform and therefore far from the ideal sound.

I have a stupid Amiga question. Please understand I'm not much of a hardware guy.

I have an OC'd CS Mk2 with a '060 that needs cooling. Is there a preferred heatsink/fan/paste/whatever combo I should look for to keep this cool?

[TroyWilkins]

Originally Posted by DamienD

Shame, you definitely lucked out there

...they are standard issue these days, all the cool kids have them

<sorry for the off topic; GMs can have fun too you know>

Hahahaha yeah. Call me weird if you like, but I still think the Amiga sound sounds good, even if it's not technically CD quality or better.

Originally Posted by Rotareneg

The simple explanation: 8 bit is noisier than 16 bit, this noise is called quantization noise.

It's most obvious when comparing quiet audio, like when the audio in this sample fades out:

[ Show youtube player ]

Ahh, that youtube video is exactly the sort of thing I'd been looking for on EweChoob, but had no luck finding. Thank you. So it's not a night and day difference, but more subtle - there if you know what to look for, but it's not that my ears are broken, hahaha.

Originally Posted by ajk

Here is what it looks like as a waveform:



If we assume that we want to play a pure (sine) tone, it can clearly be seen that the 16 bit version is much less jagged than the 8 bit. A pure tone should only have one frequency, but the jaggies (abrupt changes in the signal) will cause there to be also higher frequency content in the output. Depending on the exact conditions this will manifest as some kind of tingling, squealing or other noise in the sound.

These higher frequencies can be later filtered out, but doing so will mean also losing some of the intended higher frequency content. That is why it would be better to have a better representation (= more bits) of the signal in the first place.

And of course another major issue is also the loss in dynamic range, as Daedalus explained. A quiet tone might only use, say, 3 bits of the range and that will be a very blocky waveform and therefore far from the ideal sound.

Ahh, wonderful, thank you. So that's the intention of the low pass audio filter on the Amiga?

[TroyWilkins]

Originally Posted by esc

I have a stupid Amiga question. Please understand I'm not much of a hardware guy.

I have an OC'd CS Mk2 with a '060 that needs cooling. Is there a preferred heatsink/fan/paste/whatever combo I should look for to keep this cool?

I could be wrong here, but my understanding is that a cooler for a 486/Pentium would do the trick nicely, with something with a fan doing a better job but introducing noise that may or may not concern you. As for thermal paste, probably anything you can get would do the job, although I'd personally go for something that is non-conductive so that if you accidently get any somewhere you don't want it, it's not an issue.

[Daedalus]

Yep, I used a cooler from a 486 on my Blizzard 1260. Works great, but securing it can be a problem since the boards don't have standard heatsink mounts. Thermally conductive glue is one option, but can be difficult to reverse if you ever wish to get rid of the heatsink in the future. Personally I used two lines of thin nylon cord to tie the heatsink down with normal paste and tensioned the lines with a cable tie, but I'm sure others have more elegant solutions.

[Supamax]

Originally Posted by Daedalus

Personally I used two lines of thin nylon cord to tie the heatsink down with normal paste and tensioned the lines with a cable tie, but I'm sure others have more elegant solutions.

Some (even companies like Asus) use bi-adhesive thermal pads between heatsink and IC.
Pro: the adhesive is enough to keep the heatsink fixed
Con: in time (some years), the pads become fragile and may crumble

Thanks dudes! Just ordered some slick 486 heatsink/fan combos and some thermal adhesive pads. Much appreciated!

[drHirudo]

Why Amiga 1000 CPU clock rate is only 7.14 MHz, while the Atari ST managed to get it to 8 MHz. What prevented the Amiga starting at 8 MHz? Did C= save another 0.5$ on quartz generator for the TV signals, while sacrificing 12% of the speed?

[Jope]

Originally Posted by drHirudo

Why Amiga 1000 CPU clock rate is only 7.14 MHz, while the Atari ST managed to get it to 8 MHz. What prevented the Amiga starting at 8 MHz? Did C= save another 0.5$ on quartz generator for the TV signals, while sacrificing 12% of the speed?

Everything is synchronized to the TV screen. The Amiga was designed to get clocked by an external video source from the beginning, so as a result the machine ran at around that same speed even when not externally clocked.

Now since Jay Miner's dead, we can only speculate which feature was the side effect - the capability to get externally clocked or the reduced component count. It most likely wasn't a Commodore thing, but an Amiga Inc thing.

[demolition]

The C64 and VIC 20 are also different in a similar way as the C64 is clocked at 985248 Hz while the VIC 20 is 1108404 Hz thus the VIC 20 CPU is running 12.5% faster despite the fact that CPU is pretty much the same one. I guess it is also the video timings that defined these clocks. In the C64, the video chip is the master on bus while in the VIC 20, the CPU is the master so that could mean something.

Edit: The Amiga CPU is running syncronously to the rest of the system - is that also the case in an Atari? If the Amiga was redesigned to have the CPU run asyncronously, it could be clocked at 8 MHz, but the end result might be a slower system anyway, although pure CPU operations could be a little faster. It would also make it less efficient to make timing-critical code which is used on many demos and games since you cannot rely so much on the timing between the system parts.

[DamienD]

Say I want to use a program and part of the command line to run through all files from a CLI is #?; why does it then process the files in reverse alphabetical order?

Is there a way to process in alphabetical order instead still using #? to select all files?

[Amiga1992]

Originally Posted by TroyWilkins

Ahh, wonderful, thank you. So that's the intention of the low pass audio filter on the Amiga?

The filter is a reconstruction filter, so yes, it is for trying to make up for some of the "resolution" missing between steps. Basically, it removes a little bit of the quantization noise you would hear when it's off.

[Daedalus]

The #? operation is handled by the application itself from what I understand, so it will be down to whatever way the program traverses the directory listing. It should be possible to script it handily enough using List to sort the matching entries and format it with a separate command for each matching entry.

[DamienD]

Thanks man

The program I'm using is PPShow40.

To get around the problem of reverse alphabetical order processing, I manually added each of the 71 files to the command line

...but then I get an error saying "Command too long".

[Amiga1992]

Yes, the List command is very powerful. Personally, I wouldn't mind getting a low-down on how to power-use it. I never quite understood how to use the advanced options of formatting.

[TroyWilkins]

Originally Posted by Akira

The filter is a reconstruction filter, so yes, it is for trying to make up for some of the "resolution" missing between steps. Basically, it removes a little bit of the quantization noise you would hear when it's off.

Ahh, fantastic, thank you. It would be interesting to see the difference in the waveform with and without the low pass filter on - I think I'll have to do some experiments and see if I can produce something for the web site to demonstrate this on the Paula page.

[Daedalus]

List is rather excellent indeed There's a good reference in the AmigaDOS manual, and on wiki.amigaos.net (OS4 site, but most commands are identical).

For what you need, there's the SORT keyword:

List #? SORT NAME

Will give you all entries in alphabetical order. The LFORMAT keyword lets you specify the output format as anything really, by filling a string as you desire. The manual gives lots of placeholders you can use, for example %P is path and %N is filename, so

List #? SORT NAME LFORMAT "%P%N"

Will list the filenames (and their paths if they weren't in the current directory), without the additional flags, dates etc. that you get as standard. We don't want to include any subdirectories, so we add the FILES option:

List #? FILES SORT NAME LFORMAT "%P%N"

Now, to make a script, if we run:

List #? FILES SORT NAME LFORMAT "C:PPShow40 %P%N"

You'll see that you get the filenames listed in alphabetical order with C:PPShow40 before each one. The final step is to direct that to a script:

List #? FILES SORT NAME LFORMAT "C:PPShow40 %P%N" >show.script

Now, instead of the output in the Shell window, you'll have a script you can now execute:

Execute show.script

And you should* be sorted


*I'm going from memory here, apologies if I've made a typo...

Edit: And if you want to exclude all icons, you use the standard AmigaDOS pattern matching:

List ~(#?.info) FILES SORT NAME LFORMAT "C:PPShow40 %P%N" >show.script

[idrougge]

SORT wasn't added until a bit after OS 3.1 (first in the Envoy package, I think), wasn't it?

[Daedalus]

Hmmmm, I was sure it's been there all along, but then I'm using 3.9 and 4.x so long I honestly can't remember when it came in. If that's the case (and you're using 3.1) then scratch my whole post :/

[Jope]

Originally Posted by DamienD

To get around the problem of reverse alphabetical order processing, I manually added each of the 71 files to the command line :crazy

Check S:SPAT and S:DPAT for inspiration here. Sometimes you can use them as they are.