🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.amiga.tech
7 messages
7 total messages Started by Jeffrey C Murphy Wed, 12 Dec 1990 02:25
IBM Decode Rephrased
#7419
Author: Jeffrey C Murphy
Date: Wed, 12 Dec 1990 02:25
15 lines
1276 bytes
 OK: I have C1581 formatted disks. When I use the TrackRead option
in RawCopy 1.3g it reads in a track (hence, the name:). If I then
go to the buffer and examine the track, I see raw-mfm data. If I select
Decode MFM, I still get a bunch of garbage. If I select IBM Decode, then
I get the actual data decoded. I know this because I am reading track 39
and after MFM and IBM decoding, it resembles the earlier commodore dir track
formats. All I would like to know is: What Algorithm is used by the IBM
Decode option? 
 Another Question: Can I use TD_RAWREAD to read in a foreign formatted track?
I am trying to write a prog to read and decode the 1581 tracks so that I can
transfer the files over to the amiga (I no longer have a 1581, so 64 emul's 
won't help.)

Thanx agen Jeff M.
Filter ON/OFF
#7513
Author: Aaron Hightower
Date: Mon, 17 Dec 1990 02:26
9 lines
765 bytes
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
Re: Filter ON/OFF
#7514
Author: Bob Fahey <NECR0SIS>
Date: Mon, 17 Dec 1990 03:46
25 lines
1728 bytes
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 |
Re: Filter ON/OFF ; Direct hardware access
#7515
Author: Aaron Hightower
Date: Mon, 17 Dec 1990 05:20
28 lines
1911 bytes
In article <faheyr.661405562@silver> faheyr@silver.ucs.indiana.edu (Bob Fahey <NECR0SIS>) writes:
>aaron@stat.tamu.edu (Aaron Hightower) writes:
>
>>I have an Amiga3000 and was wondering how I can control the audio filter.
>
>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).
>
>filter_on:	move.w	#$7000,$bfe000
>filter_off:	move.w	#$7002,$bfe000
>
>>Thanks,
>> Aaron Hightower

FYI, it worked on the 3000.  I was trying another way that was mentioned before
and couldn't get it to work; just wanted to say thanks, and continue discussion
on hardware registers.  I recently changed a big joystick read portion of one
of my programs to directly read the hardware as described in the HW RKM.
I reduced about 3 pages of code down to about 5 lines.  :-)  I don't think that
there is anything wrong with using hardware registers as long as you are willingto suffer the possible consequences.  In some cases (such as the joystick) I
doubt that I would proceed with the methods described in the Libs/Devs RKM
again.  I found it very tiring to go through so many layers of (unneccesary)
software that inflated my program without need.  It is still possible to write
small C programs, but it is easier to maintain a scope of your program's size
when you are using an assembler (IMHO).  

Thanks for the quick info  
  Aaron Hightower
Re: Filter ON/OFF
#7521
Author: Marc Espie
Date: Mon, 17 Dec 1990 18:07
7 lines
889 bytes
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
Re: Filter ON/OFF
#7529
Author: logan shaw
Date: Tue, 18 Dec 1990 00:32
36 lines
2422 bytes
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
Re: Filter ON/OFF ; Direct hardware access
#7541
Author: Peter da Silva
Date: Tue, 18 Dec 1990 02:04
31 lines
1821 bytes
In article <10942@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
> In article <faheyr.661405562@silver> faheyr@silver.ucs.indiana.edu (Bob Fahey <NECR0SIS>) writes:
> >filter_on:	move.w	#$7000,$bfe000
> >filter_off:	move.w	#$7002,$bfe000

> It is still possible to write
> small C programs, but it is easier to maintain a scope of your program's size
> when you are using an assembler (IMHO).  

This has nothing to do with C versus Assembler. Try this:

	unsigned short *filter = ((unsigned short *)0xbfe000);
	*filter = 0x7000;
	*filter = 0x7002;

(modulo games with volatile to defeat the optimiser)

You can talk to the hardware directly in C, or assembler. You can use the ROMS
in C, or assembler. If you bypass the ROMS one day someone is going to get
pissed off when their whizz-bang joystick handler doesn't work with your
program.

But for the third time that's got nothing to do with whether your program is in
C or assembler, other than that folks who are into assembler are more likely to
want to play with the silicon directly.

Just make sure you get the address of the joystick registers from the ROMs,
and that you tell them you're stealing a game port.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads