[comp.sys.amiga.tech] Filter ON/OFF

aaron@stat.tamu.edu (Aaron Hightower) (12/17/90)

I have an Amiga3000 and was wondering how I can control the audio filter.
I have an articly previously posted that mentions clearing the 1st bit
in location $BFE001.  This doesn't seem to work correctly on the 3000.

Am I doing something wrong maybe?  Has this changed?  I have seen it done
on my machine; is there some other way to address this feature?

Thanks,
 Aaron Hightower

faheyr@silver.ucs.indiana.edu (Bob Fahey <NECR0SIS>) (12/17/90)

aaron@stat.tamu.edu (Aaron Hightower) writes:

>I have an Amiga3000 and was wondering how I can control the audio filter.
>I have an articly previously posted that mentions clearing the 1st bit
>in location $BFE001.  This doesn't seem to work correctly on the 3000.

Hmm... I'll probably regret posting this, since the last time I did so, 
I got flamed to hell. (I am talking about reading/writing registers directly).
It seems that a few C programmers would rather write a large quantity of code
instead of just dealing with the info at the the source, i.e. registers. (No
offense, C programmers). If someone knows how to toggle the filter in C, I 
would be interested in seeing the code....

Anyway, Here's how I have done it (not saying it is CORRECT, but it works 
nonetheless) ;-)
filter_on:	move.w	#$7000,$bfe000
filter_off:	move.w	#$7002,$bfe000

>Thanks,
> Aaron Hightower

|      ///| a.k.a. NECR0SIS     faheyr@silver.ucs.indiana.edu  -or-          |
|  \\\///_|                     faheyr@rose.ucs.indiana.edu                  |
|   \XX/  |  M  I  G  A      "'Ere long done do does did..."  - The Smiths   |
|             "...life is seen through the eyes of a dog..."  - Skinny Puppy |

espie@ibis.Stanford.EDU (Marc Espie) (12/18/90)

Please Commodore, please... If there is a system way to do it on every
machine, tell us. The way I see it, there will soon be programs playing
with the filter which will work on the 3000 and nothing else. I don't
know what this hardware location hold on other machines
but this IS a compatibility problem.

	Marc Espie

lshaw@ccwf.cc.utexas.edu (logan shaw) (12/18/90)

In article <faheyr.661405562@silver> faheyr@silver.ucs.indiana.edu (Bob Fahey <NECR0SIS>) writes:
>aaron@stat.tamu.edu (Aaron Hightower) writes:
>Hmm... I'll probably regret posting this, since the last time I did so, 
>I got flamed to hell. (I am talking about reading/writing registers directly).
>It seems that a few C programmers would rather write a large quantity of code
>instead of just dealing with the info at the the source, i.e. registers.

It's not that we're C programmers, it's that we're trying to do it correctly,
so it doesn't break later on.  You can write incorrectly in C, and (believe
it or not) you can write *correctly* in assembly as well.

Poking around at the hardware when there is an operating-system interface
is simply not acceptable.  I have done it before, and I've seen it break.
You can't go breaking the rules and expect your software to work on new
machines like the 3000.  Your code may work faster in some cases, but in
some cases it won't work at all.

>Anyway, Here's how I have done it (not saying it is CORRECT, but it works 
>nonetheless) ;-)
>filter_on:	move.w	#$7000,$bfe000
>filter_off:	move.w	#$7002,$bfe000

Written incorrectly in C:
#define FILTER_ON  ( *((short *)0xbfe000) = 0x7000 )
#define FILTER_OFF ( *((short *)0xbfe000) = 0x7002 )

>|      ///| a.k.a. NECR0SIS     faheyr@silver.ucs.indiana.edu  -or-          |
>|  \\\///_|                     faheyr@rose.ucs.indiana.edu                  |
>|   \XX/  |  M  I  G  A      "'Ere long done do does did..."  - The Smiths   |
>|             "...life is seen through the eyes of a dog..."  - Skinny Puppy |

-- 
=----------------Logan-Shaw---(lshaw@ccwf.cc.utexas.edu)----------------=
  "Trust in the Lord with all thine heart, and lean not on thine own
   understanding.  In all thy ways acknowledge Him and he shall direct
   thy paths"        - Proverbs 3:5-6

csg019@cck.cov.ac.uk (-~=Zaphod=~-) (01/07/91)

In article <41560@ut-emx.uucp> lshaw@ccwf.cc.utexas.edu (logan shaw) writes:
>In article <faheyr.661405562@silver> faheyr@silver.ucs.indiana.edu (Bob Fahey <NECR0SIS>) writes:
>>aaron@stat.tamu.edu (Aaron Hightower) writes:
>>Hmm... I'll probably regret posting this, since the last time I did so, 
>>I got flamed to hell. (I am talking about reading/writing registers directly).
>>It seems that a few C programmers would rather write a large quantity of code
>>instead of just dealing with the info at the the source, i.e. registers.
>
>It's not that we're C programmers, it's that we're trying to do it correctly,
>so it doesn't break later on.  You can write incorrectly in C, and (believe
>it or not) you can write *correctly* in assembly as well.
>
>Poking around at the hardware when there is an operating-system interface
>is simply not acceptable.  I have done it before, and I've seen it break.
>You can't go breaking the rules and expect your software to work on new
>machines like the 3000.  Your code may work faster in some cases, but in
>some cases it won't work at all.
You can poke around the dffxxx point if you want to. It wont crash. 
And the code will work faster in *ALL* cases.
The filter can be toggled by using

	eor.b #2,$bfe001
	      ^
	      |
       You wont belive how long this hash sign took to find on this keyboard!

Why is it that C people tend to slag assembly language programmers off and
not visa-versa? Theres room for both languages.
>>filter_on:	move.w	#$7000,$bfe000
>>filter_off:	move.w	#$7002,$bfe000
If i remeber correctly, this might write over some other flags (mouse test for
a start off!)
You could use or.w & and.w instead of move.w for a better effect.

-- 
*********///  O O **A member of S.H.I.T. (Super High Intelegence Team)**///***
*       ///    u    Fight, defeat and kill organized laming.           ///   *
*  \\\ ///    ---      Zaphod (TCC)  csg019@uk.ac.cov.cck ok?     \\\ ///    *
****\\X//**********************************************************\\X//******